Agent Plugins : le nouveau standard ouvert pour les extensions d'agents IA

Ce qu'Agent Plugins est réellement

Je construis des intégrations pour gagner ma vie, donc ma première réaction face à tout nouveau standard est de vérifier quelle part relève d'une vraie spécification et quelle part relève du communiqué de presse. Celui-ci, c'est surtout une spécification.

Agent Plugins se décrit comme un standard ouvert et neutre vis-à-vis des fournisseurs pour empaqueter des composants réutilisables qui étendent les agents IA. En pratique, il standardise une seule chose : la forme du dossier. Où se trouve le manifeste, quels champs il peut contenir, où un client doit chercher les skills, et où il doit chercher la configuration du serveur MCP. Tout le reste, y compris l'installation, les marketplaces, les permissions et toute l'expérience utilisateur, reste entre les mains de chaque client.

Le plus petit plugin qui fait quelque chose tient en trois fichiers :

hello-plugin/
├── plugin.json
└── skills/
    └── greet/
        └── SKILL.md

Et le manifeste peut tenir en deux lignes :

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "hello-plugin"
}

C'est tout. $schema et name sont les seuls champs obligatoires. Tout le reste, version, description, author, homepage, repository, license, keywords, extensions, est optionnel.

Le problème résolu est ennuyeux mais bien réel. Chaque client d'agent a développé son propre format de plugin, si bien que la même skill devait être réorganisée pour chaque client, et un paquet construit pour l'un devait être adapté avant qu'un autre puisse le charger. Si vous avez déjà maintenu le même SKILL.md dans quatre structures de dépôt différentes, vous connaissez déjà la forme de cette douleur. C'est la même fragmentation qui rendait pénible de raisonner sur les plugins ChatGPT et les GPTs et Actions il y a quelques années, sauf qu'il y a maintenant plus de clients.

Ce qui entre dans un plugin, et ce qui n'y entre pas

La version 1 définit exactement deux types de composants. Les skills et les serveurs MCP. C'est un nombre délibérément restreint, et c'est la décision de conception la plus intéressante de tout le document.

Les deux se trouvent à des emplacements fixes que le manifeste n'a pas le droit de modifier. Les skills vont dans skills/, un sous-répertoire par skill, contenant un SKILL.md. La configuration MCP va dans mcp.json à la racine. La spécification précise explicitement qu'un client ne doit pas récurer plus profondément à la recherche de skills supplémentaires, et ne doit pas accepter de configuration MCP déclarée en ligne dans plugin.json.

Pour le format de SKILL.md lui-même, la spécification s'en remet entièrement à un autre document : les skills doivent être conformes à la spécification Agent Skills, qui reste la source de vérité pour le frontmatter et la structure scripts/, references/ et assets/. Agent Plugins dit seulement où les trouver.

Voici ce qui voyage et ce qui ne voyage pas :

Tout ce qu'un client souhaite ajouter de son côté va dans un espace de noms en domaine inversé, soit comme clé sous extensions dans le manifeste, soit comme répertoire de premier niveau nommé com.example.client/. Les autres clients sont tenus d'ignorer les espaces de noms qu'ils n'implémentent pas, sans même en valider le contenu. C'est une petite règle aux grandes conséquences : un plugin peut transporter des extras spécifiques à un client tout en continuant de se charger proprement partout ailleurs.

Le volet MCP a plus de mordant que je ne l'attendais. Trois transports sont reconnus, stdio, streamable-http et le sse déprécié, et un client conforme doit prendre en charge au moins l'un des deux premiers. Les points de terminaison distants doivent utiliser HTTPS, sauf si l'hôte est en loopback. Chaque sous-processus stdio reçoit les variables d'environnement PLUGIN_ROOT et PLUGIN_DATA, et ${PLUGIN_ROOT} et ${PLUGIN_DATA} s'étendent dans args, env et cwd, mais nulle part ailleurs. Le confinement des chemins est appliqué partout, si bien qu'un command du type ../bin/server est invalide, et pas simplement déconseillé.

L'isolation des pannes est la partie sur laquelle je m'appuierais vraiment en production. Une entrée MCP défaillante désactive ce serveur, pas le plugin. Un SKILL.md mal formé fait sauter cette skill, pas le dossier. Un plugin qui échoue la validation de schéma du manifeste est en revanche rejeté purement et simplement, et aucun de ses composants ne s'exécute. Ces frontières sont détaillées une par une, ce qui est bon signe : cela a été écrit par des gens qui ont déjà livré ce genre de choses. Quiconque a déjà débogué une intégration MCP à moitié chargée appréciera cette précision.

Quelles parties de votre extension voyagent réellement

Plutôt que de redécrire la répartition, voici la même information à explorer vous-même. Choisissez un composant et voyez s'il survit à un déplacement entre clients.

Qui est vraiment derrière

Les standards vivent ou meurent selon leur gouvernance, c'est donc la section que je lis en premier.

Le Technical Steering Committee compte cinq personnes, chacune nommée en tant qu'individu avec une affiliation associée, plutôt que comme un siège détenu par une entreprise :

L'annonce de Vercel crédite un groupe un peu plus large, citant Amazon Web Services, Anysphere, GitHub, Microsoft, OpenAI et Vercel comme ayant développé le standard ensemble.

La charte comporte trois clauses qui méritent d'être lues deux fois. Aucun fournisseur ne peut contrôler la majorité des sièges de Core Maintainer. Tous les rôles de gouvernance sont occupés par des individus, et aucun siège n'est réservé aux entreprises. Et le nom, les logos, les domaines et les organisations GitHub sont détenus en fiducie par une entité neutre désignée par le comité, sans qu'aucun fournisseur ne puisse revendiquer un contrôle exclusif de l'identité du projet.

Les preuves documentaires confirment tout cela. Le dépôt a été incubé sous vercel-labs/open-plugin-spec et se trouve désormais sous une organisation distincte, agentplugins, le texte de la spécification étant sous CC-BY-4.0 et le code sous Apache 2.0. Si l'affirmation de neutralité venait un jour à ne plus tenir, la licence signifie que le projet reste forkable plutôt que capturable. C'est à peu près le même scénario que celui suivi par l'industrie avec le travail sur l'agentic commerce protocol, et c'est un meilleur signal qu'un communiqué de consortium sans dépôt derrière.

L'absence en forme d'Anthropic

Anthropic n'apparaît pas sur la liste des mainteneurs, et Claude Code ne figure pas parmi les clients de lancement cités par Vercel. Cela mérite qu'on s'y attarde, car Claude Code est l'endroit où se fait actuellement une très grande part de la création réelle de plugins, et parce qu'Agent Skills y a commencé.

Les formats sont proches mais pas compatibles. La structure de plugin documentée d'Anthropic place le manifeste dans .claude-plugin/plugin.json et la configuration MCP dans .mcp.json, deux chemins cachés, là où Agent Plugins utilise des plugin.json et mcp.json visibles à la racine. Claude Code embarque aussi des types de composants que le standard ne couvre pas du tout, et la même forme réapparaît dans le format du plugin Cowork et dans les plugins IDE.

Ce sont des différences de chemin de fichier, le type d'incompatibilité le plus facile à corriger qui soit. Un plugin pourrait dès aujourd'hui embarquer les deux manifestes sans grand drame. Mais tant que personne n'aura fait ce travail, un auteur ciblant les deux écosystèmes continuera de maintenir deux structures, ce qui est précisément le problème que le standard cherchait à éliminer. Je ne lirais pas cette absence comme un rejet, et il n'existe de déclaration publique dans aucun sens. Je la lirais comme quelque chose d'inachevé.

Il vaut la peine de noter que le même schéma se répète ailleurs. Atlassian propose les skills d'agent Rovo, ServiceNow propose ses propres skills d'agent, et Freshworks propose une bibliothèque de skills préconstruites. Aucun d'eux n'entre dans le périmètre d'une spécification pensée pour les agents de codage, mais c'est la même idée empaquetée de cinq façons différentes, ce qui en dit long sur le stade précoce où en est tout cela.

Ce que la version 1.0.0 laisse délibérément de côté

C'est la section que je voudrais qu'un relecteur sécurité lise avant que quiconque installe quoi que ce soit.

Les mainteneurs sont d'une franchise rafraîchissante sur les lacunes. Un document dédié future considerations liste, parmi ce que la v1.0.0 ne définit pas :

• Un modèle de confiance, un système de permissions ou du sandboxing. Aucune déclaration de capacités, aucun flux de consentement, aucun niveau de confiance graduel.
• La vérification de provenance. Aucune vérification de signature, aucune attestation reliant un plugin publié à son dépôt source.
• La gestion des secrets. La spécification interdit les identifiants dans env et dans les headers HTTP, et n'offre aucune alternative portable.
• Les contrôles d'entreprise. Aucune liste d'autorisation, aucune liste de blocage, aucun registre à l'échelle de l'organisation, aucune surcharge de politique centralisée.
• Les pistes d'audit. Aucun schéma d'événement standard pour l'installation, l'activation, la mise à jour ou la désinstallation.
• La résolution de dépendances. Les plugins ne peuvent pas déclarer de dépendances envers d'autres plugins.

La spécification comporte bel et bien de vraies règles de sécurité là où elle le peut : les chemins doivent rester dans la racine du plugin, les points de terminaison MCP non-loopback doivent utiliser HTTPS, les en-têtes configurés ne doivent pas être transmis à travers une redirection vers une origine différente sans autorisation explicite de l'utilisateur, et les clients ne doivent pas récupérer un schéma sur le réseau pendant le chargement d'un plugin. Tout cela est sensé. Mais tout cela porte aussi entièrement sur le paquet, pas sur ce que ce paquet a ensuite le droit de faire.

La lecture honnête est donc la suivante. Agent Plugins résout la distribution. Il ne résout pas la confiance. Un serveur MCP à l'intérieur d'un plugin peut lancer un processus arbitraire avec votre environnement, et le standard ne dit rien sur le fait de savoir si cela devrait être autorisé. Que ce soit acceptable ou non dépend entièrement du client dans lequel vous l'installez et des contrôles de permissions que ce client se trouve embarquer. Côté Claude Code, cela signifie les contrôles administrateur et le settings.json ; ailleurs, cela signifie ce que ce fournisseur a décidé.

Ce que cela signifie si vous achetez des agents IA plutôt que de les construire

La plupart des lecteurs d'un article sur une spécification de plugins sont des développeurs. Mais l'effet de second ordre touche quiconque évalue des agents IA pour une fonction métier, et le support est le cas le plus net.

L'argument de vente d'un format de plugin portable est que votre extension n'est pas l'otage d'un seul fournisseur. C'est vrai, et c'est une bonne raison de préférer les clients qui l'adoptent. C'est aussi plus étroit que ce que cela laisse entendre, car la portabilité du paquet n'est pas la portabilité du résultat. Que votre SKILL.md se déplace proprement entre deux clients ne signifie pas que l'agent se comporte de la même façon dans les deux, qu'il dispose des mêmes permissions d'outils, ou qu'il résout la même proportion de tickets. Ce dernier chiffre est celui qui finance le projet, et c'est sur cela qu'un agent IA pour le service client est réellement jugé.

Je vois le même raisonnement revenir constamment dans les discussions construire ou acheter. Un responsable ingénierie avec qui nous avons travaillé a résumé le calcul mieux que je ne saurais le faire :

"We could try to write our own LLM application but we didn't want to invest our time into that. We wanted something that we would not have to maintain."

Karel, GENERAL BYTES

C'est un responsable ingénierie qui gère une base de connaissances de plus de 300 articles dans Confluence et Telegram, et qui a choisi d'acheter plutôt que de construire. Un standard réduit le coût de l'assemblage des pièces. Il ne fait rien pour le coût continu de possession du résultat, et c'est précisément là que ces projets deviennent vraiment coûteux.

Les trois questions que je poserais à n'importe quel fournisseur, standard ou pas :

1. Puis-je exporter ce que je lui ai appris ? Les prompts, les règles, la logique d'escalade. Si la réponse est non, un format de plugin portable ne change rien à votre lock-in.
2. Qui décide de ce qu'il peut toucher ? Comme la v1 ne définit aucun modèle de permissions, c'est une réponse propre à chaque client, et vous devriez l'obtenir par écrit avant que quoi que ce soit n'atteigne une file d'attente en production. Pour les équipes soumises à des réglementations, cela s'intègre directement dans votre revue de confidentialité des données.
3. Puis-je le tester sur mon propre historique avant sa mise en production ? Une simulation sur des scénarios écrits par quelqu'un n'équivaut pas à un essai réel sur vos propres tickets passés.

Cette troisième question est celle sur laquelle je ne transigerais pas. Nous avons vu un bot au ton assuré donner tranquillement de mauvaises réponses, ce qui explique exactement pourquoi chaque déploiement chez eesel est d'abord simulé sur des tickets historiques, plutôt qu'activé et observé sans plus de précaution.

Essayez eesel pour un support qui se branche sur ce que vous utilisez déjà

eesel reprend la même idée que poursuit Agent Plugins, vous rencontrer là où vous travaillez déjà, et l'applique au helpdesk. Il se connecte à Zendesk, Freshdesk et Gorgias, ainsi qu'à Slack, Confluence et le reste de votre base de connaissances interne, puis rédige ou résout à partir de ce qu'il y apprend.

L'élément différenciant est la troisième question ci-dessus. Avant qu'eesel ne réponde au moindre ticket en production, vous le faites tourner sur votre propre historique de tickets et voyez ce qu'il aurait dit, sur quels tickets, avec quel niveau de confiance. Vous choisissez ensuite quels types de tickets il est autorisé à toucher. C'est gratuit à essayer, et la mise en place se fait en quelques minutes plutôt qu'en un trimestre.

Et la suite

Ma lecture après une journée passée avec la spécification : le format est assez petit pour être adopté rapidement, la gouvernance est plus solide que celle de la plupart des standards à leur première version, et l'histoire de la sécurité est un trou délibéré assorti d'une feuille de route. Une spécification minimale qui sort l'emporte sur une spécification exhaustive qui se dispute encore, et Agent Plugins est clairement la première catégorie.

Les deux choses que je surveillerais. Si Anthropic converge, sachant que l'écart tient essentiellement à deux chemins de fichiers et à l'équivalent des types de composants supplémentaires d'un écosystème entier. Et si la v1.1 apporte un modèle de permissions avant que quelqu'un ne livre un plugin qui fasse regretter à tout le monde qu'elle n'existe pas encore.

Si vous êtes en train de choisir des outils d'agent IA, qu'il s'agisse d'un agent de codage comme Cursor ou d'une CLI agentique, traitez la prise en charge d'Agent Plugins comme un signal légèrement positif sur la posture d'un fournisseur face au lock-in. Puis traitez ses réponses sur les permissions et les tests comme ce qui décide réellement de la question.