QA augmentée. Ce que l'IA change vraiment dans le test.

Le parc que personne n'a le temps de maintenir.

Dans les organisations d'ingénierie que nous accompagnons à Paris, Dubaï, Singapour et Bali, le constat se répète. Il existe un parc automatisé construit sur quatre ans, il tourne en cinquante minutes, un tiers est en échec ou en quarantaine, tout le monde sait quelles alertes ignorer, et la décision de mise en production revient à deux personnes qui lisent le rapport et tranchent au jugé. Personne n'a le temps de réparer, puisque chaque sprint apporte des fonctionnalités à couvrir.

Brancher un modèle qui génère deux cents cas de plus sur cette situation l'aggrave. La question utile est plus étroite : quelles parties du métier consomment du temps sans exiger de jugement, et un modèle peut-il les traiter assez bien pour rendre à l'équipe son temps de jugement.

Ce que recouvre la QA augmentée.

La QA augmentée, c'est l'usage de modèles de langage et de code à l'intérieur d'un processus de test existant, pour rédiger, réparer, classer et préparer, avec un humain qui relit tout ce qui devient un verdict. C'est une discipline distincte du test des systèmes d'IA eux-mêmes, qui obéit à d'autres règles puisque le système sous test est probabiliste. Il ne faut pas confondre les deux, et le principe qui les sépare est celui que nous posons dans l'IA fait le travail, l'humain valide. Ici, il s'agit d'utiliser l'IA pour mieux tester du logiciel déterministe ordinaire.

La définition porte sa propre limite. Un modèle produit vite du texte et du code plausibles. Il n'a aucun accès à l'intention derrière une fonctionnalité, aucune connaissance du segment client qui tolère telle défaillance, et aucun enjeu dans la mise en production. Tout ce qui dépend de ces trois choses reste à une personne.

Là où l'IA gagne sa place.

• La conception de tests à partir des exigences. Donnez à un modèle une user story avec ses critères d'acceptation et demandez-lui d'énumérer les scénarios, y compris les cas limites et les cas négatifs qu'un analyste fatigué saute un vendredi à seize heures. Le résultat est un brouillon, et sa valeur tient à la couverture des possibilités plutôt qu'à la formulation. La qualité de la sortie suit celle des critères d'acceptation presque exactement.
• La maintenance du parc automatisé. C'est l'usage le plus rentable et le moins commenté. Une refonte du front casse quarante sélecteurs, et les réparer à la main représente une semaine de travail qui n'apprend rien à personne. Un modèle qui lit le diff et les traces d'échec propose les corrections, un testeur relit et intègre. Les équipes qui commencent par là voient l'effet dès le premier sprint, parce qu'elles s'attaquent au bouchon qui bloquait tout le reste.
• Le triage des anomalies. Est-ce un doublon d'un ticket ouvert il y a onze mois avec d'autres mots. À quel composant la rattacher. Quelle sévérité ont reçu les anomalies voisines. Quel commit récent touche le chemin de code de la stack trace. Les modèles sont réellement bons là-dessus, et le triage est l'endroit où les grandes organisations perdent des jours par semaine en aiguillage plutôt qu'en correction.
• Les jeux de données de test. Produire des données réalistes, variées, hors production, qui respectent l'intégrité référentielle et les contraintes de confidentialité, c'est du travail manuel lent avec une spécification claire, donc un bon terrain. Les données générées couvrent aussi des distributions de valeurs qu'un jeu fabriqué à la main n'atteint jamais, ce qui fait remonter des défauts à soi seul.
• L'appui aux tests exploratoires. Un modèle qui lit le journal des modifications et les six derniers mois d'anomalies peut proposer où regarder cette semaine. L'exploration reste humaine. La lecture de l'historique n'a pas à l'être.

Là où elle n'a rien à faire, et pourquoi l'oracle compte.

Un oracle, c'est ce qui vous dit quel devrait être le résultat correct. Un modèle à qui l'on demande d'écrire des tests pour du code existant lit ce code et en déduit le comportement attendu, donc il écrit des tests qui passent. Le bug installé depuis deux ans dans une règle d'arrondi devient la spécification, et il dispose maintenant d'un test au vert pour le défendre.

Un test généré encode le comportement que le code a déjà, bug compris.

Voilà la frontière. Générer depuis les exigences est utile, générer depuis l'implémentation est un piège, et aucun modèle ne vous dira lequel de deux comportements plausibles le métier voulait réellement. Trois autres domaines restent aux personnes. L'appréciation du risque, puisque décider quoi tester avec un temps fini avant une mise en production suppose de savoir quelles défaillances l'organisation peut absorber, et c'est une conversation métier. La recette et la signature, puisqu'un verdict produit par un modèle que personne n'a relu n'est pas un verdict, et qu'aucun régulateur, auditeur ou client ne le traitera comme tel. Et les tests non fonctionnels, où performance, résilience et sécurité reposent sur une connaissance de l'infrastructure, une modélisation réaliste de la charge et un raisonnement sur les menaces. Les modèles aident à rédiger des scénarios et à lire des résultats. Ils ne remplacent pas l'ingénierie.

Le piège : plus de tests que vous ne pouvez en maintenir.

Toutes les équipes que nous avons vues adopter la génération font le même geste au premier trimestre. La couverture devient l'objectif, le parc double, le temps d'exécution double avec lui, l'instabilité augmente puisque les tests générés sont plus fragiles que ceux écrits à la main, et en deux sprints les échecs sont de nouveau ignorés. L'équipe vient d'industrialiser exactement le problème dont elle partait. Quatre règles tiennent ce risque.

• Plafonnez le parc. Fixez un temps d'exécution maximal pour la chaîne d'intégration et traitez-le comme une contrainte dure. Ajouter un test suppose de le justifier ou d'en retirer un autre.
• Relisez chaque test généré comme du code. Même pull request, même relecteur, même exigence. Un test généré que personne n'a lu est de la dette technique avec une coche verte.
• Supprimez sans état d'âme. Les tests qui n'ont jamais échoué en dix-huit mois, ou qui échouent pour des raisons étrangères au comportement qu'ils prétendent vérifier, coûtent plus qu'ils ne rapportent.
• Videz la quarantaine avant de générer. Si un tiers du parc est déjà ignoré, la génération ajoute du bruit au bruit. Réparez d'abord, étendez ensuite.

Ce que le testeur conserve.

Le métier devient plus intéressant et plus exigeant, ce qui n'est pas la même chose que plus confortable. Le temps se déplace de l'écriture et de la réparation vers trois choses : concevoir ce qui doit être testé et pourquoi, relire une production qui arrive plus vite qu'on ne peut la lire distraitement, et tenir la conversation sur le risque avec le produit et l'ingénierie.

Deux manques de compétence apparaissent immédiatement. Le premier est la relecture en volume, savoir-faire qui s'apprend et qu'on n'enseigne presque jamais : ce qu'il faut chercher dans un cas généré, repérer un test qui n'affirme rien, reconnaître une assertion qui recopie l'implémentation. Le second est la littératie de l'évaluation, moins affaire de formulation habile que de capacité à écrire une spécification assez précise pour être vérifiable, et c'est la discipline décrite dans la suite d'évaluation. Les testeurs en difficulté sont ceux dont la valeur venait du volume d'exécution manuelle. Ceux qui s'épanouissent sont ceux qui demandaient déjà pourquoi une fonctionnalité existe.

Ce qu'il faut mesurer.

Le nombre de tests et le pourcentage de couverture montent dès l'allumage de la génération, et ils ne disent rien de la qualité du test. Cinq mesures parlent.

• Le délai jusqu'à un verdict fiable. Du code terminé à un résultat que l'équipe suit sans conversation parallèle. C'est le chiffre autour duquel tourne tout l'exercice.
• Le taux de défauts échappés. Anomalies découvertes en production par version, segmentées par sévérité. S'il monte pendant que le nombre de tests monte, le parc teste les mauvaises choses.
• La part en quarantaine. Proportion du parc actuellement désactivée, en échec ou ignorée. Une quarantaine qui grossit est le signal le plus net que la génération dépasse la maintenance.
• L'effort de maintenance. Heures passées à réparer des tests par sprint, relevées avant et après. C'est là qu'apparaît le premier gain réel.
• La charge de relecture. Temps consacré à relire les artefacts générés. Un gain qui se contente de déplacer le travail de l'écriture vers la relecture n'est pas un gain, et c'est la mesure que les équipes oublient de prendre.

Établissez les cinq mesures avant l'arrivée du premier outil. Reconstituer une base après coup relève de la devinette, et cela rend le business case final indéfendable dans le mauvais sens.

Un premier trimestre qui fonctionne.

Commencez par la maintenance, pas par la génération. Pointez le modèle sur les tests en échec et en quarantaine, réparez le parc, ramenez la chaîne à un état où un build rouge veut dire quelque chose. Cela seul change le rapport de l'équipe à son propre outillage, et cela prend des semaines et non des trimestres.

Ajoutez ensuite le triage, peu risqué et immédiatement rentable. Puis la génération de conception à partir des critères d'acceptation, sur une seule squad, avec relecture obligatoire et parc plafonné. N'étendez à une deuxième squad que lorsque la première a tenu son temps d'exécution et sa part de quarantaine sur un sprint complet. Faites tourner l'ensemble dans votre gestionnaire de sources et votre chaîne d'intégration, avec les mêmes portes de relecture que le code de production. Un outillage de test qui vit à côté du flux d'ingénierie se dégrade en silence, et la dégradation reste invisible jusqu'à la mise en production qui tourne mal.

Ce que nous faisons.

Nous menons des audits QA et des programmes d'augmentation : lecture de votre parc actuel et de sa quarantaine, passe de réparation, triage et génération installés dans votre chaîne avec des portes de relecture, la base de mesure ci-dessus, et la formation en promotions qui rend vos testeurs rapides à la relecture plutôt que dépendants d'un outil. Nos équipes tech factory travaillent dans votre architecture et transmettent la méthode.

L'équipe Consulting de nos bureaux de Paris, Dubaï, Singapour et Bali est joignable depuis le formulaire ci-dessous. Nous répondons sous un jour ouvré, avec le partner qui suivra le dossier.