Cet article fait partie d’une série sur les agents IA d’exécution de tests. Dans la partie 1, j’ai présenté les principes des agents IA GUI et leur capacité à exécuter les tests sur IHM. Dans la partie 2, j’ai illustré un exemple concret avec Lynqa intégré à Jira/Xray.
Dans cette troisième partie, je souhaite aborder un paradoxe observé sur le terrain : certaines équipes QA perçoivent ces deux approches de l’automatisation par l’IA comme mutuellement exclusives, les obligeant à choisir entre l’agent IA exécutant les tests et l’IA assistant à l’écriture des scripts.
IA pour l’automatisation : deux approches différentes mais complémentaires
Commençons par clarifier ce dont on parle, car sous le terme générique « IA pour automatiser les tests » se cachent des approches différentes.
Les agents IA d’exécution de tests prennent vos cas de test manuels ou vos scénarios Gherkin tels qu’ils sont rédigés et les exécutent directement sur l’interface, sans script ni code. L’agent interprète les étapes en langage naturel, interagit avec l’application et produit un rapport d’exécution détaillé : résultats par étape, captures d’écran, analyse des vérifications. C’est un outil IA fait pour les QA fonctionnels, ceux qui connaissent l’application et qui conçoivent les tests.
Les assistants ou agents IA de scripting, à l’image de GitHub Copilot dans VS Code sont utilisés pour accélérer l’écriture et la maintenance des scripts de test dans des frameworks classiques tels que Playwright ou Cypress. Ils s’adressent aux automaticiens qui construisent les suites de régression scriptées et qui passaient jusqu’ici une partie non négligeable de leur temps à effectuer de la maintenance sur du code cassé.
Ce sont donc deux approches IA, deux modes d’usage et deux profils d’utilisateurs. Le tableau ci-dessous résume les principales différences.
Ce tableau invite à quelques remarques pratiques. La frontière entre les deux approches repose moins sur la nature des tests que sur leur niveau de maturité et sur le profil des utilisateurs de l’IA :
- Des tests fonctionnels en situation évolutive (IHM, nouvelles features, …) n’ont pas vocation à être scriptés ; cela correspond à l’exécution automatique par un agent IA.
- À l’inverse, une suite de régression stable, exécutée à chaque build, mérite l’investissement en scripting pour sa robustesse et ses performances en CI/CD, avec l’assistance de l’IA pour la création et la maintenance.
En pratique, un usage complémentaire et séquentiel
Ce qui me semble important, c’est que ces deux voies peuvent non seulement coexister, mais aussi s’enchaîner de façon très naturelle au fil des cycles de développement.
Prenons un exemple concret. Une équipe travaille sur une application e-commerce. En cours de sprint, le QA fonctionnel a rédigé des scénarios Gherkin pour tester le tunnel de commande : ajout au panier, saisie d’adresse, paiement et confirmation.
Ces scénarios évoluent à chaque itération en fonction des retours des développeurs et du PO. L’agent IA les exécute directement, sans intervention de l’automaticien, et produit le rapport de test pour la démo de fin de sprint. C’est rapide, c’est sans code et ça valorise le travail de conception du QA fonctionnel.
Quelques sprints plus tard, le tunnel de commande est stabilisé. Les scénarios ont été éprouvés par plusieurs cycles d’exécution agentique, les ajustements sont mineurs. C’est à ce moment que l’automaticien reprend la main : il prend ces scénarios matures, et avec l’aide de GitHub Copilot ou d’un outil équivalent, il génère les scripts Playwright correspondants. Ces scripts entrent dans la suite de régression, tournent à chaque build et l’automaticien n’a plus à les réécrire de zéro.
Ce séquencement, agent IA d’abord pour valider et affiner, scripting par l’IA ensuite pour industrialiser, est selon moi la trajectoire naturelle vers laquelle vont converger la plupart des équipes QA.
Ce que ça change pour les équipes QA
Pour les équipes QA, cette distinction a des implications concrètes sur la répartition des compétences et des responsabilités.
Côté QA, fonctionnels et analystes de test, l’agent IA d’exécution leur donne de l’autonomie dans l’automatisation sans les contraindre à monter en compétences sur un framework. Ils n’ont pas besoin de maîtriser Playwright pour faire tourner leurs scénarios automatiquement. C’est un levier de productivité et, j’oserais dire, de fierté professionnelle : leur travail de conception de tests est directement exécutable.
Côté automaticiens, l’IA de scripting les libère de la tâche ingrate : la maintenance. Ils passent moins de temps à corriger des sélecteurs cassés ou à réécrire des scripts après une refonte de l’IHM, et plus de temps à la conception de l’architecture de test et à la qualité des suites de régression.
Quelques questions pratiques pour guider l’organisation :
- Quels tests sont destinés à être fréquemment actualisés ? Ils correspondent au périmètre naturel de l’agent IA d’exécution.
- Quelles fonctionnalités sont stabilisées et font l’objet d’une régression systématique ? Ce sont les candidats au scripting assisté par IA.
- L’équipe QA dispose-t-elle d’automaticiens avec une réelle capacité à maintenir des scripts ? Sinon, l’agent IA d’exécution de tests peut couvrir l’essentiel des besoins pour accélérer les cycles de test.
Pour conclure
Je ne crois pas que la question soit « agent IA ou scripting IA ». Je vois plutôt le sujet de l’articulation de ces deux approches pour qu’elles servent chacune dans l’équipe, au bon moment du cycle de vie des tests.
Pour accélérer les cycles de test et supprimer les goulets d’étranglement des phases d’exécution des tests manuels au sein des sprints, les équipes QA peuvent mettre en place une approche complémentaire, appuyée sur ces deux approches, pour automatiser les tests avec l’IA.
Cela permet d’optimiser, grâce à l’IA, autant les cycles de tests manuels (en première phase) que l’automatisation scriptée (en deuxième phase).
Et vous, dans vos équipes, comment gérez-vous l’arrivée de l’IA dans la QA ?
Échangeons en commentaires.
À propos de l’auteur
Bruno Legeard dirige le Lab IA de Smartesting (éditeur de Lynqa). Expert en test logiciel et membre du CFTL, il contribue activement à la définition de la certification ISTQB CT-GenAI « Tester avec l’IA générative ».
