Un agent IA sous GPT-5.5 a passé au crible 2600 tests automatisés de TravelLine en deux semaines

Ilsur Mingazov, testeur chez TravelLine, a mené en deux semaines avec un agent IA l'audit des tests automatisés de la plateforme destinée aux hôtels. L'analyse sémantique a porté sur environ 2600 tests, issus d'une base de 6500 scénarios E2E, tandis que les statistiques d'exécution ont été collectées sur l'ensemble de la base. Le déclencheur : la migration planifiée des tests de Java vers .NET. L'équipe a jugé qu'un transfert « tel quel » embarquerait dans la nouvelle stack les 15 années de dette technique accumulées. Au final, environ 450 tests obsolètes ont été supprimés dans la section des tests par captures d'écran, et des tâches de tests d'intégration ont été créées pour plusieurs sections.

L'environnement de l'agent : code, MCP et choix du modèle

Une simple liste de noms de scénarios issue du TMS ne suffisait pas pour ce travail : l'équipe a donc fourni à l'agent un contexte complet. L'environnement de travail se composait des éléments suivants :

• OpenCode — l'environnement dans lequel l'agent travaille.
• Dépôts locaux — des clones du produit et du projet de tests automatisés. L'agent parcourt lui-même les dossiers, cherche méthodes et classes et met en correspondance les appels, sans rien copier manuellement dans le contexte.
• TestIT via MCP — l'équipe a d'abord essayé des requêtes directes à l'API, puis est passée à un serveur MCP. L'agent appelle des outils prêts à l'emploi, et le serveur récupère les entités, les métadonnées et les exécutions.
• GPT-5.5 — le modèle choisi dans le catalogue d'OpenCode. Les versions Flash allégées ont été écartées d'emblée : sur la mise en correspondance de l'architecture et de la logique complexe, elles perdaient des détails. GPT-5.5 a tenu un long prompt contenant les règles de la pyramide de tests, appelé les outils MCP avec précision et n'a pas inventé de liens entre tests et code.
• Prompt système et contrat de réponse — les critères de séparation entre E2E et integration, plus un format de rapport en markdown strict, sans remplissage.

Le premier test a porté sur l'agent lui-même. Face à la demande d'analyser une section, il a renvoyé une liste incomplète. Les logs de raisonnement ont montré qu'il s'appuyait sur les jeux de tests (suites), alors que le testeur attendait l'arborescence des sections et sous-sections. Une capture d'écran de l'arborescence et une explication détaillée de l'origine des tests ont réglé le problème. La marche à suivre a ensuite été fixée dans les instructions de l'agent.

Première itération : migrer, descendre d'un niveau ou ne pas toucher

Dans skill.md, chaque test devait recevoir l'une des trois étiquettes suivantes :

• MIGRATE_TO_NET — scénario pertinent, migré à l'identique vers le framework .NET ;
• SHIFT_TO_INTEGRATION — logique métier ou API qu'il convient de confier aux développeurs backend sous forme de tests d'intégration ;
• OBSOLETE_OR_BROKEN — fonctionnalité supprimée ou modifiée, test cassé, doublon d'un autre test ou vérification UI superflue ; non migré.

L'agent rattachait à l'E2E le happy path critique, les parcours utilisateur de bout en bout, les enchaînements de sous-systèmes, la navigation et l'affichage. À l'integration, il rattachait les calculs, la validation des combinaisons de données, l'enregistrement des paramètres et les limites, c'est-à-dire tout ce que le navigateur ne fait que ralentir.

La section Transfers en offre un exemple parlant. Sur 18 tests E2E, l'agent a rapproché les scénarios des tests d'intégration existants et constaté que 15 d'entre eux reproduisent des vérifications de niveau inférieur, mais à un coût plus élevé et avec un risque accru d'échecs instables. Résultat : 3 tests en MIGRATE_TO_NET, 0 en SHIFT_TO_INTEGRATION, 15 en OBSOLETE_OR_BROKEN. Un transfert direct aurait ajouté 15 scénarios superflus sur .NET : un temps d'exécution plus long, davantage d'échecs à analyser et plus de code à maintenir.

Deuxième itération : P85 sur les échecs et la durée

Le code ne dit pas à quelle fréquence un test échoue ni combien de temps il dure en réalité. Pour chacun des ~6500 tests, l'équipe a donc demandé à TestIT jusqu'à 100 derniers résultats, puis les a regroupés par section. Deux indicateurs ont été calculés :

• fail rate — la part de résultats Failed dans le total, par exemple 10 sur 100 donne 10% ;
• P85 de la durée — calculé sur les exécutions au statut Passed ; les tests échoués n'ont pas été pris en compte, pour que les timeouts ne faussent pas l'analyse.

Au sein de chaque section, les seuils P85 ont été calculés pour les deux indicateurs, ce qui a donné quatre groupes : uniquement les échecs fréquents, uniquement les tests longs, l'intersection et le reste. L'intersection a été traitée en premier. Un test long n'est pas forcément mauvais, et des échecs fréquents peuvent s'expliquer par le produit ou l'environnement. Les statistiques ont servi à constituer une file d'analyse, pas à rendre un verdict.

Dans la section reports, l'agent a dénombré 245 tests, 24 051 exécutions et 1598 échecs, soit un fail rate de 6,6%. Pour les échecs seuls, 29 tests entrent dans la zone problématique ; pour la durée seule, 28 ; pour les deux critères à la fois, 9. Pour ces neuf tests, l'agent a préparé un rapport au format DOCX et Markdown (passed / failed / P85 passed en secondes) :

• modification des paramètres d'une commande — 87 / 11 / 131,0 ;
• annulation d'une opération avec recalcul partiel — 86 / 11 / 102,0 ;
• filtrage des données par paramètres — 88 / 10 / 308,0 ;
• vérification du fuseau horaire dans les rapports — 78 / 10 / 170,9 ;
• vérification de la périodicité dans les exports — 75 / 11 / 162,0 ;
• confirmation du statut d'une entité — 74 / 11 / 144,1 ;
• finalisation de la commande — 75 / 9 / 169,8 ;
• envoi de notifications transactionnelles — 70 / 19 / 240,1 ;
• traitement du paiement et exécution du remboursement — 63 / 33 / 253,7.

Ce que les autres équipes peuvent en retenir

Le rôle de l'humain n'a pas changé : fixer les critères, vérifier les conclusions de l'agent et débattre des cas complexes avec les développeurs. L'agent a pris en charge la recherche de fichiers, la lecture du code, la mise en correspondance des vérifications et la collecte des statistiques. Le résultat n'est pas un rapport, mais un ensemble de tâches. L'équipe a supprimé les doublons, éliminé environ 450 tests par captures d'écran, créé des tâches pour les tests d'intégration et pour la migration des scénarios validés, et placé les autres sections dans la file de discussion.

Pour les équipes dotées d'une grande base de tests, la leçon est pratique. L'agent a besoin d'un accès au code et au système de gestion des tests via MCP, pas d'un export de noms. Les étiquettes de décision apportent plus que des descriptions, et la vérification initiale de l'agent mérite d'être prévue dans le plan. Il est raisonnable de traiter en premier les tests à la fois longs et instables. Un agent configuré avec des règles d'analyse reste dans l'équipe et peut analyser les échecs, rechercher la couverture existante et évaluer de nouveaux scénarios sans reconstituer le contexte.