Skills, subagents, MCP et plugins dans Claude Code : lequel choisir ?

Actuellement, dans Claude Code, il existe cinq façons de faire la même revue de code : une commande slash, un skill, un subagent, un plugin ou simplement un prompt dans le chat. Aucune n’est meilleure qu’une autre par défaut : le choix dépend de la tâche, du budget de tokens et des personnes qui l’utiliseront en plus de vous.

Voici le guide que j’aurais aimé me donner il y a un an. Un arbre de décision en 4 questions, une matrice « tâche → couche » prête à l’emploi et 5 erreurs fréquentes qui font gaspiller des tokens à tous les vibe coders avec qui je travaille.

Pour découvrir comment travailler avec le service, consultez la documentation Ailoot.

Que sont les Skills, les subagents, MCP et les plugins en une phrase ?#

Avant de choisir, distinguons les termes. Les quatre couches ont un objectif commun : étendre les capacités de Claude au-delà de celles dont il dispose par défaut. Mais chacune a sa propre nature.

Skill désigne un répertoire contenant un fichier SKILL.md qui décrit quand et comment appliquer une méthodologie donnée. Anthropic compare un Skill aux consignes données à une nouvelle recrue : on ne lui dicte pas chaque étape tous les jours, on lui fournit une procédure.

Subagent désigne une session Claude distincte, avec son propre contexte, lancée depuis la conversation principale. Elle possède une caractéristique essentielle : l’isolation. Un subagent peut lire 30 fichiers, produire un résumé et ne renvoyer que celui-ci au chat principal. Le contexte de la conversation principale reste propre.

MCP (Model Context Protocol) est une norme ouverte d’Anthropic qui permet de connecter Claude à des systèmes externes. Dans un billet de blog publié le 13 novembre 2025, Anthropic a expliqué la distinction aussi clairement que possible :

Plugin désigne un ensemble prêt à l’emploi de Skills, de subagents, de hooks et de commandes créé par quelqu’un d’autre et distribué dans un marketplace. Installez-le en une seule ligne avec /plugin install et vous obtenez tout d’un coup. Si un Skill est votre propre procédure, un plugin est une procédure achetée à une autre entreprise.

En bref, les Skills sont des recettes, les subagents sont des collègues spécialisés et MCP fournit des outils externes grâce auxquels Claude peut accéder à des services et à des données. Le coût en tokens varie : un Skill est le moins coûteux (il se charge lorsqu’il est déclenché), tandis que MCP est nettement plus coûteux (chaque serveur connecté occupe constamment de la place dans la fenêtre de contexte).

Pourquoi 4 couches si un seul fichier CLAUDE.md suffit ?#

Dans le projet décrit, CLAUDE.md est une grande carte des règles : où placer les choses, comment publier, quels accords sont en vigueur. Sans ce fichier, Claude repartirait de zéro à chaque nouvelle session.

Mais CLAUDE.md a ses limites. Voici trois situations dans lesquelles il ne suffit plus.

Situation 1 : une règle ne fonctionne que de temps en temps. CLAUDE.md dit : « exécute toujours npm run build avant git push ». Claude le lit au début de la session, acquiesce, commence à écrire du code après 25 messages et oublie. Je me suis déjà surpris trois fois à pousser sans lancer le build ; ces pushes ont échoué en production. Un hook bien configuré et testé peut lancer un build déterministe et rejeter l’opération couverte. Sa portée dépend de l’événement et du chemin d’outil ; il n’intercepte pas à lui seul les pushes d’un autre terminal ou logiciel. Vérifiez qu’un build volontairement raté bloque votre vrai chemin.

Situation 2 : un processus en 15 étapes qui se répète. Dans l’exemple décrit, chaque guide passe par 14 étapes : recherche → structure → MDX → 7 vérifications QA parallèles → publication en production → IndexNow. Si j’écris un prompt à chaque fois en disant « exécute l’étape 1, puis 2, puis 3 », je gaspille des tokens avant même de commencer. C’est pourquoi tout ce flux de travail est empaqueté dans le Skill build-masterskaya-guide : un ensemble de consignes de 34 KB lancé par la phrase « créons un nouveau guide pour le projet ».

Situation 3 : une tâche dévore le contexte. Pour vérifier qu’un guide déjà publié est à jour, Claude doit lire la transcription d’un livestream de 30 KB, 20 rétrospectives de 5 KB chacune et comparer le tout avec le site actuel. Si je fais cela dans le chat principal, j’aurai 200K tokens de contenu inutile dans le contexte à la fin de la vérification. Un subagent effectue le même travail, renvoie un résumé de seulement 300 mots à la conversation principale, puis se termine.

Situation 4 : je veux que l’équipe dispose des mêmes modèles que moi. Un ensemble prêt à l’emploi de règles de conception frontend, de hooks pour publier avec Coolify, et de MCP pour les vérifications avec Playwright. C’est un plugin : j’empaquette ma configuration, je la publie dans le marketplace et un collègue l’installe en une seule ligne.

CLAUDE.md couvre les bases : « voici comment nous travaillons ». Les 4 couches supplémentaires couvrent ce que CLAUDE.md ne peut pas faire concrètement : répéter des actions à l’aide de déclencheurs, isoler le contexte, accéder au monde extérieur et partager.

Quand faut-il un Skill plutôt que CLAUDE.md ?#

Le test pour savoir si un Skill est utile est simple : vous vous surprenez à copier le même long prompt depuis vos notes dans le chat. La troisième fois est déjà un signal.

J’ai actuellement 7 répertoires dans ~/.claude/skills/ : build-masterskaya-guide, build-vc-spoke, build-reel-script, build-practicum-instruction, update-config, simplify et keybindings-help. Le plus utilisé est build-masterskaya-guide (ce guide a été écrit avec lui). Il contient 34 KB de méthodologie : les étapes à suivre, les vérifications QA multi-agents à exécuter, les conditions de validation qui doivent interrompre le processus et les artefacts à enregistrer dans /tmp/.

Quand ne pas créer de Skill.

• Une règle comme « réponds dans la langue préférée de l’utilisateur » a sa place dans CLAUDE.md, pas dans un Skill. Un Skill se charge lorsqu’il est déclenché, mais cette règle doit toujours s’appliquer.
• Une instruction ponctuelle comme « lance le refactoring maintenant » a sa place dans le chat, pas dans un Skill.
• Une tâche exigeant un contexte séparé peut utiliser un sous-agent ; sa procédure récurrente peut aussi rester dans une skill.

Le principal anti-pattern. L’erreur la plus fréquente des vibe coders consiste à intégrer une procédure dans un subagent alors qu’elle devrait être dans un Skill. Un subagent coûte plus de tokens (il dispose de son propre contexte), démarre plus lentement et est souvent excessif. Si la méthodologie d’une tâche tient en 1 500–2 000 mots et ne nécessite pas de lire des fichiers externes, c’est un Skill.

Pour savoir comment structurer un Skill, quoi mettre dans le frontmatter et quels déclencheurs utiliser, consultez le guide Skills Claude Code en 2026 : comment créer une bibliothèque personnelle de Skills.

Quand faut-il un subagent plutôt qu’un Skill ?#

Un Skill stocke la méthodologie ; un subagent fait le travail. Ce sont des couches différentes, souvent confondues parce qu’elles sont toutes deux lancées « depuis le chat ».

Un subagent n’a de sens que pour isoler le contexte. La session Claude principale dispose d’un budget de 200 000 tokens (ou 1 million en version bêta). Si vous lui demandez dans le chat principal de lire 30 fichiers et de les analyser un par un, vous consommerez la moitié de la fenêtre à lire le contenu intermédiaire. Un subagent fait le même travail dans une session distincte et ne renvoie que le résultat au chat principal.

Exemple concret de projet. Chaque guide passe par plusieurs vérifications QA parallèles : le style, les citations et les faits vérifiés à partir de sources primaires, la structure adaptée aux moteurs de recherche, ainsi que l’intégrité des liens internes et externes. Chaque vérification mobilise son propre contexte : un glossaire de règles, WebFetch sur des dizaines d’URL et des recherches dans le texte.

Si j’exécutais toutes ces vérifications dans un seul chat, le contexte me submergerait avant même que la première soit terminée. Lancer les subagents en parallèle avec run_in_background: true résout le problème : ils travaillent en arrière-plan, le chat principal avance et, après 4–6 minutes, je reçois des rapports concis et applique les modifications.

Deuxième exemple : une recherche approfondie. Lorsque je choisis un sujet pour un nouveau guide, 4 subagents recueillent des signaux en parallèle :

• V1 - forums et communautés sur 14 jours
• V2 - réseaux sociaux
• V3 - plateformes vidéo + blog d’Anthropic
• V4 - lacunes SEO

Chacun renvoie 30–40 éléments avec un score de viralité. Je les rassemble dans un ensemble, les pondère selon 9 dimensions et choisis le meilleur. Sans les subagents, cette étape s’étendrait sur 2–3 heures et consommerait le contexte principal.

Quand ne pas créer de subagent.

• Une tâche qui ne nécessite ni lecture de fichiers ni utilisation de WebFetch a sa place dans le chat principal.
• Une procédure répétable relève d’une skill et peut s’exécuter dans un sous-agent si l’isolation aide.
• L’accès externe exige un outil autorisé comme MCP ou une CLI, utilisable par le sous-agent chargé de la tâche.

Le principal anti-pattern. Créer un subagent nommé backend-engineer ou qa en espérant que Claude comprendra quand l’utiliser. Des subagents spécialisés (comme migration-test-writer ou api-route-reviewer) donnent de meilleurs résultats que des subagents génériques. Plus leur nom et leurs instructions sont précis, plus Claude choisit le bon avec exactitude.

Pour savoir comment créer des subagents spécialisés, connaître la syntaxe du frontmatter et découvrir 5 exemples prêts à l’emploi, consultez le guide Subagents Claude Code en 2026 : guide pas à pas.

Quand faut-il MCP plutôt qu’un Skill ou un subagent ?#

Anthropic a donné la formule la plus concise pour expliquer la différence dans un billet de blog : MCP connecte Claude aux données ; les Skills apprennent à Claude quoi faire avec ces données.

Une skill de revue d’issues GitHub exige leur contenu, fourni par MCP autorisé, CLI ou texte transmis. Elle définit ensuite analyse et format des constats ; l’accès MCP seul ne prescrit pas cette procédure.

Ma pile MCP.

• Playwright MCP - QA visuelle de chaque guide. Ouvrir la page sur ordinateur et sur mobile, vérifier la largeur du conteneur et le rendu des blocs.
• Stitch MCP - accès au système de design, génération de composants dans le style de la marque.
• vidIQ MCP - analyse des tendances et vérification du potentiel viral des idées.
• Railway MCP - gestion de l’infrastructure de déploiement.

Chacun de ces 4 serveurs est un pont vers un système externe. Sans MCP, je devrais soit écrire mon propre code wrapper, soit passer par un navigateur. Avec MCP, tout se passe dans la session Claude.

Coût en tokens. MCP est la couche la plus coûteuse. Chaque serveur connecté occupe constamment de la place dans la fenêtre de contexte : déclarations d’outils, schémas d’arguments et descriptions. J’ai 4 serveurs MCP : cela représente environ 8–12K tokens dans chaque nouvelle session avant même que j’aie posé une question.

Cela signifie qu’on ne connecte MCP que s’il est réellement nécessaire dans la plupart des sessions. Si vous utilisez Sentry MCP une fois par semaine, mieux vaut l’activer à la demande avec le flag --mcp sentry plutôt que de le garder dans la liste permanente.

Quand ne pas utiliser MCP.

• La méthodologie pour « travailler avec les données » a sa place dans un Skill, pas dans MCP.
• Une longue lecture peut bénéficier d’un sous-agent ; des fichiers ou enregistrements externes peuvent aussi exiger un accès MCP.
• Une publication déclenchée par une seule commande appelle un hook ou un plugin, pas MCP.

Le principal anti-pattern. Créer un serveur MCP pour quelque chose qui serait mieux traité par un Skill. J’ai vu un exemple dans une discussion HN (ce fameux fil qui a obtenu 422 points le 27 mai) : l’auteur avait écrit un serveur MCP qui fournissait des « instructions de revue de code ». Mais il ne s’agit pas d’un accès au monde extérieur, c’est une procédure. Un Skill fait la même chose avec 10 fois moins de tokens.

Incident de concurrence sur une ressource. J’ai déjà vu Playwright MCP se bloquer avec l’erreur « Browser is already in use » : une fenêtre Chrome était ouverte en même temps, et MCP ne pouvait pas prendre le contrôle du navigateur. C’est une leçon importante : un serveur MCP utilise des ressources système partagées. Si une ressource est utilisée par plusieurs processus (un navigateur, un port ou un fichier), pensez à l’isoler dès le départ.

Vous trouverez un guide prêt à l’emploi pour connecter 7 MCP fonctionnels dans Serveurs MCP Claude Code en 2026 : 7 configurations prêtes à l’emploi.

Quand faut-il un plugin plutôt qu’un Skill ou un subagent ?#

Les Skills, les subagents et MCP concernent votre méthodologie. Un plugin est la méthodologie prête à l’emploi de quelqu’un d’autre, que vous importez dans votre configuration.

En octobre 2025, Anthropic a lancé Claude Code Plugins, un mécanisme officiel de distribution. Un plugin est un répertoire qui peut contenir :

• ses propres commandes slash
• ses propres Skills
• ses propres subagents
• ses propres hooks
• ses propres configurations MCP
• ses propres styles de sortie

Tout cela est regroupé dans un seul paquet avec plugin.json. L’installation se fait en une ligne dans ~/.claude/settings.json ou avec la commande /plugin install <name>.

Ma pile de plugins.

• frontend-design du marketplace officiel claude-plugins-official — 67 styles, 96 palettes, 57 paires de polices, 13 frameworks. Lorsque je crée un nouveau bloc pour le site ou un modèle d’e-mail, je charge ce plugin et j’obtiens toute la bibliothèque d’un coup.
• playwright du même marketplace officiel — un ensemble de Skills et de configurations MCP pour tester les navigateurs.
• telegram — un ensemble prêt à l’emploi pour gérer un compte Telegram depuis Claude Code (politique, liste d’autorisations, appairage).
• trailofbits/skills — un ensemble de Skills de sécurité de Trail of Bits, une entreprise à laquelle je fais confiance pour les questions de sécurité.

Les 4 plugins tiennent en trois lignes dans settings.json. Sans plugins, je passerais des heures à créer la même bibliothèque à la main.

Quand ne pas utiliser un plugin.

• Si la méthodologie est entièrement la vôtre et qu’elle n’a pas vocation à être partagée, gardez-la sous forme de Skill.
• Si vous ne savez pas encore qui l’utilisera, essayez-la d’abord vous-même sous forme de Skill.
• Si vous devez rapidement transférer trois fichiers sur une nouvelle machine, cp ~/.claude/skills/X /new/machine/.claude/skills/ suffit.

Le principal anti-pattern. Utiliser un plugin à la place de CLAUDE.md, par exemple avec des règles sur « notre façon de travailler dans ce projet ». Un plugin est conçu pour la distribution et la réutilisation. Si les règles ne concernent qu’un dépôt, elles ont leur place dans CLAUDE.md, pas dans un plugin.

En se projetant vers 2026, Anthropic s’oriente clairement vers un marketplace d’équipe pour les plugins. Les entreprises pourront ainsi publier leurs méthodologies internes sous forme de plugins, les versionner et les mettre à jour pour tous les employés avec une seule commande. Pour un entrepreneur indépendant, cela signifie : installez ce qui existe déjà et ne réinventez pas la roue.

Arbre de décision : 4 questions à se poser avant chaque tâche#

Question 1 : existe-t-il une procédure répétable à conserver ?

Si oui, placez la méthode dans une skill, son SKILL.md et une description claire du déclenchement. Cela fournit la procédure, sans donner en soi d’accès externe ni de contexte séparé.

Question 2 : faut-il isoler le contexte ou déléguer un rôle précis ?

Si oui, utilisez un sous-agent avec tâche et outils précis. Il peut suivre la méthode d’une skill dans son contexte isolé.

Question 3 : faut-il un outil ou des données externes ?

Si oui, donnez un accès autorisé via MCP ou un autre outil adapté, comme une CLI déjà configurée. La skill décrit son usage et le sous-agent peut l’exécuter.

Question 4 : faut-il distribuer et maintenir cet ensemble comme paquet ?

Si oui, un plugin distribue skills, définitions d’agents, hooks ou configuration MCP. Vous pouvez le créer ou utiliser celui d’un autre auteur.

Exemple combiné : revue récurrente d’issues GitHub. Une skill définit procédure et format, MCP ou CLI GitHub fournit l’accès autorisé, un sous-agent lit un long fil et retourne les constats, un plugin distribue le tout à l’équipe. Les quatre réponses peuvent être « oui » sans s’annuler.

5 erreurs de sélection des couches fréquentes chez les vibe coders#

Je vois ces 5 schémas chaque semaine chez les vibe coders avec lesquels je travaille. Une personne sur deux en commet au moins un durant sa première semaine.

Erreur 1 : un subagent au lieu d’un Skill.

Symptôme : un auteur a créé un subagent pour « écrire un nouvel article de blog ». À chaque exécution, il se lance, lit 2 KB de méthodologie, génère un article, puis se termine. Au bout d’une semaine, l’auteur remarque que chaque exécution consomme 5K tokens supplémentaires pour charger le subagent.

Ce qui aurait dû se passer : « comment écrire un article » est une méthodologie, donc un Skill. Le déclencheur est la phrase « nouvel article de blog ». Le Skill se charge dans le chat principal sans ouvrir une session distincte. C’est 3 à 5 fois moins coûteux.

Erreur 2 : un serveur MCP au lieu d’un Skill.

Symptôme : un auteur a écrit un serveur MCP qui fournit des consignes sur « la façon de faire une revue de code ». Les déclarations d’outils, les descriptions des schémas d’arguments et la documentation occupent constamment le contexte. Chaque requête gaspille 2–3K tokens pour rien.

Ce qui aurait dû se passer : « comment faire une revue de code » est une procédure, pas un accès à un système externe. Utilisez un Skill. MCP ne se justifie que si vous avez besoin d’un accès en temps réel, par exemple à Sentry pour récupérer les erreurs les plus récentes.

Erreur 3 : un plugin au lieu de CLAUDE.md.

Symptôme : un auteur a empaqueté des règles de projet (« toujours utiliser le mode TypeScript strict », « ne pas utiliser de tirets », « utiliser uniquement pnpm, pas npm ») dans un plugin et l’a installé. Chaque nouvelle session charge alors un plugin qui fait doublon avec ce qui devrait se trouver dans CLAUDE.md.

Ce qui aurait dû se passer : les règles propres à un projet ont leur place dans le fichier CLAUDE.md de ce projet. Un plugin sert à distribuer une méthodologie à plusieurs personnes ou dépôts.

Erreur 4 : essayer de créer un Skill avec un hook.

Symptôme : un auteur a constaté qu’un hook s’exécute automatiquement lors d’un événement (par exemple, avant l’enregistrement d’un fichier). Il a décidé de créer un « Skill via un hook » pour que Claude applique automatiquement la méthodologie à chaque modification. Cela a provoqué une boucle de déclenchement sans fin, consommé du contexte et entraîné un comportement imprévisible.

Ce qui aurait dû se passer : un hook est du code déterministe qui exécute une commande, met en forme le résultat ou bloque une opération. Un hook ne charge pas de Skill et ne lance pas Claude. Si vous voulez « toujours appliquer la méthodologie X », utilisez un Skill avec un déclencheur ou une entrée dans CLAUDE.md.

Erreur 5 : ajouter une couche alors qu’aucune n’est nécessaire.

Symptôme : un auteur entend parler des Skills, lit des guides, se dit « je dois empaqueter cette méthodologie » et passe une soirée à créer un Skill pour une tâche qui se présente une fois par mois.

Ce qui aurait dû se passer : une tâche ponctuelle se fait directement dans le chat, au cas par cas. Un Skill ne se justifie que si vous faites cette tâche plus d’une fois par jour. Sinon, c’est de la suringénierie qu’il faudra ensuite maintenir.

Vérifiez indépendamment procédure, isolation du contexte ou rôle, accès aux outils et distribution. Ajoutez chaque couche répondant à un besoin concret et combinez-les si nécessaire.

Ce qu’Anthropic dit de la fragmentation : où va Claude Code en 2026 ?#

Ce que cela signifie pour les six prochains mois à un an.

Premièrement : les Skills deviennent la couche principale pour les tâches procédurales. Anthropic mise clairement sur cette couche, la moins coûteuse et la plus prévisible. Si vous ne comprenez pas à quoi sert un Skill en 2026, commencez par l’étudier. Toutes les autres couches graviteront autour de lui.

Deuxièmement : les subagents se spécialisent. Le rôle essentiel des subagents est d’isoler le contexte lors des tâches lourdes. Les subagents génériques comme qa-engineer vont disparaître ; les subagents spécialisés comme migration-test-writer et api-route-reviewer vont rester.

Troisièmement : les nouvelles annonces d’Anthropic en l’espace de 14 jours — la commande /workflows (28 mai 2026) pour orchestrer des dizaines de subagents et la séparation de la facturation de l’Agent SDK à partir du 15 juin — signifient que l’utilisation programmatique passe dans un pool distinct. C’est le signe qu’Anthropic développe une infrastructure pour des systèmes automatisés de 10+ agents plutôt que pour des sessions individuelles.

Pour un vibe coder en 2026, cela signifie une chose simple : les quatre couches resteront en place au moins six mois de plus, puis certaines fusionneront. Mais l’arbre de décision en quatre questions restera valable après cette fusion : il porte sur la nature de la tâche, pas sur le nom précis de la couche.

Matrice prête à l’emploi : 10 tâches courantes → la couche adaptée#

La règle principale pour utiliser ce tableau est de ne pas essayer de « tout faire en même temps ». La plupart des vibe coders qui travaillent seuls se contentent de CLAUDE.md + 5–7 Skills + 2–4 serveurs MCP. Les subagents et les plugins s’ajoutent à mesure que le projet grandit.

Et ensuite : comment construire votre espace de travail dans Claude Code#

Ces cinq couches ne se succèdent pas, elles s’imbriquent. CLAUDE.md constitue la fondation du projet ; les quatre autres s’ajoutent à mesure que les tâches évoluent.

Découvrez Ailoot.