Plugins Claude Code : installer et créer les siens

Installer un plugin Claude Code tient en une commande, claude plugin install nom@catalogue. Ce qui suit demande plus d'attention : un plugin activé fait partie de chaque session, ses hooks se déclenchent sans qu'on l'appelle, et ses fichiers peuvent changer à la mise à jour suivante. Nous utilisons sept plugins sur le serveur où travaillent nos agents de développement, et l'inventaire que nous en avons fait le 26 octobre 2026 a relevé trois points que les commandes d'inventaire ne montrent pas, ou montrent mal.

Ce tutoriel s'adresse aux développeurs et aux équipes qui utilisent déjà Claude Code et veulent installer des plugins sans perdre la main sur leur configuration, ou empaqueter la leur pour la partager. Chaque commande a été rejouée le 26 octobre 2026 sur Claude Code 2.1.306, avec un plugin jetable créé pour l'occasion.

Ce qu'un plugin Claude Code ajoute à chacune de vos sessions

Un plugin ajoute à toutes vos sessions des instructions que Claude lit et du code qui s'exécute avec vos droits, même quand vous ne vous en servez pas. Techniquement, c'est un dossier qui regroupe des skills, des agents, des hooks ou des serveurs MCP, que Claude Code installe et charge comme un seul bloc, selon la présentation officielle des plugins. Le manifeste .claude-plugin/plugin.json lui donne son nom, seul champ obligatoire. La page des composants en liste davantage : skills et commandes, sous-agents, hooks, serveurs MCP et serveurs de langage, moniteurs qui tournent en tâche de fond, styles de réponse, thèmes, et un dossier bin/ que Claude Code ajoute au PATH de son shell.

Le nom et la description de chaque skill et de chaque agent que Claude peut invoquer de lui-même occupent le contexte à chaque tour, que le plugin serve ou non. Ses serveurs MCP démarrent avec la session, et ses hooks se déclenchent à leurs événements dès le chargement, sans attendre qu'on appelle le plugin. Tout ce qu'il exécute, il l'exécute avec vos droits d'utilisateur. La page de sécurité des plugins précise que hooks, moniteurs et serveurs MCP ou de langage tournent hors du bac à sable de Claude Code, et que les règles de permission ne couvrent que les appels d'outils faits par le modèle.

Notre inventaire donne un ordre de grandeur. Sept plugins sont installés, six depuis le catalogue officiel d'Anthropic et un depuis un catalogue tiers ; six sont actifs. Ensemble, les six actifs apportent 24 skills, 3 agents, 1 hook, 1 serveur MCP et 1 serveur de langage. Aucun écran de session ne donne ce total : il faut lancer claude plugin details sur chaque plugin pour le reconstituer, et son affichage s'est révélé incomplet sur un point. Si le plugin que vous visez sert surtout à brancher un outil externe, lisez aussi notre article sur le fonctionnement du Model Context Protocol : un serveur MCP seul suffit souvent, sans plugin autour.

Installer un plugin : catalogue, portée et première commande

Pour installer un plugin, on ajoute une fois le catalogue qui le liste, puis on installe le plugin par son nom suivi de celui du catalogue. Un catalogue, que la documentation appelle marketplace, est un dépôt git ou un dossier qui contient un fichier .claude-plugin/marketplace.json. Claude Code ajoute le catalogue officiel, claude-plugins-official, à la première session interactive dans un terminal. Pour les autres, la page d'installation accepte un dépôt GitHub sous la forme propriétaire/dépôt, une URL git complète, un chemin local qui commence par ./ ou un fichier marketplace.json hébergé. Depuis le shell, la séquence tient en quatre commandes :

claude plugin marketplace add votre-org/catalogue-claude
claude plugin install outils-equipe@catalogue-claude --scope project
claude plugin list
claude plugin details outils-equipe

La portée décide pour qui le plugin est actif, et la documentation d'installation en décrit trois. En portée utilisateur, valeur par défaut, l'entrée va dans ~/.claude/settings.json et vaut pour tous vos projets. En portée projet, elle va dans le fichier .claude/settings.json que vous committez : le plugin s'active pour toute l'équipe, mais chaque collègue doit encore l'installer sur sa machine. La portée locale, dans .claude/settings.local.json, ne vaut que pour vous et ce dépôt, et elle l'emporte sur les deux autres. Une session dans le cloud, y compris sur claude.ai/code, ne charge pas les plugins de vos réglages locaux. En mode non interactif avec claude -p, les plugins déjà installés se chargent, mais le panneau /plugin n'est pas disponible.

Le catalogue officiel donne une idée de l'offre. Son fichier de catalogue sur GitHub listait 315 plugins le 26 octobre 2026, à son dernier commit du 23 octobre. Seuls 53 sont stockés dans le dépôt lui-même ; les 262 autres sont récupérés depuis les dépôts de leurs éditeurs, chacun épinglé sur un commit précis. Le nom d'un catalogue dit qui le publie, sans rien garantir sur ce que fait chaque plugin qu'il référence. D'après la page de sécurité, Claude Code n'accepte les noms officiels que pour des catalogues hébergés sous github.com/anthropics/ : un catalogue tiers ne peut donc pas porter l'un de ces noms.

Mesurer ce qu'un plugin coûte, hooks compris

La commande claude plugin details chiffre le coût permanent d'un plugin en jetons, mais elle ne compte que les noms et descriptions de ses skills et agents. La page de mesure des plugins le dit : hooks et serveurs MCP n'y reçoivent aucune estimation, et le coût des outils MCP se lit avec /context dans une session. Pour les plugins du catalogue officiel, le panneau /plugin affiche aussi ce coût avant installation, et le surligne à partir de 2 000 jetons par tour. Sur notre serveur, les quatre plugins qui portent des skills ajoutent environ 2 337 jetons à chaque session, avant la moindre demande.

Le premier de ces trois points se trouve là. Pour superpowers, dans la version 7.0.0 que le catalogue officiel épingle, la commande affiche un hook SessionStart marqué « harness-only » et « no model context cost », donc sans coût en contexte. D'après son fichier de hooks, il se déclenche au démarrage, après /clear et après chaque compactage, et son script renvoie un champ additionalContext de 3 405 caractères : le texte complet d'un de ses skills, assorti d'une consigne qui demande à Claude d'invoquer un skill pertinent avant toute réponse. Or la référence des hooks indique que ce champ ajoute du contexte pour Claude, avec un plafond de 10 000 caractères par chaîne.

Nous l'avons vérifié avec un plugin jetable dont le hook de démarrage injecte un faux mot de passe du jour. La commande details lui a appliqué la même mention « no model context cost ». Lancé par claude -p avec le plugin, Claude a cité le mot de passe et précisé qu'il venait du hook ; sans le plugin, il a répondu n'en avoir aucun. Avant d'adopter un plugin, ouvrez donc son hooks/hooks.json et repérez en priorité les hooks SessionStart et UserPromptSubmit, dont la sortie entre dans la conversation. Ce texte compte dans votre contexte, et il peut orienter la conduite de Claude.

Relire un plugin tiers avant de lui faire confiance

Avant d'installer un plugin tiers, lisez les trois fichiers qui exécutent du code : hooks/hooks.json, .mcp.json et le contenu du dossier bin/. Le panneau de détails de /plugin annonce qu'un hook existe sans dire ce qu'il lance, et la documentation de sécurité renvoie explicitement à ces fichiers. Elle reproduit aussi l'avertissement que Claude Code affiche avant chaque installation, selon lequel, en substance, Anthropic ne contrôle pas ce que contiennent les plugins et ne peut pas garantir qu'ils ne changeront pas. Nous avons détaillé les permissions et le bac à sable de l'outil dans notre article sur la sécurité de Claude Code ; un plugin passe en partie à côté de ces protections.

La relecture ne vaut que pour la version relue. Le catalogue officiel a la mise à jour automatique activée par défaut, et la référence du chargement des plugins en décrit le moment : après le premier message d'une session, Claude Code rafraîchit les catalogues concernés dans un délai aléatoire de dix minutes au plus, puis remplace les copies sur disque. Notre copie de superpowers est passée de la version 6.4.1 à la 7.0.0, une version majeure, le 16 octobre 2026. Entre les deux, 54 fichiers diffèrent dans nos copies, dont le script du hook de démarrage lui-même, ce que confirme la comparaison publique des deux versions. Les catalogues tiers ont la mise à jour automatique désactivée par défaut, ce qui protège d'un changement imprévu mais laisse passer les correctifs.

Le deuxième point concerne les serveurs de langage. Le plugin swift-lsp apparaît « ✔ enabled » dans claude plugin list sur notre serveur Linux, alors que le binaire sourcekit-lsp qu'il doit lancer n'y est pas installé. La page des composants le confirme : un plugin configure la connexion mais n'installe pas le serveur, et l'échec se lit dans le journal de claude --debug. Pour retirer un plugin dont vous doutez, claude plugin uninstall suffit, mais ses fichiers restent 14 jours dans ~/.claude/plugins/cache/ avant le nettoyage automatique, selon la documentation de sécurité.

Créer son plugin Claude Code, testé pas à pas

Un plugin minimal tient en deux fichiers, un manifeste et un skill, auxquels nous avons ajouté un hook pour exercer le cas qui demande le plus de soin. Notre plugin de test suit cette arborescence :

outils-equipe/
├── .claude-plugin/plugin.json
├── skills/message-commit/SKILL.md
└── hooks/
    ├── hooks.json
    └── rappel.sh

Le manifeste se limite à quatre champs, dont seul name est obligatoire ; il devient le préfixe de chaque skill et de chaque agent du plugin.

{
  "name": "outils-equipe",
  "description": "Conventions de l'équipe : messages de commit et règle de relecture",
  "version": "0.1.0",
  "author": { "name": "Noxcod" }
}

Le fichier hooks/hooks.json reprend la forme du bloc hooks des réglages, ce qui permet d'y recopier un hook existant tel quel.

{
  "hooks": {
    "SessionStart": [
      { "matcher": "startup",
        "hooks": [ { "type": "command",
                     "command": "\"${CLAUDE_PLUGIN_ROOT}/hooks/rappel.sh\"" } ] }
    ]
  }
}

Seul plugin.json va dans .claude-plugin/ : un dossier skills/ rangé là ne se charge pas, d'après la documentation de création de plugins. Un fichier CLAUDE.md à la racine du plugin n'est pas lu non plus, précise la page des composants, donc toute consigne passe par un skill. Le skill s'appelle ensuite avec le préfixe du plugin, /outils-equipe:message-commit, ce qui évite les collisions avec vos skills personnels. Pour écrire des skills qui se déclenchent au bon moment, notre tutoriel sur la création de skills Claude Code détaille la description, les champs d'en-tête et les tests.

La première validation, avec claude plugin validate ./outils-equipe, a rendu un avertissement que nous n'attendions pas : le chemin ${CLAUDE_PLUGIN_ROOT} n'était pas entre guillemets dans la commande du hook, et un chemin d'installation qui contient une espace aurait coupé la commande en plusieurs mots. D'où les guillemets échappés dans la version ci-dessus. Le validateur a aussi listé deux refus propres au répertoire d'Anthropic, l'absence de README et de licence, sans changer le résultat, qui reste « Validation passed with warnings » avec un code de sortie 0. D'après l'aide de la commande, ces contrôles ne bloquent qu'avec l'option --profile directory, à réserver à un plugin destiné à ce répertoire.

Pour l'essayer sans l'installer, claude --plugin-dir ./outils-equipe le charge le temps d'une session, et /reload-plugins applique vos modifications sans redémarrer. Pour qu'il se charge à chaque session sans catalogue, claude plugin init outils-equipe crée le squelette dans ~/.claude/skills/outils-equipe/, où Claude Code le reprend sous l'identifiant outils-equipe@skills-dir. Si vous partez d'un dossier .claude/ existant, copiez skills et agents dans le plugin, mais retirez vos hooks des réglages une fois la copie testée : tant que les deux versions coexistent, chaque hook s'exécute deux fois, prévient la documentation de création.

Diffuser un plugin à l'équipe sans figer les mises à jour

Pour une équipe, le bon support est un catalogue privé avec une règle de version explicite. Le catalogue est un dépôt git qui contient .claude-plugin/marketplace.json avec un name, un owner et la liste des plugins. La page de création de catalogue conseille de le valider puis d'installer depuis lui sur votre machine avant de le partager, parce que la validation et l'installation n'attrapent pas les mêmes erreurs. Un chemin vers un dossier absent passe la validation et n'échoue qu'à l'installation. Dans un dépôt privé, Claude Code clone avec les identifiants git déjà présents sur la machine et ne demande jamais de mot de passe : sans clé SSH chargée ni identifiant enregistré, l'ajout échoue.

{
  "name": "catalogue-claude",
  "owner": { "name": "Votre équipe" },
  "plugins": [
    { "name": "outils-equipe",
      "source": "./plugins/outils-equipe",
      "description": "Conventions de commit et règle de relecture" }
  ]
}

La version mérite une décision explicite, parce qu'elle commande les mises à jour. D'après la page d'hébergement des catalogues, un plugin qui déclare "version": "1.0.0" garde vos collègues sur leur copie en cache tant que la chaîne ne change pas, quel que soit le nombre de commits poussés. Sans champ version, la référence du chargement calcule la version à partir du commit, et chaque nouveau commit devient une mise à jour.

Notre cache illustre le troisième point, le revers de ce second choix. Les plugins frontend-design, feature-dev et context7 du catalogue officiel n'ont pas de champ version. Entre le 13 et le 23 octobre 2026, Claude Code en a téléchargé 13 copies chacun, et pour chaque plugin les 13 copies ont des fichiers identiques octet pour octet, en dehors des marqueurs de nettoyage. Chaque commit du catalogue a produit une nouvelle version d'un plugin qui n'avait pas changé, et chaque ancienne copie attend 14 jours avant d'être effacée, comme le décrit la référence du chargement. Pour un plugin d'équipe, nous fixons donc la version et la montons à chaque livraison, avec claude plugin tag, qui, d'après son aide, crée l'étiquette git nom--v0.2.0 après avoir vérifié que plugin.json et l'entrée du catalogue s'accordent.

Deux réglages complètent la diffusion, décrits dans la page d'hébergement. Pour enregistrer le catalogue chez tous ceux qui ouvrent le dépôt, lancez une fois claude plugin marketplace add votre-org/catalogue-claude --scope project et committez le .claude/settings.json produit ; chacun devra accepter la confiance du dossier. La mise à jour automatique d'un catalogue tiers reste désactivée tant que chaque utilisateur ne l'active pas dans /plugin, ou qu'un administrateur ne pose pas autoUpdate dans les réglages gérés. Pour renommer un plugin sans casser les installations, ajoutez une table renames au catalogue plutôt que de modifier son name.

Plugin, skill ou simple réglage : notre règle de choix

Nous ne faisons un plugin que lorsqu'une même configuration doit vivre dans plusieurs dépôts ou chez plusieurs personnes, avec des versions numérotées. Pour un seul dépôt, un dossier .claude/skills/ commité suffit, et un skill personnel vit dans ~/.claude/skills/ sans aucun emballage. La documentation dit la même chose dans sa section sur le choix d'un plugin : skills, agents, hooks et serveurs MCP fonctionnent sans plugin, et le plugin sert à les livrer ensemble, à jour, à d'autres que vous. Le reste de notre organisation, mémoire et hooks compris, est décrit dans notre méthode pour utiliser Claude Code.

Pour les plugins des autres, nous appliquons quatre règles depuis cet inventaire :

• lire hooks.json, .mcp.json et bin/ avant l'installation, puis après chaque mise à jour majeure ;
• chiffrer le coût avec claude plugin details, et ajouter à la main la sortie des hooks de démarrage ;
• essayer chaque composant une fois au lieu de croire le statut « enabled » ;
• désactiver avec claude plugin disable ce qui ne sert plus, que /plugin range sous « Not used recently » après 14 jours et 10 sessions sans usage, selon la page de mesure.

Dans une équipe, le gros du travail porte sur l'organisation : décider qui maintient le catalogue, qui relit un plugin avant sa diffusion et quelle version fait foi. Si vous voulez auditer les plugins déjà installés sur vos postes ou monter un catalogue d'équipe, vous pouvez contacter Noxcod.

Questions fréquentes sur les plugins Claude Code

Quelle différence entre un plugin et un skill Claude Code ?

Un skill est un dossier avec un fichier SKILL.md qui décrit une procédure. Un plugin est un paquet qui peut contenir plusieurs skills, mais aussi des agents, des hooks, des serveurs MCP ou de langage, avec un manifeste, une version et un catalogue pour les diffuser. Ses skills prennent le nom du plugin en préfixe, comme /outils-equipe:message-commit. Un skill isolé suffit pour vous ou pour un seul dépôt ; le plugin sert à partager un ensemble cohérent entre plusieurs dépôts ou plusieurs personnes.

Comment désactiver un plugin sans le désinstaller ?

Dans le shell, claude plugin disable nom@catalogue le désactive dans la portée la plus précise qui le mentionne, selon la page de gestion, et claude plugin enable le réactive. Dans une session, l'onglet Installed de /plugin fait la même chose avec la barre d'espace. Si vous demandez sa désinstallation alors que le dépôt l'active pour toute l'équipe, Claude Code propose de le désactiver pour vous seul, dans .claude/settings.local.json. Un moniteur déjà lancé tourne jusqu'à la fin de la session.

Pourquoi une mise à jour de plugin ne change rien ?

Le plus souvent, la version calculée n'a pas bougé : l'auteur a fixé "version" dans plugin.json sans la monter, et claude plugin update répond que le plugin est déjà à jour. La session ouverte garde aussi la version chargée au démarrage : lancez /reload-plugins pour basculer hooks et serveurs, ou redémarrez pour les moniteurs. Pour un catalogue tiers sans mise à jour automatique, passez par claude plugin update nom@catalogue, car claude plugin marketplace update rafraîchit la liste sans toucher aux plugins installés.

Les plugins fonctionnent-ils avec claude -p en intégration continue ?

Selon la documentation d'installation, les plugins déjà installés se chargent en mode non interactif, mais le panneau /plugin n'y est pas disponible, et l'installation se fait par claude plugin install dans le script. Les moniteurs ne démarrent pas avec -p, et un plugin activé par le dépôt en portée projet exige la confiance accordée au dossier, que -p ne donne pas, d'après la référence du chargement. En CI, installez les plugins en portée utilisateur dans l'image, puis vérifiez-les avec claude plugin list.

Un plugin Claude Code fonctionne-t-il aussi sur claude.ai ?

Le même dossier s'installe sur claude.ai et dans Cowork, mais un autre sous-ensemble de composants s'y charge, d'après la page des composants. Un serveur MCP local ne tourne pas sur claude.ai, où il faut un serveur distant accessible par une URL https. Un plugin qui contient un dossier bin/ à sa racine n'y est pas installé du tout. Si votre équipe utilise les deux, rangez vos exécutables dans un dossier scripts/ appelé par les hooks.