Plugins d'agents ou rôles skilder : ce que chacun embarque, et où il s'exécute

Chaque grand client d’agent a désormais son système de plugins. Claude Code a lancé les plugins en octobre 2025, OpenAI a ajouté plus de 90 plugins à Codex en avril 2026, et la spécification Agent Plugins donne maintenant aux skills et aux serveurs MCP un format de paquet commun et neutre. Si votre équipe travaille avec des agents, quelqu’un a déjà demandé si les procédures de l’entreprise devaient partir en plugin.

Parfois, oui. Mais un plugin répond à une question d’empaquetage (« comment ces fichiers arrivent-ils dans ce client ? »), alors que la plupart des entreprises se posent une question de contrôle (« quel agent peut faire quoi, dans quel outil, et comment le savons-nous ? »). Un rôle skilder répond à la seconde. Cet article explique ce qu’est chacun, les compare sur les critères qui comptent en production, et indique quand choisir lequel.

La réponse courte : un plugin est un paquet installé dans un client, qui s’exécute avec les droits de la personne qui l’a installé. Un rôle est un ensemble de skills et d’outils cadrés, conservé dans un workspace et servi en MCP à n’importe quel agent au moment de l’exécution. Plugins pour l’outillage local des développeurs ; rôles pour le savoir-faire de l’entreprise qui doit atteindre plusieurs clients sous les mêmes règles.

Ce qu’est un plugin d’agent

Un plugin d’agent est un dossier de composants qu’un client installe et charge d’un bloc. La documentation de Claude Code liste ce qu’il peut contenir :

• Skills : des instructions SKILL.md que l’agent charge quand elles s’appliquent.
• Agents : des définitions de sous-agents auxquels l’agent principal peut déléguer.
• Hooks : des commandes lancées à certains moments du cycle de vie de l’agent, par exemple après chaque modification.
• Serveurs MCP : des serveurs d’outils auxquels le client se connecte tant que le plugin est actif.

Un manifeste nomme et versionne le paquet. Dans Claude Code, il se trouve dans .claude-plugin/plugin.json. Dans le format de plugin d’OpenAI, utilisé par Codex et ChatGPT, c’est un plugin.json à la racine qui pointe vers le schéma Agent Plugins :

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "support-playbook",
  "version": "1.2.0",
  "description": "Règles de remboursement et outils de ticketing pour le support"
}

Les plugins arrivent chez les utilisateurs par des marketplaces. Une marketplace est un fichier catalogue dans un dépôt Git (.claude-plugin/marketplace.json pour Claude Code, .agents/plugins/marketplace.json pour Codex) qui liste les plugins et l’endroit où récupérer chacun. Vous ajoutez la marketplace une fois, puis vous installez les plugins par leur nom.

Sur claude.ai, le même format s’installe depuis Customize > Plugins et suit votre compte dans le chat, Cowork et Claude Code. Chaque surface charge les composants qu’elle prend en charge : skills, commandes et connecteurs partout, agents seulement dans Cowork et Claude Code.

La spécification Agent Plugins

Agent Plugins est le standard ouvert sous-jacent. La version 1.0.0 définit un plugin.json obligatoire, un dossier skills/ d’Agent Skills optionnel, un mcp.json optionnel qui décrit les serveurs MCP, et des espaces de noms en domaine inversé pour les extensions propres à chaque client. Son comité de pilotage initial réunit des mainteneurs d’Amazon, Cursor, Microsoft, OpenAI et Vercel.

La spécification assume son périmètre : distribution, installation, permissions et expérience utilisateur « restent sous le contrôle de chaque client ». Elle normalise la boîte. Elle ne dit pas qui a le droit de l’ouvrir.

Ce qu’est un rôle skilder

Un rôle est un ensemble thématique de skills qu’un agent endosse : Support Engineer, Contrôleur de gestion, Chef de chantier. Il vit dans un workspace skilder et contient :

Élément	Rôle
Nom et description	Ce que l’agent lit pour choisir un rôle.
Instructions	Les consignes du rôle, données une fois que l’agent l’a appris.
Skills	Les procédures que le rôle ouvre, au format Agent Skills.
Outils	Les opérations que ces skills peuvent appeler, issues du registre interne et vérifié de serveurs MCP du workspace.
App	Des cartes interactives que l’agent affiche dans la conversation, servies comme MCP Apps.

Un agent se connecte au workspace en MCP (Streamable HTTP, avec OAuth ou une clé d’API). Il liste les rôles qu’il a le droit de voir, en apprend un, puis travaille uniquement avec les skills et les outils de ce rôle. Skills et références se chargent à la demande : un long document de procédure ne coûte rien tant que l’agent n’en a pas besoin.

Les rôles se configurent depuis des blueprints, se modifient en brouillon et se publient avec un historique de versions. Les agents travaillent toujours sur la version publiée.

Un rôle ne répond pas seulement en texte. L’endpoint du workspace sert aussi des MCP Apps, l’extension MCP pour les interfaces interactives : les résultats des outils display et analytics portent une carte, livrée comme ressource ui://. Dans un client MCP qui affiche les cartes, l’agent ouvre une session ou un appel sur place, pagine les longs résultats et propose des questions de suivi, sans quitter le chat. Les clients qui n’affichent pas de cartes reçoivent le texte.

La même unité de savoir-faire

Les deux modèles partagent leur ingrédient principal. Le dossier skills/ d’un plugin et les skills d’un rôle sont la même chose : des fichiers SKILL.md avec références, scripts et ressources, conformes au standard Agent Skills. skilder importe un SKILL.md depuis GitHub ou un fichier ZIP et exporte une skill dans le même format : une skill écrite pour un plugin peut passer dans un rôle, et inversement.

« Plugin ou rôle » n’est donc pas une question de contenu. C’est une question de lieu de résidence du contenu, de destinataires, et de ce qui se passe à chaque appel.

Plugins d’agents et rôles skilder, côte à côte

	Plugin d’agent	Rôle skilder
Nature	Un paquet de fichiers installé dans un client	Une configuration conservée dans un workspace, servie à l’exécution
Où il s’exécute	Dans le client : sur la machine de l’utilisateur ou dans la session cloud du client	Skills servies par le workspace ; appels d’outils exécutés et journalisés par lui
Atteint	Le client pour lequel il a été construit (format partagé via la spécification Agent Plugins)	Tout client MCP : Claude, ChatGPT, Copilot ou tout agent compatible MCP
Distribution	Marketplace dans un dépôt Git ; installation par utilisateur, projet ou organisation	Publié une fois dans le workspace ; les agents l’apprennent en se connectant
Mises à jour	Récupérées depuis la marketplace (mise à jour auto optionnelle)	Publier une nouvelle version la change pour chaque agent connecté
Coût en contexte	Noms et descriptions des skills de chaque plugin actif présents à chaque tour	L’agent voit le catalogue de rôles, puis seulement le rôle appris
Permissions	S’exécute avec les droits de l’utilisateur qui l’a installé	Cadrées par rôle : l’agent reçoit les outils de ce rôle, rien d’autre
Interface	Du texte, plus l’interface que livrent ses serveurs MCP	Cartes MCP App pour l’activité et l’analytique, dans les clients qui les affichent
Actions locales	Hooks, sous-agents, serveurs de langage, commandes locales	Aucune : un rôle n’exécute pas de code sur la machine de l’utilisateur
Contrôle à l’exécution	Règles de permission du client pour les appels d’outils	Les guardrails du workspace inspectent chaque appel et peuvent le refuser
Observabilité	Compteurs d’adoption et d’usage (offres Team et Enterprise), événements OpenTelemetry	Journal d’exécution par appel, taux de succès, verdicts des guardrails

La suite reprend les lignes qui tranchent la plupart des choix.

Distribution : par client ou par workspace

Un plugin s’installe. Dans Claude Code, c’est machine par machine, au niveau utilisateur, projet ou local ; sur claude.ai, il est enregistré sur le compte et synchronisé vers Cowork et Claude Code. Les organisations en offre Team ou Enterprise peuvent installer un plugin par défaut ou l’imposer à chaque membre, et restreindre les marketplaces autorisées via les paramètres gérés.

Cela fonctionne bien dans la famille de clients d’un même éditeur. Cela s’alourdit quand une même procédure doit atteindre Claude pour l’équipe d’ingénierie, ChatGPT pour les ventes et Copilot pour la finance. La spécification Agent Plugins réduit le coût de reconstruction du paquet, mais chaque client garde sa propre installation, son propre cycle de mise à jour et sa propre console d’administration.

Un rôle ne s’installe nulle part. Il se publie une fois, et tout agent qui se connecte au workspace avec les bons accès peut l’apprendre. Changer la règle de remboursement, c’est publier une nouvelle version d’une seule skill.

Contexte : toujours listé ou appris à la demande

La documentation de Claude Code le dit franchement : un plugin actif fait partie de chaque session, et « pour chaque skill, agent et commande que Claude peut invoquer de lui-même, le nom et la description sont dans le contexte de Claude à chaque tour », que le plugin serve ou non. Dix plugins de huit skills, ce sont quatre-vingts descriptions qui se disputent l’attention à chaque prompt. Anthropic affiche d’ailleurs une estimation du coût en contexte avant l’installation.

Un rôle inverse le défaut. L’agent part du catalogue des rôles qu’il peut utiliser, en apprend un, et seules les skills de ce rôle entrent dans le contexte. Un agent de support ne lit jamais les procédures du contrôleur de gestion. Nous avons détaillé le mécanisme dans du context bloat au context load.

Permissions : les droits de l’installateur ou le périmètre du rôle

La page sécurité des plugins d’Anthropic s’ouvre sur une phrase : un plugin Claude Code installé « peut exécuter du code arbitraire sur votre machine avec vos droits utilisateur ». Les hooks lancent des commandes shell hors du bac à sable, les serveurs MCP stdio démarrent comme processus locaux, et la mise à jour automatique peut modifier les fichiers que vous avez relus. L’avertissement ajoute qu’Anthropic « ne peut pas vérifier qu’ils fonctionneront comme prévu ni qu’ils ne changeront pas ».

Ce n’est pas un défaut. C’est ce qui rend les plugins utiles aux développeurs : un hook qui formate chaque fichier après modification doit tourner sur la machine. Mais la portée d’un plugin est celle de la personne qui l’a installé. Si son jeton Salesforce peut supprimer des comptes, le serveur MCP du plugin le peut aussi.

Un rôle trace une ligne plus étroite. Il accorde les outils dont ses skills ont besoin, depuis le registre interne du workspace, et rien d’autre : c’est le principe du moindre privilège appliqué aux agents. Une même personne peut détenir un compte large et connecter un agent via un rôle qui se contente de lire les tickets.

Nous avons testé cette frontière dans un article de 30 pages publié sur arXiv : 13 scénarios, six modèles, trois interfaces. Quand un appel gouverné a atteint la couche d’autorisation, aucun appel d’outil non autorisé ni aucun remboursement hors limite ne s’est exécuté, parce qu’un outil jamais livré dans un rôle appris ne peut pas être appelé. Le résumé de l’article détaille la méthode et ses limites.

Contrôle à l’exécution : avant l’installation ou à chaque appel

La gouvernance des plugins porte surtout sur l’installation : quelles marketplaces sont autorisées, quels plugins sont imposés, si les hooks de sources non gérées peuvent tourner. Ensuite, chaque appel d’outil relève des règles de permission du client, sur la machine de cet utilisateur.

Dans skilder, le point de contrôle est l’appel lui-même. Chaque appel d’outil passe par le workspace, où des guardrails (des scripts que le workspace exécute sur l’appel) rendent un verdict et, en mode bloquant, refusent l’appel avec une raison exploitable par l’agent. L’agent qui travaille sous ces règles ne les voit pas, il ne peut donc pas les contourner. Chaque appel, son rôle, son résultat et toute décision de guardrail rejoignent un journal d’exécution exportable.

Observabilité : compteurs d’adoption ou trace d’exécution

Les offres Team et Enterprise de Claude indiquent, par plugin, combien de personnes l’ont utilisé et combien d’exécutions il a eues sur les 30 derniers jours, et Claude Code peut exporter les événements de chargement et d’installation de plugins en OpenTelemetry. Vous savez qu’un plugin est utilisé.

Vous ne savez pas ce qu’ont fait ses outils. Le journal d’exécution d’un rôle répond à cette question : quel agent, quel rôle, quelle skill, quel outil, quel résultat. Pour un processus réglementé, c’est la différence entre « les gens s’en servent » et « nous pouvons montrer ce qui s’est passé ».

Quand choisir un plugin d’agent

Les plugins sont le bon outil quand le travail se passe sur la machine de l’utilisateur ou dans un seul client :

• Outillage développeur : formateurs, linters et tests branchés en hooks, serveurs de langage, sous-agents de revue de code.
• Configurations personnelles ou d’équipe qu’une personne maintient et que l’équipe adopte depuis une marketplace partagée.
• Organisations mono-client qui standardisent déjà sur Claude Code ou Codex et le pilotent via les paramètres gérés.
• Intégrations d’éditeurs, où un fournisseur d’outil livre son serveur MCP et ses skills d’usage ensemble, comme la plupart des plugins des annuaires Codex et Claude.

Quand choisir un rôle skilder

Les rôles sont le bon outil quand le savoir-faire appartient à l’entreprise plutôt qu’à la configuration d’un développeur :

• Plusieurs clients : la même procédure doit fonctionner dans Claude, ChatGPT et Copilot, parce que les équipes n’utilisent pas le même agent.
• Accès cadré : un agent doit atteindre certains outils d’un système et pas d’autres, quel que soit le compte de l’utilisateur.
• Contrôle à chaque appel : une règle doit tenir à chaque appel (pas de suppression de ticket, pas de paiement au-delà d’un seuil), pas seulement à l’installation.
• Audit : il vous faut une trace de ce qu’a fait chaque agent, attribuable à une personne et à un rôle.
• Utilisateurs non développeurs : finance, support, opérations, qui ne taperont jamais /plugin install.

Utiliser les deux

Les deux se combinent. Un plugin peut déclarer un serveur MCP distant, et un workspace skilder en est un. Les développeurs gardent les plugins qui agissent en local, tandis que les procédures de l’entreprise et les outils gouvernés arrivent par la connexion au workspace, à l’identique dans chaque client. Les skills restent portables d’un côté à l’autre, puisque ce sont les mêmes fichiers SKILL.md.

C’est le partage que nous avons décrit entre MCP et skills : le format de paquet dit comment les capacités voyagent, le rôle dit quel agent peut s’en servir, comment, et avec quelle trace.

À retenir

• Un plugin d’agent empaquette skills, serveurs MCP, hooks et sous-agents pour un client, s’installe depuis une marketplace et s’exécute avec les droits de son installateur.
• La spécification Agent Plugins normalise le paquet entre clients. Elle laisse permissions et distribution à chaque client.
• Un rôle skilder sert skills et outils cadrés depuis un workspace à tout agent MCP, appris à l’exécution, contrôlé à chaque appel et journalisé.
• Les deux utilisent SKILL.md : le contenu passe de l’un à l’autre.
• Plugins pour l’outillage local des développeurs, rôles pour le savoir-faire de l’entreprise sur plusieurs clients, et comptez utiliser les deux.

Pour voir comment un rôle est structuré, lisez la documentation des rôles.

Questions fréquentes

Qu'est-ce qu'un plugin d'agent ? +

Un plugin d'agent est un paquet installable qui étend un client d'agent IA. C'est un dossier avec un manifeste (plugin.json) et des composants : Agent Skills (SKILL.md), définitions de serveurs MCP, hooks, sous-agents ou commandes. Le client l'installe depuis une marketplace, un catalogue qui liste les plugins et l'endroit où les récupérer. Claude Code, Claude Cowork, Codex et ChatGPT prennent en charge les plugins, et la spécification ouverte Agent Plugins normalise les parties communes.

Qu'est-ce que la spécification Agent Plugins ? +

Agent Plugins est un standard ouvert et neutre pour empaqueter Agent Skills et serveurs MCP dans des plugins portables. La version 1.0.0 définit un manifeste plugin.json obligatoire, un dossier skills/ et un fichier mcp.json optionnels, ainsi que des espaces de noms en domaine inversé pour les extensions propres à chaque client. Son comité de pilotage initial réunit des mainteneurs d'Amazon, Cursor, Microsoft, OpenAI et Vercel. Distribution, installation et permissions restent du ressort de chaque client.

Quelle différence entre un plugin Claude Code et une skill ? +

Une skill est un fichier SKILL.md (avec références et scripts optionnels) qui explique à l'agent comment mener une tâche. Un plugin est un paquet qui peut contenir plusieurs skills avec des serveurs MCP, des hooks, des sous-agents et des commandes, installés d'un bloc sous une même version. Une skill fonctionne seule ; le plugin est le format de distribution quand plusieurs composants doivent voyager ensemble.

Qu'est-ce qu'un rôle skilder ? +

Un rôle est un ensemble thématique de skills qu'un agent endosse, par exemple Support Engineer ou Contrôleur de gestion. Il vit dans un workspace skilder, contient des instructions, des skills et les outils que ces skills peuvent appeler, et il est servi en MCP. Un agent se connecte au workspace, liste les rôles qu'il a le droit de voir, en apprend un et travaille avec ses skills. Les rôles se configurent depuis des blueprints et se publient avec un historique de versions. Dans les clients qui affichent les MCP Apps, des résultats comme l'activité et l'analytique reviennent sous forme de cartes interactives.

Les plugins d'agents sont-ils sûrs en entreprise ? +

Ils peuvent l'être, avec une revue. La documentation d'Anthropic précise qu'un plugin Claude Code peut exécuter du code arbitraire sur votre machine avec vos droits utilisateur, que les hooks lancent des commandes shell hors du bac à sable, et qu'Anthropic ne peut pas vérifier les plugins tiers. Une organisation peut restreindre les marketplaces autorisées, imposer des plugins et limiter les hooks via les paramètres gérés. La vraie question porte moins sur l'installation que sur l'exécution : ce que font les outils du plugin à chaque appel, et qui le voit.

Peut-on utiliser plugins d'agents et rôles skilder ensemble ? +

Oui. Un plugin peut déclarer un serveur MCP distant, et un workspace skilder en est un. Les développeurs gardent les plugins qui agissent sur leur machine (hooks, serveurs de langage, sous-agents), et les procédures de l'entreprise et les outils gouvernés arrivent par la connexion au workspace, de la même façon dans Claude, ChatGPT et Copilot.

Les rôles skilder utilisent-ils le même format SKILL.md que les plugins ? +

Oui. Les skills skilder suivent le standard Agent Skills. Un paquet SKILL.md s'importe depuis GitHub ou un fichier ZIP, et une skill s'exporte dans le même format avec ses références et ses scripts : un contenu écrit pour un plugin peut passer dans un rôle, et inversement.