Comment je livre du code en production avec une équipe d'agents IA

L'IA écrit du code plus vite que n'importe qui. Ce n'est plus la partie difficile depuis un moment. La partie difficile, c'est la confiance : savoir que ce que l'agent a écrit est correct, sûr, et le restera après les dix prochains changements.

Sur un terminal de trading en production, « ça a l'air bon » ne suffit pas. Je n'utilise donc pas un seul assistant IA. Je fais tourner un petit pipeline d'agents spécialisés, chacun avec une seule mission, des règles écrites, et aucune permission de noter son propre travail. Voici comment ça marche.

Le pipeline en un coup d'œil

Un ticket est cadré à partir du contrat d'API.
Des agents développeurs le construisent en parallèle, chacun dans son propre worktree git.
Des contrôles stricts tournent avant tout push.
Un agent relecteur adverse essaie de casser le changement.
Une boucle de revue IA tourne jusqu'à zéro problème.
Je relis et je valide.

Chaque étape existe parce que quelque chose a mal tourné sans elle.

1. Le contrat fait foi

Les tickets sont écrits par des humains, et les humains sont vagues. Un contrat OpenAPI, non. Chaque agent lit le contrat sur la branche exacte où il travaille, et pas sur ce qui se trouve être sorti en local. Quand le ticket et le contrat ne sont pas d'accord, le contrat l'emporte.

Cette seule règle élimine toute une catégorie de bugs : des validateurs qui s'écartent de la vraie API, des énumérations presque justes, des champs optionnels à un endroit et obligatoires à un autre.

2. Des développeurs dans des worktrees isolés

Je fais tourner deux agents développeurs à la fois, et chacun a son propre worktree git. Ils ne partagent jamais de répertoire de travail, ne peuvent donc pas se marcher sur les fichiers, et je peux relire deux tickets en parallèle sans chaos de fusion.

C'est avec le parallélisme que les agents rapportent vraiment. Un ingénieur seul peut faire avancer plusieurs chantiers, à condition que chacun soit isolé.

3. Rien ne part au rouge

Avant tout push, l'ensemble des contrôles doit passer :

le lint sur tout le dépôt
les tests unitaires dans chaque workspace, pas seulement celui qu'on a touché
un build de production
des tests de bout en bout dans un vrai navigateur

« Le lint passe » est une étape, pas le contrôle. Les agents ont une forte tendance à crier victoire trop tôt, alors les contrôles sont scriptés et non négociables.

4. Un relecteur dont le métier est de tout casser

L'agent relecteur travaille dans son propre worktree, positionné sur le commit exact à relire. Son rôle n'est pas de confirmer que le changement fonctionne. Son rôle est de trouver ce que le développeur a manqué, et il attaque cinq classes de défauts à chaque fois :

Des entrées non fiables lues avant d'être validées
Des données rattachées au mauvais propriétaire, comme un résultat qui arrive après que l'utilisateur a changé de compte
Des validateurs qui dérivent du contrat
Les bornes et la précision : tester les deux côtés de chaque limite, et s'arrêter pile dessus
Une interface qui affiche un état faux ou le laisse fuiter

5. Un problème doit être reproduit par un test qui échoue

C'est la règle qui fait tenir tout le système. Un relecteur ne peut pas se contenter de dire « ça a l'air faux ». Chaque problème doit venir avec un test qui échoue et le reproduit, plus un témoin qui prouve que le jeu de test lui-même est valide.

Sans ça, la revue par IA devient du bruit : des inquiétudes plausibles qui font perdre des heures. Avec ça, chaque problème est soit réel et prouvable, soit inexistant. J'en parle plus en détail dans pourquoi chaque relecteur de code IA a besoin d'un test qui échoue.

6. Une validation par commit

Une validation s'applique à un commit et à rien d'autre. Si la branche bouge, même d'une ligne de documentation, elle est relue à nouveau. Ça paraît strict, mais c'est la seule façon pour qu'une validation veuille vraiment dire quelque chose.

7. Savoir s'arrêter

Une boucle de revue IA peut tourner indéfiniment si on la laisse faire. La tendance indique quand s'arrêter : trois problèmes, puis deux, puis un, puis un détail. Quand le seul problème d'un tour n'existe qu'à cause de la correction du tour précédent, la boucle se relit elle-même, et c'est le signal pour livrer.

Ce que ça apporte

Les agents font le volume : la saisie, l'écriture des tests, la première passe de revue. Je fais le jugement : quoi construire, quels problèmes sont réels, et quand c'est prêt. Résultat : un seul ingénieur peut livrer comme une petite équipe, avec plus de revue que la plupart des équipes n'en ont réellement.

Si vous voulez mettre en place ce type de workflow dans votre équipe, parlons-en.