MCP passe au sans état dans sa plus grande mise à jour protocolaire

MModel Context Protocol (MCP)FYI29 juillet 2026Infrastructure
Ce qui s’est passé
Anthropic shipped MCP 2026-07-28 — a stateless rewrite that eliminates sessions, adds header-based routing, and formalizes the extensions framework.
Pourquoi c’est important
MCP servers can now run on standard Kubernetes with conventional load balancers — the missing piece for production-scale enterprise AI agent deployments.
Que faire
If you maintain an MCP server or client, start migration planning now — AWS, Microsoft, Cloudflare, and GitHub are already in production with the new spec.

Anthropic a livré la spécification MCP 2026-07-28 le 28 juillet — la plus grande révision depuis le lancement du protocole en novembre 2024 — et elle change fondamentalement le fonctionnement de MCP : le protocole est désormais sans état (stateless). Fini les handshakes initialize, fini les en-têtes Mcp-Session-Id, fini les sessions persistantes au niveau du load balancer. Chaque requête porte désormais sa propre version de protocole, son identité client et ses capacités dans _meta. N'importe quelle requête peut atterrir sur n'importe quelle instance de serveur derrière un simple load balancer round-robin. C'est la mise à jour qui fait de MCP une infrastructure d'entreprise prête pour la production.

Ce qui s'est passé

Le cœur sans état fait la une, mais la spec 2026-07-28 livre six changements majeurs d'un coup :

  • Plus de handshake ni de sessions. L'échange initialize/initialized et l'en-tête Mcp-Session-Id sont retirés. Chaque requête est auto-descriptive — les clients qui ont besoin des capacités du serveur en amont appellent le nouveau RPC server/discover, mais il est optionnel. Les serveurs MCP peuvent désormais fonctionner sur des déploiements Kubernetes conventionnels avec des load balancers standard et sans magasins Redis partagés (Anthropic, 2026).
  • Requêtes multi-allers-retours (MRTR). Les interactions serveur-vers-client comme l'élicitation et le sampling ne nécessitent plus un flux SSE maintenu ouvert. Le serveur renvoie resultType: "input_required" avec un jeton opaque requestState, et le client réessaie l'appel original avec les réponses de l'utilisateur. N'importe quelle instance de serveur peut prendre en charge la relance (Anthropic, 2026).
  • Routage par en-têtes. Chaque requête HTTP Streamable expose désormais Mcp-Method et Mcp-Name dans des en-têtes standard. Les passerelles API, les limiteurs de débit et les WAF peuvent router, limiter et mesurer sur les seuls en-têtes — sans avoir à inspecter le corps JSON. Les métriques de disponibilité et de latence deviennent également des en-têtes de réponse standard (Anthropic, 2026).
  • Cadre d'extensions formel. Les extensions ne sont plus du texte libre. La spec établit des catégories standard — Authentification, Transport, Types de Capabilités, Types de Protocole — avec exigences de documentation et de compatibilité. Les extensions tierces passent d'expérimentales à interopérables (Anthropic, 2026).
  • Streamable HTTP par défaut. Streamable HTTP est désormais le transport standard unique. Les Meta-Messages (_meta) documentent des détails de protocole comme la version et les capacités. Les Résumés au niveau du lot agrègent les entrées/sorties de lots d'outils. Les Notifications ont des définitions standard (Anthropic, 2026).
  • Compatibilité ascendante et migration. La spec définit des chemins de transition explicites pour les serveurs et clients existants. Des Meta-Messages côté serveur exposent la version de spec supportée. Côté client, les adaptateurs d'outils enveloppent les fournisseurs de transport non-HTTP, et les points de terminaison disponibles publient la couverture de migration (Anthropic, 2026).

Pourquoi c'est important

Dire que c'est important est un euphémisme. MCP est le protocole qui relie les agents IA aux outils et aux données, et jusqu'à présent, il avait un problème fondamental de mise à l'échelle. Les sessions persistantes — le mécanisme que presque toutes les implémentations MCP utilisaient pour maintenir l'état entre les appels — empêchaient un déploiement standard dans les environnements d'entreprise.

La version sans état résout trois problèmes qui rendaient MCP fragile :

ProblèmeAvant 2026-07-28Après 2026-07-28
Mise à l'échelleChaque session devait atterrir sur la même instance de serveur — le sticky-session routing empêchait le scaling horizontal standardLes requêtes sont sans état ; n'importe quelle instance peut les traiter. Fonctionne avec un simple round-robin de load balancer
RésilienceUne panne de serveur = sessions perdues, obligeant les clients à réinitialiserPas de sessions à perdre, les requêtes échouées sont réessayées sur l'instance suivante
ObservabilitéPas de métriques standard au niveau de la requête — les équipes instrumentaient ad hocMétriques de disponibilité et de latence dans les en-têtes de réponse standard, plus Mcp-Method et Mcp-Name dans les en-têtes de requête

L'adoption par l'industrie est déjà réelle. AWS a annoncé le support de la spécification dans Agents for Bedrock le jour du lancement. Microsoft l'a intégrée à Copilot Studio le 28 juillet. Cloudflare a déployé Workers MCP le 28 juillet. GitHub a mis à jour Copilot Extensions. Ce n'est pas une spec qui cherche des adoptants — c'est une spec que les fournisseurs de plateforme déploient en production le jour de la sortie.

Ce que cela signifie pour les équipes

Si vous maintenez un serveur ou un client MCP, le plan de migration est désormais votre problème le plus urgent. La spec sans état n'est pas facultative — c'est le chemin de mise à niveau vers les environnements d'entreprise, et les fournisseurs de plateforme se déplacent déjà.

Commencez par :

  1. Auditez votre base actuelle de serveurs et clients MCP pour identifier les dépendances aux sessions
  2. Priorisez les serveurs qui gèrent des interactions multi-allers-retours (élicitation, sampling) — ils nécessitent le plus de refonte
  3. Planifiez la migration HTTP Streamable comme transport par défaut
  4. Cartographiez vos points d'extension par rapport aux catégories formelles du nouveau cadre

La politique de dépréciation compte aussi : la spec définit des chemins de transition explicites. Les équipes qui restent bloquées entre l'ancien et le nouveau style de transport ne sont pas laissées sans issue — les adaptateurs d'outils côté client enveloppent les fournisseurs non-HTTP pour maintenir la compatibilité pendant la transition.

Ce qui nous attend

La spécification sans état rend possibles trois changements architecturaux que MCP ne pouvait pas gérer auparavant :

  1. Applications d'agents IA multi-tenant. Le scaling horizontal sans état signifie qu'un seul cluster MCP peut servir plusieurs clients organisationnels sans risque de fuite de sessions ni aiguillage complexe
  2. Architectures agent-à-agent. Le routage par en-têtes et MRTR permettent une composition où les agents s'appellent via MCP sans qu'aucun ne possède la session
  3. Déploiements bare-metal Kubernetes. Plus besoin de déploiements MCP spécialisés — les mêmes clusters, load balancers et outils d'observabilité que le reste de votre infrastructure

Résultat : MCP 2026-07-28 n'est pas une mise à jour de spécification — c'est le jour où MCP est passé du statut de protocole de laboratoire à celui d'infrastructure d'entreprise. Les équipes qui planifient leur migration maintenant auront des déploiements d'agents IA prêts pour la production quand le reste de l'industrie rattrapera son retard.

Outils et modèles concernés

Model Context Protocol (MCP)

Ne ratez plus jamais une mise à jour

Le récap hebdomadaire : uniquement les changements de verdict et les actions urgentes. Sans remplissage.

En vous abonnant, vous acceptez notre Politique de confidentialité. Désabonnement à tout moment.