Quand une équipe adopte Claude Code, les outils s’accumulent vite : des MCP servers pour accéder aux APIs internes, des skills pour standardiser les revues de code, des agents spécialisés par domaine. Chaque développeur·se les configure manuellement, souvent en se basant sur un message Slack ou un README qui date un peu. Pas de source de vérité, pas de mise à jour automatique.
Claude Code dispose depuis peu d’un mécanisme natif pour régler ce problème : les Plugin Marketplaces. Le principe : un repo GitHub devient un catalogue de plugins que toute l’équipe peut installer en une commande, et que le projet peut activer automatiquement via son settings.json.
Ce que c’est concrètement
Un marketplace Claude Code, c’est un repo Git qui contient un fichier .claude-plugin/marketplace.json. Ce fichier liste des plugins, chacun pouvant embarquer des skills, des agents, des hooks ou des MCP servers. Les développeur·se·s s’abonnent au marketplace via /plugin marketplace add, puis installent les plugins qui les intéressent.
Pas de serveur à héberger, pas d’authentification spécifique à configurer : Claude Code réutilise vos credentials git existants. Pour les repos privés, c’est transparent dès lors que gh auth login a été fait.
Créer le repo
La structure minimale ressemble à ceci :
your-org/claude-plugins/
├── .claude-plugin/
│ └── marketplace.json
└── plugins/
└── mon-outil/
├── .claude-plugin/
│ └── plugin.json
└── skills/
└── mon-skill/
└── SKILL.md
Le repo anthropics/skills est un bon exemple concret à parcourir : c’est le marketplace officiel Anthropic, qui suit exactement cette structure et peut servir de référence pour démarrer.
Le marketplace.json référence les plugins disponibles dans le catalogue :
{
"name": "liksi-tools",
"owner": { "name": "Liksi" },
"description": "Plugins internes Liksi pour Claude Code",
"plugins": [
{
"name": "mon-outil",
"source": "./plugins/mon-outil",
"description": "Skill de revue de code orienté craftsmanship",
"version": "1.0.0"
}
]
}
Le champ source accepte un chemin relatif dans le repo, ou une référence vers un autre repo GitHub (pratique pour des plugins maintenus séparément).
Chaque plugin dispose de son propre plugin.json :
{
"name": "mon-outil",
"description": "Skill de revue de code orienté craftsmanship",
"version": "1.0.0"
}
Inclure un MCP server dans un plugin
Au-delà des skills, un plugin peut embarquer un MCP server. C’est ce qui permet de distribuer des outils d’accès aux APIs internes sans que chaque développeur·se ait à configurer manuellement la connexion.
Dans l’entrée du plugin dans marketplace.json :
{
"name": "mon-outil",
"source": "./plugins/mon-outil",
"mcpServers": {
"internal-api": {
"command": "${CLAUDE_PLUGIN_ROOT}/servers/internal-api-server",
"args": ["--config", "${CLAUDE_PLUGIN_ROOT}/config.json"]
}
}
}
La variable ${CLAUDE_PLUGIN_ROOT} pointe vers le répertoire d’installation du plugin sur la machine de l’utilisateur·ice. Le server binary ou script est donc distribué avec le plugin, versionné dans le repo.
Abonnement et installation côté développeur·se
Une fois le repo créé et poussé, s’y abonner prend une commande :
/plugin marketplace add your-org/claude-plugins
Puis on installe un plugin depuis le marketplace :
/plugin install code-review@liksi-tools
Claude Code demande à quel scope installer le plugin : utilisateur (toutes vos sessions), projet (tous les collaborateurs du repo via son settings.json), ou local (ce repo uniquement sur votre machine). Pour un usage personnel, le scope utilisateur suffit. Pour imposer l’outillage à toute l’équipe sur un projet, le settings.json commité est préférable : il ne dépend pas d’une action manuelle de chaque développeur·se.
Et /plugin list, onglet Marketplaces, confirme que le marketplace est bien référencé :
Activer les plugins automatiquement pour tout le projet
Pour éviter que chaque développeur·se ait à refaire ces étapes sur chaque machine, on peut committer un .claude/settings.json à la racine du projet. Les plugins sont alors connus et activés dès l’ouverture de Claude Code dans ce repo :
{
"extraKnownMarketplaces": {
"liksi-tools": {
"source": {
"source": "github",
"repo": "your-org/claude-plugins"
}
}
},
"enabledPlugins": {
"mon-outil@liksi-tools": true
}
}
Au prochain lancement, Claude Code détecte le marketplace, synchronise le catalogue, et active le plugin. Pas de configuration manuelle.
Un levier pour la plateforme interne
Pour une équipe platform engineering, ce mécanisme répond à une question concrète : comment distribuer un outillage IA cohérent à toutes les équipes produit sans que chacune reinvente sa configuration. Le marketplace privé joue le même rôle qu’un registre interne de bibliothèques ou qu’un catalogue de templates : il définit ce qui est disponible, vérifié, supporté.
On peut ainsi distribuer des connexions aux APIs internes (MCP servers), des pratiques de revue standardisées (skills), ou des agents spécialisés par domaine métier, sans que les équipes consommatrices aient à comprendre les détails de configuration. Un settings.json commité dans le repo de chaque projet suffit à activer l’outillage ; les équipes récupèrent les mises à jour au prochain update, sans friction.
Le mode strictKnownMarketplaces, disponible dans les settings managés, permet de restreindre les sources autorisées à une liste approuvée. Les développeur·se·s peuvent toujours installer des plugins, mais uniquement depuis des marketplaces validées par l’équipe platform, sur le même principe qu’un registre de packages avec allowlist.
Un point à ne pas ignorer : Claude Code ne propose pas de mécanisme de signature ou de checksum pour vérifier l’intégrité des plugins installés. La chaîne de confiance repose entièrement sur le contrôle d’accès au repo GitHub. En pratique, cela signifie que les mêmes protections que pour n’importe quel code interne s’appliquent : branch protection sur main, revue obligatoire des pull requests avant merge, et audit des modifications sur les fichiers plugin.json et marketplace.json. Pour les plugins qui embarquent un MCP server (binaire ou script exécuté localement), une revue de code systématique avant toute mise à jour est indispensable : ce qui est installé s’exécute sur les machines des développeur·se·s avec leurs credentials.
Gérer les versions
Deux modes de fonctionnement sont possibles. Avec "version" dans plugin.json et marketplace.json, le plugin est pincé à cette version ; pour publier une mise à jour, on bumpe le champ et on pousse. Sans "version", chaque commit dans le repo compte comme une nouvelle version et Claude Code s’aligne sur le dernier état du repo, ce qui est plus simple à opérer pour des plugins internes qui évoluent fréquemment.
Pour mettre à jour :
/plugin marketplace update liksi-tools
Pour aller plus loin
Ce qui est décrit ici couvre le cas d’usage dev, mais le mécanisme n’est pas limité aux équipes techniques. Un plugin peut embarquer des skills orientés métier : générer des specs à partir d’une user story, produire un plan de test depuis une description fonctionnelle, dépouiller un retour utilisateur. Un PO ou un QA qui dispose de Claude Code peut bénéficier exactement du même catalogue distribué, mis à jour au même rythme, sans rien installer manuellement.
À l’échelle d’une entreprise, ça change la nature de l’outil : le marketplace privé devient une couche de distribution commune pour toutes les équipes, pas seulement les développeur·se·s. On publie un plugin, et tout le monde (dev, QA, PO, PM) le retrouve dans son catalogue sans friction.
L’étape suivante, c’est de poser une interface au-dessus du repo. Le marketplace.json est lisible par n’importe quelle application : on peut construire un portail interne qui liste les plugins disponibles, affiche leur description, leur auteur·ice, leurs dernières mises à jour. Les équipes n’ont plus à parcourir un README pour savoir ce qui existe ; elles explorent un catalogue, filtrent par rôle ou domaine, et installent en un clic. Le repo Git reste la source de vérité, l’UI n’est qu’une vitrine par-dessus. C’est par exemple l’approche qu’a décrite Doctolib au Devoxx 2026 : un portail interne construit sur ce mécanisme, permettant à n’importe quelle équipe de publier et découvrir des plugins à l’échelle de l’entreprise (L’Agentic Coding, nouveau territoire du Platform Engineering).
Un format propriétaire dans un écosystème qui se cherche
Tout ce qui est décrit ici est 100% Claude Code. Le format marketplace.json, la commande /plugin, le champ enabledPlugins dans settings.json : rien de tout ça n’est portable vers un autre outil d’agentic coding. Si demain votre équipe décide de tester Cursor, Copilot Workspace ou un autre concurrent, vos plugins restent dans le tiroir.
C’est un choix assumé d’Anthropic : construire une expérience intégrée et cohérente plutôt que de viser l’interopérabilité. Le résultat est bien pensé, mais il crée une dépendance forte à l’éditeur.
D’autres outils essaient une approche différente. OpenCode a été conçu avec une philosophie “Bring Your Own Model” dès le départ : les plugins sont des fichiers JS/TS ou Markdown dans .opencode/plugins/, et un projet communautaire permet d’installer des skills et agents depuis des URLs GitHub. C’est moins intégré, mais agnostique vis-à-vis du modèle sous-jacent.
Des discussions sont en cours sur GitHub autour de la standardisation du format marketplace.json lui-même (l’idée étant qu’un plugin publié une fois soit consommable indifféremment par Claude Code et OpenCode). On n’y est pas encore, et ces efforts restent communautaires, sans engagement des éditeurs. La question commence à se poser : à mesure que l’outillage IA s’installe dans les équipes, le coût du lock-in ressemble de plus en plus à celui d’un choix de framework, difficile à anticiper et difficile à défaire.
Pour l’instant, si votre équipe est déjà all-in Claude Code, le mécanisme décrit ici est le meilleur levier disponible. Mais ça vaut la peine d’en être conscient avant d’investir dans un catalogue de plugins sur mesure.
Ressources
- Claude Code — Plugin Marketplaces : https://code.claude.com/docs/en/plugin-marketplaces
- Claude Code — Create plugins : https://code.claude.com/docs/en/plugins
- Claude Code — Plugin reference : https://code.claude.com/docs/en/plugins-reference
- anthropics/skills — marketplace officiel Anthropic (exemple de référence) : https://github.com/anthropics/skills
- Doctolib - L’Agentic Coding, nouveau territoire du Platform Engineering (Devoxx 2026) : https://youtu.be/NLg8As47Y84?list=PLTbQvx84FrATeh9140x3_O0hAwGGgEI8q
- OpenCode : https://opencode.ai
- OpenCode — Plugin system (GitHub) : https://github.com/sst/opencode
