Comment le self-healing va révolutionner vos tests automatisés grâce à l’IA ?

Les démos de ce talk sont sur GitHub : ParisTestConf 2026 et UCAAT 2026.

Le self-healing des tests : ce qu’on a partagé à la ParisTestConf

Le paradoxe que personne n’ose admettre.

On a posé la question à la salle : « Levez la main si vous automatisez des tests. »

Beaucoup de mains.

« Gardez la main levée si vous êtes frustrés par l’automatisation des tests. »

Les mains sont restées levées.

C’est le paradoxe de l’automatisation. On automatise pour gagner du temps. Mais plus la suite de tests grandit, plus la maintenance explose. Un DOM qui change, un timing asynchrone capricieux, une simple refacto… et le dashboard vire au rouge.

Le pire ? Ce n’est souvent pas votre application qui bugue. Ce sont vos tests. Le truc censé détecter les bugs, qui bugue lui-même.

C’est pour répondre à ce problème qu’on a monté ce talk à la ParisTestConf avec Steven, et c’est au cœur de ce qu’on construit chez Qanary.

C’est quoi le self-healing, concrètement ?

Le self-healing, c’est la capacité d’un système de tests à se réparer automatiquement quand quelque chose casse.

Le principe en trois étapes :

1. L’algorithme détecte qu’un élément n’est plus trouvé.
2. Il identifie comment adapter le test : changer de sélecteur, ajuster la structure.
3. Il stabilise la base de tests sans intervention humaine.

Les bénéfices sont directs : moins de temps passé en maintenance, une base de tests plus stable, une couverture qui peut passer à l’échelle, et des cycles de livraison plus rapides.

Ce n’est pas nouveau. Il existait déjà des approches algorithmiques ou par machine learning. Mais depuis quelques mois, c’est l’IA générative (les LLM) qui ouvre des possibilités nouvelles. Et c’est ce qu’on est venus montrer.

3 approches, du plus guidé au plus autonome

On a structuré le talk autour de trois niveaux d’autonomie croissante. Chaque démo était réelle, sur Playwright, reproductible à la maison.

1. Les agents Playwright (autonomie faible)

Sortis en octobre dernier, les agents Playwright embarquent trois composants :

1. Un planner, qui explore le site et identifie des parcours à couvrir.
2. Un generator, qui génère les cas de tests.
3. Un healer, qui observe la page et répare le test en cas de sélecteur cassé.

C’est bien. C’est intégré. Mais c’est très consultatif : l’outil vous demande régulièrement quoi faire. Vous restez très actif dans la boucle.

Voir la démo sur GitHub

2. Claude Code en ligne de commande (autonomie intermédiaire)

L’idée ici : et si on pouvait travailler sans ouvrir l’IDE ? Via un simple terminal, ou même la voix ?

On délègue à Claude Code la détection du problème, la recherche de solution et la mise à jour directe de la codebase. On valide, on ne scripte pas.

La vraie puissance ? Ce type d’approche peut être déclenché depuis un outil d’automatisation, un Slack, une CI Jenkins ou GitLab. Première étape vers un self-healing qui tourne sans vous.

Voir la démo sur GitHub

3. Le multi-agent (autonomie maximale)

Là, on entre directement dans la CI grâce à Claude Code. On y retrouve une structure classique d’équipe : un PO, un QA, un dev. Sauf que ce sont des sous-agents.

On donne une instruction. Selon le contexte, elle est distribuée aux agents, qui travaillent ensemble, étape par étape, pour réparer les tests, sans qu’on ait à intervenir.

C’est le niveau d’autonomie le plus élevé. Et on l’a poussé un peu au-delà du self-healing pur, volontairement, pour montrer ce qui est déjà possible.

Voir la démo sur GitHub

Ce qu’il ne faut pas faire

On a insisté sur les limites, parce qu’un talk honnête parle aussi de ce qui ne marche pas.

Le danger du faux négatif. Si un bouton disparaît parce qu’un produit est en rupture de stock, l’IA ne doit pas inventer un clic sur un autre élément. Le but n’est pas que tout soit au vert. C’est de connaître la vérité sur l’état de votre application.

Le coût des LLM. Ces modèles consomment des tokens. Le multi-agent en particulier. Dans la grande majorité des cas, le ROI reste positif. Mais ça s’anticipe.

L’IA n’est pas un stagiaire sur qui se défausser. L’intégration de ces outils est un projet à part entière. Il faut tester, vérifier, valider ce qui est produit. Vous restez garant de la qualité, quoi qu’il arrive.

Ce que ça change vraiment

Le self-healing ne supprime pas le rôle du testeur. Il le déplace.

Vous n’êtes plus le mécanicien qui répare des sélecteurs cassés un par un. Vous devenez l’architecte qui décide quoi couvrir, pourquoi, et avec quelle priorité.

Votre valeur, ce n’est pas de scripter. C’est de comprendre le produit, comprendre le métier, savoir ce qui compte vraiment à tester. L’IA répond au « comment réparer ». C’est vous qui répondez au « quoi automatiser ».

C’est dans cette conviction qu’on construit Qanary : rendre la QA plus accessible, plus autonome, et surtout plus honnête sur ce qu’elle coûte vraiment en temps.

Si vous étiez à la conf et que vous voulez creuser, ou si vous voulez tester Qanary sur votre projet, on est disponibles.