Vérification et preuve

Chaque vérification a besoin d'un témoin positif

La plupart des cours vous apprennent à écrire des tests. Peu vous apprennent ceci : une vérification cassée ne s'annonce généralement pas avec une erreur. Elle rapporte silencieusement zéro problème, et zéro problème se lit exactement comme un succès. Si personne n'a intégré un moyen de distinguer "vraiment propre" de "la vérification elle-même est cassée", vous ne le remarquerez pas, et personne lisant le rapport non plus.

Voici le correctif, énoncé comme une règle : un script de vérification doit chercher, dans la même passe, au moins une chose qu'il doit trouver. C'est ce qu'on appelle un témoin positif, un cas connu comme mauvais, planté ou présent dans les données, que la vérification est garantie d'attraper si elle fonctionne. Sans témoin positif, une vérification qui ne trouve rien est indiscernable d'une vérification qui compte mal silencieusement, lit mal son entrée, ou regarde au mauvais endroit entièrement. Deux cas mesurés rendent cela concret : un motif d'échappement cassé a un moment montré zéro violation signalée là où des milliers auraient dû apparaître, et un autre motif cassé a signalé 136 violations qui n'existaient pas. Les deux venaient exactement de la même cause profonde : une vérification qui n'avait jamais été testée elle-même.

La même logique s'étend au-delà des vérifications de code, vers tout ce qui tourne sur un planning sans humain qui surveille. Le code de sortie d'un planificateur n'est pas une preuve suffisante qu'une tâche a fait son travail : un script peut rapporter un succès encore et encore pendant que le travail qu'il était censé faire échoue silencieusement pour une raison extérieure à sa propre gestion d'erreurs, comme une dépendance que le script supposait présente et qui ne l'était pas. Le correctif consiste à croiser deux signaux : l'état propre du planificateur (la tâche est-elle activée, quel était son dernier code de sortie, quand a-t-elle tourné pour la dernière fois) et un témoin au niveau applicatif que la tâche écrit elle-même en cas de succès : un fichier horodaté, un champ de données précis, ou le rapport daté le plus récent atterrissant dans un dossier. Une tâche sans un tel témoin devrait être rapportée comme non vérifiable, jamais supposée saine par défaut simplement parce que rien ne s'est plaint.

L'ordre compte plus qu'il n'y paraît. Câblez d'abord l'écriture en cas de succès, faites vraiment tourner la tâche une fois pour de vrai afin que le témoin soit produit, et seulement ensuite déclarez la vérification active. Faire cela à l'envers, déclarer une vérification de témoin avant que quoi que ce soit n'écrive le témoin, n'est pas un petit faux pas : dans un cas réel, cela a créé six fausses alertes permanentes, des alertes qui ont entraîné les gens à ignorer tout le système de surveillance, ce qui est pire que de n'avoir aucun système.

Une dernière habitude clôture ceci : une vérification de complétude qui résume plusieurs conditions derrière une seule phrase cache exactement combien d'entre elles sont vraiment testées. "Toutes les vérifications ont réussi" posé sur une règle qui couvre silencieusement trois conditions distinctes peut réussir alors qu'une seule des trois est vraiment vérifiée. Énumérez les conditions qu'une vérification couvre, ne les résumez pas, et enfin, testez tout le mécanisme exprès : renommez un témoin (ne le supprimez jamais) et confirmez que la vérification réagit à chaque fois, puis restaurez-le. Un mécanisme de détection qui n'a jamais été testé ainsi est du code non vérifié portant une coche verte, et un mécanisme "tout va bien" périmé est pire que pas de mécanisme du tout.

Testez le vérificateur avant de faire confiance au verdict

Vous venez d'écrire un script pour mesurer quelque chose : combien de problèmes existent, combien de caractères correspondent à un motif, combien de fichiers sont correctement nommés. Le script s'exécute, affiche un chiffre, et ce chiffre paraît plausible. Voici le fait inconfortable sur lequel repose cette leçon : un chiffre plausible et un chiffre correct ne sont pas la même chose, et l'écart entre les deux ne s'annonce presque jamais de lui-même.

Lors d'un seul audit, cinq mesures écrites maison se sont avérées fausses, chacune pour une raison subtile totalement différente : une vérification de répertoire qui renvoie faux sur un lien symbolique, comme si le dossier lié n'existait pas. Une comparaison au niveau des octets qui compte mal les caractères composés de plusieurs octets, fréquent avec les lettres accentuées. Une redirection shell qui injecte silencieusement un marqueur d'ordre des octets invisible au début d'un fichier, faussant tout ce qui le lit ensuite. Une expression régulière dont le point ne correspond pas à travers les fins de ligne de style Windows, sautant silencieusement du contenu qui chevauche un saut de ligne. Et une opération de regroupement qui ignore la casse des lettres, fusionnant discrètement des éléments qui auraient dû rester distincts.

Aucune de ces cinq erreurs ne s'est annoncée. Chacune a produit un chiffre qui paraissait tout à fait raisonnable, et chacune était fausse. C'est la leçon centrale : un script de mesure défaillant échoue rarement bruyamment, il échoue en vous donnant une réponse fausse et pleine d'assurance, que vous n'avez aucune raison de mettre en doute sauf à aller spécifiquement la chercher.

Le correctif est une habitude qui coûte quelques minutes et qui devrait s'exécuter avant que vous ne fassiez confiance à la première sortie réelle d'un script de mesure : donnez au script un auto-test avant de faire confiance à son verdict. Fournissez-lui une entrée fabriquée qu'il doit absolument signaler, et une entrée propre qu'il ne doit absolument pas signaler, et assurez-vous que les deux cas de test couvrent les cas limites réalistes de votre propre terrain : fins de ligne différentes, caractères accentués ou multi-octets, liens symboliques, et casse mixte. Si le script ne peut pas classer correctement ses propres cas de test à réponse connue, son verdict sur des données réelles ne vaut rien, peu importe à quel point ce verdict paraît plausible.

Un exemple réel de ce phénomène : un vérificateur de liens morts a un jour signalé 23 problèmes, dont seulement 2 étaient de véritables problèmes réels. La plupart des autres venaient d'une incohérence de convention de nommage que le vérificateur n'avait pas prise en compte, et deux bugs distincts de faux positifs se cachaient sous ce bruit : un marqueur d'ordre des octets mal interprété comme un bloc de métadonnées manquant, et un exemple entre guillemets à l'intérieur d'un bloc de code mal interprété comme une véritable violation de style. Ces deux bugs précis n'ont été trouvés qu'en testant le détecteur lui-même contre des cas connus, pas en scrutant plus attentivement sa sortie. Cela pointe vers une vérité plus large qui mérite d'être retenue en soi : une fausse accusation coûte autant de confiance qu'un défaut manqué, donc mesurez le taux de faux positifs de votre détecteur, pas seulement ce qu'il attrape. Et sur Windows en particulier, sachez que rediriger la sortie d'un script vers un fichier via un opérateur shell peut injecter des artefacts d'encodage qui cassent tout ce qui lit ce fichier ensuite ; faire en sorte que le programme écrive lui-même son fichier de sortie évite toute cette classe de problème.

Corrigez la classe du défaut, pas l'instance

Quand vous corrigez un bug, le point d'arrêt naturel semble être le moment où le cas signalé fonctionne à nouveau. C'est cet instinct qui rend un correctif trop étroit. L'habitude qui mérite d'être construite est différente : après chaque correctif, demandez vous à quelle famille appartient le défaut, puis balayez tous les autres membres de cette famille dans la même passe, avant de passer à autre chose.

Trois correctifs réalisés le même jour ont rendu cela concret. Un chemin codé en dur a été sécurisé, tandis qu'un chemin jumeau portant le défaut identique est resté intact. L'un des deux verrous d'alerte dupliqués a été réinitialisé, tandis que l'autre est resté bloqué. Un témoin de succès a été ajouté à un processus surveillé, mais pas au moniteur distinct qui lit sa sortie. Chacun de ces correctifs, pris isolément, était correct. Chacun était aussi trop étroit, et tous les trois ont suivi exactement la même forme : corriger l'instance qui se trouve devant vous, manquer le jumeau situé à un fichier ou un module de distance.

Aucun de ces trois cas n'a été détecté par la personne qui a écrit le correctif. Tous les trois ont été détectés par une revue adverse, c'est à dire une seconde passe dont tout le travail consiste à chercher exactement ce motif. C'est là la véritable distinction entre une revue qui apporte de la valeur et une revue qui ne fait que revérifier le même travail : une simple revérification demande si ce correctif fonctionne. Une revue adverse utile demande où ailleurs ce défaut exact vit encore.

• Correctif d'instance : répare le cas spécifique qui a été signalé.
• Correctif de classe : répare chaque élément de la même famille qui partage le même motif sous jacent.
• Revue adverse : une seconde passe dont le mandat est de chasser les membres survivants de la famille, pas de revérifier le seul correctif qui fonctionne déjà.

À retenir en pratique : au moment où un correctif est appliqué, nommez à voix haute la classe de bug à laquelle il appartient (une valeur codée en dur, un état dupliqué, un témoin manquant), puis cherchez tous les autres endroits où ce motif pourrait se reproduire, dans la même session de travail.

Une correction est terminée quand elle converge avec une source que vous n'avez pas produite

Une amélioration spectaculaire donne l'impression d'une preuve. Un chiffre chute de 79 pour cent juste après que vous avez corrigé une cause identifiée, votre propre vérification interne passe au vert, et il est tentant de déclarer la correction terminée. Cette impression est exactement à l'envers. Une forte baisse est un signal de progrès, jamais une preuve de correction, et le moment où elle paraît la plus spectaculaire est le moment où vous êtes le plus tenté de supposer que la cause était unique, alors que plusieurs causes s'empilent souvent sur le même chiffre.

La seule chose qui ferme réellement la boucle est l'accord avec une source que vous n'avez pas produite vous même, une source indépendante. Dans un cas, un chiffre a chuté de 79 pour cent après un correctif, semblait terminé, et ne l'était pas : le comparer à un fichier comptable indépendant a révélé une seconde cause, sans rapport, que la baisse spectaculaire du premier correctif avait simplement masquée. La correction n'a été véritablement terminée qu'une fois que le chiffre a convergé avec cette source extérieure, pas quand la vérification interne est passée au vert.

La même discipline s'applique à tout chiffre destiné à un humain ou à un client : relisez le depuis la source faisant autorité, en production, jamais depuis un clone de développement local. Un clone dérive même s'il a commencé comme une copie exacte, et un chiffre rapporté s'est trouvé faux d'un ordre de grandeur exactement pour cette raison, une base de données locale périmée tenant lieu de la vraie.

Il existe un second piège, symétrique : un correctif correct peut créer sa propre régression ailleurs. Qualifier un délai dans un langage plus précis a allongé chaque chaîne de texte juste assez pour faire passer deux fois plus de pages au delà d'une limite de longueur. Le correctif était correct en ses propres termes et a quand même cassé autre chose. Intégrez la remesure de la même métrique dans l'outil lui même, et pesez toute régression signalée par ce qu'elle coûte réellement, si le texte affecté porte toujours son sens, plutôt que par le simple compte d'éléments au delà d'un seuil.

• Convergence : accord entre votre chiffre corrigé et une source indépendante que vous n'avez pas produite.
• Cause masquée : un second défaut, sans rapport, caché par l'ampleur de la baisse du premier correctif.
• Dérive : l'écart qui s'ouvre entre un clone de développement et la source de production en direct au fil du temps.
• Régression couplée : un effet de bord qu'un correctif correct introduit ailleurs dans le même système.

À retenir en pratique : ne déclarez jamais une correction terminée sur la seule force de la baisse. Vérifiez la par rapport à une source que vous n'avez pas construite, relisez les chiffres destinés aux clients depuis la production, et remesurez la même métrique après que le correctif est appliqué.

Marquez l'achèvement sur le résultat, jamais sur la tentative

Une automatisation qui marque une tâche comme terminée, la retire d'une file d'attente, la compte comme un succès, ou sort avec un code de statut zéro dès l'instant où elle est tentée, plutôt que lorsqu'elle réussit réellement, peut perdre du travail pour toujours sans que personne ne le remarque. Le danger n'est pas l'échec lui même. C'est que le système rapporte un succès quand même, si bien que rien ne vous dit jamais d'aller vérifier.

Un véritable script de synchronisation a fait exactement cela : il a accumulé 239 échecs consécutifs et zéro succès sur plusieurs semaines, tout en marquant chaque session comme synchronisée, en la retirant de la file, et en sortant avec le code zéro à chaque fois. Les trois couches de surveillance construites pour le surveiller ont toutes rapporté que tout allait bien, parce que chacune d'elles lisait la tentative, pas le résultat.

Le correctif est un changement dans ce qui est enregistré et quand. En cas d'échec, le travail devrait rester en file d'attente, avec un compteur de tentatives persisté et plafonné à un petit nombre d'essais, et il ne devrait être abandonné que par une ligne de journal explicite, jamais par un abandon silencieux qui ne laisse aucune trace. Le compteur de succès et le code de sortie ne doivent refléter que de véritables succès. Et un témoin de succès devrait mesurer ce que la tâche a réellement produit, un fichier qui a été écrit, un horodatage qui a avancé, pas simplement que le processus s'est terminé sans planter.

• Tentée : la tâche s'est exécutée, quel que soit le résultat.
• Réussie : la tâche a produit le résultat spécifique et observable qu'elle existe pour produire.
• Témoin de succès : une vérification liée à ce résultat produit (un fichier, un horodatage), pas au code de sortie du processus lui même.
• Abandon explicite : une ligne de journal indiquant qu'une limite de tentatives a été atteinte, par opposition à un abandon silencieux qui ne laisse rien derrière lui.

À retenir en pratique : avant de faire confiance au rapport de toute automatisation, vérifiez à quoi son signal de succès est réellement rattaché. S'il est rattaché à la tentative, elle peut tourner pendant des semaines sans rien faire d'utile tout en vous disant que tout va bien.

Un message de commit est une histoire, pas un état

Un message décrivant ce qui a été fait n'est pas une mesure de ce qui s'est réellement passé, et il ne le devient jamais simplement parce que le temps passe. Cela s'applique à bien plus que les messages de commit : un champ de statut CI et le rapport qu'un agent fait lui même sur son propre travail partagent exactement le même mode d'échec.

Un commit intitulé comme clôturant un problème de sécurité a été cru sur parole. Le code réel laissait encore fuiter les deux secrets sur cinq chemins d'appel distincts, parce que le commit n'avait touché que neuf lignes de commentaire. Le titre racontait une histoire sur l'intention. Le code en racontait une autre sur ce qui s'était réellement passé, et seul le code était vrai. Le même jour, plusieurs recommandations tirées directement du rapport d'inventaire d'un sous agent sur lui même étaient déjà périmées ou fausses, pour la raison identique : un rapport est un récit écrit par la chose évaluée, pas une mesure indépendante de celle ci.

L'intégration continue a sa propre version du même piège. Une boucle de sondage qui lit le champ de statut intermédiaire d'une tâche, plutôt que d'attendre son champ de conclusion final, peut lire une valeur vide ou transitoire et annoncer un succès avant que la tâche ne soit réellement terminée. Le correctif est mécanique : attendre un champ final non vide, ciblé sur le commit exact attendu, puis aller vérifier l'effet réel sur le système cible, pas l'annonce de victoire de l'outil lui même.

Avant de déclarer un défaut corrigé, ouvrez le fichier qui le porte et citez la ligne exacte. Quand le sujet a une contrepartie observable ailleurs, une variable d'environnement réellement chargée par une build, une réponse d'API, un fichier généré, vérifiez cette contrepartie directement au lieu de faire confiance au récit qui la décrit.

• Histoire : un message, un titre, ou un rapport décrivant un résultat visé ou revendiqué.
• État : la condition réelle et observable du code, de la tâche, ou du système à l'instant présent.
• Champ final : une valeur de statut qui ne changera plus, par opposition à une valeur intermédiaire qui pourrait changer.
• Contrepartie observable : un fait directement vérifiable (un fichier, une variable, une réponse) qui se substitue à une affirmation.

À retenir en pratique : lisez le commit, le champ, ou le rapport comme une affirmation à vérifier, jamais comme un fait déjà établi. Puis allez ouvrir le fichier réel, attendez le statut final réel, et vérifiez la contrepartie observable réelle.

Rouvrez chaque URL qu'un agent vous remet

Un agent de recherche rapporte ce qu'un index lui montre actuellement, pas ce que la page en direct contient réellement aujourd'hui. Il présentera un lien mort et un lien véritablement vivant avec exactement le même ton d'assurance, parce que de son point de vue les deux ne sont qu'une correspondance qu'il a trouvée.

L'ampleur du problème mérite d'être connue en chiffres. Lors d'un balayage de recherche d'identité, onze agents ont renvoyé 103 constats. Rouvrir les 94 qui portaient une URL a montré 33 liens morts ou redirigés, et 9 pointant vers un homonyme plutôt que le sujet réel. Près de la moitié du lot était inutilisable, bien que chaque élément ait été présenté comme un fait avec le même ton d'assurance que ceux qui tenaient debout.

Le correctif est une passe de vérification séparée. Toute URL destinée à soutenir une conclusion, ou à être citée, est rouverte par un agent différent de celui qui l'a trouvée à l'origine, et ce second agent reçoit l'instruction explicite d'essayer de réfuter le constat : l'URL répond t elle réellement, le contenu correspond t il à ce qui était affirmé, s'agit il véritablement du bon sujet plutôt que d'un homonyme. Sur la recherche d'identité ou d'attribution en particulier, énoncez à voix haute le critère de désambiguïsation (un employeur spécifique, une date spécifique, un lieu spécifique) et retombez par défaut sur indéterminé plutôt que confirmé chaque fois qu'une page ne satisfait pas ce critère.

Rapportez les deux chiffres quand vous terminez un balayage de ce genre : le compte brut des constats et le compte de ceux qui ont réellement survécu à la réouverture. Un écart nul entre les deux, sur un lot de taille réelle, n'est pas la preuve d'un balayage parfait. C'est la preuve que celui qui a vérifié n'a pas vraiment essayé.

• Constat brut : ce qu'un agent de recherche rapporte comme correspondance, non vérifié.
• Constat survivant : une URL qui a été rouverte et confirmée comme soutenant réellement l'affirmation.
• Critère de désambiguïsation : le fait spécifique (employeur, date, lieu) qui sépare le sujet réel d'un homonyme.
• Indéterminé : la valeur par défaut honnête quand une page ne satisfait pas ce critère, par opposition à la marquer faussement comme confirmée.

À retenir en pratique : ne citez et n'agissez jamais sur une URL qu'un agent vous a remise sans la rouvrir vous même, ou sans la faire réfuter par un agent différent. Rapportez le compte brut et le compte survivant côte à côte, à chaque fois.

Un contrôle de forme ne voit pas une valeur fausse

Un contrôle automatisé qui scanne un livrable avant sa publication teste presque toujours la forme : le fichier est-il valide, l'encodage semble-t-il correct, un mot-clé requis est-il présent. Il teste très rarement la vérité : le chiffre est-il exact, l'affirmation est-elle réellement juste. Cet écart reste invisible jusqu'au jour où une valeur fausse se glisse à travers un contrôle qui affiche tout au vert.

Voici un cas réel de cette faille. Une règle interdit de publier un chiffre contesté. La constante source qui contient ce chiffre respecte la règle à la perfection : elle n'est jamais imprimée directement. Mais quatre lignes plus loin, une seconde constante en est dérivée (une copie arrondie, une copie reformatée, peu importe) et cette valeur dérivée s'affiche sur une page d'accueil, un pied de page et une bannière principale, répétée sur 66 pages. Trois contrôles automatisés distincts sont restés au vert, car aucun ne comparait la valeur affichée à la valeur interdite. Ils vérifiaient la syntaxe, l'encodage et la structure. Aucun ne vérifiait le sens.

Un proche cousin de ce bug est le contrôle par mot-clé : une règle qui dit que le document doit mentionner X. Ce contrôle se satisfait trivialement en écrivant quelque chose de faux à propos de X, puisqu'il ne cherche que le mot-clé, jamais si ce qui l'entoure est correct. Tout ce qui est ajouté pour satisfaire un contrôle de forme doit être vérifié à la source de vérité, pas seulement vérifié comme présent sur la page.

Le correctif n'est pas un contrôle de forme plus intelligent, c'est un contrôle entièrement différent : interdire aussi les dérivés, pas seulement la constante d'origine, et faire tourner le contrôle sur l'artefact FINAL construit (le HTML réellement livré, pas le fichier source), en lisant sa liste de valeurs interdites depuis le même fichier de données qui a signalé le chiffre comme contesté au départ. Ne jamais décrire un contrôle de forme comme un contrôle de justesse à quelqu'un qui doit faire confiance au résultat : un livrable peut passer tous les scans disponibles et rester commercialement ou juridiquement faux.

Le remplacement en masse agit sur des chaînes, pas sur du sens

Un remplacement en masse (une recherche scriptée qui remplace chaque occurrence d'une chaîne par une autre dans de nombreux fichiers) traite chaque correspondance comme identique. Il n'a aucune idée qu'une même séquence de caractères peut signifier deux choses complètement différentes selon l'endroit où elle se trouve. Plus un motif est courant, plus il est probable qu'il signifie deux choses différentes quelque part dans votre projet, et un outil de traitement par lots réécrira les deux sans hésiter.

Un cas réel : un remplacement en masse a mis à jour un chiffre commercial partout où il apparaissait. Il a aussi réécrit la même chaîne numérique exacte à l'intérieur d'une clause juridique, où ce chiffre désignait un délai de dépôt de réclamation, pas la promesse de délai de réponse que le remplacement était censé corriger. Rien dans la chaîne elle-même ne semblait différent. Seule la phrase qui l'entourait révélait qu'elle signifiait autre chose.

L'échec inverse est tout aussi fréquent et bien plus silencieux : une substitution scriptée peut ne rien trouver à remplacer et signaler quand même un succès. Si l'attribut ou la balise cible qu'elle cherchait est absent d'un fichier particulier, la plupart des outils traitent l'absence de motif comme un résultat normal, sans erreur. Dans un cas, cela a rendu un élément visuel invisible sur la page pendant que le code de sortie (le nombre qu'un programme renvoie pour indiquer s'il a réussi, zéro signifiant généralement un succès) paraissait parfaitement propre.

Deux habitudes comblent ces deux failles. Avant de lancer un remplacement en masse, copiez les fichiers concernés dans un endroit sûr et lisez le diff (la liste des changements exacts) fichier par fichier, en portant une attention particulière aux fichiers auxquels personne ne pensait au moment d'écrire la règle, et excluez tout simplement les textes juridiques ou contractuels des passages automatisés. Après l'avoir lancé, vérifiez que le changement a réellement eu lieu en comptant combien de fois le NOUVEAU motif apparaît désormais, jamais en faisant confiance au seul code de sortie, et préférez les outils qui échouent bruyamment quand l'élément sur lequel ils devaient s'ancrer est absent.

Livrez le générateur et sa vérification de destination ensemble

Générer une référence et supprimer un objet sont des images miroir du même problème. Un générateur peut produire une référence qui pointe vers rien. Une suppression peut laisser des références pointant vers quelque chose qui n'existe plus. Les deux semblent complets de l'extérieur. Les deux ont besoin d'une vérification dédiée, et cette vérification vaut autant que la chose qu'elle surveille.

Prenez une redirection (une règle qui envoie un visiteur d'une ancienne adresse web vers une nouvelle). Un générateur a produit 237 règles de redirection sans que rien ne vérifie que les destinations existaient vraiment. Le fichier de sortie semblait complet : 237 règles, correctement formatées, prêtes à déployer. Mais une redirection pointant vers une page morte est pire pour le classement de recherche que pas de redirection du tout, puisqu'elle envoie activement visiteurs et moteurs de recherche dans un mur. Un vérificateur de destination séparé, qui visite chaque cible, signale les chaînes de redirection et signale les sources dupliquées, n'a trouvé aucun problème lors d'un passage ultérieur. Ce zéro ne signifiait quelque chose que parce que la vérification existait. Sans elle, "le générateur a tourné et a produit 237 lignes" aurait eu l'air exactement pareil, que les destinations soient réelles ou non.

Cela se généralise bien au-delà des redirections : les sitemaps, les flux RSS, les balises hreflang (des marqueurs qui indiquent aux moteurs de recherche quelle version linguistique d'une page afficher), les données structurées, et les catalogues d'images partagent tous la même forme. Chaque fois que vous livrez quelque chose dont tout le travail consiste à pointer vers autre chose, livrez son témoin de destination en même temps, dans le même commit, pas comme une pensée après coup.

Le cas miroir est la suppression. Après que 56 vidéos ont été supprimées d'une chaîne, ses playlists contenaient encore 48 entrées mortes, car la plateforme ne retire pas automatiquement un élément supprimé de chaque liste qui le référençait. Ces entrées mortes ont aussi discrètement faussé un tri sans rapport par nombre de vues. Après toute suppression en masse, demandez explicitement ce qui RÉFÉRENÇAIT les objets supprimés (index, sitemaps, liens internes, tables de jointure dans une base de données, caches) comme une question séparée de savoir si les objets eux-mêmes ont disparu. Supprimer l'objet est la moitié facile du travail.

Un garde-fou qui s'exempte lui-même n'est pas un garde-fou

Une règle qui ne fonctionne que si quelqu'un s'en souvient, l'invoque, ou qui se désactive elle-même quand un certain mot apparaît, n'est pas vraiment une règle. C'est un espoir. Cette leçon couvre trois degrés du même problème, d'une règle simplement documentée, à un garde-fou qui se désarme activement lui-même, à un garde-fou qui fonctionne techniquement mais qui est trop discret pour compter.

Le premier degré est le plus courant : une règle qui ne vit que dans la documentation ou la mémoire. Une règle de design garantissant une taille minimale de zone tactile (à quel point un bouton ou un lien doit être grand pour qu'un doigt puisse le toucher de manière fiable) était documentée correctement et comprise par tout le monde, mais appliquée manuellement sur seulement 2 des 155 emplacements possibles dans le produit en production. Une vérification de sécurité distincte a été désactivée temporairement "par discipline, on se souviendra de la réactiver", et est restée désactivée jusqu'à ce qu'une revue complètement sans rapport l'attrape. La robustesse suit un ordre clair : faites de la règle le défaut (un style global, la valeur par défaut d'une fonction, pour que la suivre ne coûte aucun effort), ou mécanisez-la en un garde-fou bloquant qui est vraiment testé en tentant l'action interdite et en confirmant qu'elle est bloquée, ou, au minimum, mesurez où la règle n'est pas appliquée pour que l'écart soit visible.

Le second degré est pire, car il ressemble à un vrai garde-fou : une vérification mécanisée qui s'exempte elle-même sous une condition. Un portail de livraison scannait les messages à la recherche de deux motifs interdits, mais se désactivait lui-même dès que le message contenait certains mots-clés, censés permettre aux gens de discuter de la règle sans la déclencher. Un message qui annonçait littéralement "je respecte la règle" tout en contenant les deux motifs interdits est passé silencieusement, précisément parce qu'il contenait les mots-clés d'exemption. Ce n'est pas une coïncidence : un message qui parle d'une règle est exactement le genre de message le plus susceptible de contenir aussi le motif que la règle interdit. Exempter par vocabulaire joue contre le garde-fou par construction. Exemptez par structure à la place (un bloc de code, un délimiteur explicite difficile à produire par accident), et avant de livrer un garde-fou, essayez activement d'écrire la phrase unique qui le désarmerait.

Le troisième degré est plus subtil encore. Un garde-fou peut être techniquement présent, entièrement mécanisé, et quand même perdre. Une instruction permanente, chargée dans chaque session, n'a produit aucune sortie visible pendant des mois, et a discrètement perdu face à une instruction concurrente qui s'annonçait bruyamment à chaque démarrage. Être chargé n'est pas la même chose qu'être remarqué. Une règle permanente doit se manifester au moment où elle compte, pas simplement se trouver correctement quelque part dans un fichier.

Validez ce que l'utilisateur ouvre, pas une étape intermédiaire

Une validation ne prouve que l'état de ce que vous avez vraiment validé, rien de plus. Chaque étape entre cette vérification et le moment où une vraie personne ouvre la vraie chose peut discrètement casser quelque chose qui était correct un instant plus tôt. L'habitude qui mérite d'être construite est simple à énoncer et facile à sauter sous pression du temps : identifiez exactement ce que l'utilisateur va ouvrir, puis validez exactement cette chose, avec l'outil qui l'ouvre vraiment.

Un échec concret : un recadrage de photo a été corrigé, puis validé en prenant une capture d'écran de la source HTML qui générait la page, et annoncé comme livré. Mais le fichier que l'utilisateur ouvrait vraiment était un PDF, généré à partir de ce HTML par une étape séparée, et cette étape introduisait son propre défaut. Le problème original était corrigé dans la source et toujours visible dans le PDF, car le PDF n'a jamais été la chose vérifiée.

Le même piège apparaît autour des API et des caches. Après avoir écrit un changement via une API, relire la même API n'est pas la preuve que le changement a pris effet : le chemin de lecture peut être servi depuis un cache périmé (une copie stockée d'une réponse, gardée pour que le système n'ait pas à refaire le travail à chaque fois), qui peut renvoyer l'ancienne valeur même si l'écriture a réussi. La seule vraie preuve consiste à vérifier le résultat observable de l'extérieur, la chose qu'un visiteur extérieur voit vraiment.

Les caches causent une seconde version, plus discrète, du même problème après une reconstruction. Si la validation ne casse pas délibérément le cache d'abord (ajouter un paramètre de requête frais à l'URL, forcer un rafraîchissement complet, ou vérifier contre un serveur configuré pour ignorer son cache), elle peut valider la version précédente sans que personne ne le remarque. Et si une ressource est reconstruite mais servie sous le même nom de fichier exact, le navigateur de chaque visiteur peut garder la version périmée pendant toute la durée de vie de son propre cache, même si le fichier sous-jacent sur le serveur est déjà corrigé. Une version vraiment nouvelle a besoin d'un nom de fichier vraiment nouveau, pas seulement d'un nouveau contenu derrière l'ancien nom.

Prouvé, ou simplement pas encore réfuté

Chaque vérification automatisée répond à une question étroite. Une vérification de types prouve que le code compile. Une suite de tests prouve que les chemins de code qu'elle exerce se comportent comme écrit. Un aperçu sans interface (une capture d'écran ou une exécution simulée d'une application sans qu'aucun humain touche un vrai écran) prouve que les composants se montent sans planter. Rien de tout cela ne prouve que le produit fonctionne vraiment pour une vraie personne tenant un vrai appareil.

C'est l'écart entre deux états très différents, et les cours qui enseignent les tests les mélangent généralement sous un seul mot : testé. La division honnête est : prouvé signifie que vous avez exécuté une commande précise et pouvez citer sa sortie. Pas encore réfuté signifie que rien n'a attrapé de problème jusqu'à présent, ce qui est une affirmation bien plus faible : un aperçu vert ou une absence d'erreurs console signifie seulement que les vérifications que vous avez faites n'ont pas révélé de défaut par hasard, pas qu'aucun n'existe.

Un vrai lot de livraisons rend cela concret. Sept lots ont été livrés avec tous les signaux automatisés au vert : vérifications de types réussies, couverture complète sur chaque version de langage, un aperçu sans interface revu et propre. La personne qui a vraiment installé l'application sur un vrai appareil a trouvé des problèmes en quelques minutes, dont aucun n'avait été attrapé par une vérification : une lenteur générale qui n'apparaît que sous un vrai écran tactile et une vraie pression mémoire, un paramètre configuré pour le mauvais matériel physique, et un bouton de contact qui composait un numéro de ligne fixe qu'aucune application de messagerie ne pourrait jamais atteindre. Chacun de ces défauts était invisible par construction pour une exécution sans interface, car une exécution sans interface n'a ni doigt, ni écran, ni ligne téléphonique.

Le correctif n'est pas d'ajouter plus de vérifications automatisées, puisque cette classe de défaut résiste à l'automatisation par nature. Le correctif est l'honnêteté dans la manière de rapporter le statut. Avant de déclarer quoi que ce soit terminé, écrivez explicitement ce qui a été prouvé, avec la commande et la ligne de sortie citée, et ce qui reste simplement pas encore réfuté, comme un aperçu propre ou l'absence d'erreurs console. Puis nommez d'avance ce qui ne peut être tranché que sur le vrai appareil ou par le vrai utilisateur, pour que personne ne confonde le silence avec un verdict.

Comptez toute la population, et nommez la mesure d'après ce qu'elle capture

Deux petites habitudes protègent contre une quantité surprenante de mauvaise analyse : tout compter avant de recommander un changement, et écrire exactement ce que votre mesure capture avant de la nommer. Sautez l'une ou l'autre et une conclusion pleine d'assurance et bien intentionnée peut être complètement fausse tout en paraissant rigoureuse.

Le premier piège est le biais d'échantillonnage : remarquer quelques cas et généraliser à partir d'eux sans vérifier le reste. Dans un cas réel, quelqu'un a repéré quatre fichiers qui enfreignaient une convention de nommage et a rédigé une recommandation radicale d'abandonner cette convention entièrement, puisqu'elle n'était clairement pas respectée. Mesurer la population complète d'abord a raconté une histoire différente : 32 des 43 éléments pertinents suivaient déjà une convention cohérente et délibérée. Le véritable défaut était plus étroit et sans rapport avec la convention elle même. Une convention déjà suivie par une large majorité est une décision que quelqu'un a prise exprès, pas un accident attendant d'être corrigé. Et le simple fait que quelqu'un accepte d'avancer avec un plan valide l'autorisation d'agir, cela ne valide jamais que le diagnostic sous jacent était correct.

Le second piège est une mesure mal étiquetée : un chiffre techniquement correct mais nommé d'après la mauvaise chose. Un graphique intitulé "journée de travail" mesurait en réalité l'écart entre le premier et le dernier message envoyé à un outil assistant dans une journée, excluant silencieusement chaque heure passée loin du clavier. Dans un autre cas, une note a lu l'usage de majuscules par quelqu'un comme un signe de frustration croissante, alors que le véritable moteur était simplement une frappe plus rapide sous la pression du temps. Un chiffre faux finit par être remarqué et corrigé. Une étiquette fausse est pire : elle contamine discrètement toutes les conclusions construites dessus, et un lecteur extérieur n'a aucun moyen de la repérer en regardant simplement le graphique.

Les deux habitudes se ramènent à une seule discipline. Avant de recommander un changement à une convention, comptez toute la population, pas les cas que vous avez remarqués par hasard. Avant de titrer un graphique, une tuile de tableau de bord, ou une colonne, écrivez en une phrase simple ce que l'instrument sous jacent capture littéralement, puis vérifiez que le titre dit exactement cela, et rien de plus.

Les agents suppriment silencieusement vos caractères accentués

Les agents suppriment couramment les caractères accentués propres à une langue, les marques comme un accent aigu ou une cédille dont de nombreuses langues (le français, l'espagnol, l'allemand entre autres) ont besoin pour orthographier correctement les mots, même quand on leur demande explicitement de les conserver. Le résultat reste un texte parfaitement valide et lisible : rien ne plante, rien ne paraît cassé, et les marques manquantes sont invisibles à une lecture rapide. Cela rend l'échec véritablement dangereux : il passe tous les contrôles qui ne cherchent qu'un problème évidemment visible.

La manière la plus courante d'essayer d'attraper cela est une vérification simple : le document contient il des caractères accentués, tout court. Cette vérification a une date de péremption cachée. Elle reste au vert pour toujours dès l'instant où un document change de langue, parce qu'elle continue de chercher l'ensemble de marques spécifique d'une langue dans un texte qui est passé à une autre langue, ou à du code brut. Une vérification utile doit correspondre à la langue actuelle réelle du document, se mettre à jour à l'instant où cette langue change, et exiger un véritable seuil numérique (une densité minimale de marques par paragraphe) plutôt que de se satisfaire d'"au moins une occurrence" quelque part dans tout le fichier.

Un second piège se trouve juste à côté du premier : une passe de correction linguistique ne doit jamais toucher au code. Les identifiants, les valeurs d'attribut, et les noms de balise sont fréquemment des mots ordinaires dans la langue cible, et par leur seule forme ils sont indiscernables de la prose. Un script qui ajoute aveuglément des accents partout où un mot semble en manquer un peut réécrire silencieusement un nom de variable ou une valeur d'attribut, cassant le programme tout en ayant l'air d'une correction orthographique inoffensive. Les corrections n'ont leur place que dans les fichiers de contenu : le texte qu'un lecteur voit réellement, jamais le code qui l'affiche.

Le détecteur le plus fiable n'essaie de rien auto corriger. Il signale plutôt deux types d'anomalie et remet l'emplacement à un humain ou à un sous agent au périmètre étroit : une anomalie de densité (une ligne pleine de mots grammaticaux ordinaires d'une langue avec zéro caractère accentué de cette langue, ce qui est statistiquement presque impossible dans un texte réel) et une incohérence interne (le même mot orthographié de deux façons différentes à l'intérieur d'un même document). Pour vérifier qu'une passe de correction a réellement fonctionné et n'a rien fait d'autre, lancez un diff octet par octet qui retire les caractères accentués à la fois de la version originale et de la version corrigée et exige qu'elles correspondent exactement. Toute reformulation, tout mot ajouté ou retiré, apparaît immédiatement, à son emplacement exact dans le fichier.