Ce qu'un garde-fou doit refuser

Une règle écrite n'est pas suivie. Une règle codée l'est. Entre les deux, il y a tout ce qui casse en production — et deux jours de travail nous l'ont rappelé assez brutalement pour qu'on l'écrive.

1. La règle qu'on se rappelle ne protège de rien

Il existe une consigne, chez nous, écrite noir sur blanc en tête du script de publication : on travaille dans l'essai, jamais directement dans la production. Elle est claire, elle est courte, elle est au bon endroit. Elle a quand même été enfreinte.

Pas par négligence : par distraction. Quelqu'un — humain ou agent — avait une modification à faire sur cent neuf pages, il l'a faite là où les pages étaient, et il a eu raison de croire que ça marchait. Ça marchait, en effet. Jusqu'au prochain assemblage, qui régénère les pages depuis leurs briques et efface la modification sans un mot.

La leçon n'est pas « il faut mieux lire les consignes ». On les avait lues. La leçon est qu'une règle dont le respect dépend de la mémoire d'une personne n'est pas une protection : c'est un souhait. Une protection, c'est quelque chose qui vérifie tout seul, et qui refuse.

Notre script de publication ne fait donc pas confiance. Il compare la date de chaque page à celle de ses briques, et s'il trouve une page plus récente que ce qui l'a produite, il s'arrête. Il ne corrige pas, il ne devine pas : il nomme le fichier et il rend la main. Le travail fait à la main n'est pas écrasé, et personne n'apprend la perte trois jours plus tard.

2. Un garde qui crie toujours n'est plus lu

Voici l'erreur la plus intéressante de la semaine, parce qu'elle est contre-intuitive.

Nous avons écrit un contrôle qui repère les services trop exposés. Au premier essai, il a signalé quinze problèmes. Quinze. Le réflexe est de se réjouir : le contrôle marche, il trouve des choses. Le réflexe est faux. En regardant chaque cas, un seul était réellement grave ; les quatorze autres étaient déjà fermés par ailleurs, et parfaitement volontaires.

Un contrôle qui signale quatorze faux problèmes pour un vrai ne protège de rien. Il sera lu deux fois, puis survolé, puis filtré, puis oublié — et le jour où il criera pour de bon, personne ne l'entendra. Le bruit ne dilue pas seulement l'attention : il la retourne contre le contrôle lui-même.

Nous l'avons donc réécrit avec trois niveaux au lieu d'un. Grave : il faut agir maintenant, et le script sort en erreur. À surveiller : le risque existe mais rien n'urge, c'est écrit en bas de rapport sans faire échouer quoi que ce soit. Conforme : on n'en parle pas. En mode automatique, il ne dit plus rien tant que tout va bien. Son silence est devenu une information.

C'est un critère de qualité pour n'importe quelle alerte : combien de fois se déclenche-t-elle pour rien ? Au-delà d'une poignée, elle nuit.

3. Vérifier le résultat, pas l'intention

Nos outils fabriquent des pages en clonant une page existante et en remplaçant ce qui doit changer. Une première version faisait ça très bien, et annonçait fièrement « article écrit ». Sauf qu'elle s'ancrait, pour trouver où commencer, sur le premier dessin vectoriel de la page. Or le premier dessin d'une page, c'est le logo du menu. L'outil effaçait donc l'en-tête, la navigation et le titre — et annonçait quand même sa réussite.

« J'ai bien remplacé quelque chose » ne prouve pas « le résultat tient debout ». C'est une distinction qui a l'air théorique jusqu'au jour où elle coûte une page en ligne.

Aujourd'hui, l'outil vérifie que la page produite a encore ses os : son en-tête, son article, son titre, son pied, sa feuille de style. S'il manque un seul de ces morceaux, il n'écrit pas le fichier. Il refuse. Le même principe protège maintenant nos exercices générés : un questionnaire à choix multiples dont la bonne réponse désigne un choix qui n'existe pas serait accepté par n'importe quelle vérification de forme — il noterait faux tout le monde, en silence, pour toujours. On vérifie donc que l'indice pointe bien sur un choix réel, et on rejette sinon. On ne rafistole pas : on rejette.

4. Nommer ce qu'on a refusé

Quand une de nos vérifications écarte quelque chose, elle le dit. Le générateur d'exercices rend la liste de ce qu'il a produit et de ce qu'il a jeté, avec le motif. Le script de publication affiche le nom du fichier fautif, pas seulement un code d'erreur.

Ce n'est pas de la coquetterie. Un outil qui cache ses rebuts laisse croire qu'il ne se trompe jamais, et cette croyance est exactement ce qui empêche de l'améliorer. On préfère un outil qui dit « j'ai écrit six exercices et j'en ai jeté deux, voici pourquoi » à un outil qui en rend six sans rien dire.

5. Restaurer sans demander la permission

Le dernier étage de notre publication est le plus simple à décrire et le plus difficile à accepter. Après avoir poussé les pages, le script va lire le site tel qu'il est réellement servi. Si le contrôle échoue, il ne prévient pas, il ne demande pas : il restaure la sauvegarde prise trente secondes plus tôt et rend la production telle qu'elle était.

Difficile à accepter, parce qu'on perd son travail sans négociation. Mais l'alternative — laisser en ligne quelque chose de cassé en attendant qu'un humain arbitre — coûte toujours plus cher. Une publication ratée qu'on refait, c'est un quart d'heure. Une page morte que personne ne remarque, c'est des jours.

6. Ce que ça change dans notre façon de travailler

Ces garde-fous n'ont pas été conçus dans un moment de sagesse. Chacun a été posé après une casse, et chacun porte, dans son propre code, le récit de ce qui l'a rendu nécessaire. C'est délibéré : quelqu'un qui relit le fichier dans six mois doit comprendre pourquoi cette vérification bizarre existe, sinon il la supprimera en trouvant qu'elle complique tout.

Ce que nous en retenons tient en quatre phrases.

Aucune de ces idées n'est nouvelle. Ce qui l'est, peut-être, c'est d'accepter de les payer : chaque garde-fou ralentit, refuse parfois à tort, et oblige à corriger avant d'avancer. On le paie volontiers. Le prix de l'autre option se règle toujours plus tard, et avec des intérêts.

🔭