OpenAI et les principaux groupes technologiques unifient le format des plugins d'agents IA

Le 6 août 2026, OpenAI, Microsoft, Amazon, Cursor et Vercel ont lancé Agent Plugins 1.0.0, visant à établir un format d'empaquetage universel pour les agents IA. Les développeurs peuvent regrouper dans un même répertoire les compétences d'agent — composées d'instructions d'opération, de scripts et de références — ainsi que des serveurs MCP connectés à des bases de données, des services cloud et des outils de développement ; théoriquement, un seul empaquetage suffit pour les utiliser sur des clients compatibles tels que ChatGPT, Codex, VS Code, Cursor, GitHub Copilot et Kiro. Il ne s'agit pas de résoudre les limites des modèles, mais la fragmentation croissante des formats dans l'écosystème des agents : actuellement, une même fonctionnalité nécessite souvent de créer des fichiers de liste distincts, de modifier les structures de répertoires et de maintenir plusieurs branches pour chaque produit. Toutefois, la spécification 1.0.0 est toujours marquée comme « projet de travail » ; elle standardise uniquement le format d'empaquetage, sans définir de magasin d'extensions, de protocoles d'installation, de modèle de permissions, d'isolation en sandbox ni de vérification des sources. Ainsi, elle ressemble davantage à un « format de paquet » pour l'écosystème des agents qu'à une boutique d'applications mature permettant d'installer en toute confiance n'importe quel plugin.

Auteur de l'article, source : Jonathan Hefner, membre de l'équipe technique de Vercel

Au cours de la dernière année, l'écosystème des agents IA a développé deux capacités d'extension importantes.

La première catégorie est les compétences Agent. Elles sont généralement composées d'un fichierSKILL.md, de scripts associés et de ressources de référence, destinés à indiquer à l'Agent comment accomplir un type particulier de tâche. Par exemple, lors du déploiement d'un site web, de l'analyse de documents financiers ou de la vérification de la sécurité du code, les compétences fournissent des étapes opérationnelles, des précautions à prendre, des règles de validation et des programmes directement exécutables.

La deuxième catégorie est le serveur MCP. Le MCP permet aux agents de se connecter à des outils et données externes, comme lire une base de données, manipuler GitHub, interroger l'état des plateformes cloud ou appeler des systèmes internes à l'entreprise. Les compétences visent à « apprendre à l'agent comment faire », tandis que le MCP vise à « fournir à l'agent des outils réellement appelables ».

Le problème réside dans le fait que ces composants manquaient auparavant d’un encadrement unifié. Même si une compétence ou le contenu central d’un serveur MCP était exactement identique, les développeurs devaient encore modifier séparément les fichiers de manifeste, la structure de répertoires et les champs de configuration lorsqu’ils intégraient ces éléments dans différents produits Agent. Avec le temps, une même extension a généré plusieurs versions spécifiques à chaque client ; une version pouvait corriger un bogue, mais les autres branches n’étaient pas nécessairement synchronisées, aboutissant finalement à ce que Google appelle le « fork et la dérive ».

Les plugins d'agent doivent fournir exactement ces capacités dans un emballage générique externe. Leur rôle est plus proche du package.json de l'écosystème JavaScript ou du format OCI dans le domaine des conteneurs : ils ne remplacent pas le code ni les protocoles à l'intérieur, mais décrivent uniformément comment ces éléments doivent être organisés, découverts et chargés.

According toversion 1.0.0 specification, an Agent Plugin is a directory with a fixed structure, and the root directory must containplugin.json. The minimal manifest only needs to declare the adopted specification version and the plugin name.

If the plugin includes skills, they are all placed in theskills/directory, with each skill having its ownSKILL.md, along with accompanying scripts, reference files, and other resources. If the plugin requires connection to external tools, placemcp.jsonin the root directory to declare one or more MCP servers.

MCP prend actuellement en charge trois méthodes de connexion : stdio avec un processus lancé localement, Streamable HTTP (recommandé actuellement), et HTTP+SSE conservé pour la compatibilité avec les anciens systèmes. Les clients ne doivent pas nécessairement prendre en charge toutes les méthodes de transmission, mais doivent au moins en prendre en charge une parmi stdio ou Streamable HTTP.

Les avantages directs de cette structure fixe sont que le client n’a pas à deviner l’emplacement des fichiers, et que les auteurs de plugins n’ont pas besoin de concevoir à nouveau les répertoires pour chaque produit. Un client compatible, même s’il ne prend en charge que les Skills et pas le MCP, peut continuer à lire la section des compétences ; en cas d’erreur de configuration MCP, la norme exige que le client saute autant que possible les serveurs défectueux, plutôt que de rendre l’ensemble du plugin inopérant.

Les plugins d'agent permettent également aux fabricants de conserver des fonctionnalités propriétaires. Les clients peuvent établir leur propre espace de noms étendu en utilisant un nom de domaine inversé, par exemplecom.example.client. Les autres clients doivent ignorer les configurations propriétaires qu'ils ne reconnaissent pas, plutôt que de rejeter l'ensemble du plugin. Cela permet aux normes de fournir une base commune tout en n'imposant pas à tous les produits d'avoir exactement les mêmes fonctionnalités.

La liste officielle de compatibilité inclut actuellement VS Code, Cursor, GitHub Copilot, ChatGPT et Codex, ainsi que Kiro d'Amazon. Vercel a initié la proposition de spécification initiale, suivie par la création du comité directeur technique initial par AWS, Anysphere (la société mère de Cursor), Microsoft, OpenAI et Vercel ; GitHub a également participé à l'affinement de la spécification.

Google a annoncé le jour de la publication qu'il rejoindrait les efforts de maintenance principaux et commencerait à faire supporter ce format par ses produits associés. Google prévoit d'adopter les Agent Plugins dans Agents CLI et Data Agent Kit, permettant aux développeurs de combiner des fonctionnalités de données telles que BigQuery, Spanner et Cloud SQL en plugins portables.

Ces acteurs méritent d’être suivis, car ils ne font pas partie du même camp au niveau des modèles et des produits. Microsoft possède VS Code et GitHub Copilot, et entretient des liens étroits avec OpenAI ; Cursor est un outil de programmation AI indépendant ; AWS possède Kiro et concurrence Microsoft et Google sur le marché du cloud ; Vercel cherche à devenir une plateforme de déploiement d’applications AI. Leur volonté de collaborer pour établir des normes de packaging indique que la fragmentation des plugins commence à augmenter les coûts de maintenance pour tous les acteurs.

La norme utilise une licence ouverte, et les discussions techniques ainsi que les décisions sont prévues pour être menées dans un projet public. Elle tente du moins, sur le plan de la conception institutionnelle, d'éviter que le format ne soit entièrement contrôlé par une seule entreprise. Toutefois, l'efficacité finale de la gouvernance ouverte dépendra des processus décisionnels des versions futures, ainsi que de la dépendance importante des produits vis-à-vis de leurs propres extensions exclusives.

L'endroit le plus susceptible de prêter à confusion dans les plugins d'agent est le terme « plugin », qui évoque des extensions de navigateur ou des applications de magasins mobiles. En réalité, la version actuelle 1.0.0 n'unifie que le format d'emballage et ne met pas en place un système complet de distribution et de sécurité des plugins.

L'interprétation officielle de Google précise clairement que la première version ne spécifie pas quel protocole doit être utilisé pour installer les plugins, d'où ils doivent être recherchés et téléchargés, ni ne prévoit de demande d'autorisations unifiée, de confirmation de l'utilisateur, d'environnement d'exécution en sandbox, de vérification de l'identité et de la source de l'éditeur. Ces tâches restent à la charge de chaque client Agent.

Although the specification requires that file paths within the plugin cannot escape the plugin root directory via../or symbolic links, the official documentation specifically notes: this path restriction does not equate to sandboxing the plugin process. An MCP server launched via stdio may still execute programs; which files, environment variables, networks, and user data it can access is determined by the client’s permission system.

Les points de terminaison MCP à distance doivent utiliser HTTPS en principe, et les plugins ne doivent pas écrire directement de mots de passe ou d'autres secrets dans les en-têtes de requête ou les configurations d'environnement publiques. Toutefois, la version 1.0.0 ne fournit pas de configuration OAuth universelle ni de mécanisme de référence de crédentials portable ; l'authentification, la connexion utilisateur et l'enregistrement des crédentials sont toujours gérés par le client.

Ainsi, un format uniforme pourrait également augmenter l'efficacité de la propagation d'extensions malveillantes. Les développeurs peuvent « packager une fois, exécuter partout » ; théoriquement, les attaquants peuvent en faire autant. Ce qui déterminera réellement à l'avenir si cette norme sera largement adoptée ne sera peut-être pas la structure de répertoire, mais la capacité des mécanismes de signature, d'alertes de permissions, d'audit de la chaîne d'approvisionnement, de mise à jour automatique et de révocation à suivre le rythme.

De nombreux produits Agent incluent également des commandes, des hooks d'événements, des modèles de sous-Agents, des composants d'interface et des flux de travail personnalisés. Les concepteurs n'ont pas imposé une uniformité de ces éléments dans la première version, mais ont choisi uniquement les deux composants déjà établis sur une base interplateforme : les Skills et les MCP.

C'est un choix prudent mais réaliste. Si les normes tentaient dès le départ de définir toutes les capacités des agents, elles risqueraient de devenir trop volumineuses et de figer la conception actuelle d'un produit en tant que règle à long terme pour l'ensemble de l'industrie. Les plugins d'agent résolvent d'abord les problèmes les plus clairs : ils relient les connaissances opérationnelles et les outils de l'agent dans un même paquet logistique portable.

Google a également souligné que chaque compétence indépendante ou chaque serveur MCP n'a pas besoin d'être empaqueté sous forme de plugin. Les plugins sont plus adaptés à un ensemble de capacités qui nécessitent une installation commune, une gestion de version commune et une migration commune. Par exemple, un ensemble de plugins de développement de base de données peut inclure à la fois des compétences en requêtes SQL, une connexion MCP à la base de données, des guides de dépannage et des scripts de déploiement ; si vous n'avez qu'un simple document explicatif, il peut être plus approprié de le distribuer directement sous forme de compétence.

Si la norme reçoit un soutien suffisant de la part des clients, les développeurs n'auront pas à reconstruire entièrement leurs compétences et leurs connexions d'outils lorsqu'ils passent de Cursor à VS Code, ou de Codex à un autre agent. Les capacités d'agent accumulées à long terme par les particuliers ou les entreprises peuvent suivre les utilisateurs, ce qui rend les modèles sous-jacents et les clients plus faciles à remplacer.

Cela changera la façon dont la plateforme Agent concourt. Les fabricants ne pourront plus retenir les utilisateurs uniquement grâce à des formats de plugins propriétaires, mais devront continuellement rivaliser sur la qualité des modèles, la fiabilité d'exécution, le contrôle des autorisations, l'expérience utilisateur et la capacité de découverte des plugins. Pour les développeurs, les plugins portables signifient qu'un seul investissement permet de toucher un plus grand nombre d'utilisateurs potentiels, sans avoir à maintenir en parallèle des projets presque identiques pour chaque marché Agent.

Mais la véritable portabilité a ses limites. Les clients peuvent n'implémenter qu'une partie de la spécification, et les mécanismes d'autorisation ainsi que les environnements d'exécution varient selon les produits ; bien que les plugins soient reconnus, leur comportement n'est pas nécessairement identique sur chaque client. L'utilisation intensive de namespaces propriétaires peut même, sous une apparence de compatibilité formelle, rétablir un verrouillage pratique.

En outre, MCP a été initialement promu par Anthropic, mais Anthropic n'apparaît pas actuellement sur la liste des principaux maintaineurs initiaux ou des premiers clients officiellement compatibles publiée pour les plugins d'agent. Cela ne signifie pas que Claude ne prendra pas en charge ce format à l'avenir, mais indique que la nouvelle norme d'emballage ne couvre pas encore tous les principaux camps d'agents.

La valeur la plus importante des plugins d'agent n'est pas la complexité technique, mais le fait qu'elle ait fait reconnaître à de nombreux fournisseurs concurrents un même problème : les modèles peuvent appeler de plus en plus d'outils, mais si chaque plateforme possède sa propre méthode d'emballage des plugins, l'écosystème des agents reproduira l'histoire fragmentée des premières applications mobiles et extensions de navigateur.

La première version de la spécification est très limitée et ne traite même pas la manière dont les plugins trouvent, installent et font confiance. Mais cette retenue pourrait également être son atout. Elle unifie d'abord la couche la plus fondamentale et la plus facile à faire consensus, permettant aux Skills et aux serveurs MCP d'avoir un moyen de transport commun, tout en laissant les autorisations, la distribution et d'autres composants pour les versions futures.

Il convient de noter quela page de spécification officielle, bien qu'elle indique la version 1.0.0, reste en statut « Working Draft » et des ajustements pourraient être apportés ultérieurement. Pour l'instant, le soutien provient principalement des fabricants ayant participé à l'élaboration de la norme, et il n'est pas encore démontré que l'écosystème des agents plus large l'ait adoptée.