Claude Code plugin : comment le publier dans l’annuaire

Claude Code plugin : la procédure en bref

Pour publier un plugin Claude, suivez cet ordre :

1. Vérifiez que le compte Claude utilisé pour la soumission dispose d’une offre Pro, Max, Team ou Enterprise.
2. Sélectionnez l’organisation qui doit rester propriétaire de la fiche sur le long terme.
3. Préparez le plugin avec .claude-plugin/plugin.json, un README et une licence.
4. Testez le dossier en local, puis placez-le dans un dépôt GitHub auquel le compte GitHub connecté peut envoyer des modifications.
5. Ouvrez le portail développeur, choisissez Plugin bundle, renseignez le dépôt, le chemin facultatif du plugin et la branche ou le tag suivi, puis lancez Validate.
6. Complétez les rubriques consacrées au traitement des données, à la conformité, au contact et aux mises à jour, puis sélectionnez Submit for review.
7. Si le plugin pointe vers un serveur MCP distant que vous exploitez, créez une soumission MCP connector distincte pour ce serveur.

Le dépôt peut rester privé pendant la validation et l’examen, à condition de respecter les exigences d’accès GitHub et d’envoi du code source d’Anthropic. Il devra être public avant la mise en ligne du plugin.

Choisir la bonne fiche avant d’ouvrir le portail

Plugin et connecteur sont liés, mais ne sont pas interchangeables. Imaginez le plugin comme un manuel d’exploitation prêt à l’emploi, et le serveur MCP distant comme le service opérationnel qui se trouve derrière. Le premier apprend le workflow à Claude ; le second lui donne un accès direct à votre produit ou à vos données.

Un skill ne constitue pas un troisième type de soumission : il doit être inclus dans un plugin bundle. Si ce bundle référence votre serveur MCP hébergé, soumettez les deux produits depuis la même organisation Claude et faites-les pointer vers la même URL de serveur. Le portail pourra ainsi associer les fiches, sans présenter aux utilisateurs des jeux d’outils en double.

Déterminer qui sera propriétaire de la fiche

Le choix de l’organisation engage durablement le produit : ce n’est pas un simple réglage administratif. Pour un plugin bundle, la première organisation qui soumet un dossier de dépôt devient propriétaire de la fiche. Une seconde organisation ne pourra pas soumettre le même dépôt et le même dossier.

Les règles liées au compte sont simples :

• Avec Pro ou Max, la soumission s’effectue depuis votre propre compte.
• Avec Team ou Enterprise, un Owner peut soumettre le plugin.
• Avec Enterprise, un Owner peut accorder l’autorisation Directory au moyen d’un rôle personnalisé.
• Le compte GitHub connecté au sein de cette organisation Claude doit pouvoir envoyer des modifications vers le dépôt.

Si une agence développe le plugin mais que son identité publique doit appartenir au client, c’est l’organisation du client qui doit le soumettre. Transférer le dépôt plus tard ne revient pas à transférer la fiche de l’annuaire.

Combien coûte cette publication ?

Les instructions publiques d’Anthropic ne mentionnent pas de frais propres à la présence dans l’annuaire. En revanche, un compte Free ne peut pas effectuer de soumission. Le coût minimal correspond donc à l’abonnement payant nécessaire pour accéder au portail.

• Un développeur indépendant sans abonnement payant peut choisir Pro à $20 pour un mois facturé mensuellement, ou à $17 par mois avec $200 réglés d’avance pour une année.
• Team commence à deux personnes. Deux licences standard coûtent $50 pour un mois facturé mensuellement, ou $40 par mois avec une facturation annuelle.
• Max commence à $100 par mois, mais cette offre n’est pas nécessaire pour soumettre un plugin.

Le principal investissement reste le travail de mise en production. Un produit hébergé demande deux soumissions préparées : l’une pour le bundle, l’autre pour le connecteur. Le plugin doit aussi disposer d’un manifeste stable, d’un README d’au moins 40 mots, d’une licence, de réponses sur le traitement des données, d’un contact pour l’examen et d’un dépôt qui pourra devenir public. En regroupant la validation, les résultats d’analyse, le statut d’examen, la publication, les mises à jour et les statistiques, le nouveau portail allège la coordination. Il ne supprime pas le travail à fournir.

Préparer un Claude Code plugin conforme à l’annuaire

Voici la structure minimale d’un bundle crédible :

your-plugin/
  .claude-plugin/plugin.json
  skills/your-workflow/SKILL.md
  README.md
  LICENSE

Le manifeste doit contenir un name permanent en minuscules, un displayName destiné aux utilisateurs, une version, une description utile, un auteur et une déclaration de licence ou un fichier de licence séparé. Choisissez soigneusement le nom permanent. Le displayName peut évoluer, mais le nom inscrit dans le manifeste constitue l’identité du plugin.

Le README ne se résume pas à l’entretien du dépôt : l’annuaire s’en sert pour construire la fiche et bloque à la validation tout plugin dont le README compte moins de 40 mots hors code. Expliquez la fonction du plugin, son mode d’emploi et les données qu’il transmet. Ne placez jamais de véritables identifiants dans le dépôt.

Si le bundle référence un serveur distant, inscrivez son endpoint HTTPS dans .mcp.json. N’y mettez aucune clé API : chaque personne qui installe le plugin reçoit ses fichiers.

Tester en local, puis valider de nouveau dans le portail

La validation locale détecte les fichiers de plugin incorrects avant même l’étape GitHub :

claude plugin validate ./your-plugin
claude --plugin-dir ./your-plugin

La première commande vérifie la syntaxe et le schéma des fichiers. La seconde lance une session Claude Code avec le dossier de travail chargé, afin de tester ses skills et ses commandes. Cette vérification locale ne remplace pas le bouton Validate du portail. Celui-ci contrôle également les règles de l’annuaire, l’organisation du dépôt, les conflits de noms, la politique applicable aux fichiers et d’autres exigences de soumission.

Pour ce guide, un petit plugin release-note-builder a été créé avec un skill et trois fichiers de tickets fictifs : un nouvel export CSV du journal d’audit, une pagination améliorée et la correction d’un doublon d’adresse e-mail. Claude Code 2.1.283 a renvoyé Validation passed, avec le code de sortie 0, sans erreur ni avertissement.

Le dossier a ensuite été chargé avec claude --plugin-dir pour un essai sur ces données. La machine ne disposait d’aucune session Claude authentifiée : la requête s’est donc arrêtée sur Not logged in · Please run /login avant tout appel de modèle. Aucune note de version générée n’a pu être observée. La limite est importante : la validation du dossier fonctionne en local, mais le test du comportement exige un accès authentifié au modèle. Pour une méthode plus complète, consultez le guide dédié aux évaluations de plugins Claude Code.

Remplir la soumission du plugin

La documentation publique décrit un parcours en six étapes concrètes.

1. Source

Saisissez le dépôt GitHub sous forme d’URL ou avec la notation owner/repo. Si le plugin se trouve dans un sous-dossier, ajoutez son chemin. Sélectionnez la branche ou le tag qui servira aux prochaines versions, ou laissez le champ vide pour suivre la branche par défaut. Cliquez ensuite sur Validate.

La validation porte sur un seul commit. Après l’envoi d’un correctif, choisissez Re-validate pour que le rapport analyse le nouveau commit.

2. Détails de la fiche

Le portail construit la fiche à partir de plugin.json et du README. Si le nom, la description ou les explications sont incorrects, modifiez les fichiers du dépôt, puis relancez la validation. Cette contrainte est saine : la promesse publique reste alignée sur le package réellement livré.

3. Traitement des données

Indiquez si le plugin lit ou conserve des données personnelles, transmet des données en dehors des connecteurs déclarés, garde certaines informations ou cible des personnes de moins de 18 ans. Ces réponses font partie du contrat produit ; ce ne sont pas de simples cases à remplir.

4. Conformité et contact

Fournissez une adresse e-mail qu’Anthropic pourra utiliser pendant l’examen, puis validez les quatre déclarations obligatoires. Le portail peut renvoyer une version avec des constats ou des modifications demandées : choisissez donc une boîte de réception réellement surveillée.

5. Mises à jour

Choisissez le webhook déclenché par défaut lors d’un push GitHub, ou uniquement les vérifications planifiées. Dans les deux cas, l’annuaire peut surveiller la branche ou le tag sélectionné. La mise en place du webhook exige des droits d’administration sur le dépôt.

6. Vérification et envoi

Contrôlez les informations, puis sélectionnez Submit for review. Une organisation peut créer jusqu’à 10 soumissions en 24 heures ; les brouillons et les soumissions retirées entrent dans ce décompte. Ne créez pas de doublon si votre intention est simplement de reprendre un brouillon existant.

Soumettre séparément le serveur MCP Claude distant

Si votre plugin appelle un serveur MCP distant que vous exploitez, revenez à Submit new et sélectionnez MCP connector. Ce parcours demande davantage d’informations opérationnelles, car Anthropic référence un service en ligne, et non un simple dossier.

Préparez l’URL du serveur, les URL de la documentation et de la politique de confidentialité, une icône, des identifiants de test pour l’équipe d’examen, ainsi que les éventuelles images du carrousel MCP App. Le parcours documenté couvre la connexion, les outils synchronisés, la fiche publique, les cas d’usage, l’entreprise, l’authentification, le traitement des données, les consignes de test, la conformité et l’examen final.

Les champs de la fiche publique comprennent un nom de serveur limité à 100 caractères, une description sur une ligne limitée à 200 caractères, une description longue limitée à 2,000 caractères, une à cinq catégories, ainsi que la documentation, la politique de confidentialité, l’assistance, l’icône et un slug d’URL permanent. Lorsque le produit l’exige, l’équipe d’examen doit également disposer d’un compte de test déjà alimenté. Ne considérez pas un connecteur comme prêt au seul motif que son endpoint de disponibilité répond : testez chaque outil avec MCP Inspector ou comme connecteur personnalisé dans Claude.

Lire chaque statut comme la prochaine action à mener

Aucun délai d’examen n’est garanti. La bonne question n’est donc pas « Combien de temps l’examen prendra-t-il ? », mais « À qui revient la prochaine action ? ».

Le statut Approved ne signifie pas que le plugin peut être installé ; seul Published le garantit. Avec le réglage par défaut, la publication d’une version validée peut encore dépendre d’un membre de l’équipe d’examen d’Anthropic. Certains plugins peuvent ensuite être configurés pour publier automatiquement les mises à jour qui passent les contrôles, mais toute version mise en attente doit toujours patienter.

Prévoir les mises à jour avant le premier lancement

Après la publication, fusionnez vos changements dans la branche suivie ou déplacez le tag surveillé. L’annuaire lit le nouveau commit, le valide, l’analyse sur le plan de la sécurité et l’affiche comme une nouvelle version. Incrémentez la version dans plugin.json à chaque publication.

Une mise à jour en échec ou en attente ne désactive pas la fiche fonctionnelle. L’annuaire continue de distribuer la dernière version publiée jusqu’à ce que sa remplaçante soit mise en ligne. La branche devient ainsi un flux de publication, et pas seulement l’emplacement du code source.

L’onglet Usage referme ensuite la boucle de retour. Pour une période allant jusqu’à 90 jours, il peut afficher les installations, les comptes actifs, la rétention, la répartition des versions, l’utilisation des composants, les erreurs de chargement, les appels MCP et leur latence, les vues de la fiche, les clics d’installation et les installations. Les chiffres sont actualisés une fois par jour en UTC et peuvent être exportés en CSV. N’annoncez aucun volume d’installations avant que le portail n’en ait réellement enregistré.

Les six équipes qui en tireront le plus de valeur

1. Les équipes SaaS dotées d’un produit MCP distant

L’équipe produit soumet le serveur en ligne comme connecteur, puis construit autour de lui un skill de workflow distribué sous forme de plugin. Les clients obtiennent à la fois l’accès aux outils et les instructions qui les rendent utiles. L’équipe suit la disponibilité du serveur et l’utilisation des outils côté connecteur, puis les installations et l’usage des composants côté plugin.

2. Les éditeurs de logiciels de workflow

Une plateforme de gestion des dépenses, de recrutement, de support ou de vente peut transformer sa meilleure procédure opérationnelle en skill et l’associer au connecteur du produit. Le bénéfice se mesure à la qualité de l’adoption : l’utilisateur ajoute un workflow, pas une collection de méthodes API dépourvues d’explications.

3. Les mainteneurs de plugins open source

Un mainteneur peut laisser le code public, suivre la branche de publication et utiliser le portail comme fiche stable et canal de mise à jour. La dernière version validée reste disponible pendant la correction d’un nouveau commit, ce qui évite d’exiger que chaque push soit immédiatement prêt pour les utilisateurs.

4. Les agences qui livrent des plugins à leurs clients

Une agence peut construire et tester le dossier, mais l’organisation du client doit effectuer la soumission si la fiche doit appartenir à ce dernier. La transmission est alors plus nette : le contrôle du dépôt, la propriété dans l’annuaire, le contact d’assistance et les statistiques reviennent à l’acheteur plutôt qu’au prestataire.

5. Les équipes plateforme en entreprise

Un Owner Enterprise peut attribuer l’autorisation Directory à certains membres au lieu de partager un rôle de propriétaire beaucoup plus large. L’équipe sépare ainsi les tâches de publication de l’administration générale de l’organisation, tout en conservant la fiche au sein de l’organisation de l’entreprise.

6. Les créateurs d’outils Claude Code qui visent au-delà du terminal

Une commande ou un skill peut rejoindre l’annuaire général, à condition de vérifier au préalable sa compatibilité avec chaque interface. Les skills fonctionnent dans le chat, Cowork et Claude Code. Les agents et les hooks ne fonctionnent pas dans le chat ; les serveurs MCP locaux non plus ; les serveurs LSP restent réservés à Claude Code. Cette vérification évite de promettre une expérience uniforme sur toutes les interfaces lorsqu’un package ne peut pas réellement la fournir.

Trois produits à développer autour du portail

1. Plugin Release Gate, l’opportunité la plus solide

Créez un contrôle GitHub qui inspecte un plugin avant que sa branche de publication n’atteigne le portail. Il lancerait la validation locale, vérifierait le README et la licence, signalerait les combinaisons de composants non prises en charge, comparerait la version du manifeste et produirait un rapport de conformité à l’annuaire.

La demande est déjà visible : claude code plugins génère environ 5,400 recherches mensuelles aux États-Unis, avec une intention commerciale et un CPC de $6.22. La plus petite version commercialisable prendrait la forme d’une GitHub App accompagnée d’un rapport web et d’un badge de dépôt. Une limite doit toutefois être clairement posée : l’outil ne peut pas garantir honnêtement l’approbation du portail, car les contrôles de l’annuaire Anthropic et l’examen humain vont plus loin que la commande locale. Sa valeur consiste à réduire les échecs évitables, pas à promettre une validation.

2. Directory Listing Optimizer

Créez une couche de reporting qui importe l’export CSV du portail et transforme les vues, les clics d’installation, les installations, les sources de découverte, les versions et l’utilisation des composants en recommandations pour les prochaines publications et pour la fiche. Le client type est un éditeur de plugin dont le trafic suffit à rendre les données quotidiennes exploitables.

claude plugins génère environ 8,100 recherches mensuelles aux États-Unis, avec une intention commerciale et un CPC de $9.05. Un MVP doit proposer l’import CSV, le calcul du tunnel, la comparaison des versions et une liste d’actions hebdomadaire. Sa limite est le démarrage à froid : avant la publication et les premiers usages réels, le produit ne dispose d’aucune donnée propriétaire à analyser. Il dépend aussi d’un export, faute d’API d’analytics documentée.

3. Cross-Surface Plugin Auditor

Créez un analyseur statique qui indique précisément ce que Chat, Cowork et Claude Code chargeront depuis un même dossier de plugin. Il doit signaler un dossier bin/ à la racine, les hypothèses liées à un MCP local, les agents et hooks ignorés par le chat et les LSP réservés à Claude Code, puis générer une matrice de test.

claude-plugins marketplace génère environ 1,900 recherches mensuelles aux États-Unis, avec une difficulté de 16 et une intention commerciale. Le MVP est un analyseur de dépôt fondé sur le tableau de compatibilité d’Anthropic. Sa limite tient à la maintenance : la prise en charge des plateformes évoluera, et les développeurs exclusivement centrés sur le terminal ne chercheront pas forcément une compatibilité plus large.

Le release gate représente le meilleur pari, car il intervient à chaque version, et pas seulement lors de la première fiche. Il complète en outre le portail au lieu de chercher à le remplacer.

Ce que le portail ne résout pas

Il ne rend pas un plugin médiocre utile. La validation peut confirmer que les fichiers sont bien formés et conformes aux règles, mais elle ne peut pas prouver qu’un skill améliore les résultats. Elle ne garantit pas non plus un comportement identique des composants dans chaque application Claude. Enfin, elle ne fournit ni délai d’examen fixe, ni label Verified sur demande, ni audience garantie le jour du lancement.

Le portail ne réduit pas non plus un produit MCP hébergé à une fiche unique. La soumission séparée du connecteur est volontaire : l’authentification du serveur, sa disponibilité, ses outils et sa politique nécessitent leur propre dossier opérationnel.

L’expérience de découverte unifiée est encore déployée progressivement au cours des semaines qui suivent le lancement du 25 septembre. Publiez pour les interfaces déjà documentées et considérez l’élargissement de la découverte comme une distribution à venir, pas comme une portée actuelle que vous pourriez promettre.

Ce qu’il faut faire lundi

Choisissez l’organisation Claude qui doit posséder la fiche. Placez un workflow réel dans un plugin bundle, attribuez-lui un nom de manifeste stable, un README utile et une licence, puis lancez la validation locale. S’il appelle votre serveur MCP hébergé, préparez en parallèle la soumission du connecteur. N’ouvrez le portail qu’une fois la propriété et le chemin du dépôt définitivement arrêtés.

Pour faire construire un plugin et son connecteur de production comme un seul système de publication fiable, découvrez les systèmes d’IA en production.