MCP passe en mode stateless : ce que change la spec du 28 juillet 2026

La release candidate du 21 mai 2026 est passée en validation SDK pendant dix semaines. Le 28 juillet 2026, la spec MCP 2026-07-28 est finalisée avec un changement de fond : le protocole devient stateless par défaut. Si tu maintiens un serveur MCP en prod, ce qui suit décrit ce qui bouge côté transport, ce qui casse dans ton code, et comment migrer sans perdre tes intégrations Claude. Pour situer ce sujet dans le reste de l'écosystème, on l'a rattaché au pilier automatiser sa stack avec Claude et MCP et au guide complet Claude 2026.

Ce que dit la spec du 28 juillet 2026, en une lecture

Le changement central est la suppression du handshake initialize / initialized obligatoire et de l'en-tête Mcp-Session-Id imposé au niveau du transport. La spec l'appelle explicitement une architecture stateless : n'importe quelle requête MCP peut atterrir sur n'importe quelle instance de serveur, sans routage sticky et sans magasin de session partagé requis par le protocole lui-même.

Trois autres blocs comptent pour un intégrateur. Les MCP Apps permettent à un serveur de renvoyer des interfaces HTML interactives que le host (Claude Desktop, par exemple) affiche dans un iframe sandboxé. Les Tasks autorisent un serveur à répondre à un appel d'outil par un handle asynchrone plutôt qu'un résultat immédiat. Enfin, six propositions d'évolution alignent l'autorisation sur OAuth 2.0 et OpenID Connect, avec validation du paramètre iss et déclaration du application_type.

Trois fonctionnalités passent en dépréciation annotée seulement : Roots, Sampling, Logging. Elles continuent de fonctionner dans cette version et dans toute release publiée dans les douze mois qui suivent. La politique de cycle de vie garantit un minimum de douze mois entre dépréciation et suppression, donc rien à réécrire dans l'urgence sur ces trois là.

À noter : aucune fonctionnalité nommée « Enterprise-Managed Authorisation » n'existe dans cette spec, malgré ce qui a pu circuler. Les évolutions d'authz sont dans les SEP OAuth citées plus haut.

Pourquoi Anthropic pousse le stateless maintenant

Le protocole MCP de 2024 supposait implicitement une session transport longue. En pratique, ça cassait dès que tu voulais déployer un serveur derrière un load balancer standard : les requêtes du même client devaient atterrir sur la même instance, ou tu perdais l'état d'initialisation. Solutions habituelles : sticky sessions, magasin partagé au niveau du protocole, ou un seul process qui tient tout en RAM. Chacune ferme des portes côté infra.

Passer en stateless débloque trois choses concrètes. Le déploiement sur du serverless (Cloud Run, Lambda, Fly.io Machines) devient viable, avec autoscale à zéro entre les requêtes. Un même binaire peut être placé derrière un load balancer round-robin sans configuration particulière. Et l'empreinte mémoire d'une instance ne dépend plus du nombre de clients connectés, seulement du nombre de requêtes en vol.

Le pattern rejoint ce que fait déjà la plupart des API REST modernes. La différence historique de MCP tenait à son héritage : SSE, transport bidirectionnel, notifications serveur vers client. La spec 2026-07-28 assume qu'on peut retrouver ces usages via des mécanismes explicites (Tasks pour l'asynchrone, resources pour l'état côté client) plutôt que via une session transport implicite.

Ce qui casse concrètement dans tes serveurs MCP existants

Le protocole ne t'oblige plus à casser ton code, mais ton code n'est probablement pas prêt. Les patterns à auditer en priorité :

• Variables globales et singletons au niveau module, en particulier pour les connexions DB, pools HTTP, ou caches d'authentification.
• Handlers de tools qui présument qu'un initialize a été appelé au préalable dans le même process.
• Progress tokens et notifications de progression stockés en mémoire du serveur.
• Subscriptions et resources qui maintiennent une vue côté serveur (liste de fichiers watchés, curseur de pagination).
• Toute logique métier qui suppose que deux appels consécutifs du même client passent par la même instance.

Exemple typique en Python qui casse en stateless :

import psycopg2

_db = None  # état de module, partagé entre requêtes

def get_db():
    global _db
    if _db is None:
        _db = psycopg2.connect(DSN)
    return _db

@server.tool
def query_orders(customer_id: str):
    return get_db().execute("SELECT ... WHERE id = %s", (customer_id,))

Sur un déploiement single-process, ça marche. Sur Cloud Run avec cinq instances qui se partagent le trafic, tu te retrouves avec cinq connexions DB indépendantes, aucune garantie que la même requête client tombe sur la même instance, et des surprises quand tu ajoutes un cache applicatif. Pour détecter ces dépendances cachées, le plus rapide est de démarrer deux instances de ton serveur en local sur des ports différents et de router les requêtes en alternance. Tout ce qui casse dans ce mode cassera en prod.

Migrer un serveur MCP stateful vers stateless : patterns concrets

Trois patterns couvrent la quasi-totalité des cas.

1. Externaliser l'état vers un store partagé. Redis, DynamoDB, ou un KV managé selon ta plateforme. La clé naturelle est le Mcp-Session-Id quand tu en génères un, ou l'identité authentifiée du client. Chaque handler lit et écrit son contexte au début et à la fin de la requête. Coût : quelques millisecondes par appel, plus le prix du store.

@server.tool
def query_orders(customer_id: str, ctx: Context):
    session_id = ctx.headers.get("Mcp-Session-Id")
    state = redis.get(f"mcp:{session_id}") if session_id else {}
    with psycopg2.connect(DSN) as db:
        return db.execute("SELECT ... WHERE id = %s", (customer_id,))

2. Rendre chaque tool idempotent et passer le contexte dans les arguments. Plus simple, plus lisible, et souvent suffisant. Au lieu de mémoriser un curseur de pagination côté serveur, tu le renvoies dans la réponse et tu demandes au client de le repasser. Claude Desktop et l'API Messages gèrent très bien ça, à condition que le schéma du tool soit explicite. Tu supprimes toute une classe de bugs et tu perds peu.

3. Utiliser les resources comme cache côté client. Si tu exposes un catalogue ou un référentiel qui change peu, publie-le comme resource. Le host Claude le récupère, le cache, et le passe en contexte à chaque appel. Ton serveur redevient purement fonction.

Pour aller plus loin sur la construction de serveurs MCP côté Anthropic, tu peux comparer avec les patterns qu'on documente dans notre guide de mise en route serveur MCP et dans notre panorama des serveurs MCP.

Implications pour un déploiement en entreprise

Côté ops, le stateless élargit franchement l'éventail des cibles. Cloud Run, Lambda, Fly Machines, Workers deviennent viables sans bricolage. L'autoscale à zéro rend économiquement raisonnable un serveur MCP interne peu utilisé, ce qui n'était pas le cas avec un process long-running.

Côté sécurité, le Mcp-Session-Id devient un identifiant sensible dès que tu l'utilises pour rehydrater du contexte. Deux options : le signer côté serveur (JWT ou HMAC avec rotation de clé), ou le lier à un token OAuth émis par ton IdP, ce que facilite l'alignement OAuth 2.0 / OIDC des SEP. Le second est plus propre en entreprise parce que tu couples le cycle de vie de la session à celui de l'authentification.

Côté multi-tenant, un même serveur peut désormais servir plusieurs organisations sans qu'un état résiduel entre requêtes ne fuite d'un tenant à l'autre. C'est un pattern courant pour les éditeurs SaaS qui exposent leur produit via MCP à leurs clients. La contrainte se déplace : chaque handler doit valider le scope tenant à l'entrée, sans se reposer sur un contexte de session initialisé une fois.

Sur l'observabilité, chaque requête devient traçable indépendamment. C'est un gain pour le debug ponctuel, mais les logs par session logique demandent une agrégation externe (par Mcp-Session-Id, par utilisateur, ou par trace ID injecté dans les headers). Prévois-le dès la migration, sinon tu perds la lisibilité que t'offrait le mode long-running.

Les arbitrages à faire avant de migrer

Rester stateful reste défendable dans plusieurs cas : serveurs internes single-tenant avec un usage modeste, intégrations qui doivent maintenir une connexion persistante vers un système legacy (WebSocket, session propriétaire), volumes faibles où la complexité d'un store externe coûte plus que le gain d'infra. Rien dans la spec ne t'y force à court terme, la compatibilité descendante est préservée.

Basculer devient l'option raisonnable dès que tu es dans un de ces cas :

Le point de bascule le plus fréquent en pratique : le moment où tu veux exposer ton serveur MCP à plusieurs équipes internes ou à des clients externes. À ce moment-là, le coût du stateful (sticky sessions, provisionnement mémoire, mono-instance) dépasse celui du refactoring.

Checklist de migration en 7 points

1. Auditer les variables globales et singletons : liste chaque état conservé entre requêtes dans ton code actuel.
2. Choisir un store d'état externe adapté à ton volume : Redis pour la vitesse, DynamoDB ou équivalent pour la simplicité opérationnelle.
3. Ajouter la lecture et l'écriture du Mcp-Session-Id dans les handlers qui ont besoin de continuité, et rien de plus.
4. Tester en double-instance locale : lance deux copies de ton serveur, alterne les requêtes, valide qu'aucun comportement ne dépend de la même instance.
5. Valider l'idempotence de chaque tool : appelle-le deux fois avec les mêmes arguments, vérifie que le résultat est cohérent.
6. Mettre en place l'agrégation de logs par session logique dès la bascule, sinon tu perds la traçabilité que t'offrait le mode long-running.
7. Prévoir un rollback vers le mode stateful pendant la période de transition : feature flag sur la gestion d'état, pour revenir en arrière si un client casse.

Passer à la pratique

Le stateless n'est pas un changement de paradigme, c'est un alignement du protocole MCP sur ce que font déjà les API modernes. Le coût de migration est concentré sur ton code, pas sur le protocole, et il est proportionnel à la quantité d'état implicite que tu portes. Pour un serveur écrit récemment avec des tools purs, ça se règle en une journée. Pour un serveur historique avec connexions, subscriptions et caches en mémoire, compte plutôt une itération complète.

Si tu veux structurer cette migration dans un cadre plus large, avec Claude comme copilote sur le refactoring, le déploiement et l'observabilité, on couvre exactement ce type de projet dans Construire votre produit IA en 5 semaines : cinq semaines, dix sessions live, une application déployée à la fin. Pour rester sur du contenu écrit, tu peux aussi consulter notre page sur l'API Anthropic pour l'usage côté serveur, et notre pilier setup si tu pars d'une base plus jeune.