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 des semaines pendant que le travail qu'il est censé accomplir échoue silencieusement pour une raison extérieure à sa propre gestion d'erreurs.

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

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

L'ordre des opérations compte plus qu'il n'y paraît. 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.

Une dernière habitude ferme la boucle. 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 au lieu de les résumer derrière une phrase du type tout va bien : cette phrase peut rester vraie sur une condition et fausse sur les deux autres sans que personne ne s'en aperçoive.

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 plutôt qu'une simple présence.