Trois pannes en une matinée, et la même règle à chaque fois
Ce matin, trois choses ont cassé. Aucune n'a été réparée là où elle se voyait.
C'est une règle que nous avons codée, pas seulement écrite : on répare la cause, puis la conséquence. Jamais l'inverse, jamais l'une sans l'autre. Voici les trois cas, dans l'ordre où ils sont arrivés.
Premier cas : le bouton qu'on ne pouvait pas cliquer
Patrick ouvre une page où dix articles attendent sa validation. Il clique. Rien.
Le symptôme dit : « le bouton est cassé ». La tentation est de refaire le bouton.
Nous avons commencé par écrire les contrôles. Sept d'entre eux sont passés au vert du premier coup : la page répond, le bouton est là, le programme de la page est valide, l'enregistrement fonctionne. Tout marchait.
Le fichier qui garde les choix, lui, ne contenait qu'une ligne — celle écrite par notre propre test. Aucune trace de Patrick. Son clic n'était jamais arrivé.
La cause n'était pas le bouton. La page tournait comme un programme lancé à la main, accroché à une session de travail. Chaque fois qu'on la relançait, elle mourait quelques secondes. Nous avons mesuré ces trous nous-mêmes : la page répondait « code 0 », c'est-à-dire personne au bout du fil. Patrick est arrivé pendant un de ces trous.
Il y avait un second défaut, plus discret : même quand ça marchait, la page ne disait rien après un clic. Impossible de savoir si ça avait pris.
Deux réparations, donc. La page est devenue un service qui se relève tout seul — nous l'avons tuée brutalement, elle répondait cinq secondes plus tard. Et elle affiche maintenant, à côté du bouton, « douze validés — enregistré » en vert, ou « pas enregistré » en rouge.
Deuxième cas : le bouton qui disait avoir travaillé
Plus tard, trois boutons s'affichent « déjà lancé ». Patrick n'a rien cliqué. Et les articles ne sont pas en ligne : le site répond « cette page n'existe pas ».
Là encore, le symptôme trompe. On pourrait effacer l'état et passer à autre chose.
En lisant le programme, la cause saute aux yeux. Le tableau de bord écrivait « fait » au démarrage du script, jamais à sa réussite. Il lançait le programme et notait « fait » dans la seconde, sans jamais regarder le résultat. Un script pouvait échouer immédiatement : le bouton restait vert.
Pire : « déjà lancé » remplaçait le bouton. Impossible même de réessayer.
C'est exactement le contrôle aveugle que nous dénonçons ailleurs : il ne tombe jamais en panne, il rassure.
Le tableau attend maintenant le résultat. Quatre états au lieu de deux — à lancer, en cours, réussi, échoué — et le bouton reste toujours cliquable.
Troisième cas : le mot écrit deux fois
Dix articles partent enfin. Les dix sont refusés. Le message est identique à chaque ligne :
REFUS (article-metatron) : article-article-metatron.html absent de l'essai
Le mot « article- » apparaît deux fois. On pourrait renommer les fichiers pour que ça passe. Ce serait réparer la conséquence.
Nous sommes allés lire la porte de publication. Ligne 94 :
FICHIERS="article-$SLUG.html"
La porte ajoute « article- » elle-même. Il fallait donc lui donner le nom nu — « metatron » — et surtout pas « article-metatron ». Le fichier, lui, s'appelle bien article-metatron.html. Les deux ne sont pas la même chose, et c'est tout le piège.
Renommer les fichiers aurait marché, une fois. Puis cassé au prochain article.
Ce que ces trois cas ont en commun
Dans les trois, l'endroit où ça se voit n'est pas l'endroit où c'est cassé.
Un bouton qui ne répond pas, ce n'est pas un bouton cassé : c'est un serveur mort. Un état qui ment, ce n'est pas un état à effacer : c'est un programme qui ne regarde pas ses résultats. Un fichier introuvable, ce n'est pas un fichier à renommer : c'est un nom donné deux fois.
Réparer le symptôme, c'est essuyer l'eau par terre sans fermer le robinet. Ça revient. Plus tard, plus loin, plus cher.
Le test qui a d'abord dit non
Il reste une question : comment savoir qu'on a touché la vraie cause ?
Un test écrit après la réparation passe au vert même si on a réparé le mauvais endroit. Il ne prouve rien. Seul un test qui a d'abord échoué sur la cause prouve quelque chose.
Nous l'avons fait à chaque fois. Le contrôle « la page ne dit rien après un clic » était rouge. Le contrôle « le tableau dit fait dès le démarrage » était rouge. Le contrôle « le script passe un nom avec article- » était rouge. Puis vert, après.
Et pour le tableau de bord, nous sommes allés plus loin : nous avons fabriqué un bouton qui rate volontairement. Le tableau a répondu :
"echoue": true, "code": 3, "pourquoi": "je vais rater expres"
Rouge, avec la raison, et un bouton « Réessayer ». Ensuite seulement nous avons retiré cet essai.
Un garde qui n'a jamais dit non est une promesse, pas un garde.
La règle est devenue un garde-fou
Une règle écrite n'est pas suivie ; une règle codée l'est.
Nous avons donc posé un garde qui refuse toute réponse annonçant une réparation sans deux choses dans le même message : la cause, nommée en clair, et un test vu rouge avant. Il tourne pour nos deux assistants. Son propre banc d'essai donne seize contrôles verts sur seize, dont cinq refus réellement observés.
Deux sorties restent toujours permises, parce qu'elles sont honnêtes : « je ne sais pas encore pourquoi, voilà ce qui trancherait », et « ce geste appartient à un humain ». Ce qui est interdit, c'est d'annoncer une réparation sans cause, ou avec un test qui n'a jamais eu l'occasion de dire non.
Et la conséquence, alors ?
On la répare aussi. Toujours après, jamais à la place.
L'état menteur a été effacé. Les fichiers ont gardé leur nom. La page a retrouvé ses boutons. Mais chacune de ces réparations est venue après que la cause soit fermée — sinon nous aurions simplement remis à zéro un compteur qui allait mentir de nouveau dans l'heure.
Trois pannes, une matinée, une seule règle. Ce n'est pas de la rigueur pour la rigueur : c'est la différence entre une journée de travail et la même journée refaite demain.