MCP 2026-07-28 : ce que le stateless change pour déployer des agents IA en entreprise

Le Model Context Protocol (MCP) s’impose progressivement comme une couche d’intégration entre les agents IA et les systèmes qu’ils utilisent : APIs, bases documentaires, services cloud, applications métiers ou outils d’administration.

La révision MCP 2026-07-28 introduit une évolution architecturale importante : le cœur du protocole devient stateless.

Concrètement, MCP passe d’un modèle reposant sur une session protocolaire à un modèle dans lequel chaque requête contient les informations nécessaires à son traitement. L’objectif est notamment d’améliorer la fiabilité et la montée en charge des serveurs MCP.

Pour les architectes, cloud engineers, DevOps et administrateurs, ce changement a des conséquences directes sur le load balancing, les gateways, les sessions, le cache et la sécurité.

Mais une distinction est essentielle :

Un protocole MCP stateless ne signifie pas que l’application métier devient stateless.

De la session MCP à des requêtes indépendantes

Dans les versions précédentes du protocole, un client commençait généralement par un échange initialize afin de négocier notamment la version du protocole et les capabilities.

Une session MCP pouvait ensuite être maintenue entre les échanges.

Conceptuellement :

Agent
  │
  │ initialize
  ▼
Load Balancer
  │
  ▼
MCP Server A
  │
  └── état de session

Dans une architecture comportant plusieurs instances, ce modèle pouvait imposer de maintenir l’état de session sur une instance particulière, de partager cet état ou d'utiliser une forme d’affinité de session.

Avec MCP 2026-07-28, l’échange initialize / initialized et le header Mcp-Session-Id disparaissent du cœur du protocole.

Chaque requête devient autonome et transporte notamment sa version de protocole et les informations du client. Un client qui souhaite connaître préalablement les capabilities d’un serveur peut utiliser le nouvel appel server/discover, mais cet appel n’est pas obligatoire.

L’architecture peut alors ressembler à :

                         ┌── MCP Server A
                         │
Agent ──► Load Balancer ─┼── MCP Server B
          / API Gateway  │
                         └── MCP Server C

Une requête peut être traitée par n’importe quelle instance compatible.

C’est une propriété particulièrement intéressante pour les architectures horizontales utilisant autoscaling, containers ou Kubernetes.

Stateless ne signifie pas « sans état »

C’est probablement le point le plus important à retenir.

La suppression de la session concerne l’état du protocole MCP, pas nécessairement l’état de l’application appelée.

Prenons un tool :

create_support_ticket

Le serveur MCP n’a plus besoin d’une session protocolaire pour identifier la succession des requêtes.

En revanche, le système de ticketing doit toujours conserver :

le ticket ;
son propriétaire ;
son statut ;
les droits d’accès ;
son historique.

L’architecture réelle reste donc souvent :

Agent
  │
  ▼
API Gateway / Load Balancer
  │
  ├────► MCP Server A ──┐
  ├────► MCP Server B ──┼──► API métier ──► Database
  └────► MCP Server C ──┘

La spécification prévoit d’ailleurs explicitement qu’une application puisse conserver un état entre plusieurs appels. Elle recommande alors de matérialiser cet état explicitement — par exemple via un identifiant retourné par un tool — plutôt que de le cacher dans une session de transport.

Le changement architectural est donc plus précisément :

découpler l’état métier de la session protocolaire MCP.

Des requêtes auto-descriptives

La révision 2026-07-28 rend également les requêtes plus faciles à identifier au niveau HTTP.

Pour un appel de tool, on retrouve par exemple :

MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: searchProducts

Les métadonnées du corps de la requête transportent également les informations de version et de client. AWS AgentCore documente le même modèle pour les gateways utilisant cette révision.

Cette évolution est importante pour les infrastructures intermédiaires.

Une gateway peut désormais identifier :

Mcp-Method = tools/call
Mcp-Name   = deleteResource

sans devoir interpréter en profondeur le payload JSON-RPC.

Elle peut ainsi utiliser ces informations pour effectuer du routage, de l’observabilité ou appliquer certaines politiques d’accès.

Cela ne signifie cependant pas que les headers assurent la sécurité à eux seuls.

Authentification, autorisation et validation côté serveur restent indispensables.

Ce que cela change pour le load balancing

Le principal bénéfice du stateless apparaît lorsque plusieurs instances MCP sont placées derrière un load balancer.

Dans un modèle dépendant d’une session :

Client 1 ──► LB ──► Server A
                      ↑
                   session

Client 2 ──► LB ──► Server B
                      ↑
                   session

le routage d’une requête vers une autre instance peut nécessiter de reconstruire ou partager l’état associé.

Avec 2026-07-28 :

Request 1 ──► Server A
Request 2 ──► Server C
Request 3 ──► Server B

Le protocole est conçu pour qu’une requête puisse arriver sur n’importe quelle instance derrière un load balancer classique, sans stockage partagé imposé par MCP.

Pour Kubernetes, des services serverless ou des groupes d’instances autoscalées, cela réduit donc la nécessité d’utiliser des sticky sessions uniquement pour satisfaire le protocole MCP.

Mais cela ne permet pas de supprimer automatiquement toutes les sticky sessions.

Un serveur peut toujours conserver un état applicatif local.

La question à poser avant toute modification devient donc :

Mon implémentation conserve-t-elle un état local nécessaire entre deux appels ?

Les gateways prennent une place plus importante

Les headers Mcp-Method et Mcp-Name rendent MCP plus exploitable derrière des infrastructures HTTP existantes.

Une architecture d’entreprise peut par exemple adopter le modèle suivant :

Agents
   │
   ▼
Identity Provider
   │
   ▼
API / MCP Gateway
   │
   ├──► MCP Finance
   ├──► MCP Infrastructure
   └──► MCP Knowledge

La gateway peut devenir un point commun pour :

Authentification
       │
Autorisation
       │
Rate limiting
       │
Routage
       │
Journalisation
       │
MCP Servers

La révision 2026-07-28 facilite notamment le routage ou l’autorisation à partir des headers exposant la méthode MCP et, lorsque cela s’applique, le nom du tool, de la resource ou du prompt.

Cela ne doit toutefois pas conduire à concentrer toute la sécurité dans la gateway.

Les systèmes métiers doivent continuer à vérifier les permissions réellement accordées à l’identité appelante.

Le least privilege doit aussi s’appliquer aux agents

Un tool :

get_vm_status

n’expose évidemment pas le même niveau de risque que :

delete_vm

ou :

modify_firewall_rule

Une architecture d’agents d’entreprise doit donc distinguer plusieurs niveaux de contrôle :

Identité
   ↓
Tools accessibles
   ↓
Autorisation métier
   ↓
Approbation éventuelle

Microsoft Foundry recommande par exemple de définir une allow list avec allowed_tools et d’exiger une approbation pour les opérations à haut risque, notamment celles qui modifient des données ou des ressources.

Foundry permet également de configurer require_approval globalement ou pour certains tools.

Le principe dépasse largement Microsoft :

Un agent ne devrait accéder qu’aux tools nécessaires à sa mission.

Il s’agit simplement d’appliquer le principe de least privilege à l’IA agentique.

Les catalogues de tools deviennent plus facilement cacheables

La révision 2026-07-28 apporte également des mécanismes permettant aux réponses de type liste de fournir des indications de cache ainsi qu’un ordre déterministe.

Cela concerne notamment les catalogues de tools.

Conceptuellement :

Agent
  │
  ├── tools/list ──► MCP Server
  │                    │
  │◄──── catalogue ────┘
  │
  ├── cache local
  │
  └── tools/call

Cela peut réduire le nombre d’appels répétés de découverte et contribuer à stabiliser les représentations envoyées aux modèles.

Il faut néanmoins prévoir une stratégie d’invalidation cohérente.

Un catalogue conservé trop longtemps pourrait continuer à référencer un tool supprimé ou ne pas exposer immédiatement un nouvel outil.

Comment gérer les interactions en plusieurs étapes ?

Stateless ne signifie pas qu’une interaction doit nécessairement se limiter à un seul aller-retour.

MCP 2026-07-28 introduit le modèle Multi Round-Trip Requests (MRTR) pour les opérations qui nécessitent plusieurs interactions.

Par exemple, un tool peut avoir besoin :

d’une confirmation utilisateur ;
d’un paramètre manquant ;
ou d’une information supplémentaire.

Le serveur peut alors retourner un résultat indiquant qu’une entrée supplémentaire est nécessaire. Le client réexécute ensuite l’appel en transmettant les réponses demandées.

Conceptuellement :

Client ───── requête ─────► Server
Client ◄── input_required ─ Server

        utilisateur
             │
             ▼

Client ── nouvelle requête ─► Server
       + réponses demandées

La continuation devient explicite plutôt que dépendante d’une connexion bidirectionnelle maintenue ouverte.

Une migration doit commencer par la compatibilité

Passer à 2026-07-28 ne consiste pas simplement à modifier une chaîne de version.

Une architecture réelle contient souvent plusieurs couches :

Agent
  ↓
SDK MCP
  ↓
Reverse Proxy
  ↓
Gateway
  ↓
MCP Server
  ↓
Application métier

Tous ces composants peuvent évoluer à des rythmes différents.

La première étape consiste donc à construire une matrice de compatibilité :

ComposantÀ vérifier
Client / agent	Support de `2026-07-28`
SDK MCP	Révision réellement supportée
MCP Server	Support du modèle stateless
Reverse proxy	Conservation des headers MCP
Gateway	Versions MCP acceptées
Authentification	Compatibilité avec les nouveaux échanges
Load balancer	Dépendances aux sticky sessions
Application	État local conservé entre appels
Observabilité	Journalisation des nouvelles métadonnées

Amazon Bedrock AgentCore Gateway constitue un exemple intéressant de coexistence des versions : AWS documente actuellement le support de 2026-07-28, 2025-11-25, 2025-06-18 et 2025-03-26.

Une infrastructure peut donc devoir supporter temporairement plusieurs générations de clients.

Une méthode de migration progressive

Pour une plateforme MCP existante, il est préférable d’éviter une bascule globale.

Commencez par inventorier les clients, SDK, serveurs, proxies et gateways.

Identifiez ensuite toutes les dépendances à une session ou à un état conservé localement.

Testez alors deux requêtes successives envoyées vers deux instances différentes :

Request A ──► Instance 1
Request B ──► Instance 2

Le résultat fonctionnel doit rester correct.

Vérifiez ensuite que les proxies et gateways conservent correctement :

MCP-Protocol-Version
Mcp-Method
Mcp-Name

lorsque ces headers sont requis.

Testez enfin :

l’authentification ;
les autorisations ;
les interactions Multi Round-Trip ;
le cache des listes ;
les erreurs et timeouts ;
le scaling horizontal ;
les opérations nécessitant une approbation ;
le rollback vers la version précédente.

Checklist avant passage à MCP 2026-07-28

Avant de considérer la migration comme terminée :

vérifier le support de 2026-07-28 par le client, le SDK, le serveur et les gateways ;
identifier toute dépendance cachée à une session MCP ;
tester plusieurs instances derrière le load balancer ;
vérifier la transmission des headers MCP ;
tester server/discover si la découverte préalable des capabilities est utilisée ;
définir la stratégie de cache des catalogues ;
tester authentification et autorisation ;
limiter les tools accessibles à chaque agent ;
imposer une approbation pour les opérations à risque lorsque nécessaire ;
journaliser les invocations de tools sensibles ;
tester les interactions Multi Round-Trip ;
valider une procédure de rollback.

Conclusion

MCP 2026-07-28 ne se résume pas à la suppression d’une session.

Le passage à un cœur stateless rapproche MCP des architectures cloud modernes : requêtes indépendantes, instances interchangeables, load balancing horizontal et gateways capables de prendre certaines décisions à partir des métadonnées HTTP.

Mais deux raccourcis doivent absolument être évités :

stateless protocol ≠ stateless application

stateless ≠ security by default.

L’état métier doit toujours être géré explicitement. Les identités et permissions restent indispensables. Les tools sensibles doivent être limités et, lorsque le risque le justifie, soumis à approbation.

Avant toute migration, la bonne question n’est donc pas :

« Puis-je supprimer mes sessions ? »

mais :

« Où se trouve réellement l’état de mon architecture, et quels composants en dépendent encore ? »

C’est cette cartographie qui permet de profiter des bénéfices de MCP 2026-07-28 sans transformer une simplification du protocole en problème d’architecture.