Agent Plugins 1.0 : un format de paquet unique pour tous les agents IA

Qu’est-ce qu’Agent Plugins ? Agent Plugins 1.0 est un standard d’empaquetage ouvert et indépendant de tout fournisseur — publié le 6 août 2026 — qui regroupe les Agent Skills et les configurations de serveurs MCP dans un dossier portable que n’importe quel client d’agent compatible peut charger. Un plugin est un dossier contenant un manifeste plugin.json obligatoire, un dossier skills/ optionnel rassemblant des Agent Skills, et un fichier mcp.json optionnel déclarant des serveurs MCP. ChatGPT, Codex, Cursor, GitHub Copilot, Kiro et VS Code le prennent en charge dès son lancement.¹²

Six entreprises qui se font concurrence au quotidien ont livré une réponse commune à un problème que tout utilisateur d’agent a déjà ressenti : l’extension que vous avez conçue pour un client d’agent ne fonctionne pas dans le suivant. Vercel a lancé la proposition et développé la spécification avec Amazon, Anysphere (l’éditeur de Cursor), GitHub, Microsoft et OpenAI² ; le même jour, Google annonçait rejoindre les mainteneurs principaux et intégrer la prise en charge à ses propres produits.⁶ Le résumé en une ligne du site officiel : « un format de paquet portable pour des composants réutilisables qui étendent les agents IA ».¹

Le nom de l’entreprise qui a créé les deux couches ainsi empaquetées ne figure pas sur la liste des mainteneurs. Cette absence constitue la moitié de l’histoire, et la seconde moitié de cet article.

TL;DR : Agent Plugins 1.0 normalise la couche d’empaquetage autour de deux spécifications existantes — Agent Skills et le Model Context Protocol — sans en remplacer aucune : il fixe l’emplacement des deux à l’intérieur d’un dossier partageable.¹ Un plugin est un dossier : plugin.json pour l’identité, skills/ pour les compétences, mcp.json pour les serveurs, plus des dossiers d’espace de noms en domaine inversé pour les ajouts propres à chaque client. La version 1 est délibérément un socle d’interopérabilité : la spécification ne définit aucune sémantique portable pour l’installation, les registres, les permissions, la provenance, les secrets ou OAuth ; tout cela reste à la charge du client.¹² Codex a livré la prise en charge entre les versions v0.146.0 et v0.147.0.⁴ Anthropic, qui a créé Agent Skills et MCP, ne figure pas parmi les mainteneurs — Claude Code conserve son propre format de plugin.³⁷⁸

Points clés

• Développeurs indépendants : rédigez vos compétences sous forme d’Agent Skills standard (un dossier avec un SKILL.md) et elles constituent déjà le substrat portable ; les envelopper dans un plugin ne demande qu’un manifeste. Cessez de maintenir une copie par client.
• Responsables d’équipe : le standard couvre l’empaquetage, pas la distribution ni la politique. Votre registre, votre mécanisme de mise à jour et votre gestion des listes d’autorisation restent des décisions propres à chaque client — prévoyez-le avant de promettre en interne un « écrire une fois, exécuter partout ».
• Ingénieurs sécurité : la version 1 ne définit ni couche de provenance, ni couche de permissions, ni couche de signature — la décision de confiance se déplace entièrement vers votre revue au moment de l’installation. La portabilité élargit le rayon d’impact des attaques par compétence empoisonnée.

Ce qui a été livré

Le 6 août 2026, Vercel a publié Agent Plugins 1.0.0, une spécification ouverte qu’elle a initiée et développée avec Amazon, Anysphere, GitHub, Microsoft et OpenAI.² La spécification normative réside dans un dépôt public dont la liste de mainteneurs couvre Amazon, Cursor, Microsoft, OpenAI et Vercel,³ et Google a annoncé le jour du lancement rejoindre ce groupe comme mainteneur principal, la prise en charge arrivant déjà dans son propre outillage d’agents.⁶

La liste des clients disponibles dès le premier jour couvre les plus grandes surfaces de l’écosystème : VS Code, Cursor, GitHub Copilot, ChatGPT et Codex, ainsi que Kiro.¹² La prise en charge dans le CLI de Codex a en réalité précédé l’annonce publique : la v0.146.0 (29 juillet) a ajouté les manifestes Agent Plugins et la publication de plugins d’espace de travail, et la v0.147.0 (7 août) a bouclé la boucle avec l’installation portable de plugins et la recherche dans les catalogues locaux, personnels, d’espace de travail et distants.⁴

La portée est énoncée dès la première ligne de la spécification : elle « définit la spécification canonique Agent Plugins v1.0.0 pour empaqueter, sous forme de plugins distribuables, des composants réutilisables qui étendent les agents IA ».¹ De l’empaquetage — pas un nouveau langage de compétences, pas un remplacement de MCP. Les deux formats sous-jacents conservent leurs propres spécifications ; ce standard fixe leur emplacement à l’intérieur d’un dossier qu’un client sait découvrir.

L’anatomie d’un plugin

Un plugin est un dossier composé d’un fichier obligatoire et de trois surfaces optionnelles :¹

my-plugin/
├── plugin.json              # required: identity + metadata
├── skills/                  # optional: Agent Skills
│   └── release-notes/
│       └── SKILL.md         # one immediate subdirectory = one skill
├── mcp.json                 # optional: MCP server configs
└── com.example.client/      # optional: client-namespace directory

plugin.json est un manifeste à schéma fermé. Les champs de premier niveau autorisés sont exactement au nombre de dix : $schema, name, version, description, author, homepage, repository, license, keywords et extensions — et la spécification se montre stricte pour tout le reste : « Les clients DOIVENT signaler et ignorer chaque champ inconnu et DOIVENT poursuivre le chargement du plugin si le manifeste satisfait par ailleurs cette section ».¹ Le champ name accepte les caractères alphanumériques minuscules, les traits d’union et les points, dont le premier et le dernier caractère sont alphanumériques, sans traits d’union ni points consécutifs.¹

skills/ accueille les Agent Skills exactement telles qu’elles existent déjà : « Chaque sous-dossier immédiat contenant un chemin nommé exactement SKILL.md qui pointe vers un fichier ordinaire est traité comme une compétence ».¹ mcp.json déclare les serveurs MCP ; un client qui prend en charge les serveurs MCP des plugins « DOIT prendre en charge au moins l’un des transports stdio ou streamable-http » et DEVRAIT gérer les deux, sse restant optionnel — et la spécification autorise explicitement un client limité aux compétences à être conforme sans prendre en charge le moindre serveur MCP.¹

Les dossiers en domaine inversé comme com.example.client/ accueillent les comportements propres à un client, la règle de portabilité étant écrite en langage normatif : « Un client DOIT ignorer les entrées de manifeste correspondant à des espaces de noms qu’il n’implémente pas, sans valider le contenu de leurs valeurs ».¹

Ce dernier mécanisme pèse plus lourd qu’il n’y paraît. Les composants qui diffèrent le plus d’un client à l’autre sont mis à l’écart du noyau portable : commandes, hooks, agents, règles et serveurs LSP sont les exemples que donne la spécification elle-même de types de composants qui « restent trop spécifiques à chaque client pour un contrat portable stable » et demeurent hors du format v1 tant que leurs formats n’auront pas convergé.¹ Le noyau portable, ce sont les compétences plus les configurations MCP, point final.

Ce que la version 1 laisse volontairement de côté

La spécification normalise la plus petite chose qui puisse fonctionner. Elle ne définit aucune sémantique portable pour l’installation, les registres, les permissions, la provenance, les secrets ou OAuth — chacun de ces points reste à la charge du client¹² — et elle ne définit pas davantage de couche de signature. La trajectoire d’extension retenue par les mainteneurs est conservatrice par choix : un type de composant n’entre dans le noyau portable qu’une fois les implémentations suffisamment convergentes pour le définir précisément.¹

Il faut y voir la physique d’une coalition plutôt que de la timidité. Six entreprises — dont cinq livrent des clients d’agents aux formats de plugins incompatibles — pouvaient s’entendre sur l’emplacement des fichiers ; elles ne pouvaient pas encore s’entendre sur le déclenchement des hooks, l’enregistrement des commandes ou le modèle de permissions qui l’emporte. Le standard a donc figé la couche où les comportements avaient déjà convergé (une compétence est un dossier markdown, MCP est un protocole de communication) et relégué tout ce qui reste disputé dans des espaces de noms. C’est un socle d’interopérabilité, et les socles sont utiles précisément parce que tout le monde peut s’y tenir.

Le prix de ce socle : le « construire une fois, exécuter partout » s’applique au paquet, pas à l’expérience. Un plugin s’installe partout ; ce qu’il peut faire varie toujours selon le client, et la manière dont il est installé, mis à jour et jugé digne de confiance dépend entièrement de ce dernier.

Le trou en forme d’Anthropic

Voici l’aspect le plus étrange. Agent Skills, ce format de dossiers d’instructions que le standard empaquette, est une création d’Anthropic annoncée en octobre 2025.⁸ Le Model Context Protocol aussi, qu’Anthropic a ouvert en logiciel libre en novembre 2024.⁷ Les deux couches placées sous ce standard d’empaquetage viennent du seul grand fournisseur d’outils d’agents dont le nom n’apparaît nulle part dans la liste des mainteneurs.³

Claude Code conserve son propre format de plugin — son manifeste, ses sources de marketplace, son empaquetage de hooks et de commandes — et rien de ce qui a été annoncé le 6 août ne change cela. La passerelle, pour l’instant, ne va que dans un sens : Codex embarque une source de marketplace Claude Code (v0.146.0), et sa commande /import fait migrer vers Codex les paramètres de Claude Code, les serveurs MCP, les plugins, les sessions, les commandes et les mémoires liées au projet.⁴

En pratique, la couture est plus fine que l’organigramme ne le laisse croire, et la raison tient au substrat : une compétence est un dossier accompagné d’un SKILL.md, dans tous les écosystèmes. Les compétences que vous écrivez pour Claude Code sont exactement l’artefact que transporte un Agent Plugin. Ce qui ne voyage pas, c’est l’emballage — le manifeste de plugin de Claude Code d’un côté, plugin.json de l’autre — ainsi que les composants propres à chaque client (les hooks avant tout) que chaque écosystème garde natifs. Si vous maintenez des compétences aujourd’hui, vous écrivez déjà la couche portable ; la divergence porte sur l’empaquetage, pas sur le contenu.

Reste la question ouverte que pose ce lancement : Anthropic finira-t-elle par adopter le format, publier un équivalent, ou laisser la passerelle à sens unique ? La composition de la coalition — tous les grands éditeurs de clients d’agents sauf un — fait dépendre la trajectoire de ce standard d’empaquetage moins de ses mérites techniques que d’une décision : l’auteur absent de ses deux couches sous-jacentes jugera-t-il que ce socle vaut la peine qu’on s’y tienne ?

La question de chaîne d’approvisionnement que personne n’a normalisée

Un format de paquet portable dépourvu de couche de provenance est aussi un format d’attaque portable. La version 1 laisse la provenance et les permissions à la charge du client et ne définit aucun outillage de signature ou de validation,¹ ce qui signifie que la décision de confiance se joue entièrement au moment de l’installation, client par client, utilisateur par utilisateur.

Cela compte davantage ce mois-ci que le mois dernier. Des travaux récents sur les attaques au niveau des compétences — ElasticBack en est l’exemple le plus net — démontrent la pose de portes dérobées conditionnelles dans un unique document de compétence, et décrivent les compétences d’agent comme « une chaîne d’approvisionnement émergente où une seule compétence empoisonnée peut compromettre durablement chaque agent qui l’installe ».⁵ La portabilité démultiplie le phénomène : le même plugin empoisonné s’installe désormais dans six clients au lieu d’un, et la portée du standard laisse la détection à la revue, quelle qu’elle soit, effectuée par chaque client (ou chaque utilisateur).

J’ai développé l’argument complet avant l’existence de ce standard dans Les compétences d’agent ont besoin de gestionnaires de paquets : le contexte d’agent est devenu une chaîne d’approvisionnement logicielle, et l’installer sans risque exige la machinerie que les écosystèmes de paquets ont déjà appris à construire — manifestes, fichiers de verrouillage, installations à portée limitée, garde-fous de revue, retour arrière. Agent Plugins 1.0 livre le manifeste et s’arrête là ; le reste de cette liste est précisément ce que la v1 laisse aux clients. Inspectez ce que vous installez ; le format ne le fera pas à votre place. (Un piège voisin, décrit dans Les compétences que mon agent ne voyait pas : les agents chargent les descriptions de compétences sous un budget de contexte strict, et les compétences livrées par un plugin rejoignent ce même catalogue — la portabilité ajoute des compétences à une file d’attente qui tronque déjà en silence.)

Ce qu’il faut faire aujourd’hui

Si vous utilisez Codex : vous disposez déjà du standard. codex plugin expose l’installation portable d’Agent Plugins, et la recherche de plugins couvre les catalogues locaux, personnels, d’espace de travail et distants depuis la v0.147.0.⁴ Les équipes peuvent publier des plugins dans leur propre espace de travail au lieu de monter une marketplace publique.

Si vous utilisez Claude Code : rien ne change dans votre format de plugin. Continuez à écrire vos compétences sous forme de dossiers de compétences standard — c’est la couche portable — et considérez l’emballage comme jetable. Si vous utilisez aussi Codex, sa source de marketplace Claude Code et sa commande /import transportent votre installation existante.⁴

Si vous utilisez VS Code, Cursor, Copilot, ChatGPT ou Kiro : vous figurez sur la liste des clients disponibles au lancement ; la manière dont les plugins s’installent relève de l’expérience utilisateur de votre client, car le standard ne la spécifie délibérément pas.¹

Si vous publiez des outils pour développeurs : le manifeste est assez petit pour être adopté en un après-midi, et le dépôt de la spécification est public.³ La décision intéressante n’est pas de savoir s’il faut lire plugin.json : c’est de choisir lesquels de vos composants vous reléguez dans votre espace de noms en domaine inversé, car cette frontière est la déclaration de fait de ce que vous considérez comme portable.

FAQ

Agent Plugins remplace-t-il MCP ou Agent Skills ?

Non. Le rôle affiché de la spécification est « d’empaqueter, sous forme de plugins distribuables, des composants réutilisables qui étendent les agents IA »¹ : les compétences conservent leur format SKILL.md, les serveurs MCP conservent leur protocole, et le standard fixe l’emplacement des deux à l’intérieur d’un dossier partageable.

Un plugin peut-il embarquer des hooks, des commandes slash ou des agents personnalisés ?

Pas de façon portable, pas en v1. La spécification cite les commandes, les hooks, les agents, les règles et les serveurs LSP comme exemples de types de composants qui « restent trop spécifiques à chaque client pour un contrat portable stable », donc hors du format portable tant que leurs formes n’auront pas convergé. Un client peut les transporter dans son dossier d’espace de noms en domaine inversé, et les clients DOIVENT ignorer les espaces de noms qu’ils n’implémentent pas.¹ Le noyau portable, ce sont les compétences plus les configurations MCP.

Pourquoi Anthropic ne fait-elle pas partie du standard ?

Ni la spécification ni la coalition ne l’ont dit. Ce qui est public : la liste des mainteneurs couvre Amazon, Cursor, Microsoft, OpenAI et Vercel, auxquels s’ajoute Google au lancement,³⁶ tandis qu’Anthropic — créateur à la fois d’Agent Skills et de MCP⁷⁸ — est absente, et que Claude Code conserve son propre format de plugin. La passerelle concrète se trouve aujourd’hui du côté de Codex : sa source de marketplace Claude Code et sa migration /import.⁴

Peut-on installer des Agent Plugins tiers en toute sécurité ?

Le format ne vous aide en rien à trancher : la version 1 laisse les permissions et la provenance à la charge du client et ne définit aucun outillage de signature ou de validation.¹ Traitez un plugin comme n’importe quel code auquel vous accordez vos privilèges. Les travaux sur les portes dérobées au niveau des compétences (ElasticBack) montrent qu’un seul document de compétence empoisonné peut compromettre de façon conditionnelle chaque agent qui l’installe, et la portabilité multiplie le parc installé.⁵

Références