Ce qu'un sous-agent fait vraiment

Un Claude, une tâche, une fenêtre neuve

Un sous-agent, c'est une instance de Claude que ta session lance pour une tâche précise. La documentation officielle le résume ainsi : il fait le travail dans son propre contexte et ne rend que le résumé.

Ta session principale, celle où tu tapes, devient chef de chantier. Elle décide quoi confier, écrit la consigne, puis lit le rapport.

Ce qu'il reçoit au départ

Un sous-agent ne part pas de rien. Au lancement, sa fenêtre contient :

• son prompt système : ses instructions permanentes, écrites dans le fichier qui le définit. On écrit ce fichier ensemble au chapitre 2.
• la consigne de la tâche : le message que ta session rédige au moment de lui confier le travail.
• tes fichiers CLAUDE.md, à tous les niveaux, comme ta session.
• un instantané de l'état git du projet, s'il y a un dépôt.
• les skills qu'on lui demande de précharger, s'il y en a. Un skill est une procédure écrite que Claude charge quand elle sert (c'est tout le sujet de la formation Les skills).

Ce qu'il ne voit pas

C'est le point le plus important : il ne voit pas ta conversation. Ni tes messages, ni les fichiers que ta session a déjà lus, ni les skills qu'elle a déjà utilisés.

Il existe une exception, le fork : un sous-agent qui hérite de toute la conversation. On le voit au chapitre 3.

Ce qu'il rend

Le sous-agent lit, cherche et lance des commandes dans sa fenêtre à lui. Quand il a fini, seul son dernier message revient dans ta session.

La documentation officielle le montre avec une simulation : le sous-agent y lit 6 100 tokens de fichiers, et la session principale reçoit un résultat de 420 tokens. Un token, c'est un morceau de mot : l'unité qui mesure la taille du contexte.

Ceux que Claude Code fournit déjà

Claude Code embarque des sous-agents prêts à l'emploi. Claude s'en sert de lui-même quand la tâche s'y prête :

• Explore : recherche dans le code, en lecture seule. Il ne charge pas tes CLAUDE.md, pour rester rapide.
• Plan : même principe, utilisé en mode plan pour préparer un plan avant de modifier quoi que ce soit.
• general-purpose : l'agent à tout faire, qui peut chercher et modifier.

Il en existe quelques autres, plus discrets. Par exemple claude-code-guide, qui répond à tes questions sur Claude Code lui-même.

Quand tu demandes « trouve où on gère l'expiration des sessions », Claude peut confier la recherche à Explore. Les dizaines de fichiers lus restent chez lui. Toi, tu reçois la réponse.

L'exemple vécu : dix rédacteurs en parallèle

Ce site avait besoin de dix formations. Plutôt qu'une session qui les écrit l'une après l'autre, ma session a lancé dix sous-agents en même temps, un par formation.

Chacun a reçu la même structure de consigne :

• un dossier à lui : contenu/formations/<slug>/, avec l'interdiction d'écrire ailleurs ;
• un cahier des charges commun : le fichier contenu/LISEZMOI.md, qui fixe le format des fichiers et les règles d'écriture ;
• une exigence d'exactitude : vérifier chaque commande dans la documentation officielle avant de l'écrire, et ne pas écrire ce qui ne peut pas être vérifié ;
• des interdits clairs : pas de lecture des fichiers .env, pas de commit, pas de serveur lancé, pas d'autres agents lancés ;
• un contrôle final obligatoire, avec le format exact du rapport à rendre.

La formation que tu lis sort de ce dispositif. Son rédacteur a lu la page officielle des sous-agents en entier, puis celles des worktrees, des coûts et des tâches en arrière-plan. Tout ça est resté dans sa fenêtre.

Ma session, elle, ne reçoit qu'un rapport par formation : la liste des leçons, leur nombre de mots, leur statut gratuit ou payant, et les points qui n'ont pas pu être vérifiés.

Ce qui fait que ça marche

Lancer dix agents ne suffit pas. Trois choix ont compté, et ils reviennent dans toute la formation.

1. Des zones séparées. Un dossier par agent : aucun fichier n'est touché par deux agents à la fois.
2. Une source commune. Un seul cahier des charges, lu par tous, au lieu de dix consignes qui finissent par diverger.
3. Une fin définie. Chaque agent sait quoi vérifier avant de répondre, et quoi rendre.

Le troisième point est celui qu'on néglige. Mes règles d'orchestration contiennent d'ailleurs une clause née de ce problème : des agents qui rendaient « en attente » comme réponse finale, au lieu du résultat. On décortique ce piège au chapitre 3.

Quand ne pas déléguer

Un sous-agent n'est pas toujours le bon choix. La documentation recommande de rester dans ta conversation principale quand :

• la tâche demande beaucoup d'allers-retours avec toi ;
• plusieurs étapes partagent beaucoup de contexte, comme préparer, coder puis tester la même fonctionnalité ;
• c'est un petit changement rapide et ciblé ;
• la rapidité compte : un sous-agent part de zéro et doit d'abord se renseigner.

Ce que la suite t'apporte

Tu as la vue d'ensemble. La suite de la formation te donne les moyens de le faire chez toi :

• Chapitre 2, créer ses agents : le fichier qui définit un agent, où le ranger, comment limiter ses outils, quel modèle choisir, et comment écrire une consigne. Tu y trouves la consigne complète reçue par les rédacteurs de ce site, expliquée ligne par ligne.
• Chapitre 3, travailler en parallèle : lancer plusieurs agents sans conflit de fichiers, avec des dossiers séparés ou des worktrees git, les suivre en arrière-plan, choisir entre skill, sous-agent, hook et MCP, et éviter les pièges qui coûtent cher.