Pourquoi vérifier que mes tests savent échouer ?
En usage
Un contrôle qui ne dit rien, je le prenais pour une bonne nouvelle. En septembre 2026, j’ai compris qu’il pouvait aussi vouloir dire qu’on ne voyait plus rien.
En relisant avec un agent les épreuves prévues pour un de mes logiciels, je leur ai posé une seule question : par quel chemin mesures-tu, et ce chemin peut-il tomber sans que le système soit en panne ? Plusieurs ne tenaient pas. Une épreuve du genre « personne ne doit pouvoir faire ceci » réussit aussi quand le service est éteint, tout simplement parce qu’un service éteint ne laisse personne rien faire. Le même jour, j’ai repassé toutes mes surveillances à cette question, et corrigé celles qui en avaient besoin. Depuis, chaque épreuve négative a son témoin positif, c’est-à-dire un essai joué juste avant, par le même chemin, qui prouve que le système répond ; et chaque petite pièce que mes agents me livrent arrive avec sa contre-épreuve, la preuve que sa vérification sait refuser ce qui est faux.
J’en retiens que le silence d’un contrôle ne prouve rien. L’électronique me l’avait déjà appris avec la carte de mon labo : on commence par la plus petite preuve qui puisse échouer. Et je fais lancer les tests avant qu’on me demande de vérifier moi-même.
C’est en usage dans mes chantiers depuis l’automne 2026.
Mon étincelle : « Pour chaque test qui vérifie qu’une chose est impossible, ajoute juste avant un test qui prouve, par le même chemin, que le système répond ; puis montre-moi un cas où ton test échoue. » Un test que je n’ai jamais vu échouer, je ne le compte pas encore.