La première fois que j'ai utilisé un sous-agent, je l'ai mal utilisé. Je l'ai lancé pour renommer une variable. Une variable. C'était comme engager un entrepreneur pour changer une ampoule — plus lent, plus cher, et franchement ridicule. Alors avant de vous montrer comment configurer un sous-agent dans Claude Code, permettez-moi d'être direct sur les cas où vous ne devriez pas le faire.
Un sous-agent est une instance séparée de Claude à qui votre session principale peut confier une tâche. Il dispose de sa propre fenêtre de contexte — une ardoise vierge —, effectue le travail et renvoie un résumé. Le mot-clé est séparé. Le travail du sous-agent ne pollue pas votre conversation principale. Il explore, parcourt dix fichiers, et votre session principale ne voit que la conclusion.
C'est tout l'intérêt des sous-agents, et c'est pourquoi la plupart des débutants les utilisent mal.
Quand les sous-agents aident vraiment
Ils aident quand une tâche remplirait sinon votre contexte principal de choses dont vous n'avez pas besoin de garder.
Pensez à chercher dans une grande base de code « où gérons-nous l'authentification ? » Sans sous-agent, Claude lit quinze fichiers dans votre conversation principale, et ces quinze fichiers restent dans le contexte pour le reste de la session, consommant des tokens à chaque échange. Avec un sous-agent, cette exploration se déroule dans une fenêtre jetable. Vous récupérez « l'auth se trouve dans src/auth/, voici comment ça fonctionne » — trois phrases au lieu de quinze fichiers.
Donc : les sous-agents se justifient quand le travail est exploratoire (beaucoup de lecture, petite conclusion) ou parallèle (plusieurs choses indépendantes à la fois). Chercher, investiguer, lancer une grande suite de tests et résumer les échecs, passer en revue un diff selon une liste de contrôle — ce sont des cas d'usage parfaits.
Voici le test que j'utilise maintenant. Demandez-vous : cette tâche va-t-elle beaucoup lire pour peu produire ? Si oui, sous-agent. Si la tâche est une modification directe que vous pouvez déjà visualiser, faites-la directement. Renommer une variable ne lit rien et produit un changement précis. Pas de sous-agent.
Quand NE PAS les utiliser
N'utilisez pas un sous-agent pour une modification d'un seul fichier que vous comprenez déjà. N'en utilisez pas pour un travail séquentiel où chaque étape dépend de la précédente. Et n'en utilisez pas juste parce que ça semble sophistiqué. Chaque sous-agent a un coût de démarrage — il s'initialise, construit son propre contexte, renvoie un rapport. Pour les petits travaux, ce coût revient plus cher que ce qu'il économise.
Les modèles Claude plus récents sont aussi assez conservateurs pour créer des sous-agents d'eux-mêmes, ce qui est généralement correct. Si vous voulez déléguer, vous devez souvent le demander explicitement ou le configurer. Ce qui nous amène au comment.
Configurer un sous-agent personnalisé
Claude Code vous permet de définir des sous-agents nommés sous forme de fichiers. Déposez un fichier markdown dans .claude/agents/ de votre projet (ou dans votre configuration de départ pour un usage global). Voici un vrai exemple que j'utilise pour la revue de code :
---
name: reviewer
description: Reviews a diff for bugs and missing edge cases. Use after writing code, before committing.
tools: Read, Grep, Bash
---
You are a focused code reviewer. Given a diff or a set of changed files:
1. Read the changed code and the files it touches.
2. Look for actual bugs — off-by-one, null handling, wrong async behavior.
3. Check for missing edge cases and untested paths.
4. Report findings as a short list, each with a severity (high/medium/low).
Don't rewrite the code. Don't nitpick style. Report what you find and stop.
Quelques éléments méritent d'être soulignés. La ligne description n'est pas décorative — c'est ce que Claude utilise pour décider quand déléguer à cet agent. Rédigez-la comme vous rédigeriez la description d'un outil : dites quand y recourir, pas seulement ce qu'il fait. « À utiliser après avoir écrit du code, avant de faire un commit » donne à Claude un déclencheur concret.
La ligne tools définit ce que le sous-agent peut toucher. Mon reviewer dispose de Read, Grep et Bash — suffisant pour inspecter et lancer des tests, rien pour modifier. C'est délibéré. Un reviewer ne devrait pas modifier votre code. Restreindre la liste des outils maintient le sous-agent dans son rôle et c'est une source d'inquiétude en moins.
Le corps est le prompt système du sous-agent — toute sa personnalité et sa mission. Notez qu'il est précis et délimité. « Rapporte ce que tu trouves et arrête-toi » est important, car sinon un sous-agent zélé commence à corriger des choses, et vous vous retrouvez avec des modifications que vous n'aviez pas demandées.
L'utiliser
Une fois le fichier en place, vous pouvez l'invoquer dans une session :
Utilise le sous-agent reviewer sur mon dernier commit.
Claude le lance, le sous-agent effectue sa lecture et son rapport dans son propre contexte, et vous récupérez une liste de constats propre — sans que quinze fichiers ne débarquent dans votre conversation principale. Pour l'exploration, vous n'avez même pas besoin d'un fichier personnalisé ; le sous-agent général intégré gère très bien les tâches ponctuelles « va trouver X ».
Le changement de perspective
Voici ce qui a finalement rendu les sous-agents évidents pour moi. Arrêtez de les voir comme « un Claude plus puissant ». Ils ne sont pas plus intelligents. Ils permettent de garder votre contexte principal propre en envoyant le travail désorganisé ailleurs.
Une fois que vous voyez les choses ainsi, la question de quand les utiliser trouve sa réponse d'elle-même. Travail désorganisé, chargé en lecture, jetable ? Déléguez-le. Travail précis que vous pouvez déjà anticiper ? Faites-le vous-même. Un reviewer qui lance vos tests et vous remet une liste de constats : parfait. Un entrepreneur pour changer une ampoule : beaucoup moins.
Rédigez un sous-agent cette semaine. Faites-en le reviewer ci-dessus. Lancez-le sur votre prochain commit. Vous ressentirez alors la différence, et vous saurez exactement quand avoir recours au suivant.