Chapitre 8.3 — Workflows : l’orchestration
⏱️ TL;DR — Un workflow est un cran au-dessus du subagent : un script d’orchestration déterministe qui coordonne beaucoup d’agents (fan-out, pipeline, vote), avec des boucles et des conditions. On y recourt pour trois raisons : être exhaustif (couvrir en parallèle), être confiant (vérification adversariale avant de conclure), ou traiter une échelle qu’un seul contexte ne tient pas (migration massive, audit large). C’est puissant, coûteux et opt-in — la plupart de ton travail quotidien n’en a pas besoin. À connaître pour les gros coups, pas pour un CRUD.
🎯 Objectifs
- Distinguer un workflow d’un simple subagent.
- Savoir les trois raisons légitimes d’en lancer un.
- Reconnaître les patterns d’orchestration.
- Décider honnêtement quand ça ne vaut pas le coût.
Subagent vs workflow
Un subagent, c’est une délégation ponctuelle (8.1). Un workflow, c’est un programme qui orchestre de nombreux agents de façon déterministe : « lance N explorateurs en parallèle, dédoublonne, puis fais vérifier chaque trouvaille par 3 sceptiques, garde ce qui survit ». Là où tu délègues une tâche à un subagent, un workflow structure un flux entier.
Les trois raisons d’orchestrer
Un workflow se justifie quand tu veux :
- Être exhaustif — décomposer un gros travail et le couvrir en parallèle (auditer 40 fichiers, explorer un monolithe par zones). Un seul agent séquentiel serait lent et risquerait d’en manquer.
- Être confiant — obtenir plusieurs perspectives indépendantes et une vérification adversariale avant de committer une conclusion. Utile pour une revue sérieuse, une décision d’architecture, un audit sécurité.
- Passer l’échelle — traiter ce qu’un contexte ne peut pas tenir : une migration sur des centaines de fichiers, un balayage large. On distribue, chaque agent prend un morceau.
Si aucune de ces trois raisons n’est là, un subagent (ou même la session principale) suffit.
Les patterns d’orchestration
Sans entrer dans l’écriture d’un workflow (c’est un sujet avancé), connais les formes récurrentes — ce sont des idées réutilisables même à la main :
| Pattern | Idée |
|---|---|
| Fan-out / parallèle | plusieurs agents attaquent des morceaux indépendants en même temps |
| Pipeline | chaque item traverse des étapes (trouver → vérifier → corriger), sans barrière globale |
| Vérif adversariale | N sceptiques essaient de réfuter chaque trouvaille ; on ne garde que ce qui survit |
| Panel de juges | plusieurs approches générées, notées, on synthétise à partir de la meilleure |
| Boucle jusqu’à épuisement | on relance des chercheurs jusqu’à ce que K tours ne trouvent plus rien |
Le pattern le plus précieux pour la qualité : la vérification adversariale. Faire réfuter une trouvaille par des agents indépendants élimine les « findings plausibles mais faux » — c’est ce qui distingue une revue sérieuse d’une revue qui gobe tout.
💡 Réflexe d’architecte — Même sans lancer un workflow, emprunte ses idées. Tu peux, à la main, demander une vérification adversariale (« essaie de réfuter cette conclusion ») ou un panel (« propose 3 approches, compare, recommande »). Les patterns d’orchestration sont d’abord des façons de penser la fiabilité, avant d’être des scripts.
Honnêtement : quand ça NE vaut PAS le coût
⚠️ Piège — Sortir un workflow pour une tâche ordinaire. Les workflows peuvent lancer des dizaines d’agents et consommer énormément de tokens. Pour une feature, un bug, un refactor local, c’est de l’artillerie inutile — plus lent à mettre en place que la tâche elle-même. Le workflow est pour les gros coups délibérés : audit exhaustif, revue à fort enjeu, migration massive, recherche approfondie.
En pratique, pour un dev web sur un projet de taille normale, tu passeras 95 % du temps en session principale + subagents ponctuels, et tu réserveras les workflows aux rares moments où l’exhaustivité, la confiance ou l’échelle le justifient vraiment. Et c’est opt-in : ça ne se déclenche pas tout seul, tu le demandes explicitement.
🧭 Sur TaskFlow — TaskFlow, projet de taille normale, n’a pas besoin de workflows au quotidien. Un cas où ça se justifierait : « avant une release, audite tout le code de TaskFlow sur la sécurité, la perf, l’accessibilité et la cohérence, en parallèle, avec vérification de chaque finding ». Là, l’exhaustivité + la confiance valent l’orchestration. Le reste du temps, session + subagents suffisent.
✏️ Exercices
Exercice 1 — Les trois raisons. Trouve, dans ton travail, UN cas réel qui justifierait un workflow (exhaustivité, confiance, ou échelle). Puis trois cas qui ne le justifient PAS. Qu’est-ce qui les sépare ?
✅ Solution
Justifié : un audit complet avant release (exhaustivité + confiance), une migration sur des centaines de fichiers (échelle). Non justifié : une feature, un bug, un refactor local (petits, couplés, une session suffit). Le séparateur : y a-t-il un vrai besoin d’exhaustivité/confiance/échelle qu’un seul contexte ne couvre pas ?
Exercice 2 — Emprunte un pattern. Sur une conclusion importante récente, applique à la main la vérification adversariale : demande à l’agent de tenter de la réfuter. Le résultat tient-il ?
✅ Solution
La réfutation révèle souvent un angle mort ou, au contraire, renforce la confiance si la conclusion résiste. C’est le cœur de la fiabilité : ne pas se contenter de la première réponse plausible, mais la stress-tester. Tu tiens là un réflexe applicable partout, sans workflow.
🧠 Quiz de révision
1. Qu’est-ce qui distingue un workflow d’un subagent ?
Le subagent délègue une tâche à un agent. Le workflow est un script d’orchestration déterministe qui coordonne beaucoup d’agents (fan-out, pipeline, vote) avec boucles et conditions.
2. Quelles sont les trois raisons légitimes d’orchestrer ?
Être exhaustif (couvrir en parallèle), être confiant (perspectives + vérification adversariale), passer l’échelle (ce qu’un contexte ne tient pas). Sans l’une des trois, un subagent suffit.
3. Quel pattern est le plus précieux pour la qualité, et pourquoi ?
La vérification adversariale : faire réfuter chaque trouvaille par des agents indépendants élimine les findings « plausibles mais faux ». C’est ce qui sépare une revue sérieuse d’une revue qui gobe tout.
4. Pourquoi ne pas lancer un workflow pour une tâche ordinaire ?
Parce qu’il peut lancer des dizaines d’agents et coûter énormément, pour un gain nul sur une feature/bug/refactor local. C’est de l’artillerie réservée aux gros coups (audit, migration, recherche approfondie), et c’est opt-in.
5. Peut-on profiter des idées d’orchestration sans workflow ?
Oui : à la main, demander une vérification adversariale ou un panel d’approches applique les patterns sans script. Ce sont d’abord des façons de penser la fiabilité.
Chapitre suivant : Atelier — déléguer sur TaskFlow — exploration et revue déléguées en pratique.