Votre conversation avec Claude Code ressemble parfois à un bureau en fin de journée : des dizaines de fichiers ouverts, des résultats de recherche empilés, et plus aucune place pour travailler. Bonne nouvelle : vous pouvez déléguer. Dans ce module, vous allez confier des missions à des sous-agents qui travaillent dans leur propre espace, puis transformer vos procédures répétitives en skills que Claude dégaine au bon moment. Votre contexte reste propre, et votre savoir-faire devient réutilisable.

Ce que vous allez apprendre

• Pourquoi la fenêtre de contexte se remplit, et comment les sous-agents la préservent
• Déléguer et paralléliser des explorations, sans la moindre configuration
• Créer des sous-agents spécialisés : un relecteur de code, un expert base de données
• Capitaliser votre savoir-faire dans des skills chargées à la demande
• Choisir le bon outil : CLAUDE.md, commande custom, skill ou sous-agent

Une conversation, une seule mémoire de travail

Commençons par le problème. La fenêtre de contexte, c’est la mémoire de travail de Claude : tout ce qu’il garde en tête pendant la conversation. Chaque fichier lu, chaque résultat de commande, chaque échange y prend de la place. Imaginez un plan de travail de cuisine : plus vous y posez d’ingrédients, moins il reste d’espace pour cuisiner.

Vous connaissez déjà les remèdes d’urgence : /compact pour résumer la conversation, /clear pour repartir de zéro. Mais ce sont des remèdes, pas une prévention. Quand Claude explore quarante fichiers pour répondre à une seule question, ces quarante fichiers restent dans le contexte. Trois questions plus tard, votre plan de travail déborde.

Les sous-agents règlent le problème à la racine. Un sous-agent, c’est un assistant spécialisé que Claude peut invoquer pour une mission précise. Le point capital : il travaille dans sa propre fenêtre de contexte, complètement séparée de la vôtre. Il lit les quarante fichiers chez lui, réfléchit chez lui, et ne rapporte que sa conclusion.

Pensez à un stagiaire brillant à qui vous confiez un dossier épais. Il s’installe dans le bureau d’à côté, épluche tout, et revient avec une note de synthèse d’une page. Le dossier n’a jamais encombré votre bureau. C’est exactement ce que fait un sous-agent : le travail salissant se passe ailleurs, seul le résultat vous parvient. Si la notion de fenêtre de contexte reste floue, notre glossaire la reprend en détail.

Déléguer sans rien configurer

La bonne nouvelle, c’est que vous n’avez rien à installer pour commencer. Claude Code sait déjà créer des sous-agents génériques à la demande. Il suffit de le demander en français, dans la conversation :

Utilise des sous-agents pour explorer ces trois pistes en parallèle :
la piste du cache, la piste des permissions et la piste du réseau.

Regardez ce qui se passe : Claude lance trois enquêteurs simultanément, chacun dans son propre contexte. Ils travaillent en parallèle, sans se gêner, puis Claude rassemble leurs trois conclusions et vous propose une synthèse. Vous venez de paralléliser une investigation, en une phrase.

Le même réflexe vaut pour toutes les opérations bavardes. Une suite de tests qui crache trois mille lignes de journal ? Déléguez :

Lance la suite de tests dans un sous-agent et rapporte uniquement
les tests qui échouent, avec leur message d'erreur.

Les trois mille lignes restent dans le contexte du sous-agent. Vous ne recevez que l’essentiel.

💡 Astuce — Déléguez systématiquement ce qui produit beaucoup de texte que vous ne relirez jamais : suites de tests, analyses de journaux, lectures de documentation. C’est le moyen le plus simple de garder une conversation principale fluide pendant des heures.

⚠️ Piège courant — Les conclusions des sous-agents reviennent dans votre conversation principale. Si vous lancez huit sous-agents et que chacun rapporte trois pages, votre contexte se remplit quand même. Demandez explicitement des synthèses courtes : « rapporte en dix lignes maximum ».

Créer un sous-agent spécialisé

La délégation spontanée, c’est bien. Mais la vraie puissance arrive quand vous créez des spécialistes permanents, avec leur personnalité, leurs outils et leurs consignes. La commande /agents est votre point d’entrée pour gérer vos sous-agents dans la session. Et la méthode universelle, celle qui marche partout et se partage avec l’équipe, c’est un simple fichier markdown.

Deux emplacements possibles. Le dossier .claude/agents/ à la racine du projet : ces sous-agents sont versionnés avec le code, toute l’équipe en profite. Le dossier ~/.claude/agents/ dans votre répertoire personnel : ces sous-agents vous suivent dans tous vos projets.

Chaque fichier commence par un frontmatter, un en-tête de configuration au format YAML placé entre deux lignes de trois tirets. Quatre champs à connaître :

• name : l’identifiant du sous-agent, en minuscules avec des traits d’union.
• description : la phrase la plus importante du fichier. Elle ne décrit pas ce que fait l’agent, elle décrit QUAND l’invoquer. C’est elle que Claude lit pour décider de déléguer.
• tools (optionnel) : la liste fermée des outils autorisés. Sans ce champ, le sous-agent hérite de tous les outils.
• model (optionnel) : le modèle qui anime le sous-agent. À la date de cette formation, les gammes se nomment Haiku pour la vitesse et l’économie, Sonnet pour l’équilibre, Opus pour la puissance maximale. Sans ce champ, le sous-agent utilise le modèle de votre conversation.

Et le corps du fichier, tout ce qui suit le frontmatter ? C’est le prompt système du sous-agent : sa lettre de mission permanente, les instructions qui définissent qui il est et comment il travaille.

Exemple 1 : le relecteur de code

Voici un relecteur exigeant, en lecture seule. Créez le fichier .claude/agents/code-reviewer.md :

---
name: code-reviewer
description: Relecteur de code exigeant. Utiliser après chaque modification de code pour vérifier qualité, sécurité et lisibilité. Use PROACTIVELY.
tools: Read, Grep, Glob, Bash
model: sonnet
---

Vous êtes un relecteur de code senior, exigeant mais constructif.

À chaque invocation :
1. Exécutez git diff pour identifier les modifications récentes.
2. Lisez les fichiers concernés en entier, pas seulement les lignes changées.
3. Vérifiez : lisibilité, gestion des erreurs, secrets exposés, tests manquants.

Vous travaillez en lecture seule : ne modifiez jamais aucun fichier.
Classez chaque remarque : critique (à corriger), avertissement, suggestion.

Décortiquons. La liste tools contient Read, Grep, Glob et Bash, mais ni Edit ni Write : ce sous-agent est structurellement incapable de modifier un fichier. Bash lui sert uniquement à consulter l’historique git. La mention « Use PROACTIVELY » dans la description invite Claude à le solliciter de lui-même après chaque modification, sans que vous ayez à le demander.

Exemple 2 : l’expert base de données

Deuxième spécialiste : un connaisseur du schéma de données, cantonné aux requêtes en lecture. Fichier .claude/agents/db-expert.md :

---
name: db-expert
description: Expert de la base de données du projet. Utiliser pour toute question sur le schéma, les tables, les index ou pour écrire une requête.
tools: Read, Grep, Glob, Bash
---

Vous êtes l'expert de la base de données de ce projet.

Le schéma de référence se trouve dans db/schema.sql : lisez-le avant
de répondre à toute question.

Règles absolues :
- Uniquement des requêtes en lecture (SELECT). Jamais d'écriture :
  ni INSERT, ni UPDATE, ni DELETE, ni DROP.
- Pour chaque requête proposée : la requête, son explication en une
  phrase, puis le résultat attendu.

Ici, pas de champ model : l’expert hérite du modèle de la conversation principale. Et notez comme la description énumère les situations concrètes qui doivent déclencher la délégation : schéma, tables, index, requêtes. Ce sont les mots que vous emploierez naturellement dans vos demandes.

💡 Astuce — Ne rédigez pas ces fichiers à la main : demandez à Claude de le faire. « Crée un sous-agent code-reviewer dans .claude/agents/ qui relit mes modifications en lecture seule » produit un fichier propre en quelques secondes. Relisez-le, ajustez la description, c’est tout.

Deux bonnes pratiques qui changent tout

Première règle d’or : les agents d’exploration en lecture seule. Un sous-agent qui se contente de lire va vite, ne présente aucun risque, et ne pollue pas votre contexte. Réservez les outils d’écriture à votre conversation principale, là où vous voyez et validez chaque changement. Un explorateur n’a pas besoin d’un stylo, seulement d’une loupe.

Deuxième règle d’or : soignez la description comme une annonce d’embauche. C’est elle, et elle seule, que Claude consulte pour décider de déléguer automatiquement. Une description vague comme « aide sur la base de données » déclenchera peu de délégations. Une description précise comme « utiliser pour toute question sur le schéma, les tables ou les requêtes » tombera juste à chaque fois. Décrivez le QUAND avec les mots de vos demandes réelles.

⚠️ Piège courant — Le sous-agent ne voit pas votre conversation. Il démarre avec son prompt système et la consigne de mission que Claude rédige pour lui, rien d’autre. Si un détail est indispensable, par exemple « ignore le dossier vendor », précisez-le dans votre demande : Claude le transmettra dans la consigne.

Les skills : des dossiers de savoir-faire

Changeons de registre. Les sous-agents délèguent du travail ; les skills capitalisent du savoir. Une skill, c’est un dossier qui contient un fichier SKILL.md, et éventuellement des scripts et des documents de référence. Elle vit dans .claude/skills/ à la racine du projet, ou dans ~/.claude/skills/ pour vos skills personnelles. Le fichier SKILL.md porte un frontmatter avec deux champs, name et description, suivi des instructions.

Le mécanisme clé s’appelle le chargement à la demande, ou divulgation progressive. En permanence, Claude ne connaît que la petite description de chaque skill. Le contenu complet, lui, n’est chargé que lorsque votre demande correspond. Imaginez une étagère de classeurs : vous lisez les étiquettes d’un coup d’œil, mais vous n’ouvrez un classeur que le jour où la recette vous sert. Un savoir-faire de trois pages ne coûte donc presque rien, jusqu’au jour où il devient utile.

C’est la différence fondamentale avec le sous-agent : la skill ne part pas travailler ailleurs, elle enrichit la conversation en cours avec des connaissances et une méthode.

Exemple : la skill rapport-hebdo

Supposons que chaque vendredi, vous rédigez un rapport d’activité avec le même modèle, le même ton, la même collecte de données. Capitalisez tout cela une bonne fois. Créez le dossier .claude/skills/rapport-hebdo/ avec trois éléments :

• SKILL.md : les consignes de rédaction et l’enchaînement des étapes
• template.md : le modèle du rapport, avec ses sections imposées
• scripts/collecte.sh : le script qui rassemble les commits et tickets de la semaine

Et voici le contenu de SKILL.md :

---
name: rapport-hebdo
description: Rédige le rapport hebdomadaire d'activité du projet. Utiliser quand on demande le rapport de la semaine, un bilan hebdo ou un point d'avancement.
---

# Rapport hebdomadaire

## Étapes
1. Exécutez scripts/collecte.sh pour récupérer les commits
   et les tickets fermés de la semaine.
2. Remplissez template.md sans modifier sa structure.
3. Rédigez en trois sections maximum : faits, chiffres, priorités.

## Règles de rédaction
- Ton factuel, phrases courtes, aucun jargon.
- Les chiffres d'abord : commits, tickets fermés, incidents.
- Terminez toujours par les priorités de la semaine suivante.

Désormais, quand vous tapez « prépare-moi le bilan de la semaine », Claude reconnaît la correspondance avec la description, charge la skill, lance le script de collecte, remplit le modèle et applique vos règles de rédaction. Le vendredi suivant, même qualité, zéro rappel de consignes. Votre savoir-faire est devenu un actif de l’équipe.

💡 Astuce — Placez dans ~/.claude/skills/ les savoir-faire qui vous suivent partout, comme votre style de rédaction de commits. Placez dans .claude/skills/ du projet, versionné avec git, tout ce qui doit profiter à l’équipe entière. Un nouveau collègue hérite instantanément des procédures de la maison.

Le tableau de décision : quatre outils, quatre usages

Après CLAUDE.md et les commandes custom des modules précédents, puis les skills et sous-agents de celui-ci, une question légitime se pose : quand utiliser quoi ? Retenez ce tableau, il vaut de l’or.

Outil	Nature	Qui déclenche	Exemple typique
CLAUDE.md	Règles toujours vraies, courtes, chargées à chaque session	Personne, c’est permanent	« Utilise pnpm, réponds en français »
Commande custom	Action précise, déclenchée à la demande	Vous, en tapant son nom	Déployer, formater un commit
Skill	Savoir-faire riche, chargé quand la tâche correspond	Claude, quand c’est pertinent	Procédure du rapport hebdomadaire
Sous-agent	Délégation d’une mission dans un contexte séparé	Claude ou vous	Relecture de code, exploration massive

La question à vous poser suit toujours le même fil. L’information est-elle vraie en permanence et tient-elle en une ligne ? CLAUDE.md. Est-ce une action que vous voulez déclencher vous-même, au moment que vous choisissez ? Commande custom. Est-ce un savoir-faire volumineux qui ne sert que dans certaines situations ? Skill. La tâche mérite-t-elle un ouvrier autonome dont le travail intermédiaire ne doit pas encombrer votre conversation ? Sous-agent. Ces quatre briques se combinent d’ailleurs très bien : un sous-agent peut appliquer une skill, et tous respectent votre CLAUDE.md. Pour situer ces mécanismes dans le paysage plus large des assistants, notre dossier IA et notre comparatif des IA complètent utilement ce module.

À vous de jouer

Créez votre premier spécialiste et confiez-lui une vraie mission : relire votre dernier commit.

1. Ouvrez un terminal à la racine d’un projet git et créez le dossier des sous-agents : mkdir -p .claude/agents (sous Windows, créez simplement le dossier .claude\agents dans l’explorateur).
2. Créez le fichier .claude/agents/code-reviewer.md et recopiez-y intégralement l’exemple 1 de ce module : frontmatter avec name, description, tools et model, puis le prompt système du relecteur.
3. Lancez claude dans ce projet. Le sous-agent est détecté au démarrage de la session.
4. Passez la commande : « Utilise le sous-agent code-reviewer pour relire les modifications du dernier commit ». Observez le travail : le sous-agent consulte l’historique git dans son propre contexte, et seule sa synthèse classée arrive dans votre conversation.
5. Testez maintenant la délégation automatique : modifiez un fichier, puis demandez simplement « vérifie mes changements », sans nommer le sous-agent. S’il n’est pas invoqué, enrichissez sa description avec les mots que vous venez d’employer.
6. Pour aller plus loin, créez la skill rapport-hebdo du module, puis demandez « prépare le bilan de la semaine » et regardez Claude la dégainer tout seul.

En résumé

• Un sous-agent travaille dans un contexte séparé et ne rapporte que sa conclusion : votre conversation principale reste propre.
• Sans aucune configuration, demandez des sous-agents en parallèle pour explorer plusieurs pistes ou absorber les tâches bavardes.
• Un sous-agent spécialisé tient dans un fichier .claude/agents/mon-agent.md : frontmatter avec name, description, tools et model, corps du fichier en guise de prompt système.
• La description décide de la délégation automatique : décrivez QUAND invoquer l’agent, et ajoutez « use PROACTIVELY » pour l’encourager.
• Une skill est un dossier .claude/skills/nom/SKILL.md, avec scripts et modèles, chargé uniquement quand la tâche correspond.
• Le tableau de décision : CLAUDE.md pour le toujours vrai, commande custom pour vos actions, skill pour le savoir-faire contextuel, sous-agent pour la délégation.

Votre atelier est désormais peuplé de spécialistes et de classeurs de recettes. Au prochain module, Claude Code sort du terminal interactif : mode headless, intégration continue et GitHub Actions, votre agent va apprendre à travailler pendant que vous dormez.