L'IA peut-elle prouver qu'un logiciel n'a pas de bugs ? Dijkstra répond toujours non

« Le test d'un programme peut révéler la présence de bugs, mais jamais prouver leur absence. » — Edsger W. Dijkstra, 1969

Au printemps 2026, une équipe du cabinet allemand codecentric a raconté avoir fait écrire seize mille tests unitaires en quatre jours par un agent de développement IA, portant à 80 % la couverture d'une grosse application .NET à moderniser. Seize mille tests, tous verts. Que prouvent-ils ? Rien, répondrait Dijkstra — et il aurait raison en 2026 comme en 1969. Aucune quantité de tests réussis ne garantit qu'un logiciel est correct : il restera toujours, tapi dans un cas non exploré, un bug possible. La question intéressante n'est donc pas de savoir si l'IA écrit des tests plus vite que nous — elle le fait — mais ce qu'elle change à ce paradoxe fondateur, et ce qu'elle n'y changera jamais.

Ce que l'IA change vraiment

La transformation est réelle et profonde. Elle se déploie sur quatre fronts.

L'efficacité d'abord. Écrire et maintenir des tests est un travail de Sisyphe : chaque nouvelle version casse des scripts, chaque interface modifiée brise des scénarios. Les LLM génèrent désormais des cas de test à partir de spécifications en langage naturel — un responsable produit décrit une fonctionnalité en français, l'IA en tire une première batterie de scénarios. Mieux : les tests dits self-healing détectent qu'un bouton a été renommé ou qu'un identifiant a changé, et se réparent seuls, là où il fallait auparavant tout réécrire à la main. Les éditeurs spécialisés (Digital.ai, Mabl et d'autres) rapportent des réductions de temps de test substantielles — de l'ordre de 30 à 50 % selon les contextes, chiffres qu'il faut prendre pour ce qu'ils sont, des retours fournisseurs à vérifier sur son propre terrain.

La qualité ensuite, et c'est ici que l'IA touche directement au problème de Dijkstra. Le talon d'Achille du test humain, c'est l'imagination bornée : nous testons les cas auxquels nous pensons, et les bugs se logent précisément dans ceux auxquels nous ne pensons pas. Or un LLM excelle à générer des scénarios que personne n'aurait imaginés : valeurs extrêmes, enchaînements absurdes, comportements d'utilisateurs erratiques. Il ne prouve toujours pas que le logiciel est correct — mais il débusque bien davantage de défauts, plus tôt.

La maîtrise du risque encore. En analysant l'historique des bugs, la complexité du code et le taux de modification des composants, des modèles prédictifs désignent les hotspots — les zones où la prochaine défaillance a le plus de chances de surgir. On concentre alors l'effort de test là où il compte, plutôt que de le diluer uniformément. C'est du triage médical appliqué au code : on soigne d'abord ce qui saigne.

L'accessibilité enfin. Historiquement, écrire des tests exigeait de savoir coder, ce qui excluait les équipes métier — celles-là mêmes qui détiennent la connaissance fonctionnelle. Grâce au langage naturel et aux interfaces no-code, un responsable métier peut désormais décrire un scénario (« quand un utilisateur saisit un mauvais mot de passe, un message d'erreur doit s'afficher ») et obtenir un test exécutable. La syntaxe Gherkin (« Étant donné / Quand / Alors »), quasi naturelle, devient une documentation vivante que tous — métier, développeurs, testeurs — peuvent lire. Le test cesse d'être une affaire de spécialistes pour devenir un langage commun.

Le cygne noir de Popper

Pour comprendre pourquoi tout cela ne lève pas le paradoxe de Dijkstra, un détour philosophique s'impose — bref, promis. Karl Popper a placé au cœur de la science une idée simple : on ne prouve jamais une théorie, on ne fait que ne pas réussir à la réfuter. Mille cygnes blancs ne prouvent pas que tous les cygnes sont blancs ; un seul cygne noir renverse tout. Le test logiciel est de part en part poppérien : chaque test qui passe est une réfutation manquée, jamais une preuve. Les seize mille tests verts de notre ouverture élargissent la chasse aux cygnes noirs — ils ne ferment pas le ciel. L'IA est un formidable amplificateur de réfutation ; elle n'est pas, et ne sera jamais, une machine à certitudes.

Qui teste le testeur ?

Voici en outre le paradoxe que l'engouement fait trop souvent oublier, et sur lequel un consultant honnête se doit d'insister. Nous employons désormais un outil faillible — un LLM qui hallucine, on l'a assez dit — pour vérifier la correction d'un autre système. Les Romains posaient déjà la question : quis custodiet ipsos custodes ? Qui gardera les gardiens ? Une IA qui génère un test peut générer un mauvais test — un test qui passe alors qu'il devrait échouer, endormant la vigilance au lieu de l'aiguiser. Un correctif suggéré par l'IA peut réparer le symptôme et aggraver la maladie.

D'où la règle d'or, non négociable : l'humain reste dans la boucle. Non par nostalgie, mais par nécessité logique. Puisque le test ne prouve jamais l'absence de bugs, le jugement sur ce qui mérite d'être testé, sur ce qui compte vraiment, sur ce qu'un test réussi signifie réellement, ne peut être délégué. On rejoint ici les autres précautions de bon sens : entraîner l'IA sur des données de qualité, protéger la confidentialité des spécifications, se méfier des outils trop jeunes, et ne jamais automatiser pour le plaisir d'automatiser. Mesurer la fiabilité de ces systèmes faillibles est devenu une discipline à part entière — c'est tout l'objet du benchmark tau-bench, qui évalue la fiabilité réelle des agents conversationnels, et les agents y trébuchent encore.

Le testeur ne disparaît pas — il monte en grade

La crainte qui accompagne toute automatisation resurgit ici : l'IA va-t-elle remplacer les testeurs ? La réponse tient dans le paradoxe de Dijkstra lui-même. Si tester ne consistait qu'à exécuter mécaniquement des scénarios, oui, la machine l'emporterait. Mais tester, au sens profond, c'est concevoir la réfutation : imaginer par où le système pourrait céder, hiérarchiser les risques, juger de la gravité d'un défaut au regard du métier. Ce travail-là, l'IA l'assiste mais ne le remplace pas. Le testeur de demain écrira moins de scripts et pensera davantage — supervision, analyse de risque, dialogue avec le métier. Il montera d'un cran, comme le développeur avant lui : c'est la même ascension que j'ai décrite face à Claude Code, l'agent de développement d'Anthropic.

Trois questions avant de déléguer vos tests

Quand une équipe me demande si elle peut confier ses tests à l'IA — recadrer les attentes avec la phrase de Dijkstra est le premier geste de nos missions de conseil en IA —, je lui soumets trois questions. Un : savez-vous dire ce qu'un test réussi signifie chez vous — quelles règles métier il protège, et lesquelles restent sans gardien ? Deux : qui relit les tests générés, et avec quelle compétence pour repérer celui qui passe alors qu'il devrait échouer ? Trois : si l'IA disparaissait demain, votre équipe saurait-elle encore concevoir une stratégie de réfutation, ou n'aurait-elle appris qu'à appuyer sur le bouton ?

Trois réponses claires, et l'IA fera de vous de meilleurs traqueurs d'erreurs. Une seule hésitation, et vous n'aurez fait qu'automatiser votre aveuglement. Popper disait que la science avance non en accumulant des certitudes, mais en éliminant des erreurs. Nous ne construirons jamais de logiciel parfait ; nous pouvons devenir toujours meilleurs à traquer nos propres fautes — la seule forme de qualité qui ait jamais existé.