Dans Claude Code, les skills portent les méthodes de l'équipe, les sous-agents délèguent des tâches à des assistants spécialisés, les hooks imposent des règles qui s'exécutent à coup sûr, et le plan mode force Claude à proposer avant d'agir. Quatre briques, quatre rôles : ensemble, elles transforment un outil individuel en pratique d'équipe.
La différence se joue sur la fiabilité. Une consigne écrite dans un fichier est suivie la plupart du temps. Un hook est exécuté chaque fois. Un skill s'applique quand la tâche correspond. Un sous-agent isole le bruit d'une exploration. Choisir la bonne brique évite de tout empiler dans un seul fichier de consignes.
Cet article, vérifié sur la documentation officielle de Claude Code au 4 octobre 2026, détaille chaque brique, des exemples (revue de code, conventions, tests, sécurité), la façon de les partager par Git, et les pièges rencontrés en équipe.
1. Claude Code skills, subagents, hooks, plan mode : le rôle de chacun
Les quatre mécanismes répondent à des besoins différents. Le tableau ci-dessous sert de repère : il se lit en une minute et permet de décider où ranger une règle.
| Brique | Ce que c'est | Où ça vit | Usage typique |
|---|---|---|---|
| Skill | Une méthode en Markdown, chargée quand la tâche correspond ou lancée par une commande | .claude/skills/<nom>/SKILL.md | Conventions d'API, procédure de revue, génération de tests |
| Sous-agent | Un assistant spécialisé avec son propre contexte, ses outils et son modèle | .claude/agents/<nom>.md | Relecteur de code, auditeur de sécurité, enquêteur en lecture seule |
| Hook | Une action déterministe déclenchée à un moment du cycle (avant ou après un outil, fin de réponse) | .claude/settings.json | Bloquer une commande, formater après édition, lancer un linter |
| Plan mode | Un mode de permission en lecture seule : Claude explore et propose un plan | Réglage de session ou de sous-agent | Cadrer un changement multi-fichiers avant d'écrire du code |
Une règle simple pour trancher : si l'oubli est acceptable, c'est une consigne ou un skill. Si l'oubli est inacceptable (secrets, commandes destructrices, formatage exigé par la CI), c'est un hook. Si la tâche produit beaucoup de texte intermédiaire dont la conversation n'a pas besoin, c'est un sous-agent.
Les consignes générales du projet restent dans le fichier CLAUDE.md, traité dans notre article sur le fichier CLAUDE.md d'une équipe de développement. Pour le panorama complet de l'outil, voir le guide Claude Code.
2. Claude Code skills : méthodes versionnées dans le dépôt
Un skill est un dossier contenant un fichier SKILL.md. L'en-tête précise un name et une description qui indique quand l'utiliser ; le reste est la procédure en Markdown. Le dossier peut aussi contenir des fichiers de référence, des exemples et des scripts.
---
name: api-conventions
description: Conventions d'API de ce dépôt. À utiliser pour tout nouvel endpoint.
---
Pour chaque endpoint :
- nommage REST, pluriel pour les collections
- format d'erreur unique { code, message }
- un test d'intégration par route
Deux façons de déclencher un skill
Un skill peut être chargé automatiquement quand la description correspond à la demande, ou lancé à la main par une commande du type /nom-du-skill. Deux champs de l'en-tête règlent cela :
- disable-model-invocation: true : seul un humain peut le lancer. À réserver aux actions sensibles comme un déploiement.
- user-invocable: false : seul Claude le charge, utile pour un savoir de référence qu'on ne lance pas à la main.
Autres champs utiles en équipe
Le champ allowed-tools pré-approuve certains outils pendant le skill, par exemple les commandes git de lecture. Le champ context: fork exécute le skill dans un sous-agent isolé, avec agent pour choisir lequel. Une commande précédée d'un point d'exclamation et placée dans le skill s'exécute avant l'envoi à Claude : on y injecte par exemple le diff de la pull request en cours.
Où ranger un skill
La documentation distingue quatre emplacements : personnel (~/.claude/skills/, sur votre machine), projet (.claude/skills/, versionné), plugin, et configuration gérée par l'organisation. En cas de nom identique, l'ordre de priorité est : entreprise, personnel, projet. Pour un standard d'équipe, le dossier du projet est le bon réflexe.
Attention à ne pas confondre : cet article traite des skills côté développement. Leur usage côté bureau (comptes rendus, offres, clôtures) est détaillé dans Claude Skills en entreprise.
3. Claude Code subagents : des assistants spécialisés à contexte isolé
Un sous-agent est un fichier Markdown avec un en-tête : name et description sont obligatoires, puis des champs optionnels comme tools, model, permissionMode, skills ou maxTurns. Le corps du fichier est son prompt système.
---
name: code-reviewer
description: Relit les changements récents. À utiliser après chaque série de modifications.
tools: Read, Grep, Glob, Bash
model: sonnet
---
Tu relis le code pour la qualité, la lisibilité et la sécurité.
Réponds par une liste de points classés par gravité.
Ce qui change par rapport à un skill
Un sous-agent démarre avec son propre prompt système, sans l'historique de la conversation. Il reçoit un message de délégation, les fichiers CLAUDE.md et un instantané de l'état git, puis renvoie un résumé. Tout ce qu'il a lu ou exécuté en route reste hors de votre contexte principal. C'est l'intérêt : faire lancer la suite de tests et ne remonter que les échecs, ou explorer trois modules en parallèle.
Les sous-agents intégrés et les emplacements
Claude Code embarque trois sous-agents : Explore (lecture seule, recherche dans le code), Plan (lecture seule, recherche avant de présenter un plan) et un agent généraliste pour les tâches à plusieurs étapes. Les vôtres se rangent dans .claude/agents/ (projet, versionné) ou ~/.claude/agents/ (personnel), ou viennent d'un plugin. En cas de conflit, la priorité va à la configuration gérée, puis au drapeau de lancement, puis au projet, puis à l'utilisateur.
Choisir le modèle et limiter les droits
Chaque sous-agent peut avoir son modèle : un modèle rapide et économique pour la recherche, un modèle plus capable pour la revue d'architecture. Le champ tools restreint ses outils ; disallowedTools en retire. Un auditeur de sécurité n'a besoin ni d'écrire ni de lancer des commandes arbitraires : lecture seule suffit. Pour un panorama de modèles à jour, voir notre article sur Claude Sonnet 5.5.
Sur les workflows qui enchaînent plusieurs agents, notre article sur les dynamic workflows de Claude Code et les agents IA montre comment les orchestrer.
4. Claude Code hooks : des règles qui s'exécutent à chaque fois
Un hook est une action branchée sur un événement du cycle de vie. La documentation en liste plusieurs dizaines ; les plus utiles en équipe sont PreToolUse (avant un outil), PostToolUse (après), UserPromptSubmit (à l'envoi d'un prompt), Stop (quand Claude termine), SessionStart et les événements liés aux sous-agents (SubagentStart, SubagentStop).
Cinq types de handlers existent : une commande shell, un appel HTTP, un appel d'outil MCP, une évaluation par un modèle (prompt) et un agent expérimental de vérification. Le plus courant reste la commande shell, qui reçoit les informations de l'appel en JSON sur l'entrée standard.
{
"hooks": {
"PostToolUse": [
{
"matcher": "Write|Edit",
"hooks": [{ "type": "command", "command": "npm run lint" }]
}
]
}
}Bloquer : le code de sortie 2
Pour un événement comme PreToolUse, un script qui se termine avec le code de sortie 2 bloque l'appel de l'outil. Le script peut aussi renvoyer en JSON une décision (allow, deny, ask) avec un motif lisible. Sur UserPromptSubmit, le blocage empêche le prompt d'atteindre Claude ; sur Stop, il oblige Claude à poursuivre.
Ciblage, configuration et partage
Le champ matcher filtre par nom d'outil (Bash, Edit|Write, ou un motif MCP). Les hooks se déclarent dans ~/.claude/settings.json (tous vos projets), .claude/settings.json (le projet, versionné), .claude/settings.local.json (local, non partagé), les réglages gérés par l'organisation, un plugin ou l'en-tête d'un skill ou d'un sous-agent. Les hooks de plusieurs fichiers se cumulent. Les hooks du projet demandent que l'espace de travail soit approuvé, et tous les hooks correspondants s'exécutent en parallèle.
5. Claude Code plan mode : cadrer avant de modifier
Le plan mode est un mode de permission en lecture seule : Claude lit le code, explore, puis présente un plan d'action. Il ne modifie rien tant que l'équipe n'a pas validé. La documentation des sous-agents le décrit comme la valeur plan du champ permissionMode, à côté de default, acceptEdits, auto, dontAsk et bypassPermissions.
Pour une équipe, le plan mode sert surtout dans trois situations :
- Un changement qui touche plusieurs fichiers : on relit le plan avant d'autoriser les écritures, comme on relit un ticket avant de coder.
- Une zone sensible : authentification, facturation, migrations de base de données.
- Un code inconnu : un développeur qui arrive sur un dépôt demande d'abord un plan d'exploration.
Le plan mode ne remplace pas la revue de code humaine : il déplace la discussion plus tôt, au moment où corriger une direction ne coûte rien. Une bonne pratique d'équipe consiste à coller le plan validé dans la description de la pull request.
6. Exemples d'équipe : revue, conventions, tests, sécurité
Voici comment répartir un même besoin entre les briques. L'idée est qu'une règle ait un seul foyer, choisi selon le niveau de garantie attendu.
| Besoin | Brique recommandée | Mise en œuvre |
|---|---|---|
| Revue de code | Sous-agent | Un code-reviewer en lecture seule, avec la grille de l'équipe dans son prompt |
| Conventions d'API ou de nommage | Skill de référence | Un skill chargé automatiquement sur les nouveaux endpoints |
| Tests | Skill et hook | Un skill décrit la méthode de test ; un hook PostToolUse lance les tests ou le linter après édition |
| Sécurité | Hook et sous-agent | Un hook PreToolUse bloque les commandes destructrices et les fichiers de secrets ; un auditeur en lecture seule relit les changements |
| Changement lourd | Plan mode | Plan validé en équipe avant toute écriture |
Un enchaînement type sur une fonctionnalité
On demande un plan en lecture seule. Après validation, Claude code en s'appuyant sur le skill de conventions. À chaque édition, le hook lance le formateur. Une fois les modifications terminées, le sous-agent relecteur examine le diff dans son propre contexte et renvoie une liste de points. Chacune des quatre briques intervient à un moment où elle est la plus fiable.
À retenir
Ces briques réduisent le travail de relecture, elles ne l'éliminent pas. Un sous-agent de revue signale des points, un humain décide. Un hook de sécurité complète les contrôles de la CI et la gestion des secrets, il ne les remplace pas. Pour les risques liés aux données, voir la sécurité des données avec Claude Code.
7. Partager, versionner et éviter les pièges
Les trois formats vivent dans le dépôt, donc dans Git : .claude/skills/, .claude/agents/ et .claude/settings.json. Ils suivent le cycle habituel : branche, pull request, relecture, fusion. Chaque développeur les récupère en clonant le dépôt. Pour une diffusion au-delà d'un projet, les plugins regroupent skills, sous-agents et hooks, et les réglages gérés permettent à l'organisation de les imposer.
Cinq règles de gouvernance
- Un propriétaire par fichier : une personne responsable de chaque skill, agent ou hook, comme pour du code.
- Relecture en pull request : un hook exécute une commande sur la machine de chaque développeur, il se relit avec la même attention qu'un script d'installation.
- Descriptions précises : c'est la description qui décide si un skill ou un sous-agent est déclenché. Trop vague, il part à tort ; trop étroite, il ne part jamais.
- Droits minimaux : outils restreints pour chaque sous-agent,
disable-model-invocationpour les actions sensibles. - Revue trimestrielle : supprimer ce qui n'est plus utilisé, tester le reste sur un cas réel.
Les pièges fréquents
- Un skill qui ne se déclenche pas : la description ne contient pas les mots que l'équipe emploie. On le lance à la main avec la commande et on corrige la description.
- Des règles critiques écrites dans un skill : la documentation rappelle que les skills restent dans le contexte sans se recharger tout seuls ; pour une règle persistante, un hook est plus sûr.
- Un sous-agent trop bavard ou trop puissant : sans le champ
tools, il hérite de tous les outils disponibles. - Un hook trop lent : un linter complet à chaque édition ralentit tout le monde. On cible avec
matcheret on garde les contrôles longs pour la CI. - Des noms en double : deux sous-agents au même nom créent des conflits, la commande
/doctorpermet de le vérifier.
Les fonctions et les noms de champs évoluent vite d'une version à l'autre : avant un déploiement, relisez les pages sous-agents et hooks de la documentation. Pour un approfondissement technique par un praticien, le blog ianas.fr détaille les frameworks d'agents.
Pour mettre ces pratiques en place sur un vrai dépôt, avec les conventions de votre équipe, notre formation Claude Code part de votre code et de votre CI.
Questions fréquentes sur Claude Code : skills, subagents, hooks et plan mode
Pour aller plus loin
- Guide Claude Code : l'outil, ses usages et sa mise en place en équipe.
- Claude Skills en entreprise : les skills côté bureau, procédures à standardiser et gouvernance.
- Fichier CLAUDE.md d'équipe : les consignes de base du projet.
- Dynamic workflows Claude Code : orchestrer plusieurs agents.
- Formation Claude Code : adopter l'outil en équipe sur un dépôt réel.
