Comment créer des plugins Claude Code : guide pas à pas

Claude Code gère la plupart des tâches de développement dès l'installation, mais chaque équipe a des flux de travail spécifiques que les paramètres par défaut ne couvrent pas. Vous pouvez, par exemple, vouloir une commande personnalisée qui génère des composants selon la structure en vigueur dans votre entreprise, un linting automatique avant chaque commit, ou un accès instantané à la documentation d'un framework que vous utilisez en continu.

Les plugins Claude Code vous permettent d'ajouter vous-même ces fonctionnalités. Vous pouvez installer des plugins créés par la communauté ou développer les vôtres.

Si vous découvrez l'outil de codage agentique d'Anthropic, nous vous conseillons de commencer par le guide Claude Code ou le cours Introduction to Claude Models. Ce tutoriel suppose que Claude Code est installé et que vous l'avez déjà utilisé pour des tâches basiques.

Au terme de ce guide, vous saurez :

• Trouver et installer des plugins depuis l'annuaire d'Anthropic et des sources communautaires
• Comprendre les trois types de composants que peut contenir un plugin
• Choisir le bon type selon l'usage
• Conçoir et partager vos propres plugins

Pour un aperçu des capacités du dernier modèle d'Anthropic, consultez notre guide sur Claude Sonnet 5.

En bref

• Les plugins Claude Code regroupent des skills, des serveurs MCP et des hooks dans des packages partageables, que vous installez avec claude plugin add

• Les skills se chargent à la demande (~100 tokens chacun) ; les serveurs MCP préchargent les définitions d'outils (réduit par Tool Search) ; les hooks s'exécutent en scripts shell sans coût en tokens

• Utilisez des skills pour la connaissance et les workflows, des serveurs MCP pour l'accès à des APIs externes, et des hooks pour des règles à appliquer systématiquement

• Créez un plugin avec trois fichiers : un manifeste .claude-plugin/plugin.json, un répertoire skills/ et un fichier d'instructions SKILL.md

Qu'est-ce qu'un plugin Claude Code ?

Un plugin est un package qui regroupe une ou plusieurs extensions Claude Code pour en faciliter le partage et l'installation. Plutôt que de copier manuellement des fichiers de configuration entre machines ou collègues, vous encapsulez tout dans un plugin et le distribuez en un seul bloc.

Les plugins peuvent contenir trois types de composants :

• Skills : commandes personnalisées que vous invoquez avec /skill-name, ou invites contextuelles que Claude utilise automatiquement quand c'est pertinent

• Serveurs MCP : connexions à des services et APIs externes donnant à Claude accès à des données auxquelles il n'aurait pas accès autrement

• Hooks : scripts shell qui s'exécutent automatiquement sur des événements spécifiques, par exemple avant l'édition d'un fichier ou après un commit

Un plugin peut n'en contenir qu'un seul, ou combiner plusieurs composants qui coopèrent. Un plugin de « déploiement » pourrait inclure une skill /deploy pour les déploiements manuels, un serveur MCP qui vérifie l'état de votre environnement de staging, et un hook qui lance les tests avant toute commande de déploiement.

Le fichier manifeste plugin.json définit le contenu d'un plugin. Il spécifie les skills, serveurs MCP et hooks à installer, ainsi que des métadonnées comme le nom, la version et l'auteur. Lors de l'installation, Claude Code lit ce manifeste et déploie chaque composant au bon endroit.

Ce format de packaging vous évite de connaître la structure interne des fichiers des extensions Claude Code. Vous installez le plugin, et tout se met en place automatiquement.

Trouver et installer des plugins Claude Code

La plupart des plugins se trouvent à deux endroits. L'annuaire officiel d'Anthropic sur claude.com/plugins propose des plugins développés par Anthropic, des contributions communautaires vérifiées et des extensions tierces populaires. Chaque fiche présente les composants inclus, les informations de compatibilité et les instructions d'installation.

La deuxième source est GitHub :

Une fois le plugin trouvé, la commande d'installation dépend de son emplacement :

# Depuis l'annuaire officiel
claude plugin add @anthropic/deploy-helper
 
# Depuis un dépôt GitHub
claude plugin add github:username/repo-name
 
# Depuis un répertoire local (pratique en développement)
claude plugin add ./my-plugin

Après en avoir installé quelques-uns, vous souhaiterez les suivre. La commande plugin permet de lister, mettre à jour et supprimer :

# Lister tous les plugins installés
claude plugin list
 
# Mettre à jour un plugin spécifique vers la dernière version
claude plugin update @anthropic/deploy-helper
 
# Mettre à jour tous les plugins
claude plugin update --all
 
# Supprimer un plugin
claude plugin remove @anthropic/deploy-helper

Lors de l'installation, vous choisissez aussi la portée. Il y en a deux : au niveau utilisateur, l'installation se fait dans ~/.claude/plugins/ et fonctionne sur tous vos projets ; au niveau projet, elle se fait dans .claude/plugins/ au sein d'un dépôt spécifique.

Par défaut, la portée est utilisateur. Pour installer un plugin uniquement sur le projet courant, ajoutez l'option --project :

claude plugin add @anthropic/deploy-helper --project

Les plugins à portée projet sont pertinents lorsque l'extension est liée à une base de code donnée. 

Un plugin qui formalise votre processus de déploiement d'entreprise a sa place dans ce projet. Un plugin qui met en forme le code selon vos préférences personnelles relève du niveau utilisateur. Si un plugin existe aux deux portées, la version projet est prioritaire : les équipes peuvent ainsi imposer des configurations spécifiques au projet, tout en laissant les développeurs conserver leurs plugins personnels ailleurs.

Choisir le bon type de plugin Claude Code

Les trois types de composants ont des objectifs différents et consomment les tokens de la fenêtre de contexte de manière distincte. Comprendre ces arbitrages aide à choisir la bonne approche pour chaque besoin.

Skills vs serveurs MCP : l'arbitrage des tokens

Les serveurs MCP préchargent toutes les définitions d'outils dans la fenêtre de contexte au démarrage de la session. Chaque outil nécessite son nom, sa description et tout son schéma de paramètres, ce qui représente généralement 100–300 tokens par outil. Une configuration avec cinq serveurs consomme environ 55 000 tokens avant même de taper un caractère :

• GitHub : 35 outils
•  Slack : 11 outils
• Sentry : 5 outils
• Grafana : 5 outils
• Splunk : 2 outils

Une analyse a relevé des configurations avec 7+ serveurs consommant plus de 67 000 tokens, soit un tiers d'une fenêtre de contexte de 200 K consommé avant même de démarrer la conversation.

Les skills adoptent une approche différente, par divulgation progressive. Au démarrage, Claude ne voit que le nom de chaque skill et une ligne de description dans le front matter YAML, soit environ 100 tokens par skill. 

Les instructions complètes ne sont chargées que lorsque Claude juge la skill pertinente pour la tâche en cours. Les fichiers de référence ne se chargent que si nécessaire. Et les scripts n'entrent jamais dans la fenêtre de contexte : Claude les exécute en externe et seul le résultat revient.

Anthropic a rééquilibré ce point fin 2025 avec Tool Search, une fonctionnalité qui apporte le chargement paresseux aux serveurs MCP. 

Au lieu de précharger chaque définition d'outil, Claude Code détecte désormais quand les descriptions d'outils dépasseraient 10 % du contexte disponible et bascule sur un chargement à la demande. 

Les tests internes ont montré une chute de l'usage du contexte d'environ 134 000 tokens à ~5 000 tokens pour de grandes bibliothèques d'outils. La précision de sélection des outils s'est aussi améliorée, avec Opus 4 passant de 49 % à 74 % et Opus 4.5 de 79,5 % à 88,1 % sur les évaluations MCP.

Voici comment trancher entre les deux.

Les skills sont idéales quand vous souhaitez que Claude accède à des connaissances ou à des workflows qu'il appliquera avec jugement. Une skill décrivant votre checklist de revue de code se charge quand Claude révise du code, mais c'est lui qui décide comment appliquer chaque point selon le contexte. 

Les skills sont également pertinentes pour des opérations nécessitant des scripts de calcul intensif, puisque le code du script reste hors contexte.

Les serveurs MCP conviennent quand Claude a besoin de données temps réel issues de services externes comme des messages Slack, des PR GitHub ou des requêtes base de données. C'est aussi le bon choix quand plusieurs agents d'IA doivent partager les mêmes outils, ou si vous avez besoin de fonctions d'entreprise comme des journaux d'audit et des permissions explicites.

Beaucoup de configurations combinent les deux : les skills fournissent le « comment » et le « quand » via des instructions en langage naturel, tandis que les serveurs MCP gèrent les appels API réels.

Skills populaires à installer

• Superpowers (notre tutoriel) : plus de 20 workflows éprouvés pour TDD, débogage et planification structurée
• frontend-design : indique à Claude d'éviter les designs génériques et d'assumer des choix esthétiques forts
• mcp-builder : guide pour créer des serveurs MCP et intégrer des APIs externes
•  webapp-testing : tester des applications web locales avec Playwright pour vérifier l'UI
•  skill-creator : outil interactif qui vous guide pour créer de nouvelles skills

Serveurs MCP populaires à connecter

• Context7 : recherche de documentation en temps réel et spécifique à la version
• GitHub : recherche de dépôts, gestion des PR, suivi des issues
• Playwright : automatisation de navigateur via arbres d'accessibilité plutôt que captures
• Supabase : requêtes SQL avec prise en compte de la Row Level Security
• Sentry : suivi d'erreurs et performance directement dans l'éditeur

Vous pouvez aussi consulter notre guide des meilleurs serveurs MCP distants.

Hooks : la couche déterministe

Les hooks ne rentrent pas dans le débat skills vs MCP. Alors que les skills et serveurs MCP s'adressent à Claude (c'est Claude qui décide de les utiliser), les hooks s'adressent au système. Ils se déclenchent sur des événements comme PreToolUse ou PostToolUse, en exécutant des scripts shell avant ou après que Claude effectue certaines actions. Claude ne décide pas si un hook s'exécute.

Les hooks sont donc le bon choix quand quelque chose doit se produire sans exception : linting avant chaque commit, blocage des écritures dans des répertoires protégés, journalisation de chaque commande bash, ou exécution des tests avant tout déploiement.

Cette développeuse recommande des hooks « block-at-submit » plutôt que « block-at-write ». Bloquer Claude en plein travail perturbe l'agent et dégrade les résultats. Son équipe utilise un hook PreToolUse qui encapsule Bash(git commit) et vérifie l'existence d'un fichier temporaire uniquement présent si les tests réussissent. Pas de fichier, pas de commit. L'agent termine son travail, puis la validation intervient à la fin.

Les hooks n'ajoutent aucun surcoût en tokens puisqu'ils s'exécutent comme des scripts shell hors contexte.

Hooks utiles à configurer

• ESLint/Prettier à l'édition : mise en forme automatique après écriture par Claude
• Barrière de tests au commit : bloquer les commits tant que les tests ne passent pas
• Chemins protégés : empêcher les écritures dans migrations, configs ou vendor
• Notification à la fin : envoyer des alertes Slack ou bureautiques quand une tâche longue se termine
• Sauvegarde de transcription : enregistrer l'historique de conversation avant la compaction

Comment créer vos propres plugins Claude Code

Lorsqu'une skill vit dans votre répertoire personnel .claude/, vous êtes le seul à pouvoir l'utiliser. L'emballer dans un plugin permet de la partager avec vos collègues ou de la réutiliser entre projets.

Nous allons créer un plugin nommé session-logger qui ajoute la commande /session-logger:summarize. Lorsqu'elle est invoquée, Claude passe en revue la conversation et ajoute un résumé structuré à SESSION_LOG.md.

Créer la structure du plugin

Les plugins peuvent être placés n'importe où sur votre système de fichiers. Pour ce tutoriel, créons-le dans votre répertoire personnel :

cd ~
mkdir -p session-logger/.claude-plugin
mkdir -p session-logger/skills/summarize

Cela crée :

~/session-logger/
├── .claude-plugin/
│   └── plugin.json  	# le manifeste va ici, et nulle part ailleurs
└── skills/
	└── summarize/   	# le nom du dossier devient le nom de la commande
    	└── SKILL.md 	# doit s'appeler exactement comme cela

Rédiger le manifeste

Créez ~/session-logger/.claude-plugin/plugin.json :

{
  "name": "session-logger",
  "description": "Log session summaries to a markdown file",
  "version": "1.0.0"
}

Le champ name devient le préfixe d'espace de noms. Toutes les commandes de ce plugin commenceront par /session-logger:.

Écrire la skill

Créez ~/session-logger/skills/summarize/SKILL.md :

---
description: Log a summary of the current session to SESSION_LOG.md
disable-model-invocation: true
---
 
When invoked, review the conversation and create a summary with these sections:
 
- **Date/time**: Current timestamp
- **Tasks completed**: What was accomplished
- **Files modified**: List of files created or changed
- **Decisions made**: Architectural or implementation choices
- **Open questions**: Unresolved items for future sessions
 
Append the summary to SESSION_LOG.md in the project root. Create the file if it doesn't exist.

La ligne disable-model-invocation: true indique à Claude que vous seul pouvez déclencher cette skill. Sans ce drapeau, Claude pourrait décider de l'exécuter de lui-même s'il estime que cela aide la conversation. Pour un logger ou un outil de déploiement, on préfère généralement un contrôle manuel.

Tester en local

Allez dans n'importe quel projet où vous souhaitez utiliser le plugin, puis lancez Claude Code avec l'option --plugin-dir pointant vers votre plugin :

cd ~/your-project
claude --plugin-dir ~/session-logger

Saisissez /session-logger:summarize pour invoquer la commande. Notez que les commandes de plugin n'apparaissent pas dans les suggestions d'autocomplétion tant que vous n'avez pas tapé le nom complet. Le texte devient bleu lorsque Claude Code la reconnaît comme commande valide.

Après avoir travaillé un peu dans la session, lancez la commande. Claude passe en revue la conversation et ajoute une entrée à SESSION_LOG.md dans le répertoire de votre projet courant.

Partager avec d'autres

Publiez votre plugin sur GitHub. Pour le distribuer au-delà d'un clonage manuel, ajoutez-le à une place de marché. Le guide marketplace explique comment créer votre propre marketplace ou soumettre le plugin à des existantes.

Pour conclure

Les plugins transforment Claude Code d'un assistant généraliste en un outil adapté à votre quotidien. Le logger de session que nous avons construit prend environ cinq minutes et trois fichiers. La plupart des plugins utiles ne sont pas beaucoup plus complexes.

Si vous avez suivi le guide, vous avez maintenant un plugin opérationnel sur votre machine. Essayez de l'ajuster : modifiez le format du résumé, ajoutez des sections, ou remplacez-le par quelque chose dont votre équipe a vraiment besoin. La structure reste la même que vous créiez un outil perso rapide ou un plugin destiné à des centaines de développeurs.

Par ailleurs, parcourez les dépôts communautaires quand vous le pouvez. Voir comment les autres structurent leurs plugins apprend des schémas que la documentation ne couvre pas.

Pour aller plus loin avec Claude Code, consultez nos tutoriels sur les bonnes pratiques Claude Code, le cadre de skills Superpowers, les commandes slash pour les sessions longues, et la sécurité et les permissions. Pour en savoir plus sur les modèles Claude, nous recommandons le cours Introduction to Claude Models.