MCP passe en mode stateless : ce que la spec 2026-07-28 change pour vos serveurs

Deux semaines après sa publication, la révision 2026-07-28 du Model Context Protocol occupe déjà l’essentiel des discussions d’outillage agentique — et pour une fois, ce n’est pas un effet d’annonce. Les changements touchent le modèle d’exécution du protocole, pas sa surface d’API. Si vous exploitez des serveurs MCP en production, la question n’est plus « faut-il migrer ? » mais « dans quel ordre démonter les hypothèses que la spec précédente autorisait ? ».

Rappel express : ce que MCP résout, et pourquoi cette révision est une rupture

MCP normalise la manière dont un modèle (ou plutôt son hôte : IDE, agent, orchestrateur) découvre et invoque des capacités externes — tools, resources, prompts — via JSON-RPC 2.0 sur un transport stdio ou HTTP. L’intérêt est trivial à énoncer : un serveur écrit une fois, consommé par n’importe quel client conforme, sans intégration ad hoc par fournisseur de modèle.

Le problème, jusqu’ici, était ailleurs. Le transport « Streamable HTTP » introduit en 2025 restait fondamentalement orienté session : le serveur pouvait émettre un identifiant de session, le client devait le renvoyer, et l’état de connexion conditionnait la validité des échanges — notifications, streaming SSE, reprise après coupure. Cette conception, héritée du modèle stdio local, s’est révélée hostile à tout déploiement réaliste : affinité de session obligatoire sur le load balancer, état en mémoire à répliquer, incompatibilité de fait avec les runtimes serverless à cycle de vie court.

La révision 2026-07-28 tranche : le cœur du protocole devient stateless. Le reste des nouveautés découle largement de cette décision.

Le cœur stateless : MCP redevient une charge HTTP ordinaire

Concrètement, un serveur conforme au cœur 2026-07-28 n’a plus besoin de maintenir quoi que ce soit entre deux requêtes. Chaque appel porte le contexte nécessaire à son traitement : version de protocole, identité, paramètres. Une requête d’outil ressemble désormais à ce qu’un ingénieur backend attend d’une API HTTP :

POST /mcp HTTP/1.1
Host: mcp.exemple.internal
Content-Type: application/json
Accept: application/json, text/event-stream
MCP-Protocol-Version: 2026-07-28
Authorization: Bearer <access_token>

{
  "jsonrpc": "2.0",
  "id": "42",
  "method": "tools/call",
  "params": {
    "name": "search_incidents",
    "arguments": { "service": "billing", "since": "2026-08-01" }
  }
}

Les conséquences opérationnelles sont immédiates :

• Scaling horizontal sans affinité. Plus besoin de sticky sessions ni de cookie de routage : n’importe quelle instance peut traiter n’importe quelle requête. Vos règles de load balancing redeviennent triviales (round-robin, least-connections).
• Serverless viable. Un serveur MCP peut vivre dans une Lambda, une Cloud Run ou un Worker, avec un cold start acceptable puisqu’il n’y a plus de handshake de session à reconstituer.
• Observabilité normale. Une requête = une trace. Les corrélations par session, jusqu’ici nécessaires pour reconstruire un appel, deviennent optionnelles.
• Résilience. Le redémarrage d’une instance ne casse plus d’échange en cours autre que celui qu’elle traitait.

Attention : stateless qualifie le protocole, pas votre domaine métier. Un serveur qui expose un panier, une transaction ou un curseur de pagination gère toujours cet état — mais il le fait dans son backing store, avec sa propre sémantique, et non via une couche de session imposée par MCP. C’est précisément la séparation qui manquait.

Multi Round-Trip Requests et routage par headers

Le stateless posait une question évidente : comment gérer les interactions qui exigent plusieurs allers-retours — élicitation d’un paramètre manquant, demande de sampling auprès du client, confirmation utilisateur avant une action destructive ?

La réponse est le mécanisme de Multi Round-Trip Requests : une requête peut donner lieu à un échange en plusieurs étapes explicitement chaînées, sans que le serveur ait à conserver un contexte implicite. Le lien entre les étapes est porté par la requête elle-même, ce qui rend chaque tour d’échange auto-suffisant et routable indépendamment.

Le routage par headers complète le dispositif. Les métadonnées nécessaires à l’aiguillage — version de protocole, corrélation, cible logique — remontent au niveau HTTP, là où les infrastructures savent les lire. Un reverse proxy, un service mesh ou une API gateway peut router, autoriser ou limiter le débit sans parser le corps JSON-RPC, ce qui était jusqu’ici un anti-pattern coûteux et fragile.

# Aiguillage vers un pool dédié selon la version de protocole négociée,
# sans inspection du payload JSON-RPC
map $http_mcp_protocol_version $mcp_pool {
    default          mcp_legacy;
    "2026-07-28"     mcp_stateless;
}

location /mcp {
    proxy_pass http://$mcp_pool;
}

Ce détail apparemment mineur est ce qui rend un déploiement MCP gouvernable par une équipe plateforme avec l’outillage qu’elle possède déjà.

Des résultats de listes cacheables

tools/list, resources/list et prompts/list sont appelés à chaque initialisation de session client, souvent plusieurs fois par minute dans un IDE. Leur résultat est pourtant quasi statique et, surtout, il est réinjecté dans le contexte du modèle : sur un serveur exposant quelques dizaines d’outils richement documentés, cela représente une part non négligeable de la fenêtre de contexte, payée à chaque tour.

La révision rend ces résultats explicitement cacheables, avec une sémantique de validation. Le client peut donc conserver la liste et se contenter d’une revalidation :

GET /mcp/tools HTTP/1.1
MCP-Protocol-Version: 2026-07-28
If-None-Match: "tools-v17-9f3ac1"

HTTP/1.1 304 Not Modified
ETag: "tools-v17-9f3ac1"
Cache-Control: max-age=300

Deux bénéfices, tous deux mesurables chez vous plutôt que dans une brochure : la latence de démarrage d’une session client s’effondre (plus d’aller-retour complet ni de sérialisation de schémas JSON volumineux), et le coût en tokens de la re-déclaration des outils disparaît tant que le cache est valide. Côté serveur, pensez à faire dériver votre validateur d’un hash du catalogue effectif et des droits de l’appelant : deux utilisateurs avec des périmètres RBAC différents ne doivent pas partager la même entrée de cache.

Tasks et MCP Apps : deux primitives, deux problèmes distincts

Tasks répond à un manque criant : les opérations longues. Jusqu’ici, un outil qui déclenche un build, une migration de schéma ou un scan de sécurité devait soit bloquer la requête, soit inventer sa propre convention de polling. Tasks normalise le cycle de vie : création, interrogation d’état, récupération du résultat, annulation. Le modèle est parfaitement compatible avec le cœur stateless — le serveur persiste la tâche là où il le souhaite et l’expose par identifiant.

// Réponse à un tools/call déclenchant une opération longue
{
  "jsonrpc": "2.0",
  "id": "42",
  "result": {
    "task": {
      "taskId": "tsk_01J9X…",
      "status": "working",
      "pollInterval": 2000
    }
  }
}

Le client interroge ensuite la tâche jusqu’à un état terminal, sans connexion maintenue ouverte pendant vingt minutes. Pour une équipe DevOps qui expose des pipelines CI/CD via MCP, c’est la primitive qui manquait.

MCP Apps adresse un problème orthogonal : le rendu. Certaines réponses ne se prêtent pas au texte — un diff, un graphe de dépendances, un formulaire de confirmation structuré. MCP Apps permet à un serveur de proposer une interface interactive que l’hôte affiche dans un conteneur cloisonné, avec un canal de communication normalisé vers le serveur. La règle d’hygiène est simple : traitez ce contenu comme du code tiers, avec les mêmes réflexes que pour une iframe non fiable (CSP stricte, pas d’accès aux credentials de l’hôte).

Extensions et dépréciation formelle : la fin des montées de version subies

Le framework d’Extensions sépare enfin le cœur du protocole de ses ajouts optionnels. Une extension est négociée à l’initialisation, identifiée de manière stable, et peut évoluer à son rythme sans forcer une révision du cœur. C’est le mécanisme qui permet, par exemple, à l’autorisation d’entreprise d’atteindre la stabilité indépendamment du reste.

En pratique, cela signifie qu’un client et un serveur peuvent converger sur un sous-ensemble commun de fonctionnalités plutôt que de rejeter la connexion sur une incompatibilité de version globale. Vos matrices de compatibilité passent d’un axe (version) à deux (version du cœur × extensions supportées) — plus verbeux à documenter, mais infiniment plus opérable.

La politique de dépréciation formelle est le complément indispensable : un élément déprécié est annoncé, marqué comme tel et conservé pendant une fenêtre définie avant retrait. Pour une équipe plateforme, c’est ce qui rend possible un plan de migration daté, plutôt qu’une course derrière la dernière release des SDK.

Autorisation durcie et Enterprise-Managed Authorization

L’autorisation MCP repose sur OAuth 2.1 avec Resource Indicators (RFC 8707) et découverte du serveur d’autorisation (RFC 9728). La révision 2026-07-28 en resserre les exigences, et surtout stabilise l’extension Enterprise-Managed Authorization.

C’est le déblocage attendu par les DSI. Concrètement, l’extension permet à une organisation de placer les serveurs MCP sous la gouvernance de son IdP : SSO existant, RBAC centralisé, provisioning et déprovisioning cohérents avec l’annuaire, révocation immédiate. Plutôt qu’un flux OAuth négocié individuellement entre chaque client et chaque serveur — modèle ingérable au-delà de quelques intégrations —, l’entreprise déclare quels serveurs sont autorisés, pour quels groupes, avec quels scopes.

Le point technique à ne pas manquer : les tokens sont liés à une ressource. Un serveur MCP doit rejeter un token dont l’audience ne le désigne pas explicitement. C’est la défense de base contre la confused deputy, où un serveur relaie un token vers une API tierce qui l’accepte trop volontiers.

Sécurité : l’injection de prompt indirecte est un problème d’architecture

Les travaux récents sur l’injection de prompt dans les pipelines CI/CD convergent vers une conclusion inconfortable : le problème n’est pas la crédulité des modèles, il est structurel. Dès lors qu’un système mélange, dans un même canal, des instructions de confiance et des données non fiables (issue GitHub, log de build, contenu d’une page web récupérée par un outil), aucun prompt système ne restaure une frontière que l’architecture n’a pas établie.

Conséquence directe pour vos serveurs MCP :

• Le périmètre de confiance est celui du token, pas celui du modèle. Si un outil peut écrire dans un dépôt, considérez que tout contenu entrant dans le contexte peut déclencher cette écriture. Dimensionnez les scopes en conséquence.
• Cloisonnez les serveurs exposés en CI. Un runner qui traite une pull request externe ne doit pas avoir accès au même serveur MCP — ni au même token — qu’un job de déploiement. Séparez les identités, pas seulement les branches.
• Distinguez lecture et écriture. Les annotations d’outils (readOnlyHint, destructiveHint) sont des indications, pas des contrôles. L’application effective se fait côté serveur, sur la base de l’identité authentifiée.
• Exigez une confirmation humaine hors bande pour les opérations irréversibles. Une confirmation demandée dans le même canal que celui qui a pu être empoisonné n’en est pas une.

Le durcissement de l’autorisation apporté par cette révision ne supprime pas l’injection de prompt. Il rend simplement possible de borner son rayon d’action, ce qui est le seul objectif atteignable aujourd’hui.

Migration : par où commencer

1. Inventaire. Listez vos serveurs, leur version de protocole, leur transport, et surtout leurs dépendances à l’état de session : cache en mémoire indexé par session, souscriptions de ressources, curseurs de pagination stockés côté serveur.
2. Isolez les points de rupture. Tout ce qui suppose « le client qui a appelé A rappellera B sur la même instance » doit disparaître ou être externalisé (Redis, base, ou identifiant porté par la requête).
3. Migrez le transport avant les fonctionnalités. Passez au cœur stateless, validez le comportement derrière un load balancer sans affinité, puis seulement ensuite adoptez Tasks, le caching des listes et MCP Apps.
4. Traitez l’autorisation comme un chantier distinct, avec vos équipes IAM. La validation d’audience et l’intégration à l’IdP ne se bricolent pas dans un sprint de fin de trimestre.
5. Gardez une période de double support. Le framework d’Extensions et la politique de dépréciation vous donnent la marge nécessaire : utilisez-la plutôt que de forcer vos consommateurs à basculer d’un coup.

Ce qui reste ouvert

Plusieurs zones grises subsistent. La découverte et la confiance dans les serveurs — comment un hôte sait qu’un serveur est celui qu’il prétend être — restent largement déléguées à des mécanismes hors spec, registres internes ou allow-lists. L’attribution fine des coûts entre hôte, client et serveur pour les opérations de sampling n’a pas de réponse normalisée. Et l’interaction entre Tasks longues et révocation de token en cours d’exécution mérite un traitement plus explicite.

Le déplacement de fond est ailleurs, et il est net : MCP cesse d’être un protocole d’IA à part pour redevenir du HTTP que vos équipes savent déployer, router, cacher, autoriser et observer avec l’outillage existant. C’est moins spectaculaire qu’une nouvelle primitive, mais c’est ce qui décide si vos serveurs MCP restent des prototypes ou deviennent de l’infrastructure.