Automatisation des tests en langage naturel: Karim Jouini sur TestGuild

L’épisode s’adresse aux testeurs, automaticiens, QA leads et responsables DevOps qui voient passer un nouvel outil de test « IA » chaque semaine. Si vous n’avez que dix minutes: la démonstration d’ouverture (Joe lance un test sur son propre site à partir d’une simple URL), l’explication à 19:07, et le cas concret de la banque à 34:59. L’épisode est en anglais.

Karim Jouini part d’un constat vécu chez Expensya, sa précédente entreprise (250 personnes, 60 pays): la qualité logicielle y freinait la croissance plus que tout le reste, avec près d’un million de lignes de code Playwright à maintenir. Sa réponse avec Thunders: l’automatisation des tests en langage naturel. Les tests sont écrits en anglais courant, et une IA les exécute en interprétant chaque étape à l’écran, sans générer de code intermédiaire.

Trois idées structurent l’échange:

• Le langage naturel résiste au changement. Si le bouton « Next » devient une flèche, le test ne casse pas: l’IA comprend l’intention.
• L’humain garde la stratégie. Il décide quoi tester, avec quelles données, et valide ce qui est un défaut ou non. L’IA exécute, analyse et apprend.
• Le ROI se mesure en vitesse et en couverture: livrer deux fois plus vite et couvrir dix fois plus de scénarios avec les mêmes ressources, selon Karim. Une banque européenne a ainsi ramené une migration de core banking de trois ans de tests à quatre mois.

Pourquoi les tests automatisés classiques freinent la croissance

Avant de parler d’IA, Karim décrit le problème qu’il a vécu comme dirigeant. Chez Expensya, surnommée « l’Expensify européen » par Joe, le produit était mis à jour tous les jours, dans 60 pays et 17 langues. Avec des réglementations qui changent pays par pays, c’étaient deux à quatre changements réglementaires par semaine à intégrer sans régression. Il identifie quatre dimensions au problème.

1. Le coût: Environ un million de lignes de code Playwright, écrites et maintenues par des développeurs et des QA. Autant de temps qui n’allait pas au produit.
2. La durée des campagnes: Avec des cartes d’entreprise, des connexions bancaires et des agences de voyage à intégrer, une version majeure demandait quatre à cinq semaines de campagne de test, ce qui limitait mécaniquement le nombre de versions majeures par an.
3. La maintenance: Lors d’un changement de charte graphique, remettre les tests automatisés en état a pris six mois. Les sélecteurs avaient changé, pas le fonctionnement du produit.
4. La collaboration: L’entreprise était agile, mais le test restait en cascade. Surtout, personne ne pouvait répondre avec certitude à un grand compte qui demandait: « Qu’avez-vous testé, dans notre configuration ? »

C’est ce diagnostic qui a convaincu Karim et son cofondateur Jihed Othmani, après la vente d’Expensya, que la qualité logicielle était le chantier à reprendre de zéro.

« Un testeur manuel sous stéroïdes »: l’automatisation des tests en langage naturel

Karim résume le marché en deux familles. Le test manuel est de haute qualité, car un humain voit ce qu’aucun script ne vérifie: un problème d’UX, une lenteur, une incohérence. Mais il ne passe pas à l’échelle. L’automatisation passe à l’échelle, mais elle coûte cher à construire, exige des profils techniques et crée un transfert de connaissance permanent entre ceux qui savent comment le produit doit fonctionner et ceux qui savent coder les tests.

Thunders vise le meilleur des deux: la souplesse d’un bon testeur manuel, à qui l’on explique une fonctionnalité ou transmet un document, avec la vitesse de l’automatisation. La plateforme repose sur deux modules.

Du cahier des charges au plan de test

On part d’une user story, d’un ticket Jira, d’une spécification fonctionnelle ou d’un simple prompt. L’IA propose des sections de test, puis des scénarios, des cas et enfin des étapes, aussi détaillées qu’un script Selenium. Le document est collaboratif: plusieurs personnes, y compris un client, peuvent l’éditer, ou demander à l’IA de le faire.

Du « Selenium en anglais »

Le second module exécute ces étapes. « Va sur cette page, clique ici, saisis ceci, vérifie que la page correspond à la maquette Figma. » Des personas IA suivent le script et agissent comme un utilisateur. L’exemple de Karim: un test demande de cliquer sur « Next », mais le bouton est devenu une flèche. Un script Selenium échoue faute de trouver l’élément. L’IA, elle, comprend que la flèche signifie « suivant », continue, et laisse un commentaire pour qu’on précise l’instruction. Les tests existants se créent aussi par enregistrement: le parcours enregistré est converti en récit en langage naturel plutôt qu’en coordonnées de clics.

Aucun code sous le capot: ce qui change pour la maintenance

C’est le point sur lequel Joe insiste: si le test est en anglais, qu’y a-t-il en dessous, du Selenium ou du Playwright ? « Il n’y a rien en dessous », répond Karim. Beaucoup d’outils génèrent du code, puis tentent de le réparer quand il casse (le fameux self-healing des sélecteurs). Thunders interprète chaque étape au moment de l’exécution, en regardant le contenu du navigateur. Le cache et l’optimisation évitent de consommer des tokens inutilement et de ralentir l’exécution, mais aucun code n’est produit.

Deux conséquences pratiques:

• Moins de maintenance: un changement d’interface qui ne change pas la fonctionnalité ne casse pas le test. C’est ce que les tests auto-réparateurs promettent, poussé jusqu’au bout.
• Les tests restent un actif versionnable: pour les automaticiens habitués à Git, chaque test peut être synchronisé dans le dépôt via l’API, sous forme de fichier JSON contenant l’anglais. Les PM, PO et testeurs manuels, eux, s’intéressent surtout à la propriété et au débogage de leurs tests.

Dans le pipeline CI/CD

Quand un test qui passait hier échoue, l’IA décrit l’échec (« ce formulaire devait être en lecture seule, un champ est modifiable »), le compare à l’exécution précédente et remonte à la cause, par exemple un utilisateur de test dont le rôle a changé. Si l’humain confirme le défaut, un ticket Jira est créé avec les étapes de reproduction. Plusieurs clients branchent ensuite Jira sur un assistant de code (Cursor, Devin), puis relancent le test pour valider le correctif. Une boucle de bout en bout.

Les garde-fous

Par défaut, un test écrit s’exécute sans validation. Le contrôle humain porte sur ce qui est un défaut ou non, avec une boucle d’apprentissage. L’exemple: vérifier l’absence de fautes sur les pages partenaires de TestGuild. Si un partenaire porte un nom de marque inventé, l’IA le signalera comme faute, on lui indique que c’est attendu, et elle ne le signalera plus.

Comment écrire un bon test en langage naturel

Faut-il bien écrire l’anglais pour obtenir de bons résultats ? Non, répond Karim: les fautes de frappe sont tolérées. Le vrai ennemi, c’est l’ambiguïté. Sa règle: si vous donnez votre instruction à dix personnes et qu’elles ne font pas toutes la même chose, l’instruction est mauvaise.

« Clique sur l’élément bleu » est exécutable, mais faible: combien de nuances de bleu, et s’agit-il d’un bouton, d’un lien ou d’un texte ? Un assistant de notation des prompts, annoncé pour la version majeure suivante, signale ce type d’étape et explique pourquoi elle est fragile.

Joe en tire la conclusion côté métier: l’expert du domaine, celui qui connaît les règles de l’application, écrit naturellement les meilleurs tests. L’IA fait le travail d’exécution, l’expert fait le travail de pensée. Karim le formule ainsi: Thunders est « votre armée de stagiaires », capable de tester en parallèle et sans limite, mais la stratégie de test (quoi tester, quand, avec quelles données) reste à l’humain. Côté technologies, tout ce qu’un humain peut ouvrir dans un navigateur est testable: applications web, API, applications accessibles via Citrix, et le mobile natif via une ferme d’appareils.

Deux études de cas: une banque et un éditeur SaaS

Joe le reconnaît: son audience est sceptique. Karim répond par deux cas chiffrés, en précisant d’emblée que l’un d’eux le met « un peu mal à l’aise ».

Une banque européenne: trois ans de tests ramenés à quatre mois

Une grande banque européenne devait mettre à niveau son système de core banking, massivement personnalisé et entouré d’applications maison. Elle prévoyait trois ans de tests avec une équipe de dix QA. Avec Thunders, le projet a duré quatre mois, pour trois raisons:

1. Les experts métier ont écrit des tests en enregistrant leurs propres parcours, comblant un déficit de connaissance que dix QA ne pouvaient pas combler seuls.
2. Les sessions utilisateurs existantes ont été transformées en scénarios par un outil interne.
3. L’ancien code Selenium, Cypress et Playwright a été converti en langage naturel (voir comment importer vos tests existants).

La formule de Karim: « Un crédit immobilier reste un crédit immobilier, quelle que soit la version du core banking. » Le formulaire peut passer d’une page à quatre étapes et les composants changer: fonctionnellement, on demande toujours un crédit. Il reste honnête sur la limite: il a fallu quatre mois de travail, « nous sommes à 80 ou 90 % dans cette direction ».

Un éditeur SaaS qui a confié le test à ses product managers

Le second cas est un éditeur de logiciels d’environ 50 millions de chiffre d’affaires, en forte croissance, qui avait déjà décidé de se séparer de ses équipes de test manuel et automatisé. Sa demande à Thunders: empêcher la qualité de s’effondrer. Neuf product managers rédigent désormais les spécifications et construisent tous les cas de test dans Thunders. Sceptiques au départ, ils ont constaté qu’ils passaient moins de temps à tester eux-mêmes qu’à expliquer auparavant à une autre équipe quoi tester, puis à analyser ses résultats. Karim assume la gêne: le ROI est réel, mais des personnes ont perdu leur emploi dans le processus.

Joe y voit une piste que Karim confirme: des modules de test métier réutilisables. Un cabinet spécialisé dans les logiciels de leasing automobile construit ainsi, sur Thunders, ce que signifie « tester un système de leasing », pour le réutiliser d’un constructeur à l’autre.

QA managers: de contributeur individuel à manager d’IA

La question de l’emploi revient deux fois dans l’épisode. Karim ne pense pas que l’automatisation des tests en langage naturel détruise des postes à court terme, mais il reconnaît qu’une équipe avec des leaders fonctionnels solides peut s’en servir au lieu de recruter des QA.

Sa conviction va au-delà du test: l’IA transforme chaque contributeur individuel en manager. Il décrit sa propre journée: choisir le matin les dix tâches à confier à ses agents, rédiger ses prompts pendant deux heures, puis relire, corriger, renvoyer. Pour un QA manager, la question devient donc: mon équipe est-elle prête à devenir une équipe de QA leads, qui délèguent l’exécution tout en restant propriétaires de la qualité ? Déléguer à Thunders ne dispense pas de posséder le résultat, de la même façon qu’un développeur reste responsable du code écrit par l’IA.

• Un test en langage naturel interprété à l’exécution ne casse pas quand l’interface change sans que la fonctionnalité change.
• « Aucun code sous le capot » est une différence d’architecture, pas un détail: générer puis réparer du code, ce n’est pas la même chose que l’interpréter à chaque exécution.
• L’ambiguïté est l’ennemie du test IA, pas la qualité de l’anglais: une étape comprise de dix façons différentes est une mauvaise étape.
• La stratégie de test reste humaine: quoi tester, quand, avec quelles données, et ce qui constitue un défaut.
• Les experts métier deviennent des auteurs de tests, ce qui a permis à une banque européenne de passer de trois ans à quatre mois.
• Définissez l’indicateur de succès avant de lancer un projet IA: c’est la première cause d’échec des pilotes, selon Karim.

Animé par Joe Colantonio, le TestGuild Automation Podcast est l’un des podcasts de référence de la communauté du test logiciel anglophone, avec plus de 570 épisodes consacrés à l’automatisation, aux outils, au test de performance et, de plus en plus, à l’IA. TestGuild organise aussi Automation Guild, une conférence en ligne annuelle, où Joe a fait plus ample connaissance avec Karim et Thunders en 2026. Sa ligne éditoriale est de faire le tri entre effet d’annonce et pratique réelle, avec une audience d’automaticiens réputée exigeante. Écouter l’épisode sur testguild.com.