Plugins : empaqueter un ensemble de configurations éparses en un clic

📚 Navigation de la série : L'article précédent [23 Sous-agents (Subagents)] vous a appris à créer votre propre assistant spécialisé de vos propres mains. Mais avez-vous remarqué un problème ? Les subagents, commandes, skills, hooks, toutes ces bonnes choses sont des pièces détachées configurées individuellement. Cet article vous apprennent à les regrouper dans un plugin : installez-les et désactivez-les en un clic, et vous pourrez même récupérer des packages complets prêts à l'emploi créés par d'autres directement depuis le « marketplace de plugins ».

Les amis, aujourd'hui nous allons parler de la façon d'empaqueter un ensemble de configurations éparses en un clic. À ce propos, avez-vous déjà rencontré ce scénario : vous avez travaillé dur pour configurer un ensemble de « subagent + hook + MCP » pour votre équipe, puis un jour un nouveau collègue arrive, vous lui expliquez pendant une demi-heure — « ce fichier va dans agents/, cette partie de hook est à ajouter dans settings.json, et au fait n'oublie pas le .mcp.json » — et après l'explication, vous vous rendez compte qu'il a quand même oublié un endroit, et que l'exécution chez lui n'est pas la même que chez vous. Ce n'est la faute de personne, la gestion de pièces détachées est ainsi faite : plus les configurations sont dispersées, plus il est facile d'oublier des choses lors des explications orales.

Regardez en arrière ce que vous avez accumulé au fil des articles précédents : le 18e article présentait le CLAUDE.md, le 22e configurait un serveur MCP, le 23e créait un subagent, avec des skills et des hooks intercalés au milieu. Chaque élément est utile individuellement, mais ils sont tous dispersés — le subagent va dans agents/, le hook est écrit dans settings.json, le MCP est configuré dans .mcp.json, répartis dans plusieurs fichiers.

Le problème est là : ce que vous avez configuré avec tant d'efforts dans le projet A, vous devez le copier fichier par fichier si vous voulez le réutiliser dans le projet B. Et si un nouveau collègue de l'équipe veut votre configuration, vous devez lui expliquer oralement la structure des répertoires, avec le risque d'oublier des choses. La gestion de pièces détachées est à la fois fatigante et propice aux erreurs.

En clair, les plugins sont la réponse officielle de Claude Code à ce problème : regrouper ces pièces détachées (commands, subagents, skills, hooks, serveurs MCP) dans un package global distribuable et activable/désactivable en un clic. Cet article explique en détail ce qu'est un plugin, comment en récupérer des tout prêts sur le marché, et comment les gérer.

Après avoir lu cet article, vous saurez :

• Ce que contient exactement un plugin et comment choisir entre « configuration en pièces détachées » et « plugin », le tout résumé dans un tableau clair.
• La logique en deux étapes du « marketplace de plugins » : d'abord ajouter le marché, puis installer le plugin, avec les commandes à copier-coller.
• Comment installer un plugin depuis le marché de démonstration officiel et exécuter les commandes qu'il apporte, avec les résultats attendus.
• À quoi ressemble la structure d'un répertoire de plugin (plugin.json + dossiers de composants), pour pouvoir l'imiter lorsque vous voudrez créer le vôtre.
• L'étape cruciale de la « confiance » avant d'installer des plugins tiers : ne considérez jamais un plugin inconnu comme un logiciel inoffensif.

---

01 Comprendre d'abord : qu'est-ce qu'un plugin au juste ?

Pour commencer par la conclusion : un plugin n'est rien d'autre qu'un « dossier autonome » qui regroupe les extensions que vous avez apprises précédemment (skill, subagent, hook, commande, serveur MCP) afin de pouvoir les installer, les désactiver et les distribuer comme un tout.

Pourquoi en a-t-on besoin ? Parce que les configurations en pièces détachées présentent trois inconvénients majeurs : la réutilisation difficile d'un projet à l'autre, le partage manuel au sein de l'équipe et l'impossibilité de suivre les mises à jour. Pour transférer un subagent et un hook configurés dans un projet vers un autre, vous devez copier-coller manuellement ; pour les partager avec des collègues, vous devez expliquer précisément où placer chaque fichier. Le plugin consiste à mettre tout cela « dans une boîte », de sorte qu'il suffit de déplacer la boîte entière ou de la donner à quelqu'un d'autre.

Analogie : le store d'extensions de navigateur. Si vous voulez ajouter un bloqueur de publicité, un traducteur ou un outil de capture d'écran à Chrome — vous n'avez pas besoin d'écrire de code ou de modifier des configurations, vous allez sur le store d'extensions, vous cliquez sur « Installer », et tout un ensemble de fonctionnalités est intégré. Si vous n'en voulez plus, vous cliquez sur « Supprimer » pour une désinstallation propre. C'est exactement la même approche pour les plugins de Claude Code : parcourir le marché, installer un ensemble de fonctionnalités en un clic, sans avoir à tout configurer manuellement pièce par pièce ; cela transforme les extensions auparavant dispersées dans plusieurs fichiers en un seul élément directement « installable/désinstallable » dans le store.

La documentation officielle explique très bien le choix entre « plugin » et « configuration en pièces détachées », je vous l'ai résumé dans un tableau :

Dimension	Configuration en pièces détachées (répertoire .claude/)	Plugin (plugin)
Le plus adapté pour	Utilisation propre à un projet, flux de travail personnel, expérimentation rapide	Partage au sein de l'équipe/communauté, réutilisation multi-projet, publication versionnée
Comment partager	Copier manuellement les fichiers pour les donner à d'autres	Via le marché, les autres installent en un clic avec /plugin install
Nom du skill	Court, par exemple /hello	Avec espace de noms (namespace), par exemple /my-plugin:hello
Gestion des versions possible	Non, les modifications ne peuvent pas être notifiées aux utilisateurs	Oui, l'utilisateur reçoit les mises à jour uniquement si un numéro de version est défini

La logique de décision de ce tableau tient en une phrase : pour un projet personnel et une utilisation à la volée, le vrac suffit ; si c'est pour d'autres personnes, pour du multi-projet ou pour pouvoir mettre à jour, passez aux plugins. La recommandation officielle est d'ailleurs de « commencer par itérer rapidement en vrac avec .claude/, puis de le transformer en plugin une fois prêt à être partagé » — ne créez pas un plugin dès le départ pour une configuration unique, ce serait de la sur-ingénierie.

Voici un point sur lequel les débutants se trompent le plus souvent, qu'il convient de clarifier dès le départ : le nom d'un skill dans un plugin comporte toujours un « espace de noms ». Si vous écrivez un skill hello dans un plugin nommé my-plugin, vous ne l'appelez pas avec /hello, mais avec /my-plugin:hello.

💡 En résumé : un plugin emballe skill, subagent, hook, commande et serveur MCP dans une boîte facile à installer et à désinstaller ; le vrac convient pour un usage personnel, mais pour le partage, la réutilisation et les mises à jour, emballez le tout sous forme de plugin.

---

02 Pourquoi empaqueter est plus efficace que de laisser les fichiers dispersés

La section précédente a expliqué le « quoi », celle-ci vient appuyer sur le « pourquoi cela en vaut la peine » — car si vous ne connaissez que le concept, vous pourriez encore vous dire « copier manuellement quelques fichiers ne me prend pas beaucoup de temps ».

La vraie différence se joue sur trois aspects, illustrés par des scénarios concrets :

Premièrement, la réutilisation multi-projet. Imaginez que vous ayez une configuration habituelle pour votre « flux de travail de commit Git » — un skill pour générer des messages de commit standardisés, et un hook pour lancer automatiquement le lint avant le commit. Au début, cette configuration est en pièces détachées, donc à chaque nouveau projet, vous devez copier le contenu de skills/ et la section correspondante de settings.json. Si vous oubliez la partie hook, le lint ne sera pas exécuté avant le commit dans le nouveau projet, risquant d'introduire une erreur de formatage. Une fois empaqueté en plugin, une seule commande /plugin install dans le nouveau projet suffit, et vous n'oublierez plus rien.

Deuxièmement, le partage en équipe. Partager des configurations en pièces détachées avec des collègues revient généralement à dire « copie ce dossier, mets-le sous .claude/agents/, et puis n'oublie pas d'ajouter ce hook dans tes paramètres » — des explications orales qui mènent presque à coup sûr à des erreurs de configuration chez l'autre. Avec un plugin, c'est différent : vous le publiez sur un marché (même un dépôt privé interne à l'entreprise), votre collègue l'installe avec une seule commande, et la configuration est rigoureusement identique, évitant le classique « ça marche chez moi mais pas chez toi ».

Troisièmement, les mises à jour de version. C'est la faiblesse majeure du vrac. Si une configuration en vrac change, les personnes qui l'utilisent n'ont aucun moyen de le savoir, à moins que vous ne les préveniez individuellement. Un plugin peut comporter un numéro de version : lorsque vous publiez une nouvelle version, l'utilisateur reçoit automatiquement la mise à jour lorsqu'il met à jour ; la documentation officielle mentionne même une « mise à jour automatique » — activée par défaut sur le marché officiel, et désactivée par défaut sur les marchés tiers (une conception très logique : les mises à jour de confiance sont reçues automatiquement, tandis que celles des tiers requièrent votre accord explicite).

Analogie : une application mobile et sa relation avec l'App Store. Lorsque vous installez une application et qu'une nouvelle version sort, le store vous pousse une notification « mise à jour disponible », et vous cliquez pour mettre à niveau sans avoir à retélécharger manuellement le package d'installation. Le plugin vis-à-vis du marché est comme l'application vis-à-vis de l'App Store — l'installation se fait en un clic, et les mises à jour découlent du marché, sans aucune manipulation manuelle de votre part.

Comparez la différence entre le vrac et le plugin sur ces trois aspects :

Ce que vous voulez faire	❌ Configuration en vrac	✅ Plugin
Transférer vers un nouveau projet	Copier manuellement chaque fichier, risque d'oubli	Une seule commande /plugin install
Donner à des collègues	Expliquer oralement où placer et comment configurer	Publier sur le marché, l'autre installe via une commande
Pousser des mises à jour	Impossible de notifier, obligation de prévenir manuellement	Avec numéro de version, mise à jour automatique/manuelle pour l'utilisateur

Pour être franc, quand on est seul sur un projet unique, on ne ressent pas vraiment les avantages des plugins ; mais dès que l'équipe s'agrandit ou que les projets se multiplient, le vrac commence à devenir un fardeau. J'ai moi-même basculé entièrement vers les plugins après avoir commencé à encadrer une équipe — auparavant, pour configurer l'environnement d'un nouveau venu, je devais passer une bonne partie de la matinée à lui expliquer fichier par fichier devant son écran « celui-ci va dans agents/, ce hook est à ajouter dans les settings », et il y avait toujours un oubli quelque part ; depuis que nous les avons empaquetés en plugins sur un dépôt interne, les nouveaux n'ont plus qu'une commande à lancer pour que leur configuration soit identique à la mienne, et nous n'avons plus jamais eu de problèmes de disparité.

💡 En résumé : la véritable valeur des plugins réside dans le changement d'échelle — la réutilisation multi-projet, le partage en équipe et les mises à jour se font en une seule commande avec les plugins, alors qu'ils reposent sur des manipulations humaines fastidieuses avec le vrac ; plus il y a de personnes et de projets, plus l'écart se creuse.

---

03 Marketplace de plugins : d'abord ajouter le « magasin », puis installer l'« application »

Maintenant que l'on sait ce qu'est un plugin, la question suivante est : où récupérer ceux créés par les autres ? La réponse est « le marketplace de plugins (plugin marketplace) ».

Voici la distinction la plus importante, et celle sur laquelle les débutants butent le plus souvent : l'utilisation du marché se fait en « deux étapes », pas en « une ».

• Étape 1 : Ajouter le marché. Enregistrer un marché auprès de Claude Code, afin qu'il puisse parcourir les plugins disponibles sur ce marché. Attention, cette étape n'installe aucun plugin, elle rend simplement le catalogue visible.
• Étape 2 : Installer le plugin. Choisir ce que vous voulez dans le catalogue et l'installer individuellement.

Analogie : installer un nouveau « store d'applications » sur votre téléphone. En plus du store par défaut de votre téléphone, vous pouvez installer un store d'applications tiers — mais « installer ce store » ne signifie pas « installer les applications qu'il contient ». Le store vous permet simplement de naviguer et de voir toute sa collection ; pour obtenir une application spécifique, vous devez cliquer dessus et la télécharger individuellement. Le marché de plugins est ce type de « store d'applications » : l'ajouter permet de naviguer, installer un plugin est une autre affaire.

Une fois que vous avez bien en tête ces « deux étapes », les commandes suivantes coulent de source. Voyons d'abord comment ajouter un marché — l'outil officiel prend en charge plusieurs sources, la plus courante étant depuis GitHub :

/plugin marketplace add owner/repo

Il suffit de remplacer owner/repo par le nom réel du dépôt GitHub (par exemple, le marché de démonstration officiel est anthropics/claude-code). En plus de GitHub, les marchés peuvent être ajoutés à partir d'une URL Git (GitLab, Bitbucket, auto-hébergé, etc.), d'un chemin local ou d'une URL distante ; la documentation officielle liste toutes ces syntaxes, les débutants n'ayant qu'à retenir la version GitHub, qui est la plus courante.

Une fois le marché ajouté, installez un plugin avec cette commande :

/plugin install plugin-name@marketplace-name

La partie après l'arobase @ correspond au nom du marché, ce qui signifie « installer ce plugin à partir de ce marché ». Par exemple, pour installer l'intégration GitHub à partir du marché officiel :

/plugin install github@claude-plugins-official

Il convient de mentionner spécifiquement le marché officiel intégré : claude-plugins-official. Vous n'avez pas besoin de l'ajouter manuellement — il est présent dès que vous lancez Claude Code, et contient une sélection de plugins validés par Anthropic (des intégrations externes comme GitHub, GitLab, Slack, Figma, Sentry, ainsi que des plugins LSP pour l'intelligence de code, des plugins de revue de sécurité, etc.). Ainsi, si vous souhaitez installer un plugin officiel, vous pouvez sauter l'étape « ajouter le marché » et passer directement à l'instruction install.

💡 En résumé : l'utilisation d'un marché se fait toujours en deux étapes : /plugin marketplace add pour ajouter le catalogue, et /plugin install xxx@nom-du-marché pour commander ; seul le marché officiel claude-plugins-official est pré-intégré et prêt à installer immédiatement.

---

04 Trois marchés officiels, pour quels usages ?

La section précédente a mentionné plusieurs noms de marchés, ce qui peut prêter à confusion. Cette section clarifie les trois marchés maintenus officiellement, afin que vous sachiez à quoi correspond chacun d'eux.

Analogie : trois centres commerciaux aux positionnements différents dans une même ville. L'un est un magasin d'usine officiel de la marque (proposant uniquement des articles rigoureusement sélectionnés par la marque), un autre est un grand marché ouvert aux exposants tiers (les tiers viennent y installer leurs stands, mais après avoir passé un contrôle de sécurité à l'entrée), et le dernier est un showroom temporaire (conçu uniquement pour exposer des échantillons afin de montrer ce qui est possible). Les trois marchés officiels de Claude Code correspondent exactement à ces définitions :

Marché	Commande pour l'ajouter	Positionnement	Contenu
claude-plugins-official (Officiel)	Intégré, pas besoin d'ajouter	Sélection officielle	Plugins sélectionnés par Anthropic, les plus stables
claude-community (Communauté)	/plugin marketplace add anthropics/claude-plugins-community	Soumis par des tiers, validé automatiquement	Plugins fournis par la communauté, chacun fixé à un commit spécifique
claude-code-plugins (Démonstration)	/plugin marketplace add anthropics/claude-code	Exemples officiels	Exemples de plugins pour montrer leurs capacités

Quelques points importants à préciser :

Le marché officiel est le plus stable mais n'est pas ouvert aux candidatures libres. Anthropic décide seul des plugins à y intégrer, le contenu y est soigneusement sélectionné, réduisant au minimum le risque de mauvaise surprise. Les intégrations classiques dont vous avez besoin au quotidien — intégration GitHub, LSP pour différents langages, revues de sécurité — s'y trouvent généralement.

Le marché de la communauté est ouvert, mais avec des barrières. Les plugins tiers soumis doivent passer une validation automatique et un filtre de sécurité d'Anthropic pour y entrer, et chaque plugin est « épinglé à un commit Git spécifique » — ce qui signifie que vous installez exactement la version examinée, sans que l'auteur puisse modifier le contenu en douce. Il doit être ajouté manuellement, et s'installe ensuite sous le nom claude-community.

Le marché de démonstration sert à l'apprentissage. Il contient des modèles montrant « ce que le système de plugins permet de réaliser », et nous l'utiliserons pour notre exercice pratique dans la section suivante. Il doit également être ajouté manuellement.

Ordre recommandé pour choisir vos plugins : priorisez le marché officiel ; s'il n'y est pas, cherchez dans le marché de la communauté, et si vous le trouvez, vérifiez sa page d'accueil et les autorisations requises avant de l'installer. Le marché de démonstration ne sert généralement que pour l'apprentissage ou les tests — son rôle est de servir de modèle, pas d'être utilisé au quotidien en production.

💡 En résumé : le marché officiel intégré est le plus stable, le marché de la communauté doit être ajouté manuellement mais fait l'objet de contrôles de sécurité, et le marché de démonstration sert de modèle pour apprendre ; au quotidien, commencez par le marché officiel, allez sur le marché de la communauté si besoin, et utilisez le marché de démonstration pour vous exercer.

---

05 Qu'installe-t-on réellement lorsque l'on installe un plugin ?

Une fois que vous lancez /plugin install, qu'est-ce qui est concrètement intégré à votre environnement ? Cette section l'explique en détail, pour vous éviter de vous demander « et maintenant, comment je m'en sers » une fois l'installation terminée.

Un plugin peut apporter plusieurs types de composants, chacun ayant son propre « mode de déclenchement », ce qui est le point clé :

Composant	Comment l'utiliser après installation
Skills / Commands	Deviennent des commandes avec espace de noms de la forme /nom-du-plugin:nom-du-skill, que vous lancez manuellement ou que Claude appelle automatiquement
Subagents	Apparaissent dans la liste /agents, Claude les affecte automatiquement selon la tâche ou vous pouvez les sélectionner manuellement
Hooks	Se déclenchent automatiquement lors d'événements correspondants (comme après la modification d'un fichier), sans que vous ayez à intervenir
MCP server	Démarre automatiquement, ses outils sont intégrés à la boîte à outils de Claude et utilisables directement
LSP server	Fournit à Claude une intelligence de code en temps réel (navigation vers la définition, recherche de références, erreurs instantanées) ; nécessite l'installation des binaires du serveur de langage correspondants

Vous l'avez compris ? Certains composants nécessitent que « vous les appeliez activement » (skills, commandes), tandis que d'autres « agissent automatiquement » (hooks, MCP, LSP). Par conséquent, après avoir installé un plugin, vous devez savoir quels types d'éléments il contient pour comprendre comment l'utiliser.

La bonne nouvelle est que la nouvelle version de Claude Code vous affiche ces éléments avant que vous ne les installiez. Dans l'interface /plugin, en ouvrant les détails d'un plugin, vous trouverez une section « Will Install » (Sera installé) qui liste les commandes, agents, skills, hooks, serveurs MCP et LSP apportés par le plugin. Elle fournit également une estimation du « Context Cost » (Coût de contexte) — qui vous indique combien de tokens ce plugin va consommer dans votre fenêtre de contexte à chaque tour.

Ce « coût de contexte » mérite que l'on s'y attarde, car il est crucial. Rappelez-vous ce que nous avons vu dans le 19e article sur la gestion du contexte : chaque composant apporté par un plugin va occuper une place sur votre plan de travail. Installer trop de plugins revient à encombrer votre contexte avec des descriptions de skills ou des définitions d'outils MCP avant même d'avoir commencé à travailler. Avant d'installer un plugin, vérifiez toujours cette estimation : quelques centaines de tokens ne posent pas de problème, mais à partir d'un millier, demandez-vous si vous en avez réellement besoin. Installer des tas de plugins inutiles qui encombrent le contexte pour rien est une erreur classique des débutants.

Autre détail important : après avoir installé un plugin, pensez à exécuter /reload-plugins pour qu'il prenne effet, sans avoir à redémarrer Claude Code. Pour charger, désactiver ou activer des plugins en cours de session, utilisez cette commande de rafraîchissement :

/reload-plugins

Une fois exécutée, elle vous indiquera le nombre de plugins, de skills, d'agents, de hooks, de serveurs MCP et LSP actuellement chargés.

💡 En résumé : les composants apportés par un plugin se divisent en deux catégories : ceux que « vous appelez activement » (skills/commandes) et ceux qui « agissent automatiquement » (hooks/MCP/LSP) ; vérifiez la liste de ce qui sera installé et le coût en contexte dans les détails avant l'installation, puis exécutez /reload-plugins pour activer le plugin.

Ce schéma regroupe les deux lignes directrices de cet article : à gauche, le processus en deux étapes « ajouter le marché → installer le plugin », et à droite, les cinq types de composants empaquetés dans la boîte d'un plugin (skill, subagent, hook, serveur MCP, serveur LSP), ainsi que leur fonctionnement (« appel actif » ou « action automatique ») après installation.

---

06 En pratique : ajouter un marché, installer un plugin et l'utiliser

Rien ne vaut la pratique. Voici comment ajouter un marché depuis les exemples officiels, installer un vrai plugin et exécuter les commandes qu'il apporte, le tout sans prérequis de configuration complexe ; vous n'avez qu'à suivre les étapes. Nous allons installer le plugin commit-commands — un plugin qui ajoute des skills à votre flux de travail Git.

Étape 1 : Lancer Claude Code et ajouter le marché de démonstration

Lancez Claude Code depuis n'importe quel répertoire :

claude

Saisissez ensuite dans la zone d'entrée (c'est la première des deux étapes — ajouter le marché) :

/plugin marketplace add anthropics/claude-code

Résultat attendu : Claude Code télécharge le catalogue de ce marché et confirme que le marché a bien été ajouté. Votre catalogue est désormais garni, mais vous n'avez encore installé aucun plugin.

Étape 2 : Ouvrir le gestionnaire de plugins pour explorer

Saisissez :

/plugin

Résultat attendu : Une interface s'ouvre avec quatre onglets — Discover / Installed / Marketplaces / Errors (Découvrir / Installés / Marchés / Erreurs) — dans laquelle vous pouvez naviguer avec la touche Tab (Shift+Tab pour revenir en arrière). Allez sur l'onglet Discover pour voir les exemples de plugins du marché que vous venez d'ajouter. Si vous voyez commit-commands dans la liste, c'est que le marché a été correctement ajouté.

Étape 3 : Installer le plugin commit-commands

Vous pouvez cliquer dessus dans l'interface pour choisir la portée de l'installation, ou l'installer directement en ligne de commande (c'est la deuxième étape) :

/plugin install commit-commands@claude-code-plugins

Notez que la partie après l'arobase @ est claude-code-plugins — c'est le nom interne de ce marché de démonstration (et non l'adresse du dépôt anthropics/claude-code que vous avez saisie pour l'ajouter). Lors de l'installation, il vous sera demandé de choisir la portée :

• Portée utilisateur (par défaut) : utilisable par vous-même sur l'ensemble de vos projets.
• Portée projet : enregistré dans .claude/settings.json, utilisable par tous les contributeurs du dépôt.
• Portée locale : utilisable uniquement par vous-même sur ce dépôt spécifique.

Choisissez la « portée utilisateur » par défaut pour commencer.

Résultat attendu : Le terminal confirme le succès de l'installation du plugin, et peut éventuellement lister les dépendances installées automatiquement avec lui.

Étape 4 : Activer le plugin et examiner les commandes apportées

/reload-plugins

Résultat attendu : Claude Code se recharge et affiche le nombre de plugins, skills, agents, hooks, ainsi que de serveurs MCP et LSP actuellement activés. Le skill de commit-commands disposant d'un espace de noms, il fournit une commande de la forme /commit-commands:commit.

Étape 5 : L'utiliser — voir le skill du plugin à l'œuvre

Modifiez d'abord un fichier dans votre répertoire actuel pour générer un changement (par exemple, en créant un fichier texte vide), puis saisissez :

/commit-commands:commit

Résultat attendu : Ce skill va vous aider à mettre vos modifications en index (stage), générer un message de commit et créer le commit. Le fait de voir ce processus Git se dérouler de bout en bout prouve que le plugin est non seulement installé, mais que le skill qu'il apporte est opérationnel — vous voilà équipé d'un flux de travail complet prêt à l'emploi.

⚠️ Si l'étape 5 indique que la commande /commit-commands:commit est introuvable, assurez-vous d'avoir bien exécuté /reload-plugins à l'étape 4 ; si le problème persiste, allez dans l'onglet « Errors » de /plugin pour voir les erreurs de chargement.

En effectuant ces cinq étapes, vous venez de valider l'ensemble de la chaîne « ajouter le marché → installer le plugin → activer → utiliser ». C'est la même procédure pour installer n'importe quel plugin.

💡 En résumé : ajouter le marché (marketplace add) → installer le plugin (install) → activer (/reload-plugins) → utiliser la commande avec espace de noms — exécuter le processus complet pour commit-commands est le meilleur moyen de le comprendre.

---

07 Créer votre propre package ? Comprendre d'abord la structure d'un plugin

Jusqu'ici, nous n'avons fait qu'utiliser les plugins des autres, mais vous aurez rapidement envie de créer vos propres packages de configuration. Cette section n'explique pas comment en concevoir un de A à Z (ce qui fera l'objet d'un autre article), mais vous présente la structure d'un répertoire de plugin afin que vous sachiez comment il est constitué.

Le cœur d'un plugin se compose de deux éléments : un fichier d'« identité » + les dossiers de composants.

Le fichier d'identité est .claude-plugin/plugin.json, qui déclare le nom, la description et la version du plugin :

{
  "name": "my-first-plugin",
  "description": "A greeting plugin to learn the basics",
  "version": "1.0.0"
}

La clé name y est essentielle — elle sert de préfixe pour l'espace de noms des skills. Les skills de ce plugin deviendront /my-first-plugin:xxx. La clé version est facultative, mais les utilisateurs ne recevront des notifications de mise à jour que si vous incrémentez ce numéro, pensez donc à le mettre à jour à chaque publication d'une nouvelle version.

Les dossiers de composants se placent à la racine du plugin, organisés par type. Voici la structure de répertoires recommandée par la documentation officielle :

Ce que vous voulez ajouter	Dossier de destination
skill	skills/<nom>/SKILL.md
subagent	agents/
hook	hooks/hooks.json
MCP server	Fichier .mcp.json à la racine
LSP server	Fichier .lsp.json à la racine

Un plugin complet ressemble à ceci :

my-first-plugin/
├── .claude-plugin/
│   └── plugin.json        ← Fichier d'identité, le seul placé ici
├── skills/
│   └── hello/
│       └── SKILL.md
├── agents/
│   └── reviewer.md
└── hooks/
    └── hooks.json

Voici un piège classique sur lequel la documentation insiste particulièrement :

Erreur fréquente : Ne placez pas les dossiers commands/, agents/, skills/ ou hooks/ à l'intérieur du dossier .claude-plugin/. Seul le fichier plugin.json doit s'y trouver. Tous les autres répertoires doivent se situer à la racine du plugin.

En clair : le dossier .claude-plugin/ ne doit contenir que le fichier plugin.json, tous les dossiers de composants devant se situer au niveau de la racine du plugin, à côté de .claude-plugin/. C'est un piège dans lequel je suis tombé lors de ma première création — j'avais placé par commodité le dossier skills/ dans .claude-plugin/. Le plugin s'est chargé sans erreur, /reload-plugins n'a rien signalé, mais le skill refusait d'apparaître. Après avoir vérifié le nom, la version et l'espace de noms dans le fichier plugin.json sans trouver d'erreur, j'ai fini par réaliser que le problème venait de l'emplacement du dossier. Dès que je l'ai déplacé à la racine, le skill est apparu immédiatement.

Vous remarquerez que cette arborescence est presque identique à la structure de projet .claude/ vue au 13e article, à celle des agents/ du 23e article et au .mcp.json du 22e article. Ce n'est pas un hasard — un plugin consiste précisément à « regrouper dans un dossier unique les configurations auparavant dispersées dans votre répertoire .claude/ ». C'est pourquoi la documentation officielle indique qu'il est facile de convertir des configurations en vrac en plugin, les formats étant identiques.

Pour tester un package que vous venez de créer localement, la documentation officielle propose une option bien pratique qui évite d'avoir à passer par un marché : spécifier le chemin du plugin local au démarrage avec --plugin-dir :

claude --plugin-dir ./my-first-plugin

Cette option est conçue pour le développement et les tests. After avoir modifié le plugin, il vous suffit de lancer /reload-plugins pour voir les changements, sans avoir à le publier sur un marché pour le réinstaller.

💡 En résumé : un plugin est constitué de .claude-plugin/plugin.json (identité, le name définit l'espace de noms) et de dossiers de composants situés à la racine ; retenez bien cette règle d'or : seul plugin.json va dans .claude-plugin/, tous les autres répertoires se placent à la racine.

---

08 Installer des plugins tiers : l'étape cruciale de la confiance

C'est la section la plus importante de cet article, et celle sur laquelle vous devez être particulièrement vigilant : un plugin n'est pas un simple outil inoffensif, il dispose des autorisations nécessaires pour exécuter du code arbitraire sur votre machine.

Rappelez-vous les limites de sécurité présentées au 21e article — ces principes s'appliquent tout autant, voire plus, aux plugins. La documentation officielle est très claire à ce sujet :

Les plugins et les marketplaces sont des composants hautement approuvés qui peuvent exécuter du code arbitraire sur votre machine avec vos privilèges d'utilisateur. N'installez des plugins et n'ajoutez des marketplaces qu'à partir de sources de confiance.

Qu'est-ce que cela implique ? Un plugin peut inclure un hook (qui exécute automatiquement des scripts), un serveur MCP (qui lance un programme en arrière-plan) ou des fichiers exécutables dans un dossier bin/. Lorsque vous l'installez et l'activez, ces programmes s'exécutent avec vos privilèges d'utilisateur — ils peuvent lire vos fichiers, se connecter à Internet et exécuter des commandes, avec le même niveau de privilèges que vous-même. Installer un plugin dont vous ne connaissez pas la provenance revient à exécuter un script inconnu directement sur votre machine.

Analogie : double-cliquer sur un fichier .exe téléchargé sur un site inconnu. Vous n'exécuteriez pas un programme inconnu sans réfléchir, car une fois lancé, ses privilèges sont identiques aux vôtres. Installer un plugin tiers est de même nature — la question de la confiance de la source est un prérequis indispensable avant toute installation.

Voici donc trois points de contrôle à vérifier systématiquement avant d'installer un plugin tiers :

Point de contrôle	Action
La source est-elle fiable ?	Donnez la priorité au marché officiel ; pour le marché de la communauté, vérifiez l'auteur et la page d'accueil ; évitez les dépôts personnels inconnus si vous avez un doute
Que contient le plugin ?	Avant d'installer, examinez dans les détails du plugin sur /plugin s'il contient des hooks, des MCP ou des exécutables
Quelle portée lui donner ?	En cas de doute, testez le plugin avec une « portée locale » plutôt que de l'installer en « portée utilisateur » sur l'ensemble de vos projets

Quelques choix de conception officiels permettent toutefois de limiter les risques : les plugins du marché de la communauté font l'objet d'une validation automatique et de contrôles de sécurité, et sont figés sur un commit Git spécifique (empêchant l'auteur de modifier le code en douce) ; le marché officiel est quant à lui rigoureusement sélectionné par Anthropic. Mais ces garde-fous ne remplacent pas votre propre vigilance — la règle reste de « n'installer qu'à partir de sources de confiance ».

Une bonne pratique consiste à installer les plugins du marché officiel les yeux fermés ; pour ceux de la communauté, vérifiez rapidement l'identité de l'auteur et les permissions requises ; quant aux plugins personnels de provenance inconnue, ne les installez pas à moins d'avoir lu et compris leur code source. Les plugins sont certes pratiques, mais la sécurité ne doit jamais être sacrifiée pour de la commodité — ne confondez pas simplicité d'installation et absence de danger.

💡 En résumé : un plugin s'exécute avec vos privilèges d'utilisateur pour lancer du code arbitraire ; installer un plugin tiers revient à exécuter un script externe sur votre machine. Vérifiez trois éléments : la fiabilité de la source, le contenu du package et la portée de l'installation. Privilégiez le marché officiel et méfiez-vous des sources inconnues.

---

09 Synthèse

Dans cet article, nous avons exploré le fonctionnement des plugins de Claude Code, de leur concept théorique à leur mise en œuvre pratique — ils consistent à regrouper les différents éléments configurés séparément dans un package unique facile à installer, à distribuer et à mettre à jour.

Synthèse des points clés à retenir :

Objectif	Outil	Point clé
Comprendre le rôle d'un plugin	Le plugin comme boîte d'intégration	Regroupe skill, subagent, hook, MCP et LSP ; préférez le vrac en local, et passez au plugin pour le partage
Obtenir des plugins tiers	Le marketplace	Processus en deux étapes : ajouter le marché avec marketplace add → installer avec install
Connaître les marchés	Les trois marchés officiels	Le marché officiel intégré est le plus stable, le marché de la communauté doit être ajouté, le marché de démonstration sert d'exemple
Activer les plugins	/reload-plugins	Commande pour charger les modifications sans redémarrer Claude Code
Inspecter le contenu	Les détails sur /plugin	Affiche la liste des composants installés et l'impact sur le contexte (Context Cost) avant d'installer
Créer son propre plugin	Fichier plugin.json et structure	Placer uniquement plugin.json dans le dossier .claude-plugin/, les autres répertoires allant à la racine
Gérer la sécurité	Analyse de confiance	Les plugins pouvant exécuter du code arbitraire, n'installez qu'à partir de sources fiables

Vous êtes désormais en mesure de : choisir entre plugin et configuration en vrac, installer et activer un plugin depuis un marché en suivant la procédure, inspecter son contenu et son coût en contexte dans l'interface, comprendre sa structure de dossiers et appliquer les règles de sécurité indispensables avant d'installer des extensions tierces. Grâce à cela, vous pouvez exploiter des flux de travail complets mis à disposition sur le marché sans avoir à les concevoir vous-même.

Des articles 18 à 24, nous avons fait le tour des extensions de Claude Code : CLAUDE.md, MCP, subagent, skill, hook, et enfin les plugins pour coordonner le tout. Votre boîte à outils est maintenant complète.

---

Le prochain article 25 « Système de mémoire (memory) » s'intéresse à un point parfois frustrant : à chaque nouvelle session, Claude redémarre de zéro, oubliant vos préférences ou les règles de votre projet. Nous verrons comment permettre à Claude de se souvenir de vous d'une session à l'autre — pour conserver en mémoire votre pile technologique ou les contraintes de votre projet sans avoir à les répéter. Quoi de plus agréable que de travailler avec un assistant qui connaît vos habitudes de travail comme un collaborateur de longue date ?

---

Lectures recommandées

• Voice Mode vocal : dicter ses instructions plutôt que de les saisir
• Agent teams Équipes d'agents : collaboration multi-sessions
• Gestion du contexte : éviter l'amnésie sans saturer les tokens