Pourquoi vos tests passent au vert alors que la prod est cassée

Le 19 juillet 2026, un essai publié sur phronesis.world documente une journée d'audit édifiante. Entre le 18 et le 19 juillet, une page offrait gratuitement un livre payant, un formulaire de contact perdait silencieusement chaque message envoyé, un plan du site s'affichait vide pour la majorité des visiteurs, et une métrique censée mesurer la « cohérence » d'un texte ne mesurait en réalité que sa longueur. Le point commun entre ces quatre bugs : chacun avait déjà passé un test censé l'intercepter.

L'auteur, Rincón, D., accompagné de l'IA Claude qui tenait le rôle d'ingénieur du site audité, en tire un catalogue de dix façons dont un contrôle peut rester vert alors que tout est cassé. La thèse tient en une phrase : relancer un test rejoue l'instrument, le tester autrement met l'instrument à l'épreuve.

Pourquoi ce sujet vous concerne, même sans lire l'essai en entier

Si vous travaillez avec une CI/CD, un pipeline de tests, ou même un simple script de vérification avant déploiement, vous avez probablement déjà vécu une version de ces pièges sans le reconnaître : un badge vert sur GitHub Actions, un déploiement en production, puis un client qui signale un bug que « les tests auraient dû attraper ». L'intérêt de ce catalogue, c'est qu'il donne des noms précis à des mécanismes qu'on croise sans les identifier.

Quatre pièges documentés, avec les exemples réels de l'audit

Le contrôle qui ne peut pas échouer

Un script de vérification affichait douze lignes marquées BAD, puis concluait PASS. La variable qui portait l'échec était fixée à l'intérieur d'un sous-shell : elle mourait avec lui, et le résumé final lisait une variable que rien n'avait jamais pu écrire. Le contrôle ne mentait pas, il était structurellement incapable de dire la vérité.

Le symptôme à surveiller chez vous : un test qui n'a jamais échoué depuis sa création. Cassez la fonctionnalité exprès, une fois, et regardez si le test devient rouge. S'il ne peut pas échouer, ce n'est pas un test, c'est une décoration.

Le mauvais dialecte

Une recherche de href="/courses" ne trouvait rien, parce que le framework générait href="/courses/" avec un slash final. Un audit qui attendait min="0" croisait du JSX qui écrit min={0}. Dans les deux cas, le contrôle était bien formé, mais pour un langage différent de celui réellement déployé. Le désaccord se traduit en silence, et le silence se lit comme une bonne santé.

Avant de faire confiance aux résultats négatifs d'un vérificateur, donnez-lui un cas positif connu. S'il ne trouve pas ce que vous savez être présent, son « rien trouvé » ne veut rien dire.

Le silence lu comme un succès

Un formulaire de contact postait vers un worker qui n'existait plus depuis des semaines. Chaque envoi échouait, chaque échec était avalé par un bloc catch, et le formulaire avait l'air de fonctionner. Un système de scores de jeu envoyait ses requêtes vers des points d'API jamais déployés, chacune se terminant par un catch(() => {}) muet.

L'absence d'erreur n'est pas la preuve d'un succès. Il faut exiger le signal positif (le code 201, l'enregistrement effectivement créé, la réponse reçue) avant de croire qu'un chemin fonctionne de bout en bout.

La mesure qui mesure autre chose

Un score de « cohérence » censé évaluer la qualité d'un texte s'est révélé mesurer surtout sa longueur : le même document, tronqué à huit phrases, obtenait 0,39 ; en entier, 0,11. Même texte, même sens, un écart du simple au quadruple. Ce qui a révélé le problème n'était pas un test de justesse, mais un test d'invariance : appliquer une transformation à laquelle la mesure devrait être indifférente, et regarder si le résultat bouge. Une mesure peut être parfaitement fiable et mesurer la mauvaise chose.

L'essai documente au total dix mécanismes de ce type, parmi lesquels un protocole expérimental qui efface l'effet qu'il cherche à observer, ou un texte qui continue d'affirmer un chiffre après que la donnée sous-jacente a changé. Le catalogue complet est disponible sur la source citée en fin d'article.

Ce que ça change concrètement dans votre pipeline

Pour une PME ou une équipe dev française qui gère sa propre CI, trois réflexes ressortent de cet audit :

• Testez vos tests. Un test qui n'a jamais échoué n'a jamais rien prouvé. Cassez volontairement le comportement visé, une fois, pour vérifier que le test le détecte.
• Vérifiez à la couche où la conséquence se produit. Un audit du code source ne dit rien de la page réellement rendue chez l'utilisateur. Tester le HTML source d'un site qui hydrate du JavaScript côté client, c'est tester un artefact, pas l'expérience réelle du visiteur.
• Exigez un signal positif, pas seulement l'absence d'erreur. Formulaire, webhook, API de paiement : le test doit vérifier que la donnée est bien arrivée quelque part, pas seulement qu'aucune exception n'est remontée.

Notre lecture chez CZSyn

Ce que cet audit met en évidence rejoint une réalité qu'on observe régulièrement en intervention chez nos clients : une CI verte donne un faux sentiment de sécurité, et ce sentiment est d'autant plus dangereux qu'il est confortable. Un badge vert sur un dépôt ne dit rien sur la robustesse réelle d'un site, seulement sur la robustesse du test qu'on a écrit pour le vérifier. Ce sont deux choses différentes, et la confusion entre les deux coûte cher : un formulaire de contact qui perd des prospects pendant des semaines sans que personne ne s'en aperçoive, c'est un manque à gagner direct, pas un simple détail technique.

Le point le plus utile de cet essai, à notre avis, tient dans sa dernière idée : « checking again is not checking » (relancer un contrôle n'est pas contrôler). Faire tourner la même suite de tests dix fois ne prouve rien de plus que la faire tourner une fois. Ce qui prouve quelque chose, c'est de changer d'angle : casser la fonctionnalité pour voir le test réagir, regarder la page rendue plutôt que le code source, exiger la preuve positive plutôt que l'absence de plainte. C'est un principe simple, peu coûteux à appliquer, et qu'on recommande d'intégrer dans toute revue de pipeline CI, quelle que soit la taille de l'équipe.

Sources primaires

• Rincón, D., avec Claude, « Ways of Checking », Phronesis, 2026.
• Phronesis, phronesis.world, le site dont l'audit fait l'objet de l'essai.