TCS a assemblé des agents de test pour les banques : 100 scénarios en 24 heures au lieu de 200

L'automatisation des tests accélère depuis longtemps l'exécution, mais touche à peine au reste. Les scénarios sont toujours imaginés par des humains, les scripts sont réécrits après chaque modification d'une user story, et un test en échec est analysé à la main. C'est précisément ce maillon de la chaîne que TCS a décidé d'automatiser pour ses clients des banques, de la finance et de l'assurance (BFSI). L'entreprise en a parlé avec AWS.

Un seul prompt ne suffit pas : il faut un pipeline

L'entreprise a formulé quatre exigences. Chaque test doit s'appuyer sur le contexte d'un projet précis. Le système doit couvrir à la fois les API et l'interface web dans le navigateur. Les données de chaque client doivent être isolées. Le chemin de l'exigence au rapport doit être reproductible d'une release à l'autre.

Un simple appel à un LLM n'offre pas ce niveau de contrôle. TCS a donc réparti le travail entre des agents, chacun avec ses propres outils, règles de validation et contexte. Le routage n'est pas confié au modèle, mais à un superviseur déterministe. Les agents sont écrits avec le Strands Agents SDK et s'exécutent dans Amazon Bedrock AgentCore Runtime.

Voici la répartition des rôles :

• l'agent générateur construit les scénarios, les convertit en Gherkin et écrit des tests automatisés en Java ou Python ;
• l'agent de chat distingue une question d'une demande de modification d'un artefact, et soit répond, soit corrige ;
• l'agent de tâches transforme un BRD en user stories avec critères d'acceptation ;
• l'agent incrémental complète les tests le long d'une chaîne de tickets Jira liés, au lieu de repartir de zéro ;
• l'agent d'exécution lance les tests, classe les échecs et enregistre le résultat.

Le contexte est récupéré depuis Amazon Bedrock Knowledge Bases : Jira, BRD, Swagger, code, locators et données de test. Les résultats sont filtrés par client, projet et session, de sorte que les connaissances d'un client n'atterrissent pas dans les tests d'un autre. Pour l'UI, un service dédié basé sur Puppeteer construit, à partir d'une URL et d'un objectif textuel, une description de scénario et des locators XPath.

Fonctionnement du lancement et de l'auto-réparation

L'agent d'exécution détermine lui-même le type de test à partir du code. Les tests d'API tournent sur ECS avec Fargate. Les tests Selenium tournent sur ECS au-dessus d'EC2, où Chrome fonctionne avec un écran virtuel, et l'enregistrement via FFmpeg est diffusé vers S3 et CloudFront.

La boucle de correction des erreurs est décrite comme un graphe LangGraph avec un ordre d'étapes strict : récupérer, exécuter, corriger, enregistrer. Le nombre de tentatives est limité. Si l'échec est classé comme une erreur de code, un agent distinct reçoit un contexte réduit et propose une correction ciblée. Des contrôles de sécurité rejettent les fichiers vides, les nouveaux fichiers inattendus et les hausses brutales de taille. Les erreurs d'environnement, par exemple les pannes réseau ou d'authentification, ne sont jamais autorisées à déclencher une correction du code. C'est la réponse à la crainte principale : l'agent ne doit pas « réparer » un test uniquement pour qu'il passe.

Isolation des clients et résultat

La plateforme est multi-locataire. La couche de gestion commune comprend EKS, un registre et un portail d'administration. Chaque client dispose de son propre namespace Kubernetes, de son pool Cognito, de sa clé KMS, de son bucket S3, de ses tables DynamoDB et de sa base de connaissances. L'onboarding passe par EventBridge et CodeBuild avec AWS CDK, ce qui rend le déploiement d'un nouveau client reproductible. Les secrets Jira et GitLab sont stockés dans Secrets Manager, WAF, NetworkPolicy et ResourceQuota s'y ajoutent, et OpenTelemetry collecte la traçabilité des agents.

Sur une charge représentative d'environ 100 scénarios, le processus manuel prenait environ deux heures par scénario, soit 200 heures. Avec l'orchestrateur, on arrive à environ 14 minutes par scénario, soit 24 heures. C'est 88 % d'effort en moins.

Limites et points à retenir

Le chiffre provient du benchmark interne de TCS, et les délais dépendent de la complexité de l'application et de l'équipe. Il s'agit d'une publication conjointe avec AWS, qui vend aussi la solution via son Marketplace. Il n'y a pas de vérification indépendante, ni de données sur la part des tests que les ingénieurs réécrivent malgré tout.

La leçon pratique dépasse le QA bancaire. Pour les processus réglementés, le schéma qui fonctionne est celui où le modèle ne pilote pas le processus, mais exécute des étapes ciblées. Le routage est déterministe, le nombre de tentatives est limité, les erreurs d'environnement sont séparées des erreurs de code, et l'isolation des données est intégrée à l'infrastructure. Si vous construisez des agents pour un processus de bout en bout, commencez par ces garde-fous, et choisissez le modèle ensuite.