Six géants de l'IA (OpenAI, Microsoft, GitHub, AWS, Vercel, Anysphere) ont publié conjointement la spécification ouverte Agent Plugins 1.0.0, unifiant les normes de conditionnement des plugins d'agents IA. Les développeurs n'ont besoin de conditionner qu'une seule fois pour que leurs plugins soient compatibles avec plusieurs clients, tels que Cursor, GitHub Copilot et Codex. La spécification définit des structures telles que plugin.json, les compétences et mcp.json, mais ne concerne que la couche de conditionnement, sans aborder des éléments clés comme les hooks ou les agents personnalisés. Anthropic, pionnier du système de plugins Claude Code, n'a pas participé à cette initiative, mais son format est déjà compatible avec de nombreux autres systèmes. Cela signifie que la concurrence sur les normes sous-jacentes s'est déplacée vers la bataille pour l'écosystème de plugins, et le véritable enjeu réside dans la capacité à attirer le plus de développeurs.Auteur et source de l'article : Nouvelle Intelligence
Les six géants de l'IA ont rarement siégé à la même table.
Le 6 août, une spécification ouverte intitulée Agent Plugins 1.0.0 a été officiellement publiée.
Il réalise un projet attendu depuis longtemps par des milliers de développeurs d'IA : créer une « boîte » standardisée pour les plugins d'agents IA, permettant ainsi une seule emballage universel, sans avoir à les reconditionner pour chaque client.
Les développeurs d'OpenAI ont publié un message sur le compte officiel : « Un seul paquet, compatible avec tous les clients d'agents compatibles », et ont mentionné une série de partenaires collaborateurs.
Ce cadre semble insignifiant, mais il cible précisément les points de douleur.
Le même skill, le même serveur MCP, le même noyau, et pourtant vous devez réintégrer séparément pour Cursor, GitHub Copilot, Codex : dès qu’un service est mis à jour, vous devez tous les modifier un par un.
Les plugins Agent veulent mettre fin à ce travail répétitif.
Structure du répertoire, fichier de liste, et syntaxe de configuration MCP, toutes unifiées. Emballez-les ensemble ; les clients prenant en charge ce format les reconnaîtront.
Schéma de fonctionnement des plugins Agent : les compétences dégroupées à gauche et le MCP sont intégrés dans la « boîte » plugin.json au centre, puis redistribués à divers clients tels que l’IDE, l’CLI et les plateformes entreprises.
Par exemple.
Vous avez créé un plugin « interroger la base de données et rédiger un rapport hebdomadaire » ; une fonction enseigne à l’IA à organiser les résultats de requête en un rapport hebdomadaire que l’équipe apprécie, et un serveur MCP se charge de connecter l’IA à la base de données.
Avant, pour qu'il fonctionne sur trois clients simultanément, il fallait créer trois paquets et modifier chaque fois les trois. Maintenant, il suffit de créer un seul paquet et de le modifier une seule fois.
La liste des contributeurs inclut AWS, Anysphere (la société mère de Cursor), GitHub, Microsoft, OpenAI et Vercel, et Google a même été ajouté parmi les mainteneurs principaux le jour même de la publication.
Le créateur de ce système de jeu, Anthropic, fait toutefois défaut.
Ce qui est uniformisé, c'est l'« emballage », et non l'agent.
Un plugin, généralement composé de deux éléments.
Les mêmes compétences d'agent, fournissant des instructions et des ressources réutilisables pour le modèle ; l'autre est le serveur MCP, chargé de se connecter aux outils et services externes.
Ces deux éléments peuvent déjà être réutilisés entre les clients.
Le véritable point bloquant se trouve au niveau le plus externe : la structure de répertoires, les fichiers manifeste et la configuration MCP varient d’un client à l’autre ; chaque composant doit être reconditionné selon les règles du « nouvel endroit » lorsqu’il est déplacé vers un autre client.
Les plugins Agent ont uniformisé l'emballage externe.
Un plugin est un dossier.
Placez un fichier plugin.json à la racine, mettez toutes les compétences dans le dossier skills/ et configurez MCP dans mcp.json.
La liste ne contient que deux champs obligatoires : $schema et name ; tout le reste est déterminé par la position fixe, le client n'a pas à deviner, même le numéro de version peut être omis.
Quant aux « éléments propriétaires » que chaque entreprise souhaite inclure, tels que ses propres hooks, commandes ou interfaces, placez-les tous dans un dossier nommé selon un nom de domaine inversé.
D'autres clients ne reconnaissent pas ce répertoire et le sautent directement s'ils le détectent. Étant une couche publique, il est plus propre, plus léger, et facile à implémenter.
Et il en impose très peu.
1.0 ne reconnaît que deux types de composants portables : les compétences dans le dossier skills/ et la configuration MCP dans mcp.json.
Les hooks, les commandes avec slash, les agents personnalisés — ces éléments restent encore le domaine de chaque plateforme et ne sont pas unifiés.
Le corps du texte est toujours marqué « Work in Progress », comme si l'officiel ajoutait en aparté : « C'est encore en cours de modification » — il reste encore un certain chemin à parcourir avant d'atteindre un standard mature approuvé par l'industrie.
Une phrase : Agent Skills gère les commandes, MCP gère les outils connectés, et Agent Plugins gère le regroupement des deux dans un même emballage.
Seul l'emballage est uniforme ; les agents à l'intérieur n'ont pas été modifiés.
Un paquetage unique ne signifie pas un fonctionnement universel
Même si les boîtes d'emballage sont uniformisées, les opérations ne suivent pas encore.
Il ne gère que les enveloppes des deux types de composants : skills et mcp.json. Dès qu'il s'agit de les exécuter, il se désengage :
L’installation, la distribution, les autorisations, l’environnement isolé, l’authentification, la vérification de confiance et l’expérience utilisateur — tout est laissé à la discrétion de chaque client.La prise en charge des différents modes de transmission, tels que stdio, Streamable HTTP et l'ancienne version d'HTTP+SSE, varie d'une plateforme à l'autre. Le bon fonctionnement d'un même plugin sur un autre client dépend également de la chance.
Microsoft a également souligné la sécurité : le serveur MCP et les hooks dans les plugins exécuteront du code sur votre appareil local ; assurez-vous de vérifier la source et l'auteur avant d'installer, et faites particulièrement attention aux éléments du marché communautaire.
Les documents packagés d'OpenAI utilisent toujours la structure .codex-plugin/plugin.json, qui n'est pas la même que le plugin.json du répertoire racine de la spécification ouverte.
La norme garantit uniquement que les clients compatibles peuvent découvrir les composants portables qu'ils prennent en charge ; en pratique, les méthodes d'authentification et les environnements d'exécution peuvent encore différer.
Ainsi, regrouper de manière uniforme ne signifie pas que l'exécution est également uniformisée ; une chaîne entière de projets les sépare encore.
Au fond, ce qui est unifié ici est précisément le niveau que les géants sont le moins enclins à lâcher.
Aucun des éléments véritablement précieux — marché des applications, système d'autorisations, point d'entrée utilisateur, ainsi que les capacités spécialisées comme les hooks et les agents personnalisés — n'a été transmis.
Cette structure, pourquoi me semble-t-elle si familière ?
Les personnes familières avec l'extension Claude Code pourraient être interloquées.
plugin.json, skills, mcp.json, ce n'est pas exactement le même système que Claude Code utilise depuis toujours ?
Bien avant l'apparition de cette norme, Anthropic avait déjà conçu un système complet de plugins pour Claude Code : un fichier .claude-plugin/plugin.json à la racine, accompagné de skills, mcp.json, commands et agents, ainsi que deux marchés officiels pour permettre aux utilisateurs de partager des plugins.
L’approche d’empaquetage « plugin = compétences + MCP + une liste » a été l’une des premières mises en œuvre par Anthropic, et leur solution est même plus complète : compétences, hooks, MCP, sous-intelligences, commandes avec slash — tout est inclus en un seul ensemble.
Cette nouvelle norme n'inclut que les deux éléments universels : les compétences et le MCP ; les autres aspects plus sophistiqués n'ont pas été intégrés.
Il est intéressant de noter que, bien qu'Anthropic n'ait pas encore rejoint, le format ressemble presque exactement au sien.
Claude Code possède déjà une variable racine dédiée au répertoire des plugins, nouvelle norme reprise telle quelle, avec simplement un nom différent, mais un fonctionnement identique et une structure presque identique.
La couche de compatibilité ne peut plus être cachée.
La documentation officielle de VS Code de Microsoft inclut déjà l'extension anthropics/claude-code dans le marché par défaut.
Il prend en charge le nouveau format ouvert tout en continuant de reconnaître le format Claude .claude-plugin/plugin.json.
Codex d'OpenAI va encore plus loin : il conserve délibérément l'ancien nom de variable de Claude, uniquement pour assurer la compatibilité avec les plugins Claude existants.
Autrement dit, tout le monde s'est réuni et a adopté un format « très similaire à Claude Code », sans que Anthropic soit présent.
Pionnier, devenu absent
Une entreprise qui a inventé un nouveau concept, mais qui a été absente tout au long du processus alors que les autres en faisaient une norme.
Mais cela ne signifie pas qu'Anthropic est exclu.
Les deux nouveaux outils de Google incluent Claude Code parmi les compatibles, et il possède également deux marchés d'extensions officiels.
Plus précisément, Anthropic a toujours préféré construire ses propres bâtiments.
Cette fois-ci, il n'a pas rejoint cette table aux normes unifiées, mais a continué à gérer son propre écosystème fermé, du format à la distribution en passant par le marché.
Ce n'est pas la première fois qu'il devient le plus évident absent lors d'un événement « Venez tous ».
Tout le monde connaît cette entreprise, qui a toujours pour habitude de parfaire son propre modèle avant de penser à s'aligner sur les autres.
Le bénéfice est que le produit est autonome et offre une expérience cohérente, mais le prix à payer est qu'il est facilement absent lors de chaque handshake à l'échelle de l'industrie.
Pourquoi maintenant ?
Une fois les normes sous-jacentes convenues, la concurrence monte d'un niveau.
Par exemple, plusieurs entreprises peuvent collaborer pour construire les fondations d’un centre commercial, mais une fois les fondations posées, la concurrence se déplace vers les boutiques et les étagères au-dessus.
C'est le terrain de chaque entreprise, où la compétition ne porte plus sur qui a le modèle avec les meilleures notes, mais sur qui possède l'écosystème de plugins le plus vaste et qui vient en premier à l'esprit des développeurs.
Six ont fixé les spécifications de la boîte cette fois-ci.
Mais ce qui décide réellement du vainqueur, ce n'est pas la boîte, ce sont les agents qu'elle contient — celui qui parvient à retenir les développeurs à ses côtés grâce à eux est le gagnant.