Documentation des plugins Claude Code : Ce que sont les plugins, comment les installer et quand utiliser MCP à la place

Si vous cherchez la documentation des plugins Claude Code, la réponse courte est la suivante : les plugins sont la couche de packaging des extensions Claude Code. Un plugin peut regrouper des skills, agents, hooks, serveurs MCP, serveurs LSP et moniteurs en une seule unité installable, tandis que MCP reste la couche de connexion aux outils en dessous. Si vous avez cherché « plugin MCP » ou « plugin doc », c’est généralement la distinction que les docs veulent que vous fassiez : les plugins distribuent la configuration, MCP connecte les outils, et la documentation de référence explique la forme technique de chaque élément.

Claude Code dispose désormais d’une surface d’extension suffisante pour que la terminologie devienne rapidement confuse. « Plugin » est souvent utilisé comme terme générique pour tout, même lorsque la fonctionnalité réelle en jeu est un skill, un hook ou un serveur MCP. Cette confusion a son importance car les étapes d’installation, le modèle de sécurité et la charge de maintenance diffèrent pour chacun.

Avant d’entrer dans la configuration, une note pratique pour les équipes qui souhaitent plus de flexibilité backend qu’un workflow exclusivement basé sur des modèles fermés : la couche d’extension de Claude Code est distincte du modèle que vous exécutez derrière. Cela signifie que vous pouvez conserver la même configuration de plugin, skill et MCP tout en acheminant l’inférence via un modèle open-weight sur Novita AI comme qwen/qwen3-coder-480b-a35b-instruct, une option crédible pour un travail réel sur dépôt lorsque vous souhaitez un meilleur contrôle des coûts sans renoncer aux outils agentiques.

Ce que la documentation actuelle souligne

La documentation live de Claude Code sépare désormais quatre éléments très clairement :

• les plugins, qui encapsulent des extensions réutilisables ;
• MCP, qui connecte Claude Code à des outils et sources de données externes ;
• les skills et sous-agents, qui contiennent des comportements réutilisables ;
• les hooks, qui automatisent des actions sur des événements du cycle de vie.

Cela signifie qu’une grande partie des recherches de « documentation des plugins Claude Code » demande en réalité la référence des plugins, le flux de découverte/installation, ou les docs MCP qui expliquent comment la connectivité des outils fonctionne. Les docs actuelles exposent également des flux d’installation et de distribution basés sur une marketplace, vous permettant d’installer des plugins préconstruits au lieu de câbler chaque composant vous-même.

Ce que sont réellement les plugins Claude Code

Les docs actuelles d’Anthropic définissent les plugins comme la couche de distribution et de réutilisation des extensions Claude Code. En pratique, cela signifie qu’un plugin est un répertoire autonome avec un manifeste et des composants d’extension optionnels tels que :

• skills
• agents
• hooks
• configuration MCP
• configuration LSP
• binaires auxiliaires
• paramètres par défaut

C’est pourquoi la documentation officielle des plugins a de l’importance même si ce que vous voulez vraiment est un skill réutilisable ou une structure MCP en une commande. Le plugin est souvent ce que vous installez, mais le comportement qui vous intéresse vit à l’intérieur des composants emballés.

La conséquence la plus importante est le nommage. Les skills de plugin sont dans un espace de noms, donc une commande d’un plugin ressemble à ceci :

/my-plugin:hello

Cet espace de noms n’est pas cosmétique. Il empêche les collisions entre plugins qui expédient des commandes nommées de manière similaire.

Plugins vs MCP vs Skills vs Hooks

C’est là que la plupart des développeurs perdent du temps dans la documentation.

Utilisez ce raccourci :

Fonctionnalité	Ce qu’elle fait	Meilleur cas d’utilisation
Plugin	Emballage et distribution des extensions	Réutiliser la même configuration sur plusieurs projets ou entre coéquipiers
MCP	Connecte Claude Code à des outils et services externes	GitHub, Notion, bases de données, contrôle de navigateur, APIs internes
Skill	Donne à Claude des connaissances réutilisables ou un workflow	Listes de vérification de review, flux de déploiement, style maison, prompts répétables
Hook	S’exécute automatiquement sur des événements du cycl de vie	Linter après édition, bloquer des commandes risquées, déclencher des notifications

Beaucoup de questions « plugin Claude Code » sont en réalité des questions MCP. Si votre objectif est « connecter Claude Code à Jira » ou « laisser Claude interroger notre base de données », vous ne cherchez pas principalement une fonctionnalité de plugin. Vous cherchez un serveur MCP, qui peut être installé directemment ou emballé dans un plugin. En pratique, cela signifie que de nombreuses recherches de « plugin MCP » sont en réalité des recherches du bon serveur plus du bon chemain d’emballage ou d’installation.

C’est aussi pourquoi l’aperçu des fonctionnalités dans la documentation d’Anthropic est utile : il sépare explicitement les plugins de MCP et des skills. Les plugins sont l’emballage. MCP est la connexion externe. Les skills sont les instructions réutilisables. Les hooks sont la couche d’automatisation.

Du point de vue de la pile Novita, c’est aussi l’endroit le plus propre pour séparer le raisonnement de l’exécution. Si vous construisez un workflow personnalisé adjacent à Claude Code autour d’outils MCP, l’API LLM de Novita peut gérer la couche de raisonnement d’utilisation d’outils tandis que Novita Agent Sandbox gère la couche d’éxécution isolée pour le code, les commandes shell et les effets de bord des outils. Cette séparation correspond naturellement à la frontière « le modèle décide » vs « l’exécution s’exécute » que les docs de plugin et MCP décrivent réellement.

Quand devriez-vous utiliser un plugin

Utilisez un plugin lorsqu’au moins l’une de ces conditions est vraie :

• vous voulez la même personnalisation Claude Code sur plusieurs dépôts ;
• vous voulez que vos coéquipiers installent une seule chose plutôt que de copier manuellement les fichiers .claude/ ;
• vous voulez un emballage versionné et partageable pour les skills, hooks ou configurations MCP ;
• vous prévoyez de distribuer l’extension via une marketplace.

Ne recourez pas d’abord à un plugin si vous n’expérimentez que dans un seul dépôt. Les docs d’Anthropic recommandant toujours de commencer par une configuration .claude/ autonome pour une itération rapide. C’est le chemin le moins frictionné pour les workflows spécifiques à un projet.

En d’autes termes :

• la configuration autonome est meilleure pour l’expérimentation locale ;
• les plugins sont meilleurs pour la portabilité et la distribution.

Le moyen le plus rapide d’installer un plugin existant

Si vous connaissez déjà le nom du plugin et la marketplace, les docs actuelles pointent vers le flux de commande slash depuis l’intérieur de Claude Code.

Par exemple, les docs MCP d’Anthropic utilisent ce chemin d’installation pour le plugin officiel mcp-server-dev :

/plugin install mcp-server-dev@claude-plugins-officiel

Si Claude Code signale que la marketplace est manquante, ajoutez-la d’abord :

/plugin marketplace add anthropics/claude-plugins-official

Puis réexécutez la commande d’install.

Après l’install, vérifiez si Claude vous dit de recharger les plugins. Si c’est le cas, exécutez :

/reload-plugins

Cette étape de rechargement compte plus qu’il n’y paraît. C’est une raison courante pour laquelle les développeurs pensent qu’un plugin « n’a pas fonctionné » alors que les fichiers sont présents mais que les commandes ne sont pas actives dans la session en cours.

Comment créer votre propre plugin Claude Code

Si vous voulez construire votre propre plugin, les docs actuelles présentent un démarrage rapide simple :

1. Créez un répertoire de plugin.
2. Ajoutez .claude-plugin/plugin.json.
3. Ajoutez un répertoire skills/, agents/, hooks/ ou autre répertoire d’extension supporté.
4. Lancez Claude Code avec --plugin-dir pendant le développement.

L’exemple le plus petit et utile est un plugin qui livre un skill. Les docs d’Anthropic montrent un manifeste plus un dossier skills/<name>/SKILL.md. Le manifeste définit l’identité du plugin, et le skill devient une commande avec espace de noms.

Pendant le développement, le flux de test canonique est :

claude --plugin-dir ./mon-premier-plugin

Puis invoquez le skill depuis Claude Code :

/mon-premier-plugin:hello

Un détail qui est facile à manquer : seul plugin.json appartient dans .claude-plugin/. Vos répertoires skills/, agents/ et hooks/ restent à la racine du plugin, pas imbriqués sous .claude-plugin/.

Pourquoi les docs mentionnent constamment MCP dans les guides de plugins

Parce qu’un plugin peut livrer une configuration MCP.

C’est utile lorsque vous avez un service interne que chaque ingénieur de votre équipe doit pouvoir atteindre avec Claude Code. Au lieu de dire à tout le monde de configurer manuellement le même serveur MCP, vous pouvez emballer cette configuration avec le reste de votre workflow Claude Code.

Cela ne rend pas MCP obsolète. Cela change simplement la façon dont le serveur est livré.

Pensez-y de cette manière :

• MCP répond : « Comment Claude parle-t-il à ce système externe ? »
• Un plugin répond : « Comment distribuons-nous cette configuration proprement ? »

Si vous concevez une plateforme de développement interne, cette distinction permet d’économiser beaucoup de travail de configuration dupliqué.

Quand MCP est le meilleur point de départ

Commencez par MCP, pas par un plugin, lorsque l’exigence principale est l’accès externe :

• trackers de tickets
• outils de surveillance
• Slack
• Notion
• bases de données
• automatisation de navigateur
• services HTTP internes

Les docs MCP actuelles d’Anthropic montrent quatre modes de connexion courants :

• serveurs HTTP distants
• serveurs SSE distants
• serveurs stdio locaux
• serveurs WebSocket distants

Pour la plupart des services cloud, HTTP est le transport recommandé. SSE est documenté mais marqué comme déprécié là où HTTP est disponible.

Si vous n’avez besoin de connecter qu’un seul service pour vous-même, claude mcp add est généralement le meilleur endroit pour commencer. Emballez-le dans un plugin plus tard si la configuration s’avère réutilisable.

MCP donne à Claude Code un moyen d’atteindre les outils, mais il ne remplace pas un runtime d’exécution sécurisé lorsque l’un de ces outils doit exécuter du code, toucher aux fichiers ou exécuter des commandes. Dans cette configuration, l’API LLM de Novita est le backend de raisonnement qui décide quand et comment appeler les outils, tandis que Novita Agent Sandbox est l’environnement d’exécution plus sûr pour le côté exécution de code du workflow. Si votre plugin ou serveur MCP expose une exécution de code à distance, une automatisation de navigateur ou des aides basées sur shell, cette séparation est plus que de l’hygiène d’architecture. C’est la différence entre « Claude peut appeler cet outil » et « cet outil s’exécute dans un runtime isolé au lieu de se trouver sur le portable d’un ingénieur ou sur un hôte partagé ».

Règle de décision pratique

Si vous ne savez toujours pas quelle page de doc vous avez réellement besoin, utilisez cette règle :

• « Je veux que Claude Code fasse quelque chose de la même manière à chaque session. » Commencez par CLAUDE.md ou un skill.
• « Je veux que Claude Code parle à un autre système. » Commencez par MCP.
• « Je veux que cette configuration soit facile à réutiliser ou à partager. » Emballez-la comme plugin.
• « Je veux que quelque chose s’exécute automatiquement sur un événement. » Utilisez un hook.

C’est plus utile que de mémoriser les noms des fonctionnalités parce que cela correspond directement au problème que vous résolvez.

Où cela s’insère dans un workflow réel

Si la configuration du plugin ou de MCP n’est qu’une pièce d’une pile agentique plus grande, associez-la à Qu’est-ce qu’un agent de codage ?, Runtime d’agent vs interpréteur de code, et Sandbox de serveur MCP : serveurs MCP isolés avec système de fichiers, secrets et contrôles réseau. Cela vous donne la chaîne complète de la planification à l’accès aux outils en passant par l’exécution isolée.

Un bon workflow de plugin pour les équipes réelles

Pour la plupart des équipes, la progression la plus propre ressemble à ceci :

1. Prototypez le workflow dans .claude/ ou avec des commandes directes claude mcp add.
2. Ne conservez que les parties qui s’avèrent utiles dans le travail réel.
3. Emballez ces parties dans un plugin avec un manifeste clair et des skills avec espace de noms.
4. Partagez-le via une marketplace ou un chemin de distribution interne.

Cela évite le mode d’échec le plus courant : transformer chaque idée en plugin avant que quiconque sache si le workflow vaut la peine d’être maintenu.

Si votre équipe associe Claude Code à un backend de modèle alternatif, c’est aussi l’étape où Novita AI peut être utile sur le plan opérationnel. La couche de plugin et de MCP reste la même, tandis que le routage des modèles peut passer à l’API LLM de Novita pour les sessions lourdes en codage qui n’ont pas besoin d’un modèle fermé premium à chaque étape. Cette séparation est souvent plus simple que de reconcevoir la pile d’extension elle-même.

Erreurs courantes dans la configuration des plugins Claude Code

Voici les erreurs qui font perdre le plus de temps :

Traiter chaque extension comme un plugin

Parfois, la bonne réponse est un skill simple ou une configuration directe de serveur MCP. Emballer trop tôt ajoute de la maintenance.

Mettre les fichiers dans le mauvais répertoire

plugin.json va dans .claude-plugin/. Les skills et hooks non.

Oublier l’espace de noms

Un skill de plugin est invoqué avec le préfixe du plugin, pas comme une commande globale.

Sauter le rechargement après l’installation

Si Claude vous dit d’exécuter /reload-plugins, faites-le avant de supposer que l’installation a échoué.

Utiliser un plugin alors que le vrai besoin est MCP

Si le problème central est la connectivité des outils, concentrez-vous d’abord sur MCP et emballez plus tard.

En résumé

La documentation des plugins Claude Code a plus de sens une fois que vous cessez de traiter « plugin » comme le seul concept d’extension. Les plugins sont la couche de distribution. Les skills contiennent des instructions réutilisables. Les hooks automatisent les événements du cycle de vie. MCP connecte Claude Code aux systèmes externes.

Ce cadre rend le reste de la documentation beaucoup plus facile à naviguer. Si votre objectif est une configuration rapide, commencer par la plus petite unité fonctionnelle qui solve le problème. N’ajoutez l’emballage que lorsque la configuration vaut la peine d’être réutilisée.

FAQ

Les plugins Claude Code sont-ils la même chose que les serveurs MCP ?

Non. Les serveurs MCP sont la couche de connexion pour les outils et services externes. Les plugins sont une couche d’emballage qui peut inclure la configuration MCP ainsi que des skills, hooks, agents et autres extensions Claude Code.

Comment installer un plugin Claude Code ?

Depuis l’intérieur de Claude Code, utilisez la commande /plugin install avec le nom du plugin et de la marketplace. Si la marketplace n’est pas présente, ajoutez-la avec /plugin marketplace add ..., puis rechargez les plugins si Claude vous y invite.

Dois-je utiliser un plugin ou simplement des fichiers .claude/ ?

Utilisez les fichiers .claude/ pour une itération rapide spécifique à un projet. Utilisez un plugin lorsque la configuration doit être réutilisée sur plusieurs projets, partagée avec des coéquipiers ou distribuée via une marketplace.

Quand dois-je utiliser MCP plutôt qu’un plugin ?

Utilisez d’abord MCP lorsque votre objectif principal est l’accès externe à des systèmes comme GitHub, Jira, Notion, Slack ou des API internes. Si vous comparez un guide « plugin MCP » avec une page de documentation sur les plugins, considérez le guide MCP comme la référence de connexion aux outils et la page de documentation des plugins comme la référence d’emballage. Emballez cette configuration en plugin plus tard seulement si vous avez besoin d’une réutilisation et d’une distribution plus propres.

Les plugins Claude Code peuvent-ils fonctionner avec des backends de modèle non Anthropic ?

Oui. La couche d’extension et le backend de modèle sont des préoccupations distinctes. En pratique, cela signifie que vous pouvez conserver la même configuration de plugin et de MCP de Claude Code tout en acheminant l’inférence via un fournisseur compatible comme Novita AI pour les workflows de codage supportés.

Articles recommandés

• Plugins Claude Code : comment les outils MCP étendent Claude Code avec des capacités externes
• Règles Claude Code : comment écrire CLAUDE.md et gérer le contexte de codage agentique
• Construire un serveur MCP d’exécution de code à distance avec Novita Sandbox et la bibliothèque mcp-use

Sources vérifiées le 31 août 2026 : Aperçu des fonctionnalités Claude Code, Documentation des plugins Claude Code, Documentation MCP Claude Code et Bibliothèque de modèles Novita AI.