Introduction
Le 22 août 2026, les mainteneurs du Model Context Protocol ont publié leur feuille de route pour les six à douze prochains mois. À peine un mois après la spécification 2026-07-28 — qui avait introduit un noyau stateless pour les serveurs distants — ce document structure cinq chantiers prioritaires et formalise une gouvernance par groupes de travail. L'ambition est claire : transformer un protocole prometteur en standard d'intégration fiable pour les équipes enterprise.
La fin de la double pile transport
Le problème est connu de quiconque a développé un serveur MCP : les serveurs distants utilisent Streamable HTTP, les serveurs locaux passent par stdio, et les SDKs maintiennent deux pipelines distincts, avec les écarts de comportement qui en découlent. La solution retenue est HTTP/2 over stdio — le protocole HTTP encapsulé directement dans la communication stdin/stdout d'un sous-processus local, en conservant les garanties de cycle de vie d'une gestion de processus classique. Pour les équipes de développement, cela signifie un outillage de test et de CI unifié et la suppression d'une classe entière de bugs liés à cette dualité.
Le chantier intègre également les ETags pour la mise en cache des résultats d'outils et de ressources, dans la continuité des TTL introduits en juillet. Résultat attendu : moins d'appels redondants sans logique supplémentaire côté client.
L'identité des agents, sans les antipatterns actuels
Le deuxième chantier est le plus structurant pour les équipes sécurité. Les intégrations MCP reposent encore trop souvent sur des clés API partagées ou des refresh tokens de longue durée — précisément ce qu'un audit SOC 2 ou une politique zero-trust sanctionne.
Le roadmap cible deux mécanismes complémentaires. DPoP (RFC 9449) lie un token à la clé privée éphémère du client via une signature JWT : un token intercepté devient inutilisable, sans PKI à opérer ni certificat à gérer. Le Workload Identity Federation (SEP-1933) permet, lui, à un agent cloud d'obtenir des permissions via son identité de charge de travail, sans credential stocké. Ces travaux sont coordonnés avec les groupes IETF OAuth et WIMSE, ouvrant une convergence avec les stacks d'identité enterprise déjà déployés.
Progressive discovery et redesign de l'interface d'outils
L'interface tools/call retourne simultanément content et structuredContent, ce qui a produit des implémentations divergentes côté serveurs et clients. Le redesign prévu clarifie la sémantique une bonne fois pour toutes.
Plus structurant encore : la progressive discovery permettra aux clients de charger les outils d'un serveur au fil des besoins, plutôt qu'en ingérant le catalogue complet au démarrage. Pour un serveur exposant des centaines d'outils, c'est un changement architectural direct, avec un impact mesurable sur la latence initiale et la saturation du contexte des modèles.
Une gouvernance ouverte aux contributeurs
Le document formalise le cadre des Specification Enhancement Proposals (SEPs) avec une règle nette : les SEPs alignées sur un domaine prioritaire bénéficient d'un examen accéléré. Chaque domaine est encadré par un Working Group avec des mainteneurs nommés publiquement. Pour les équipes souhaitant peser sur l'évolution du protocole, le chemin est désormais documenté — Working Group d'abord, SEP formelle ensuite.
Des SDKs générés depuis la spécification
Les SDKs actuels sont maintenus à la main et dérivent de la spécification entre deux releases. L'objectif de ce cycle est de générer un SDK de référence directement depuis la spec, validé contre une suite de tests de conformité publiée. Moins de drift, moins de corrections post-release, et des exemples de démarrage cohérents avec la version en production.
Ce qu'il faut anticiper maintenant
Ce roadmap n'impose pas de migration immédiate, mais il dessine les arbitrages à prendre dès aujourd'hui. Aligner les implémentations sur Streamable HTTP permet d'absorber le passage à HTTP/2 over stdio sans rupture. Évaluer DPoP pour les workloads cloud évite de construire sur des patterns que le standard rendra progressivement caducs. Pour les équipes ayant des besoins spécifiques, les Working Groups sont ouverts et la fenêtre pour influencer la prochaine spécification est là.