Claude Code s'étend par six mécanismes : les skills, les subagents, les serveurs MCP, les hooks, les plugins et les commandes personnalisées, auxquels s'ajoutent les équipes d'agents. Six briques, et un constat : la plupart des utilisateurs choisissent au hasard. Un serveur MCP parce qu'un post l'a recommandé, une skill parce que c'est nouveau, un hook jamais, parce que personne n'a expliqué à quoi ça sert. Le résultat se voit dans les projets : des contextes encombrés, des règles qui ne s'appliquent qu'une fois sur deux, des mécanismes empilés sans logique.
Ce chapitre remplace le hasard par une grille de lecture en deux questions. À la fin, vous saurez dire, pour n'importe quel besoin, quelle brique le porte. Et, tout aussi important, quand n'en utiliser aucune.
Deux questions suffisent
Première question : est-ce que ça doit se produire à coup sûr ? Certaines choses ne tolèrent pas l'à-peu-près : le lint après chaque édition, les tests avant chaque commit, l'interdiction absolue de toucher à tel dossier. Si l'oubli est inacceptable, il vous faut du déterminisme, et le déterminisme a un nom : le hook, une commande que le système exécute à un événement donné, que Claude le veuille ou non.
Si au contraire il s'agit d'un savoir-faire à mobiliser quand c'est pertinent, rédiger un rapport au format maison, dérouler la procédure de release, alors c'est une skill : Claude décide du moment.
Deuxième question : est-ce que ça pollue mon contexte ? Vous savez depuis le chapitre 2 que la fenêtre de contexte est votre ressource la plus précieuse. Si une tâche exige de lire beaucoup pour conclure peu, fouiller une base de code, comparer des pistes, déléguez-la à un subagent : un contexte isolé dont vous ne recevez que la conclusion. Si au contraire le détail de la tâche nourrit directement la suite de votre session, gardez-la inline, dans le fil principal.
Et MCP ? Il répond à une troisième situation, orthogonale aux deux premières : le besoin de brancher l'extérieur, une base de données, un navigateur, une API. Les plugins, eux, ne sont pas un pouvoir de plus mais un emballage : le moyen de partager tout le reste. Anthropic présente d'ailleurs officiellement ces mécanismes sous une bannière commune, le « steering » : autant de manières de piloter l'agent.
La philosophie vient du créateur de l'outil, Boris Cherny : Claude Code est volontairement un outil de bas niveau, qui n'impose aucun workflow. À vous de le façonner, et c'est exactement ce que ces briques permettent. Reprenons-les une par une, de la plus déterministe à la plus autonome.
Les hooks : ce qui doit arriver arrive
Un hook est une commande shell attachée à un événement du cycle de Claude Code : après une édition de fichier, avant l'exécution d'une commande, avant un commit. Pas d'intelligence, pas d'appréciation : l'événement se produit, la commande s'exécute. C'est précisément sa force. Les trois usages types : le lint qui passe après chaque édition, la suite de tests qui tourne avant chaque commit, et les garde-fous, comme bloquer une commande destructrice ou protéger un répertoire sensible.
❯ claude ❯ Ajoute un champ « motif » au formulaire d'annulation. · Claude édite le fichier... annulation-form.tsx modifié. [hook post-édition] eslint --fix... [hook] 1 import inutilisé supprimé. 0 erreur. Le lint est passé sans que personne le demande.
Le test pour reconnaître un candidat au hook tient en une phrase : « si ça n'arrivait pas une fois sur dix, serait-ce grave ? » Si la réponse est oui, n'en faites jamais une consigne de CLAUDE.md. Une consigne est probabiliste : le chapitre 3 vous a montré le budget d'instructions, et une règle noyée parmi quarante autres finit par sauter. Un hook, lui, est une garantie.
Les skills : le savoir-faire chargé à la demande
Une skill est un dossier contenant un fichier SKILL.md : des instructions, parfois accompagnées de gabarits et de scripts, que Claude charge quand il juge la situation pertinente. Souvenez-vous du collaborateur du chapitre 2, brillant mais doté d'un carnet de taille fixe : la skill est le classeur de procédures qu'il n'apprend pas par cœur, mais qu'il sait ouvrir au bon moment. Le savoir-faire ne coûte du contexte que lorsqu'il sert.
Les bons candidats : le gabarit de votre rapport d'audit, la procédure de release, la charte rédactionnelle, tout savoir-faire maison qui revient régulièrement sans revenir toujours. Démonstration, toujours sur le projet de Talia, la kiné qui nous suit depuis le chapitre 1 :
❯ claude ❯ Rédige le rapport d'audit du cabinet de Talia. · Claude repère la skill « rapport-audit »... Skill chargée : SKILL.md (plan type, ton, gabarit). Le rapport suit la structure maison en 5 parties. rapport-talia.md écrit, prêt pour relecture.
Le point clé : c'est Claude qui décide de charger la skill, sur la foi de sa description. Soignez donc cette description comme une petite annonce : elle doit dire quand utiliser la skill, pas seulement ce qu'elle contient. Si une skill ne se déclenche jamais, le diagnostic est presque toujours le même : sa description ne décrit pas les situations où vous l'attendiez.
Créer ses propres skills : le réflexe qui manque à presque tout le monde
Utiliser les skills existantes, c'est bien. Écrire les siennes, c'est le vrai levier, et c'est ce que presque personne ne fait. Trois symptômes signalent qu'une skill vous manque.
- 01 · La copieVous recollez le même pavé de prompt, à la virgule près, pour la troisième fois cette semaine.
- 02 · La rediteVous réexpliquez à chaque fois « comment on fait ça ici », et vous en oubliez la moitié : il faut deux allers-retours pour récupérer ce que vous saviez déjà.
- 03 · La dériveLe résultat varie d'une fois sur l'autre alors que la procédure, elle, ne varie pas. C'est le symptôme le plus coûteux.
Dans les trois cas, le diagnostic est le même. Le savoir-faire existe, vous l'avez en tête, il n'est simplement écrit nulle part.
Les candidats sont partout dès qu'on les cherche : écrire les tests à la manière de la maison, créer un nouveau module avec l'architecture du chapitre 4, monter le squelette d'un nouveau projet, dérouler une release, produire un rapport client au bon format, instrumenter une page. Les possibilités sont infinies, et c'est précisément le piège : nous y reviendrons en fin de section.
Une skill tient dans un dossier et un fichier, SKILL.md. En tête, deux lignes qui comptent plus que tout le reste : un nom et une description. Cette description est la seule chose que Claude a en permanence sous les yeux ; le corps ne se charge que si elle correspond à ce que vous êtes en train de faire. Vient ensuite la procédure elle-même, écrite comme vous l'expliqueriez à un nouveau venu : les étapes, les conventions, les pièges, ce qu'il ne faut surtout pas faire. À côté du SKILL.md, vous pouvez poser ce que la procédure utilise : gabarits, scripts, exemples de sortie.
Le geste : la faire écrire par Claude, à chaud
N'écrivez pas vos skills à la main. Faites-les écrire par Claude, juste après avoir fait la chose une fois, tant que la session est encore chaude. Il a tout le contexte : les décisions prises, les pièges rencontrés, ce que vous avez corrigé au passage, y compris ce que vous auriez oublié en la rédigeant à froid le lendemain.
❯ claude ❯ On vient de créer le module « facturation » ensemble. ❯ Transforme la procédure qu'on a suivie en skill réutilisable. · Claude relit la session et extrait la procédure... .claude/skills/nouveau-module/SKILL.md créé. description : « créer un module métier (arborescence, CLAUDE.md de module, tests, câblage) » + le gabarit d'arborescence et le CLAUDE.md type. La prochaine fois, une phrase suffira.
C'est pour cela que je parle d'un réflexe et pas d'un chantier : deux minutes en fin de tâche, une fois. La prochaine fois, « crée le module paiement » remplace le pavé de trois cents mots.
S'en servir : automatique, à la main, ou imposé
Une fois la skill posée, vous avez trois régimes. Le régime normal est automatique : Claude reconnaît la situation dans la description et charge la skill sans que vous demandiez rien. Le deuxième est manuel : vous l'invoquez explicitement, par son nom, quand vous voulez la forcer ou quand vous doutez qu'elle se déclenche. Le troisième passe par le brief : une ligne dans le CLAUDE.md du chapitre 3, « toute nouvelle route d'API passe par la skill api-module », et la skill devient la manière officielle de faire dans ce projet.
Rappelez-vous simplement la première question de ce chapitre : si l'oubli est inacceptable, ce n'est plus une consigne qu'il vous faut, c'est un hook.
Reste le revers, et il est réel. Chaque skill installée coûte sa description dans votre contexte, en permanence, et ajoute une option de plus au moment où Claude choisit quoi charger. Dix skills bien nommées accélèrent tout. Quarante skills « au cas où » font l'inverse : elles diluent le choix, allongent le temps de réponse, et finissent par faire charger la mauvaise. C'est le même budget que celui des instructions du chapitre 3, appliqué à un autre étage.
Écrire une skill, ou ne pas en écrire
Ce qui mérite une skill
- Une procédure que vous avez déjà réexpliquée trois fois
- Un format maison que vous voulez identique à chaque fois
- Un enchaînement d'étapes où l'oubli d'une seule coûte cher
- Un savoir-faire que l'équipe doit partager (il partira en plugin)
On évite
- La skill écrite « au cas où », avant le troisième usage
- Celle qui reformule ce que le CLAUDE.md dit déjà
- Celle qui encapsule une tâche que Claude fait très bien sans aide
- Celle qui n'a pas servi depuis un mois : supprimez, git s'en souvient
Les subagents : l'enquêteur qui lit à votre place
Un subagent est une session de travail isolée que votre session principale mandate : une mission, un contexte vierge, un rapport final. Le pattern à retenir porte un nom : l'enquêteur. Il lit quarante fichiers, suit les pistes, croise les indices, et vous ne recevez que la conclusion.
Trois lignes dans votre contexte au lieu de quarante fichiers.
❯ claude ❯ D'où vient la règle des 24 h ? Qui l'utilise, où ? · Claude délègue à un subagent enquêteur... [subagent] 40 fichiers lus dans un contexte isolé. Conclusion : la règle vit dans booking/rules.ts, appelée à 3 endroits (serveur, UI, rappels par mail). Votre contexte n'a reçu que ces trois lignes.
Deux vertus s'ajoutent à l'isolation. La parallélisation, d'abord : plusieurs enquêteurs peuvent creuser plusieurs pistes en même temps, pendant que votre session principale avance. Le regard neuf, ensuite : vous avez vu au chapitre 8 que le testeur doit ignorer ce que le dev a en tête ; un subagent offre cette virginité de contexte sans rouvrir de terminal. Quant au coût de tout ce petit monde, le chapitre 10 montrera qu'un subagent d'exploration n'a pas besoin du même modèle que votre session principale.
MCP : brancher l'extérieur, avec parcimonie
MCP, pour Model Context Protocol, donne à Claude des outils vers le monde extérieur : interroger votre base de données, piloter un navigateur, lire vos maquettes Figma, appeler des API métier. Quand rien d'autre n'y donne accès, c'est la bonne brique, et parfois une brique spectaculaire : voir Claude naviguer dans l'application qu'il vient de coder pour vérifier son travail change la nature de la boucle de vérification du chapitre 6.
Le piège, maintenant, et il est assez répandu pour mériter son paragraphe : un serveur MCP branché coûte du contexte en permanence. La description de chacun de ses outils s'installe dans votre fenêtre, que vous les utilisiez ou non. Dans les projets que je reprends, je retrouve régulièrement des configurations où plusieurs serveurs sont branchés à demeure et n'ont pas servi depuis des semaines.
Du contexte loué à l'année pour un usage de passage.
C'est le « tout-MCP », que le chapitre 13 rangera dans le bestiaire des pièges nommés.
D'où le critère de choix, en trois temps.
- Un CLI mûr existe-t-il ?Pour GitHub, gh ; pour Postgres, psql. Claude sait déjà s'en servir, un CLI ne coûte rien quand il ne sert pas, et il fait souvent mieux que le serveur MCP équivalent.
- Le besoin exige-t-il un flux que seul MCP offre ?Le pilotage d'un navigateur, la lecture de Figma ? Branchez, c'est le bon usage.
- Débranchez ce qui ne sert plusVérifiez de temps en temps avec /context, la commande du chapitre 2, ce que vos serveurs vous coûtent réellement.
Et écrire le sien ?
C'est le cran au-dessus de la skill, et le cas est plus rare, mais il existe. Une skill transmet un savoir-faire : elle n'ouvre aucune porte. Un serveur MCP, lui, expose des outils, c'est-à-dire des fonctions que Claude peut appeler, avec les accès qui vont avec : votre API métier, votre back-office, un service interne qui n'a pas de client en ligne de commande. Voyez-le comme un savoir-faire doublé d'un trousseau de clés. On l'écrit avec le SDK officiel, en quelques dizaines de lignes pour les cas simples, et Claude sait très bien le faire écrire sous votre direction : décrivez les opérations à exposer, il produit le serveur, vous le branchez.
Le moment où ça se justifie est assez précis : plusieurs personnes de l'équipe ont besoin du même accès, aucun CLI ne l'offre, et le besoin est durable. Là, le retour est spectaculaire, votre service interne devient un outil natif pour toute l'équipe, avec les mêmes garanties pour tout le monde. En dehors de ce cas, la réponse sobre reste souvent meilleure : une skill qui documente les appels à faire avec le CLI ou curl que vous avez déjà. Zéro serveur à maintenir, zéro contexte loué à l'année, et le chapitre 13 aura un piège de moins à vous reprocher.
Plugins, commandes personnalisées, équipes d'agents
Restent trois briques, plus vite expliquées.
- PluginsIls empaquettent : skills, hooks, subagents et configuration réunis en un ensemble installable, que l'équipe partage et versionne. C'est la brique du lead. La pratique de l'équipe cesse d'être orale : un nouveau venu installe le plugin et hérite d'un coup des garde-fous et des savoir-faire de la maison.
- Slash commands personnaliséesElles appartiennent à l'histoire récente de l'outil : des raccourcis de prompt qu'on invoquait à la main. Les skills les ont largement remplacées : même service rendu, avec un avantage décisif, Claude sait déclencher une skill de lui-même au moment pertinent. Si vous en maintenez encore, vous savez désormais vers quoi les faire migrer.
- Agent teamsPlusieurs agents coordonnés sur un même chantier, qui se répartissent le travail. C'est le niveau au-dessus du subagent, et la tentation est grande de commencer par là. Résistez-y le temps qu'il faut : une équipe d'agents amplifie votre méthode, y compris ses défauts. Tant que la chaîne de rôles du chapitre 8 ne tourne pas proprement en solo, la faire jouer par plusieurs agents multiplie surtout le bruit.
Le tableau de choix
La grille entière tient dans un tableau. Gardez-le à portée de main : c'est le seul passage du chapitre qui mérite d'être relu au moment de choisir.
| Je veux... | La bonne brique |
|---|---|
| Le lint après chaque édition, sans exception | Hook |
| Les tests avant chaque commit, garanti | Hook |
| Bloquer une commande à risque, protéger un dossier | Hook (garde-fou) |
| Un gabarit ou une procédure maison, mobilisés au bon moment | Skill |
| Arrêter de recoller le même pavé de prompt | Une skill, écrite par Claude en fin de tâche |
| Donner à l'équipe l'accès à une API maison sans CLI | Un serveur MCP, écrit pour l'occasion |
| Explorer une grosse base de code sans saturer ma session | Subagent |
| Mener plusieurs recherches indépendantes en parallèle | Subagents |
| Un regard neuf (testeur, réviseur du chapitre 8) | Session séparée ou subagent |
| Interroger ma base, piloter un navigateur, lire Figma | MCP |
| Parler à GitHub | Le CLI gh, avant tout serveur MCP |
| Partager la pratique de l'équipe | Plugin |
| Un raccourci de prompt | Une skill (les commandes custom sont dépassées) |
| Plusieurs agents coordonnés sur un chantier | Agent team |
Questions fréquentes sur la boîte à outils
Comment créer une skill Claude Code ?
Une skill est un dossier contenant un fichier SKILL.md : un nom, une description qui dit dans quelles situations l'utiliser, puis la procédure écrite comme pour un nouveau venu, avec les gabarits et scripts qu'elle utilise. Le meilleur moyen de l'écrire n'est pas de l'écrire : demandez-le à Claude juste après avoir fait la tâche une fois, dans la même session. Il a encore en mémoire les décisions prises et les pièges rencontrés, et il en tire une procédure plus fidèle que ce que vous rédigeriez de mémoire le lendemain.
Combien de skills faut-il installer ?
Le moins possible, et pas une de plus. Chaque skill coûte sa description dans le contexte en permanence, et ajoute une option au moment où Claude choisit quoi charger : quarante skills « au cas où » diluent le choix, ralentissent les réponses et finissent par en faire charger une mauvaise. Le bon déclencheur n'est pas l'idée d'une skill possible, c'est la troisième répétition d'une même explication. Et une skill qui n'a pas servi depuis un mois se supprime.
Skill ou MCP : comment choisir ?
Les deux ne répondent pas à la même question. Une skill embarque un savoir-faire, instructions, gabarits, scripts, que Claude charge quand c'est pertinent : elle ne donne accès à rien de nouveau. Un serveur MCP donne accès à l'extérieur : base de données, navigateur, Figma, API. Si le besoin est « faire comme il faut », c'est une skill. Si le besoin est « atteindre un système », c'est MCP, après avoir vérifié qu'un simple CLI ne fait pas mieux : un serveur branché coûte du contexte en permanence.
Qu'est-ce qu'un subagent dans Claude Code ?
Un agent mandaté par votre session principale, avec sa propre fenêtre de contexte : il reçoit une mission, travaille isolé, et ne rend que sa conclusion. L'intérêt est double. Votre contexte reste propre : le subagent peut lire quarante fichiers, vous ne recevez que trois lignes. Et plusieurs subagents peuvent travailler en parallèle sur des pistes indépendantes. C'est aussi un moyen d'obtenir un regard neuf, dans l'esprit des rôles séparés du chapitre 8.
À quoi servent les hooks ?
À garantir. Un hook attache une commande shell à un événement du cycle de Claude Code : après chaque édition, avant chaque commit. Elle s'exécute systématiquement, sans que Claude ait à en décider. On y met tout ce qui ne tolère pas l'oubli : le lint, les tests, les garde-fous de permissions. La règle pratique : toute consigne de CLAUDE.md qui peut devenir un hook doit le devenir, car une consigne est probabiliste quand un hook est certain.
La suiteLa boîte à outils est complète ; reste à payer juste. Au chapitre 10 : quel modèle pour quelle tâche, comment lire sa consommation, et les réflexes qui allègent la facture sans rien céder sur la qualité.
David Silvera
Développeur mobile & web freelance · 15 ans · Android, iOS, React Native, Next.js
Ce guide est tiré de ma pratique quotidienne : ce site lui-même est développé avec Claude, selon la méthode qu'il enseigne. J'accompagne aussi les équipes qui veulent monter en compétence : audit de pratique, formation, mise en place d'outillage.
Discutons de votre équipe