Plugins Claude Code : Qu'est-ce que c'est et comment les utiliser

Un plugin Claude Code est un dossier qui distribue plusieurs types d'extensions à la fois. Alors qu'une compétence est un simple fichier SKILL.md enseignant un comportement à Claude, un plugin peut regrouper des compétences, des sous-agents, des hooks, des commandes slash et même un serveur MCP, et tout installer avec une seule commande. C'est la différence entre donner une fiche recette à quelqu'un et lui donner une cuisine équipée.

Anthropic a ajouté les plugins à Claude Code fin 2025, et ils ont résolu un problème réel : les équipes n'installaient pas une compétence à la fois, elles assemblaient des configurations. Une configuration d'"ingénieur backend" pouvait nécessiter une compétence de débogage, un sous-agent de revue de code, un hook pre-commit et une connexion MCP à une base de données. Avant les plugins, cela signifiait quatre installations séparées et quatre endroits où la configuration pouvait se désynchroniser. Un plugin en fait une.

Nous testons et cataloguons les compétences Claude sur SkillProof, et les plugins sont la couche supérieure à ce que nous examinons habituellement : un format d'empaquetage, pas un comportement. Ce guide couvre ce qui se trouve réellement à l'intérieur d'un plugin, comment fonctionne le système de marketplace, et la même question de confiance que nous posons pour les compétences depuis nos débuts, appliquée maintenant à quelque chose avec une surface d'attaque beaucoup plus grande.

Ce que les plugins empaquetent réellement

Quatre types d'ingrédients peuvent apparaître à l'intérieur d'un seul plugin, et la plupart des plugins réels en utilisent plus d'un :

• Compétences — Instructions markdown qui se chargent lorsqu'une tâche correspond, le même format couvert dans ce que sont les compétences Claude.
• Sous-agents — Instances Claude séparées avec leur propre prompt système et fenêtre de contexte, utiles pour déléguer une tâche bruyante ou parallèle.
• Hooks — Commandes shell qui se déclenchent automatiquement lors d'événements tels qu'une sauvegarde de fichier, un commit ou la fin d'un appel d'outil. Un hook de linting à la sauvegarde est l'exemple classique.
• Commandes slash — Commandes personnalisées comme /deploy ou /standup qui exécutent un prompt ou un script prédéfini lorsqu'un membre de l'équipe les tape.
• Serveurs MCP — Une connexion à un outil ou une source de données externe, configurée une fois à l'intérieur du plugin au lieu d'être configurée manuellement dans chaque projet.

Un plugin n'a pas besoin des cinq. Beaucoup n'en livrent que quelques-unes, ou un seul hook plus la commande qui le déclenche. Ce qui en fait un plugin plutôt qu'une collection lâche de fichiers, c'est qu'il s'installe comme une unité, avec un manifeste décrivant ce qu'il contient.

Plugins vs compétences : l'analogie npm-package

La façon la plus claire d'y penser : une compétence est une fonction, un plugin est un package.

Une seule compétence enseigne un comportement à Claude, qu'il s'agisse de formater des notes de réunion ou d'auditer une page SEO. Elle n'a pas de dépendances ni de configuration au-delà de son propre markdown. C'est intentionnel : une compétence écrite pour couvrir plusieurs tâches non liées a tendance à se déclencher de manière peu fiable sur toutes, car sa description ne peut pas être spécifique à une seule.

Un plugin est l'unité de distribution autour de ce comportement. Dans le monde npm, une fonction ne s'expédie pas seule ; elle s'expédie à l'intérieur d'un package avec un package.json, un numéro de version, et peut-être quelques autres fonctions qui vont ensemble. Un plugin joue le même rôle pour Claude Code : c'est la chose avec un nom, une version, un auteur et un manifeste, et les compétences, hooks et commandes à l'intérieur sont les exportations.

Cette distinction est importante pour une raison pratique. Lorsque quelque chose casse, "le déclencheur de la compétence est trop vague" et "le hook du plugin exécute la mauvaise commande shell" sont des bugs différents avec des corrections différentes. Blâmer tout le plugin pour une seule mauvaise compétence à l'intérieur, ou vice versa, fait perdre du temps. Lisez d'abord le manifeste pour voir ce qui a réellement été livré avant de diagnostiquer quoi que ce soit.

Cela signifie également que les deux unités sont évaluées différemment. Une compétence vit ou meurt sur la qualité du déclencheur et si sa sortie surpasse celle par défaut de Claude. Un plugin vit ou meurt sur la coopération de ses parties : le hook se déclenche-t-il avant ou après que la compétence ait besoin de sa sortie, la commande appelle-t-elle un serveur MCP qui est effectivement configuré, son installation entre-t-elle en conflit avec quelque chose que vous avez déjà.

Anatomie d'un plugin

Chaque plugin a besoin d'un répertoire .claude-plugin à sa racine contenant plugin.json, le manifeste. Tout le reste (skills/, agents/, hooks/, commands/, .mcp.json) se trouve à côté sous forme de dossiers simples que Claude Code recherche par convention.

Voici un plugin petit mais complet, annoté :

team-standards/
├── .claude-plugin/
│   └── plugin.json
├── skills/
│   └── code-review/
│       └── SKILL.md
├── hooks/
│   └── hooks.json
└── commands/
    └── deploy.md

// .claude-plugin/plugin.json
{
  "name": "team-standards",
  "version": "1.2.0",
  "description": "Notre hook de linting, compétence de revue et commande de déploiement en une seule installation.",
  "author": "platform-team"
}

Le manifeste est délibérément mince. Il identifie le plugin et sa version ; il n'énumère pas chaque fichier à l'intérieur, car Claude Code découvre automatiquement skills/, hooks/ et commands/ par leurs noms de dossiers.

// hooks/hooks.json
{
  "PreToolUse": [
    {
      "matcher": "Bash",
      "hooks": [{ "type": "command", "command": "./scripts/check-branch.sh" }]
    }
  ]
}

Ce hook se déclenche avant tout appel d'outil Bash et peut le bloquer, c'est ainsi qu'un plugin applique quelque chose comme "ne jamais exécuter de commandes git destructrices sur main" sans compter sur Claude pour se souvenir de vérifier.

<!-- commands/deploy.md -->
---
description: Exécuter notre checklist de déploiement sur staging
---

Vérifier que la branche n'est pas main, confirmer que les migrations sont appliquées,
puis exécuter `./deploy.sh staging`. Rapporter le résumé du log de déploiement.

Taper /deploy exécute exactement ceci, à chaque fois, formulé identiquement pour chaque membre de l'équipe qui installe le plugin. Cette cohérence est tout l'argument : trois composants, un numéro de version, une commande d'installation, et personne n'a sa configuration locale qui dérive de celle des autres.

Un fichier séparé, marketplace.json, ne fait pas partie du plugin lui-même. C'est l'index qu'un dépôt de marketplace publie pour que Claude Code sache quels plugins s'y trouvent et où les récupérer. Le marketplace.json d'un dépôt peut lister des dizaines de plugins sans rapport ; considérez-le comme le registre, avec plugin.json comme package individuel à l'intérieur.

Installation depuis les marketplaces

Obtenir un plugin sur votre machine prend deux commandes. D'abord, pointez Claude Code vers une marketplace :

/plugin marketplace add anthropic/plugins

Ceci lit le marketplace.json de ce dépôt et ajoute tous les plugins qu'il liste à ce que vous pouvez parcourir. Ensuite, installez-en un :

/plugin install code-standards@anthropic

La partie @anthropic spécifie quelle marketplace utiliser, car vous pouvez en avoir plusieurs ajoutées à la fois et le même nom de plugin pourrait théoriquement exister dans plus d'une. Claude Code récupère les fichiers du plugin, enregistre ses compétences et commandes, et connecte les hooks ou serveurs MCP qu'il déclare.

Voici la partie qui devrait vous sembler familière si vous avez lu quoi que ce soit d'autre que nous avons écrit : personne ne les examine. Ajouter une marketplace signifie faire confiance à celui qui maintient ce dépôt, et installer un plugin à partir de celle-ci signifie faire confiance à chaque fichier que le plugin apporte, y compris les hooks qui exécutent des commandes shell et les serveurs MCP qui obtiennent un accès réseau. C'est exactement le problème de confiance que nous avons documenté pour les compétences, sauf qu'un plugin a plus de pièces mobiles, ce qui signifie plus d'endroits où quelque chose de mal peut se cacher. Une compétence ne peut être qu'un texte persuasif chargé dans le contexte. Un plugin peut aussi être un hook qui s'exécute à chaque commit, que vous regardiez ou non.

Notre liste de contrôle de sécurité pour les compétences s'applique ici avec une addition. Avant d'installer un plugin :

1. Lisez le manifeste et chaque fichier auquel il fait référence avant d'exécuter la commande d'installation, pas après. Un plugin.json prétendant être un "assistant de déploiement" qui déclare également un serveur MCP pointant vers un domaine inconnu est un signal qui mérite d'être examiné.
2. Épinglez la version. Installez code-standards@1.2.0, pas ce que latest résoudra mardi prochain. Un plugin qui change son comportement de hook après que vous l'ayez déjà approuvé est pire qu'un plugin qui était mauvais dès le départ, car vous ne le chercherez pas.
3. Vérifiez spécifiquement quels hooks et commandes sont livrés. Les hooks s'exécutent automatiquement, sans que vous ne tapiez quoi que ce soit, lors d'événements tels que les appels d'outils et les sauvegardes de fichiers. C'est le composant le plus digne d'être lu en entier, car c'est celui qui agit sans votre invite sur le moment.
4. Traitez un serveur MCP inclus dans un plugin comme tout autre serveur MCP : il obtient un accès réseau réel et souvent des identifiants réels. L'inclure dans un plugin ne le rend pas plus sûr, cela le rend juste plus facile à installer sans remarquer sa présence.

Nous couvrons le modèle de menace complet, y compris à quoi ressemble un hook ou une compétence malveillante en pratique, dans notre guide de sécurité des compétences. Tout ce qui concerne le traitement des instructions tierces comme une dépendance que vous n'avez pas auditée s'applique aux plugins, mais avec un rayon d'explosion plus large.

Quand empaqueter la configuration de votre équipe en tant que plugin

Le signal le plus clair que vous êtes prêt pour un plugin : vous avez écrit les mêmes instructions de configuration dans un README, une épingle Slack et un document d'intégration, et elles sont déjà désynchronisées dans deux des trois endroits.

Prenons un cas concret. Une équipe de plateforme souhaite que chaque session Claude Code des ingénieurs applique les mêmes normes : pas de commits directs sur main, une passe de revue de code cohérente avant la fusion, et un déploiement en une commande vers staging. Séparément, c'est un hook que quelqu'un doit se souvenir d'ajouter à settings.json, une compétence que quelqu'un doit se souvenir d'installer, et une commande dont quelqu'un doit se souvenir de l'existence. Empaqueté en tant que plugin team-standards, c'est une ligne :

/plugin install team-standards@our-org

et chaque nouvel employé obtient le hook de protection de branche, la compétence checklist de revue de code et la commande /deploy en une seule étape, versionnées ensemble de sorte qu'une mise à jour du script de déploiement et une mise à jour des critères de revue soient livrées dans la même version au lieu de dériver.

Le signal inverse est également important : si votre configuration est une seule compétence sans hooks, commandes ou dépendance MCP, l'empaqueter en tant que plugin ajoute un manifeste et une liste de marketplace sans bénéfice. Publiez-la comme une compétence seule, comme nous le couvrons dans ce que sont les compétences Claude, et utilisez un plugin uniquement lorsqu'il y a plus d'une pièce mobile à maintenir en synchronisation. Si le serveur MCP est la partie compliquée de votre configuration, nos notes sur la création d'un se trouvent dans MCP Builder, ce qui vaut la peine d'être consulté avant de décider si un plugin a besoin de son propre serveur plutôt que de pointer vers un serveur existant.

Notre propre guide de configuration Claude Code en 30 minutes explique comment construire cette couche couche par couche pour un individu ; un plugin d'équipe est le même exercice de superposition, juste versionné et partagé au lieu d'être assemblé manuellement sur chaque ordinateur portable.

L'écosystème en 2026, honnêtement

Les plugins sont jeunes, et ça se voit. Le format de marketplace n'a été stabilisé qu'il y a quelques mois, ce qui signifie que la plupart des fichiers marketplace.json en circulation ont été écrits contre une ébauche précoce de la spécification et n'ont pas été touchés depuis. La qualité de la documentation varie énormément : certains dépôts de plugins ont un README clair avec un historique des versions, d'autres sont un seul commit sans explication de ce que le hook inclus fait réellement.

La fragmentation est le problème le plus important. Parce qu'un plugin peut déclarer ses propres compétences au lieu de référencer celles que vous avez déjà installées, le même comportement est réinventé dans une douzaine de plugins différents avec une douzaine de barres de qualité différentes. Nous avons vu une compétence de revue de code incluse dans trois plugins sans rapport, aucun n'étant conscient de l'existence des autres, chacun écrit selon une norme différente.

Cela produit la même loterie de qualité que nous avons documentée pour les compétences communautaires en général : environ la moitié de ce que nous testons échoue du premier coup, que ce soit à cause d'un script d'installation qui suppose une structure de répertoire que l'auteur n'a jamais vérifiée sur une machine propre, ou d'un hook qui ne fait rien silencieusement parce qu'il a été écrit contre une version antérieure de l'API des hooks. Un plugin ne résout pas ce taux d'échec. Il regroupe simplement plus de composants qui peuvent chacun échouer indépendamment, et un plugin ne fonctionne que si chaque pièce à l'intérieur le fait.

Rien de tout cela ne signifie qu'il faut éviter les plugins. Cela signifie appliquer le même scepticisme que vous appliqueriez à toute dépendance : vérifiez qui la maintient, vérifiez quand elle a été mise à jour pour la dernière fois, et n'installez pas quelque chose avec trois composants lorsque vous n'en avez besoin que d'un. Le format d'empaquetage est vraiment utile pour maintenir une équipe synchronisée. Ce n'est pas un substitut à la lecture de ce que vous installez.

FAQ

Quelle est la différence entre un plugin Claude Code et une compétence ?

Une compétence est un comportement unique dans un fichier markdown. Un plugin est une unité de distribution qui peut regrouper plusieurs compétences aux côtés de sous-agents, de hooks, de commandes slash et d'un serveur MCP, le tout installé ensemble avec une seule commande et un seul numéro de version. Les compétences de chaque plugin sont toujours des compétences en dessous ; le plugin est juste l'empaquetage autour d'elles.

Comment installer un plugin Claude Code ?

Ajoutez d'abord la marketplace avec /plugin marketplace add <repo>, puis installez un plugin spécifique à partir de celle-ci avec /plugin install <plugin-name>@<marketplace>. Épinglez une version plutôt que d'installer ce que la marketplace pointe actuellement comme dernière, afin qu'une mise à jour ne change pas silencieusement un comportement que vous avez déjà examiné.

Les plugins Claude Code sont-ils sûrs à installer ?

Traitez-les comme vous traiteriez toute dépendance tierce, et plus attentivement qu'une simple compétence, car un plugin peut également livrer des hooks qui exécutent automatiquement des commandes shell et des serveurs MCP avec un accès réseau réel. Lisez le manifeste et chaque fichier inclus avant d'installer, pas après. Notre guide de sécurité des compétences couvre le modèle de menace sous-jacent en détail.

Puis-je mettre mon propre serveur MCP dans un plugin ?

Oui. Un plugin peut déclarer un .mcp.json qui configure un serveur MCP dans le cadre de l'installation, de sorte que les membres de l'équipe obtiennent la connexion configurée automatiquement au lieu de la configurer manuellement dans chaque projet. Si vous construisez le serveur lui-même plutôt que de simplement le connecter, consultez MCP Builder pour la partie construction de celui-ci.

Où trouver des plugins Claude Code à installer ?

Anthropic maintient une marketplace officielle, et des marketplaces communautaires se sont développées rapidement depuis le lancement du format. La qualité varie autant que pour les compétences communautaires en général, alors vérifiez le manifeste, vérifiez quand il a été mis à jour pour la dernière fois, et privilégiez les plugins des mainteneurs qui documentent ce qui est réellement à l'intérieur avant d'ajouter leur marketplace.