| name | tour-de-controle |
| description | Orchestre une tâche complexe en trois temps avec Claude Code — PLANIFIER avec le modèle le plus puissant (Fable 5 / Opus), DÉLÉGUER l'exécution à des sous-agents calibrés lot par lot (Haiku / Sonnet / Opus selon la complexité) lancés en parallèle, puis VÉRIFIER chaque livrable de façon adversariale avec le modèle puissant avant de conclure. Déclenché par "tour de contrôle", "orchestre cette tâche", "planifie-délègue-vérifie", "fais-le faire par des sous-agents", ou toute grosse tâche multi-lots où l'utilisateur veut la qualité du grand modèle sans payer le grand modèle sur chaque ligne. |
tour-de-controle — planifier, déléguer, vérifier
Le principe : le grand modèle est trop précieux pour exécuter, et trop bon pour ne pas
vérifier. Sur une grosse tâche, on ne lui demande pas de tout faire — on lui demande
les deux choses où il écrase tout : le plan et le contrôle qualité. L'exécution,
elle, part vers des sous-agents plus petits, plus rapides, moins chers, qui travaillent
en parallèle.
PLANIFIER DÉLÉGUER VÉRIFIER
(grand modèle, 1 fois) (petits agents, en //) (grand modèle, 1 fois)
┌──────────────────┐ ┌──────┐ ┌──────┐ ┌──────────────────┐
│ spec complète │ → │lot 1 │ │lot 2 │ ... → │ contrôle contre │
│ + critères de │ └──────┘ └──────┘ │ les critères du │
│ "fini" par lot │ chaque lot = un agent │ plan, lot par lot│
└──────────────────┘ autonome └──────────────────┘
↳ ce qui échoue
repart en lot ciblé
Pourquoi ça marche (et pourquoi maintenant) :
→ Les modèles frontière type Claude Fable 5 sont devenus excellents en planification
long-horizon et en vérification — mais chaque tour coûte cher et peut durer plusieurs
minutes. Les utiliser pour exécuter chaque sous-tâche, c'est payer un prix de
tour de contrôle pour faire rouler des chariots à bagages.
→ Un petit modèle avec une spec précise livre un travail quasi équivalent sur un lot
bien découpé. Toute la qualité se joue dans la découpe et dans le contrôle — pas dans
le muscle de l'exécutant.
→ La vérification par un agent à contexte frais bat l'auto-critique : l'exécutant ne
voit pas ses propres angles morts.
Quand l'utiliser
- Tâche en plusieurs lots indépendants : audit d'un dossier, migration de fichiers,
production d'une série de documents, analyse multi-sources, refonte par sections.
- L'utilisateur veut borner le coût tout en gardant la qualité du grand modèle là où
elle compte.
- La tâche a des critères de réussite vérifiables (ou peut en recevoir).
Quand NE PAS l'utiliser
- Tâche courte ou séquentielle qu'un seul passage règle — l'orchestration coûterait plus
cher que le travail. Fais-la directement.
- Tâche créative d'un seul tenant (un texte, un design) — la découpe casse la cohérence.
- Micro-tâches en rafale : un sous-agent repart de zéro (contexte frais à reconstruire),
la délégation se rentabilise sur des lots de volume, pas sur des retouches d'une minute.
Workflow (3 phases)
Phase 1 — PLANIFIER (toi, le grand modèle, effort maximal)
- Spec complète d'abord. Si la demande est floue, pose TOUTES tes questions en un
seul tour (objectif, périmètre, contraintes, format de sortie, exemples de "bien").
Un plan sur une demande floue produit des lots flous — et des sous-agents perdus.
- Découpe en lots indépendants. Chaque lot doit être exécutable seul, sans voir les
autres. Si deux lots dépendent l'un de l'autre, fusionne-les ou séquence-les.
- Pour chaque lot, écris 4 choses dans un plan affiché à l'utilisateur :
- Mission : une phrase, verbe d'action.
- Matière : les fichiers / données / liens exacts dont le lot a besoin.
- Critères de fini : 2 à 4 critères vérifiables (pas "de qualité", mais
"contient les chiffres exacts du tableau source", "moins de 300 mots", "0 lien mort").
- Modèle : le tier d'exécution choisi via la grille de routing (voir Réglages),
avec sa justification en 3-5 mots ("mécanique pur", "rédaction nuancée"…). Le routing
se décide AU PLAN, jamais à l'improvisation au moment du lancement.
- Valide le plan avec l'utilisateur si la tâche est lourde ou ambiguë. Sinon, enchaîne.
Phase 2 — DÉLÉGUER (sous-agents calibrés, en parallèle)
- Lance un sous-agent par lot via l'outil Agent/Task, avec le modèle assigné
dans le plan (
model: "haiku" / "sonnet" / "opus" — grille de routing dans
les Réglages). Lance tous les lots indépendants dans le même tour — ils tournent
en parallèle.
- Le prompt de chaque sous-agent est autonome : il ne voit RIEN de la conversation.
Recopie dedans la mission, la matière (chemins complets), les critères de fini, et le
format de sortie attendu. Termine par : « Ta dernière réponse EST le livrable —
renvoie le contenu brut, pas un résumé de ce que tu as fait. »
- Pendant que les agents tournent, ne refais pas leur travail toi-même. Attends.
Phase 3 — VÉRIFIER (toi, le grand modèle, casquette d'inspecteur)
- Contrôle chaque livrable contre ses critères de fini — en cherchant à le refuser.
Pose-toi pour chaque critère : « qu'est-ce qui prouverait que c'est raté ? » et va
vérifier dans les sources (relis le fichier produit, recoupe les chiffres, teste les
liens). Un livrable qui "a l'air bien" sans preuve = non vérifié.
- Ce qui échoue repart en lot ciblé : poursuis l'agent exécutant si l'environnement le
permet (son contexte est intact), sinon un nouveau sous-agent — dans les deux cas avec le
livrable fautif, le critère raté et la correction attendue. Maximum 2 boucles de
reprise — au-delà, reprends le lot toi-même ou remonte le blocage à l'utilisateur.
Escalade de tier : si la 1re reprise échoue sur le même modèle, la 2e se lance
un tier au-dessus (haiku → sonnet → opus). Un échec répété est rarement un problème
de consigne — c'est un lot sous-calibré, et un tier de plus coûte moins cher qu'une
3e boucle.
Exception micro-correction : une déviation triviale et mécanique (≤ 1 ligne à
supprimer ou remplacer) se corrige directement au contrôle et se note au rapport — une
boucle complète pour ça serait du gaspillage.
- Rapport final à l'utilisateur : ce qui a été produit (avec chemins), ce qui a été
vérifié et comment, ce qui a été repris, ce qui reste ouvert. Jamais de "tout est bon"
sans pointer les preuves.
Réglages par défaut — grille de routing
| Rôle | Modèle | Quand |
|---|
| Planification + vérification | le modèle de la session (idéalement Fable 5 / Opus) | Toujours — c'est là que l'intelligence paie |
| Exécution mécanique | haiku | Zéro jugement requis : extraire, lister, compter, reformater, inventorier |
| Exécution standard (défaut) | sonnet | Analyse, synthèse, rédaction structurée, code balisé — 90 % de la qualité, fraction du coût |
| Exécution complexe | opus | Jugement nuancé, rédaction niveau publication, raisonnement multi-étapes DANS le lot, matière ambiguë ou contradictoire |
Règles de routing :
→ En cas d'hésitation entre deux tiers : prends le tier supérieur si le lot est coûteux
à reprendre ou sur le chemin critique ; l'inférieur sinon. Une reprise coûte plus cher
que l'écart de prix entre deux tiers.
→ opus reste l'exception, pas la règle. Si la majorité des lots réclame opus, c'est
que la découpe est mauvaise (lots trop gros, trop ambigus) — redécoupe, ou admets que la
tâche n'est pas faite pour la délégation.
→ Le doute se lève par le critère de fini : un lot dont les critères sont purement
mécaniques ("compte exact", "liste exhaustive") n'a jamais besoin de plus que haiku,
quelle que soit la taille de la matière.
Règles d'or :
→ Jamais plus de lots que nécessaire. 3 gros lots bien spécifiés battent 10 miettes.
→ Les critères de fini s'écrivent AVANT de lancer les agents, jamais après — sinon on
vérifie ce qui a été produit au lieu de ce qui était demandé.
→ La vérification n'est pas optionnelle. Sauter la phase 3, c'est tout le pattern qui
s'effondre : on a juste payé moins cher pour un résultat non contrôlé.
