La nouvelle roadmap de MCP : ce qu’elle signifie pour ceux qui construisent dessus

Le 22 août, les maintainers du Model Context Protocol ont publié une roadmap mise à jour couvrant les six à douze prochains mois de travail sur le protocole. Elle nomme cinq domaines prioritaires, les Core Maintainers responsables de chacun et une règle discrète mais importante sur les propositions reviewées en premier. La roadmap précédente, de mars, promettait quatre choses et en a livré l’essentiel dans la release de spécification de juillet. Celle-ci a donc gagné le droit d’être prise au sérieux. Ma lecture : MCP devient volontairement une infrastructure web ordinaire, et la question utile pour les builders est de savoir quelle partie de votre stack cela change en premier.

Points clés - La roadmap fixe cinq priorités : agentic messaging, un transport HTTP-native unique, agent identity et enterprise security, des primitives de tools plus propres et des SDKs générés depuis la spécification. - Les Spec Enhancement Proposals, SEPs, dans ces domaines reçoivent un review accéléré. En dehors, attendez-vous à une queue plus longue et une barre plus haute. - Les promesses de la roadmap de mars ont largement atterri dans la spec 2026-07-28 : core stateless, résultats de listes cacheables et Multi Round-Trip Requests. - Les deux changements les plus susceptibles de toucher votre code sont agent identity, DPoP et Workload Identity Federation, et progressive tool discovery pour les grands catalogues. - Traitez la roadmap comme une direction, pas comme un engagement. Les maintainers le disent eux-mêmes. Ne mettez pas votre build en pause pour elle.

Qu’ont réellement annoncé les maintainers MCP ?

Les faits d’abord. La roadmap MCP mise à jour, datée du 22 août 2026, organise le prochain cycle de spec autour de cinq domaines prioritaires, chacun avec des Core Maintainers nommés et un ou plusieurs Working Groups derrière :

1. Agentic messaging primitives : événements initiés par le serveur, channels, subscriptions et webhooks, afin que les clients cessent de poller, plus une composition review pour que Tasks, triggers et progress notifications partagent un même lifecycle.

2. HTTP-native transport unification and hardening : Streamable HTTP comme unique binding, à terme parlé sur stdio pour les serveurs locaux, et caching étendu aux ETags.

3. Agent identity and enterprise-ready security : finaliser DPoP, Demonstrating Proof of Possession, et définir un chemin opinionated pour agent identity et delegation construit sur des standards IETF existants.

4. Improved primitives : redesign de la shape des résultats tools/call, plus un nouvel effort de progressive discovery pour que les clients découvrent le catalogue d’un serveur selon leurs besoins.

5. Improved SDK developer experience : un extension contract et une expérience visant à générer un SDK Tier 1 et ses quickstarts directement à partir de la spécification.

À côté des cinq domaines se trouve une règle qui façonnera tout le reste : les SEPs dans les priorités obtiennent un review accéléré, et les propositions soutenues par un Working Group avancent le plus vite. Selon les maintainers : "maintainer review time is scarce. We spend it here first." La roadmap précise également qu’elle reflète la pensée actuelle plutôt que des engagements fermes, donc certains éléments peuvent glisser ou arriver sous une autre forme.

La roadmap MCP publiée le 22 août 2026 fixe cinq domaines prioritaires pour les six à douze prochains mois : agentic messaging, transport HTTP-native, agent identity, primitives de tools améliorées et SDKs générés depuis la spec. Les propositions alignées reçoivent un review accéléré ; les autres attendent davantage.

Pourquoi cette roadmap compte-t-elle ?

Elle compte parce que la précédente a livré. Les roadmaps de jeunes projets open source sont souvent des documents aspirationnels qui vieillissent en silence. Celle-ci a un track record. La roadmap de mars 2026 fixait quatre priorités, et l’essentiel est arrivé cinq mois plus tard dans la release de spécification 2026-07-28 :

L’adoption donne son poids à la roadmap. En juillet 2026, les SDKs Tier 1 du protocole approchaient un demi-milliard de téléchargements par mois, avec les SDK TypeScript et Python chacun au-delà d’un milliard de téléchargements cumulés. Lorsqu’un protocole de cette taille vous indique où il va, il vaut la peine de lire la carte.

Source : roadmap MCP de mars et août 2026 et annonce de la spécification 2026-07-28.

La roadmap MCP de mars 2026 promettait transport evolution, agent communication, governance maturation et enterprise readiness. Cinq mois plus tard, la spécification 2026-07-28 a livré un core de protocole stateless, l’extension Tasks, Multi Round-Trip Requests et une deprecation policy formelle avec une fenêtre minimale de douze mois.

Qu’est-ce que cela signifie si vous construisez sur MCP ?

Pour les builders, l’impact immédiat est inégal. Deux des cinq domaines changeront probablement votre code dans l’année. Les trois autres changent surtout la manière dont le protocole est gouverné et maintenu autour de vous. Voici chaque domaine traduit.

Agentic messaging : la fin du polling

Le vrai travail d’agent ne rentre pas dans request et response. Les jobs durent des minutes, les serveurs terminent pendant que le client ne regarde pas, et aujourd’hui la seule réponse du client est souvent de poller, coûteux et laid. La roadmap priorise les événements initiés par le serveur : channels, subscriptions et webhooks, afin qu’un serveur puisse dire à votre client quand le travail est terminé. La composition review compte tout autant. Tasks, subscriptions/listen et progress notifications risquent actuellement de devenir trois réponses différentes à "le serveur n’a pas encore fini", et les maintainers veulent un lifecycle partagé, un modèle de cancellation et une error surface communs. Si vous construisez des tools long-running, c’est le domaine à suivre sur Discord.

Un transport, parlé partout

La release 2026-07-28 a transformé un serveur MCP remote en workload HTTP ordinaire. La roadmap veut maintenant effacer la séparation remote/local : Streamable HTTP comme unique binding, parlé sur stdin et stdout pour les serveurs locaux, avec HTTP/2 fournissant le multiplexing pendant que le subprocess conserve ses garanties de sécurité et lifecycle. Aujourd’hui chaque feature HTTP-native a besoin d’un second design spécifique stdio, ou ne fonctionne pas localement, et les SDKs maintiennent deux transport pipelines. Un modèle de transport unique réduit cela. Le caching s’étend aussi : ETags au-dessus des hints ttlMs et cacheScope arrivés en juillet, afin que les résultats de tool calls puissent être versionnés plutôt que refetchés.

Agent identity : celui qui mordra le plus tôt

L’authorization MCP suppose une personne avec un browser au moment du consentement. De plus en plus, le caller est un agent : cloud workload avec sa propre identity, agissant pour un user absent, ou créant des sub-agents qui devraient obtenir moins d’authority que leur parent. Honeycomb, cité dans l’annonce de la release de juillet, attribue déjà près de 20 % de ses queries interactives mensuelles aux agents. Pendant ce temps, beaucoup de serveurs MCP de production reposent encore sur des API keys copiées-collées et des refresh tokens long-lived, exactement la pratique que ce travail veut retirer. Le plan est de finaliser et adopter DPoP, plus un chemin standard de delegation via Workload Identity Federation, SEP-1933, le grant ID-JAG derrière Enterprise-Managed Authorization et RFC 8693 token exchange, coordonné avec les groupes IETF OAuth et WIMSE.

Le modèle d’authorization de MCP a été conçu pour un humain approuvant l’accès dans un browser, mais les agents deviennent les callers. La roadmap priorise DPoP et un chemin standard de delegation basé sur Workload Identity Federation et RFC 8693 token exchange, afin que les serveurs puissent reconnaître les identités d’agents sans API keys copiées ni tokens long-lived.

Résultats de tools et progressive discovery

Deux confusions sont corrigées ici. La première est tools/call renvoyant content et structuredContent à la fois, ce qui a produit des implémentations divergentes parce qu’un auteur de serveur ne peut pas savoir quelle forme le client montrera au model. Ce contract va être redesigné. La seconde est l’échelle : connectez-vous à un serveur avec cent tools et le model paie pour toute la surface avant que le user n’ait posé une seule question, et la sélection se dégrade avec la longueur de la liste. La facture de tokens n’est pas théorique. Dans le test Cloudflare de février 2026, exposer une API de 2 500 endpoints comme définitions de tools MCP a consommé environ 1,17 million de tokens, contre environ 1 000 via code-calling. Progressive discovery est la réponse proposée : un petit entry point qui révèle davantage du catalogue à mesure que la conversation se resserre, lié au travail de caching ci-dessus. J’ai écrit sur les cas où cet overhead rend une API simple préférable ; progressive discovery est la tentative de MCP pour réduire l’écart.

SDKs générés depuis la spec

Le point le plus discret est peut-être le plus révélateur. Aujourd’hui, SDKs, reference servers et quickstarts sont maintenus à la main. La roadmap lance une expérience : générer un candidate SDK Tier 1 et ses quickstarts directement depuis la spécification, valider les deux contre une conformance test suite et publier les résultats, y compris quelles layers devraient relever de codegen déterministe et lesquelles être model-assisted. Si cela fonctionne, les bugs de clarté de la spec apparaissent comme generation failures, et les SDKs cessent de dériver du document qu’ils sont censés implémenter.

Que devriez-vous faire maintenant ?

Quatre choses, par ordre d’urgence :

1. Cette semaine : arrêtez de construire du nouveau travail sur des surfaces deprecated. Roots, Sampling, Logging et le transport legacy HTTP+SSE ont été deprecated dans la spec 2026-07-28 avec une fenêtre minimale de douze mois. Ils fonctionnent toujours. Les nouvelles implémentations ne devraient pas les adopter.

2. Ce mois-ci : rendez votre serveur cache-friendly. Les list results portent déjà ttlMs et cacheScope, et les ETags arrivent. Un serveur qui émet aujourd’hui des cache hints raisonnables a une migration d’avance.

3. Ce trimestre : auditez l’authentification de vos agents. Si un serveur MCP que vous exploitez fait confiance à une API key copiée ou un refresh token long-lived pour un caller unattended, c’est exactement le pattern que le Agent Identity Working Group existe pour remplacer. Suivez le groupe plutôt que d’inventer votre propre delegation scheme. L’angle governance rejoint ce que j’ai couvert dans la gouvernance des agents IA.

4. Si vous voulez façonner le protocole : écrivez votre SEP dans un domaine prioritaire. Présentez-la d’abord au Working Group concerné et obtenez son soutien. Les propositions alignées avec la roadmap obtiennent un review accéléré ; les autres attendent.

Deux choses à ne pas faire. Ne mettez pas un build en pause en attendant la prochaine spec : la version actuelle est la base stable, et la deprecation policy vous garantit désormais douze mois de préavis sur toute disparition. Et ne traitez pas la roadmap comme une promesse. Elle dit dans sa première section que les priorités peuvent évoluer et que du travail non listé peut quand même shipper. Si vous êtes plus tôt dans le parcours, mon walkthrough pratique pour un premier serveur MCP et ma sélection de serveurs utiles à connecter sont les points de départ pratiques.

La spécification MCP 2026-07-28 a deprecated Roots, Sampling, Logging et le transport legacy HTTP+SSE avec une fenêtre minimale de douze mois. L’annonce de release confirme qu’ils continuent à fonctionner pendant cette période, mais les nouvelles implémentations ne devraient pas les adopter.

La vue d’ensemble

Prenez du recul et le pattern est celui d’un protocole qui grandit en public. MCP a été donné à l’Agentic AI Foundation, vendor-neutral, sous la Linux Foundation en décembre 2025, avec OpenAI et Block comme cofondateurs. Depuis, il a gagné contributor ladder, feature lifecycle, deprecation policy et désormais une déclaration publique de la destination de l’attention des maintainers. Le extensions framework fait aussi un travail discret mais réel : SEP-2133 permet à tout Working Group d’expérimenter dans un repository experimental-ext- avant une proposition formelle, afin que les idées soient testées sans déstabiliser le core.

Ce que je surveillerais sur les deux prochains trimestres est HTTP over stdio. Si serveurs locaux et remote convergent réellement vers un seul transport, "MCP server" cesse d’être un type spécial de software et devient un web service avec une interface standard. C’est le point où le protocole disparaît dans la plomberie, ce que la bonne infrastructure est censée faire.

Questions fréquentes

MCP est-il suffisamment stable pour construire dessus maintenant ?

Oui, avec discipline de migration. La spec 2026-07-28 a introduit une deprecation policy formelle avec une fenêtre minimale de douze mois, et les SDKs arrivent avec des migration notes pour les breaking changes. Le protocole continuera de bouger, mais il vous prévient désormais un an à l’avance quand quelque chose dont vous dépendez va disparaître.

Qu’est-il arrivé aux sessions MCP ?

Elles ont été retired dans la spécification 2026-07-28. Le handshake initialize et le header Mcp-Session-Id ont disparu, SEP-2575 et SEP-2567. Chaque request est désormais self-describing, portant protocol version et client capabilities dans _meta, et un call optionnel server/discover remplace le handshake pour les clients qui veulent les capabilities upfront. Toute request peut arriver sur n’importe quelle instance derrière un load balancer round-robin.

Dois-je attendre la prochaine spec avant de construire ?

Non. La roadmap décrit une direction pour les six à douze prochains mois, pas des features engagées, et les maintainers le disent explicitement. La spec actuelle est stable, cacheable et stateless. Construisez dessus, évitez les surfaces deprecated et suivez les deux Working Groups dont les sorties vous toucheront le plus.