Subagents, Skills et MCP - la puissance la plus récente de Claude Code

La grotte au trésor la plus profonde ! Tu vas y découvrir les fonctions qui sont les ajouts les plus récents à Claude Code : les subagents, les skills et le protocole MCP. Ce sont elles qui transforment un navigateur solitaire en un équipage complet et bien rodé.

Les subagents

Un subagent, c'est un agent spécialisé, avec son propre prompt et son propre jeu d'outils, auquel Claude délègue des tâches ciblées. C'est comme envoyer un matelot dédié à une besogne précise : l'un relit le code, l'autre écrit les tests, et tout cela peut se dérouler en parallèle.

Ne te trompe pas de définition : un subagent n'est pas une seconde installation de Claude Code sur un autre ordinateur - tout se passe dans ta session, sur ta machine. Ce n'est pas non plus un plugin graphique pour l'éditeur VS Code, ni un mode où Claude fonctionnerait sans modèle d'IA. C'est le même modèle, avec des consignes plus étroites et une mission plus précise.

Où vivent les subagents ?

Tu les définis dans des fichiers markdown situés dans le dossier .claude/agents/<name>.md. Chaque fichier contient son propre prompt système et la liste des outils auxquels il a droit. Rien à déclarer dans package.json sous une section "agents", et aucune variable d'environnement CLAUDE_AGENTS n'entre en jeu - un simple fichier markdown suffit à faire naître un nouveau membre d'équipage.

Voici un exemple de subagent relecteur de code, enregistré dans le fichier .claude/agents/code-reviewer.md :

1---
2name: code-reviewer
3description: Passe le code en revue pour trouver bugs et failles de securite. A utiliser apres chaque modification du code.
4tools: Read, Grep, Glob
5---
6
7Tu es un relecteur de code experimente. Tu cherches les erreurs de logique,
8les failles de securite et les entorses aux bonnes pratiques. Sois concis -
9ne signale que les vrais problemes.

Le bloc entre les tirets, c'est l'en-tête : il doit commencer à la toute première ligne et contient deux champs obligatoires. name est le nom de l'agent - un fichier sans ce champ est tout simplement ignoré par Claude Code. description explique à Claude quand faire appel à ce subagent. Le champ facultatif tools limite les outils dont il dispose - ici la lecture et la recherche (Read, Grep, Glob), et rien d'autre : il inspecte la cale sans jamais rien y déplacer. Le texte qui suit l'en-tête est le prompt système : c'est lui qui donne au matelot son caractère et sa consigne de travail.

À quoi ça sert ?

• Spécialisation - un agent dédié (par exemple code-reviewer, test-writer) reste concentré sur une seule chose
• Parallélisme - plusieurs tâches peuvent avancer en même temps
• Contexte plus propre - le travail du subagent n'encombre pas la conversation principale

Gérer les subagents

Tu n'es pas obligé d'écrire ces fichiers markdown à la main : le plus simple pour recruter un nouveau matelot, c'est de le demander à Claude dans une session, et il écrit lui-même le fichier dans .claude/agents/ :

1Crée dans .claude/agents/ un subagent code-reviewer qui lit seulement le code et signale les bugs

Dans les versions récentes de Claude Code, la commande /agents n'ouvre plus d'assistant de création : elle te rappelle seulement ce chemin. Ensuite, Claude décide tout seul du moment où déléguer une tâche au subagent approprié - tu n'as pas besoin de l'appeler à la main à chaque fois.

Les skills

Les skills sont des capacités réutilisables invoquées par le modèle. Ce sont des procédures toutes prêtes que Claude peut lancer au bon moment, sans que tu réexpliques la marche à suivre. Tu les invoques toi-même - ou Claude les invoque de sa propre initiative - via /<skill-name>, par exemple /deploy :

1# Invocation du skill nomme "deploy"
2/deploy

Retiens bien cette forme : il n'existe pas de flag --skill à passer au démarrage, et on ne va jamais bricoler le dossier node_modules pour cela - une barre oblique suivie du nom du skill, c'est tout. Les skills brillent sur les workflows répétitifs, cette même suite d'étapes que tu refais encore et encore. Un skill, c'est un dossier avec un fichier SKILL.md : un skill de projet se trouve dans .claude/skills/<nom>/SKILL.md, un skill personnel dans ~/.claude/skills/<nom>/SKILL.md, et le nom du dossier devient la commande, donc .claude/skills/deploy/SKILL.md donne /deploy.

MCP - Model Context Protocol

MCP (Model Context Protocol) est un standard qui connecte Claude à des outils et données externes - GitHub, bases de données, Slack, le navigateur, Sentry et bien d'autres. C'est comme ajouter de nouveaux instruments au compas, pour que le navigateur voie plus loin que tes seuls fichiers.

Ce n'est donc ni un format de compression qui réduirait la taille du modèle Claude, ni une commande qui effacerait le contexte de la conversation - celle-là, tu la connais déjà, c'est /clear - ni un langage de programmation venu remplacer TypeScript. MCP est un protocole de branchement, rien de plus.

Ajouter un serveur MCP

L'ordre des mots ne change jamais : d'abord claude, puis mcp, puis add, et enfin le nom du serveur, un double tiret -- et la commande qui le lance. Le double tiret sépare les options de Claude de la commande du serveur, pour que les flags du serveur (comme -y dans npx -y) ne soient pas pris pour des options de Claude.

1# Ajoute un serveur MCP depuis le terminal
2claude mcp add <nom> -- <commande>
3
4# Exemple : un serveur MCP en HTTP
5claude mcp add --transport http sentry https://mcp.sentry.dev/mcp

Le second exemple montre une variante précieuse : avec --transport http, le serveur n'est plus un programme local mais une adresse distante. Tu peux également déclarer tes serveurs MCP dans un fichier .mcp.json à la racine du projet, ce qui les partage d'un coup avec tout l'équipage.

Gérer les serveurs MCP

Une fois les serveurs branchés, tu veux savoir lesquels répondent encore. Là aussi, une commande de session te donne l'état des lieux :

1/mcp

Elle affiche les serveurs MCP connectés et te permet de les gérer sans fouiller dans les fichiers de configuration. Tu peux aussi charger une configuration MCP dès le démarrage, avec le flag --mcp-config suivi du chemin du fichier. La consigne se place avant le flag, car --mcp-config accepte plusieurs fichiers à la fois et prendrait tout ce qui le suit pour un autre fichier de configuration :

1claude "Check recent errors in Sentry" --mcp-config ./mcp-servers.json

Ici, Claude démarre déjà branché sur Sentry et traite la demande dans la foulée. Très pratique quand une configuration ne sert qu'à un script précis et n'a pas vocation à rester dans le projet.

À quoi sert MCP ?

Grâce à MCP, Claude Code peut par exemple :

• lire et commenter les issues et les PR sur GitHub
• interroger ta base de données
• récupérer les erreurs depuis Sentry
• piloter le navigateur

Comment tout cela s'articule ?

Imagine la mission "ajoute une fonctionnalité et assure-toi qu'elle marche" :

1. Le Claude principal planifie le changement (le Plan Mode de l'exercice précédent)
2. Il implémente le code en lisant et en modifiant les fichiers
3. Il délègue la relecture au subagent code-reviewer
4. Il lance un skill pour le workflow répétitif, le déploiement par exemple
5. Via MCP, il vérifie dans Sentry qu'aucune erreur n'est apparue après le changement

Tout l'équipage travaille de concert - c'est exactement cela, le vibecoding moderne avec Claude Code.

Résumé

Les subagents - des agents spécialisés définis dans .claude/agents/<name>.md, que tu crées en le demandant à Claude ou à la main Les skills - des capacités réutilisables invoquées via /<skill-name>, par exemple /deploy MCP - la connexion à GitHub, aux bases de données, à Slack et à Sentry, par claude mcp add ou .mcp.json Gestion de MCP - la commande /mcp, le flag --mcp-config La synergie - planification + implémentation + subagent relecteur + skill + MCP

Dans le dernier exercice, tu découvriras les hooks, le mode headless et le workflow complet du vibecoding !

À bientôt !

1---
2name: code-reviewer
3description: Passe le code en revue pour trouver bugs et failles de sécurité. À utiliser après chaque modification du code.
4tools: Read, Grep, Glob
5---
6
7Tu es un relecteur de code expérimenté. Tu cherches les erreurs de logique,
8les failles de sécurité et les entorses aux bonnes pratiques.
9
10Sois concis - ne signale que les vrais problèmes, avec leur niveau de gravité.