Chapitre 8.2 — Quand déléguer (et quand pas)
⏱️ TL;DR — Déléguer a un coût (latence, brief, perte du contexte partagé). On délègue quand le bénéfice dépasse ce coût : grosse exploration à isoler, regard indépendant voulu, ou tâches indépendantes parallélisables. On ne délègue pas ce qui est petit, ce qui exige un aller-retour serré avec toi, ou ce qui a besoin du contexte riche de la session principale. Le fil conducteur : délègue le bruit et l’indépendant, garde la décision et le couplé.
🎯 Objectifs
- Peser coût et bénéfice d’une délégation.
- Reconnaître les bons cas de délégation.
- Reconnaître les cas où déléguer coûte plus que ça ne rapporte.
- Utiliser le parallélisme pour les tâches indépendantes.
Le calcul coût/bénéfice
Le coût le plus sous-estimé : la perte du contexte partagé. Le subagent ne « sait » que ce que tu lui dis ; il n’a pas tout le fil de ta session. Pour une tâche profondément liée à ce que vous venez de faire ensemble, re-briefer un subagent coûte plus que de la faire toi-même.
Les bons cas de délégation
| Cas | Pourquoi ça marche |
|---|---|
| Exploration / cartographie | beaucoup de lecture → peu de conclusion ; on isole le bruit |
| Analyse verbeuse (logs, dumps) | idem : le volume reste chez le subagent |
| Revue / vérification indépendante | un regard non biaisé par celui qui a écrit |
| Tâches indépendantes en parallèle | plusieurs choses à faire qui ne dépendent pas l’une de l’autre |
| Audit spécialisé (sécu, perf, deps) | un agent sur-mesure focalisé sur un axe |
Le dénominateur commun : soit la tâche génère du bruit qu’on veut isoler, soit elle bénéficie d’un regard séparé, soit elle est parallélisable.
Les cas où NE PAS déléguer
⚠️ Piège — La sur-délégation : découper une tâche simple en cinq subagents « pour paralléliser », alors qu’elle tient en une session. Tu paies cinq briefs + cinq latences + la recomposition, pour un travail que la session principale aurait fait d’un trait. Le multi-agent n’est pas un but ; c’est un outil pour un vrai besoin d’isolation/indépendance.
Ne délègue pas quand :
- c’est petit et local (éditer un fichier connu, un typo) — le coût dépasse le gain ;
- ça exige un aller-retour serré avec toi (décisions successives, feedback à chaud) — le subagent, orienté « livrable », s’y prête mal ;
- ça a besoin du contexte riche de la session (ce que vous venez de construire ensemble) — re-briefer coûte plus que faire ;
- la décision t’appartient — on délègue l’exploration et l’analyse, pas le jugement final (tu restes l’architecte).
💡 Réflexe d’architecte — « Délègue l’exploration, garde la décision. » Les subagents ramènent la matière (une carte, une analyse, des findings) ; toi (et l’agent principal) tranches. Si tu te surprends à déléguer une décision, arrête : un subagent te donnera un avis dans son coin, sans ta vue d’ensemble. Le jugement reste au centre.
Le parallélisme : plusieurs indépendants à la fois
Quand plusieurs tâches sont indépendantes, tu peux lancer plusieurs subagents en parallèle — chacun dans son contexte, tous en même temps. Gain : le temps total ≈ celui du plus lent, pas la somme.
La condition absolue : l’indépendance. Trois explorations de modules différents → parallèle, parfait. Mais une chaîne où B a besoin du résultat de A → séquentiel (le parallélisme n’a pas de sens si les tâches se dépendent). Paralléliser des tâches couplées, c’est se compliquer la vie pour rien.
📚 Aller plus loin — Le vrai parallélisme structuré (des dizaines d’agents, fan-out/pipeline, vote) relève des workflows (8.3), un outil avancé et opt-in. Pour le quotidien, lancer 2-3 subagents indépendants suffit largement — inutile de sortir l’artillerie orchestrée pour trois explorations.
🧭 Sur TaskFlow — Sur TaskFlow, on déléguera une exploration (bruit à isoler) et une revue (regard neuf) — deux bons cas. On ne déléguera pas l’écriture des petites tranches du CRUD (couplées, locales, décision à nous). Bon réflexe : la feature se pilote au centre ; on sous-traite ce qui mérite un contexte à part.
✏️ Exercices
Exercice 1 — Trie tes tâches. Prends 6 tâches. Classe : « à déléguer » (bruit/indépendant/regard neuf) vs « à garder » (petit/couplé/décision). Combien déléguais-tu à tort, ou pas assez ?
✅ Solution
À déléguer : explorations, analyses de logs, revues, audits, tâches indépendantes. À garder : éditions locales, tâches à aller-retour serré, décisions d’archi. Beaucoup de devs sous-délèguent l’exploration (et saturent leur session) tout en étant tentés de sur-déléguer par « effet multi-agent ». Le bon curseur suit le coût/bénéfice.
Exercice 2 — Parallèle ou séquentiel ? Prends 3 sous-tâches d’un projet. Sont-elles indépendantes (→ parallèle) ou enchaînées (→ séquentiel) ? Justifie.
✅ Solution
Trois audits de zones différentes → indépendants → parallèle. « Explore le module, puis refactore-le, puis teste-le » → chaîne → séquentiel. Le test : est-ce que l’une a besoin du résultat d’une autre ? Si oui, séquentiel. Paralléliser du couplé ne gagne rien et complique.
🧠 Quiz de révision
1. Quel est le coût le plus sous-estimé d’une délégation ?
La perte du contexte partagé : le subagent ne sait que ce qu’on lui dit. Pour une tâche liée à ce que vous venez de faire, re-briefer coûte plus que de la faire soi-même.
2. Cite deux bons cas de délégation.
Par exemple : l’exploration/analyse verbeuse (isoler le bruit) et la revue indépendante (regard non biaisé). Aussi : tâches indépendantes en parallèle, audits spécialisés.
3. Qu’est-ce que la « sur-délégation » ?
Découper une tâche simple en plusieurs subagents « pour paralléliser » alors qu’elle tient en une session : on paie briefs + latences + recomposition pour rien. Le multi-agent n’est pas un but.
4. Quelle est la condition absolue du parallélisme ?
L’indépendance des tâches. Si B a besoin du résultat de A, c’est séquentiel. Paralléliser des tâches couplées ne gagne rien.
5. Que ne délègue-t-on jamais ?
La décision/le jugement final : on délègue l’exploration et l’analyse (la matière), on garde le jugement (la vue d’ensemble). L’architecte reste au centre.
Chapitre suivant : Workflows : l’orchestration — quand et pourquoi structurer le multi-agent.