MCP 2026-07-28 : transport stateless, MCP Apps et ce que les entreprises doivent migrer

MCP 2026-07-28 : transport stateless, MCP Apps et ce que les entreprises doivent migrer

Le 28 juillet 2026, le Model Context Protocol publie sa plus grande révision depuis le lancement. La specification MCP 2026 stateless entreprise agents n'est plus une évolution marginale : c'est un changement de fondation pour tout déploiement MCP en production.

En avril 2026, nous avions analysé comment MCP stabilisé et le protocole A2A redessinaient l'interopérabilité des agents IA. Trois mois plus tard, la release candidate 2026-07-28 — verrouillée le 21 mai 2026 selon le blog officiel MCP — va plus loin. Elle livre la feuille de route 2026 annoncée le 9 mars 2026 : un cœur stateless qui scale sur une infrastructure HTTP ordinaire, des extensions first-class (MCP Apps, Tasks), un durcissement OAuth/OIDC, et une politique de dépréciation formelle.

Si votre entreprise a déjà connecté Claude, Cursor, n8n ou un agent custom à des serveurs MCP distants, cet article répond à une question précise : qu'est-ce qui casse, qu'est-ce qui s'améliore, et comment migrer sans interrompre vos workflows ? Nous nous appuyons exclusivement sur la documentation officielle (blog MCP, changelog draft, annonces AAIF) et sur notre expérience de déploiement d'agents en production chez BOVO Digital.

---

Pourquoi cette release est différente de l'article MCP d'avril 2026

L'article d'avril posait le cadre conceptuel : MCP pour les outils, A2A pour la communication entre agents, écosystème en croissance, centaines de serveurs pre-built. La spec 2026-07-28 entre dans le concret opérationnel.

Ce n'est pas un doublon : c'est la suite logique. Si l'article d'avril expliquait pourquoi adopter MCP, celui-ci explique comment migrer quand MCP devient une brique d'infrastructure critique derrière un load balancer, une API Gateway et un IdP d'entreprise.

De la RC verrouillée (mai 2026) à la spec finale du 28 juillet 2026, puis migration production à partir d'août

---

Le changement fondateur : MCP devient stateless au niveau protocole

Le titre de cette release candidate, tel que formulé par l'Agentic AI Foundation, est clair : MCP devient stateless à la couche protocole. Six Specification Enhancement Proposals (SEPs) convergent vers cet objectif, en complétant le plan « The Future of MCP Transports » publié en décembre 2025.

Avant / après : un appel d'outil en Streamable HTTP

Sous 2025-11-25, invoquer un outil exigeait d'abord d'établir une session :

POST /mcp HTTP/1.1
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"initialize",
 "params":{"protocolVersion":"2025-11-25","capabilities":{},
           "clientInfo":{"name":"my-app","version":"1.0"}}}

Le serveur répondait avec un Mcp-Session-Id que chaque requête suivante devait porter, épinglant le client à l'instance qui avait émis la session :

POST /mcp HTTP/1.1
Mcp-Session-Id: 1868a90c-3a3f-4f5b
Content-Type: application/json

{"jsonrpc":"2.0","id":2,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"}}}

Sous 2026-07-28, le même appel devient une requête unique, traitable par n'importe quelle instance :

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
           "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

Conséquence opérationnelle immédiate, selon le blog MCP : un serveur distant qui nécessitait sticky sessions, store de sessions partagé et inspection profonde des corps JSON-RPC à la gateway peut désormais tourner derrière un load balancer round-robin, router sur l'en-tête Mcp-Method, et laisser les clients mettre en cache les réponses tools/list tant que le ttlMs du serveur le permet.

SEP-2575 : fin du handshake initialize

Le couple initialize / notifications/initialized disparaît. La version de protocole, l'identité client et les capacités négociées — auparavant échangées une fois à la connexion — voyagent désormais dans _meta sur chaque requête, sous des clés comme io.modelcontextprotocol/protocolVersion, io.modelcontextprotocol/clientInfo et io.modelcontextprotocol/clientCapabilities.

Un mismatch de version renvoie UnsupportedProtocolVersionError. Pour la découverte amont, un nouveau RPC server/discover — que les serveurs doivent implémenter — annonce les versions supportées, les capacités et l'identité du serveur. Les clients peuvent l'appeler avant toute interaction, ou l'utiliser comme sonde de compatibilité STDIO.

SEP-2567 : suppression de Mcp-Session-Id

L'en-tête Mcp-Session-Id et la session au niveau protocole sont supprimés. Les endpoints de liste (tools/list, resources/list, prompts/list) ne varient plus par connexion. Deux conséquences majeures pour l'entreprise :

1. Horizontal scaling simplifié : plus de sticky routing imposé par le protocole.
2. Cache CDN-friendly : les listes d'outils deviennent des ressources cacheables avec métadonnées explicites.

Cinq piliers : core stateless, opérabilité, extensions, auth OAuth/OIDC, gouvernance

---

Protocole stateless, applications stateful : le pattern des handles explicites

Supprimer la session protocole ne signifie pas que votre CRM connector, votre automate navigateur ou votre pipeline documentaire doit devenir amnésique. Les mainteneurs MCP le formulent explicitement : les serveurs qui portent un état entre appels émettent un handle explicite — basket_id, browser_id, workflow_run_id — retourné par un outil, que le modèle repasse comme argument ordinaire.

En pratique, ce pattern s'avère souvent plus puissant que l'état caché dans les métadonnées de transport :

• Le modèle voit l'identifiant et peut le raisonner.
• Il peut composer des handles entre outils (« utilise le browser_id du step 1 pour le step 3 »).
• Il peut transférer un contexte entre étapes d'une chaîne d'agents.

Chez BOVO Digital, nous appliquons déjà ce pattern sur nos intégrations n8n + MCP : un nœud « init_session » retourne un identifiant que les nœuds suivants consomment. La spec 2026-07-28 aligne enfin le protocole sur ce que HTTP faisait depuis vingt ans — tokens, cookies, IDs opaques — plutôt que de simuler de la continuité via une couche transport propriétaire.

---

Requêtes serveur→client sans connexion persistante

Un protocole stateless doit quand même permettre au serveur de demander une saisie mid-call (confirmation de suppression, choix entre options). Deux SEPs reconstruisent ce flux :

SEP-2260 : les requêtes initiées par le serveur ne peuvent être émises que pendant le traitement actif d'une requête client. Fini l'elicitation « out of nowhere » : chaque prompt utilisateur remonte à une action qu'il — ou son agent — a déclenchée.

SEP-2322 (Multi Round-Trip Requests) : au lieu de maintenir un flux SSE ouvert, le serveur retourne un InputRequiredResult :

{
  "resultType": "inputRequired",
  "inputRequests": {
    "confirm": {
      "type": "elicitation",
      "message": "Supprimer 3 fichiers ?",
      "schema": { "type": "boolean" }
    }
  },
  "requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0="
}

Le client collecte les réponses et réémet l'appel original avec inputResponses et le requestState echo. N'importe quelle instance serveur peut reprendre le retry : tout le contexte est dans le payload.

Pour les équipes SRE, c'est une victoire : plus de connexions SSE longues à monitorer comme des websockets fantômes. Pour les développeurs de serveurs MCP, c'est une refonte de la gestion d'elicitation à planifier avant août 2026.

---

Couche opérabilité : headers, cache, tracing distribué

Trois changements « inglorieux mais critiques » rendent le trafic MCP indiscernable, du point de vue routing et observabilité, d'une API HTTP classique.

SEP-2243 : en-têtes Mcp-Method et Mcp-Name obligatoires

Chaque requête Streamable HTTP POST doit inclure Mcp-Method (ex. tools/call) et Mcp-Name (nom de l'outil ou de la ressource). Les load balancers, API Gateways et rate-limiters routent sans parser le corps JSON-RPC. Les serveurs rejettent les requêtes où en-têtes et corps divergent.

Au MCP Dev Summit AAIF d'avril 2026, plusieurs acteurs — Kong, Docker, Solo.io, plateformes internes type Uber — reverse-engineeraient le nom d'outil depuis le body. Ce hack disparaît le 28 juillet.

La même SEP introduit le support de headers custom depuis les paramètres d'outil via x-mcp-header, utile pour propager un tenant ID ou un correlation ID sans modifier le schéma métier.

SEP-2549 : ttlMs et cacheScope

Les résultats de tools/list, resources/list et resources/read portent ttlMs et cacheScope, calqués sur HTTP Cache-Control. Les clients savent combien de temps une liste d'outils reste fraîche et si le cache peut être partagé entre utilisateurs. Un flux SSE long-lived n'est plus le seul moyen de détecter un changement de liste.

SEP-414 : W3C Trace Context

La propagation traceparent, tracestate et baggage dans _meta est documentée avec des noms de clés figés. Une trace OpenTelemetry partant de l'application hôte traverse le SDK client, le serveur MCP et les appels downstream en un seul arbre de spans.

Agent IA → load balancer round-robin → instances MCP stateless → outils métier, avec OAuth/OIDC en amont

---

Extensions first-class : MCP Apps et Tasks

SEP-2133 transforme les extensions en citoyens de première classe. Identifiées par des IDs reverse-DNS, négociées via une map extensions sur les capacités client/serveur, hébergées dans des dépôts ext-* avec maintainers délégués, elles versionnent indépendamment de la spec core. Un Extensions Track formel existe dans le processus SEP.

MCP Apps (SEP-1865) : interfaces HTML sandboxées

Les serveurs peuvent déclarer des interfaces HTML interactives que l'hôte rend dans un iframe sandboxé. Les outils déclarent leurs templates UI à l'avance pour permettre prefetch, cache et revue sécurité avant exécution. L'UI communique via le même JSON-RPC que les tool calls — chaque action UI passe par le même chemin d'audit et de consentement.

Cas d'usage concrets pour une PME :

• Formulaire de validation de commande avant exécution d'un outil « process_refund ».
• Sélecteur visuel de fichiers avant un « bulk_export ».
• Dashboard léger de suivi d'une tâche longue (couplé à l'extension Tasks).

Ce n'est pas l'équivalent d'une application Next.js complète. Pour une stack web agent-native plus large — serveur MCP Next.js, Prisma, contrats de données — notre analyse développement web piloté par agents IA détaille où MCP s'insère dans l'architecture front/back.

Tasks : graduation en extension avec nouveau cycle de vie

Tasks était une fonctionnalité expérimentale du core en 2025-11-25. L'usage production a révélé assez de friction pour justifier une refonte en extension.

Nouveau modèle :

• Le serveur peut répondre à tools/call avec un handle de tâche.
• Le client pilote via tasks/get, tasks/update, tasks/cancel.
• La création de tâche est server-directed : le client annonce l'extension, le serveur décide quand une invocation devient une tâche.
• tasks/list est supprimé : sans sessions, lister les tâches cross-clients n'a pas de scope bien défini.

Breaking change explicite : quiconque a shipé contre l'API Tasks expérimentale 2025-11-25 doit migrer vers le nouveau cycle de vie extension. Auditez vos serveurs internes avant le 28 juillet.

---

Durcissement OAuth/OIDC : six SEPs pour l'entreprise

Le pattern de déploiement MCP — un client, de nombreux serveurs protégés — amplifie certaines attaques OAuth classiques. Six SEPs alignent la spec sur les pratiques OAuth 2.0 / OpenID Connect en production.

Action prioritaire août 2026 : implémenter SEP-2468 dans chaque client MCP custom. Les mix-up attacks contre des APIs OAuth-protected sont documentées depuis 2016 ; MCP hérite du même modèle de menace.

Pour les déploiements n8n + MCP en entreprise, ces changements impactent directement la configuration OAuth2 des credentials n8n et des serveurs MCP self-hosted. Notre agence d'automatisation n8n intègre systématiquement cette revue IdP lors des migrations de protocole.

---

Dépréciations : Roots, Sampling, Logging — pas de suppression immédiate

SEP-2577 et SEP-2596 introduisent un cycle de vie Active → Deprecated → Removed avec minimum douze mois entre dépréciation et suppression possible.

Ce sont des dépréciations annotation-only : méthodes, types et capability flags continuent de fonctionner dans cette release et dans toute version publiée dans les douze mois suivants. Votre code appelant roots/list le 29 juillet 2026 obtiendra encore une réponse valide.

Stratégie recommandée :

1. Inventorier les appels Roots/Sampling/Logging dans vos serveurs et clients.
2. Planifier le remplacement sur Q4 2026 – Q2 2027, pas en urgence juillet.
3. Ne pas construire de nouvelles features sur ces APIs — privilégier les paramètres d'outils et OpenTelemetry.

Le transport HTTP+SSE (déprécié depuis 2025-03-26) passe en statut Deprecated formel (SEP-2596). Migrez vers Streamable HTTP si ce n'est pas déjà fait.

---

JSON Schema 2020-12 et changement de code d'erreur

SEP-2106 élève inputSchema et outputSchema des outils au JSON Schema draft 2020-12 complet :

• Schémas d'entrée : racine type: "object" conservée, mais composition (oneOf, anyOf, allOf), conditionnels et $ref/$defs autorisés.
• Schémas de sortie : sans restriction de type racine.
• structuredContent peut être n'importe quelle valeur JSON, pas seulement un objet.
• Interdiction de auto-déréférencer des $ref externes ; limites de profondeur et temps de validation imposées (garde-fous DoS).

Changement plus discret mais piégeux : SEP-2164 remplace le code MCP custom -32002 (ressource manquante) par -32602 Invalid Params JSON-RPC standard. Si votre client matche le littéral -32002, mettez à jour avant la migration.

Pour les équipes qui exposent des outils MCP depuis des APIs métier polymorphes — factures, tickets, entités CRM — JSON Schema 2020-12 est une nette amélioration expressivité. Budgettez du temps de validation de schémas dans votre CI.

---

Gouvernance : comment MCP évoluera sans casser le core

Trois SEPs de gouvernance accompagnent le rework stateless :

• Politique de cycle de vie (SEP-2577 + SEP-2596) : fenêtre minimale de douze mois, règles écrites.
• Framework Extensions : nouvelles capacités en opt-in, stabilisation hors du core spec.
• SEP-2484 : un SEP Standards Track ne peut atteindre Final sans scénario correspondant dans la suite de conformance — la même suite qui score les SDK officiels via le système de tiers.

Le message des mainteneurs est explicite : le rework stateless est le genre de changement fondateur qui nécessitait une rupture propre. Avec les fenêtres de dépréciation et les extensions comme outils standard, les implémentations ciblant 2026-07-28 devraient adopter les révisions futures sans réécrire transport et lifecycle.

La spec 2026 excelle en scalabilité HTTP, sécurité OAuth et UI intégrée ; la 2025-11-25 reste plus compatible avec le code legacy existant

---

Plan de migration entreprise : checklist avant le 28 juillet

Voici le plan que nous appliquons chez BOVO Digital pour les clients avec MCP en production.

Phase 1 — Audit (semaine 1)

• Lister tous les serveurs MCP distants et leur version de protocole annoncée.
• Identifier les dépendances à Mcp-Session-Id, sticky sessions, Redis session store.
• Repérer les usages de Tasks expérimental, Roots, Sampling, HTTP+SSE.
• Cartographier les clients MCP (Cursor, Claude Desktop, agents n8n, SDK custom).

Phase 2 — Compatibilité SDK (semaines 2–6)

• Vérifier la roadmap des SDK utilisés (TypeScript, Python) pour support 2026-07-28.
• Tester server/discover sur chaque serveur interne.
• Valider les en-têtes Mcp-Method / Mcp-Name derrière votre API Gateway.

Phase 3 — Refactoring serveur (semaines 4–8)

• Remplacer l'état session protocole par des handles explicites dans les outils concernés.
• Migrer l'elicitation SSE vers Multi Round-Trip Requests.
• Ajouter ttlMs / cacheScope aux endpoints de liste.
• Instrumenter W3C Trace Context → OpenTelemetry.

Phase 4 — Auth et sécurité (semaines 6–10)

• Implémenter validation iss (SEP-2468) côté client.
• Corriger DCR application_type pour clients CLI/desktop.
• Tester re-registration après changement d'issuer IdP.

Phase 5 — Validation production (semaines 10–12)

• Load test round-robin sans sticky sessions.
• Chaos test : kill instance mid-request, vérifier reprise via requestState.
• Rollback plan documenté vers 2025-11-25 si client hôte non compatible.

Évaluez sticky sessions et usage Tasks expérimental pour décider si migrer dès août 2026 ou rester sur 2025-11-25 temporairement

---

MCP 2026-07-28 et votre stack d'automatisation n8n

n8n a été l'un des premiers orchestrateurs à embrasser MCP pour connecter agents et outils métier. La spec stateless change trois choses pour les workflows n8n :

1. Fiabilité des connexions MCP distantes. Sans session protocole, un redémarrage de pod n'invalide plus toutes les sessions actives. Les workflows long-running qui invoquaient des outils MCP toutes les dix minutes perdent une classe entière de failures « session expired ».

2. Cache des définitions d'outils. Avec ttlMs, le nœud MCP Agent peut mettre en cache tools/list entre exécutions, réduisant la latence et la charge sur les serveurs internes.

3. OAuth durci. Les credentials OAuth2 n8n connectés à des serveurs MCP doivent être revus : validation iss, refresh token semantics, binding issuer. C'est fastidieux, mais moins coûteux qu'un incident de sécurité IdP.

Si vous déployez des agents MCP sans équipe platform dédiée, externaliser la migration à une agence d'automatisation n8n expérimentée sur MCP évite les raccourcis dangereux — désactiver l'auth « temporairement », ignorer les headers obligatoires, ou shipper des handles d'état non validés.

---

Ce que les entreprises gagnent — et ce qu'elles paient

Gains mesurables

• Scaling horizontal sans sticky sessions ni store partagé obligatoire au niveau protocole.
• Observabilité alignée sur OpenTelemetry et headers HTTP standards.
• Sécurité OAuth alignée sur RFC 9207 et pratiques OIDC enterprise.
• Extensibilité via MCP Apps et Tasks sans gonfler le core spec.
• Prévisibilité via politique de dépréciation à douze mois minimum.

Coûts de migration

• Refactoring des serveurs MCP qui stockaient l'état en session protocole.
• Migration Tasks expérimental → extension Tasks.
• Mise à jour clients matchant -32002 ou ignorant les headers routing.
• Tests de charge et chaos engineering sur la nouvelle architecture.
• Formation des équipes sur handles explicites et Multi Round-Trip Requests.

Le calcul ROI dépend de votre maturité MCP. Une PME avec deux serveurs MCP internes en stdio local impacte faiblement. Un groupe avec quinze serveurs HTTP derrière Kong, dix agents en production et des workflows Tasks critiques doit budgéter six à douze semaines d'ingénierie platform.

---

Positionnement BOVO Digital : de l'article d'avril à la migration de juillet

En avril, nous recommandions d'adopter MCP comme standard d'accès outils, en complément d'A2A pour l'orchestration inter-agents. En juillet, la recommandation évolue :

1. Si vous n'avez pas encore MCP : démarrez directement sur 2026-07-28 si votre SDK le supporte ; sinon, 2025-11-25 en stdio local avec plan de migration Q3 2026.
2. Si MCP est déjà en production HTTP : planifiez la migration stateless avant fin Q3 2026 — le gain scaling est immédiat une fois migré.
3. Si vous construisez des agents sur mesure : intégrez MCP Apps et Tasks extension dans votre roadmap produit, pas comme afterthought.

Notre offre de création d'agents IA inclut désormais un audit de compatibilité MCP 2026-07-28 dès la phase de cadrage : version de protocole, pattern d'état, revue OAuth, stratégie de cache. Nous appliquons les mêmes standards à nos propres agents internes avant de les proposer aux clients.

---

Calendrier officiel et fenêtre de validation

Points clés du blog MCP :

• Release candidate verrouillée : 21 mai 2026.
• Spec finale : 28 juillet 2026.
• Fenêtre de validation : dix semaines pour SDK maintainers et implémenteurs client, contre workloads réels.
• SDK Tier 1 : support attendu dans cette fenêtre.
• Signaler un problème : issues sur le dépôt specification ; questions d'implémentation via les Working Groups Discord.

Cette release contient des breaking changes — ce n'est pas la norme future, mais une rupture fondateur justifiée. Les outils de gouvernance (dépréciation, extensions, conformance suite) existent pour que les prochaines révisions soient incrémentales.

---

Conclusion : MCP entre dans l'âge de l'infrastructure de production

La specification MCP 2026-07-28 répond à une promesse formulée par David Soria Parra (co-créateur MCP) en avril 2026 : rendre le protocole prêt à productioniser les systèmes agentiques. Transport stateless, extensions MCP Apps et Tasks, OAuth durci, politique de dépréciation écrite — ce n'est plus un standard de labo, c'est une couche d'infrastructure comparable à ce que REST a été pour le web API.

Trois actions concrètes cette semaine :

1. Auditez vos serveurs MCP pour sessions, Tasks expérimental et transport HTTP+SSE.
2. Testez server/discover et les en-têtes routing sur un environnement de staging.
3. Planifiez la migration OAuth (SEP-2468 en priorité) avec votre équipe sécurité.

Si vous avez découvert MCP via notre article d'avril sur MCP et A2A, considérez celui-ci comme le chapitre suivant : moins de vision, plus de runbook. Et si votre stack web évolue vers une architecture agent-native, croisez cette lecture avec notre guide Next.js, Prisma et MCP en 2026.

Besoin d'accompagnement ? Notre agence d'automatisation n8n déploie des agents MCP en production avec revue OAuth, load testing et documentation de migration. Pour un agent sur mesure avec compatibilité 2026-07-28 dès le POC, consultez notre offre création d'agents IA. Nous commençons par un audit de votre stack MCP existante — pas par une vente de technologie que vous n'utilisez pas encore.