Quand le filet de sécurité se décroche en silence

Il y a des pannes qui font du bruit, et il y a celles qui font le contraire. Celle-ci a passé plusieurs semaines dans la deuxième catégorie, et c'est ce qui la rend intéressante à raconter.

Le symptôme

Notre chaîne d'intégration — le contrôle automatique qui relit tout le code à chaque modification — signalait une erreur. Une seule famille d'erreurs, toujours la même formulation : le calcul de ce type demande trop d'étapes, j'abandonne.

On corrige le fichier désigné. On relance. L'erreur réapparaît — ailleurs. On corrige. Elle repart encore ailleurs. Trois passes de correction se sont succédé de cette façon, chacune faisant baisser le compteur sans jamais l'amener à zéro.

Avec le recul, un détail aurait dû nous arrêter bien plus tôt : l'erreur se déplaçait par ordre alphabétique. Ce n'est pas le comportement d'un défaut local. C'est la signature d'une ressource partagée qui s'épuise.

La cause

L'outil qui vérifie notre code a une limite d'effort, et cette limite est commune à l'ensemble du programme. Chacun de nos appels vers l'interface de la plateforme lui demandait de parcourir la liste complète de nos deux cents adresses pour retrouver la bonne. Une fois, c'est indolore. Quatre cent quarante-cinq fois, la limite est franchie.

Le message s'affichait alors sur le dernier appel branché — presque jamais celui qui avait consommé la réserve. C'est le disjoncteur qui saute quand on allume la lampe de chevet : la lampe n'y est pour rien.

Le vrai coût

Le message n'était que la partie visible. Ce qui comptait, c'est ce qui se passait juste avant lui.

Quand la vérification n'a plus les moyens d'aller au bout, elle ne s'arrête pas : elle laisse passer. Des pages entières de notre console manipulaient une réponse dont la forme n'était plus contrôlée du tout. Un champ mal orthographié, une clé absente, un renommage oublié : plus rien ne les aurait signalés.

C'est la nuance qui nous intéresse ici, et elle dépasse largement notre outillage. Une alarme bruyante finit toujours par être traitée — elle dérange. Une protection qui s'éteint discrètement, en laissant le voyant allumé, ne dérange personne. On continue de s'appuyer dessus.

Ce que ça avait laissé passer

Une fois la réserve dégagée, la vérification a retrouvé les moyens de faire son travail. Six défauts réels sont apparus d'un coup — tous présents en ligne, aucun détecté par les contrôles habituels.

Le sélecteur de métier de notre assistant de brief ne se remplissait jamais avec la valeur déjà choisie : reprendre un brief commencé donnait l'impression de repartir de zéro. Quatre autres sélecteurs affichaient leur texte d'invite comme s'il s'agissait d'une option qu'on pouvait retenir. Et le relevé de coût d'une génération de site oubliait de compter les passes de correction — précisément les générations les plus chères.

Aucun de ces défauts n'est spectaculaire. Ce sont des irritants : un formulaire qui se vide, un chiffre légèrement faux. Exactement le genre de choses qu'une vérification automatique est censée attraper avant nous, et qu'elle n'attrapait plus.

Ce qu'on a changé

Nous avons retiré ces appels du mécanisme qui coûtait si cher, par deux portes explicites et documentées. Le compromis est assumé et écrit noir sur blanc dans le code : on renonce à une vérification qui n'opérait déjà plus, au profit d'une déclaration qui, elle, opère.

Deux garanties n'ont pas bougé. La transmission de la session au moment où une page se construit sur nos serveurs — celle qui évite qu'un écran d'administration s'affiche vide — passe toujours par le même chemin. Et la validation des données envoyées reste là où elle a toujours dû être : sur le serveur, à l'arrivée, indépendamment de qui appelle.

Enfin, un test relit désormais l'ensemble du code et refuse le retour d'un appel non encadré, en nommant le fichier et la ligne. Comme tous nos garde-fous, il a été validé en réintroduisant volontairement le défaut, pour vérifier qu'il échoue bien. Un test qu'on n'a jamais vu échouer ne prouve rien.

Ce qu'on en retient

Deux choses, dont une qui ne concerne pas que le code.

La première : quand la même correction fait réapparaître le même problème ailleurs, la cause est en amont. Il faut cesser de traiter les cas un par un et chercher ce qu'ils ont en commun. Nous avons mis trois passes à l'admettre.

La seconde : une protection silencieuse est une protection qu'il faut vérifier de temps en temps. Un voyant vert ne dit pas que tout va bien — il dit que personne n'a signalé le contraire. Ce n'est pas la même chose.