Atelier Multidécor fabrique des cuisines et des armoires sur mesure à Saint-Siméon-de-Bonaventure, en Gaspésie, depuis 1994. Telos Machina héberge et entretient le site de l’atelier sur Cloudflare Workers. À l’été 2026, l’outil de surveillance externe a commencé à signaler une panne plusieurs fois par jour, alors que chaque vérification manuelle montrait un site en ligne, rapide, sans erreur. Cet article documente le diagnostic qui a suivi, la réparation, et le travail de vitesse et de structure qui l’a accompagné. Il ne contient aucun chiffre de trafic, de classement ni de revenu. Ces données se suivent ailleurs, hors de ce texte.
Le moniteur qui criait au loup
Le moniteur de disponibilité surveille ateliermultidecor.com depuis le 13 juillet 2026. Depuis cette date, l’alerte revenait plusieurs fois par jour, toujours avec le même message : délai de 48 secondes dépassé. Jamais un code d’erreur. Jamais une connexion refusée.
Chaque fois qu’on vérifiait le site à la main pendant une alerte, il répondait normalement, en une fraction de seconde. L’hypothèse la plus simple, dans ce genre de situation, est que le moniteur lui-même a un problème : réseau, résolution de nom, ou configuration de l’outil. Trois vérifications ont fermé cette piste.
Sept autres sites surveillés par le même outil, depuis le même conteneur, la même résolution DNS et la même adresse Cloudflare, sont restés à 100 % de disponibilité pendant toute la période : telosmachina.ai, anniedallaire.ca, 21km.ca, gazonnet.ca et deux outils internes. La résolution DNS du site d’Atelier Multidécor était identique, octet pour octet, à celle des sites en bonne santé. Les huit moniteurs partageaient exactement le même intervalle de vérification, le même délai et le même nombre de tentatives. Le moniteur n’était pas en cause.
Une panne que les vrais visiteurs n’ont jamais vue
La deuxième hypothèse était plus inquiétante : que le site ralentissait vraiment par moments, et que les visiteurs ordinaires en payaient le prix sans s’en plaindre. Les journaux du réseau Cloudflare ont tranché dans l’autre sens.
Pendant les heures où chaque sonde de surveillance restait bloquée, plus de 800 requêtes réelles se terminaient avec succès à la même heure, sans une seule erreur. Le site n’était pas en panne. Il l’était seulement pour une catégorie de visiteur très précise : la sonde de surveillance elle-même.
Le signal dans les journaux d’exécution
La réponse était dans les journaux d’exécution du Worker, le programme qui traite chaque requête sur le réseau de Cloudflare. Chaque appel bloqué montrait la même signature : environ 78 secondes d’attente, environ 5 millisecondes de calcul réel, et zéro sous-requête complétée. Un visiteur qui ferme sa page en plein chargement laisse une trace complètement différente, autour d’une demi-seconde pour chacun des deux chiffres.
Le compte horaire des appels bloqués collait exactement au compte horaire des alertes du moniteur : trois appels bloqués à 14 h contre trois alertes, neuf contre neuf à 15 h, dix contre dix à 16 h, zéro contre zéro entre 10 h et 13 h. Un chiffre identique dans deux systèmes différents n’est plus une coïncidence.
La cause : un Worker qui s’attendait lui-même
La cause tenait en une phrase, une fois trouvée. Les versions du programme d’hébergement antérieures à 1.20.1 font en sorte que le Worker s’appelle lui-même par une requête web ordinaire, pour traiter sa propre file d’attente de mise à jour des pages (le mécanisme qui garde une page à jour sans la reconstruire au complet à chaque visite).
Cloudflare interdit ce genre d’appel : un Worker ne peut pas s’invoquer lui-même par une requête web ordinaire sur le même compte. La requête restait donc en attente pour toujours, ce qui correspond exactement au signal observé : presque aucun calcul, aucune sous-requête complétée, un délai qui finit par expirer côté visiteur plutôt que côté serveur. La version 1.20.1 remplace cet appel par un mécanisme interne conçu pour ce type de communication.
Pourquoi ce genre de diagnostic compte
Un plombier qui ne sait pas pourquoi un tuyau fuit répare le symptôme visible et attend la prochaine fuite. Le même réflexe existe en hébergement web. Sans les journaux d’exécution du Worker, la piste la plus facile aurait été de blâmer le moniteur, de baisser la fréquence des alertes, ou d’ignorer les fausses alertes.
Aucune de ces trois réponses n’aurait réglé quoi que ce soit. Le Worker aurait continué de rester bloqué sur les mêmes requêtes. Le diagnostic a coûté du temps de lecture de journaux plutôt qu’une intervention rapide. C’est le compromis qu’on fait chaque fois qu’un signal ne correspond pas à ce qu’il devrait vouloir dire.
Le piège de la fenêtre propre
La réparation elle-même a été rapide une fois la cause connue : mise à jour du programme d’hébergement et de Next.js, le moteur du site. La vérifier a pris plus de temps, et a bien failli tromper l’équipe à trois reprises.
Chaque nouveau déploiement remet à zéro toutes les copies actives du site dans le monde entier. Une période sans panne juste après un déploiement ne prouve donc rien : elle serait identique avec ou sans réparation. La discipline retenue a été de mesurer d’abord la meilleure période sans panne que l’ancien code, non réparé, avait lui-même réussi à tenir entre deux incidents : 30 heures et 23 minutes. La réparation n’a compté comme confirmée que le jour où elle a battu ce chiffre, le 30 juillet, à 46 heures et 44 minutes sans incident.
Un critère plus strict, sept jours consécutifs sans le moindre déploiement, n’a encore jamais pu être rempli : le site continue d’évoluer, et chaque nouveau déploiement remet le chronomètre à zéro. Un chantier actif ne satisfait peut-être jamais ce genre de seuil.
Une faille de sécurité fermée au passage
La mise à jour a réglé autre chose en chemin. Le site tournait sur Next.js 16.1.6, une version en dessous du plancher que Telos Machina impose sur ses propres sites (16.2.6 ou plus récent) à cause d’une faille connue dans le traitement des langues (CVE-2026-44573), qui permet de contourner certaines règles de routage bilingue. Le nouveau programme d’hébergement exige justement Next.js 16.2.6 ou plus récent pour fonctionner.
La panne fantôme et la faille de sécurité ont donc été réglées dans le même déploiement, le 27 juillet 2026. Deux problèmes de nature complètement différente, réglés par le même changement de numéro de version. Ça n’arrive pas souvent, alors ça mérite d’être noté.
Le reste du chantier : vitesse, images et structure
Le diagnostic de la panne fantôme n’était qu’une partie du travail. Une série de correctifs de vitesse et d’image a suivi, chacun mesuré avant et après. Le LCP, le temps d’affichage du plus gros élément visible d’une page, est la mesure que Google utilise pour juger la vitesse perçue d’une page.
| Élément | Avant | Après |
|---|---|---|
| Score d’accessibilité (Lighthouse mobile) | 96 | 100 |
| Poids HTML de la page d’accueil | 333 283 octets | 86 042 octets |
| Image d’en-tête (format AVIF) | 253 Ko | 25 Ko |
| Polices préchargées | 10 | 4 |
| LCP, page d’accueil (correctif du logo) | 7,1 s | 6,4 s |
| LCP, page de ville (image principale chargée en priorité) | 5,1 s | 3,8 s |
| Score Lighthouse mobile, page de ville | 79 | 88 |
La plus grosse partie de la réduction du poids HTML venait d’un fichier de traduction qui chargeait les deux langues du site en une seule fois, plutôt que seulement celle demandée. Les dix polices préchargées au départ pesaient ensemble 376 kilo-octets et ralentissaient l’affichage du plus gros élément visible au lieu de l’accélérer, l’effet inverse de ce que le préchargement est censé faire. Il en reste quatre.
Un bogue distinct causait aussi une boucle sur les adresses inconnues du site : chaque page introuvable relançait une redirection vingt fois de suite avant de s’arrêter, à chaque chargement. Corrigé le 2 septembre.
Le plan du site, le fichier qui liste chaque page pour les moteurs de recherche, comptait 64 adresses le 5 août. Il en compte 92 aujourd’hui, dont douze pages consacrées à des villes de la Gaspésie et du Bas-Saint-Laurent, chacune écrite pour sa propre localité plutôt que copiée d’une ville à l’autre. Le site a aussi reçu la structure technique que Telos Machina utilise sur ses propres pages : données structurées par page, correspondance français-anglais pour les moteurs de recherche, soumission automatique des nouvelles adresses, et un accès ouvert aux robots de lecture de contenu plutôt que le blocage par réflexe que beaucoup de sites appliquent aujourd’hui. Dix-huit photographies réelles de pièces de Félix Gagné, l’ébéniste derrière l’atelier, ont remplacé des images génériques ou générées par ordinateur sur les pages principales début septembre.
FAQ
Le site d’Atelier Multidécor est-il vraiment tombé en panne ?
Pas pour ses visiteurs. L’outil de surveillance signalait une panne plusieurs fois par jour, mais les vraies visites à la même heure se terminaient toutes avec succès. La panne existait, seulement pas là où elle semblait être.
Qu’est-ce qui causait le problème ?
Un bogue dans le programme qui héberge le site sur le réseau de Cloudflare, présent dans toute version antérieure à 1.20.1. Ce programme tentait de s’appeler lui-même pour traiter sa propre file d’attente de mise à jour des pages, une opération que Cloudflare ne permet pas entre deux copies d’un même site. La requête attendait une réponse qui ne viendrait jamais.
Ce genre de bogue est-il visible pour un propriétaire d’entreprise ?
Rarement. Il ne fait pas planter le site pour un client qui navigue normalement. Il se cache dans les journaux techniques d’hébergement et dans le comportement d’un outil de surveillance externe, ce qui explique pourquoi il peut passer inaperçu longtemps.
Où voit-on les résultats de recherche de ce projet ?
Pas ici. Ce texte documente ce qui a été diagnostiqué et réparé sur le site lui-même. Les chiffres de visibilité dans les moteurs de recherche se suivent ailleurs et ne font pas partie de cet article.
On répare ce genre de panne avec la même rigueur qu’on documente ici : établir ce qu’un système fait vraiment avant de décider comment le corriger. Notre page sites web explique comment on aborde l’hébergement et la vitesse pour une PME artisanale.