Chapitre 1.4 — La carte des briques
⏱️ TL;DR — Claude Code s’étend avec six briques qu’on confond tout le temps :
CLAUDE.md(mémoire toujours présente), skills (capacités à la demande), subagents (instances déléguées à contexte isolé), hooks (automatismes garantis par le harness), serveurs MCP (outils externes), plugins (paquets de distribution). Chacune répond à une question différente. Ce chapitre est la carte : savoir laquelle utiliser quand est déjà 80 % de la maîtrise. Les parties suivantes creusent chaque brique.
🎯 Objectifs
- Nommer les six briques d’extension et la question à laquelle chacune répond.
- Choisir la bonne brique face à un besoin concret (arbre de décision).
- Éviter les confusions classiques (skill vs commande vs hook vs plugin).
- Savoir où chaque brique est traitée en détail dans le playbook.
Les six briques, une question chacune
| Brique | Répond à… | Chargement | Détaillée en |
|---|---|---|---|
CLAUDE.md (mémoire) | « Que doit-il toujours savoir sur ce projet ? » | permanent, dès le start | Partie 3 |
| Skill | « Quelle capacité réutilisable lui donner, à la demande ? » | à la demande (pertinence) | Partie 9 |
| Subagent | « Quelle sous-tâche déléguer dans un contexte propre ? » | à l’invocation | Partie 8 |
| Hook | « Que faire automatiquement, à chaque fois ? » | événement (harness) | Partie 7 |
| Serveur MCP | « À quel outil/donnée externe le connecter ? » | connecté à la session | Partie 10 |
| Plugin | « Comment distribuer/installer un paquet d’extensions ? » | installé | Partie 10 |
Retiens surtout deux axes qui expliquent presque tous les choix :
- Axe « chargement » : le
CLAUDE.mdest toujours là (donc garde-le court — unCLAUDE.mdobèse mange le contexte de chaque tâche). Une skill ne coûte que quand elle sert. Un hook ne vit pas dans le contexte du tout. - Axe « déclencheur » : tout est invoqué (par toi ou le modèle) sauf le hook, qui se déclenche tout seul. C’est LA distinction à ne jamais oublier.
⚠️ Piège — Mettre dans le
CLAUDE.mdune règle du type « lance toujours prettier après chaque édition ». Le modèle peut l’oublier (c’est du texte parmi d’autres). Si tu veux une garantie, c’est un hook : le harness l’exécute mécaniquement, sans dépendre de l’attention du modèle. Convention →CLAUDE.md. Automatisme garanti → hook.
L’arbre de décision
Face à un besoin, descends cet arbre :
Quelques applications concrètes :
| Besoin | Bonne brique |
|---|---|
« Respecte nos alias d’import @/… » | CLAUDE.md (convention) |
| « Formate le code après chaque édition » | Hook (garanti) |
| « Sais générer une PR bien décrite quand je le demande » | Skill / commande |
| « Analyse ces 2000 lignes de logs sans polluer ma session » | Subagent |
| « Lis le schéma de ma base Postgres » | Serveur MCP |
| « Installe la panoplie revue+commit de mon équipe » | Plugin (marketplace) |
💡 Réflexe d’architecte — La plupart des configs Claude Code illisibles viennent d’une brique utilisée pour le mauvais job : des automatismes noyés dans un
CLAUDE.mdgéant, des conventions dupliquées dans dix skills, un serveur MCP là où les outils natifs suffisaient. Un bon setup, c’est la bonne brique au bon endroit, et le moins de briques possible.
Ce que tu as probablement déjà (sans le savoir)
Si tu utilises déjà Claude Code, tu as sans doute :
- des skills installées (par ex.
caveman,grill-me,write-a-skill,prototype,handoff…) — on les passera en revue en Partie 9 ; - peut-être un plugin officiel (
claude-code-setup) et sa marketplace (claude-plugins-official) — Partie 10 ; - un
settings.jsonminimal (modèle, permissions) sans hooks — on va justement en ajouter en Partie 7.
Tout le playbook consiste à passer de « j’ai des briques posées un peu au hasard » à « chaque brique a une raison d’être et un emplacement juste ».
📚 Aller plus loin — Anthropic a publié un guide de « pilotage » qui recoupe cette carte : quand choisir
CLAUDE.md, skills, hooks, subagents. On s’y réfèrera ; garde en tête l’axe toujours-présent vs à-la-demande vs hors-contexte.
✏️ Exercices
Exercice 1 — Range tes besoins. Écris 6 besoins réels de ton quotidien de dev, puis fais-les passer dans l’arbre de décision. Combien tombent sur « hook » alors que tu les gérais « à la main » jusque-là ?
✅ Solution
Les candidats hooks les plus fréquents : formater/linter après édition, lancer les tests avant de conclure, bloquer une édition d’un fichier interdit, empêcher un commit sur main. Si tu répétais ces consignes à chaque session, tu payais un coût inutile : ce sont des automatismes, donc des hooks (Partie 7).
Exercice 2 — Audit express. Ouvre ton ~/.claude : liste tes skills installées et regarde ton settings.json. As-tu des hooks ? une skill que tu n’utilises jamais ? Note ce que tu voudras nettoyer/ajouter en avançant dans le playbook.
✅ Solution
Beaucoup de setups ont plusieurs skills installées mais zéro hook — c’est le gisement d’amélioration numéro un. À l’inverse, des skills jamais déclenchées encombrent la liste : on verra en Partie 9 comment garder un set net et pertinent.
🧠 Quiz de révision
1. Quelle est la seule brique qui se déclenche « toute seule » ?
Le hook : c’est le harness qui l’exécute sur un événement, sans invocation par toi ni par le modèle. Toutes les autres briques sont invoquées.
2. Pourquoi garder le CLAUDE.md court ?
CLAUDE.md court ?Parce qu’il est chargé en permanence : il coûte du contexte à chaque tâche. Un CLAUDE.md obèse dilue l’attention de l’agent et le pousse à ignorer une partie des règles. On y met l’essentiel universel, pas tout.
3. Convention de code vs automatisme mécanique : quelle brique pour chaque ?
Convention (« utilise nos alias d’import ») → CLAUDE.md. Automatisme garanti (« formate après chaque édition ») → hook. Ne jamais compter sur le CLAUDE.md pour garantir un automatisme.
4. Tu dois analyser un énorme log sans encombrer ta session. Quelle brique ?
Un subagent : il travaille dans son propre contexte et te renvoie juste la conclusion, gardant ta session principale nette.
5. Skill, plugin, serveur MCP : lequel est un « paquet de distribution » ?
Le plugin. Il peut contenir des skills, des commandes, des hooks, de la config MCP, et s’installe depuis une marketplace. Une skill est une capacité ; un serveur MCP est un connecteur d’outils externes.
Fin de la Partie 1. Tu as le bon modèle mental et la carte des briques. On passe à l’action : Partie 2 — Cadrer un nouveau projet, là où se joue « comment donner la bonne direction dès le départ ».