Ce que l'IA change dans une journée de testeur, et ce qu'elle ne change pas

« L'IA va-t-elle remplacer les testeurs ? » C'est une question fréquente chez les personnes qui envisagent une reconversion vers le test. Plutôt que de prédire l'avenir, cet article regarde ce qui est déjà observable : ce que les outils savent faire aujourd'hui, ce que demandent les offres d'emploi, et ce que nous avons mesuré sur une mission.

Un repère pour commencer : dans notre baromètre des compétences QA d'octobre 2026, une offre QA sur cinq (20,7 %) mentionne l'IA. Le sujet est dans les fiches de poste. Il ne les a pas remplacées : la même étude montre que Jira (40 %), l'agilité (48,6 %) et la CI/CD (35,1 %) restent bien plus cités.

Sur le terrain : de trois semaines à une journée

Un exemple tiré de nos missions. À partir d'un fichier PDF de spécification :

• extraire les scénarios de test nous prenait environ une semaine ; avec un assistant IA, une demi-journée ;
• les automatiser avec Playwright représentait environ deux semaines de travail ; aujourd'hui, une demi-journée.

Ce gain n'a de valeur qu'avec une relecture systématique des scénarios et du code produits : c'est elle qui garantit que les tests vérifient bien ce que dit la spécification. Et une règle avant tout : une spécification client ne part dans un outil d'IA qu'avec l'accord du client, et dans un outil qu'il autorise.

Ce qui se réduit

Le code répétitif. Avec un serveur comme Playwright MCP, un assistant ouvre l'application, observe la page et propose un test à partir de ce qu'il a vu. Écrire des sélecteurs et de la plomberie à la main prend moins de temps.

L'extraction des scénarios. À partir d'une spécification, un assistant propose rapidement une liste de scénarios, comme dans l'exemple ci-dessus. Attention : il peut inventer une règle métier qui n'existe pas. Un premier jet, pas une livraison.

Le tri des échecs. Lire des journaux, comparer deux exécutions, proposer une cause probable : l'IA accélère ce travail. Les Test Agents de Playwright vont plus loin avec un « healer » qui tente de réparer les tests en échec, et qui marque le test comme à corriger quand il n'y arrive pas.

Ce qui grossit

La relecture. Un test qui passe n'est pas forcément un bon test. L'IA vérifie volontiers ce qu'elle vient de faire (un clic a eu lieu) plutôt que ce que le métier attend (le bon montant, le bon statut). Relire devient une part importante du travail : notre grille de revue des tests générés par l'IA tient en 7 questions.

La conception. Partitions d'équivalence, valeurs limites, tables de décision : décider quoi tester reste un travail humain, et c'est lui qui donne de la valeur aux tests générés.

Les données et la sécurité. Des données de test dédiées et recréées à chaque exécution, aucun mot de passe dans un prompt, aucun agent lancé sur la production. Plus l'outil est autonome, plus ces règles comptent.

Tester l'IA elle-même. Quand une application intègre un modèle de langage, ses réponses varient d'une exécution à l'autre. Il faut des jeux d'évaluation, des critères d'acceptation et un suivi des régressions adaptés. C'est un champ de compétences nouveau pour les équipes QA.

Ce qui ne change pas

• Comprendre le métier du client : c'est ce qui permet de dire qu'un résultat est faux.
• Décider de ce qui est correct. Un outil peut exécuter un test ; il ne sait pas, seul, ce que l'entreprise attend.
• Parler avec les développeurs et le Product Owner, et défendre un risque avant une mise en production.
• La responsabilité. Quand un test laisse passer une régression, ce n'est pas l'assistant qui en répond.

Une journée type, version 2027 (exemple illustratif)

• 9 h : point d'équipe. Une nouvelle fonctionnalité de remboursement arrive en recette.
• 9 h 30 : l'assistant propose une première liste de scénarios à partir de la spécification. Le testeur en retire deux qui reposent sur une règle inventée et ajoute les valeurs limites oubliées.
• 11 h : exploration du parcours avec l'assistant, sur l'environnement de test, avec un compte dédié.
• 14 h : l'assistant génère les tests. Le testeur les relit avec une grille : assertion métier, locators accessibles, données isolées. Il casse volontairement le code une fois pour vérifier que chaque test échoue.
• 16 h : deux tests échouent dans la CI. L'assistant propose une cause, le testeur la vérifie avant de corriger.
• 17 h : le testeur présente au Product Owner les risques restants, ceux qu'aucun test automatique ne couvre.

Les outils raccourcissent les étapes du milieu. Le début (décider quoi tester) et la fin (juger le risque) restent humains.

Ce qu'il faut apprendre, concrètement

1. Les bases du test : techniques de conception, gestion des anomalies, outils comme Jira et Xray.
2. Un framework d'automatisation (Playwright en tête des offres QA) et assez de code pour relire ce que l'IA produit.
3. L'usage d'un assistant, avec une méthode : explorer, générer, relire.
4. Le test des systèmes qui intègrent de l'IA. La certification ISTQB CT-GenAI couvre l'usage de l'IA générative dans le test.

C'est l'ordre que suit notre formation testeur QA automatisation & IA : la conception des tests d'abord, Playwright ensuite, puis l'IA appliquée au test.

Ce qu'on surveille

• La part des offres QA qui mentionnent l'IA, au prochain baromètre (20,7 % en octobre 2026).
• La manière dont les offres décrivent cette compétence : « utiliser l'IA pour tester » ou « tester des systèmes d'IA ».
• La maturité des agents de test, version après version.

Questions fréquentes

Article signé par Oussama Belakhdar, rédigé avec l'aide de l'IA. Le retour de mission est celui de l'auteur ; les pourcentages viennent du baromètre ADC du 2 octobre 2026. La journée type est un exemple illustratif, pas un témoignage.