GitHub prend en charge Agent Plugins 1.0 dans Visual Studio Code, Copilot CLI et l’application Copilot. Ce format ouvert permet de distribuer dans un même paquet les instructions d’un agent, ses compétences et les serveurs MCP dont il dépend. L’objectif est simple : construire une extension une fois, puis l’utiliser dans plusieurs clients compatibles au lieu de maintenir une intégration spécifique pour chacun.
Le standard a été publié le 6 août avec des contributeurs issus notamment d’AWS, Anysphere, Google, Microsoft, OpenAI et Vercel. Cette convergence est importante pour les équipes qui commencent à accumuler des agents internes, car le véritable coût ne réside plus seulement dans le prompt, mais dans sa distribution, ses permissions et son maintien dans le temps.
La réponse rapide
| Question | Réponse |
|---|---|
| Que contient un plugin ? | Un manifeste plugin.json, des compétences et, si nécessaire, une configuration MCP. |
| Est-il réservé à GitHub Copilot ? | Non. Le format est ouvert, même si chaque client peut ajouter ses propres extensions. |
| Remplace-t-il MCP ? | Non. Il peut empaqueter et configurer des serveurs MCP. |
| Peut-on le déployer en entreprise ? | Oui, avec des listes de plugins et de catalogues autorisés. |
| Le format garantit-il la sécurité ? | Non. Les outils, secrets et permissions doivent toujours être audités. |
Un paquet plutôt qu’une collection de fichiers
Un plugin possède un manifeste à sa racine. Le dossier skills/ décrit les savoir-faire que l’agent peut activer, tandis que mcp.json déclare les connexions à des outils ou données externes. Un répertoire propre à un fournisseur, comme com.github.copilot/, peut compléter le socle commun sans rendre tout le paquet dépendant de ce fournisseur.
Cette organisation répond à un problème déjà visible dans les entreprises. Une équipe crée une procédure pour analyser un incident, une autre ajoute un serveur MCP vers l’observabilité, puis chaque développeur assemble manuellement les deux dans son éditeur. Le plugin transforme cet assemblage en artefact versionné, relisible et testable.
La portabilité ne signifie toutefois pas que le comportement sera identique partout. Les modèles, les interfaces de permission et les capacités des clients diffèrent. Le standard rend le paquet transportable ; il ne normalise pas entièrement le moteur qui l’exécute.
Ce que GitHub apporte avec la version 1.0
Visual Studio Code, Copilot CLI et l’application Copilot peuvent désormais découvrir et installer ces plugins. Un développeur peut donc retrouver un même agent spécialisé dans son terminal, son éditeur ou un environnement distant, avec une configuration plus cohérente.
Pour les administrateurs, GitHub expose des paramètres tels que enabledPlugins, extraKnownMarketplaces et strictKnownMarketplaces. Ils servent à imposer certains plugins, déclarer des catalogues internes ou empêcher l’utilisation de sources non approuvées. Les listes d’autorisation MCP restent complémentaires : approuver un paquet ne doit pas automatiquement donner accès à toutes les commandes de ses serveurs.
Un nouveau maillon de la chaîne logicielle
Un plugin peut demander l’exécution d’un binaire, appeler une API interne ou lire un dépôt. Il doit donc être traité comme une dépendance logicielle, pas comme un simple texte de configuration. L’auteur, la provenance, la version et les changements de permissions doivent être contrôlés avant diffusion.
Les catalogues privés seront utiles pour publier des assistants adaptés à une architecture, à un guide de style ou à une procédure d’astreinte. Ils créent aussi une responsabilité : un plugin obsolète peut recommander une commande dangereuse ou continuer d’appeler une API retirée. Une politique de mise à jour et de retrait devient nécessaire.
Comment l’adopter sans créer une dette supplémentaire
Commencez par un cas étroit et mesurable, par exemple la préparation d’une revue de code ou le diagnostic d’un service. Placez les instructions stables dans une compétence, limitez MCP aux outils indispensables et documentez les données accessibles. Testez ensuite le paquet dans deux clients réellement utilisés par l’équipe.
Versionnez le plugin, exigez une revue pour les modifications du manifeste et enregistrez les résultats attendus sur quelques scénarios. En entreprise, distribuez-le depuis un catalogue contrôlé et associez-le à une liste MCP explicite. Les secrets doivent rester dans le gestionnaire du client ou dans l’infrastructure, jamais dans le paquet.
Enfin, mesurez les échecs et les demandes de confirmation. Un agent portable qui nécessite des corrections manuelles à chaque exécution ne devient pas utile par le seul fait d’être standardisé.
Agent Plugins 1.0 donne aux agents de développement un format de distribution qui leur manquait. Son intérêt dépendra moins du nombre de plugins disponibles que de la capacité des organisations à les gouverner comme du logiciel à part entière.




La discussion
Commentaires
Chargement des commentaires…