Claude Code et 11 Agents : Comment une équipe QA a automatisé jusqu'à 80% de la routine de test

Une équipe d'assurance qualité a démontré que les agents IA pouvaient déjà assumer la majeure partie du travail de test routinier : de la lecture des exigences et de la conception des scénarios de test au chargement des cas de test dans TMS et à la création de Merge Requests avec des autotests prêts à l'emploi. Plutôt que d'élargir son personnel avec deux testeurs supplémentaires, l'équipe a construit un « exosquelette » de 11 agents spécialisés basé sur Claude Code et affirme qu'il couvre jusqu'à 80% du travail opérationnel d'un ingénieur QA. Ils sont partis d'un problème typique des équipes de produits : le développement lance de nouvelles fonctionnalités plus vite que les tests ne peuvent convertir les exigences en scénarios, données et automatisation.

Selon une évaluation interne, environ 20% du temps QA est consacré à l'analyse des exigences et à la conception des tests, 15% à la création de cas dans TMS, 10% à la préparation des données, 25% à l'automatisation, puis viennent les vérifications elles-mêmes, la régression et les rapports. Au total, jusqu'à 80% de la charge de travail peut être décrite par des règles et décomposée en étapes répétables. D'où l'idée : ne pas remplacer l'ingénieur, mais le transformer en opérateur de pipeline qui définit la tâche, contrôle les artefacts et n'intervient que là où le système manque de contexte ou doit prendre une décision ambiguë.

L'architecture est construite comme une chaîne modulaire de 11 skills et d'un orchestrateur séparé. Un agent extrait la tâche de Jira et les matériaux connexes de Confluence, un autre décompose les exigences en User Stories et tâches, un troisième génère des scénarios de test selon les règles ISTQB, les suivants gèrent les données manquantes, les divergences, les sélecteurs DOM, les autotests API et interface utilisateur, comparent les scénarios avec le code, chargent les cas dans Zephyr Scale et créent des Merge Requests dans GitLab. Des scénarios JSON avec traçabilité complète aux exigences et critères d'acceptation servent de source unique de vérité, tandis qu'une matrice de couverture RTM est construite en parallèle.

Pour la partie frontend, le système accède également à Figma via MCP et extrait non seulement des captures d'écran, mais la structure de l'interface, les états des éléments et les contraintes. Un accent spécial a été mis sur la qualité et la protection contre les points faibles typiques des LLM. Après la génération de scénarios, l'orchestrateur exécute des points de contrôle de qualité : vérification du schéma JSON, complétude des étapes, priorités, absence de doublons et couverture des exigences.

Après la génération des autotests, le contrôle devient encore plus strict : le code Python, les fixtures et l'exécution réelle des tests sont validés. Un schéma de débogage à deux étapes est utilisé. D'abord, le système exécute chaque test séparément et différencie les problèmes de code de test des défauts réels du produit.

Ensuite, le test de mutation intervient : sur un test déjà réussi, l'assert est inversé, et s'il reste quand même vert, ce test est considéré comme vide et nécessite un affinement. Une autre couche importante est le protocole de conflits entre Jira, Figma, le texte des exigences et le comportement réel de l'interface. Les conflits évidents sont résolus automatiquement par hiérarchie de priorité des sources, tandis que les cas contestés sont escaladés à l'ingénieur.

En pratique, le pilote sur un mois et demi a fourni des chiffres qui justifient généralement le lancement de telles expériences. Le nombre de cas de test de régression a augmenté d'environ 50 à 400, le détail des scénarios est devenu complet, et la couverture de régression par automatisation a approché 100%. Le temps de régression lui-même a été réduit d'environ un jour à des dizaines de minutes, le chemin de la fin du développement à l'approbation QA de plusieurs jours à quelques heures, et l'intégration des tests sur un nouveau projet prend désormais environ quatre heures de configuration au lieu de mois pour l'embauche et l'adaptation.

De plus, le système a commencé à trouver plus de contradictions d'exigences cachées et de bugs que le processus manuel. Pendant ce temps, la version pilote fonctionne sur un abonnement Claude Pro pour 100 dollars par mois et, selon les affirmations, est capable de servir 2–3 projets avec plus de 100 tests par mois pour chacun. La principale conclusion de cette étude de cas est que le rôle d'assurance qualité commence vraiment à passer de l'exécution manuelle à la gestion du contexte, des règles et de la qualité des décisions que prend l'IA.

Mais l'histoire ne fonctionne que sous certaines conditions : les exigences doivent être suffisamment complètes, le projet doit avoir une source appropriée de contexte comme les contrats d'API et les données de test, et le pipeline lui-même ne doit pas être une « boîte noire ». La valeur ici ne réside pas dans la génération magique de tests, mais dans une chaîne transparente d'étapes qui peuvent être réexécutées, vérifiées et progressivement renforcées. Si cette approche prend son envol au-delà des pilotos, le marché des tests pourrait obtenir non pas un remplacement pour les ingénieurs, mais un format beaucoup plus productif et évolutif pour leur travail.