MCP : la feuille de route change de cap

Ce qui se passe

Les Core Maintainers du Model Context Protocol ont publié une feuille de route actualisée, qui couvre la prochaine version de la spécification et au-delà. Elle a été construite avec les Working Groups, et elle sert d'abord de filtre : les SEP — les propositions d'évolution de la spécification — qui tombent dans l'un des cinq chantiers passent en revue accélérée. Les autres ne sont pas refusées d'office, mais le temps de revue va aux priorités d'abord.

Trois des cinq chantiers reprennent des sujets que la feuille de route précédente rangeait « à l'horizon » : les événements initiés par le serveur, l'amélioration des types de résultat, et l'identité des agents. Ils ont suffisamment mûri pour devenir des priorités à part entière.

Le problème de fond

MCP a été conçu autour d'un schéma requête-réponse. Un client demande, un serveur répond. Les charges de travail agentiques n'entrent plus dans ce moule : les boucles durent, les serveurs poussent des résultats au fil de l'eau, et il faut pouvoir infléchir un travail en cours.

Le protocole a déjà grandi dans cette direction, avec Tasks, subscriptions/listen et les notifications de progression. Ce qui manque, c'est la garantie que ces briques fonctionnent bien ensemble, d'où une revue de composition menée conjointement par les groupes Agents, Transports et Triggers & Events.

Les trois chantiers qui comptent

Primitives de messagerie agentique

Le travail porte sur les événements initiés par le serveur — webhooks et canaux — pour que le client cesse d'interroger en boucle en attendant un résultat. Il porte aussi sur la maturation de l'extension Tasks (SEP-2663), avec l'objectif de la faire entrer dans la spécification elle-même.

Unification du transport

Depuis la version du 28 juillet 2026, un serveur MCP distant n'est plus rien d'autre qu'une charge HTTP ordinaire : il s'héberge et s'exploite sur l'infrastructure qui sert déjà vos API. L'approche a tenu à l'échelle, et l'objectif est maintenant de l'étendre aux autres modes de déploiement — y compris les serveurs locaux, qui parleraient Streamable HTTP par-dessus stdio. Un seul transport à implémenter, côté serveur comme côté client.

Identité des agents

C'est le chantier le plus structurant. L'autorisation MCP telle qu'elle existe suppose une personne qui approuve un accès dans un navigateur. Or les appelants sont de plus en plus des agents tournant comme charges de travail cloud, avec leur propre identité, agissant pour un utilisateur absent, ou déléguant une autorité plus étroite à des sous-agents.

L'objectif est que les serveurs MCP puissent reconnaître ces identités sur la base de standards existants, pas de clés d'API collées à la main ni de jetons à longue durée de vie. Concrètement : finalisation de DPoP (RFC 9449) et poussée de son adoption, puis un chemin balisé pour l'identité et la délégation via la Workload Identity Federation, le grant ID-JAG derrière l'Enterprise-Managed Authorization, et l'échange de jetons standard. Le travail se fait en lien avec les groupes IETF OAuth et WIMSE.

Les deux autres

Primitives améliorées. Une réponse à tools/call peut porter la même sortie sous plusieurs formes, et le développeur de serveur n'a aujourd'hui aucun moyen de savoir laquelle un client donné mettra devant le modèle. L'objectif est un contrat unique et clair. S'y ajoute un problème d'échelle : se connecter à un serveur exposant cent outils fait payer toute cette surface au modèle avant même la première question, et la sélection d'outil se dégrade à mesure que la liste grandit. D'où un chantier de découverte progressive — un petit point d'entrée, puis révélation du catalogue à mesure que la conversation se précise.

Ergonomie des SDK. Investissement sur la conformité à la spécification et la qualité de la documentation, avec un argument nouveau : beaucoup de développeurs construisent désormais leurs serveurs en pointant un agent sur les bibliothèques. Des API claires et des docs exactes décident alors si le code produit fonctionne.

Ce que ça change pour vous

Si vous maintenez un serveur MCP :

• l'extension Tasks est en trajectoire d'entrée dans la spécification — s'en approcher maintenant évite une migration plus tard ;
• si votre serveur est exposé à des agents non interactifs, DPoP et l'échange de jetons sont la direction officielle : ne bâtissez pas sur des jetons longue durée ;
• un catalogue de cent outils est un problème reconnu par les mainteneurs, pas une fatalité à absorber côté client.

La réserve est simple : c'est une direction, pas une spécification datée. Rien ici n'est gravé, et le calendrier n'est pas donné.