Pipelines V3/V4 — Guillaume Samard

Comment ça est né

Igor délègue, mais « délèguer à un agent », au début, c'est lui donner un prompt et espérer. Les pipelines, c'est la réponse au besoin de fiabilité : comment faire produire du code de bout en bout, de façon reproductible, sans que le résultat dépende de l'humeur d'un modèle ? La réponse est une machine — une chaîne de phases où chaque rôle a une entrée, une sortie, et une mesure.

Le point de départ est un prompt, le point d'arrivée est du code testé et déployé. Tout le milieu est un système. Le V3 a posé les rôles, le V4 a posé le contrôle : c'est la maturation d'une idée en un outil de production.

Le contexte

Le V3 introduit une vraie séparation des rôles : un Analyste qui clarifie le besoin, des Chercheurs qui documentent, un Architecte qui planifie, et une phase de Validation. Le principe central est que le développement et le test sont des rôles distincts — celui qui code n'est pas celui qui vérifie. C'est ce qui évite le biais du « c'est fait ».

Le V4 pousse plus loin vers le contrôle : une matrice d'outils contrôlée (chaque agent a exactement les outils qu'il doit avoir, pas plus), un scoring sur cinq axes pour arbitrer entre les candidats d'une phase, un anti-zombie (heartbeat) qui repère et relance les agents qui s'endorment, des checkpoints git à chaque étape pour ne jamais perdre l'état, et des presets d'effort — fast, balanced, perfectionniste.

La timeline SSE suit l'avancement en direct : on voit chaque phase se lancer, produire, être notée. C'est un pipeline observable autant qu'exécutant. Et le V4 a fait ses preuves : une application complète, produite de bout en bout, du prompt au code déployé.

Ce qui distingue les pipelines d'un simple « chain-of-agents », c'est la séparation des rôles et le contrôle : scoring, heartbeat, checkpoints. On ne fait pas confiance au premier résultat, on arbitre ; on ne suppose pas que l'agent est vivant, on le vérifie ; on ne perd pas l'état, on le checkpointe.

Le point dur

Faire tenir une chaîne d'agents sans qu'elle se perde ou s'endorme

Une chaîne d'agents, ça casse de trois façons : un agent qui s'endorme en plein milieu (zombie), un état qui se perde si un appel échoue, et un résultat médiocre qui passe parce que personne ne l'a noté. J'ai attaqué chacune : le heartbeat détecte l'agent qui ne répond plus et le relance, les checkpoints git sauvegardent l'état à chaque étape pour pouvoir repartir, et le scoring 5 axes arbitre entre les candidats au lieu d'accepter le premier.

Le deuxième point dur, c'est la séparation des rôles : séparer Dev et Testeur, c'est bien, mais il faut que le testeur ait un accès suffisant pour vraiment vérifier, sans être influencé par la solution du dev. C'est un équilibre d'accès et de contexte que j'ai dû calibrer.

Fonctionnalités

Séparation des rôles Dev ≠ Testeur

L'agent qui écrit le code n'est pas celui qui le teste ; builder et verifier sont découplés.

Phases plan → code → test → deploy

Amélioration du prompt, planification, codage, test, correction, déploiement — chaque phase a sa sortie.

Scoring qualité 5 axes

Chaque production est notée sur cinq axes pour arbitrer entre les candidats d'une même phase.

Anti-zombie heartbeat + checkpoints git

Les agents qui s'endorment sont détectés et relancés, et l'état est checkpointé en git à chaque étape.

Presets fast · balanced · perfectionniste

Trois niveaux d'effort, et une timeline SSE qui suit l'avancement en direct.

Matrice d'outils contrôle d'accès

Chaque agent a exactement les outils qu'il doit avoir, pas plus — un contrôle d'accès fin sur les capacités.

Arbitrages techniques

Séparer Dev et Testeur Évite le biais du « c'est fait » — celui qui code n'est pas celui qui vérifie. Contrepartie : Plus d'agents, donc plus de coût et de latence ; le testeur doit avoir un accès calibré.

Checkpoints git à chaque étape On ne perd jamais l'état, et on peut rejouer ou repartir d'une étape. Contrepartie : Du code et de l'historique à maintenir, et un léger surcoût à chaque checkpoint.

Heartbeat anti-zombie Un agent qui s'endort casse la chaîne ; on le détecte et on le relance. Contrepartie : Un mécanisme de surveillance permanent, avec un seuil à calibrer (ni trop court, ni trop long).

Presets d'effort Un fix rapide n'a pas besoin du même effort qu'une feature majeure. Contrepartie : Trois profils à maintenir et à documenter ; le mauvais choix de preset coûte cher.

Stack technique

PhasesAnalyste · Chercheurs · Architecte · Validation

Contrôlematrice d'outils · heartbeat

Sûretécheckpoints git

Suiviscoring 5 axes · timeline SSE

Presetsfast · balanced · perfectionniste

En chiffres

0axes de scoring

0presets

100%checkpointé en git

end-to-endV4, app complète

0rôles

Parcours du projet

V3
Séparation des rôles : Analyste → Chercheurs → Architecte → Validation, Dev et Test distincts.
Scoring
Notation sur 5 axes pour arbitrer les candidats d'une phase.
Fiabilité
Anti-zombie (heartbeat), checkpoints git, presets d'effort fast/balanced/perfectionniste.
V4
Matrice d'outils, timeline SSE, et une application complète produite en end-to-end.
Production
Le pipeline devient le moteur de la délégation de code d'Igor.

Ce que ça a rendu

01
Production reproductible
Un prompt entre, du code testé et déployé sort — de façon reproductible, pas au hasard.
02
Preuve par l'end-to-end
Le V4 a produit une application complète de bout en bout.
03
Le moteur de la délégation
Les pipelines sont la façon dont Igor délègue la production de code à grande échelle.