MCP change de squelette : ce que la refonte 2026 du protocole va casser chez toi

Bon. Si t’as déjà un ou plusieurs serveurs MCP qui tournent en prod, j’ai une mauvaise et une bonne nouvelle.

La mauvaise : le protocole sur lequel tu t’es appuyé change de fondations. Pas un patch, un vrai refactor.

La bonne : une bonne partie de ce refactor, c’est exactement le genre de dette technique que tout le monde se plaignait de devoir gérer soi-même — sticky routing, sessions à trimballer entre instances, ce genre de trucs pénibles. Là, le protocole s’en charge à ta place.

Je précise tout de suite un truc important : on est le 12 juillet 2026. La spec finale de cette révision est annoncée pour le 28 juillet. Donc au moment où j’écris ça, c’est une release candidate, pas un texte figé. Je vais rester honnête sur ce statut tout du long, parce que je trouve ça un peu dingue de voir des gens réagir à des RC comme si c’était déjà gravé dans le marbre.

Le vrai changement : MCP devient stateless au niveau du protocole

Jusqu’ici, un client MCP faisait un handshake initialize/initialized, récupérait un Mcp-Session-Id, et devait ensuite router systématiquement vers la même instance de serveur pour garder son contexte. Si t’as déployé plusieurs instances derrière un load balancer, tu connais la douleur : routing collant, store de session partagé, tout le folklore habituel des applis stateful.

La RC supprime carrément ce mécanisme au niveau du protocole. Plus de handshake d’initialisation, plus de header de session. Chaque requête devient auto-suffisante, avec ses métadonnées embarquées directement dedans.

Concrètement : “any MCP request can land on any server instance, and the sticky routing and shared session stores that horizontal deployments needed before are no longer required at the protocol layer.” Traduction : ton load balancer peut redevenir un bête round-robin, plus besoin d’affinité de session, plus besoin d’inspecter profondément le trafic pour router — tu peux même router sur un simple header Mcp-Method.

Si ton serveur avait besoin d’état, il faut migrer vers un pattern de handle explicite : le serveur génère un identifiant (un basket_id, un browser_id, peu importe le nom) et le modèle le repasse comme un argument ordinaire aux appels suivants. En gros, ce que les APIs HTTP font depuis toujours. L’état redevient visible pour le modèle, plutôt que planqué dans une session invisible côté serveur.

C’est là que se situe le vrai chantier de migration si tu as un serveur MCP qui compte sur des sessions implicites aujourd’hui. Si ton serveur garde de l’état en mémoire attaché à une session, il va falloir le réécrire pour qu’il expose cet état via un handle explicite. Ce n’est pas dramatique, mais ce n’est pas non plus un simple bump de version dans ton package.json.

Ce qui devient plus simple à opérer

Je vais pas faire genre je suis contre. Franchement, pour qui a déjà galéré à faire scaler un serveur MCP stateful derrière plusieurs pods, cette partie du refactor est une bonne nouvelle. Ne plus dépendre d’un store de session partagé, ne plus avoir besoin de sticky routing, ça simplifie sérieusement l’observabilité et le scaling horizontal. Tu peux traiter un serveur MCP comme n’importe quel service HTTP stateless : n’importe quelle instance répond, tu scales avec des replicas basiques, ton monitoring redevient standard.

C’est le genre de changement qui, sur le papier, sonne comme un détail d’architecture. Sur le terrain, ça veut dire moins d’incidents “cette requête a atterri sur la mauvaise instance et a perdu son contexte”.

Les extensions : Tasks casse, MCP Apps ouvre une nouvelle surface

Deux extensions sortent officiellement avec cette révision.

Tasks, d’abord. Si t’avais déjà branché l’API expérimentale de tasks de la révision 2025-11-25, prépare-toi : c’est un breaking change. Le nouveau lifecycle demande au client de le piloter avec tasks/get, tasks/update et tasks/cancel. Donc si t’as codé contre l’ancienne API expérimentale, il va falloir migrer.

MCP Apps, ensuite. C’est la nouveauté qui m’intéresse le plus, et aussi celle qui m’inquiète un peu. Ça permet à un serveur de renvoyer des interfaces HTML rendues côté serveur, que le client affiche dans un iframe sandboxé. En clair : ton serveur MCP peut désormais pousser de l’UI, pas juste des données ou des appels d’outils.

C’est pratique. Mais ça déplace la surface de risque. Un serveur MCP qui renvoyait du texte ou du JSON, tu peux l’auditer relativement facilement. Un serveur qui renvoie du HTML rendu dans une iframe, même sandboxée, c’est une nouvelle classe de review à ajouter à ta checklist de sécurité — que ce soit pour ton propre serveur ou pour ceux que tu connectes depuis des tiers. Si tu bosses avec des serveurs MCP externes non maîtrisés, ce point mérite clairement d’être sur ta liste de vigilance avant d’activer l’extension.

Auth : plus rigide, mais plus standard

Six propositions alignent l’autorisation MCP sur les pratiques OAuth 2.0 et OpenID Connect : validation du paramètre iss selon la RFC 9207, déclaration de application_type en Dynamic Client Registration, et un binding des credentials à l’autorité d’émission. Rien de révolutionnaire si t’as déjà bossé avec de l’OAuth sérieux ailleurs, mais si ton implémentation actuelle est un peu artisanale sur ce volet, il va falloir la muscler pour rester conforme.

Trois trucs qui partent en dépréciation, sans urgence

Roots, Sampling et Logging entrent en dépréciation formelle. Roots se fait remplacer par les paramètres d’outils, les URIs de ressources ou la config serveur. Sampling par une intégration directe avec l’API du fournisseur LLM. Logging par stderr en stdio, ou OpenTelemetry pour de l’observabilité structurée.

Bonne nouvelle : la politique de dépréciation impose un minimum de douze mois entre l’annonce et le retrait effectif. Dans cette révision, ce sont des dépréciations “annotation-only” — donc rien qui casse aujourd’hui. Mais si t’utilises ces trois features, c’est le moment de planifier la migration plutôt que de te faire surprendre dans un an.

Ce que je ferais, concrètement

Vu qu’on est encore sur une RC et que le texte final est attendu pour le 28 juillet, je ne me précipiterais pas à tout réécrire cette semaine. La fenêtre de dix semaines entre le verrouillage de la RC (21 mai) et la sortie finale existe justement pour que les mainteneurs de SDK et les implémenteurs valident sur de vraies charges — donc les SDK officiels devraient absorber une bonne partie de la complexité de migration.

Ce que je surveillerais activement : est-ce que mon serveur dépend de sessions implicites (migration à prévoir vers des handles), est-ce que j’utilisais l’API Tasks expérimentale (breaking change confirmé), et est-ce que je compte activer MCP Apps un jour (nouvelle surface à auditer, pas à activer par défaut sans réflexion).

Et surtout : je vérifierais le texte final le 28 juillet avant de migrer quoi que ce soit en prod. Une RC, ça bouge encore. J’avais déjà creusé l’écosystème des serveurs MCP dans MCP servers, la vraie surprise de 2026, et la même règle s’applique ici : c’est un protocole qui mûrit vite, mais qui mûrit encore.

Sources

• MCP Specification 2026-07-28 Release Candidate — blog.modelcontextprotocol.io
• Model Context Protocol — modelcontextprotocol.io