Le 22 août 2026, l'équipe du Model Context Protocol (MCP) a publié une feuille de route mise à jour, à peine un mois après avoir livré la plus grosse révision du protocole depuis son lancement : la spécification du 28 juillet 2026. Cette fois, il ne s'agit plus de refondre les fondations, mais de dire clairement où le protocole va après le passage au stateless. Et le programme annoncé est copieux.
Cinq chantiers prioritaires pour le prochain cycle
La feuille de route identifie cinq zones prioritaires pour le prochain cycle de spécification : les primitives de messagerie agentique, l'unification du transport autour de HTTP natif, l'identité des agents et la sécurité en entreprise, l'amélioration des primitives existantes (tools, resources, prompts), et enfin l'expérience développeur sur les SDK officiels.
Ce n'est pas un hasard si l'identité des agents et la sécurité d'entreprise arrivent en bonne place. Depuis que MCP est sorti des labos pour équiper des chaînes agentiques en production, le protocole a dû rattraper un vrai retard : jusqu'ici, un serveur MCP savait difficilement distinguer « quel agent, pour le compte de quel utilisateur, avec quelle autorisation » exécute un appel d'outil. Or c'est précisément ce que réclament les équipes sécurité des grandes entreprises avant d'ouvrir leurs systèmes internes à des agents autonomes.
Ce que la version du 28 juillet a déjà livré
Pour comprendre l'ampleur du virage, il faut revenir sur la release du 28 juillet, que j'avais déjà couverte début août sur ce blog. Elle a transformé MCP en protocole stateless, capable de tourner sur une infrastructure HTTP classique sans session persistante côté serveur — un vrai soulagement pour qui déploie des serveurs MCP derrière un load balancer ou une passerelle API standard.
Elle a aussi introduit des extensions versionnées indépendamment de la spécification centrale, identifiées par des ID en reverse-DNS et maintenues dans leurs propres dépôts ext-*. Deux extensions concrètes ont été livrées avec cette release : MCP Apps, qui permet à un serveur de fournir une interface utilisateur rendue côté client, et Tasks, pour gérer les traitements longue durée sans bloquer la connexion. L'autorisation, elle, s'est rapprochée des standards OAuth et OpenID Connect déjà en place dans la plupart des systèmes d'information d'entreprise.
Autre nouveauté moins visible mais structurante : la spécification s'est dotée d'une véritable politique de dépréciation. Les changements du 28 juillet ont été les premiers à la suivre, ce qui signifie que le protocole peut désormais évoluer sans casser brutalement ce que les développeurs ont déjà construit dessus. Pour un écosystème qui a grandi très vite depuis son lancement par Anthropic fin 2024, c'est un signal de maturité qu'il valait la peine de saluer.
HTTP natif : la fin des ambiguïtés de transport
Le deuxième chantier annoncé — l'unification du transport autour de HTTP natif — répond à un problème très concret que beaucoup d'équipes ont rencontré en connectant leurs premiers serveurs MCP : la cohabitation de plusieurs mécanismes de transport (stdio, SSE, HTTP streamable) a longtemps généré des incompatibilités entre clients et serveurs qui, sur le papier, respectaient tous deux la spécification. Converger vers un transport HTTP natif et documenté de façon univoque devrait réduire ce genre de friction, qui reste aujourd'hui l'une des premières causes de bugs signalés sur les dépôts SDK officiels.
Le chantier « primitives de messagerie agentique » va, lui, plus loin que le simple appel d'outil unitaire. L'objectif affiché est de mieux modéliser les échanges multi-tours entre un agent et un serveur — des conversations où plusieurs appels s'enchaînent avec du contexte partagé, ce qui correspond de plus en plus à l'usage réel des agents en production, loin du modèle « une requête, une réponse » des débuts du protocole.
Pourquoi cette feuille de route compte, même si vous ne codez pas de serveur MCP
On pourrait se dire que tout ceci ne concerne que les développeurs qui bâtissent des serveurs MCP maison. C'est une erreur. MCP est en train de devenir la couche de plomberie standard entre les agents IA et le reste du système d'information — bases de données, CRM, outils internes, API tierces. Anthropic, Microsoft et Okta ont déjà adopté certains éléments de la spécification d'autorisation d'entreprise annoncée en juillet, ce qui en dit long sur la vitesse à laquelle ce protocole s'installe comme standard de facto, un peu à la façon dont HTTP ou OAuth2 se sont imposés en leur temps.
Pour un dirigeant de PME ou d'ETI qui envisage de connecter un agent IA à ses outils internes, cette feuille de route est un signal utile : le protocole sur lequel repose une bonne partie de l'écosystème agentique actuel n'est plus un prototype de laboratoire, il se dote d'une gouvernance, d'une politique de compatibilité et d'un calendrier de sécurité pensé pour l'entreprise. C'est exactement le type de maturité qu'il faut regarder avant de brancher un agent autonome sur des données sensibles.
Reste une question ouverte : la cadence. Le protocole a livré sa plus grosse révision en juillet, publié sa feuille de route en août, et le prochain cycle de spécification s'annonce déjà chargé sur cinq fronts en parallèle. À ce rythme, les équipes qui maintiennent des serveurs MCP en production vont devoir suivre les mises à jour d'aussi près que celles d'un framework web classique — un changement d'habitude pour un écosystème encore jeune, mais probablement inévitable si MCP veut tenir sa promesse de standard universel.
