À quoi ressemble vraiment un agent IA en production

L’IA fait écrire du code dix fois plus vite. Le reste du métier, lui, n’a pas bougé. Et c’est exactement là que tout se joue.

Quand le code sort dix fois plus vite, le réflexe est de sauter ce qui ralentit : pas de ticket, pas d’analyse, pas de spec, on code directement. Sur le moment, ça avance. Six mois plus tard, c’est la dette qu’on traîne.

Le cycle de développement standard existe pour une raison : une idée, un ticket, une analyse, un design, un plan, du code, une revue. Chaque étape rattrape ce que la précédente a laissé flou. Le problème n’a jamais été le cycle. C’est qu’à la vitesse où l’IA produit du code, plus personne ne le tient jusqu’au bout.

Je ne voulais pas troquer la vitesse contre la rigueur. Alors j’ai construit, pour mes propres projets, un agent qui exécute ce cycle complet, de bout en bout, à la vitesse où l’IA travaille. Pas un chatbot : un pipeline.

C’est aussi le pendant concret de pourquoi la plupart des projets IA meurent entre le POC et la production. Le premier article établissait que les modèles fonctionnent, mais pas les systèmes qui les entourent. En voici un, en détail.

La forme réelle du système

L’agent n’est pas un chatbot. C’est un pipeline. Le travail entre sous forme de ticket et traverse des phases :

idée → découverte → spec technique → planification → implémentation → revue

Chaque phase est une session IA autonome et distincte, avec une seule responsabilité et un seul livrable à produire. La découverte rédige la spécification fonctionnelle. La spec technique en tire une conception. La planification en dérive un plan. L’implémentation écrit le code. La revue le relit.

Aucun prompt monolithique ne couvre l’ensemble. Cinq sessions ciblées s’en chargent, chacune ne recevant que le contexte dont elle a besoin. La première décision d’architecture qui compte n’est pas quel modèle, mais comment découper le travail : des unités assez petites pour qu’une session n’en porte qu’une, et soit jugée sur ce seul livrable.

Le modèle, dans tout ça, en représente peut-être un dixième. Voici les neuf autres.

Toutes les tâches ne suivent pas le même chemin

Un pipeline unique pour tout est la première chose qui cède au contact du réel. L’agent oriente donc chaque tâche selon sa forme, pas seulement son contenu.

• Une fonctionnalité suit les cinq phases complètes.
• Un correctif saute spec technique et planification, et tourne sur un prompt dédié au diagnostic. On ne traite pas un bug comme une fonctionnalité : un défaut ponctuel n’a pas besoin d’un document de conception, et l’y forcer gaspille deux allers-retours LLM à produire des livrables que personne ne lira.
• Un epic s’arrête après découverte et spec technique, puis se décompose en tickets enfants qui suivent chacun leur propre pipeline.

Ce routing n’a rien de spectaculaire, mais c’est l’étape la plus déterminante. Le coût et la latence se fixent là, avant même le premier token, en n’accordant à chaque tâche que les phases qu’elle justifie.

Le modèle le moins cher qui passe

La question du modèle ne vient qu’ensuite. L’agent ne tourne pas sur un modèle unique : à chaque étape, il prend le plus petit modèle capable de la réaliser.

Car chaque phase ne demande pas la même puissance de raisonnement. Les plus lourdes, concevoir une architecture ou bâtir le plan, vont au modèle le plus capable : c’est là que tout se joue, et un mauvais plan empoisonne toute la suite du pipeline. Les phases au périmètre déjà cadré, comme écrire le code à partir d’un plan et de tests, ou relire, se contentent d’un modèle intermédiaire. Ce n’est pas une recommandation de principe : c’est le réglage par défaut du système, et chaque phase peut passer à un modèle plus puissant le jour où elle en a besoin.

Le principe est trivial, et c’est tout l’intérêt. Payer le tarif d’un modèle de pointe pour une tâche déjà cadrée, c’est de loin la façon la plus courante de voir une facture IA tripler sans bruit en production. Le correctif tient en une décision de routing, prise une fois.

Les tests avant le code

L’implémentation ne commence pas par écrire du code. Elle écrit d’abord les tests qui échouent, dérivés de la spec. Le code n’a ensuite qu’un seul objectif : les faire passer.

Ça change deux choses. La définition de « terminé » devient objective : les tests passent, ou ils ne passent pas, il n’y a plus de zone grise où l’agent se déclare satisfait trop facilement. Et les tests deviennent un filet : la session qui touchera ce code plus tard verra immédiatement si elle casse ce qui marchait. C’est aussi pour ça que l’implémentation peut tourner sur un modèle plus modeste. Le travail est borné par des tests qui disent, sans ambiguïté, quand c’est bon.

Ce qui en fait un agent : la boucle de validation

C’est ici que le système cesse d’être un simple script.

Quand la session d’une phase se termine, le pipeline n’avance pas pour autant. Un validateur prend le relais, une autre session IA, un autre modèle, un rôle volontairement étroit, et relit le livrable tout juste produit au regard du précédent. La conception respecte-t-elle vraiment la spec fonctionnelle ? Le plan couvre-t-il vraiment la conception ? S’il valide, le pipeline avance. Sinon, la session productrice reprend, ses objections précises réinjectées dans le contexte, et corrige. Le validateur ne raisonne pas, il vérifie : il tourne donc sur le modèle le moins cher du lot, un ordre de grandeur sous le reste.

Trois détails n’ont été réglés qu’au prix de vraies exécutions en production, et ce sont eux qui séparent une démo d’un système :

• La session porte son propre historique. Une session reprise reçoit les retours de toutes ses tentatives précédentes, pas seulement la dernière. Sans cela, elle corrige la nouvelle remarque tout en défaisant en silence ce qu’elle avait déjà réparé, et la boucle oscille sans fin.
• Elle s’arrête délibérément. Le nombre de tentatives automatiques avant de passer la main n’est pas un chiffre rond choisi par confort. Je l’ai affiné sur de vrais tickets : c’est le point où la boucle converge encore. Au-delà, les chances d’aboutir s’effondrent. Soit l’agent n’y arrive pas, soit il finit par contenter le validateur avec une solution qui coche les cases mais reste fausse. Dans les deux cas, mieux vaut passer la main à un humain que de s’acharner vers une mauvaise réponse.
• Aucun chef d’orchestre. Pas de processus orchestrateur séparé, pas de scheduler, pas d’abonné à un bus d’événements pour coordonner tout cela. Le cycle « une étape livre, on valide » constitue à lui seul la boucle. Le design qui a survécu à la production est le plus simple : le moins de pièces mobiles susceptibles de casser à 2h du matin.

Cette boucle, produire, vérifier contre la source de vérité, corriger, savoir s’arrêter, c’est elle, l’agent. Le modèle n’en est qu’un composant.

Les détails qui décident tout

Un système qui tient en production se joue sur des détails d’architecture qu’aucun tutoriel ne mentionne. Trois qui m’ont coûté cher :

• Chaque ticket dans son propre worktree git. Deux sessions qui tournent en parallèle sur le même dépôt se corrompent mutuellement le travail. L’isolation par worktree n’est pas un confort, c’est ce qui rend le parallélisme possible sans réconciliation manuelle permanente.
• La CI est le juge, pas le modèle. L’agent ne se déclare jamais « fini ». Il pousse, attend le vert de la CI, et si ça casse, une phase dédiée lit les logs, comprend l’échec et se répare. Le succès est prouvé par une autorité extérieure, pas affirmé par celui qui vient d’écrire le code.
• Le contexte est un budget, pas une décharge. Sur un pipeline long, chaque session ne reçoit que le livrable strict dont elle a besoin, jamais tout l’historique. Tout réinjecter fait exploser le coût, gonfle la latence, et dégrade la qualité : un modèle noyé sous le contexte rate ce qui compte au milieu.

Rien de tout cela n’est dans le modèle. Et tout cela décide si le modèle fait, un jour, son travail.

Ce qui reste quand on change de modèle

Changez le modèle sous-jacent demain : le système continue de tourner. Vous réajustez un seuil, peut-être une valeur de routing par défaut, et vous passez à la suite.

Et cette liberté est très concrète. Vous passez d’un fournisseur à un autre sans réécrire l’agent. Vous ajoutez un modèle de secours qui prend le relais quand le fournisseur principal tombe. Vous confiez les tâches sensibles à un modèle ouvert hébergé chez vous, et le reste à une API du marché. À chaque fois, le routing décide qui fait quoi. L’architecture, elle, ne bouge pas.

Retirez le routing, la boucle de validation, la reprise qui porte son historique, l’isolation par worktree, et le meilleur modèle du marché ne produit plus qu’un assemblage coûteux et impossible à observer.

Le modèle est interchangeable. L’architecture, non. C’est toute la différence entre un projet qui livre une belle démo au printemps et un projet qui tourne encore, d’astreinte, en production, le printemps suivant.

Si vous avez un agent bloqué du mauvais côté de cette ligne, fonctionnel en démo mais pas encore un système, c’est exactement le terrain sur lequel j’interviens. On en parle ?