Auditer les plugins Claude Code avant d’installer la marketplace officielle

La marketplace officielle de plugins Claude Code d’Anthropic n’est plus une rumeur planquée au fond de dossiers de config. Le dépôt GitHub public, anthropics/claude-plugins-official, compte plus de 30 000 étoiles au 17 juin 2026, et son README décrit un annuaire sélectionné, avec des plugins internes Anthropic et des entrées tierces. Ce même README contient aussi la phrase qui devrait dicter votre posture : « Assurez-vous de faire confiance à un plugin avant de l’installer, de le mettre à jour ou de l’utiliser », parce qu’Anthropic ne contrôle pas chaque serveur MCP, fichier ou autre dépendance embarquée dans ces plugins (GitHub).

Cet avertissement n’est pas du jargon juridique. Un plugin Claude Code peut embarquer des commandes slash, des skills, des agents, des hooks, des serveurs MCP, des serveurs LSP, des exécutables et des paramètres. En langage développeur clair : il peut ajouter du contexte au prompt, démarrer des processus locaux, appeler des services distants, exécuter des hooks shell sur des événements de cycle de vie, et exposer de nouveaux outils au modèle.

Le bon modèle mental n’est pas « installer un thème d’éditeur ». C’est « ajouter une dépendance capable d’exécuter du code près de mon arbre source ».

La Marketplace Est Réelle, Mais « Officielle » Ne Veut Pas Dire « Sûre Les Yeux Fermés »

Anthropic a annoncé les plugins Claude Code le 9 octobre 2025, en les décrivant comme des collections de commandes slash, d’agents, de serveurs MCP et de hooks installables avec /plugin (Claude blog). La documentation actuelle de Claude Code indique que la marketplace officielle Anthropic, claude-plugins-official, est disponible automatiquement au démarrage de Claude Code, et qu’on peut installer un plugin avec :

/plugin install github@claude-plugins-official

Si le plugin manque, la documentation indique de rafraîchir la marketplace avec :

/plugin marketplace update claude-plugins-official

ou de l’ajouter avec :

/plugin marketplace add anthropics/claude-plugins-official

C’est le parcours officiel idéal (Claude Code docs). Il est utile. Il est aussi insuffisant comme politique opérationnelle.

Le fichier de marketplace du dépôt officiel pointe vers un mélange de dossiers de plugins locaux et de sources externes épinglées par commit SHA. Par exemple, des entrées peuvent référencer des dépôts GitHub, des sous-dossiers, des refs et des SHA dans .claude-plugin/marketplace.json (raw marketplace file). L’épinglage aide, mais il ne supprime pas la nécessité d’inspecter ce que fait le code épinglé. Un plugin peut toujours lancer un serveur, demander des identifiants, exécuter des hooks ou dépendre d’un binaire dont le comportement change en dehors du manifeste de la marketplace.

La communauté a remarqué la même chose. Dans un fil récent de r/ClaudeAI demandant quels plugins Claude Code étaient importants, une réponse recommandait d’abord CLAUDE.md et les hooks, puis seulement des serveurs MCP spécifiques au projet. Une autre mettait en garde contre le fait de balancer des « connecteurs au hasard » dans Claude Code, parce qu’ils coûtent des tokens et peuvent polluer le contexte (Reddit). C’est le vrai débat maintenant : les plugins sont puissants, mais chaque capacité supplémentaire ajoute une surface de coût.

Commencez Par le Manifeste, Puis Lisez le Dépôt

Votre première cible d’audit, c’est la source du plugin. N’installez pas depuis des extraits de recherche, des commandes copiées-collées d’un blog ou des agrégateurs de marketplace quelconques tant que vous ne pouvez pas remonter jusqu’à un dépôt et un manifeste.

Dans le dépôt officiel de la marketplace, vérifiez :

1. L’entrée de marketplace dans .claude-plugin/marketplace.json
2. Le type source, l’URL, le chemin, la ref et le SHA
3. Le .claude-plugin/plugin.json du plugin, s’il existe
4. Tout .mcp.json, .lsp.json, hooks/hooks.json, commands/, skills/, agents/, bin/ et scripts

La référence des plugins Anthropic liste les chemins de composants principaux. Les hooks vivent dans hooks/hooks.json, les serveurs MCP peuvent vivre dans .mcp.json, les exécutables peuvent vivre dans bin/, et les manifestes de plugins peuvent pointer vers des emplacements de composants personnalisés (Claude Code plugin reference). Autrement dit, « j’ai vérifié plugin.json » ne suffit pas. Un plugin peut s’appuyer sur les chemins de découverte par défaut.

Une revue manuelle rapide ressemble à ça :

git clone https://github.com/OWNER/PLUGIN-REPO /tmp/plugin-audit
cd /tmp/plugin-audit

find . -maxdepth 3 \( \
  -name plugin.json -o \
  -name hooks.json -o \
  -name .mcp.json -o \
  -name .lsp.json -o \
  -path "*/bin/*" -o \
  -path "*/scripts/*" \
\) -print

rg -n "curl|wget|bash|sh -c|chmod|open |xdg-open|osascript|token|api_key|secret|eval|exec|spawn|subprocess"

Cette commande rg est brutale, mais ici, brutal, c’est bien. Vous cherchez les surprises à l’installation, l’exécution shell, les ouvertures de navigateur, les téléchargements distants, la gestion d’identifiants et les scripts qui modifient votre dépôt ou votre répertoire personnel.

Ma règle : si un plugin a besoin d’un script shell pour faire son travail principal, je veux comprendre chaque commande de ce script avant installation. S’il télécharge un autre artefact à l’exécution, je traite cet artefact d’exécution comme une partie du plugin.

Les Serveurs MCP Sont la « Commodité » la Plus Coûteuse

MCP est l’endroit où la commodité d’un plugin peut devenir un coût caché. La documentation MCP d’Anthropic indique que les serveurs MCP définis par un plugin démarrent automatiquement quand le plugin est activé, et que les outils MCP du plugin apparaissent à côté des outils MCP configurés manuellement (Claude Code MCP docs). La documentation dit aussi que les serveurs MCP de plugins utilisent les mêmes variables d’environnement que les serveurs configurés manuellement, ce qui compte si votre shell exporte des tokens cloud, des URL de bases de données ou des identifiants de services internes.

La plainte de la communauté est précise : les schémas d’outils MCP peuvent consommer du contexte avant même que vous appeliez un outil. Dans un fil r/ClaudeCode sur le surcoût en tokens, des utilisateurs pointaient les plugins désactivés et l’absence de gros serveurs MCP comme explication probable d’une consommation plus basse, et un commentateur qualifiait les schémas d’outils MCP d’« énorme coût caché » (Reddit). Dans un autre fil, un commentateur affirmait que les serveurs MCP connectés enregistrent leurs schémas d’outils dans le contexte et recommandait d’élaguer les serveurs par session (Reddit).

Traitez les estimations de tokens exactes venues de Reddit comme anecdotiques tant que vous ne les avez pas reproduites dans votre propre setup. La tendance de fond reste correcte : un serveur toujours actif avec beaucoup d’outils verbeux n’est pas gratuit.

Utilisez ce tableau de décision avant d’installer un plugin de type connecteur :

Un outil CLI est souvent plus sûr parce qu’il n’est invoqué qu’en cas de besoin et ne produit une sortie que pour ce tour. MCP peut être plus sûr quand il vous donne de l’OAuth limité, des outils typés et des journaux d’audit. L’erreur, c’est d’installer MCP par réflexe.

Les Hooks Méritent Leur Propre Revue de Sécurité

Les hooks sont la fonctionnalité qui donne aux plugins un côté magique. Ce sont aussi ceux que j’audite le plus durement.

Les hooks Claude Code peuvent s’exécuter sur des événements comme SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, PreCompact et SessionEnd. La référence des plugins indique que les types de hooks incluent les command hooks, HTTP hooks, MCP tool hooks, prompt hooks et agent hooks (Claude Code plugin reference). Le guide des hooks explique qu’un hook PreToolUse peut bloquer une action en sortant avec le code 2, tandis que la sortie stdout de UserPromptSubmit, UserPromptExpansion et SessionStart peut être ajoutée au contexte de Claude (Claude Code hooks guide).

C’est beaucoup de pouvoir.

Un bon hook bloque un comportement dangereux ou ajoute un contexte compact et déterministe. Un mauvais hook transforme chaque prompt en pipeline RAG coûteux, fuite le texte du prompt vers un endpoint HTTP, ou modifie silencieusement votre environnement.

Auditez les hooks avec quatre questions :

1. Quel événement le déclenche ?
2. Quel matcher le limite ?
3. Quelles données reçoit-il ?
4. Qu’écrit-il dans stdout, stderr, le disque, le réseau ou le contexte ?

La communauté est divisée ici, et c’est utile. Dans un fil r/ClaudeCode sur les hooks, certains développeurs les décrivent comme le seul moyen fiable d’imposer des règles, de bloquer de mauvaises actions git ou de rappeler à Claude d’écrire en mémoire. D’autres construisent des flux mémoire et RAG élaborés sur UserPromptSubmit (Reddit). Les deux peuvent être valables. La différence, c’est le budget et le rayon d’explosion.

Pour des installations d’équipe, j’autoriserais les hooks de politique avant les hooks d’injection de contexte. Un hook PreToolUse qui bloque les motifs rm -rf est facile à raisonner. Un hook UserPromptSubmit qui récupère et injecte de la mémoire à chaque tour exige des mesures, des plafonds et une responsabilité claire.

Installez Étroitement, Mesurez, Puis Promouvez

Claude Code prend en charge des scopes de plugins utilisateur, projet, local et géré. La documentation décrit le scope utilisateur comme personnel et transversal aux projets, le scope projet comme partagé via .claude/settings.json, et le scope local comme spécifique au projet mais non partagé (Claude Code docs).

Utilisez ces scopes comme mécanisme de déploiement progressif :

1. Installez d’abord en local.
2. Exécutez une vraie tâche.
3. Vérifiez les détails dans /plugin et /mcp.
4. Utilisez /context et /usage avant et après.
5. Désactivez tout ce qui ne rentabilise pas sa présence.
6. Ne promouvez au scope projet qu’après revue.

La documentation indique désormais que le panneau de détails du plugin peut afficher des estimations de coût de contexte dans Claude Code v2.1.143 et versions ultérieures, les dates de dernière mise à jour dans v2.1.144 et versions ultérieures, et un inventaire « Will install » dans v2.1.145 et versions ultérieures (Claude Code docs). Utilisez cet inventaire avant d’appuyer sur installer. Si un plugin prétend être un formateur mais installe un serveur MCP, un hook et un moniteur en arrière-plan, arrêtez-vous et inspectez.

Surveillez aussi les mises à jour automatiques. Anthropic indique que les marketplaces officielles ont les mises à jour automatiques activées par défaut, tandis que les marketplaces tierces et locales les ont désactivées par défaut. La documentation décrit aussi DISABLE_AUTOUPDATER et FORCE_AUTOUPDATE_PLUGINS pour contrôler le comportement de mise à jour (Claude Code docs). La mise à jour automatique est pratique pour les correctifs de sécurité, mais elle modifie votre chaîne d’approvisionnement à l’exécution. Pour les équipes réglementées, épinglez les versions de marketplace dans une marketplace interne revue plutôt que de laisser chaque laptop dériver indépendamment.

La Checklist Que J’Utilise Avant Installation

Voici la version courte que je donnerais à n’importe quel développeur d’une équipe utilisant Claude Code.

Source :

• La marketplace est-elle anthropics/claude-plugins-official, un dépôt interne ou un dépôt tiers ?
• La source du plugin est-elle épinglée à un SHA ?
• La page d’accueil correspond-elle au propriétaire de la source ?
• Le dépôt contient-il des changements récents inattendus, des blobs générés ou des scripts d’installation ?

Composants :

• Ajoute-t-il des serveurs MCP ?
• Ajoute-t-il des hooks ?
• Ajoute-t-il des exécutables dans bin/ ?
• Ajoute-t-il des agents capables d’appeler des outils ?
• Ajoute-t-il des serveurs LSP qui exigent des binaires locaux ?

Permissions :

• Quels identifiants demande-t-il ?
• Les valeurs sensibles sont-elles stockées via le userConfig du plugin comme champs sensibles ?
• Le serveur MCP obtient-il un accès en lecture seule ou en écriture ?
• Un hook téléphone-t-il à la maison via HTTP ?
• Un script hérite-t-il de variables d’environnement trop larges ?

Coût :

• Que rapporte /plugin comme coût de contexte ?
• Qu’est-ce qui change dans /context après activation ?
• Le plugin ajoute-t-il de la valeur à chaque session, ou seulement dans de rares workflows ?
• Une commande CLI pourrait-elle produire le même résultat avec moins de contexte persistant ?

Opérations :

• Pouvez-vous le désactiver proprement avec /plugin disable name@marketplace ?
• Pouvez-vous le désinstaller proprement ?
• Laisse-t-il derrière lui de la config, des identifiants, des daemons, des caches ou une authentification navigateur ?
• Qui possède les mises à jour ?
• Qu’est-ce qui casse si la source du plugin disparaît ?

La réponse tranchée : installez moins de plugins que vous n’en avez envie. Préférez les petits plugins ennuyeux qui ajoutent un seul workflow. Préférez les CLIs pour les opérations ponctuelles. Utilisez MCP quand le serveur est limité, audité et réellement interactif. Utilisez les hooks comme garde-fous, pas comme décharge pour chaque préférence que vous aimeriez que le modèle retienne.

Les plugins deviennent le format de paquet de Claude Code pour les workflows. C’est une bonne chose. Cela signifie que les équipes peuvent partager des setups répétables plutôt que du folklore de prompts transmis oralement. Mais ce format de paquet est assez puissant pour mériter une revue de dépendances, une revue de permissions et une revue de coûts. Si vous ne feriez pas un curl | bash d’un outil dans votre dépôt sans le lire, n’installez pas sa version plugin juste parce qu’elle apparaît dans une interface de marketplace rassurante.

Pied de page discret : si vous voulez essayer Claude Fable 5 vous-même, vous pouvez l’utiliser via Claude Fable 5 on OneHop, un endpoint compatible drop-in proposé environ 30 % sous le prix catalogue. Les nouveaux comptes peuvent commencer avec 10 $ gratuits, sans carte bancaire.

À lire aussi : Bien démarrer avec Claude Fable 5.