GitHub pousse Agent Plugins 1.0 pour unifier les agents entre VS Code, le terminal et l’app Copilot

GitHub a annoncé le 12 août 2026 la disponibilité générale du support d’Agent Plugins 1.0 dans VS Code, Copilot CLI, le SDK GitHub Copilot (kit de développement logiciel) et l’application GitHub Copilot, sur toutes les offres Copilot. Le standard lui-même a été publié le 6 août 2026 avec AWS, Anysphere, Microsoft, OpenAI et Vercel ; Google a rejoint le même jour comme mainteneur principal. L’idée est simple : empaqueter dans un format commun des skills (compétences réutilisables d’un agent) et des serveurs MCP (Model Context Protocol, un protocole qui relie un agent à des outils ou à des sources de contexte) pour éviter de maintenir un packaging différent selon chaque client. (github.blog)

Ce qui change concrètement pour une équipe

Jusqu’ici, publier un plugin pour plusieurs agents était possible, mais GitHub explique que cela impliquait de la duplication : même logique métier, mêmes outils derrière, mais manifestes (fichiers de description) et arborescences de fichiers différents selon le client. Avec Agent Plugins 1.0, un client compatible peut découvrir depuis un même paquet les skills et la configuration MCP qu’il sait charger. GitHub précise aussi que les anciens plugins Copilot restent pris en charge, sans migration obligatoire. En pratique, cela prolonge la trajectoire vue ces derniers jours dans Copilot : après la mémoire persistante dans JetBrains et la continuité de contexte dans l’app, le chantier devient maintenant celui de la portabilité entre outils. (github.blog)

Le format visé par le standard

Pour un développeur qui maintient déjà des intégrations, la migration est décrite par GitHub comme « surtout du travail de manifeste ». Il faut notamment ajouter $schema dans plugin.json, placer les compétences dans skills/, la configuration MCP dans mcp.json, puis ranger les éléments spécifiques à Copilot dans com.github.copilot/. Le standard définit donc un socle portable ; les comportements propres à un client restent possibles via un espace de noms dédié (un dossier réservé à ce client). Le site du standard résume la structure minimale ainsi : (github.blog)

{
  "$schema": "agent-plugins-1.0",
  "plugin": "my-plugin",
  "portable_parts": {
    "skills": "skills/",
    "mcp": "mcp.json"
  },
  "copilot_extensions": "com.github.copilot/"
}

Distribution et gouvernance : le vrai sujet entreprise

Le point le plus concret pour les équipes n’est peut-être pas le format lui-même, mais sa gouvernance. GitHub indique que les clients Copilot Business et Enterprise peuvent réutiliser les paramètres d’administration existants dans VS Code, Copilot CLI, l’application Copilot et l’agent cloud Copilot. Dans managed-settings.json, trois clés sont mises en avant : enabledPlugins pour installer automatiquement ou bloquer des plugins, extraKnownMarketplaces pour ajouter des places de marché autorisées, et strictKnownMarketplaces pour limiter l’installation à des places de marché gérées. GitHub ajoute qu’aucune politique séparée n’est nécessaire pour Agent Plugins 1.0, et recommande de combiner cela avec des listes d’autorisation MCP (listes de serveurs explicitement autorisés ou bloqués, par URL, commande ou nom). (github.blog)

« You can now build a plugin once and use it across all compatible agent clients. » (github.blog)

Où on en est dans la séquence Copilot

Vu depuis une équipe de développement, la séquence devient lisible. Le 7 août 2026, GitHub avait surtout travaillé la continuité du contexte entre l’application Copilot, le terminal et VS Code. Le 11 août 2026, la brique JetBrains ajoutait mémoire persistante, modèles locaux via Ollama (un outil pour exécuter des modèles sur sa machine) et davantage de contrôle centralisé. Le 12 août 2026, Agent Plugins 1.0 ajoute la couche qui manquait pour industrialiser ces usages : un même paquet, plusieurs clients, et les mêmes garde-fous d’administration. Autrement dit, GitHub ne vend pas seulement plus de réponses de l’agent ; il assemble progressivement une plate-forme où les capacités, les outils et les règles d’entreprise suivent le développeur d’un environnement à l’autre. (github.blog)