MCP passe stateless : le protocole des agents devient un workload HTTP ordinaire

Le 28 juillet 2026, les mainteneurs du Model Context Protocol ont publié la spécification 2026-07-28, et Anthropic a annoncé le même jour son déploiement progressif dans les produits Claude. La révision supprime l'échange initialize / initialized, supprime l'identifiant de session, et ramène MCP à un protocole requête/réponse. C'est la cinquième révision majeure depuis le lancement de novembre 2024, et celle qui casse le plus de choses.

Le volume d'usage explique l'orientation prise. Anthropic annonce plus de 400 millions de téléchargements mensuels de SDK, quatre fois plus qu'un an auparavant ; le blog MCP évoque de son côté près d'un demi-milliard par mois sur les SDK Tier 1, les paquets TypeScript et Python ayant chacun franchi le milliard de téléchargements cumulés. Le directory de connecteurs de Claude référence plus de 950 serveurs. Le projet est hébergé sous l'égide de la Linux Foundation. À cette échelle, un protocole cesse d'être une convention d'intégration et devient une dépendance d'architecture : il faut le déployer, le router, le mettre en cache, le sécuriser et le déprécier proprement. La révision traite ces cinq points.

La session disparaît du protocole

Jusqu'à cette version, un serveur MCP distant négociait un initialize, puis maintenait un état de session identifié par l'en-tête Mcp-Session-Id. Les équipes qui exploitaient ces serveurs payaient la facture habituelle : du routage collant vers l'instance qui détient la session, ou un stockage d'état partagé entre instances. Le reste du web a passé vingt ans à se débarrasser de cette contrainte.

La spécification 2026-07-28 retire les deux. Chaque requête se décrit elle-même : version du protocole, identité et capacités du client voyagent dans _meta. Un client qui veut connaître les capacités d'un serveur avant d'agir appelle server/discover, un appel optionnel. N'importe quelle requête peut donc atterrir sur n'importe quelle instance derrière un load balancer round-robin, sans stockage partagé. Serverless, edge, Kubernetes standard : déployer un serveur MCP redevient un problème de déploiement web.

Les auteurs prennent soin de poser la limite : retirer la session du protocole n'oblige pas votre application à devenir sans état. Un serveur qui doit porter de l'état entre deux appels fait émettre un handle explicite par un outil, que le modèle repasse ensuite en argument. L'état quitte alors le transport pour rejoindre le domaine. Il devient visible pour le modèle, journalisable pour l'exploitant, et rejouable après incident.

MRTR : l'humain dans la boucle sans connexion maintenue

Si le serveur ne peut plus pousser une requête vers le client sur un flux ouvert, comment lui demander une confirmation en milieu d'appel ? La réponse s'appelle Multi Round-Trip Requests (MRTR), et elle remplace elicitation/create, sampling/createMessage et roots/list. Le serveur répond resultType: "input_required" en listant ce dont il a besoin ; le client rejoue l'appel initial avec les réponses attachées dans inputResponses. Aucun flux à maintenir, et une sémantique de reprise explicite.

Supabase mesure le gain dans les retours partenaires publiés par les mainteneurs : son serveur MCP tournant en mode stateless, l'elicitation ne lui était pas praticable, alors que c'est exactement ce qu'il faut pour faire confirmer par l'utilisateur le coût d'une création de projet ou une requête destructrice. Le garde-fou humain restait jusqu'ici en tension avec la scalabilité. MRTR desserre cette tension.

Ce qui rend MCP exploitable en production

Deux ajouts intéressent surtout les équipes qui exploitent ces serveurs au quotidien.

• Routage par en-têtes. Les requêtes Streamable HTTP portent désormais Mcp-Method et Mcp-Name. Une passerelle, un rate limiter ou un WAF route, autorise et mesure sur ces en-têtes sans parser le corps JSON. L'outillage réseau existant s'applique à MCP tel quel, ce qui évite d'en inventer un nouveau et prolonge directement la logique de passerelle unifiée que nous recommandons pour gouverner une flotte d'agents.
• Listes cacheables. tools/list, prompts/list, resources/list et resources/read portent ttlMs et cacheScope, avec un ordre déterministe. Un catalogue d'outils stable et ordonné garde valide le prompt cache en amont entre deux reconnexions : le gain se lit en latence, et surtout en coût de tokens.

Un cœur stable, des extensions versionnées

La révision formalise un framework d'extensions versionné. Les capacités à forte valeur et à forte volatilité sortent du cœur du protocole :

• MCP Apps : des interfaces interactives rendues par le serveur dans la conversation, en iframe sandboxée.
• Tasks : les travaux longs et asynchrones, avec tasks/get en polling et tasks/update ; les notifications de changement passent par un flux unique subscriptions/listen auquel le client s'abonne par type. AWS a contribué l'extension.
• Enterprise Managed Authorization (EMA) : le provisionnement centralisé des connecteurs via l'IdP de l'organisation.

Le découpage relève autant de la gouvernance que de la conception : un cœur minimal et stable, des extensions libres d'évoluer vite sans casser tout le monde. Une DSI ne se contente plus de suivre une spécification, elle choisit lesquelles de ses extensions elle adopte, et à quel rythme.

L'autorisation, là où se joue l'entreprise

Les mainteneurs le disent sans détour : l'autorisation est le poste où les implémenteurs passent le plus de temps. Le durcissement porte sur quatre points.

Les serveurs d'autorisation doivent retourner le paramètre iss conformément à la RFC 9207, et les clients doivent le valider avant d'échanger le code, ce qui ferme une faille de confusion de serveur d'autorisation. Les clients positionnent application_type lors de l'enregistrement dynamique, ce qui met fin aux rejets de redirections localhost pour les applications desktop et CLI. Les credentials clients restent liés à l'émetteur qui les a créés, sans réutilisation d'un serveur d'autorisation à l'autre. Enfin, le Dynamic Client Registration est formellement déprécié au profit des Client ID Metadata Documents (CIMD).

Un serveur MCP se branche donc sur Entra ou Okta sans contournement. C'était le prérequis manquant pour passer les revues de sécurité des grands comptes, et il complète le travail d'identité des agents que nous décrivons sous le nom de passeport agent.

Ce qui meurt, et quand

Roots, Sampling et Logging sont dépréciés, ainsi que le transport HTTP+SSE historique. Ils continuent de fonctionner, et continueront pendant au moins douze mois : la révision introduit une politique de dépréciation formelle avec une fenêtre minimale d'un an.

Une politique de dépréciation datée permet de planifier une migration au lieu de la subir. Pour un DSI, c'est ce qui sépare une technologie qu'on met en production d'une technologie qu'on regarde passer.

Les quatre SDK Tier 1 (TypeScript, Python, Go, C#) supportent la spécification depuis le jour de l'annonce, avec des notes de migration ; le SDK Rust la supporte en beta. Les mainteneurs ne cachent pas le coût de migration pour les implémentations qui dépendaient des identifiants de session.

Côté Claude

Anthropic déploie le support de la spécification dans les produits Claude et met en avant plusieurs briques déjà livrées cette année : MCP Apps, l'authentification managée pour les entreprises (l'administrateur autorise un connecteur une fois, les utilisateurs héritent de l'accès via leurs groupes IdP), un dashboard d'observabilité pour les connecteurs publiés au directory, et les MCP tunnels en research preview, qui connectent Claude à des serveurs MCP internes sans endpoint public ni règle firewall entrante.

Ce dernier point compte pour les organisations européennes. Brancher un agent sur un SI interne sans surface d'exposition publique change la nature de la conversation avec les équipes sécurité.

Ce que nous en retenons

Le coût d'exposition d'un outil interne baisse d'un cran. Tant qu'un serveur MCP imposait une gestion de session, l'exposer proprement demandait une décision d'architecture. Sur un cœur stateless, la même opération redevient un déploiement HTTP standard servi par l'outillage existant. Multiplier les serveurs MCP internes devient donc viable, là où beaucoup d'organisations s'orientaient vers une passerelle monolithique faute de mieux. C'est le chemin que nous décrivions en passant de l'API-First à l'AI-First, et son ticket d'entrée vient de baisser.

L'état redevient un objet de conception. Matérialiser l'état en handles explicites passés au modèle change la posture des équipes : le contexte sort du transport, l'agent le lit, l'exploitant le trace. Rejouer, auditer et tester un enchaînement d'appels devient possible là où l'état de session rendait ces trois opérations pénibles.

L'interopérabilité gagne du terrain. Des contributeurs d'Anthropic, Google, Microsoft, AWS et Cloudflare ont façonné la spécification, avec un support annoncé dès le premier jour chez plusieurs hébergeurs. Un standard réellement multi-acteurs sur la couche d'accès aux outils protège du verrouillage propriétaire au niveau applicatif. Notre lecture de la guerre des protocoles ne bouge pas sur le fond : MCP consolide la couche outils, A2A garde la couche inter-agents. La question de la souveraineté ne disparaît pas non plus, elle se déplace vers les modèles et les données, là où elle doit se poser.

Que faire maintenant

1. Inventorier vos serveurs MCP et repérer ceux qui dépendent de Mcp-Session-Id : ce sont eux qui portent le coût de migration.
2. Mettre à jour les SDK vers les versions alignées sur 2026-07-28, et lire les notes de migration avant de toucher au code.
3. Remplacer les usages de Roots, Sampling et Logging. Douze mois passent vite.
4. Basculer l'autorisation de DCR vers CIMD, et valider iss côté client.
5. Réévaluer les cas d'usage que le mode stateless rendait impraticables : confirmations utilisateur, tâches longues, interfaces interactives. Ce sont eux qui débloquent des scénarios métier, pas le transport.

Toute nouvelle implémentation gagne à adopter le modèle stateless dès maintenant. La rétrocompatibilité tient douze mois, et elle a une date de fin.

---

Sources

• blog.modelcontextprotocol.io : « The 2026-07-28 Specification », David Soria Parra et Den Delimarsky, 28 juillet 2026 (bascule stateless, MRTR, framework d'extensions, durcissement de l'autorisation, politique de dépréciation, retours partenaires dont Supabase, volumes de téléchargement des SDK Tier 1).
• modelcontextprotocol.io : spécification complète 2026-07-28 et son changelog (suppression de Mcp-Session-Id, _meta, server/discover, en-têtes Mcp-Method et Mcp-Name, ttlMs et cacheScope).
• claude.com : « Bringing MCP 2026-07-28 to Claude », Anthropic, 28 juillet 2026 (déploiement progressif, MCP Apps, authentification managée, dashboard d'observabilité, MCP tunnels, 400 millions de téléchargements mensuels de SDK, plus de 950 serveurs au directory).
• modelcontextprotocol.io/extensions/apps et /extensions/tasks : documentation des extensions MCP Apps et Tasks.
• modelcontextprotocol.io/docs/sdk : état de support des SDK Tier 1 (TypeScript, Python, Go, C#) et du SDK Rust.
• rfc-editor.org : RFC 9207, paramètre iss et défense contre la confusion de serveur d'autorisation.
• platform.claude.com : MCP tunnels en research preview (connexion à des serveurs internes sans endpoint public).
• siliconangle.com : « Biggest ever MCP update brings metadata, cybersecurity enhancements », 28 juillet 2026.
• theregister.com : « MCP gets an enterprise makeover », 29 juillet 2026.
• x.com : David Soria Parra, co-créateur de MCP, sur la portée de la release et ses dix-huit mois de retours communautaires. Voir aussi le thread @ClaudeDevs du 28 juillet 2026.

Note de fiabilité : les volumes de téléchargement de SDK et le nombre de serveurs au directory sont des chiffres auto-déclarés par Anthropic et par les mainteneurs du projet, non audités ; les deux sources ne donnent d'ailleurs pas le même ordre de grandeur (400 millions par mois côté Anthropic, près d'un demi-milliard côté blog MCP sur un périmètre de SDK différent). Le retour Supabase provient des témoignages partenaires sélectionnés et publiés par les mainteneurs. La fenêtre de dépréciation de douze mois est un minimum annoncé, pas une date de fin de support connue. Les lectures « coût d'exposition », « état comme objet de conception » et « interopérabilité » relèvent de l'analyse de SFEIR.