Une banque passe aux tiny teams : l’IA écrit 90% du code, les agents prennent en charge 20% des tâches

La plupart des équipes utilisent déjà l’IA, mais surtout comme un outil d’autocomplétion intelligent : l’ingénieur écrit, le modèle suggère. Dans une banque, l’équipe Budget Tool, chargée de la gestion des dépenses, est allée plus loin. Elle a réorganisé son fonctionnement autour de petits groupes où chaque ingénieur porte la responsabilité du résultat de bout en bout, tandis qu’un agent s’occupe de la routine. Son tech lead, Dima Vdovin, a raconté sur Habr ce que cette expérience a donné. Un récit sans fard, avec ses échecs et ses effets secondaires désagréables.

Premier sprint : un échec utile

Au départ, deux équipes pluridisciplinaires dédiées aux fonctionnalités, pour un total de 14 personnes, avec Kotlin et Spring côté backend, TypeScript et React côté frontend. Pour le pilote, deux personnes ont été mobilisées, un développeur backend et un spécialiste QA, pendant deux mois. L’objectif : traiter une user story de bout en bout, de l’analyse à la mise en production.

La première petite tâche n’a pas atteint la production au bout de deux semaines. L’analyse des besoins a pris beaucoup de temps, mais c’est surtout le frontend qui a posé problème. L’équipe a tenté de fournir les maquettes Figma à l’agent, puis a multiplié les corrections pour répondre aux remarques de revue. Seuls le développeur frontend et le designer disposaient des licences Figma Dev Mode et du MCP correspondant. Il était donc parfois plus simple de montrer à l’agent une capture de l’écran finalisé.

Le rythme s’est ensuite accéléré : à chaque sprint, le cycle se raccourcissait. Mais les problèmes persistaient, tous liés au contexte :

• Les connaissances restent dans les têtes. Les conventions d’architecture se sont accumulées pendant des années. Tant qu’elles ne figurent pas dans le contexte de l’agent, il commet des erreurs.
• La revue ralentit le travail. Un ingénieur produit peine à évaluer du code dans un domaine qui n’est pas le sien, et le code s’écrit plus vite qu’il ne se vérifie.
• La manière de transmettre le design reste floue. Il faut un véritable canal entre la maquette et l’agent, plutôt qu’un assemblage de solutions de fortune.

Le harness comme produit

Ici, le harness désigne l’ensemble des règles, compétences (skills), MCP et éléments de contexte qui permettent à l’agent de travailler dans votre projet en particulier. L’équipe n’a pas réinventé la roue : elle a réutilisé les ressources déjà disponibles dans la banque et dans son domaine métier.

L’idée centrale repose sur une boucle continue : réaliser une tâche avec l’IA, analyser les points où l’agent a buté, enrichir ses compétences et son contexte, puis relancer. Des pôles d’expertise en ont la charge : backend, frontend, QA et analyse système. Ils recueillent les retours de toutes les tiny teams, repèrent les lacunes et diffusent les meilleures solutions aux autres équipes.

L’équipe a été répartie en quatre tiny teams et un discovery hub, qui réunit le product owner, le designer et l’analyste métier. L’absence d’analyste dans les tiny teams est délibérée : elle incite davantage à utiliser l’IA. Les tâches sont classées par couleur. Les vertes, de petite taille, sont confiées aux agents autonomes. Les jaunes, plus importantes, sont réalisées au sein de l’équipe, en local, avec l’aide de l’IA. Les rouges exigent une expertise approfondie et ne peuvent être résolues qu’en unissant les forces disponibles.

Des agents sur serveur et le prix des gains

Au début, tout se faisait en local : il est ainsi plus facile de recadrer l’agent par messages et d’acquérir de l’expérience. Mais un agent local ne travaille que tant que le portable reste ouvert. L’équipe veut en faire un ingénieur supplémentaire : lui attribuer une tâche dans l’outil de suivi et recevoir un MR prêt à être revu.

Elle a commencé par la sécurité. Lorsqu’un scan AppSec détecte une bibliothèque ou une image vulnérable, l’agent crée lui-même une tâche, apporte les modifications et prépare un MR. Au matin, plusieurs demandes sont prêtes pour la revue. Désormais, l’équipe lui confie aussi de petites tâches métier, lorsque les modifications à apporter, leur méthode et leur emplacement sont clairement définis.

Bilan après six mois : les LLM écrivent 90% du code, plus de 70% des tâches métier ont été réalisées en mode AI-assisted et les agents sur serveur en traitent plus de 20%. Mais le nombre de tâches terminées a d’abord diminué, puis des effets secondaires sont apparus :

• la charge cognitive et le risque d’épuisement professionnel augmentent ;
• sans connaissances dans les domaines voisins, impossible de définir la tâche ou de vérifier le résultat ;
• il faut repenser la revue : examiner l’architecture, plutôt que la syntaxe ;
• l’analyse et la planification restent à la charge de l’humain, qui doit prendre davantage de décisions.

Les enseignements à en tirer

Les conseils des auteurs sont concrets. Commencez par une tâche répétitive assortie de critères d’achèvement clairs. Utilisez des agents de développement existants plutôt que d’écrire le vôtre. Mettez d’abord le scénario au point en local, puis seulement déployez-le sur serveur. Encapsulez tout ce qui est déterministe dans des scripts appelés par un skill. Rédigez la documentation de façon à ce que les humains et les agents la comprennent de la même manière.

La réflexion sur les métriques d’évaluation est particulièrement précieuse : sans elles, impossible de savoir si le harness s’est amélioré ou si vous ne faites que modifier des réglages. Il mérite donc d’être géré comme un produit et d’être explicitement comptabilisé dans la dette technique.

Les limites comptent aussi. Il s’agit de l’expérience d’une seule équipe bancaire, avec une stack bien rodée. Les chiffres sont internes et n’ont été vérifiés par personne. Quant aux tâches d’analyse complexes, où une erreur aurait un coût élevé, elles ne sont pas encore confiées aux agents. Mais l’enseignement est universel : le gain de vitesse ne viendra pas d’un modèle plus puissant, mais de la capacité de votre équipe à expliquer à l’agent vos façons de travailler.