Cinq briques, un seul système

Tu as déjà les pièces

Si tu utilises Claude Code depuis quelques semaines, tu as sans doute un CLAUDE.md. Peut-être aussi un skill, un hook, ou un serveur MCP branché sur un outil. Chaque pièce marche. Mais chacune vit dans son coin, et tu ne sais pas toujours laquelle prendre.

Cette formation ne réexplique pas chaque brique en détail : le site a une formation pour chacune. Ici, on les assemble. D'abord comprendre ce que fait chaque brique et comment elles se parlent. Ensuite monter un vrai système. Enfin l'emballer dans un plugin, un paquet que Claude Code installe en une commande, et le partager.

Les cinq briques en une phrase

• CLAUDE.md : un fichier texte que Claude Code lit en entier au début de chaque session. Il porte ce que Claude doit toujours savoir : les commandes du projet, les conventions.
• Le skill : un dossier avec un fichier SKILL.md, qui décrit un savoir-faire. Au départ, Claude ne voit que sa description. Le contenu complet arrive quand le skill sert, lancé par toi avec /nom ou choisi par Claude.
• Le hook : une commande que Claude Code lance lui-même à un moment précis, par exemple avant chaque commande du terminal. Le modèle ne décide pas s'il s'exécute.
• Le serveur MCP : un programme qui donne à Claude des outils vers un système extérieur, comme un navigateur, GitHub ou une base de données. MCP (Model Context Protocol) est le standard qui fait le lien.
• Le sous-agent : un autre Claude, lancé pour une tâche, qui travaille dans sa propre fenêtre de contexte et ne te rend qu'un résumé.

La fenêtre de contexte, c'est tout ce que le modèle a sous les yeux pendant une conversation : tes messages, les fichiers lus, les consignes. Elle a une taille limitée, et tout ce qui y entre compte dans ta consommation.

Pour le détail des briques, les deux formations les plus proches de celle-ci sont Les hooks et Les skills.

Trois questions pour ne plus les confondre

Sur le papier, les cinq briques se ressemblent : ce sont presque toutes des fichiers texte. Trois questions suffisent à les séparer.

Qui la déclenche ?

• CLAUDE.md : personne. Il est toujours là.
• Le skill : toi, avec /nom, ou Claude, quand ta demande correspond à sa description.
• Le hook : un événement de la session. Ni toi ni Claude.
• Le serveur MCP : Claude, quand il appelle un de ses outils.
• Le sous-agent : Claude, qui lui délègue une tâche, ou toi, en le nommant.

Quand entre-t-elle dans le contexte ?

• CLAUDE.md : en entier, à chaque échange.
• Le skill : sa description dès le départ, son contenu seulement quand il sert. Un skill que toi seul peux lancer n'entre même pas avant que tu l'appelles.
• Le hook : jamais, sauf s'il renvoie un texte à Claude.
• Le serveur MCP : le nom de ses outils au départ, leur détail à l'usage.
• Le sous-agent : il a sa propre fenêtre. Seul son résumé revient dans la tienne.

Où travaille-t-elle ?

• CLAUDE.md et le skill : dans ta conversation, sous forme de consignes.
• Le hook et le serveur MCP : hors du modèle, dans des programmes qui tournent sur ta machine (ou chez un hébergeur, pour un serveur MCP distant).
• Le sous-agent : dans une conversation à part.

Le schéma

Lis-le de gauche à droite. Trois briques agissent sur la session : CLAUDE.md et les skills lui donnent des consignes, les hooks réagissent à ce qui s'y passe. Les deux autres travaillent pour elle : le serveur MCP va chercher ce que Claude ne voit pas, le sous-agent fait le travail long à l'écart.

Un système, pas une pile d'outils

La documentation officielle le dit simplement : chaque brique règle un problème différent, et une vraie installation les combine. Elle donne quatre combinaisons courantes :

• skill et MCP : le serveur fournit la connexion, le skill apprend à Claude à bien s'en servir ;
• skill et sous-agent : un skill lance des sous-agents qui travaillent chacun de leur côté ;
• CLAUDE.md et skills : la règle courte toujours chargée, le détail dans un skill chargé à la demande ;
• hook et MCP : un hook déclenche une action extérieure, par exemple un message quand Claude touche un fichier sensible.

C'est ce qui se passe sur ma chaîne de vidéos. Le CLAUDE.md du projet porte les règles. Des skills comme /nouveau-tip déroulent la fabrication d'une vidéo. La lecture des fichiers .env est refusée par une règle de permission, pas par une phrase. Et pour des captures de pages privées, Claude a piloté mon navigateur à travers un serveur MCP. Chaque brique fait sa part, et aucune n'essaie de faire celle d'une autre.

Le vrai problème : tout reste dans un dossier

Ces briques vivent à des endroits différents : .claude/skills/, .claude/agents/, .claude/settings.json pour les hooks, .mcp.json pour les serveurs. Elles marchent dans ce projet-là. Le jour où un deuxième projet en a besoin, tu recopies. Puis tu corriges une copie, et tu oublies l'autre.

La documentation a un signal pour ce moment : quand un deuxième dépôt a besoin de la même installation, fais-en un plugin. Un plugin réunit les skills, les agents, les hooks et les serveurs MCP dans un seul dossier, que Claude Code installe et met à jour d'un bloc.

Ce que la suite t'apporte

• La leçon suivante, gratuite : ce qu'un plugin emballe, et l'installation d'un vrai plugin depuis la marketplace officielle, en une commande.
• Chapitre 2 : un arbre de décision pour choisir la bonne brique, les branchements entre briques (un agent qui reçoit des skills et un serveur MCP, un hook qui appelle un outil MCP), puis un système complet qui prépare une mise en ligne, testé sous Windows.
• Chapitre 3 : emballer ce système dans ton propre plugin, le publier dans ta marketplace sur un dépôt git, sortir des versions, et relire un plugin avant de l'installer.

Sources

Pages officielles vérifiées le 19 octobre 2026 (Claude Code 2.1.303) :

• Extend Claude Code : rôle de chaque brique, moment où elle se charge, combinaisons courantes
• Plugins overview : ce qu'est un plugin et quand en faire un
• Hooks reference : hooks déclenchés par les événements de la session