Quand utiliser les sous-agents de Claude Code
Claude Code dispose d'un Agent tool capable de lancer des sous-agents indépendants au sein d'une conversation. Chaque sous-agent possède son propre contexte, exécute sa tâche, puis renvoie le résultat à l'agent principal.
Sur le papier, c'est très puissant. En pratique, la plupart du temps, vous n'en avez pas besoin. Cet article fait le point : quand un sous-agent apporte une vraie valeur ajoutée, et quand il ne fait que compliquer les choses.
Vous ne pouvez pas appeler l'Agent tool directement depuis CLAUDE.md ou une slash command — c'est un outil interne que Claude Code décide lui-même d'utiliser ou non. En revanche, vous pouvez orienter sa décision via vos prompts.
Le fonctionnement d'un sous-agent :
Les caractéristiques clés :
- Contexte isolé : le sous-agent n'a pas accès à l'historique de la conversation principale — il ne voit que le prompt qu'on lui a donné au lancement
- Compression des résultats : peu importe le nombre de fichiers lus ou de commandes exécutées en interne, seul un résumé est renvoyé à l'agent principal
- Exécution parallèle : plusieurs sous-agents peuvent être lancés et s'exécuter simultanément
Le cas d'usage le plus courant. Vous demandez à Claude Code d'investiguer un problème qui nécessite d'explorer plusieurs pistes en même temps.
Par exemple : "Comment l'authentification est-elle implémentée dans ce projet ?"
Sans sous-agent, Claude Code procède séquentiellement : lire le controller d'auth → le middleware → les routes → le modèle → la config... Étape par étape, c'est lent.
Avec des sous-agents :
Lancer 3 sous-agents en parallèle :
- Agent 1 : examiner la logique d'authentification dans les controllers et middlewares
- Agent 2 : analyser la conception des modèles User et Session
- Agent 3 : inspecter les fichiers de configuration et variables d'environnement liés à l'auth
Trois axes explorés simultanément, résultats agrégés. Vous pouvez guider ce comportement dans votre CLAUDE.md :
## Tâches d'investigation
Pour les investigations couvrant plusieurs modules, privilégier le lancement
de plusieurs sous-agents en parallèle, puis consolider les conclusions.
La fenêtre de contexte de Claude Code est limitée. Si une sous-tâche nécessite de lire beaucoup de fichiers pour n'en tirer qu'une conclusion, un sous-agent permet de garder tout ce "bruit de traitement" en dehors du contexte principal.
Exemples typiques :
Le point commun de ces tâches : beaucoup d'input, peu d'output. Le sous-agent digère la masse d'informations et ne renvoie que l'essentiel.
Certaines tâches comportent un risque d'échec. En utilisant un sous-agent avec le paramètre isolation: "worktree", il travaille dans un git worktree indépendant. Si ça tourne mal, votre répertoire de travail reste intact.
## Refactoring à haut risque
Pour les refactorings de grande envergure, utiliser un sous-agent
avec isolation worktree. Fusionner uniquement après validation du résultat.
Cas d'usage adaptés :
- Refactoring exploratoire : on ne sait pas si l'approche va fonctionner, le sous-agent essaie d'abord
- Comparaison de solutions : implémenter deux approches en parallèle et comparer les résultats
- Génération de code : produire du code boilerplate en masse, relire avant d'intégrer
"Renomme cette fonction de camelCase en snake_case" — faites-le directement. Le surcoût d'un sous-agent (construction du contexte, attente du retour, parsing du résultat) est plus lent que l'exécution directe.
Règle simple : si un Grep + un Edit suffisent, pas besoin de sous-agent.
"Lire la config → modifier le code en conséquence → mettre à jour les tests en fonction"
Ce type de chaîne où chaque étape dépend de la précédente ne se prête pas au découpage. Avec des sous-agents, il faudrait faire transiter les résultats intermédiaires via les prompts — c'est pénible et source de perte d'information. L'exécution séquentielle reste la meilleure option.
Un sous-agent renvoie du texte résumé, pas des données structurées. Si vous avez besoin d'une modification exacte (par exemple insérer du code précis à la ligne 47), confiez-la directement à l'agent principal.
Le sous-agent excelle pour "investiguer et conclure", pas pour "exécuter une modification chirurgicale".
Si votre conversation vient de commencer et que la fenêtre de contexte est encore vide, inutile de "protéger le contexte" avec un sous-agent. Attendez que la conversation s'allonge et que l'agent principal commence à compresser l'historique avant de déléguer les tâches lourdes.
Prenons un cas concret : analyser tous les controllers d'un projet Rails utilisant before_action pour comprendre les patterns d'authentification et d'autorisation.
Sans sous-agent :
Claude Code lit les fichiers de controller un par un, chacun occupant du contexte principal. Avec 20 controllers, le contenu des fichiers peut consommer une quantité massive de tokens. Au moment de livrer l'analyse, les détails lus en début de session risquent d'avoir été compressés et perdus.
Avec un sous-agent :
Lancer un sous-agent : "Lire tous les controllers dans app/controllers/,
identifier tous les callbacks before_action, analyser les patterns
d'authentification et d'autorisation, et produire une synthèse classifiée."
Le sous-agent lit tous les fichiers dans son propre contexte et renvoie un résumé propre. Le contexte de l'agent principal est à peine sollicité — il récupère la conclusion et peut avancer.
Vous ne pouvez pas forcer Claude Code à utiliser ou non les sous-agents, mais vous pouvez exprimer vos préférences dans CLAUDE.md :
## Préférences d'utilisation des agents
### Tâches adaptées aux sous-agents
- Investigation multi-modules (3 répertoires ou plus)
- Recherche et statistiques sur une large base de code
- Refactoring exploratoire (avec isolation worktree)
### Tâches à ne PAS découper en sous-agents
- Modification d'un seul fichier
- Opérations séquentielles avec dépendances
- Correction de bug dont on connaît déjà l'emplacement
Est-ce que le "processus" de cette tâche est bien plus volumineux que sa "conclusion" ?
Si oui — utilisez un sous-agent pour digérer le processus et ne renvoyer que la conclusion.
Si non — faites-le directement, sans couche intermédiaire.
Les sous-agents ne sont pas meilleurs en plus grand nombre. C'est un outil de gestion de contexte, pas un framework de programmation concurrente. Bien utilisés, ils permettent à Claude Code de garder la tête claire sur les gros projets. Mal utilisés, ils ne font que gaspiller du temps de démarrage.