You scanned the QR code from UCAAT, click the button below to open the GitHub.
Si vous avez scanné le QR code de la ParisTestConf, cliquez sur le bouton ci-dessous pour ouvrir le github.
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 bug. Ce sont vos tests. Le truc censé détecter les bugs, qui bug 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 :
L’algorithme détecte qu’un élément n’est plus trouvé
Il identifie comment adapter le test — changer de sélecteur, ajuster la structure
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 LLMs — qui ouvrent des possibilités nouvelles. Et c’est ce qu’on est venu 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.
Vous voulez une démo ? Cliquez sur le bouton ci-dessous
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 script 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.
Vous voulez une démo ? Cliquez sur le bouton ci-dessous
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.
Vous voulez une démo ? Cliquez sur le bouton ci-dessous
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 LLMs. 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.
Si vous avez scanné le QR code de la ParisTestConf, cliquez sur le bouton ci-dessous pour ouvrir le github.
