Choisir ses fonctionnalités : CLAUDE.md vs Skill vs Hook vs MCP vs Subagent
📚 Navigation de la série : L'article précédent 29 Agent teams 智能体团队 vous a appris à utiliser Agent teams pour la collaboration parallèle multi-agents. Cet article clôture la quatrième partie — après avoir étudié CLAUDE.md, Skill, Hook, MCP et Subagent, il est easy de s'y perdre. Je vous propose un tableau décisionnel et un arbre de décision pour associer directement votre « besoin » à « l'outil adéquat » sans aucune hésitation.
À ce stade, vous disposez d'un grand nombre de points d'extension.
CLAUDE.md, Skill, Hook, MCP, Subagent, sans oublier les commandes slash (slash command) omniprésentes... Autant de termes que vous comprenez individuellement. Pourtant, dès qu'il s'agit de déterminer quel outil convient à un besoin précis, vous risquez fort de bloquer. Les questions les plus fréquentes après avoir découvert cet ensemble sont : « Dois-je utiliser un Skill ou un Subagent pour cela ? » ou « Puis-je simplement consigner cette consigne dans CLAUDE.md ? »
En clair, le problème n'est pas le manque de connaissances, mais l'absence d'une correspondance claire entre « besoin » et « solution ». Vous avez lu la présentation officielle de chaque point d'extension, mais elles sont organisées selon la question « qu'est-ce que c'est », et non « qu'avez-vous besoin de faire ». Cet article adopte l'approche inverse : partir de votre besoin pour déterminer l'outil approprié.
Pour le dire ainsi : les chapitres précédents vous ont mis ces outils en main un par un, et cet article vous apprend lequel dégainer le moment venu.
À la fin de cet article, vous obtiendrez :
- Une définition rapide de ce que chaque point d'extension (y compris slash command) résout, quand le choisir et quand l'éviter
- Un tableau décisionnel « besoin → solution recommandée » pour trouver le bon remède
- Un arbre de décision facile à suivre : trois ou quatre questions suffisent à verrouiller votre choix
- Une analyse comparative des paires les plus sujettes à confusion (Skill vs Subagent, CLAUDE.md vs Skill, Hook vs Règles de permission)
- Les clés pour combiner ces points d'extension et les distribuer sous forme de plugin
01 Bâtir une vision globale : Six points d'extension répartis dans la « boucle de l'agent »
Avant de choisir, posez les bases dans votre esprit. Ces points d'extension ne sont pas six options équivalentes, mais six points d'ancrage situés à différentes étapes du flux de travail de Claude.
Rappelez-vous la « boucle de l'agent » abordée dans le chapitre 03 : le travail de Claude se résume au cycle « penser → agir → observer ». Ces six points d'extension (CLAUDE.md, Skill, slash command, MCP, Subagent, Hook) viennent s'insérer précisément dans les différentes phases de cette boucle : certains enrichissent le contexte avant de « penser », d'autres permettent de se connecter à l'extérieur ou de créer un clone au moment d'« agir », tandis que d'autres encore déclenchent des actions automatiques à des moments précis. La documentation officielle le résume très bien :
Les extensions s'insèrent dans différentes parties de la boucle de l'agent.
Analogie : l'accueil d'un hôpital. Si vous ne vous sentez pas bien, vous ne foncez pas au hasard dans un service. Vous passez d'abord par l'accueil pour décrire vos « symptômes » : mal de tête vers la neurologie, mal de ventre vers la gastro-entérologie, radiographie vers la radiologie. L'accueil ne soigne pas, son rôle est de vous orienter vers le bon service selon vos symptômes. Dans cet article, je joue le rôle de cet accueil : vous me présentez votre « besoin » et je vous oriente vers le bon « point d'extension ».
En situation réelle, vos interrogations tournent souvent autour de ces phrases : « Je veux qu'il respecte cette règle à chaque fois », « Je veux qu'il appelle automatiquement cette compétence si nécessaire », « Je veux que cette action se produise automatiquement à un moment donné », ou « Je veux le connecter à des données ou des services externes ». Une fois le besoin exprimé clairement, l'orientation devient évidente. Les sections suivantes détaillent chaque service, avant de vous proposer un tableau de synthèse et un arbre décisionnel.
💡 Résumé en une phrase : Les six points d'extension ne sont pas des options équivalentes parmi lesquelles choisir au hasard, mais des ancrages situés aux différentes étapes du cycle « penser → agir → observer ». Le choix dépend du besoin à adresser et non de la complexité de l'outil.
02 Six services, une définition rapide pour chacun
Commençons par définir précisément le domaine d'application de chaque point d'extension. Cette section sert de fondation au tableau décisionnel ci-dessous. En accord avec la nomenclature officielle, j'associe à chacun d'eux un scénario représentatif.
CLAUDE.md — La règle à « mémoriser systématiquement ». Conventions de projet, commandes de build, consignes permanentes comme « toujours utiliser pnpm au lieu de npm » ou « lancer les tests avant de valider ». Ce contexte toujours actif est chargé automatiquement au début de chaque session, de sorte que Claude y ait accès dès qu'il commence à travailler.
Skill — La compétence spécialisée à « appeler au besoin ». Connaissances ou flux de travail réutilisables : un guide de style d'API, une check-list de déploiement, une routine de débogage. Au quotidien, il n'occupe qu'une simple description ; son contenu complet n'est chargé que lorsqu'il devient nécessaire. Vous pouvez également l'appeler explicitement en tapant /<name>.
slash command — Le flux fixe à « déclencher manuellement en un clic ». Il s'agit en réalité d'une variante d'utilisation d'un Skill (celle déclenchée par /<name>). La seule différence réside dans l'initiateur : le Skill est évalué automatiquement par Claude pour savoir s'il doit être utilisé, tandis que la slash command est lancée lorsque vous saisissez explicitement /deploy.
MCP — L'interface pour le « connecter au monde extérieur ». Interroger votre base de données, envoyer un message sur Slack, piloter un navigateur... Pour tout ce qui dépasse les outils intégrés de Claude et nécessite une connexion à des services ou données externes, utilisez le protocole MCP (voir chapitre 22).
Subagent — Le « clone indépendant » pour les tâches fastidieuses. Si vous devez analyser des dizaines de fichiers ou effectuer de larges recherches, mais que vous ne souhaitez obtenir qu'une synthèse sans encombrer la conversation principale, déléguez le travail à un Subagent (voir chapitre 23). Il travaille dans un contexte isolé et ne renvoie qu'un résumé une fois sa tâche accomplie.
Hook (Crochet) — Le déclenchement automatique à « un moment clé ». Un Hook est simplement une séquence d'actions exécutée automatiquement dès qu'un événement survient. Lorsqu'un événement lié au cycle de vie se produit (par exemple, « après chaque modification de fichier », « au démarrage de la session »), l'action s'exécute systématiquement — lancer un linter, rejeter des commandes dangereuses, envoyer une notification. Cela ne dépend pas de la réflexion de Claude ; son exécution est garantie.
Le concept de Hook n'a pas été abordé en détail auparavant. Pour le moment, gardez simplement à l'esprit qu'il s'agit d'une action automatique déclenchée par un événement. La syntaxe complète et la liste des événements pris en charge seront traitées au chapitre 33.
Vous n'avez pas besoin d'apprendre ce tableau par cœur. Cependant, les colonnes « Déclencheur » et « Encombrement du contexte permanent » constituent la ligne de partage des eaux pour toutes vos décisions futures — l'une détermine si l'action est à votre initiative ou automatique, et l'autre indique si l'outil mérite de rester activé en permanence.
| Point d'extension | Rôle principal en une phrase | Déclencheur | Encombrement du contexte permanent |
|---|---|---|---|
| CLAUDE.md | Règles du projet à respecter systématiquement | Automatique, chargé à chaque session | Oui (texte persistant) |
| Skill | Connaissances/flux spécialisés appelés au besoin | Choix de Claude ou saisie de /<name> | Faible (uniquement la description au repos) |
| slash command | Flux fixe déclenché manuellement en un clic | Saisie de /xxx | Faible (identique à Skill) |
| MCP | Connexion à des données/services externes | Appel d'un outil par Claude | Faible (uniquement le nom de l'outil au départ) |
| Subagent | Contexte isolé / tâches parallèles dédiées | Délégation par vous ou par Claude | Aucun sur la session principale (contexte dédié) |
| Hook | Actions fixes déclenchées par des événements spécifiques | Événements du cycle de vie | Nul (sauf s'il produit des sorties renvoyées) |
💡 Résumé en une phrase : Les six points d'extension ont chacun leur spécialité : les règles dans CLAUDE.md, l'expertise dans un Skill, le flux en un clic via une slash command, la connexion externe via le protocole MCP, l'isolation du travail avec un Subagent et les déclenchements automatiques temporels via des Hooks.
03 Tableau décisionnel : À chaque besoin sa solution
Une fois la structure posée et les rôles définis, passons au cœur de cet article : le tableau décisionnel « besoin → solution recommandée ». Son utilisation est simple : repérez la phrase qui décrit le mieux votre intention dans la colonne de gauche, identifiez la solution associée et consultez les détails pour comprendre pourquoi ce choix s'impose plutôt qu'un autre.
| Votre besoin (votre intention) | Solution recommandée | Pourquoi ce choix / Pièges à éviter |
|---|---|---|
| « Respecter systématiquement nos conventions » (utiliser pnpm, exécuter les tests avant de valider) | CLAUDE.md | Règle permanente devant être visible au début de chaque session |
| « Avoir accès à ce guide de style ou à cette API en cas de besoin » | Skill | Document de référence. Évite d'encombrer le contexte au repos, chargé uniquement sur demande |
« Je veux lancer tout le processus de déploiement en tapant /deploy » | slash command (variante d'un Skill) | Flux multi-étapes fixe déclenché par l'utilisateur |
| « Interroger la base de données interne ou publier sur Slack » | MCP | Nécessite une connexion à des services ou données externes hors de portée des outils natifs |
| « Analyser des dizaines de fichiers et ne me renvoyer qu'une conclusion » | Subagent | Nécessite d'isoler le contexte pour éviter d'encombrer la fenêtre de conversation principale avec les étapes intermédiaires |
| « Rechercher ces différents éléments en parallèle de manière indépendante » | Subagent (plusieurs en parallèle) | Tâches spécialisées parallèles, s'exécutant séparément et renvoyant une synthèse |
| « Lancer ESLint automatiquement après chaque modification de fichier » | Hook (PostToolUse) | Action automatique déclenchée à un moment précis, sans intervention intellectuelle de Claude |
« Bloquer impérativement des commandes du type rm -rf / » | Hook (PreToolUse) ou Règles de permission | Nécessite une garantie d'interdiction absolue qui ne repose pas sur de simples instructions |
| « Il oublie souvent cette convention malgré deux rappels » | CLAUDE.md | Les erreurs récurrentes doivent être gravées sous forme de règles permanentes et non corrigées à la volée dans le chat |
| « Je tape le même prompt d'accueil tous les jours » | Skill | Les prompts répétitifs doivent être sauvegardés sous forme de Skill réutilisable |
| « Je souhaite réutiliser cette configuration sur un autre projet » | Plugin (couche d'emballage) | Regroupe et distribue les Skills, Hooks, Subagents et serveurs MCP sous une forme unifiée |
J'ai intégré ici la logique officielle consistant à « enrichir votre configuration au fil du temps » : de nombreux besoins naissent de la répétition. Saisir le même prompt pour la troisième fois ou corriger la même erreur pour la deuxième fois est le signal qu'il est temps de « formaliser » cette consigne dans un point d'extension adapté, plutôt que de la répéter manuellement à chaque session.
Voici un piège classique à éviter. Par souci de simplicité, on peut être tenté d'insérer un document d'API de trois cents lignes directement dans CLAUDE.md en pensant : « C'est plus pratique s'il le garde en mémoire en permanence ». Conséquence directe : chaque session commence par consommer une large part de votre contexte, limitant votre espace de travail avant même d'avoir commencé. De plus, Claude a alors tendance à passer à côté des conventions clés vraiment importantes, noyé sous les détails techniques de l'API. En déplaçant ce document dans un Skill et en ne laissant dans CLAUDE.md qu'une simple référence (« Voir les spécifications d'API dans api-skill »), le contexte redevient immédiatement clair. C'est le sens de la recommandation officielle :
Gardez CLAUDE.md sous les 200 lignes. S'il s'allonge, déplacez le contenu de référence dans des skills.
💡 Résumé en une phrase : En cas de doute, traduisez d'abord votre besoin sous forme d'intention, puis cherchez la correspondance dans ce tableau. Retenez surtout : permanent → CLAUDE.md, référence sur demande → Skill, connexion externe → MCP, travail isolé → Subagent, événement temporel → Hook.
04 Un arbre de décision : Identifiez votre outil en trois ou quatre questions
Le tableau est parfait lorsque votre besoin est déjà clair, mais il arrive que l'on hésite sur la formulation. Dans ce cas, l'arbre de décision est plus fluide : suivez le cheminement des questions à choix binaire jusqu'à la feuille finale pour trouver votre réponse.
J'ai conçu l'arbre ci-dessous. Il repose sur quatre questions clés. En les posant dans cet ordre, vous ne devriez pas vous tromper :
Ce schéma décompose la question « De quel point d'extension ai-je besoin ? » en un parcours de questions du haut vers le bas — d'abord s'interroger sur le besoin de connexion externe ou de garantie absolue, puis sur l'automatisation, pour descendre pas à pas vers un outil spécifique représenté par chaque feuille.
En déroulant ce cheminement par écrit, vous constaterez que la logique est très naturelle :
Question 1 : La tâche nécessite-t-elle de « se connecter à un service ou à des données externes » ? Si oui — par exemple, interroger une base de données, publier sur Slack ou piloter un navigateur — orientez-vous directement vers MCP. Fin du parcours. C'est le critère le plus simple à isoler en premier.
Question 2 : L'action doit-elle s'appliquer « systématiquement, sans dépendre de la bonne volonté de Claude » ? S'il s'agit d'une interdiction ou d'une contrainte absolue — par exemple, « interdiction d'éditer le fichier .env », « bloquer impérativement rm -rf / » ou « exécuter systématiquement lint après modification de fichier » — utilisez un Hook (ou des règles de permission, voir section suivante). Le mot clé ici est garantie : le Hook s'exécute de façon déterministe lors de la survenue de l'événement ; consigner l'instruction dans CLAUDE.md n'est qu'une simple « demande » que Claude peut omettre ou ignorer.
Question 3 : S'agit-il d'une « tâche complexe ponctuelle que vous souhaitez isoler » ? Si vous devez analyser un grand nombre de fichiers ou lancer de larges recherches pour n'en extraire qu'une conclusion, sans encombrer le chat principal, ou si vous souhaitez paralléliser plusieurs tâches — déléguez le travail à un Subagent. Il s'exécute dans un contexte isolé et ne renvoie que la synthèse.
Si vous n'avez pas encore trouvé de correspondance, il s'agit alors de choisir entre « Connaissance », « Règle » ou « Flux ». Posez-vous la dernière question :
Question 4 : L'élément doit-il être « visible en permanence » ou « consulté uniquement au besoin » ?
- Une règle devant être accessible en permanence (conventions, commandes de build, interdictions) → CLAUDE.md.
- Des connaissances ou des processus consultés ponctuellement (documentation d'API, check-list de déploiement, routine de débogage) → Skill.
- Un flux d'actions multi-étapes à déclencher manuellement en un clic → associez un nom
/<name>à ce Skill et utilisez-le comme slash command.
Ces quatre questions, allant de la connexion externe évidente aux subtilités de « règle vs connaissance », filtrent pas à pas votre besoin jusqu'à la solution exacte. Face à un nouveau besoin, gardez simplement ces quatre étapes en tête.
💡 Résumé en une phrase : Le cheminement de l'arbre est : Connexion externe ? → Garantie absolue ? → Isolation requise ? → Permanent ou sur demande ?. Ces quatre questions vous mènent directement à la bonne feuille sans avoir à apprendre de définitions par cœur.
05 Les trois paires les plus sujettes à confusion détaillées
L'arbre est utile, mais certains concepts partagent des similitudes et peuvent prêter à confusion. J'ai sélectionné les trois paires de questions les plus courantes chez les débutants pour les analyser en détail. Une fois ces nuances comprises, le choix s'imposera de lui-même.
Skill vs Subagent
Ces deux outils sont souvent confondus car ils permettent tous deux de structurer un enchaînement d'actions. Leurs finalités sont pourtant très différentes.
Analogie : le manuel vs l'agent envoyé sur le terrain. Un Skill est un manuel de référence partagé : celui qui en a besoin le consulte, et son contenu s'intègre directement dans vos notes de travail actuelles (contexte principal). Un Subagent est un collaborateur externe envoyé en mission : il réalise le travail de son côté et revient vous présenter uniquement les conclusions, sans que les détails de ses recherches n'encombrent vos notes.
La différence fondamentale réside dans un concept clé : le contexte.
| Critère de comparaison | Skill | Subagent |
|---|---|---|
| Nature | Connaissances / processus réutilisables | Collaborateur autonome avec son propre contexte isolé |
| Destination du contenu | Chargé dans votre session principale | Exécuté dans sa propre session, seul le résultat revient |
| Impact sur le chat principal | Consomme le contexte principal | Isolé, impact quasi nul sur la session principale |
| Cas d'usage idéal | Documents de référence, flux appelables | Analyse de fichiers volumineux, tâches parallèles, expert dédié |
Pour trancher en une seconde : si vous voulez que les étapes intermédiaires s'intègrent dans votre flux de travail, choisissez un Skill ; si vous voulez éviter de polluer votre espace et n'obtenir que le résultat final, optez pour un Subagent. Notez qu'ils peuvent se combiner : un Subagent peut être instancié en chargeant des Skills spécifiques, ce qui revient à « envoyer un agent sur le terrain muni de ses manuels dédiés ».
CLAUDE.md vs Skill
Tous deux servent à stocker des consignes, la différence résidant dans leur mode de chargement.
| Critère | CLAUDE.md | Skill |
|---|---|---|
| Moment du chargement | Automatique au début de chaque session | Sur demande (chargé uniquement au besoin) |
| Peut déclencher un flux | Non | Oui, via la saisie de /<name> |
| Idéal pour | Règles permanentes du type « toujours faire X » | Documents de référence, flux d'actions |
La règle de décision officielle est très simple : les informations que « Claude doit connaître en permanence » vont dans CLAUDE.md, tandis que celles qu'il doit « consulter ponctuellement » vont dans un Skill. Le piège des « trois cents lignes d'API dans CLAUDE.md » mentionné à la section 03 consiste précisément à placer dans CLAUDE.md ce qui relève d'un Skill.
Hook vs Règles de permission
La question ici est de savoir : pour bloquer une action dangereuse, vaut-il mieux utiliser un Hook ou des règles de permission (le mot-clé deny abordé au chapitre 20) ?
Commençons par leur point commun : tous deux constituent des contraintes absolues et garanties, ne reposant pas sur la coopération de Claude. Sur ce plan, ils se distinguent nettement des simples consignes de CLAUDE.md. La documentation officielle le résume ainsi :
Les instructions telles que « Ne jamais éditer .env » dans CLAUDE.md ou dans un skill sont des demandes, et non des garanties. Un hook
PreToolUseempêchant l'édition constitue une exécution forcée.
La différence réside dans le périmètre de contrôle et la complexité des actions associées :
- Règles de permission : Déclaratives. Elles déterminent uniquement si l'utilisation d'un outil ou l'exécution d'une commande est autorisée. Définir une règle du type
Bash(rm -rf *)dans les règles deny (via la clé"deny": ["Bash(rm -rf *)"]du fichier settings.json) suffit à bloquer la commande de façon simple. Idéal pour un contrôle d'accès pur et simple. - Hook : Permet d'exécuter un script. En plus de bloquer l'action, il peut réaliser d'autres opérations en parallèle — consigner un log au moment du blocage, envoyer une notification ou réécrire automatiquement les paramètres. Idéal pour les scénarios de type « bloquer + action complémentaire » ou pour les règles complexes non modélisables par de simples permissions.
Une règle empirique efficace : pour les décisions binaires (autorisé/refusé), privilégiez les règles de permission (faciles à déclarer en une ligne) ; s'il faut réaliser une opération additionnelle au moment du blocage (logging, notification, réécriture), utilisez un Hook. Les deux approches ne s'excluent pas et s'associent souvent — les permissions définissent le cadre général, tandis que les Hooks gèrent les cas particuliers nécessitant des actions complémentaires.
💡 Résumé en une phrase : Le Skill s'intègre à votre contexte tandis que le Subagent reste isolé pour ne renvoyer que la conclusion ; CLAUDE.md est permanent tandis que le Skill est à la demande ; les permissions gèrent l'accès binaire tandis que le Hook s'occupe du blocage accompagné d'actions complémentaires. Distinguer ces trois paires élimine les hésitations.
06 La combinaison comme norme : Pensez à associer les outils
À ce stade, vous pourriez penser que choisir un point d'extension s'apparente à une question à choix unique. C'est tout le contraire : en situation réelle, les projets associent presque toujours ces outils. Chaque point d'extension intervient dans son domaine de prédilection pour former une boîte à outils complète.
Voici quelques combinaisons classiques proposées officiellement, illustrées par des cas concrets :
| Combinaison | Mode de collaboration | Illustration concrète |
|---|---|---|
| Skill + MCP | MCP gère la connexion, le Skill explique comment l'utiliser | MCP connecte la base de données, le Skill détaille la structure des tables et les requêtes courantes |
| Skill + Subagent | L'appel du Skill lance des Subagents en parallèle | Un Skill /audit instancie simultanément trois Subagents pour auditer la sécurité, les performances et le style |
| CLAUDE.md + Skill | CLAUDE.md fixe le cadre, le Skill fournit les détails | CLAUDE.md indique « Respecter nos conventions d'API », le Skill contient le guide de style complet |
| Hook + MCP | Le Hook s'exécute lors d'un événement et interagit avec l'extérieur via MCP | Après modification d'un fichier critique, le Hook utilise MCP pour publier une alerte sur Slack |
L'association « Skill + MCP » illustre parfaitement l'intérêt de la combinaison : avec MCP seul, Claude se connecte à la base de données mais ignore la structure des tables ou les meilleures manières de l'interroger ; avec un Skill seul, il connaît la méthodologie mais ne peut pas interagir avec vos données. L'association des deux permet à la fois la connexion et la pertinence. En pratique, on configure la connexion via MCP et on liste dans le Skill les détails (« Pour les commandes utilisateurs, interroger telle table, tel champ contient le montant net ») : les requêtes générées par Claude sont ainsi immédiatement opérationnelles.
Comment réutiliser un ensemble de configurations cohérentes sur d'autres projets ou les partager avec des collègues ? La réponse est le Plugin — la couche permettant d'« empaqueter et distribuer » l'ensemble.
Analogie : la valise. Pour partir en voyage, vous ne portez pas vos chemises, votre rasoir et vos chargeurs en vrac sous le bras. Vous les rangez dans une valise. Un Plugin est cette valise : il regroupe les Skills, Hooks, Subagents et serveurs MCP au sein d'une entité installable unique. Pour appliquer la même configuration sur un autre projet, il suffit d'installer ce plugin. De plus, les Skills embarqués disposent d'un espace de noms dédié (comme /my-plugin:review), ce qui évite les collisions de noms entre différents plugins. La documentation officielle l'explique clairement :
Un plugin regroupe des skills, des hooks, des subagents et des serveurs MCP au sein d'une seule unité installable.
Le fonctionnement détaillé des Plugins a été abordé au chapitre 24. Retenez simplement son rôle dans l'architecture globale : les cinq autres outils sont des « fonctionnalités », tandis que le plugin est la couche d'« empaquetage et de distribution ».
💡 Résumé en une phrase : Choisir un point d'extension n'est pas exclusif — les configurations de production associent presque toujours ces outils (Skill + MCP, CLAUDE.md + Skill...). Pour déplacer ou partager une suite complète d'outils, utilisez un Plugin pour tout regrouper dans un conteneur unique.
07 En pratique : Orienter une liste de besoins concrets
La théorie ne suffit pas, passons à un exercice pratique d'orientation. Voici une liste simulée de besoins réels que vous pourriez rencontrer sur un projet. Votre objectif : utiliser l'arbre de décision pour orienter chaque besoin vers le bon outil. Cet exercice purement intellectuel est plus efficace pour ancrer la logique que l'apprentissage de définitions.
Étape 1 : Copiez cette liste dans vos notes (ou gardez-la à l'esprit)
Liste des besoins (associez un point d'extension à chaque besoin) :
A. Convention d'équipe : « Toujours utiliser pnpm et interdire npm », à faire respecter systématiquement
B. Permettre d'interroger la base de données interne PostgreSQL de l'entreprise
C. Lancer tout le flux de publication (« tagger → mettre à jour le changelog → pousser ») en tapant une seule commande
D. Lancer automatiquement prettier pour formater le code après chaque modification de fichier
E. Analyser l'intégralité du répertoire utils en une seule fois et lister uniquement les fonctions inutilisées
F. Accéder ponctuellement à une longue table de correspondance des codes d'erreur internes
G. Interdire formellement et bloquer de manière absolue l'exécution des scripts de migration sur la base de données de productionÉtape 2 : Déroulez l'arbre de décision par vous-même pour associer chaque réponse
Prenez le temps d'évaluer chaque point à l'aide des quatre questions du chapitre 04 (Connexion externe ? Garantie absolue ? Isolation requise ? Permanent ou sur demande ?) avant de consulter les réponses.
Étape 3 : Vérification des réponses
Voici les solutions recommandées accompagnées de leur justification. Le score importe moins que la compréhension du raisonnement :
| Besoin | Outil recommandé | Justification (cheminement dans l'arbre) |
|---|---|---|
| A Utiliser pnpm | CLAUDE.md | Pas de connexion externe, pas de garantie par script, pas d'isolation. C'est une convention permanente devant être lue à chaque session |
| B Interroger la base de données | MCP | Répond positivement à la question 1 : nécessite une connexion à des données/services externes |
| C Publication en un clic | slash command | Flux multi-étapes déclenché manuellement. Associer une commande /release à un Skill |
| D Formatage après édition | Hook (PostToolUse) | Moment d'exécution fixe, automatique et systématique, ne nécessitant pas de réflexion de la part de Claude |
| E Rechercher le code inutilisé | Subagent | Analyse de fichiers volumineux pour n'en extraire qu'un résultat. Isole le processus pour ne pas saturer la session principale |
| F Table des codes d'erreur | Skill | Document de référence consulté ponctuellement, à ne pas charger dans CLAUDE.md |
| G Interdire la migration | Règles de permission / Hook | Nécessite une garantie absolue de blocage, de simples instructions ne suffisent pas. Avantage aux règles de permission pour un contrôle d'accès pur |
Résultat attendu : si vous n'avez pas confondu A et F (l'un dans CLAUDE.md, l'autre dans un Skill), ni D et G (l'un exécuté automatiquement par un Hook, l'autre bloqué par les permissions), et que vous avez choisi un Subagent pour E plutôt qu'un Skill — votre logique d'orientation est en place. Vous pourrez l'appliquer à vos futurs besoins concrets.
Si vous avez hésité sur un point, relisez le comparatif correspondant à la section 05, l'écart réside probablement là. Cette gymnastique d'esprit demande un peu d'entraînement avant de devenir un réflexe — au début, on a tendance à concevoir un Skill pour des tâches qui relèvent d'un Subagent, avant de constater que la session principale se retrouve saturée et de comprendre l'intérêt d'isoler l'action.
💡 Résumé en une phrase : Orienter chaque point d'une liste de besoins réels à l'aide de l'arbre de décision est cent fois plus efficace que d'apprendre des définitions. En cas de doute, référez-vous aux comparatifs de concepts.
08 Conclusion
Cet article conclut notre quatrième partie en transposant les concepts des temps des cinq points d'extension (et des slash commands) vers une approche axée sur les besoins réels.
Récapitulons les points clés :
| Votre intention | Outil à utiliser | Point clé en une phrase |
|---|---|---|
| « À respecter systématiquement » | CLAUDE.md | Règles permanentes, chargées d'office à chaque session, à maintenir sous les 200 lignes |
| « Consulter en cas de besoin / Déclencher en un clic » | Skill / slash command | Connaissances ou flux à la demande, n'encombrent pas le contexte au repos |
| « Se connecter à des services ou données externes » | MCP | Accès aux ressources externes non couvertes par les outils natifs |
| « Analyser des fichiers et n'avoir que la conclusion » | Subagent | Isolation du contexte, tâches spécialisées en parallèle, renvoie uniquement la synthèse |
| « Déclenchement automatique garanti à un moment clé » | Hook | Actions déterministes déclenchées par un événement, contrainte absolue de sécurité |
| « Transposer toute la configuration ou la partager » | Plugin | Empaquette et distribue les outils ci-dessus au sein d'une seule unité installable |
Vous devriez maintenant être capable de : analyser un besoin exprimé en langage naturel sans hésiter entre les différents concepts. Posez-vous simplement les quatre questions clés (Connexion externe ? Garantie absolue ? Isolation requise ? Permanent ou sur demande ?) et suivez l'arbre décisionnel pour identifier le bon outil. Les différences entre des notions proches (Skill vs Subagent, CLAUDE.md vs Skill, Hook vs Permissions) vous apparaissent désormais clairement. En établissant ce pont entre besoins et solutions, vous donnez tout leur sens aux outils étudiés dans la quatrième partie pour les exploiter à bon escient.
La quatrième partie sur les fonctionnalités avancées s'achève ici. Vous connaissez désormais ces outils et savez lequel dégainer selon les cas. Il ne reste plus qu'à les mettre en pratique.
À partir du prochain chapitre, nous aborderons la cinquième partie sur la configuration système et l'optimisation. Nous commencerons par le chapitre 31 « settings.json : Configuration utilisateur et projet » — après avoir manipulé CLAUDE.md, les permissions et bientôt les Hooks, il est indispensable de structurer ces paramètres dans les bons fichiers et de comprendre les règles de priorité entre paramètres système et projet. Une configuration identique saisie dans votre répertoire utilisateur ou à la racine d'un projet peut produire des effets radicalement opposés. Nous tirerons tout cela au clair au prochain chapitre.