Bien utiliser les sous-agents
Sur cette page
Savoir créer un sous-agent ne dit pas quand s’en servir. Déléguer a un coût, et la documentation de Claude Code est devenue explicite sur ce point : certains conseils d’hier sont aujourd’hui des contre-emplois. Cette leçon vous aide à faire le bon choix, présente les trois schémas d’utilisation qui fonctionnent et liste les erreurs à éviter.
Quand un sous-agent est rentable
Les bonnes pratiques officielles retiennent quatre situations :
- mener en parallèle des travaux indépendants, pour que l’ensemble finisse plus tôt ;
- garder une sortie longue hors de la conversation, comme une suite de tests complète ou une recherche large, qui sinon resterait là pour le reste de la session ;
- obtenir un relecteur qui n’a pas vu comment le code a été écrit ;
- donner à une tâche moins d’outils que la session principale, comme un relecteur qui peut lire mais pas modifier.
Ce qu’il coûte
Surtout des jetons : chaque sous-agent envoie ses propres requêtes, qui comptent dans la même consommation que votre conversation. Parfois aussi du temps : un sous-agent neuf doit d’abord rassembler un contexte que votre conversation avait déjà, et il peut finir plus lent que si la tâche avait été faite sur place. Et par défaut, c’est le même modèle, ou un plus petit, sur la même tâche : vous gagnez du parallélisme ou un regard neuf, pas une réponse plus intelligente.
Conversation principale ou sous-agent ?
| Restez dans la conversation principale quand… | Prenez un sous-agent quand… |
|---|---|
| la tâche demande des allers-retours fréquents ou des retouches successives | la tâche produit une sortie volumineuse dont vous n’avez pas besoin |
| plusieurs phases partagent beaucoup de contexte (planifier, coder, tester) | vous voulez imposer des restrictions d’outils ou de permissions |
| le changement est rapide et ciblé | le travail est autonome et peut se résumer |
| la latence compte |
Deux autres outils sont parfois plus adaptés. Pour une question sur ce qui est déjà dans la conversation, /btw voit tout votre contexte, sans outils, et sa réponse n’entre pas dans l’historique. Pour une procédure réutilisable qui doit s’exécuter dans le contexte principal, une skill convient mieux qu’un sous-agent.
Trois schémas qui fonctionnent
Isoler une opération volumineuse. C’est l’usage le plus efficace :
Use a subagent to run the test suite and report only the failing tests with their error messages
Mener des recherches en parallèle, quand les pistes ne dépendent pas les unes des autres :
Research the authentication, database, and API modules in parallel using separate subagents
Chaque sous-agent explore sa zone, puis Claude fait la synthèse. Attention : chaque résultat revient dans votre conversation, et beaucoup de sous-agents qui rapportent chacun des résultats détaillés finissent par occuper beaucoup de contexte.
Enchaîner des sous-agents pour un travail en plusieurs étapes, Claude transmettant à chacun ce qui est utile du précédent :
Use the code-reviewer subagent to find performance issues, then use the optimizer subagent to fix them
Les contre-emplois à éviter
- Déléguer pour avoir une meilleure réponse. La documentation est claire : confier la même tâche à un sous-agent ne l’améliore pas. Ce qui aide, c’est un relecteur neuf, ce qui est autre chose que déléguer.
- Déléguer pour « protéger » la fenêtre de contexte. C’était un bon conseil quand les fenêtres étaient petites. Avec une fenêtre d’un million de jetons sur la plupart des modèles actuels et une compaction automatique, en manquer est devenu rare. Les sous-agents restent excellents pour le parallélisme, les sorties bruyantes et la relecture indépendante, mais chacun de ces usages coûte des jetons.
- Supposer que le sous-agent connaît la conversation. Il ne la voit pas. Si une règle doit l’atteindre, elle doit figurer dans la consigne ou dans ses instructions.
- Donner tous les outils par défaut. Un sous-agent qui n’a besoin que de lire doit être limité à
Read, Grep, Glob. - Écrire des descriptions floues ou qui se recoupent. Claude choisit mal, ou pas du tout.
- Compter sur
/rewindpour défaire son travail. Les modifications faites par un sous-agent ne sont en général pas enregistrées dans les points de contrôle de votre session : utilisez git pour revenir en arrière.
Garder la main sur le coût
model: haikupour les tâches simples ;- des résumés courts en retour ;
/usage, qui attribue la consommation récente aux skills, aux sous-agents, aux plugins et aux serveurs MCP, pour savoir ce qui rapporte ce qu’il coûte ;- des limites, si besoin : par défaut, un sous-agent peut lancer ses propres sous-agents jusqu’à trois niveaux sous la conversation principale (
CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTHchange cette profondeur,1désactive l’imbrication), et Claude Code refuse d’en lancer un nouveau quand vingt tournent déjà.
Pour interdire un sous-agent précis, ajoutez-le aux règles de refus : "deny": ["Agent(Explore)"] dans les permissions de vos réglages.
Suivre et reprendre
Les sous-agents en arrière-plan s’affichent dans un panneau sous l’invite ; /tasks liste ceux qui tournent et ceux qui viennent de finir, et donne accès à leur transcription. Chaque appel crée une nouvelle instance ; pour poursuivre le travail d’un sous-agent plutôt que de recommencer, demandez à Claude de le reprendre : il retrouve tout son historique.
À vous de jouer
Trier vos tâches. Listez cinq tâches que vous confiez souvent à Claude Code. Pour chacune, décidez avec le tableau de cette leçon : conversation principale, sous-agent, /btw ou skill. Pour les sous-agents retenus, notez le bénéfice attendu (parallélisme, sortie volumineuse, regard neuf ou outils réduits) ; si vous n’en trouvez aucun, la tâche reste dans la conversation.
Sources officielles : Using subagents effectively (Claude Academy) · Create custom subagents (documentation Claude Code : quand déléguer, limites de profondeur et de nombre) · Best practices · Checkpointing (modifications des sous-agents hors des points de contrôle) · Manage costs (
/usage)
Points clés à retenir
- Un sous-agent est rentable pour le parallélisme, les sorties volumineuses, la relecture indépendante et la restriction d’outils
- Il coûte des jetons, parfois du temps, et ne donne pas une réponse plus intelligente
- Trois schémas : isoler une opération volumineuse, chercher en parallèle, enchaîner des sous-agents
- Contre-emplois : déléguer pour mieux répondre, supposer qu’il voit la conversation, tout lui permettre, compter sur
/rewind /usagemesure ce que coûte chaque type de sous-agent ;/btwou une skill sont parfois le meilleur choix