Le 24 février 2026, Anthropic a annoncé les marketplaces de plugins privés pour Claude Code, donnant aux admins un moyen de construire, héberger et contrôler les plugins sans toucher aux registres publics d'Anthropic. Ce que vous obtenez de cet article : les étapes exactes pour bundler une compétence et l'intégrer à un plugin distribuable, l'héberger dans un repo GitHub privé, épingler les versions, et diagnostiquer les pannes les plus courantes quand une deuxième machine refuse de s'installer proprement.
Quand une équipe a besoin d'un plugin
La marketplace publique convient pour l'expérimentation individuelle. Une fois que plus d'une personne s'appuie sur la même commande slash ou le même script hook, la distribution ad hoc s'effondre rapidement. Quelqu'un copie un fichier manuellement, utilise un chemin légèrement différent, et Claude Code ignore silencieusement le hook parce que le nom ne correspond pas à ce que le registre attend.
C'est le vrai déclencheur d'une marketplace privée : la cohérence sur les machines, pas le nombre de personnes. Si vous avez deux développeurs et que les deux ont besoin du même hook de déploiement, une marketplace privée vaut l'heure de configuration. Si vous en avez vingt, ce n'est pas optionnel.
L'autre déclencheur est la confidentialité. La documentation de création de plugins d'Anthropic est explicite : pour garder un plugin interne à votre équipe, vous hébergez la marketplace dans un repository privé. Soumettre à claude-community publie votre plugin pour que n'importe qui le voie et l'installe. Un repo privé évite tout cela. Si votre plugin contient des patterns API internes, des commandes slash propriétaires, ou quoi que ce soit que vous préféreriez ne pas indexer, la route privée est la bonne.
À noter : si votre équipe exécute déjà des serveurs MCP en production, vérifiez comment la distribution de plugins privés s'intègre dans cette pile avant de vous engager dans une structure, puisque les deux approches ont des cas d'usage qui se chevauchent mais sont distincts.
Bundler une compétence et un hook existants
Un plugin est un dossier. C'est le résumé honnête. Selon la documentation officielle des plugins, la structure minimale viable ressemble à ceci :
my-plugin/
plugin.json
README.md
skills/
my-skill.md
hooks/
hooks.json
guard.sh
Le plugin.json est le manifeste. Il nomme le plugin, déclare une version, et pointe vers les sous-répertoires skills et hooks. Un exemple illustratif épuré :
{
"name": "deployment-tools",
"version": "1.2.0",
"description": "Deployment workflow helpers for the platform team",
"skills": ["skills/"],
"hooks": "hooks/hooks.json"
}
Les compétences sont des fichiers markdown qui définissent ce que Claude sait faire, et les commandes slash vivent à l'intérieur. Les hooks sont des déclarations JSON qui câblent des scripts shell à des points de déclenchement (avant un appel d'outil, après une session, et ainsi de suite). Vous pouvez bundler n'importe quelle combinaison des deux dans un seul dossier de plugin. La documentation des compétences note que les commandes personnalisées font maintenant partie du modèle de compétences, donc n'essayez pas de les maintenir comme un système parallèle séparé.
Une chose qui trompe les gens : les scripts hook doivent être exécutables. Exécutez chmod +x hooks/guard.sh avant de commiter. Claude Code vérifie le bit de permission et ignorera silencieusement un hook s'il n'est pas défini.
Créer et distribuer une marketplace privée
Une marketplace est un repository GitHub avec une structure de dossier spécifique. Chaque plugin vit dans son propre sous-répertoire. À la racine du repo vous avez besoin d'un registry.json qui catalogue ce qui est disponible. La documentation de la marketplace de plugins décrit cette structure en détail, et la démo communautaire à mrlm-xyz/demo-claude-marketplace montre deux exemples de plugins qui fonctionnent avec des agents, des commandes et des compétences si vous voulez une référence concrète avant de construire à partir de zéro.
Une fois le dépôt créé, informez Claude Code à partir de .claude/settings.json à la racine du dépôt :
{
"extraKnownMarketplaces": {
"company-tools": {
"source": {
"source": "github",
"repo": "your-org/claude-plugins"
}
}
},
"enabledPlugins": {
"deployment-tools@company-tools": true,
"code-formatter@company-tools": true
}
}
Validez ce fichier. Désormais, chaque membre de l'équipe qui approuve le dossier du projet obtient la place de marché ajoutée automatiquement, sans invite supplémentaire ni étape CLI manuelle. Le bloc enabledPlugins signifie que ces deux plugins sont actifs par défaut. Quiconque ne les souhaite pas peut les désactiver localement ; les valeurs par défaut réduisent simplement les frictions pour tous les autres.
Si vous êtes sur un plan Team ou Enterprise et distribuez via les paramètres d'organisation, le dépôt de la place de marché doit être privé ou interne. L'application Claude GitHub le lit, vous devrez donc lui accorder l'accès explicitement. Un dépôt public échoue silencieusement dans ce chemin, ce qui est l'un des modes d'erreur les plus déroutants.
Pour les équipes gérant des travaux Claude Code côté client à grande échelle, les services d'agence Claude Code de Seahawk gèrent la configuration de la place de marché et la gouvernance des plugins en continu si vous préférez ne pas gérer cette infrastructure vous-même.
Contrôlez les versions et passez en revue les mises à jour
C'est là que la plupart des places de marché privées se trompent. Les gens épinglent une version dans plugin.json, poussent un changement cassant sous le même tag, et se demandent pourquoi la restauration n'a pas fonctionné. Les tags Git sont la bonne unité de vérité de version ici, pas seulement la chaîne de version dans le manifeste.
Le flux de travail qui tient vraiment :
- Augmentez le champ
versiondansplugin.json(suivez semver :1.2.0à1.3.0pour les ajouts rétro-compatibles,2.0.0pour les changements cassants). - Validez et poussez.
- Créez un tag git :
git tag v1.3.0 && git push origin v1.3.0. - Mettez à jour
registry.jsonpour pointer l'entrée du plugin vers le nouveau tag.
Pour installer une version spécifique sur une machine :
/plugin install deployment-tools@company-tools --version 1.3.0
Pour restaurer le tag précédent :
/plugin install deployment-tools@company-tools --version 1.2.0
Le flag --version se résout par rapport aux tags git dans le dépôt source. Si vous n'avez pas tagué, Claude Code revient à HEAD de la branche par défaut, ce qui signifie que « restauration » n'a aucun sens. Tachez chaque publication. Cela prend dix secondes et évite de vrais problèmes.
Pour l'examen des mises à jour, traitez le dépôt de la place de marché comme n'importe quel autre codebase de production : exigez une demande de fusion, au minimum une approbation, et une entrée de journal des modifications dans README.md avant de fusionner vers main. La documentation d'Anthropic elle-même note que les plugins sont des composants hautement fiables qui peuvent exécuter du code arbitraire, donc une politique où une seule personne peut fusionner sur un dépôt de plugin est une mauvaise idée quelle que soit la taille de l'équipe.
Testez l'installation sur une deuxième machine
Avant de dire à l'équipe élargie de récupérer le nouveau plugin, installez-le sur un profil complètement nouveau. Pas une autre fenêtre de terminal. Un profil nouveau sans secrets intégrés, sans état de plugin existant, et sans entrées de place de marché pré-configurées au-delà de ce qui se trouve dans le settings.json du dépôt.
Liste de contrôle numérotée pour un test de deuxième machine propre :
- Clonez le dépôt du projet.
- Ouvrez Claude Code et approuvez le dossier quand vous y êtes invité.
- Confirmez que la place de marché apparaît avec
/plugin marketplace list. - Installez le plugin explicitement :
/plugin install deployment-tools@company-tools. - Exécutez la commande slash que le plugin expose et vérifiez qu'elle retourne le résultat attendu.
- Vérifiez que le hook se déclenche en appelant l'outil pertinent et en inspectant le résultat.
- Vérifiez qu'aucune donnée d'identification ou chemin local de votre machine de développement n'apparaît dans la réponse.
Cette dernière vérification est importante. Les scripts de hook qui référencent des chemins absolus (/Users/yourname/scripts/...) se cassent sur toute autre machine. Utilisez des chemins relatifs au répertoire du plugin ou des variables d'environnement que les équipes peuvent définir de manière cohérente.
Dépannez les noms, chemins et dépendances
La plupart des échecs d'installation sont l'une de trois choses.
Décalages de noms. Le nom du plugin dans plugin.json doit correspondre exactement au nom du répertoire dans le dépôt du marketplace et au nom utilisé dans registry.json. Sensible à la casse. Si plugin.json dit deployment-tools et l'entrée du registre dit Deployment-Tools, la commande d'installation retourne une erreur not-found qui semble sans rapport avec la casse.
Problèmes de chemins dans les hooks. Comme mentionné ci-dessus, les chemins absolus sont la source principale des bogues « ça marche sur ma machine ». Auditez chaque script de hook pour les chemins codés en dur avant de taguer une version. Un simple grep -r "/Users" hooks/ détecte le plus courant.
Lacunes de dépendances. Si votre script de hook appelle un binaire externe (jq, gh, docker, un CLI interne personnalisé), documentez cette dépendance dans README.md avec la version minimale. Claude Code ne résout pas les dépendances de binaires externes pour vous. Un hook qui se termine silencieusement parce que jq n'est pas installé est difficile à diagnostiquer, notamment pour un coéquipier qui ne sait pas que le hook existe.
Quelques autres points à vérifier si l'installation s'immobilise :
- L'application GitHub a besoin d'un accès en lecture au dépôt du marketplace privé. Vérifiez les paramètres de l'organisation si la récupération s'immobilise.
- Si
extraKnownMarketplacesest danssettings.jsonmais que le marketplace n'apparaît pas après avoir approuvé le dossier, confirmez que le fichier est commité et que l'invite de confiance a été acceptée, non ignorée. - Les noms de plugins dans
enabledPluginsdoivent utiliser le formatname@marketplaceexactement.deployment-toolsseul ne se résoudra pas sans le qualificateur de marketplace.
La série dev.to de Nagell couvre la gestion automatique des versions et la publication CI plus en détail si vous voulez intégrer GitHub Actions dans le workflow de tagging. Vaut le coup d'être lue avant de construire l'étape CI manuellement.
Pour un contexte plus large sur la façon dont Claude Code s'intègre dans un vrai workflow de développement au-delà des plugins seuls, cet aperçu des superpuissances de Claude Code est un complément utile.
FAQ
Puis-je héberger le marketplace ailleurs que sur GitHub ?
Le champ source dans settings.json supporte github et local comme types de source selon la documentation actuelle du plugin marketplace. Un chemin local fonctionne pour une seule machine ou un partage réseau monté, mais il ne se met pas à jour automatiquement comme le ferait une source adossée à git. Pour la distribution en équipe avec suivi des versions, un dépôt GitHub privé est le choix pratique en ce moment.
Les membres de l'équipe ont-ils besoin de leur propre accès GitHub au dépôt du marketplace privé ?
Pas directement. Si vous distribuez via les paramètres de l'organisation sur un forfait Team ou Enterprise, l'application GitHub Claude lit le dépôt en leur nom. Si vous utilisez extraKnownMarketplaces dans settings.json sans le chemin de synchronisation org, chaque utilisateur a besoin d'un accès en lecture au dépôt via ses propres identifiants GitHub ou une clé de déploiement.
Quelle est la différence entre enabledPlugins et l'installation effective d'un plugin ?
enabledPlugins dans settings.json active les plugins automatiquement quand le dossier du projet est approuvé. C'est un défaut, pas une installation forcée. Un utilisateur peut toujours désactiver un plugin localement. L'installation manuelle via /plugin install ajoute le plugin quel que soit ce que dit settings.json. Les deux mécanismes fonctionnent ensemble : les défauts pour la commodité, l'installation manuelle pour tout ce qui sort du contexte du projet.
Puis-je avoir plusieurs marketplaces privés dans une organisation ?
Oui. L'objet extraKnownMarketplaces accepte plusieurs clés. Chaque clé est un alias de marketplace local, et chacun pointe vers un dépôt source séparé. Vous pourriez avoir company-tools, data-team-plugins et security-tools tous enregistrés dans le même settings.json. Assurez-vous simplement que les alias sont uniques et ne rentrent pas en collision avec claude-plugins-official ou claude-community.
Comment cela interagit-il avec la marketplace officielle d'Anthropic ?
Ils coexistent. Claude Code enregistre claude-plugins-official automatiquement au premier lancement interactif. Votre marketplace privée s'ajoute à côté. Les plugins de votre marketplace privée sont référencés comme plugin-name@your-alias ; les plugins officiels comme plugin-name@claude-plugins-official. Pas de conflit, tant que vos noms de plugins ne dupliquent pas les noms officiels et ne créent pas d'ambiguïté de résolution.
La mise en garde la plus importante de tout cela : les tags git sont le seul mécanisme fiable de restauration. Une chaîne de version dans plugin.json sans tag correspondant n'est que de la décoration, pas une option de récupération.