MCP publie une feuille de route centrée sur le HTTP et l'identité

Les Core Maintainers du Model Context Protocol (MCP), le standard ouvert hébergé par l'Agentic AI Foundation (AAIF) de la Linux Foundation, ont publié une feuille de route actualisée qui fixe le cap du protocole pour la prochaine version de la spécification et au-delà. Comme l'a rapporté le média technique japonais Publickey, cette feuille de route s'organise autour de cinq domaines prioritaires : la messagerie destinée aux agents, l'unification du transport autour du HTTP, l'identité des agents et la sécurité pour l'entreprise, l'amélioration des outils de base, et une meilleure expérience développeur pour les SDK. Le blog officiel de MCP confirme que cette feuille de route a été élaborée conjointement par les Core Maintainers et la communauté des groupes de travail, et qu'elle « fixe la direction du travail sur le protocole pour les prochains mois ».

MCP est né en novembre 2024 comme un protocole proposé par Anthropic pour connecter ses modèles Claude à des sources de données et des outils externes. Le 9 décembre 2025, la Linux Foundation a annoncé avoir reçu ce protocole en donation et créé l'Agentic AI Foundation pour en piloter l'évolution, avec Amazon Web Services, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft et OpenAI comme membres platine. Selon l'annonce de la Linux Foundation, MCP est devenu l'un des projets open source à la croissance la plus rapide de l'année écoulée, avec plus de 97 millions de téléchargements mensuels de SDK et plus de 10 000 serveurs actifs, intégré nativement dans ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot et Visual Studio Code. En juillet, l'extension « Enterprise-Managed Authorization » (EMA) est passée en version stable et le protocole est devenu sans état (stateless), une mise à jour majeure qui facilite les déploiements à grande échelle.

Cinq domaines prioritaires

D'après le billet officiel « The New MCP Roadmap », cette mise à jour prolonge la précédente feuille de route publiée en mars, qui comptait quatre priorités : évolution et scalabilité du transport, communication entre agents, maturation de la gouvernance, et préparation à l'entreprise. L'essentiel des progrès de ces cinq derniers mois a atterri dans la version de spécification du 28 juillet 2026 (2026-07-28). Les sessions au niveau du protocole et la poignée de main d'initialisation ont été supprimées, permettant aux serveurs de monter en charge horizontalement sans conserver d'état (SEP-2575, SEP-2567) ; les clients disposent désormais d'un appel `server/discover` pour connaître les capacités d'un serveur avant toute connexion ; et les résultats de listes sont devenus cachables (SEP-2549).

• Messagerie pour agents : construire des événements initiés par le serveur (webhooks et canaux) pour que les clients arrêtent d'interroger en boucle, et faire mûrir l'extension Tasks (SEP-2663) jusqu'à son intégration dans la spécification principale
• Unification du transport autour du HTTP : étendre Streamable HTTP aux serveurs locaux également, via HTTP/2 sur stdio pour conserver les avantages du multiplexage tout en gardant un sous-processus
• Identité des agents et sécurité pour l'entreprise : finaliser Demonstrating Proof of Possession (DPoP) et définir l'identité et la délégation des agents via Workload Identity Federation (SEP-1933) et l'échange de jetons ID-JAG, plutôt que des clés API copiées-collées ou des jetons à longue durée de vie
• Amélioration des outils de base : standardiser la forme des réponses de `tools/call` et introduire une découverte progressive, pour qu'un modèle n'ait pas à charger tout le catalogue d'outils d'un serveur avant même la première question de l'utilisateur
• Meilleure expérience développeur pour les SDK : affiner l'ergonomie des API et la précision de la documentation, alors que de nombreux développeurs — et de plus en plus d'agents IA eux-mêmes — écrivent du code client ou serveur MCP directement à partir des SDK

Ce que cela résout pour les entreprises

Le modèle d'autorisation actuel de MCP suppose qu'un humain valide l'accès dans un navigateur. Le blog officiel souligne qu'une part croissante des appelants sont désormais des agents fonctionnant comme des charges de travail cloud dotées de leur propre identité, agissant pour le compte d'un utilisateur absent, ou déléguant une autorité plus restreinte à des sous-agents. Le chantier sur l'identité vise à donner aux serveurs MCP un moyen standardisé de reconnaître et de faire confiance à ces identités d'agents, appuyé sur des standards existants plutôt que sur des clés API copiées-collées, en coordination avec les groupes de travail IETF OAuth et WIMSE sur les mécaniques d'échange de jetons. L'unification autour du HTTP compte tout autant sur le plan opérationnel : un serveur MCP distant construit sur Streamable HTTP ne se distingue plus d'une charge de travail HTTP classique, ce qui permet aux entreprises de l'héberger et de le faire évoluer sur la même infrastructure — répartiteurs de charge, passerelles, supervision — qu'elles utilisent déjà pour leurs API, au lieu de construire une plomberie sur mesure pour un protocole à part.

Sur la priorisation, le blog officiel est explicite : les propositions (SEP) qui correspondent à l'un des cinq domaines prioritaires bénéficient d'une revue accélérée, tandis que les autres ne sont pas rejetées automatiquement mais font face à des délais plus longs et à une exigence de justification plus élevée, la capacité de revue des mainteneurs étant limitée et volontairement concentrée sur ces cinq domaines.

Pourquoi cela compte pour les équipes qui construisent des agents

MCP est déjà le connecteur qu'utilisent la plupart des grands produits IA — ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, Visual Studio Code — pour atteindre des outils externes, ce qui fait de cette feuille de route bien plus qu'un document d'ingénierie interne : elle indique où se dirige le standard de facto de la connectivité agent-outil. Pour les entreprises qui branchent des agents IA sur leurs systèmes internes, le travail d'unification HTTP devrait réduire le coût opérationnel de l'exploitation de serveurs MCP à grande échelle, en supprimant le besoin d'une infrastructure séparée pour les déploiements en stdio ou WebSocket. Le chantier sur l'identité répond à un risque très concret que les équipes portent déjà : des clés API partagées entre services ou restées valides après le changement de poste d'un salarié. Un moyen standardisé de restreindre et de révoquer les identifiants propres à un agent, appuyé sur des journaux d'audit, remplace le partage informel de clés par quelque chose qu'une équipe sécurité peut réellement gouverner. Les organisations qui authentifient aujourd'hui leurs connexions MCP avec des jetons à longue durée de vie devraient voir ceci comme un signal précoce pour préparer une migration une fois ce chantier identité et délégation livré.