L’IA agentique a besoin de plus de testeurs, pas de moins

L’IA agentique transforme la manière dont les logiciels sont livrés. Les assistants préparent des demandes de fusion, les agents lancent des migrations et les robots de revue affirment qu’une modification est sans risque avant même qu’un humain ait fini son café. Le secteur présente souvent cette évolution comme un moyen de réduire les effectifs dans le domaine de la qualité. C’est une vision à l’envers. Plus les machines écrivent une part importante du code, plus la compétence rare n’est pas la génération, mais la vérification indépendante.

L’enquête 2025 Stack Overflow auprès des développeurs a révélé que 84 % des répondants utilisent ou prévoient d’utiliser des outils d’IA dans le développement, et que 51 % des développeurs professionnels y ont recours chaque jour. Le sentiment positif est tombé à 60 %, et les développeurs sont plus nombreux à se méfier activement de la précision de l’IA (46 %) qu’à lui faire confiance (33 %). La principale source de frustration, citée par 66 % des répondants, était la production de solutions presque justes, mais pas tout à fait. Les recherches DORA 2025 de Google Cloud ont fait état d’un taux d’adoption de l’IA de 90 % parmi les professionnels du développement logiciel ; plus de 80 % estimaient que l’IA avait amélioré leur productivité, mais seulement 24 % déclaraient lui faire très largement ou énormément confiance. Quand l’IA est utile sans inspirer confiance, le travail des testeurs s’élargit au lieu de diminuer.

La vitesse ne prouve rien

Je suis ingénieur qualité logicielle et je me consacre aux tests des systèmes agentiques et aux contrôles CI pour le code généré par l’IA. En interne, nous avons déployé un outil de revue des demandes de fusion et un générateur de cas de test. Ce sont tous deux des outils de préparation. Aucun n’évalue son propre travail. Cette règle est importante, car les agents s’expriment avec assurance. L’assurance ne garantit pas l’exactitude.

Nous l’avons appris à nos dépens. Lors d’un projet pilote d’outil de revue des demandes de fusion développé avec l’IA, une modification a passé la CI en moins de 4 minutes. Deux jours plus tard, un tableau de bord en aval affichait des températures impossibles. Une inversion de la conversion Celsius-Fahrenheit se trouvait sur un chemin de code que la suite de tests n’avait jamais exercé. Le pipeline était au vert. Le produit, lui, était erroné. Une CI au vert qui ne pose jamais la question difficile, c’est du théâtre.

Cet incident s’inscrit dans une tendance plus générale. Le rapport de CodeRabbit État de la génération de code par l’IA et par les humains a analysé 470 demandes de fusion GitHub issues de projets open source (320 coécrites avec l’IA, 150 écrites uniquement par des humains). Les modifications rédigées par l’IA ont généré environ 1,7 fois plus de problèmes au total, avec des problèmes de logique et d’exactitude 75 % plus fréquents et jusqu’à 2,74 fois plus de failles de sécurité. Le rapport 2026 de Veracode sur la sécurité du code généré par l’IA, Rapport sur la sécurité du code généré par l’IA, a évalué des modèles sur différentes tâches de sécurité et constaté un taux moyen de réussite de 56 % aux tests de sécurité, à peine différent des 55 % du rapport précédent, tandis qu’environ 44 % des tâches de génération de code par l’IA introduisaient une vulnérabilité connue. La syntaxe est presque un problème résolu. Un comportement sûr et correct, non. Les testeurs sont ceux qui refusent de confondre les deux.

Les dépendances hallucinées sont un problème de test

La génération invente aussi des paquets. Une étude présentée à USENIX Security 2025, Un paquet pour vous !, a évalué les hallucinations de paquets dans 16 grands modèles de langage capables de générer du code, à partir de 576 000 échantillons. Les modèles commerciaux ont halluciné des paquets en moyenne au moins 5,2 % du temps ; la moyenne atteignait 21,7 % pour les modèles open source, avec 205 474 noms inventés uniques. La persistance de ces paquets fantômes crée une cible toute désignée pour le squattage de noms de paquets générés par l’IA : des attaquants enregistrent le nom inventé et attendent qu’un développeur ou un agent l’installe.

Les contrôles de provenance des dépendances doivent être au même niveau que les tests fonctionnels. Si un agent invente un paquet NuGet ou npm, la fusion doit échouer avant même que quiconque débatte du caractère approfondi des tests unitaires. La vérification de la provenance n’est pas une mesure d’hygiène facultative : c’est un contrôle qualité pour les modifications rédigées par l’IA.

Des contrôles qui passent à l’échelle avec les agents

Lorsqu’avec l’aide de l’automatisation par l’IA, nous avons mené à l’échelle de toute l’organisation une mise à niveau de .NET 8 vers .NET 10 en environ deux semaines, j’étais responsable des contrôles qualité. Le gain de vitesse était réel. Le besoin de vérifications qui ne se contentent pas de croire le résumé de l’agent l’était tout autant. Voici les contrôles que j’applique au code modifié :

• Des objectifs de score de mutation compris entre 60 % et 70 % pour la logique modifiée, afin que la suite de tests élimine de vrais mutants au lieu de simplement couvrir des lignes
• Des tests fondés sur les propriétés pour la logique à haut risque, lorsque les seuls exemples ne spécifient pas suffisamment le comportement
• Des contrôles de provenance des dépendances pour contrer le squattage de noms et les paquets hallucinés
• Des indicateurs de duplication et de volatilité du code pour repérer les réécritures répétitives dues aux agents
• Une vérification indépendante des affirmations des agents, comme « migration terminée », car toute affirmation reste une hypothèse tant qu’elle n’est pas étayée par des preuves

Le score de mutation n’est pas un indicateur de vanité : il permet de vérifier si vos tests détectent une faute délibérée. Le taux de couverture peut augmenter alors que la suite de tests passe toujours à côté du chemin Celsius. Les tests fondés sur les propriétés obligent le modèle du système à tenir sur toute une plage de valeurs, et pas seulement dans un scénario idéal. Les contrôles de provenance ferment la réserve de paquets. La volatilité et la duplication permettent de repérer la tendance des agents à reformuler trois fois la même idée. Ensemble, ces pratiques définissent une posture : partir du principe que l’agent se trompe jusqu’à ce que la suite de tests prouve le contraire. Je garde cette règle de calibration à l’esprit lors des revues.

Rien de tout cela ne remplace les tests d’API, les tests d’authentification, les tests de fumée ou l’automatisation de l’interface utilisateur. FlaUI et PowerShell détectent toujours les problèmes que les API ne révèlent pas. Le conditionnement avec NuGet, MSI et MSM nécessite toujours une validation de l’installation et du parcours d’installation silencieuse. Les flux de travail agentiques amplifient le volume. Ils ne rendent pas ces disciplines obsolètes.

Plus de testeurs, un travail différent

La crainte, c’est que les agents écrivent les tests et que les humains deviennent facultatifs. Les agents peuvent rédiger des scénarios de test. Ils ne devraient pas certifier leurs propres ébauches. Les répondants de Stack Overflow qui prévoient d’utiliser l’IA pour les tests à l’avenir accordent toujours une place centrale à la méfiance humaine : lorsqu’ils demanderaient de l’aide à quelqu’un d’autre, la principale raison invoquée était qu’ils ne faisaient pas confiance aux réponses de l’IA. Cet instinct est un atout pour la profession.

Il est important, dans ce contexte, de recruter et de donner les moyens d’agir à des personnes aux parcours atypiques. Je me suis orientée vers la qualité après une carrière dans les opérations RH et les données, j’ai obtenu une maîtrise en systèmes d’information à UMBC en mai 2024, et je consacre aujourd’hui mes journées à rendre les contrôles de validation de l’IA agentique opérationnels. L’IA agentique n’attendra pas que tout le monde ait le même parcours. Elle a besoin de davantage de personnes capables de concevoir des éléments probants, et non de moins de personnes qui approuvent machinalement les builds réussis.

La question du produit est simple. Si les agents sont déployés plus vite que vos processus de vérification ne peuvent réfléchir, vous ne gagnez pas en productivité. Vous ne faites que reporter un incident. Investissez dans des testeurs qui considèrent chaque affirmation d’un agent comme suspecte, intègrent les tests de mutation et la traçabilité à l’intégration continue (CI), et préservent leur jugement indépendant là où le modèle s’exprime avec le plus d’aisance et se montre le moins fiable. L’IA agentique a besoin de davantage de testeurs, et non de moins.