Agent John, de la demande client à la PR livrée

Trois agents, trois rôles précis, un seul pipeline. Une demande client devient un ticket. Un ticket devient une analyse de code. Une analyse approuvée devient une pull request. Aucun agent ne fait les trois : c'est précisément là que réside la conception.

Ce pipeline tourne en production aujourd'hui, sur nos propres livraisons client. Il est récent : renommé depuis un nom interne antérieur il y a quelques semaines, il accumule encore des heures en production. Ce qui suit décrit ce qu'il fait concrètement, y compris ce qu'il a raté en chemin.

Un mini-PRD, pas un résumé

Un utilisateur client décrit un problème sur une page "Demandes" dans son application. Agent John ne prend pas la première phrase au pied de la lettre. Il pose une question précise à la fois, creuse ce qui est réellement cassé, qui est touché, et à quoi ressemble "terminé", puis ouvre un ticket structuré comme un mini-PRD en cinq sections fixes : Contexte, Besoin, Comportement attendu, Critères d'acceptation, Hors périmètre. Aucune section n'est omise, même quand la réponse est "aucun".

Les critères d'acceptation comptent plus que le reste. C'est ce que l'agent suivant dans la chaîne vérifie contre le code.

Lire avant de juger

Dès qu'un ticket arrive, l'Instruction Agent ouvre le vrai dépôt GitHub du client, en lecture seule, et le lit avant d'écrire quoi que ce soit. C'est imposé, pas juste suggéré : une analyse soumise sans avoir ouvert un seul fichier est rejetée et jamais sauvegardée. Une analyse qui sonne juste mais repose uniquement sur le texte du ticket est exactement le mode de défaillance que cette contrainte prévient.

La sortie est plafonnée à environ 200 mots : quels fichiers sont concernés, ce que la demande signifie, ce qu'il propose de changer, et ce qui reste inconnu. Elle se termine par l'un des trois verdicts : proposed (prêt pour un feu vert), needs_info (un point bloquant non résolu), ou escalated (le changement touche le schéma de base de données ou la logique métier principale, et appartient à un humain).

Le feu vert est atomique

Un humain révise l'analyse, pas le ticket brut, et l'approuve. Cette approbation et le passage du ticket en développement ont lieu dans la même transaction. Un ticket en "in development" sans approbateur enregistré ne peut pas exister : ce n'est pas une convention, c'est un état que le modèle de données interdit.

Quand l'analyse est juste mais la formulation incorrecte, la corriger à la main est plus rapide et plus fiable que la rejeter en espérant que l'agent converge à la deuxième passe.

Design seul, délibérément

Ce n'est qu'après le feu vert que le Development Agent obtient des droits d'écriture. Son périmètre est volontairement étroit : CSS, composants UI, configuration Tailwind. Pas de logique métier, pas de routes API, pas de changements de schéma. Il lit les fichiers dont il a besoin, fait des modifications ciblées, et ouvre une pull request. Il ne merge jamais sa propre PR. Un webhook GitHub est le seul mécanisme qui ferme la boucle, marquant le ticket comme terminé quand un humain merge la PR.

Ce que les premières semaines ont révélé

Deux vrais défauts ont montré la conception fonctionner comme prévu.

Les analyses de l'Instruction Agent devaient atteindre 200 mots en moyenne. Elles ont dérivé à 680, sept fois la cible, sans que personne ne le mesure jusqu'à ce qu'on en lise quinze d'affilée. Le correctif : une alerte au double de la cible, pour attraper la dérive, pas les dix mots de trop à l'occasion.

Un bug de nommage de branche a un jour regroupé 22 tickets sur deux noms de branche seulement, bloquant complètement le développement. Les noms de branche dérivent désormais du numéro de ticket : un ticket, une branche, et un second feu vert sur le même ticket pousse sur la branche déjà ouverte plutôt que d'en créer une deuxième.

Pourquoi il n'y a pas de LangGraph ici

Le traitement de tickets en lot devait survivre à une exécution interrompue sans perdre de travail, ce qui ressemblait brièvement à un cas d'usage pour un orchestrateur de graphe complet. Le sujet a été cadré, puis écarté : avec le queue runner déjà en place, une exécution relancée rejoue pour environ 0,50 $ une fois les appels d'agents mis en cache. C'est moins cher que de réécrire la boucle d'outils sous forme de graphe. Le deletion test a tranché : supprimer l'orchestrateur ne casse rien dans la conception actuelle. Il reste sur l'étagère jusqu'à ce que le coût de rejeu devienne le vrai goulot d'étranglement.

Les trois agents

Agent John, l'Instruction Agent et le Development Agent ont chacun leur propre page : prompt système, outils et modèle.