Sous-agents Claude Code : montez votre équipe d'IA spécialisée

Au bout d'une heure de travail avec Claude Code, la conversation est pleine : des fichiers lus pour comprendre un module, la sortie complète d'une suite de tests, trois recherches dans la documentation. Tout cela occupe de la place dans la mémoire de travail de Claude, alors que vous n'aviez besoin que de la conclusion. Les sous-agents règlent exactement ce problème : Claude confie une tâche à un spécialiste, qui travaille de son côté et ne rapporte que l'essentiel.

Ce tutoriel montre comment créer les vôtres, les configurer et les déclencher, avec quatre agents prêts à copier. Tout ce qui concerne le fonctionnement de Claude Code est tiré de la documentation officielle des sous-agents, consultée en octobre 2026.

Ce qu'est un sous-agent, et pourquoi c'est utile

Un sous-agent est un assistant spécialisé qui s'exécute dans sa propre fenêtre de contexte, avec son prompt système, ses outils et ses permissions. Quand il a fini, seul son résumé revient dans la conversation principale. Trois bénéfices en découlent :

• Un contexte propre : un agent peut lire quarante fichiers ou parcourir 2 000 lignes de logs ; vous ne recevez que les trois lignes qui comptent.
• Des garde-fous : un relecteur qui n'a pas le droit d'écrire ne modifiera jamais votre code par excès de zèle.
• Le bon modèle pour le bon travail : une recherche simple peut tourner sur un modèle rapide et peu coûteux, une revue d'architecture sur le plus puissant.

La documentation résume la règle de choix ainsi : passez par un sous-agent quand une tâche produit beaucoup de sorties dont vous n'aurez plus besoin, quand vous voulez restreindre ses outils, ou quand le travail est autonome et peut se résumer. Restez dans la conversation principale pour les allers-retours fréquents et les petites modifications ciblées.

Les agents déjà intégrés

Vous utilisez probablement des sous-agents sans le savoir. Claude Code en lance plusieurs de lui-même :

• Explore : recherche rapide dans le code, en lecture seule ;
• Plan : collecte de contexte pendant le mode plan, en lecture seule ;
• General-purpose : tâches complexes, avec accès à tous les outils.

Explore et Plan démarrent volontairement sans vos fichiers CLAUDE.md, pour aller plus vite. Vos agents personnalisés, eux, en héritent.

Créer votre premier agent

Un sous-agent est un fichier Markdown. L'en-tête le configure, le corps devient son prompt système. On le range :

• dans .claude/agents/ à la racine du projet, pour l'équipe (committé avec le code) ;
• dans ~/.claude/agents/, pour vous, sur tous vos projets.

Voici l'exemple de la documentation, un relecteur de code :

---
name: code-reviewer
description: Reviews code for quality and best practices
tools: Read, Glob, Grep
model: sonnet
---

You are a code reviewer. When invoked, analyze the code and provide
specific, actionable feedback on quality, security, and best practices.

Les champs essentiels :

• name (obligatoire) : l'identifiant de l'agent.
• description (obligatoire) : c'est sur elle que Claude décide de déléguer. Elle doit dire quand utiliser l'agent, en une ou deux phrases. Ajouter « use proactively » encourage Claude à l'appeler de lui-même.
• tools : la liste des outils autorisés. Sans ce champ, l'agent hérite de tous les outils ; c'est rarement ce qu'on veut.
• model : haiku, sonnet, opus, fable, un identifiant complet, ou inherit pour reprendre le modèle de la conversation.

D'autres champs servent ensuite : permissionMode, maxTurns pour limiter le nombre de tours, skills pour précharger des skills, memory pour une mémoire persistante, isolation: worktree pour travailler sur une copie isolée du dépôt.

Pas besoin d'écrire le fichier à la main : vous pouvez demander à Claude de le créer pour vous (« crée un sous-agent qui… »). Claude Code détecte automatiquement les fichiers ajoutés ou modifiés dans ces dossiers ; seul un dossier agents/ créé pendant la session demande de redémarrer.

Quatre agents prêts à copier

Ces quatre modèles sont les nôtres, écrits au format officiel. Adaptez les prompts à votre projet : c'est là que se joue la qualité du résultat.

1. Le relecteur, en lecture seule

Il relit sans jamais pouvoir modifier : pas d'outil d'écriture, pas de terminal.

---
name: relecteur
description: Relit les modifications récentes et signale les problèmes. À utiliser après l'écriture ou la modification de code, avant un commit. Use proactively.
tools: Read, Grep, Glob
model: sonnet
---

Tu es un relecteur de code exigeant mais pragmatique.
Pour chaque problème trouvé, donne : le fichier et la ligne, le risque
concret (bug, faille, lenteur, lisibilité) et la correction proposée.
Classe les problèmes du plus grave au moins grave.
Ignore les questions de goût. Si tout est correct, dis-le en une ligne.

2. Le testeur, qui ne rapporte que les échecs

Une suite de tests produit des centaines de lignes. Cet agent les absorbe et ne rend que ce qui a cassé. Il tourne sur un modèle rapide, car le travail est mécanique.

---
name: testeur
description: Lance la suite de tests et résume les échecs. À utiliser pour vérifier que les tests passent après une modification.
tools: Bash, Read, Grep
model: haiku
---

Lance la suite de tests du projet (la commande est dans le CLAUDE.md).
Ne recopie jamais la sortie complète.
Rends uniquement : le nombre de tests passés et échoués, puis pour
chaque échec le nom du test, le message d'erreur et le fichier concerné.
Ne modifie aucun fichier.

3. L'auditeur sécurité, qui se souvient

Avec memory: project, l'agent tient ses propres notes dans .claude/agent-memory/auditeur-securite/ : il retient les risques déjà acceptés par l'équipe et ne les signale pas à chaque passage. Deux précisions : ce champ active automatiquement la lecture et l'écriture pour que l'agent puisse tenir ses notes, et il ne fonctionne que si la mémoire automatique de Claude Code est activée.

---
name: auditeur-securite
description: Audite le code à la recherche de failles (injections, secrets en dur, contrôles d'accès manquants). À utiliser avant une mise en production.
tools: Read, Grep, Glob
model: opus
memory: project
---

Tu es un auditeur sécurité. Cherche en priorité : secrets dans le code,
entrées utilisateur non validées, requêtes construites par concaténation,
routes sans contrôle d'accès, dépendances connues pour être vulnérables.
Pour chaque faille : gravité, preuve (fichier et ligne), scénario
d'exploitation en une phrase, correction.
Consulte ta mémoire : n'y signale pas de nouveau les risques que
l'équipe a déjà acceptés, et notes-y les nouvelles décisions.

4. Le documentaliste, pour les recherches

Vérifier comment fonctionne une API, retrouver une option de configuration : ce type de recherche génère beaucoup de lecture pour une réponse courte.

---
name: documentaliste
description: Cherche une information précise dans la documentation officielle d'une bibliothèque ou d'un service et rend une réponse sourcée. À utiliser pour toute question sur une API externe.
tools: Read, Grep, Glob, WebFetch, WebSearch
model: haiku
---

Trouve la réponse dans la documentation officielle uniquement.
Rends : la réponse en quelques lignes, un exemple de code minimal,
et le lien exact de la page source.
Si la documentation ne répond pas clairement, dis-le au lieu de deviner.

Déclencher un agent

Quatre façons, de la plus automatique à la plus explicite :

1. Automatiquement : Claude compare votre demande aux descriptions et délègue quand l'une correspond. D'où l'importance d'une description précise.
2. En le nommant : « Demande au relecteur de vérifier mes modifications. »
3. Avec une mention : tapez @ et choisissez l'agent dans la liste. C'est la seule façon de garantir qu'il sera utilisé.
4. Pour toute une session : claude --agent relecteur lance une session entière avec cet agent comme assistant principal.

Plusieurs agents peuvent aussi travailler en parallèle : « Analyse les modules d'authentification, de base de données et d'API en parallèle, avec un sous-agent chacun. » Un agent lancé au premier plan bloque la conversation jusqu'à ce qu'il ait fini ; avec Ctrl+B, vous l'envoyez en arrière-plan et continuez à travailler. Attention : chaque résumé revient dans votre conversation, donc dix agents bavards la rempliront quand même.

Les pièges à connaître

• L'agent ne voit pas votre conversation. Il ne reçoit que son prompt, le CLAUDE.md, le statut git et la demande que Claude lui transmet. Si vous avez expliqué un contexte important dans la conversation, il ne le connaît pas : mettez ce qui est permanent dans le CLAUDE.md.
• Les descriptions ont un coût. Celles de tous vos agents sont chargées à chaque session. Gardez-les courtes et réservez le détail au corps du fichier, qui n'est lu que lorsque l'agent travaille.
• tools ne filtre pas les commandes. On ne peut pas y écrire « Bash, mais seulement pour les tests ». Pour interdire une commande précise, ajoutez une règle de refus dans vos réglages, par exemple Bash(git push *) dans permissions.deny : elle s'applique aussi aux sous-agents. Pour un contrôle plus fin, un hook PreToolUse peut examiner chaque commande et la bloquer.
• Un agent coûte des requêtes. Pour une petite modification, la conversation principale est plus rapide et moins chère. Les agents sont faits pour les tâches volumineuses ou répétées.

Par où commencer

Inutile de créer dix agents le premier jour. La documentation de Claude Code donne un bon déclencheur : quand une tâche annexe inonde votre conversation de sorties que vous ne relirez pas, faites-en un sous-agent. Pour la plupart des équipes, le premier à créer est le testeur, et le deuxième le relecteur. Committez-les dans .claude/agents/ : toute l'équipe en profite, et chacun peut les améliorer.

Un bon sous-agent ressemble à un bon collègue : une mission claire, les outils qu'il lui faut, et un compte rendu qui va droit au but.

Si vous débutez avec la configuration de Claude Code, commencez par notre guide du CLAUDE.md et des fichiers .claude. Et si vous voulez mettre ces outils au service de vos propres projets, parlons-en.