Un correctif qui ne passe pas par l'essai n'est pas terminé
Un correctif écrit directement en production n'est pas un correctif : c'est une divergence qui attend de se refermer sur vous. Il aura suffi d'un caractère — une arobase devenue un point — pour casser l'en-tête de vingt pages publiques.
En bref : vingt pages de la vitrine ont été réparées à la main, en production, sans passer par l'essai. L'adresse de la bibliothèque de style y a été recopiée avec une faute :bootstrap.3.3au lieu debootstrap@5.3.3. L'adresse répond 404, le style ne charge jamais, et le menu du site retombe en liste à puces. Personne ne l'a vu, parce que la version anglaise des mêmes pages, elle, était juste.
1. Le circuit qui existait déjà
La tour publie sa vitrine en deux temps. On écrit dans un dossier d'essai, une adresse non indexée le sert, on regarde. Ensuite seulement, et seulement après approbation, une copie part en production. Cette discipline date du jour où l'on s'est aperçu que le dossier du dépôt était la production : un simple git pull publiait, et rien ne séparait « j'écris » de « le monde le voit ».
Le correctif dont il est question ici n'est pas passé par là. Il a été appliqué là où les pages sont servies, pas là où on les écrit.
2. Pourquoi la faute est passée
Corriger en production, c'est corriger sans filet. Trois protections sautent d'un coup.
La relecture saute. Dans l'essai, la page se regarde avant d'exister pour le public. En production, la première personne à relire est un visiteur.
La comparaison saute. La chaîne de publication compare l'empreinte de ce que la production sert à ce que l'essai a validé. Un changement qui n'existe qu'en production est, pour elle, indistinguable d'une corruption — parce que c'en est une.
Le symptôme se cache. Seules les pages françaises ont reçu l'adresse fautive ; les anglaises ont gardé la bonne. Or beaucoup d'outils de contrôle, et beaucoup de navigateurs configurés en anglais, tombent sur la version anglaise. Le site paraissait sain à qui le vérifiait, et cassé à qui le lisait.
3. Le piège suivant, plus grave que le premier
La production est une copie de l'essai. Une réparation faite à la main en production ne survit pas à la publication suivante : la copie écrase l'original, sans message d'erreur, sans trace, souvent des jours plus tard quand plus personne ne fait le lien.
Ici, l'histoire se retourne : comme l'essai était resté juste, c'est la publication normale qui répare les vingt pages. Mais l'inverse était tout aussi possible — un correctif utile appliqué hors circuit, effacé à la publication suivante, et un bug qui revient tout seul sans que personne ne comprenne pourquoi.
4. Ce qu'on en fait
- On ne réécrit pas la production à la main. Jamais, même pour une ligne, même quand ça presse. Le circuit essai → approbation → production existe pour que « ça marche chez moi » ne soit jamais la dernière vérification.
- On vérifie l'adresse d'une ressource, pas seulement sa présence. Une balise bien formée qui pointe vers une adresse morte a exactement l'air d'une balise qui marche. Un contrôle qui lit le HTML ne verra rien ; un contrôle qui demande la ressource verra le 404.
- On contrôle les deux langues. Une vérification qui suit la langue du navigateur ne teste qu'une moitié du site — et se trompe de moitié une fois sur deux.
- On détecte la divergence au lieu de l'attendre. Comparer les deux dossiers coûte quelques secondes ; découvrir des semaines plus tard qu'ils ont divergé coûte une soirée.
La leçon tient en une phrase : un correctif qui ne passe pas par le chemin normal n'est pas terminé, il est déplacé. Il vit dans l'angle mort du système — et il y meurt, ou il y pourrit.