Pipeline multi-étapes

De quoi on parle

Un pipeline multi-étapes, c’est découper un gros chantier en étapes séquencées — typiquement spec → code → test → review — où chaque étape a un objectif unique et produit une sortie claire. Sur un chantier conséquent, ces étapes tournent souvent dans des sessions distinctes, chacune avec un contexte frais.

Une seule session qui tente tout finit par saturer sa fenêtre de contexte : c’est le context rot. L’agent perd le fil de ses premières décisions. Découper donne à chaque étape un contexte propre, centré sur une seule responsabilité.

Point clé : Une étape = un objectif + une sortie vérifiable. Si tu ne sais pas dire ce qu’une étape produit, elle est mal découpée.

L’artefact : la mémoire qui survit aux sessions

Entre deux sessions, la conversation est perdue. Ce qui passe d’une étape à la suivante n’est pas l’historique du chat : c’est un artefact durable, un fichier sur le disque — une spec en Markdown, le code, la suite de tests, des notes de review. L’état du pipeline vit dans les fichiers, pas dans le contexte de l’agent. Chaque étape relit l’artefact de la précédente et produit le sien : c’est le handoff.

Point clé : Même instinct qu’un port hexagonal : l’étape suivante dépend du contrat de l’artefact (son format, son contenu), pas du déroulé interne de l’étape qui l’a produit. Ce découplage rend les étapes interchangeables et reprenables.

Attention — handoff implicite. Une session fraîche ne voit pas la conversation précédente. Le brief de handoff doit être explicite et auto-suffisant : pointer l’artefact, rappeler les contraintes, dire ce qu’on attend. « Continue ce qu’on faisait » ne veut rien dire pour une session qui démarre à vide.

Planifier en tête, vérifier entre chaque étape

La première étape — spec ou plan — est un investissement : environ 20 % du temps pour éliminer environ 80 % des mauvaises directions (80-20 Planning). Une spec nette en amont guide toutes les étapes aval.

Le revers du séquencement : une erreur en amont se propage. Une spec ambiguë empoisonne le code, qui empoisonne les tests, qui finissent par valider le mauvais comportement. D’où la règle : vérifier la sortie de chaque étape avant de la passer à la suivante — un quality gate à chaque frontière.

Attention — drift silencieux. Des tests écrits à partir d’une spec fausse passeront au vert tout en confirmant le bug. Le pipeline « marche » et produit quand même le mauvais résultat. Le filet, c’est le contrôle humain ou un sous-agent à la frontière, pas la confiance aveugle dans l’étape précédente.

Boucle fermée à l’intérieur d’une étape

Le pipeline orchestre la séquence (macro). À l’intérieur d’une étape, on veut souvent une boucle fermée auto-correctrice (micro) : exécuter, vérifier, corriger, recommencer jusqu’au succès — avec une limite de tours. Exemple pour l’étape « code » : « implémente, lance dotnet test, et si des tests échouent, corrige et relance jusqu’au vert (max 5 tentatives). » Chaque étape a son oracle de vérification.

Reprise, idempotence et garde-fous

Comme l’état vit dans les artefacts, un pipeline bien conçu est reprenable. Si l’étape test échoue, on relance depuis le code déjà sur disque — pas depuis zéro.

Point clé : Ça ressemble au pattern Saga : une transaction longue découpée en étapes, avec un point de reprise à chaque frontière. On rejoue une étape sans tout recommencer.

Attention — sur-orchestration. Un pipeline multi-sessions n’est pas gratuit : plus d’orchestration, plus de handoffs à écrire. Pour une tâche de dix minutes qu’un seul agent gère en une session, c’est de la sur-ingénierie. Le pipeline paie quand le chantier dépasse une fenêtre de contexte ou mélange trop de responsabilités. La version séquentielle simple suffit souvent ; les rôles parallèles (orchestrateur / workers) ne se justifient qu’au-delà.