64% des ingénieurs QA déclarent utiliser des outils d’IA dans leur travail. 23% disent que ça a changé significativement leur pratique.
L’écart entre ces deux chiffres est révélateur.
Depuis 2023, l’IA générative a envahi les discours sur la qualité logicielle. Les promesses sont spectaculaires : génération automatique de cas de test, auto-réparation des tests cassés, couverture augmentée sans effort humain. Les démonstrations sont impressionnantes. Les résultats en production sont — souvent — décevants.
Je passe une grande partie de mon temps avec des équipes qui essaient concrètement d’intégrer l’IA dans leurs pratiques de test. Voici ce que j’observe vraiment.
Ce qui fonctionne aujourd’hui
1. La génération de tests unitaires à partir de code existant
C’est l’usage où l’IA apporte le retour le plus tangible et le plus immédiat. Donner à un LLM une fonction Python, un service TypeScript ou une classe Java et lui demander de générer des cas de test unitaires — ça fonctionne bien, souvent très bien.
Les équipes que j’accompagne rapportent des gains de 40 à 60% sur le temps de création des tests unitaires pour des composants bien délimités. L’IA excelle à identifier les edge cases que les développeurs auraient tendance à négliger, à générer les fixtures et les mocks, à couvrir les chemins d’erreur.
Nuance importante : ça fonctionne sur du code clair et bien structuré. Sur du code legacy avec des dépendances imbriquées, l’IA génère des tests qui s’exécutent mais qui ne testent pas grand chose d’utile.
2. La maintenance des sélecteurs et locators
C’est probablement le poste de coût le plus sous-estimé dans l’automatisation UI. Chaque fois qu’un développeur renomme un composant, change une classe CSS ou restructure une page, des dizaines de tests peuvent casser. Pas à cause d’un bug — à cause d’un changement légitime.
Les outils qui utilisent l’IA pour identifier et proposer des corrections de sélecteurs cassés (Playwright avec son mode “auto-wait”, certains plugins Cypress, les outils comme Healenium) montrent des résultats concrets. Sur un programme de 3 000 tests UI, le gain de maintenance peut représenter plusieurs jours ingénieur par mois.
3. L’analyse des résultats de test
Parcourir 8 000 lignes de logs de CI/CD pour comprendre pourquoi 23 tests ont échoué est une activité fastidieuse. Les LLMs s’y révèlent étonnamment efficaces : identification des patterns d’échec communs, corrélation avec les changements de code récents, suggestion des causes probables.
Ce n’est pas de la magie — c’est de la reconnaissance de patterns à grande échelle, ce pour quoi les LLMs sont bien calibrés.
Ce qui ne fonctionne pas encore comme promis
1. La génération de tests end-to-end de bout en bout
Les démonstrations sont séduisantes : donner une URL et une description d’un parcours utilisateur, et obtenir un test E2E fonctionnel. En laboratoire, sur une application simple, ça fonctionne.
En production, sur une vraie application avec des tokens d’authentification, des états dynamiques, des animations, des dépendances de données — le taux de succès chute drastiquement. L’IA ne comprend pas le contexte métier de votre application. Elle peut générer des interactions syntaxiquement correctes qui ne testent pas ce que vous voulez tester.
Utilisation recommandée : comme point de départ, pas comme résultat final. Le test généré par l’IA est un brouillon que votre ingénieur améliore — pas un livrable directement utilisable.
2. L’auto-réparation complète des tests
L’auto-réparation partielle (corriger un locator cassé, mettre à jour un timeout) fonctionne. L’auto-réparation “intelligente” — comprendre pourquoi un test échoue et décider si c’est un vrai bug ou un test à corriger — n’est pas encore là.
J’ai vu des équipes déployer des outils d’auto-réparation qui corrigeaient des tests qui auraient dû rester en rouge. Le pipeline passait. Le bug arrivait en production. Le problème de la réparation automatique, c’est qu’elle peut masquer exactement ce que les tests sont censés détecter.
3. La compréhension de la stratégie de test
L’IA peut générer des tests. Elle ne peut pas décider quelle stratégie de test adopter pour votre contexte. Quels risques prioriser ? Quelle couverture viser sur quel module ? Où investir en automatisation vs en tests exploratoires ? Ce sont des décisions qui nécessitent une compréhension du domaine métier, des enjeux business, et de la réalité de votre organisation — compréhension que l’IA n’a pas.
Ma position en 2026
L’IA générative est un accélérateur pour les ingénieurs QA — pas un remplaçant.
Les équipes qui obtiennent les meilleurs résultats sont celles qui ont traité l’IA comme un outil dans une pratique mature, pas comme une solution à une pratique immature. Elles avaient déjà de bons processus de revue, de bonnes conventions de code, une gouvernance claire. L’IA leur a permis d’aller plus vite sur les tâches à faible valeur ajoutée.
Les équipes qui ont attendu que l’IA “règle” leurs problèmes de qualité sont dans le même état qu’avant — avec en plus de la complexité ajoutée.
La règle que j’applique avec les équipes : utilisez l’IA pour accélérer ce que vous faites déjà bien, pas pour compenser ce que vous ne faites pas.
L’IA Readiness — la cinquième dimension d’Automate Score© — mesure exactement cette capacité : pas seulement si vous utilisez des outils IA, mais si votre infrastructure, vos pratiques et votre équipe sont prêts à en tirer un vrai retour. Parce que déployer un outil d’IA sur une base de tests non gouvernée, c’est accélérer dans la mauvaise direction.
Ce qui marche en 2026, c’est l’IA au service d’une ingénierie rigoureuse. Pas l’IA comme raccourci pour éviter la rigueur.
Vous souhaitez évaluer la maturité AI Readiness de votre programme de test ? Découvrez Automate Score© sur automatescore.com.
Je suis Reda Ennasr, CEO & Cofondateur d’In Value. Ces 5 dernières années, j’ai recruté et accompagné plus d’une centaine d’ingénieurs en Automatisation des tests. Ma mission : Transformer l’automatisation en avantage compétitif. Éditeur de la plateforme Automate Score© : l’IA qui mesure et optimise la performance de l’automatisation des tests.