MCP sans état dans la spécification du 2026-07-28 : Quelles modifications pour l’infrastructure des agents ?
La nouvelle version de MCP supprime les sessions, ajoute des en-têtes de routage, des allers-retours input_required et un OAuth plus strict. Ce que cela implique pour les passerelles, l’échelle et la sécurité.
Sources: MCP Goes Stateless: Why the New Spec Changes Agent Infrastructure
Le Model Context Protocol a évolué très rapidement. Au début, les discussions portaient sur le lien entre les applications d’IA et les outils ainsi que les données. Depuis, il a intégré l’autorisation OAuth, des serveurs distants, de grandes révisions du protocole, des registres, des documents de métadonnées d’identifiant de client ainsi que l’autorisation d’entreprise. La spécification 2026-07-28 modifie quelque chose de plus fondamental : le protocole lui-même devient sans état.
La séquence d’initialisation a disparu, tout comme les sessions au niveau du protocole. Un client n’a plus besoin de rester lié à l’instance de serveur qui a accepté sa connexion. Chaque requête contient suffisamment d’informations pour fonctionner de manière autonome, et n’importe quelle instance compatible peut y répondre.
Cela pourrait passer pour une simple modification liée au transport, mais son impact architectural est bien plus profond. Les serveurs distants peuvent se comporter comme n’importe quel service HTTP natif du cloud, situés derrière des balanceurs de charge ordinaires, des passerelles API, des WAF, des plateformes serverless ainsi que des flottes de conteneurs échelonnés, sans nécessiter de mécanismes de session spécifiques à MCP.
La révision apporte également d’autres améliorations : des en-têtes de routage standard, des résultats de découverte pouvant être mémorisés en cache, des requêtes multi-allers-retours, des règles d’autorisation plus strictes, des conventions OpenTelemetry ainsi qu’un modèle d’extension formel. MCP apparaît ainsi moins particulier en tant qu’infrastructure, ce qui constitue probablement l’un des signes les plus évidents de sa maturité. Ce qui suit décrit les changements, l’importance du mode sans état en production et ses implications pour la sécurité, les passerelles et le runtime général des agents.
Pourquoi les sessions posent problème
MCP a vu le jour face à un problème modeste : fournir aux applications d’intelligence artificielle une méthode standard pour gérer des outils, des ressources et des systèmes externes. Cela fonctionnait naturellement pour les clients et serveurs locaux. Mais MCP à distance a changé la donne. Lorsque les serveurs se sont retrouvés dispersés dans des conteneurs, des clusters Kubernetes, des plateformes serverless et des infrastructures cloud, les sessions au niveau du protocole ont provoqué les mêmes difficultés que celles rencontrées avec les systèmes distribués classiques.
Un client effectuait une séquence d’initialisation, le serveur pouvait attribuer un Mcp-Session-Id et chaque requête ultérieure devait conserver cette relation. À grande échelle, cela pouvait entraîner :
- une adhérence du chargeur de balayage
- des stockages de sessions partagés
- un mécanisme de basculement en cas de panne qui prend en compte les sessions
- des connexions à long terme
- une gestion supplémentaire du cycle de vie
Rien de tout cela n’est impossible à gérer, puisque les systèmes distribués s’en occupent depuis des décennies. La question qui se pose est de savoir si MCP avait vraiment besoin de créer ces problèmes, et avec 2026-07-28, la réponse est de plus en plus non.
La nouvelle spécification élimine complètement les étapes initialize et notifications/initialized, les sessions au niveau du protocole ainsi que Mcp-Session-Id. Les requêtes contiennent tout ce qui est nécessaire pour être traitées. Conceptuellement, l’architecture évolue comme suit :
Toute instance compatible peut gérer la requête suivante. Cela convient bien mieux aux systèmes Kubernetes, aux conteneurs, aux fonctions serverless, à l’auto-échellement, aux infrastructures edge ainsi qu’au simple équilibrage de charge par round-robin.
Cela se produit déjà dans la pratique. Cloudflare a déplacé ses serveurs MCP vers ce modèle et crée un serveur sans état entièrement nouveau pour chaque requête. Google a souligné que la fin des sessions persistantes et de l’infrastructure de sessions partagées représente un avantage majeur en termes d’échelle. AWS AgentCore Gateway prend désormais en charge le nouveau protocole en plus des versions précédentes de MCP. Il s’agit donc d’une partie du modèle de déploiement actuel et non d’une architecture théorique.
L’état ne disparaît pas
Une distinction est importante ici. La suppression des sessions MCP n’empêche pas les applications de conserver leur état. Cela signifie que l’état de l’application ne devrait pas être caché à l’intérieur du mécanisme de transport. Prenons l’exemple d’un agent qui crée un espace de travail :
create_workspace()
|
v
workspace_id = ws_123
Une demande ultérieure peut indiquer explicitement le résultat :
update_workspace( workspace_id = "ws_123" )
La première requête peut être traitée par le serveur A et la deuxième par le serveur C. L’application conserve toujours un état, mais elle dispose désormais d’un identifiant explicite et ne dépend plus d’un lien invisible entre un client et un processus serveur.
L’état du protocole et l’état de l’application sont deux choses distinctes. Un état d’application explicite est plus facile à persister, à auditer, à autoriser, à faire expirer et à analyser ; de plus, les systèmes agents bénéficient d’un avantage supplémentaire : l’agent peut traiter directement cet identifiant et le transmettre entre les outils et les étapes du flux de travail.
En-têtes de routage
Le principe d’absence d’état résout un problème d’infrastructure, et un autre changement peut être tout aussi important pour les déploiements d’entreprise. MCP standardise désormais les en-têtes HTTP qui décrivent l’opération en cours. Par exemple :
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: delete_workspace
Auparavant, un intermédiaire devait peut-être ouvrir le chargement JSON-RPC pour savoir ce que l’agent souhaitait. Désormais, les informations sont visibles au niveau HTTP, ce qui ouvre des possibilités intéressantes.
Les équipes de sécurité ont des raisons de s’en soucier. Les agents ont accès à des outils de plus en plus puissants, et le gateway devient un endroit naturel pour appliquer des politiques entre l’intention et l’effet externe. Rien de tout cela ne remplace la nécessité de mécanismes de contrôle au niveau de l’agent ou de l’application. Cela permet plutôt de définir des frontières plus claires entre le protocole, le gateway, les mécanismes de contrôle et les systèmes qui les sous-tendent.
Demander des données sans session
Le passage à un modèle sans état soulève un problème évident : que se passe-t-il si un serveur a besoin de plus d’informations avant de pouvoir terminer une opération ? Imaginez une requête destructrice :
delete_environment(“production”)
Le serveur peut vouloir une confirmation au préalable. Maintenir une session bidirectionnelle ouverte uniquement pour cet échange annulerait une grande partie des avantages liés à l’absence d’état.
La solution proposée dans les spécifications est l’utilisation de demandes multi-allers-retours (MRTR). La session n’est plus nécessaire pour maintenir l’interaction active. Le serveur renvoie plutôt un résultat input_required indiquant ce dont il a besoin. L’échange se déroule approximativement comme suit :
L’approbation humaine, une authentification supplémentaire, l’absence de paramètres, les vérifications de politique et d’autres flux interactifs peuvent tous être intégrés dans un modèle de demande sans état. Cela est particulièrement pertinent pour les actions des agents à haut risque. Le fait de pouvoir appeler une fonctionnalité ne confère pas à un agent des pouvoirs illimités, et les opérations sensibles peuvent inclure un point de décision avant leur exécution.
Mémorisation en cache et observabilité
Certaines modifications moins visibles peuvent s’avérer importantes à grande échelle. Parmi celles-ci, on trouve notamment :
tools/list
prompts/list
resources/list
resources/read
Il est désormais possible de récupérer des détails de cache tels que ttlMs et cacheScope, et la liste des outils doit être renvoyée dans un ordre déterministe. Cela ressemble à une optimisation HTTP ordinaire, mais les systèmes d’IA en bénéficient également : des définitions d’outils stables peuvent améliorer le cache des prompts au niveau du LLM, tandis que des outils arrivant dans un ordre variable ou nécessitant une redécouverte répétée transforment une petite particularité du protocole en retards supplémentaires et en coûts en tokens.
La spécification décrit également comment transmettre le contexte OpenTelemetry, avec des champs familiers :
traceparent
tracestate
baggage
C’est un autre cas où MCP évolue vers des infrastructures déjà connues des équipes DevOps et des équipes de plateforme. L’objectif ne devrait pas être de créer un ensemble d’outils d’observabilité distinct uniquement pour les protocoles d’IA. Il devrait plutôt s’agir de rendre visible l’activité des agents au sein des systèmes que les organisations exploitent déjà.
L’identité devient de plus en plus importante
Les requêtes sans état ne diminuent pas l’importance de l’identité. Elles rendent même essentiel de bien gérer l’identité pour chaque requête. La nouvelle spécification poursuit l’évolution de MCP vers les pratiques établies d’OAuth et d’OpenID Connect. Cela inclut une validation de l’émetteur visant à contrer les attaques de confusion avec les serveurs d’autorisation, ainsi qu’un lien plus strict entre les identifiants et les droits d’accès.
La spécification officialise également une tendance en cours : l’inscription dynamique des clients est désormais obsolète au profit des documents de métadonnées d’identifiant de client. Les CIMD se sont imposés comme l’option la plus propre, tandis que le DCR persiste pour des raisons de compatibilité, et le texte l’indique clairement maintenant. C’est un autre signe de maturité, puisque MCP évite un système d’identité privé et continue de converger vers les normes déjà utilisées sur le Web. Cela est d’autant plus important pour les déploiements d’agents d’entreprise, à mesure que MCP évolue, passant de quelques intégrations autorisées par les utilisateurs à un grand nombre d’agents, de clients, de passerelles et d’outils.
L’enregistrement n’est qu’une partie de l’autorisation. À l’échelle d’une entreprise, la question plus difficile est de déterminer quels agents peuvent accéder à quelles capacités : des centaines d’agents appelant des centaines de services créent un problème de gouvernance de type N×M. Deux mécanismes, l’Autorisation gérée par l’entreprise (EMA) et les Accords d’autorisation par affirmation d’identité (ID-JAG), orientent cette décision vers des politiques centrales de l’entreprise. Un fournisseur d’identités d’entreprise aide à décider si un agent obtient ou non un accès, de sorte que les serveurs MCP individuels n’ont pas besoin de demander l’autorisation aux utilisateurs un par un.
MCP sans état ne remplace pas ce modèle. Il renforce la séparation : l’état de transport, l’identité du client, la politique d’autorisation et l’état de l’application constituent des aspects architecturaux distincts.
Ce qui reste en dehors du noyau
Un aspect important de cette mise à jour concerne ce que MCP supprime ou déplace. Les composants Roots, Sampling et Logging quittent le modèle principal, et le transport HTTP+SSE ancien est remplacé par Streamable HTTP. Un cadre d’extension formel voit le jour en même temps, permettant ainsi à des fonctionnalités comme Tasks de s’enrichir par le biais d’extensions sans alourdir le noyau du protocole. Cela implique des limites plus claires :
MCP n’a pas besoin de devenir l’ensemble de l’environnement d’exécution de l’agent. L’outil de gestion conserve toujours l’environnement d’exécution plus large, et MCP fournit un moyen standard pour que cet environnement interagisse avec des fonctionnalités externes. Un protocole mature n’est défini ni uniquement par ce qu’il ajoute, ni uniquement par ce qu’il décide de placer ailleurs.
Le fait d’être sans état ne signifie pas être fiable
Un serveur MCP sans état s’échelle plus simplement, bien que l’absence d’état ne signifie pas une fiabilité absolue : chaque requête traverse toujours une frontière de sécurité. L’injection de commandes ou un contexte compromis peuvent toujours influencer les agents. Les outils peuvent toujours disposer de privilèges excessifs, les identifiants peuvent encore être mal configurés, et une compromission de la chaîne d’approvisionnement peut toujours introduire des serveurs ou des outils malveillants.
Ce qui change, c’est que l’architecture devient plus claire. Au lieu de considérer les sessions de transport comme faisant partie du modèle de sécurité, les mesures de protection peuvent se concentrer sur l’identité vérifiable de l’appelant, les politiques appliquées par le pare-feu et les permissions accordées par chaque outil. Il convient d’ajouter une autorisation explicite ainsi que des identifiants de ressources explicites, de valider les entrées, d’exiger l’approbation humaine pour les actions sensibles, d’enregistrer des données de telemétrie aux fins d’audit, et de garder également le contrôle de l’agent sous surveillance.
Un point subtil : les métadonnées du client ne constituent pas automatiquement une identité. Ce que le client indique à son sujet dans les métadonnées de la demande ne peut pas être considéré de la même manière qu’une identité établie de manière cryptographique via OAuth ou un autre mécanisme fiable. Un routage et une inspection plus faciles du trafic MCP permettent aux équipes de sécurité de renforcer la mise en œuvre des règles relatives au protocole, sans confondre les métadonnées avec une preuve de confiance.
Le contexte global
Le changement majeur en 2026-07-28 est simple : MCP est sans état. L’aspect plus important réside dans ce que cela permet. Les requêtes MCP se comportent davantage comme des charges de travail HTTP ordinaires. Les serveurs s’échelonnent horizontalement sans affinité de session. Les passerelles comprennent les opérations MCP grâce à des en-têtes standard. La découverte peut être mémorisée en cache. Les workflows interactifs se poursuivent via des requêtes multi-allers-retours. L’autorisation évolue vers les pratiques éprouvées d’OAuth, l’observabilité peut utiliser OpenTelemetry, et les extensions laissent de la marge pour évoluer sans transformer le noyau en l’ensemble du temps d’exécution de l’agent.
Chacun de ces éléments semble être une amélioration du protocole, mais pris ensemble, ils en disent davantage. MCP a commencé par résoudre les problèmes de connectivité. La version distante de MCP a contraint l’écosystème à aborder les questions d’identité et d’autorisation. CIMD et l’autorisation d’entreprise visent désormais la gouvernance, tandis que la version sans état de MCP s’occupe de l’opérabilité et de l’échelle. Ce protocole devient de moins en moins exotique et s’adapte aux infrastructures que les gens savent déjà construire, sécuriser, surveiller et faire fonctionner. Pour quelque chose qui évolue si rapidement, devenir une infrastructure banale pourrait être justement l’objectif final.
Lectures complémentaires
- Notes pratiques : « MCP : Protocole qui transforme l’IA d’un chatbot en un agent IA » — Guide pas à pas des notes pratiques : « MCP : Protocole qui transforme l’IA d’un chatbot en un agent IA » : contrats, vérifications et emplacements de code prêts à l’emploi pour les équipes qui développent des systèmes MCP. —
- Créer un agent de recherche local dans LM Studio avec quatre serveurs MCP — Combinez les serveurs MCP de filesystem, GitHub, SearXNG et Camofox dans une seule conversation de LM Studio, simplifiez le schéma de l’outil, ajoutez une demande de plan de recherche et vérifiez son fonctionnement grâce à une démonstration.