tour-de-controle

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)

1. 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.
2. 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.
3. 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.
4. 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)

5. 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.
6. 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. »
7. 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)

8. 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é.
9. 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.
10. 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é.