Le 6 août 2026, un consortium qui réunit AWS, OpenAI, Microsoft, Vercel, Cursor et Google a publié la version 1.0.0 d'un standard baptisé Agent Plugins. Le principe tient en une phrase : un format commun pour empaqueter dans un seul dossier des Agent Skills et des serveurs MCP, avec les sous-agents et commandes qui vont avec. Fait notable, Anthropic ne figure pas parmi les mainteneurs de ce comité, alors même que le format Skills empaqueté est celui qu'Anthropic a cofondé fin 2025. Pour qui construit déjà sa stack IA autour de Claude Code et de MCP, c'est un basculement à comprendre avant de continuer à automatiser sa stack avec Claude et MCP, parce que le point de distribution des extensions n'est plus nécessairement un éditeur unique. Ce guide fait partie du guide complet pour apprendre Claude et se concentre sur ce que le format change concrètement dans ton workflow.
Ce qu'est un Agent Plugin, concrètement
Un Agent Plugin est un dossier avec une structure conventionnelle. Rien de magique, rien de nouveau côté runtime : c'est un format de distribution. Le manifeste plugin.json décrit le paquet (nom, version, description), et à côté vivent des sous-dossiers optionnels selon ce qu'on embarque : skills/ pour les fichiers SKILL.md, mcp.json pour la configuration des serveurs MCP, et par convention agents/ et commands/ pour les sous-agents et commandes slash.
mon-plugin/
├── plugin.json
├── skills/
│ └── audit-seo/
│ └── SKILL.md
├── mcp.json
├── agents/
│ └── redacteur-seo.md
└── commands/
└── audit-rapide.mdLe manifeste plugin.json et les dossiers skills/ et mcp.json sont ceux que documente officiellement la version 1.0.0 du standard. Les conventions agents/ et commands/, elles, reprennent l'usage déjà répandu côté Claude Code : leur inclusion formelle dans le standard multi-éditeurs n'est pas confirmée dans les sources disponibles à ce jour, traite-les comme une convention probable plutôt qu'une garantie.
La distinction avec un Skill seul ou un MCP seul est nette. Un Skill, c'est une instruction méthode : comment auditer une page, comment structurer une fiche produit. Un serveur MCP, c'est un pont vers un outil externe (HubSpot, Search Console, un CRM), donc de la capacité d'action. Le plugin, lui, ne remplace ni l'un ni l'autre : il les cohabite dans un même paquet versionné, distribuable, installable en une commande. Si tu débutes avec ces briques, la lecture des serveurs MCP disponibles pose les bases avant d'attaquer les plugins.
Pourquoi ce format change la donne pour votre stack
Avant les plugins, monter une stack Claude cohérente pour une équipe demandait de bricoler à la main. Un Skill copié dans un projet ici, un serveur MCP configuré via claude mcp add là, un sous-agent défini dans un fichier ailleurs, une commande slash oubliée sur le poste d'un collègue. Le tout à re-synchroniser à chaque nouvelle recrue ou à chaque évolution.
Le paquet unique change trois choses :
- Versioning cohérent. Tu bumps la version du plugin, tout suit : le Skill, la config MCP, les commandes. Plus de désynchronisation entre une méthode d'audit v2 et un serveur MCP resté en v1.
- Partage en équipe. Un dépôt Git avec un
marketplace.json, une commande d'installation, tout le monde tourne sur la même stack. - Indépendance vis-à-vis d'un éditeur. C'est le point le plus structurant. Le standard est ouvert, gouverné par un comité multi-éditeurs où aucun acteur ne peut détenir la majorité des sièges. Anthropic n'y siège pas à ce stade, ce qui veut dire deux choses. D'abord, aucune source vérifiée ne confirme aujourd'hui que Claude Code sait installer un paquet Agent Plugins comme client compatible : la compatibilité technique des fichiers Skills existants est plausible, mais elle n'est pas garantie. Ensuite, personne n'attend l'aval d'un éditeur pour héberger un marketplace de plugins.
Pour un opérationnel, ça signifie que la question n'est plus « quel marketplace officiel utiliser » mais « quel dépôt Git ai-je confiance à installer ». Ce déplacement du curseur, du contrôle éditorial vers l'audit côté client, mérite d'être pris au sérieux avant de sécuriser un agent qui touche à des données réelles.
Ce que tu peux installer aujourd'hui, et ce qui reste à confirmer
Attention à ne pas confondre deux choses. Claude Code a son propre système de plugins depuis plusieurs mois, avec ses commandes /plugin marketplace add et /plugin install, un format marketplace.json et des paquets qui embarquent déjà Skills, sous-agents, commandes slash et configuration MCP. C'est ce système existant, non lié au nouveau standard Agent Plugins du 6 août 2026, qui tourne concrètement dans ton terminal aujourd'hui :
/plugin marketplace add davila7/claude-code-templates
/plugin install audit-seo@claude-code-templatesLe client télécharge le paquet, active les Skills, enregistre la config MCP dans ta session, et rend les commandes slash disponibles. Tu retrouves le contenu installé dans le dossier de configuration de Claude Code, sous un répertoire plugins/ propre à ton profil. Ce format est conceptuellement proche de ce que le nouveau standard Agent Plugins ambitionne de généraliser à plusieurs éditeurs, mais aucune source vérifiée ne confirme à ce jour que les deux formats sont identiques ou interopérables : traite-les comme deux systèmes distincts tant qu'Anthropic n'a pas clarifié la question.
Deux dépôts communautaires reviennent souvent : davila7/claude-code-templates et wshobson/agents. Avant d'installer, applique les mêmes réflexes que pour n'importe quel paquet npm ou action GitHub : qui maintient le dépôt, depuis quand, combien de contributeurs, quelle fréquence de commits, quels serveurs MCP sont déclarés dans mcp.json. Un plugin qui embarque un serveur MCP inconnu accédant à des identifiants OAuth n'a pas la même surface de risque qu'un plugin qui expose une commande slash sur un Skill de rédaction.
| Type de brique | Ce que ça fait | Risque à auditer |
|---|---|---|
| Skill | Instruction méthode chargée par le modèle | Faible (texte statique) |
| Sous-agent | Rôle spécialisé, prompt système dédié | Faible à moyen |
| Commande slash | Raccourci vers un enchaînement | Moyen (peut lancer des outils) |
| Serveur MCP | Pont vers un outil externe | Élevé (accès données, secrets) |
Créer votre propre plugin pour votre équipe
Prenons un cas utile : un plugin audit-seo à usage interne. Il embarque une méthode d'audit sous forme de Skill, un serveur MCP pour interroger Search Console, un sous-agent « rédacteur SEO » qui reprend les recommandations, et une commande /audit-rapide pour lancer l'analyse d'une URL sans réécrire le contexte à chaque fois.
Le plugin.json minimal :
{
"name": "audit-seo",
"version": "0.1.0",
"description": "Audit SEO d'une URL, méthode maison + Search Console",
"skills": ["skills/audit-seo"],
"mcpServers": "mcp.json",
"agents": ["agents/redacteur-seo.md"],
"commands": ["commands/audit-rapide.md"]
}Le SKILL.md décrit la méthode d'audit (structure Hn, densité, intention, maillage interne). Le mcp.json déclare le serveur MCP Search Console avec ses variables d'environnement. Le sous-agent redacteur-seo.md contient le prompt système et les règles éditoriales. La commande audit-rapide.md orchestre le tout : appelle Search Console, applique la méthode, passe la main au sous-agent pour formuler les recommandations.
Pour tester en local avant de publier, place le dossier dans le répertoire des plugins locaux de Claude Code et charge-le en dev. Tu itères sur le Skill, tu bumps la version dans plugin.json, tu relances. Une fois stable, tu pousses sur un dépôt Git. Ce type de packaging s'inscrit dans la même logique que l'architecture d'un agent Claude bien découpé : chaque brique fait une chose, le paquet les compose.
Distribuer votre plugin : marketplace privé ou public
Un « marketplace » au sens Agent Plugins n'est pas une plateforme. C'est un dépôt Git avec un fichier marketplace.json qui liste les plugins disponibles, leur version, leur URL. Rien de plus.
{
"name": "ottho-internal",
"plugins": [
{ "name": "audit-seo", "version": "0.1.0", "source": "./audit-seo" },
{ "name": "brief-client", "version": "0.2.1", "source": "./brief-client" }
]
}Pour un marketplace privé d'équipe, un dépôt GitHub privé suffit. Tes collègues l'ajoutent via /plugin marketplace add git@github.com:ton-org/ottho-internal.git, ils installent les plugins qu'ils veulent, tu contrôles les accès au dépôt comme n'importe quel code source. Pour un marketplace public, la mécanique est identique, seule la visibilité change.
Sur la sécurité, garde deux règles en tête. Un plugin qui embarque un serveur MCP exécute du code capable d'accéder à tes données authentifiées : audite le code du serveur MCP autant que tu auditerais une dépendance dans ton package.json. Un plugin communautaire installé sans lecture est une porte ouverte, exactement comme le seraient des clés d'API Anthropic commitées par erreur dans un repo public. Sur les plans Enterprise, les Inference Hooks d'Anthropic peuvent inspecter les prompts avant qu'ils n'atteignent le modèle, ce qui donne une deuxième couche de contrôle indépendante du plugin lui-même.
Limites actuelles et ce qui reste flou
Le standard est en 1.0.0 depuis début août 2026, ce qui veut dire qu'il est jouable mais pas encore mature sur plusieurs points.
D'abord la compatibilité côté clients. Le comité de pilotage regroupe des éditeurs sérieux (AWS, OpenAI, Microsoft, Vercel, Cursor, Google), mais chaque client IA implémente le support à son rythme. Aucune source vérifiée ne confirme aujourd'hui que Claude Code sait lire un paquet plugin.json conforme au standard Agent Plugins tel que publié le 6 août 2026. Le format des Skills empaquetés est celui qu'Anthropic a cofondé, donc la compatibilité technique de fichiers SKILL.md existants est plausible sur le papier. Mais entre « techniquement compatible » et « installable en une commande dans Claude Code aujourd'hui », il y a un pas que les sources ne franchissent pas. Vérifie l'état du support dans ton client avant de miser une roadmap dessus.
Ensuite la découvrabilité. Il n'existe pas de moteur de recherche unifié des plugins disponibles. On tombe sur les dépôts par bouche-à-oreille, par listes communautaires, par explorations GitHub. C'est le stade « early npm » du format.
Enfin, la gestion des dépendances entre plugins n'est pas résolue. Deux plugins qui déclarent le même serveur MCP avec des configurations différentes, un plugin qui suppose qu'un autre est installé : ces cas d'usage remontent en Q&A mais n'ont pas de réponse standard dans la 1.0.0.
La recommandation concrète tient en trois lignes. Commence par un plugin interne minimal (un Skill + une commande slash), teste-le sur ton équipe pendant deux ou trois semaines, ajoute un serveur MCP quand la structure tient. Ne publie rien en dehors de ton organisation tant que tu n'as pas au moins une itération de retour d'usage. Et bloque du temps pour suivre l'évolution du support côté Claude Code, parce que la surface d'intégration va bouger dans les prochains mois.
Passer à la pratique
Le passage des Skills et MCP isolés au packaging plugin est le genre de bascule qui sépare une stack IA bricolée d'une stack partageable et versionnée. Si tu veux monter ce type d'outillage pour ton équipe avec un accompagnement, deux sessions live par semaine et un projet concret à la sortie, la formation Construire votre produit IA en 5 semaines couvre le cycle complet : setup, Skills, MCP, agents, distribution interne. C'est le chemin le plus direct pour arrêter de bricoler et commencer à packager.