Alfa-Bank transforme l'idée d'un testeur en générateur de stubs par IA pour les équipes de test

Un testeur d'Alfa-Bank a conçu un outil d'IA interne qui transforme une description textuelle en stubs d'API prêts à l'emploi pour tester des services. Le projet est né comme une expérience menée en soirée au sein de la communauté d'IA, avant de devenir un MVP, avec un domaine dédié et des tests au sein de la banque.

Comment le projet est né

L'histoire commence au printemps 2025, quand l'ingénieur de test Stas Zaitsev décide d'approfondir le sujet des réseaux de neurones et de voir comment les appliquer au travail quotidien de QA. Après plusieurs expériences, dont un bot Telegram pour évaluer l'anglais, il rejoint la communauté d'IA interne autour de la plateforme AlfaGen.

Lors d'une réunion, les participants ont découvert une liste d'idées utiles que les équipes n'avaient pas encore eu le temps d'aborder. L'une d'elles correspondait à une tâche bien connue des testeurs : créer automatiquement des stubs d'API.

L'idée était pragmatique et très concrète. Quand le frontend est prêt mais que le backend est encore en développement, les tests sont souvent freinés faute de réponses fonctionnelles du service. Les stubs règlent ce problème, mais leur préparation demande du temps, une configuration manuelle et une bonne compréhension de l'infrastructure.

Les exigences métier du nouvel agent décrivaient un scénario simple : l'utilisateur définit les conditions, le système précise les détails et fournit le code d'un stub utilisable immédiatement dans les tests, sans longue préparation.

Comment fonctionne le générateur

Zaitsev a réalisé la première version très vite dans l'« Atelier de prompts » d'AlfaGen : il a configuré un scénario qui générait le code du stub à partir d'une description. Mais ce format s'est révélé peu pratique pour un usage réel et passait mal à l'échelle auprès de collègues sans formation technique. Un long dialogue dans le chat, un lancement manuel et la nécessité de comprendre les détails en faisaient plus une démonstration de l'idée qu'un outil pour le quotidien des équipes de QA. D'où la nécessité d'une deuxième version, dotée d'une interface dédiée et d'un lancement automatique.

«

Le projet devait prendre 3 mois, mais je ne le savais pas et j'ai tout fait en une soirée ».

Dans la deuxième version, l'auteur a bâti un véritable agent en trois parties : WireMock pour exécuter les stubs, une couche d'API en Kotlin et Spring AI pour assurer la liaison avec l'interface web d'AlfaGen, et une UI utilisable sans connaissances approfondies en programmation.

L'utilisateur décrit simplement le scénario voulu dans une fenêtre de chat, par exemple quelles réponses renvoyer pour différents userId, si un délai est nécessaire et quand renvoyer une erreur 404. Le système enchaîne ensuite plusieurs étapes :

• il détermine le type de stub : REST ou SOAP
• il choisit la méthode HTTP appropriée
• il calcule combien de stubs distincts sont nécessaires selon les conditions
• il génère le code et en vérifie les erreurs
• il déploie le résultat dans WireMock

Selon l'auteur, le cycle complet prend 10 à 15 secondes, après quoi le stub peut être branché dans l'environnement de travail. Pour ceux qui veulent un contrôle total, l'interface conserve aussi un mode manuel, où les paramètres se définissent un par un.

L'outil est ainsi utile aussi bien aux ingénieurs expérimentés qu'aux testeurs qui ne veulent pas perdre de temps à assembler et lancer des mocks à la main. Concrètement, l'agent décharge l'utilisateur de presque toute la mécanique routinière.

Du MVP au lancement

Le prototype de soirée est vite devenu un MVP de deux semaines, puis un véritable produit interne. Après une présentation lors d'une démo de la plateforme AlfaGen, d'autres équipes de la banque se sont intéressées à l'outil, et le développeur a rejoint un groupe qui travaille à plein temps sur les agents de QA.

Le projet a ensuite été amené au niveau de la production : mode chat, dossiers par projet, groupes de stubs avec logique, corrections issues des retours de collègues et parcours utilisateur plus pratique. Fin novembre, l'équipe avait réglé les problèmes critiques et commencé à préparer un lancement plus large.

La solution a reçu un domaine dédié, les accès ont été configurés, le frontend a été réécrit avec les bibliothèques internes de la banque et la documentation a été préparée. Le générateur est aujourd'hui testé par des groupes témoins au sein de la banque, tandis qu'une version locale sert déjà sur des tâches réelles dans des produits destinés aux petites entreprises.

Au fond, c'est un exemple de la manière dont une plateforme d'IA interne transforme la difficulté d'un ingénieur en service applicatif pour toute une organisation.

Ce que cela signifie

L'histoire d'Alfa-Bank montre que des outils d'IA utiles au développement peuvent naître non seulement dans des équipes de R&D dédiées, mais aussi par le bas, à partir d'un problème concret des testeurs. Si ces projets sont rapidement dotés d'une interface, d'une documentation, de standards internes et d'un vrai pilote, ils cessent d'être une démonstration des capacités des LLM et deviennent un outil de travail qui fait gagner des heures à toute l'équipe et accélère l'arrivée de nouveaux services en phase de test.

Pour l'IA en entreprise, cela compte davantage que n'importe quelle belle démo.