La valeur n'était pas fausse : c'est le contexte qui avait bougé

Nous avons relevé quatre défauts en une semaine sur nos outils. Ils n'ont rien à voir entre eux : un panneau mal découpé, un liseré invisible, un import qui ne produit rien, du texte qui s'affiche avec ses astérisques.

Ils ont pourtant la même cause, et c'est celle-ci : la valeur écrite dans le code était juste le jour où elle a été écrite, et personne ne l'a jamais modifiée. C'est le contexte autour d'elle qui a changé.

Les quatre

Une taille par défaut de vignette, déclarée pour un navigateur de contenu qui occupe tout l'écran. Réutilisé dans une bande étroite, ce même composant déborde de sa zone de découpe et perd les deux libellés sous l'image.

Des couleurs de statut, posées une seule fois pour deux thèmes. En thème sombre elles sont nettes. En thème clair, leur contraste passe sous le seuil que le fichier s'impose lui-même par écrit, et les liserés de réussite et de refus s'effaçaient.

Deux plafonds dans un même fichier. Une constante valait 64, exacte quand la réserve en comptait 160, fausse dès qu'elle est passée à 352.

Cette réserve n'a pas grandi toute seule : elle a été relevée exprès. Et des deux endroits qui en dérivaient leur valeur, un a été mis à jour et l'autre non. Celui qui l'a été calcule désormais sa valeur au lieu de l'écrire ; l'autre a gardé son 64 littéral.

Le second plafond est du même bois. Une boucle s'arrêtait à 32, exacte quand le navigateur avait 32 emplacements fixes, fausse dès que ses cartes ont été mises dans une liste sans plafond. Le projet de l'utilisateur en comptait exactement 32 : chaque import créait ses objets sans écrire une seule carte.

Une règle d'affichage qui préservait les retours à la ligne. Juste tant que le contenu était du texte brut, fausse dès que le même champ a reçu du markdown, qui produit ses propres paragraphes.

Ce que cela change pour qui cherche

Chercher un coupable ne marche pas. Il n'y a personne à blâmer à l'endroit du défaut. Celui qui a écrit la valeur avait raison, et celui qui a changé le contexte n'a pas regardé toutes les valeurs que son changement rendait fausses. Il n'en avait pas la liste, et c'est bien le problème.

Regardez notre troisième cas de plus près : il en avait regardé une sur deux. Le travail avait été fait, et bien fait, à l'endroit qu'il avait sous les yeux. C'est la duplication qui a fait le reste.

Le symptôme ment sur son lieu. La carte qui déborde ressemble à un défaut d'alignement du composant. Le liseré invisible ressemble à un liseré qu'on aurait oublié de dessiner. La borne à 32 ressemble à un import qui échoue. Dans les trois cas, on cherche longtemps là où il n'y a rien.

Et la parade n'est pas de mieux relire. Sur le troisième cas, le correctif n'a pas été de remplacer 64 par 256. Il a été de dériver la valeur de la taille de la réserve, pour que la prochaine fois que le contexte bouge, la valeur bouge avec lui.

Le second plafond le montre mieux encore. Migrer l'appelant en recopiant simplement sa borne de 32 aurait remis exactement le défaut que la réécriture existait pour supprimer, et la construction serait repassée au vert, ce qui aurait clos le dossier. Le correctif le plus propre en apparence était celui qui remettait le défaut.

Et cela ne touche pas que les valeurs. Un outil de gestion de versions annonçait qu'une branche fusionnerait proprement. C'était vrai, contre l'état du dépôt à cet instant. Après une autre fusion, la même prédiction annonce neuf zones de conflit.

Une vérification se périme donc exactement comme une constante, et plus vite qu'elle : elle répond sur un contexte, jamais dans l'absolu. Le résultat qu'on note dans un compte rendu a une date de péremption que personne n'écrit à côté.

C'est la seule leçon qui tienne : une constante écrite en dur est un pari sur le fait que son contexte ne changera jamais. Ce pari se perd toujours, et il se perd en silence, des mois plus tard, chez quelqu'un d'autre.