Le 20 juillet, on a publié ici un article sur le harness, cette couche qui exécute le code produit par une IA, l’observe et en tire des preuves. Il laissait une question ouverte, et c’est la plus gênante des deux : une preuve de quoi, exactement ?
Un test qui passe prouve une chose, une seule. Le code s’est exécuté jusqu’au bout sans déclencher quoi que ce soit que le test sache reconnaître. Ce que le test sait reconnaître porte un nom, l’oracle. C’est le morceau dont personne ne parle, et c’est celui qui décide si un parc de tests vaut quelque chose.
L’oracle, c’est le critère, pas le scénario
En test logiciel, l’oracle est ce qui tranche entre correct et incorrect. Pas le scénario, pas le sélecteur, pas le runner. Le critère.
Ce n’est pas un mot maison. William Howden l’a introduit en 1978. La survey de référence, publiée par Barr, Harman, McMinn, Shahbaz et Yoo dans IEEE Transactions on Software Engineering en 2015, le définit comme une procédure qui distingue les comportements corrects des comportements incorrects du système sous test. Et le syllabus ISTQB Analyste de Test niveau avancé y consacre une section entière, sous le nom de problème de l’oracle de test. Ceux qui ont passé la certification l’ont étudié. Peu l’ont revu depuis que l’IA écrit des tests.
Quand un scénario vérifie qu’une fiche produit affiche 79,90 euros, l’exécution est triviale. L’oracle, c’est de savoir que 79,90 est le bon prix, pour ce produit, pour ce client, ce jour-là, avec la promotion en cours. Quand une API renvoie un 403, l’oracle, c’est de savoir si ce 403 est une régression ou le comportement attendu pour ce profil.
Cette connaissance ne se trouve nulle part dans le code. Elle vient du métier. C’est pour ça qu’elle résiste à l’automatisation, et c’est pour ça qu’un harness sans oracle solide reste une machine à produire du vert.
Un exemple courant : un sélecteur change après une refonte, le test casse, un outil de self-healing retrouve l’élément et remet le scénario au vert. Personne ne se demande pourquoi le sélecteur a changé. Si la refonte a aussi déplacé la validation dans un autre tunnel, le test continue de passer sur un parcours que plus aucun utilisateur n’emprunte.
Deux études récentes, le même angle mort
Des chercheurs de Virginia Tech et de Carnegie Mellon ont évalué huit modèles de langage sur 22 374 variantes de programmes. Sur les programmes d’origine, les résultats sont bons : 79 % de couverture de lignes, des suites de tests qui passent. Puis les chercheurs modifient le comportement des programmes et demandent aux modèles d’écrire de nouveaux tests pour la version modifiée. Un tiers de ces tests échouent sur le code qu’ils sont censés tester. Et plus de 99 % de ceux qui échouent passent sur la version d’origine, tout en exécutant la zone modifiée.
La précision compte : le modèle avait le nouveau code sous les yeux. Il a pourtant écrit des tests pour l’ancien comportement. Les auteurs parlent d’un alignement résiduel sur le programme d’origine : le modèle reproduit ce qu’il a déjà vu au lieu de lire ce que le code fait maintenant. Un test généré peut donc exécuter la bonne ligne et affirmer la mauvaise chose. Seul quelqu’un qui sait ce qui est correct peut trancher.
La seconde étude, publiée en juin, compare des tests générés par IA à des tests écrits par des développeurs, sur des bugs réels en Python. Les tests IA en détectent 69 %, les tests humains 17,2 %.
Le détail qui compte est ailleurs. La couverture de code est quasiment la même dans les deux cas, 88,5 % de lignes côté IA contre 84,8 % côté humain. Ce qui change, c’est la densité de vérification : 5,5 assertions en moyenne contre 3,2, et cinq cas limites couverts contre trois. Les tests humains, écrits à l’avance sans connaître le défaut, exécutaient autant de code et en vérifiaient moins.
Une nuance à donner tout de suite, parce qu’elle est dans l’étude et qu’elle change la lecture : les tests IA avaient accès au correctif du bug au moment de leur génération, les développeurs écrivaient les leurs avant de connaître le défaut. La conclusion honnête n’est pas que l’IA écrit de meilleurs tests. C’est que le contexte disponible au moment d’écrire un test détermine ce que ce test sera capable de voir.
Écrire un test et juger un résultat, ce n’est pas le même travail
L’objection vient toute seule : si des tests écrits par des humains vérifient moins que des tests générés, pourquoi confier la validation à un humain ?
Parce que les deux études mesurent la production de tests, pas le jugement. Empiler des assertions, penser aux cas limites, ne rien oublier : c’est de l’exhaustivité, et une machine y est meilleure qu’un développeur pressé. Mais dans l’étude sur les bugs Python, c’est le correctif qui disait à l’IA ce qui était correct. Dans l’étude sur les 22 374 variantes, personne ne lui a dit ce que le nouveau comportement devait être, et ses tests en échec affirmaient l’ancien dans plus de 99 % des cas. Dans les deux cas, personne n’a demandé à la machine de décider ce qui est correct. Quelqu’un le savait déjà.
Dans un parc de tests réel, au moment où un test casse, ce quelqu’un n’existe pas encore. Il faut que quelqu’un dise si 79,90 est toujours le bon prix, si ce 403 est voulu, si ce bouton a été déplacé exprès. C’est l’oracle, et c’est là que l’humain est irremplaçable. Pas parce qu’il écrit de meilleurs tests, mais parce qu’il porte la connaissance de ce qui est correct. La machine propose l’exhaustivité. L’humain apporte le critère.
Pourquoi la couverture s’est imposée quand même
La couverture a une qualité imbattable, elle se calcule toute seule. Aucune réunion, aucun arbitrage métier, un pourcentage dans la CI. L’oracle demande l’inverse, quelqu’un qui connaît le produit et qui tranche.
La mesure qui remplacerait utilement la couverture existe pourtant, c’est le score de mutation : on introduit volontairement des défauts dans le code et on regarde combien la suite de tests en attrape. Meta a publié sur son usage à grande échelle, assisté par IA, sur ses propres bases de code. C’est nettement plus coûteux à calculer qu’un pourcentage de lignes, et c’est précisément pour ça que peu d’équipes le font.
Mesurer ce qui se calcule tout seul plutôt que ce qui compte coûte cher au moment précis où le volume de tests générés explose. DORA a interrogé près de 5 000 professionnels en 2025 : 90 % utilisent l’IA au travail, 30 % disent lui faire peu ou pas confiance, et 24 % seulement lui font vraiment confiance. L’édition suivante a mis un nom sur l’écart, la taxe de vérification, avec un taux d’échec des changements qui passe de 5 à 6 % et des gains de productivité qui tombent à 10 % ou moins dès qu’on touche du legacy complexe.
Ce que ça change dans une stratégie de test
Un test rouge n’est pas un problème à faire disparaître. Il a quatre causes possibles : un bug applicatif, un changement d’interface légitime, une évolution du parcours métier, une instabilité d’environnement. Deux appellent une mise à jour du scénario, deux appellent qu’on n’y touche surtout pas. Diagnostiquer coûte moins cher que réparer à l’aveugle, et ça évite de faire taire une alerte qui avait raison.
La connaissance métier qui alimente l’oracle est un actif, pas une documentation. Chez Mr Suricate, elle s’appelle la mémoire applicative : ce que la plateforme sait de votre application, de vos parcours, de ce qui est normal chez vous. Le modèle sous-jacent est remplaçable, et il le sera plusieurs fois. Cette mémoire, non.
Pour aller plus loin : comment la maintenance des tests fonctionne chez Mr Suricate.
Reste la question du coût. Chez nos clients, l’entretien du parc revient à environ cinq minutes par mois et par scénario. Sur un parc de 500 scénarios, ça représente 42 heures par mois, un quart de temps plein pour tenir un parc qui, sans ça, se dégrade en silence.
Notre position
Le vert n’a de valeur que si quelqu’un peut dire ce qu’il prouve. C’est vrai d’un test écrit à la main, ça l’est deux fois plus d’un test généré ou réparé par une IA.
Un harness solide reste nécessaire. Mais il ne vaut que l’oracle qu’on lui donne. Le reste est de la mécanique.
Si vous voulez savoir ce que vos scénarios vérifient réellement aujourd’hui, c’est une conversation d’une demi-heure.
Sources
- Haroon, Khan, Gulzar (Virginia Tech, Carnegie Mellon), Evaluating LLM-Based Test Generation Under Software Evolution, prépublication arXiv, mars 2026. arxiv.org/abs/2603.23443
- Vathana, Bhatt, Patel, Eisty, LLM vs. Human Unit Tests: Fault Detection on Real Python Bugs, prépublication arXiv, juin 2026. arxiv.org/abs/2606.08588
- DORA 2025, adoption et confiance, près de 5 000 répondants. cloud.google.com
- DORA 2026, taxe de vérification, synthèse InfoQ. infoq.com
- Barr, Harman, McMinn, Shahbaz, Yoo, The Oracle Problem in Software Testing: A Survey, IEEE Transactions on Software Engineering, 2015. ieeexplore.ieee.org
- ISTQB, glossaire, oracle de test. glossary.istqb.org
- CFTL, syllabus ISTQB CTAL-TA v4.0 en français, section 1.3.4 Déterminer les oracles de test. cftl.fr
- Meta Engineering, LLMs Are the Key to Mutation Testing and Better Compliance, septembre 2025. engineering.fb.com
