43 % expérimentent l’IA en QA. 15 % l’ont vraiment déployée.

Deux chiffres sortent du World Quality Report 2025-26, et on les cite rarement ensemble : 43 % des organisations expérimentent l’IA générative en ingénierie de la qualité, 15 % l’ont déployée à l’échelle de l’entreprise.

La lecture optimiste consiste à dire que l’adoption progresse. La lecture utile consiste à demander ce qui se passe entre les deux — parce que c’est là que se trouve tout le travail réel.

Ce que mesure réellement le rapport

Avant d’interpréter, il faut lire précisément. Le rapport distingue trois états : expérimenter, déployer en production sur un périmètre, et passer à l’échelle de l’organisation. Ce sont trois choses très différentes, et les confondre produit les titres qu’on lit partout.

Les chiffres complets dessinent une image plus nuancée :

Le gain moyen de 19 % est le chiffre le plus trompeur du lot. Une moyenne qui recouvre à la fois des organisations obtenant des résultats substantiels et un tiers n’obtenant presque rien ne décrit la situation de personne. C’est exactement le même problème qu’un temps de réponse moyen en test de performance : la moyenne masque précisément ceux qui souffrent.

Les trois freins cités par les répondants

Ils ne sont pas ceux qu’on attend. Aucun ne porte sur la capacité des modèles.

• 64 % — la difficulté d’intégrer les outils aux workflows existants
• 63 % — les limites et les risques liés aux données
• 60 % — les hallucinations et la fiabilité

Autrement dit : le modèle génère un test plausible, mais personne ne sait où le ranger, avec quelles données l’exécuter, ni comment savoir s’il a raison.

Ce sont trois problèmes d’ingénierie. Pas trois problèmes d’intelligence artificielle. Et ils existaient tous les trois avant l’arrivée de la GenAI — elle les a simplement rendus impossibles à ignorer, en multipliant le volume de test produit.

Pourquoi le pilote réussit et l’échelle échoue

Un pilote se mène sur un périmètre choisi, avec des données propres, et une personne motivée qui relit chaque sortie.

Aucune de ces trois conditions ne survit au passage à l’échelle.

Le périmètre choisi devient le périmètre entier, dont une partie n’est pas testable. Les données propres deviennent les données réelles, avec leurs cas particuliers accumulés sur dix ans. Et la personne motivée qui relisait devient une équipe pour qui la relecture est une corvée ajoutée à son travail.

Le générateur, lui, ne ralentit pas. Il continue de produire.

Le test généré qui ne peut pas échouer

Voici la forme la plus courante de dette introduite par la génération automatique. Elle est invisible dans tous les tableaux de bord.

// Généré automatiquement — et jamais relu
@Test
void shouldLoginSuccessfully() {
    driver.findElement(By.id("user")).sendKeys("admin");
    driver.findElement(By.id("pass")).sendKeys("admin123");
    driver.findElement(By.id("submit")).click();
    // Aucune assertion. Ce test ne peut pas échouer.
}

Ce test passe. Il passera toujours. Il augmente la couverture déclarée et ne protège de rien.

Multipliez-le par trois cents, et vous obtenez une suite de tests dont le taux de réussite est excellent, dont la couverture est flatteuse, et qui laisse passer les régressions. Le pire scénario n’est pas l’absence de tests : c’est une suite de tests en laquelle on a confiance à tort.

La version utile demande une décision humaine — celle de dire ce qui doit être vrai après l’action :

@Test
void shouldLandOnDashboardAfterLogin() {
    loginPage.signIn(validUser);

    // L'assertion EST le test. Le reste n'est que de la mise en situation.
    assertThat(dashboardPage.isDisplayed())
        .as("L'utilisateur authentifié doit arriver sur son tableau de bord")
        .isTrue();
    assertThat(dashboardPage.welcomeMessage())
        .contains(validUser.firstName());
}

Un modèle peut écrire la première partie. Il ne peut pas décider de la seconde à votre place, parce qu’elle encode ce que votre métier considère comme correct.

Le cas des données de test

60 % des organisations déclarent peiner à produire des données de test sûres et à l’échelle. C’est le frein le plus structurel, et le moins discuté.

La réponse qui monte est celle des données synthétiques : leur usage en test est passé de 14 % en 2024 à 25 % en 2025. La progression est réelle et la direction est bonne — elle résout à la fois le problème de volume et celui de la confidentialité.

Mais elle déplace le problème plutôt qu’elle ne le supprime. Des données synthétiques mal conçues sont trop régulières : elles ne contiennent pas les cas tordus accumulés dans une base de production — le client créé en 2009 avec un champ obligatoire vide, la commande à zéro euro, l’adresse de 180 caractères. Ce sont précisément ces cas qui cassent en production.

Générer des données de test, c’est un travail de modélisation du domaine. Pas une tâche d’outillage.

Ce qui marche aujourd’hui

Notre lecture, à partir de ce que nous observons sur le terrain plutôt que dans les démonstrations commerciales.

L’analyse plutôt que la production. C’est là que le rapport bénéfice/risque est le meilleur aujourd’hui :

• regroupement automatique des échecs par cause probable, quand une suite produit quatre-vingts échecs qui n’ont que trois origines ;
• détection des tests instables à partir de l’historique d’exécution ;
• priorisation des campagnes selon l’impact d’un changement.

Dans ces trois cas, une erreur du modèle coûte peu : vous perdez quelques minutes. C’est le critère qui devrait guider l’adoption — que se passe-t-il quand le modèle se trompe ?

La génération de données de test. À condition d’être encadrée par des règles métier explicites, et non laissée libre.

L’aide à la rédaction. Transformer un critère d’acceptation flou en scénarios candidats, que l’humain trie. Le modèle propose, l’humain dispose — et c’est le tri qui crée la valeur.

Ce qui ne marche pas encore

La génération autonome de scénarios de bout en bout. Elle produit du volume, pas de la couverture. Le volume coûte en maintenance et en temps d’exécution ; la couverture protège. Les deux ne sont pas corrélés.

Le self-healing sans garde-fou. La promesse est réelle : moins de tests à reprendre à chaque changement de sélecteur. Le risque l’est aussi : un test qui « se répare » tout seul quand un sélecteur change est un test qui a peut-être masqué une régression d’interface volontaire. Les deux affirmations sont vraies simultanément. Il faut décider où l’on accepte le compromis, et le tracer.

Le raisonnement sur la logique métier. Un modèle ne sait pas que dans votre domaine, un remboursement au-delà de trente jours suit un circuit d’approbation différent. C’est écrit dans la tête de trois personnes, pas dans le code.

Ce que nous en faisons

Nous n’avons pas d’outil d’IA à vous vendre. Ce que nous constatons, c’est que les organisations qui tirent quelque chose de ces technologies sont celles qui avaient déjà résolu trois choses : la testabilité de leur produit, la maîtrise de leurs données de test, et un processus de revue qui existe réellement.

Sans ces trois fondations, l’IA n’accélère pas la qualité. Elle accélère la production d’artefacts de test, ce qui n’est pas la même chose — et peut même dégrader la situation, en produisant un sentiment de sécurité qui n’est adossé à rien.

L’écart entre 43 % et 15 % ne mesure pas le retard technologique des entreprises. Il mesure la difficulté du travail d’ingénierie qu’il faut faire avant que l’outil ne serve à quelque chose.