Claude Code plugins : l’app store d’Anthropic

Claude Code plugins n’est pas juste une annonce de plus. C’est le moment où Claude Code passe d’un outil qu’on configure à la main à une plateforme qu’on distribue.

Et ça change tout.

En une journée, le dépôt officiel anthropics/claude-plugins-official a pris une traction énorme sur GitHub : 23 146 étoiles au total, 682 étoiles en une seule journée, et des dizaines de plugins déjà rangés dans un catalogue géré par Anthropic. On n’est plus dans le bricolage de .claude/ pour ton repo perso. On est en train de voir apparaître un vrai modèle de distribution.

Claude Code plugins : ce qui change vraiment

La nouveauté, ce n’est pas “Claude peut maintenant faire des trucs en plus”. Claude Code sait déjà s’étendre via des commandes, des agents, des hooks et MCP. La nouveauté, c’est l’emballage : Anthropic a transformé ces briques en plugins installables, partageables et versionnables.

Dans son annonce, Anthropic résume ça simplement : un plugin est une collection de slash commands, agents, MCP servers et hooks qui s’installe en une seule commande. La doc officielle Create plugins va dans le même sens : les plugins servent à étendre Claude Code avec des skills, des agents, des hooks et des serveurs MCP, et la marketplace officielle est disponible par défaut quand tu lances Claude Code.

Autrement dit, Claude Code ne devient pas seulement plus puissant. Il devient distribuable.

C’est un vrai changement de paradigme. Avant, tu pouvais personnaliser ton environnement pour toi. Maintenant, tu peux empaqueter un workflow et le faire circuler dans une équipe, puis dans une communauté.

Le repo officiel le montre bien : il est découpé en 36 plugins internes et 15 plugins externes au moment où j’écris ces lignes. Ce n’est pas encore une boutique géante. Mais c’est déjà un écosystème.

À lire aussi : CLAUDE.md vs AGENTS.md : que choisir pour ton repo IA ? et Design.md pour Claude Code : générer une UI cohérente

Comment fonctionne la marketplace de Claude Code

Le modèle est volontairement simple.

D’abord, tu ajoutes une marketplace. Ensuite, tu installes les plugins que tu veux. C’est le même réflexe qu’un app store : tu ajoutes la source, puis tu pioches dedans.

La doc officielle décrit deux couches :

Couche	Ce que tu fais	Ce que ça t’apporte
Standalone `.claude/`	tu ajustes ton repo à la main	rapide, personnel, idéal pour tester
Plugin	tu empaquettes ton workflow	réutilisable, versionné, partageable
Marketplace	tu ajoutes un catalogue de plugins	découverte, distribution, mise à jour

La différence est importante. Avec .claude/, tu restes dans l’optique “ce repo, pour moi”. Avec un plugin, tu passes à “ce workflow, pour plusieurs projets”. Et avec une marketplace, tu passes à “ce workflow, pour plusieurs équipes”.

La marketplace officielle d’Anthropic est déjà disponible dans Claude Code. La doc Discover and install prebuilt plugins indique que tu peux l’explorer via /plugin, onglet Discover, ou installer un plugin directement avec une commande du type :

/plugin install github@claude-plugins-official

Le même système prend aussi en charge des marketplaces communautaires. Là, on commence à toucher au vrai sujet : Claude Code ne vend pas seulement une feature. Il met en place une distribution layer.

Et cette couche n’est pas abstraite. La doc Create plugins explique comment structurer un plugin :

un manifeste .claude-plugin/plugin.json
des commands/
des agents/
des skills/
des hooks/
et, selon les cas, des serveurs MCP

En pratique, ça veut dire qu’un plugin peut embarquer un vrai petit système, pas juste une commande isolée.

Pourquoi ce n’est pas juste un catalogue de plugins

Si tu regardes vite, tu peux croire qu’Anthropic a simplement ajouté une page “plugins”. Ce serait passer à côté du vrai changement.

Le point clé, c’est que Claude Code passe d’un outil configurable à un outil gouverné par des conventions de distribution.

Et ça change trois choses.

1) Le workflow devient portable

Le même setup peut vivre dans plusieurs repos, être versionné, puis être partagé. Tu n’as plus besoin de recopier les mêmes instructions partout.

2) Le coût devient lisible

Dans la doc week 19 / week 20 de Claude Code, Anthropic explique que claude plugin details <name> affiche l’inventaire des composants d’un plugin et même un coût token projeté par session. Ce détail n’a l’air de rien, mais il dit beaucoup : Anthropic traite déjà les plugins comme des objets qu’on doit mesurer, pas juste activer.

3) La confiance devient une vraie question produit

Un plugin, ce n’est pas un bouton magique. C’est du code, des fichiers, des commandes, parfois des serveurs MCP. Donc la discussion n’est pas seulement “qu’est-ce que ça fait ?”, mais aussi “qui le maintient ?”, “qui le valide ?”, “peut-il changer sans prévenir ?”.

C’est exactement là que Claude Code commence à ressembler à une vraie plateforme.

Le meilleur signal, ce n’est pas la feature elle-même. C’est le fait qu’on commence déjà à parler de catalogue, de marketplace, de curation, de mise à jour et de gouvernance.

Ce que tu peux installer aujourd’hui avec Claude Code plugins

Le dépôt officiel n’est pas un fourre-tout. Il est classé par usages très concrets.

La doc de marketplace officielle distingue quatre grandes familles :

Code intelligence : pour brancher des serveurs LSP et améliorer les jumps, les références et les erreurs de type
External integrations : pour connecter des outils comme GitHub, Linear, Discord, Telegram, etc.
Development workflows : pour automatiser la revue, les commits, la modernisation de code ou le setup
Output styles : pour changer la manière dont Claude répond ou explique

Le repo officiel confirme cette direction. On y trouve par exemple des plugins comme :

code-review
code-simplifier
claude-code-setup
frontend-design
commit-commands
github
linear
playwright
telegram
et plusieurs plugins LSP comme pyright-lsp, gopls-lsp, csharp-lsp, jdtls-lsp

On n’est donc pas seulement dans “un plugin pour faire une blague”. On est dans des plugins qui attaquent directement les tâches répétitives du quotidien dev.

Le plus intéressant, c’est la cohérence entre le catalogue et l’usage réel. Les plugins qui remontent aujourd’hui sont très proches des besoins les plus fréquents : relire du code, moderniser un module, connecter un outil externe, ou donner à Claude une meilleure compréhension du projet.

Et ça se voit aussi dans la traction. Le dépôt officiel est à 23k+ étoiles et a pris 682 étoiles en une journée. Sur Hacker News, le post Customize Claude Code with plugins a déjà récolté 48 points et la discussion tourne précisément autour de la distribution, des marketplaces et des soucis de clonage/synchronisation. Ce n’est pas un coin de niche silencieux.

Le vrai sujet : confiance, sécurité et gouvernance

C’est ici que l’histoire devient intéressante.

Anthropic est très clair dans son README officiel : il faut faire confiance à un plugin avant de l’installer. Le message est explicite : Anthropic ne contrôle pas ce qu’un plugin embarque, ne peut pas vérifier qu’il ne changera pas, et renvoie vers la homepage de chaque plugin pour les détails.

La doc Discover and install prebuilt plugins le dit autrement : la marketplace officielle est curated by Anthropic, mais les plugins restent des artefacts à installer. Et la marketplace communautaire est encore un autre niveau de confiance.

Ça veut dire quoi concrètement ?

Que le modèle de menace change.

Avant, ton risque principal était souvent une mauvaise config locale. Maintenant, tu as aussi :

un plugin qui importe trop de choses
un serveur MCP trop large
une commande slash qui fait plus que prévu
une marketplace qui évolue au fil des commits
et la possibilité de multiplier les extensions sans vraiment voir l’impact global

La bonne nouvelle, c’est qu’Anthropic a déjà posé des garde-fous. La mauvaise, c’est que le problème ne disparaît pas parce qu’il est bien documenté.

Le sujet n’est donc pas “plugins oui/non”. Le sujet est : quel niveau de confiance tu autorises dans ton équipe, et comment tu le formalises.

Si tu travailles dans une équipe produit ou une boîte, ça change la conversation. Tu ne déploies pas un plugin comme tu copies un fichier. Tu décides si ce plugin mérite d’entrer dans un périmètre de confiance.

Et ça, pour une équipe dev, c’est souvent plus important que la feature elle-même.

Ce que ça change pour ton équipe si tu utilises Claude Code

Si tu utilises déjà Claude Code, la bonne stratégie n’est pas de tout installer.

La bonne stratégie, c’est d’identifier les workflows récurrents qui méritent un packaging.

Par exemple :

Le setup
- un plugin pour initialiser ton repo
- des commandes qui standardisent les premières minutes de travail
La revue de code
- un plugin qui impose un format de review
- des hooks qui verrouillent certains comportements
Les intégrations
- GitHub, Linear, Discord, Telegram
- tout ce qui évite de sortir du flux
Le contexte métier
- un plugin pour le design, un autre pour la modernisation de code
- des règles qui gardent la même ligne éditoriale ou visuelle

Si tu veux partir proprement, voici la bonne progression :

commence en local avec .claude/
isole ce qui revient tout le temps
transforme ce morceau en plugin
garde le manifeste court
documente clairement ce que le plugin touche
et n’ajoute une marketplace d’équipe que si tu as vraiment besoin de distribuer le tout

En clair : ne transforme pas chaque idée en plugin. Transforme en plugin ce qui mérite d’être maintenu.

C’est exactement le genre d’approche qu’on retrouve dans les articles sur CLAUDE.md et sur MCP : le bon design n’est pas d’empiler les couches, c’est de séparer les responsabilités.

Ce qu’il faut retenir avant de cliquer sur /plugin install

Claude Code plugins, ce n’est pas juste une nouveauté produit.

C’est le passage de l’outil perso au système partageable.

Et c’est ça qui rend le sujet chaud : pas seulement parce qu’Anthropic a sorti une marketplace, mais parce que la marketplace change la façon dont les équipes vont empaqueter, distribuer et faire évoluer leurs workflows IA.

Les 5 signaux à retenir

Claude Code devient une plateforme extensible, pas seulement un terminal IA.
La marketplace officielle est déjà là et elle est disponible dès le lancement.
Le catalogue est structuré autour d’usages concrets : code intelligence, intégrations, workflows, styles.
La confiance devient centrale : plugins, MCP et fichiers peuvent changer ton périmètre de sécurité.
Le vrai gain est organisationnel : partager un workflow propre vaut souvent plus qu’ajouter un plugin de plus.

Questions fréquentes sur Claude Code plugins

Claude Code plugins ou `.claude/` : je commence par quoi ?

Commence par .claude/ si tu veux tester vite et rester dans un seul repo. Passe au plugin quand le workflow doit vivre dans plusieurs projets ou être partagé à une équipe.

Est-ce que la marketplace officielle suffit ?

Pour démarrer, oui. Elle est curatée par Anthropic et elle couvre déjà des cas très utiles. Mais dès que tu parles de sécurité, de gouvernance ou d’équipe, il faut regarder qui publie quoi et avec quel niveau de confiance.

Est-ce que c’est dangereux d’installer un plugin ?

Pas automatiquement. Mais ce n’est pas neutre. Un plugin peut embarquer des fichiers, des commandes, des hooks ou des serveurs MCP. Donc il faut le traiter comme un composant logiciel, pas comme un simple preset.

Est-ce que les plugins remplacent les skills ou les MCP servers ?

Non. Ils les emballent et les distribuent mieux. Le plugin est le conteneur, pas la brique unique.

Ce qu’il faut retenir :

Claude Code plugins marque le passage d’un outil configurable à une plateforme distribuable.
La vraie nouveauté, ce n’est pas le plugin lui-même, c’est la marketplace et le modèle de confiance qui va avec.
Si tu utilises Claude Code en équipe, le bon réflexe est de packager les workflows récurrents, pas de multiplier les extensions.