Accueil / Vérifier ce qu'il rend

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

Un contrôle automatique mesure la forme, l'encodage, la présence d'un mot clé, jamais la vérité, et valider une capture d'écran ou une étape intermédiaire ne prouve jamais ce que la personne va réellement ouvrir.

Un contrôle automatisé qui scanne un livrable avant sa publication vérifie presque toujours une seule chose : la forme. Le fichier est-il valide, l'encodage semble-t-il correct, un mot clé attendu apparaît-il quelque part sur la page. Il vérifie très rarement la vérité : le chiffre affiché correspond-il à la bonne valeur, l'affirmation est-elle réellement exacte. Cet écart reste invisible jusqu'au jour où une valeur fausse traverse un contrôle qui affiche tout au vert.

Ce qu'un contrôle de forme ne voit jamais

Une règle interdit de publier un chiffre contesté. La constante source qui le contient respecte la règle à la perfection : elle n'est jamais imprimée directement nulle part. Une seconde constante, dérivée de la première dans le même fichier, s'affiche pourtant sur un grand nombre de pages du site. Plusieurs contrôles automatisés distincts restent au vert, parce qu'aucun d'eux ne compare la valeur réellement affichée à la valeur interdite : ils vérifient la syntaxe, l'encodage, la structure, jamais le sens. La figure qui suit ce paragraphe chiffre précisément cette fuite : le nombre de pages touchées, le nombre de contrôles restés au vert malgré elle, et l'écart, en lignes de code, entre la constante interdite et sa dérivée.

Le même défaut prend une forme plus simple avec un contrôle par mot clé : une règle qui exige que le document mentionne un terme donné se satisfait trivialement en écrivant n'importe quoi de faux à côté de ce terme, puisqu'elle ne cherche que le mot, pas son contexte. Tout ce qu'un livrable ajoute pour satisfaire un contrôle de forme mérite d'être vérifié à la source de vérité, pas seulement constaté présent sur la page. Ce mécanisme prolonge 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 le cas précis qu'il devrait attraper ne prouve rien sur ce cas.

Valider ce que la personne ouvre vraiment

Un correctif visuel a été relu et confirmé correct sur une capture d'écran de la page HTML qui génère le document, puis annoncé comme livré. Le fichier réellement ouvert par la personne concernée était un PDF, produit à partir de ce HTML par une étape de conversion séparée. Cette étape portait son propre défaut : elle régénérait le PDF à partir d'une copie du HTML qui n'avait pas encore reçu le correctif, si bien que le problème, pourtant bien corrigé dans la page affichée en direct, restait visible dans le PDF distribué, parce que le PDF n'avait jamais été la chose vérifiée.

Le même piège guette autour des caches. Relire une donnée par la même voie qui vient de recevoir une écriture ne prouve rien de plus que la cohérence de cette voie avec elle même : une copie mise en cache peut renvoyer l'ancienne valeur alors que l'écriture a parfaitement réussi. Casser ce cache demande un geste actif : ajouter un paramètre inédit à l'adresse, ouvrir une fenêtre de navigation privée, ou interroger directement un serveur configuré pour ignorer son propre cache. Un simple rafraîchissement du navigateur laisse souvent un relais intermédiaire intact.

Le contrôle qui aurait vu la fuite

Voici le même mécanisme, rejouable avec un fichier fabriqué pour l'exemple : la constante interdite est bien écrite dans le code source, jamais imprimée directement, et un contrôle qui cherche cet affichage direct ne trouve rien, à raison :

$ printf 'const CHIFFRE_INTERDIT = 999;\nconst AFFICHAGE = CHIFFRE_INTERDIT.toString() + ",00 EUR";\nconsole.log(AFFICHAGE);\n' > /tmp/source-v2m3l7.js
$ grep -c "console.log(CHIFFRE_INTERDIT" /tmp/source-v2m3l7.js
0

Mais quatre lignes plus loin, la constante dérivée reprend cette valeur et s'imprime, elle, à l'exécution :

$ node /tmp/source-v2m3l7.js
999,00 EUR

Ce contrôle rend un vert honnête et pourtant faux pour l'usage qu'on en fait : il vérifie une ligne précise du fichier source, pas ce que la personne voit réellement à l'écran. La leçon tient en un geste : identifier ce que la personne va ouvrir, un PDF, une page en direct, un écran d'application, puis vérifier exactement cette chose, avec l'outil qui l'ouvre vraiment, après avoir cassé le cache. Un contrôle de forme n'est jamais un contrôle de justesse, et il ne doit jamais rester le dernier verrou avant publication.