Dans les cinq chapitres précédents, vous avez installé Claude Code, donné des instructions, dénoué des blocages et conçu vos permissions. Ce chapitre parle de transformer l'outil lui-même. Retenir le nom des extensions ne sert à rien. Ce qui sert, c'est un tableau de correspondance : « lequel résout la gêne que j'ai en ce moment ? »
Une carte pour choisir : quatre questions décident
Il y a six extensions, mais seulement quatre choses à se demander. Une demande suffit-elle ? Voulez-vous que cela s'applique à coup sûr ? Voulez-vous séparer le contexte ? Voulez-vous vous relier à l'extérieur ? Posez-vous ces questions dans cet ordre, et la réponse est presque toujours unique.
Si un oubli occasionnel n'est pas grave, des mots suffisent. → CLAUDE.md (les prémisses générales) ou Skills (la procédure d'un travail précis)
Si un seul oubli pose problème, arrêtez-le par un dispositif. → hooks. Ils s'exécutent toujours, sans passer par le jugement du modèle.
Si vous ne voulez pas noyer le fil principal sous une sortie massive, faites travailler dehors et ne recevez que la conclusion. → subagents
S'il faut des informations que l'IA ne peut pas connaître (la valeur actuelle en base, le contenu d'un suivi de tickets). → MCP
La cinquième question, c'est « est-ce que je le distribue à d'autres ? » : si oui, plugins. Ce qui se confond le plus facilement, ce sont Q1 et Q2, c'est-à-dire CLAUDE.md, Skills et hooks. Ils se ressemblent tous, mais ce qui les sépare, c'est quand ils sont lus et qui les exécute.
CLAUDE.md : une mémoire qui dure, jusqu'à ce qu'elle s'allonge trop
CLAUDE.md, posé à la racine du projet, est un fichier lu automatiquement à chaque session (pour tous les projets, ce sera ~/.claude/CLAUDE.md). Comme c'est un fichier, il échappe au « quand ça traîne, le début se perd » vu au chapitre 1. C'est l'endroit où ranger ce que vous expliquez chaque fois.
Le « il dit qu'il l'a lu et il ne le respecte pas » n'est pas de la négligence mais un problème de structure, avec trois causes.
- Le milieu s'enfonce — les consignes situées au milieu d'un long texte se laissent facilement oublier, et plus vous allongez, plus les règles du centre disparaissent de fait
- La compression les résume — quand la compression se déclenche, les règles opérationnelles fines sont écrasées. C'est pour cela que les manquements augmentent vers la fin
- La consigne la plus récente l'emporte — un « committe, allez » fait passer par-dessus la procédure de contrôle lue plusieurs centaines de tours plus tôt
Le remède, c'est de retirer. Empiriquement, ce qui fonctionne à coup sûr va jusqu'à 100 ou 150 lignes environ. Au-delà, ne gardez en tête de fichier que les règles vitales et renvoyez le détail vers un autre fichier (les doublons créent des divergences, donc une seule source de vérité). Marquez « CRITICAL » uniquement ce qui ne peut pas tomber, et donnez à chaque règle une forme jugeable de l'extérieur : plutôt que « écris soigneusement », « écris en trois lignes maximum ».
« Je l'ai lu » n'est pas une preuve. Le seul élément de jugement est le comportement après exécution. Une règle qui n'est pas respectée quel que soit le nombre de réécritures n'est pas un problème de rédaction : c'est le travail de la section suivante.
hooks : pas une demande, une certitude
« Ne réécris pas .env » : écrit dans CLAUDE.md, c'est respecté neuf fois sur dix. Si le dixième cas ne vous gêne pas, une phrase suffit. S'il vous gêne, ce sont les hooks. Voilà le point de bascule.
Un hook est une commande shell exécutée automatiquement à un moment défini. Ce n'est pas le modèle qui la lance mais Claude Code lui-même (le harnais), donc elle part sans attendre de jugement. La vue d'ensemble est traitée dans Qu'est-ce que les hooks de Claude Code ?. Il y a neuf points de déclenchement classiques.
SessionStart au démarrage ou à la reprise
UserPromptSubmit juste après votre envoi [peut bloquer]
PreToolUse juste avant un outil = portier [peut bloquer]
PostToolUse après le succès d'un outil = formatage [peut bloquer]
Notification en attente de saisie ou d'accord
Stop fin d'une réponse [peut bloquer]
SubagentStop sous-agent terminé [peut bloquer]
SessionEnd fin de session
PreCompact avant la compression [peut bloquer]
« Peut bloquer » veut dire que l'on peut arrêter l'action à cet endroit. Refuser une commande dangereuse dès PreToolUse, formater automatiquement avec PostToolUse : ces deux-là sont les portes d'entrée classiques. La configuration s'écrit sous la clé "hooks" de settings.json, et l'emplacement décide de la portée (~/.claude/ pour vous, .claude/ pour le partage, settings.local.json pour vous seul).
{ "hooks": {
"PostToolUse": [
{ "matcher": "Edit|Write",
"hooks": [ { "type": "command", "command": "..." } ] }
] } }
La structure : un nom d'événement, puis un tableau de motifs et de commandes. Le matcher vise des noms d'outils (séparés par | comme dans "Edit|Write" ; omis, il correspond à tout). Un hook reçoit du JSON sur l'entrée standard et répond par son code de sortie : 0 pour un succès, 2 pour un blocage (la sortie d'erreur standard est alors transmise à Claude). Le chemin du fichier visé se lit aussi dans le JSON d'entrée, ce qui permet d'écrire « si c'est ce chemin, on arrête ».
Un hook peut resserrer les restrictions, jamais les desserrer. Même s'il renvoie une autorisation, il ne fait qu'éviter la demande, et les règles de refus restent toujours prioritaires. Comme un refus émis par PreToolUse agit même dans le mode qui saute toutes les validations, il peut servir de plancher à ce que vous avez relâché au chapitre 5.
Le prix à payer, aussi, d'avance. Un hook exécute automatiquement n'importe quelle commande shell avec vos droits. La documentation officielle précise elle-même que la responsabilité vous incombe entièrement. Ne configurez que ce en quoi vous avez confiance, et validez les entrées. La configuration est figée au démarrage de la session, donc si « je l'ai corrigé et ça ne prend pas », ouvrez une nouvelle session.
subagents : déléguer dans un contexte séparé
La sortie complète d'une suite de tests, un journal énorme : quand des masses de texte destinées à être jetées s'accumulent, ce sont les prémisses essentielles qui sont poussées dehors. Les subagents sont le dispositif qui fait tourner ce travail dans un autre contexte et n'en rapporte qu'un résumé de la conclusion. Ils ont leur propre fenêtre de contexte, leur propre invite système et leurs propres permissions d'outils, et comme ils ne voient pas votre historique de conversation, les débris de la recherche ne reviennent pas dans le fil principal.
- Séparer paie — enquête large, contrôle produisant une sortie massive, tâche autonome dont seule la conclusion importe
- Séparer coûte — traitement séquentiel, allers-retours fréquents, travaux parallèles qui touchent le même fichier, correction qui tient en un ou deux gestes
C'est une fonction native, utilisable sans configuration. Pour ajouter une définition, écrivez .claude/agents/<nom>.md (ou ~/.claude/agents/ pour tous les projets) avec name / description / tools / model dans l'en-tête YAML. La gestion passe par /agents, l'appel par @agent-<nom>. Commencez par ceux fournis d'origine : exploration, planification, usage général.
C'est la description qui est la clé de l'appel. L'agent principal la lit pour décider s'il délègue, donc si elle est vague, il n'appellera jamais. Soyez concret sur ce que ça fait et quand l'utiliser : le même piège existe pour les Skills.
À ne pas confondre, les Agent Teams sont un dispositif où plusieurs sessions indépendantes se coordonnent par une liste de tâches partagée. C'est expérimental, sur adhésion, désactivé par défaut (CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1). Comme d'autres instances tournent, la consommation de tokens est forte, et on ne peut pas les imbriquer. La comparaison est faite dans La différence entre subagents et Agent Teams. Dans le doute, une session unique ou des subagents.
Skills : transformer des procédures en capital
Face à un « à chaque fois, cette procédure », ce qui fait la supériorité des Skills, c'est qu'ils ne s'ouvrent qu'au moment utile. Concrètement, c'est un dossier organisé autour d'un SKILL.md. En tête, name et description ; en dessous, la procédure en Markdown ; et vous pouvez y joindre reference/ ou scripts/. Il suffit de le poser dans .claude/skills/ (le projet) ou ~/.claude/skills/ (tous les projets) pour qu'il soit reconnu.
Le point capital, c'est la divulgation progressive. Au démarrage de la session, seule la courte description de chaque skill est lue, et le corps du texte et les documents ne se chargent que si la demande y correspond. C'est pourquoi vous pouvez en installer des dizaines sans que votre contexte habituel se remplisse : voilà la différence décisive avec CLAUDE.md, toujours chargé en entier. Le revers, c'est qu'en l'absence de correspondance, ils ne s'ouvrent jamais. Si la description est vague, la procédure que vous avez écrite n'existe pas. La façon de la rédiger est traitée dans Qu'est-ce que les Claude Agent Skills ?.
En une ligne. CLAUDE.md = les prémisses toujours lues, Skills = le mode d'emploi que Claude décide d'ouvrir, hooks = le traitement qui s'exécute à coup sûr.
MCP : tendre la main vers les systèmes extérieurs
Les trois précédents étaient des extensions qui changent la manière de faire. Seul MCP (Model Context Protocol) élargit ce que l'on peut atteindre : c'est une norme pour toucher ce que l'IA ne peut structurellement pas connaître, comme la valeur actuelle en base ou le ticket d'un suivi de projet. Il y a deux formes de connexion, et elles ne coincent pas au même endroit.
- Local (stdio) — le serveur démarre comme sous-processus sur votre machine. Ce qui coince, c'est le démarrage lui-même : chemins, variables d'environnement, résolution de la commande
- Distant (HTTP) — connexion par URL à un serveur dans le cloud. Ce qui coince, c'est presque toujours l'authentification : un 401 ou un 403 qui revient
Alors ne mettez pas tous les « ça ne se connecte pas » dans le même sac : commencez par regarder l'état avec /mcp. failed renvoie au démarrage local, needs authentication à l'authentification distante, pending approval à une validation en attente. C'est l'état qui décide du geste. Les remèdes sont réunis dans Comment réparer les erreurs de connexion aux serveurs MCP.
Quelques pièges propres à MCP. Le .mcp.json partagé va à la racine du dépôt (ni sous .claude/, ni à l'intérieur de settings.json), et les clés API vont dans le env de chaque serveur. Sous Windows, comme npx est en réalité un fichier de commandes, cela passe en le donnant via cmd sous la forme /c npx ....
Un serveur branché consomme du contexte. Le simple empilement des définitions d'outils comprime le contexte. Le plus sage est de désactiver les serveurs que vous n'utilisez pas.
plugins : rassembler un ensemble et le distribuer
Quand les skills, les définitions de sous-agents, les hooks et les réglages MCP commencent à s'éparpiller, les plugins servent à en faire un ensemble distribuable. Ce que l'on rate le plus souvent, ce sont les conventions de répertoires. Le manifeste est .claude-plugin/plugin.json, et c'est la seule chose à mettre dans .claude-plugin/. skills/, agents/, hooks/hooks.json et .mcp.json se posent à la racine.
/plugin marketplace add owner/repo ← enregistrer un catalogue
/plugin install name@marketplace ← en installer un depuis ce catalogue
/plugin list ← vérifier ce qui est installé
L'installation se fait en deux temps. Enregistrer le catalogue, puis installer individuellement : l'ajout seul n'installe rien. Les portées sont user (tous vos projets), project (tous les collaborateurs), local (vous seul) et managed (distribué par l'administration, non modifiable) ; pour aligner une équipe, c'est project. La marche à suivre pour en fabriquer un est traitée dans Que sont les plugins et le marketplace ?.
Un plugin peut exécuter n'importe quel code avec vos droits : c'est écrit noir sur blanc dans la documentation officielle. Anthropic ne vérifie ni les plugins tiers ni les serveurs MCP qu'ils embarquent. N'installez que ce qui vient d'un éditeur en qui vous avez confiance. La conception des permissions du chapitre 5 revient ici sous la forme de code écrit par quelqu'un d'autre.
Par quoi commencer : un mot sur l'ordre
Six extensions ont été alignées, mais il n'est pas nécessaire de tout installer. En installer avant d'avoir le problème n'ajoute que de la complexité de configuration. L'ordre part du symptôme.
- Vous donnez toujours la même explication → CLAUDE.md. Si cela ne concerne qu'un travail précis, plutôt Skills
- C'est écrit et ce n'est pas respecté → d'abord retirer. Passer aux hooks seulement pour ce qui cause un vrai dommage
- Le contexte se remplit tout de suite → confier les recherches lourdes aux subagents, et désactiver les MCP inutiles
- L'IA n'atteint pas l'information → MCP. Branchez un serveur à la fois, et passez au suivant une fois celui-ci fonctionnel
- Vous voulez distribuer les mêmes réglages → plugins. Ne rassemblez que ce que vous utilisez déjà vous-même
- Rien ne vous gêne particulièrement → n'installez rien. C'est le meilleur des états
La dernière ligne n'est pas une plaisanterie. Les extensions multiplient aussi les causes de blocage : le « Claude Code est bizarre » se révèle souvent être une couche que vous avez ajoutée vous-même. C'est pour cela que le diagnostic du chapitre 4 vient d'abord.
Résumé
- Le critère de choix, ce sont quatre questions : une demande suffit-elle (CLAUDE.md, Skills), voulez-vous que cela s'applique à coup sûr (hooks), voulez-vous séparer le contexte (subagents), voulez-vous vous relier à l'extérieur (MCP). Pour distribuer, plugins
- CLAUDE.md est la mémoire qui traverse les sessions. Trop long, le milieu s'enfonce, la compression le dilue, et la consigne la plus récente l'emporte. Retirez et affichez les priorités
- Les hooks sont exécutés par le harnais, donc aucun jugement n'intervient. Ils peuvent resserrer les restrictions, pas les desserrer
- Les subagents travaillent dans un autre contexte et ne rendent qu'un résumé. Ils ne conviennent ni au traitement séquentiel ni aux allers-retours fréquents
- Les Skills ne s'ouvrent que si la
descriptioncorrespond : c'est la divulgation progressive. En ajouter reste léger, mais une description vague fait qu'ils ne sont jamais appelés - MCP est la norme qui élargit ce que l'on peut atteindre. C'est l'état affiché par
/mcpqui décide du geste - Les plugins sont la boîte de distribution. Du code écrit par d'autres tourne avec vos droits, alors vérifiez l'éditeur
- L'ordre d'installation part du symptôme. Un élément à la fois, une fois la gêne apparue
Plus vous étendez, plus la consommation augmente. Pour finir, nous traitons l'exploitation sur la durée. Passez au chapitre 7, « Coût et limites ».