Accueil / Vérifier ce qu'il rend

Un vert ne prouve rien tant qu'il n'a pas été prouvé lui-même

Un contrôle qui n'a jamais été mis en défaut par un cas qu'il doit réellement trouver n'a rien prouvé, au sens strict où prouver exige qu'une commande précise ait tourné et que sa sortie ait été lue : un détecteur cassé rend zéro problème, et cela se lit exactement comme un succès.

Un script de vérification qui rapporte zéro problème peut vouloir dire deux choses opposées : le système contrôlé est réellement propre, ou le contrôle lui-même ne fonctionne plus. Rien dans un résultat vert ne permet de trancher entre les deux tant que ce contrôle n'a pas été mis en échec au moins une fois par un cas qu'il doit obligatoirement trouver.

Le piège du zéro

Deux cas mesurés rendent ce piège concret. Un motif d'échappement cassé a un jour rendu zéro violation signalée là où des milliers auraient dû apparaître. Un autre motif cassé, à l'inverse, a signalé des violations qui n'existaient pas, et un ordre des opérations inversé a produit des fausses alertes en continu dans un cas réel : la figure qui accompagne cette leçon chiffre ces deux échecs avec précision. Les deux venaient de la même cause profonde, une vérification qui n'avait jamais été testée sur elle-même. Le code de sortie d'une tâche planifiée pose le même piège : un script peut annoncer un succès pendant que son travail échoue.

Le témoin positif, prouvé par l'exécution

Le correctif tient en une règle. Un contrôle doit chercher, dans la même passe, au moins une chose qu'il doit trouver, un cas connu comme mauvais : c'est le témoin positif. La démonstration se fait en quelques lignes. Un script qui cherche le mot interdit secret dans un fichier, avec une expression régulière qui a oublié l'indifférence à la casse, tourne sur un fichier qui contient deux fois ce mot écrit avec une majuscule initiale.

node verif.js fixture.txt
violations trouvees : 0

Zéro. Le fichier contrôlé contient pourtant deux occurrences du mot interdit. Rien dans ce résultat ne distingue un fichier réellement propre d'un contrôle cassé, tant que personne n'a vérifié que ce contrôle sait détecter un cas connu. Ajouter l'indifférence à la casse, exactement le témoin que ce contrôle doit désormais trouver, change le verdict.

node verif2.js fixture.txt
violations trouvees : 2

Un zéro peut venir d'une recherche qui n'a rien cherché

Le journal de Claude Code d'octobre 2026 corrige deux cas où Grep et Glob annonçaient « aucun résultat » alors que le programme de recherche avait planté, ou que la cible n'était pas lisible : ils rendent maintenant une erreur, ou retentent une fois puis le signalent. L'inverse existait aussi, l'outil PowerShell prenant pour une erreur la sortie vide d'une recherche passée à Select-Object. Un lanceur de tests peut de même afficher « tests 0, échecs 0 » : citez la ligne du compteur, avec un nombre non nul, avant de lire le vert.

Un détecteur peut viser à côté. Le nom d'une classe CSS reste dans la feuille de style en ligne même quand l'élément n'est pas rendu, donc le chercher ne prouve rien. La démonstration fabrique sa page :

printf '<style>.promo{color:red}</style>\n<p>texte</p>\n' > page.html
grep -c promo page.html
grep -c 'class="promo"' page.html

1
0

Le premier compte rend 1 pour un élément absent de la page, le second 0, parce qu'il vise l'attribut posé sur l'élément. Lancez le cas d'absence avant de croire le cas de présence.

Produire le témoin avant de déclarer le contrôle actif

Câblez d'abord l'écriture du témoin en cas de succès, faites tourner la tâche une fois pour de vrai afin que ce témoin existe réellement, et seulement ensuite déclarez la vérification active. Inverser cet ordre, déclarer une vérification de témoin avant que rien n'écrive ce témoin, entraîne les gens à ignorer tout le système de surveillance : un système ignoré vaut moins que pas de système du tout.

Dernière habitude : renommez le témoin, ne le supprimez jamais, et confirmez que le contrôle réagit à chaque fois, puis restaurez-le. Énumérez aussi les conditions qu'un contrôle de complétude couvre, plutôt que de les résumer en « tout va bien », vrai sur une condition et faux sur les deux autres.

Ce principe se prolonge dans testez le vérificateur avant de croire son verdict, qui applique la même exigence à un script qui mesure un chiffre.