MCP 2026-07-28 : fin des sessions, 4 questions pour votre DSI

Ce que le blog officiel MCP publie le 28 juillet 2026

Le 28 juillet 2026, le Model Context Protocol publie sa spécification finale 2026-07-28, décrite par ses mainteneurs comme « le plus gros changement depuis le lancement du protocole » en novembre 2024.¹² La release candidate avait été verrouillée le 21 mai 2026, les bêtas des SDK dits « Tier 1 » par le projet (Python, TypeScript, Go, C#) ont été publiés le 29 juin 2026, et la fenêtre de validation par les mainteneurs et les implémentations enterprise s'est achevée avec cette publication finale.¹³

Trois changements structurels rendent cette version incompatible avec le code écrit contre les specs précédentes.

Premier changement : la fin des sessions. L'en-tête Mcp-Session-Id et la session au niveau protocole sont supprimés.⁴⁵ Concrètement, n'importe quelle requête MCP peut désormais atterrir sur n'importe quelle instance serveur : plus besoin de routage persistant (sticky routing), plus besoin de magasin de sessions partagé. Un serveur MCP distant qui exigeait auparavant un routeur intelligent avec inspection de paquets peut désormais tourner derrière un simple répartiteur de charge round-robin, en routant sur le nouvel en-tête Mcp-Method.⁴

Deuxième changement : la négociation initiale (initialize/initialized) disparaît.¹⁶ Chaque requête embarque elle-même la version de protocole, l'identité client et les capacités dans un champ _meta. Sur le transport Streamable HTTP, chaque POST doit porter trois en-têtes : MCP-Protocol-Version (dont la valeur doit correspondre à io.modelcontextprotocol/protocolVersion dans _meta, sous peine d'être rejetée en 400 HeaderMismatch), Mcp-Method, et Mcp-Name pour les requêtes qui nomment un outil, une ressource ou un prompt.¹

Troisième changement, et le plus lourd en régulé : l'alignement OAuth 2.1 et OpenID Connect devient formel — mais circonscrit. L'autorisation MCP reste optionnelle au niveau protocole (des mécanismes d'authentification personnalisés restent possibles). Pour les serveurs HTTP MCP protégés qui adoptent le cadre OAuth, la spec impose le rôle de serveur de ressources OAuth 2.1, avec OAuth 2.0 Protected Resource Metadata (RFC 9728) pour que les clients découvrent automatiquement le serveur d'autorisation, Resource Indicators (RFC 8707) côté client pour préciser à quel serveur MCP un jeton est destiné, et validation du paramètre iss selon RFC 9207.⁴⁷

Trois autres fonctions entrent en dépréciation avec une période de protection de douze mois : Roots (remplacé par des paramètres d'outil ou des URI de ressource), Sampling (remplacé par intégration directe à l'API du fournisseur LLM), Logging (remplacé par stderr ou OpenTelemetry).¹

Pourquoi vos serveurs MCP actuels vont casser

Le qualificatif « sans état » (stateless) ne vaut qu'au niveau du protocole. Un serveur MCP construit contre la spec 2025-11-25 stocke souvent en mémoire, entre deux requêtes du même client, plusieurs choses invisibles : la liste des outils que le client a le droit d'appeler, la version de protocole négociée au handshake, une file de messages SSE en attente, un contexte d'autorisation progressif.

Dans la spec 2026-07-28, le protocole ne transporte plus d'état de session : le Mcp-Session-Id disparaît, et n'importe quelle instance serveur doit pouvoir traiter n'importe quelle requête.⁴⁵ L'état applicatif reste possible (via requestState, handles explicites passés en argument d'outil, ou stockage en base) mais devient explicite dans le code plutôt qu'implicite dans la session. Les flux SSE ne disparaissent pas non plus complètement — le multi-round-trip request (MRTR) remplace certains d'entre eux, pas la totalité.

Ce qui semble un détail architectural devient une revue de code intrusive dès qu'un serveur MCP couvre plusieurs outils, plusieurs identités et plusieurs systèmes sous-jacents. Un serveur MCP interne qui reposait sur un état de session partagé pour porter sa politique d'accès va typiquement demander une refonte des outils concernés, plus un plan de migration OAuth, plus un test multi-instance derrière un répartiteur de charge.⁴⁷ Ce n'est pas un correctif, c'est un chantier.

Le prix de ne rien faire n'est pas immédiat. La documentation officielle précise qu'aucun serveur ancien ne cesse de fonctionner le 28 juillet et que les bêtas des SDK Tier 1 restent optionnelles ; les clients récents conservent un repli vers la négociation initialize pour rester compatibles avec les anciens serveurs.¹³ La coexistence des deux specs restera donc techniquement possible plusieurs trimestres. Ce n'est pas une raison d'attendre — c'est une raison de planifier la migration proprement, pas dans l'urgence.

La liste de contrôle en quatre questions à sortir cette semaine

Un DSI qui pilote un ou plusieurs déploiements MCP en production gagne à répondre à quatre questions d'ici la prochaine revue trimestrielle. Aucune ne peut être déléguée à l'équipe qui a écrit le code — chacune touche une fonction transverse.

Question un — inventaire. Combien de serveurs MCP tournent en production dans votre SI, qui les maintient, et lesquels sont critiques au sens continuité d'activité ? Un serveur MCP RH interne qui alimente un chatbot RH n'a pas le même profil qu'un serveur MCP qui déclenche des virements. La liste ne peut pas venir d'un audit outillé — il faut passer par les équipes plateforme et par les éditeurs qui ont exposé un connecteur MCP dans le SI.

Question deux — dépendance à l'état. Chaque serveur MCP inventorié doit être vérifié pour dépendance à Mcp-Session-Id ou à un état partagé entre requêtes. Un premier signal : déployez temporairement le serveur sur deux instances derrière un répartiteur round-robin.⁴ Si les enchaînements agentiques passent, c'est un bon indice ; s'ils échouent (perte de contexte entre appels d'outils, erreurs 401 après plusieurs tours, comportement incohérent selon l'instance), la refonte sera plus lourde. Ce test rapide ne remplace pas un audit du code réel, complété par des scénarios de reprise, de concurrence, d'autorisation et de requêtes multi-round-trip avant de classer un serveur « vert ».

Question trois — OAuth 2.1 et RFC 9207. Quelle est votre position actuelle sur OAuth pour vos serveurs MCP ? Beaucoup de déploiements internes utilisent encore un jeton Bearer statique ou une authentification HTTP basique derrière un VPN. La nouvelle spec impose un chemin OAuth 2.1 avec validation stricte de l'émetteur (issuer).⁷ Pour les secteurs régulés — banques ACPR, assurances Solvabilité II, mutuelles, santé HDS, opérateurs sous DORA — c'est une bonne nouvelle sur le fond mais un chantier réel côté DSI, RSSI et DPO. La question à poser à votre équipe sécurité : « avons-nous un fournisseur d'identité qui parle OAuth 2.1 + OIDC application_type registration, ou faut-il en ajouter un ? »

Question quatre — extensions et plan de charge. Trois fonctions passent en dépréciation avec douze mois de protection. Si votre socle technique utilise Roots, Sampling ou Logging au niveau MCP, la bascule est planifiée, pas urgente — mais elle doit apparaître dans la feuille de route 2027 dès maintenant.¹ Sampling en particulier disparaît au profit d'appels directs à l'API du fournisseur LLM ; c'est un changement d'architecture qui affecte la façon dont vous facturez et journalisez les appels.

Ces quatre questions donnent une notation rouge / orange / vert à chaque serveur MCP inventorié. Le rouge cette semaine devient un vert avec un plan calé pour le trimestre — le rouge non traité devient une dette qui s'accumule à mesure que le catalogue de serveurs MCP grandit.

Ce que ça change pour une entreprise française

Trois cas de figure pour une DSI ou une direction relation client d'ETI et grand compte français, avec des trajectoires différentes.

Un projet chatbot ou callbot déjà en production, connecté à un ou plusieurs serveurs MCP internes. La trajectoire dépend du SDK client utilisé et de la profondeur de l'état applicatif à refondre — l'inventaire de la Question un donne la borne haute. Le risque à documenter est le rebond invisible : si votre fournisseur de framework agents (LangGraph, CrewAI, AutoGen, Microsoft Agent Framework) met à jour son SDK vers la nouvelle spec avant que vos serveurs MCP soient prêts, les appels peuvent perdre certaines négociations, des en-têtes, ou dégrader l'expérience sans erreur explicite côté agent — à condition que le client ne conserve pas un repli vers initialize. Un chatbot relation client qui commence à répondre « je n'ai pas accès à cette information » sur des cas qu'il gérait la veille est le symptôme à surveiller — et ce risque se gère en cadrant la migration côté serveur, pas en subissant le changement.

Un projet agents IA multi-étapes en cours de développement, qui n'est pas encore en production. C'est le meilleur cas. Basculez le développement sur les SDK stables compatibles avec la spec 2026-07-28 — plutôt que finir contre l'ancienne spec et migrer plus tard. Les SDK Tier 1 sont disponibles en stable depuis la publication du 28 juillet 2026 : Python v2.0.0, TypeScript v2.0.0, C# v2.0.0, Go v1.7.0, avec des guides de migration officiels et un mode de négociation entre l'ancien et le nouveau protocole.⁹ C'est particulièrement pertinent pour les projets multi-canaux (voix + email + chat) ou qui empilent plusieurs appels agentiques dans une chaîne, où une équipe d'agents IA orchestrés sollicite plusieurs serveurs MCP différents.

Un projet en appel d'offres ou en présélection fournisseur. Ajoutez une ligne à votre grille d'évaluation : « quelle est la feuille de route du fournisseur pour la spec MCP 2026-07-28, et à quelle date ses serveurs sont-ils compatibles bout-en-bout ? ». Une réponse acceptable est un plan trimestriel écrit avec date de compatibilité bêta et de disponibilité générale. Une réponse « nous étudions la migration » vaut un point noir dans l'évaluation. Une réponse « nous n'utilisons pas MCP » vaut deux : LangGraph l'intègre via l'adaptateur officiel langchain-mcp-adapters, AutoGen (et le futur Microsoft Agent Framework) via les extensions autogen_ext.tools.mcp, CrewAI l'expose nativement dans son langage de configuration, et Anthropic maintient la spécification. Un fournisseur qui utilise un protocole propriétaire ignore un standard largement adopté et vous verrouille sur plusieurs cycles.

Une mention pour les secteurs sous DORA (banques, assurances, mutuelles, opérateurs de paiement). DORA impose un plan de continuité tiers écrit et testé pour chaque fournisseur ICT critique.⁸ Un serveur MCP interne — ou un connecteur MCP tiers — peut relever du périmètre ICT selon son rôle dans le SI et les termes du contrat, sous validation juridique et conformité ; quand c'est le cas, il rejoint votre catalogue de fournisseurs ICT critiques. Un serveur MCP qui casse pendant la migration OAuth est alors un incident technique doublé d'un point à documenter en revue ACPR ou EIOPA. La discipline de migration est le meilleur outil pour éviter que ce point devienne une réserve.

Ce qu'il faut retenir

Notre recommandation : migration disciplinée, pas migration dans l'urgence

La publication d'une spec finale n'est pas un ultimatum, c'est une occasion rare de traiter une dette technique à froid, avant qu'elle ne se transforme en incident de production. Le pire scénario est celui du DSI qui attend un incident pour lire la spec et découvre qu'une refonte de plusieurs serveurs MCP internes bloque la nouvelle version d'un chatbot en production.

Trois actions pratiques pour la semaine prochaine :

1. Confiez à un architecte ou à un responsable technique un audit des serveurs MCP actifs dans votre SI avec les quatre questions de la liste de contrôle ci-dessus. Le périmètre à couvrir dépend directement du nombre de serveurs MCP en production, à cadrer avec l'équipe plateforme.
2. Alignez les achats et la sécurité sur la mise à jour de votre grille d'appel d'offres fournisseurs IA. Chaque nouveau contrat cadre agents IA signé sans clause MCP 2026-07-28 vous expose à absorber la migration en interne, sans engagement du fournisseur sur la trajectoire.
3. Si vous ne mesurez pas encore le coût d'un projet agents IA en production, notre simulateur de retour sur investissement chatbot et callbot donne un ordre de grandeur à partir de trois paramètres — volume mensuel, coût agent humain moyen, taux de résolution automatisé cible. La bascule vers la nouvelle spec MCP n'affecte pas ce calcul, elle affecte la sécurité de la trajectoire.

Webotit.ai déploie des chatbots, callbots, mailbots et équipes d'agents IA pour des ETI et grands comptes français, en s'appuyant sur des serveurs MCP internes et des connecteurs MCP tiers. Sur les projets en cours, la spec 2026-07-28 change la manière dont nous versionnons nos serveurs et nos contrats — pas la valeur livrée aux directions relation client, e-commerce, RH ou back-office. Sur les projets à cadrer, la question à poser dès cette semaine à votre fournisseur d'agents IA est simple : « à quelle date votre socle technique passe en spec 2026-07-28, et qu'est-ce qui bouge chez moi ? ».

Questions frequentes

Le 28 juillet 2026, la spec MCP publiée est-elle la version finale ou une release candidate ?+

C'est la spécification finale. La release candidate avait été verrouillée le 21 mai 2026 et une fenêtre de validation de dix semaines a permis aux mainteneurs des SDK Tier 1 (Python, TypeScript, Go, C#) et aux implémentations en entreprise de la tester contre des charges réelles avant publication.¹³ La spec du 28 juillet est le résultat de cette validation.

Mon serveur MCP écrit contre la spec 2025-11-25 fonctionnera-t-il encore en novembre 2026 ?+

Techniquement oui. La documentation officielle précise que les clients récents conservent un repli vers la négociation initialize pour rester compatibles avec les anciens serveurs, donc rien ne casse le 28 juillet.¹ Le vrai risque est progressif : à mesure que LangGraph, CrewAI, Microsoft Agent Framework ou l'un des Managed Agents Anthropic met à jour son SDK vers la spec 2026-07-28, votre serveur ancien peut être appelé de façon dégradée — perte de la négociation initiale, en-têtes manquants, incompréhension mutuelle sur les nouveaux _meta. Planifier une migration sur le trimestre est plus prudent que corriger un incident en production.⁴

Qu'est-ce qui change concrètement pour un chatbot ou un callbot en production ?+

Sur le papier rien pour l'utilisateur final, si le repli côté client et la gestion de l'état applicatif fonctionnent correctement. Un chatbot qui interroge un serveur MCP interne (par exemple pour lire un catalogue produits ou déclencher une action métier) verra son fournisseur d'agent basculer sur des appels sans état, sans routage persistant. Si votre serveur MCP maintenait un état en mémoire entre requêtes (sessions, tokens, contextes progressifs), il faudra le refondre. Une migration incomplète peut, en revanche, produire des réponses dégradées ou des erreurs 401 visibles côté utilisateur. Un premier signal : déployez le serveur sur deux instances derrière un répartiteur round-robin et vérifiez que rien ne casse — puis complétez par un audit de code.⁴

Pourquoi l'alignement OAuth 2.1 change-t-il la donne pour les secteurs régulés ?+

Les banques (ACPR) et les entités financières sous DORA doivent documenter l'authentification et la gestion des accès pour chaque fournisseur ICT critique ; les assurances et mutuelles y ajoutent Solvabilité II et les guides EIOPA.⁸ Le cadre HDS, distinct, certifie l'hébergement des données de santé confié à un prestataire tiers et ne s'applique donc qu'à un serveur MCP qui héberge effectivement ce type de donnée — la validation juridique et conformité détermine son périmètre au cas par cas. Un serveur MCP peut relever du périmètre ICT selon son rôle dans le SI et les termes du contrat ; quand c'est le cas, un jeton Bearer statique ou une authentification HTTP basique derrière VPN est difficile à défendre en revue. La spec 2026-07-28 impose alors OAuth 2.1 avec Resource Indicators (RFC 8707), Protected Resource Metadata (RFC 9728) et validation iss (RFC 9207) — un cadre qui, une fois implémenté, simplifie la revue d'audit.⁷

La spec finale est publiée le 28 juillet 2026 — faut-il déclencher la migration en urgence ?+

Non. La documentation officielle précise qu'aucun serveur ancien ne cesse de fonctionner le 28 juillet et que les bêtas des SDK Tier 1 restent optionnelles.¹³ La coexistence des deux specs reste techniquement possible tant qu'un client conserve un repli vers initialize. Un projet démarré à cette date contre la spec finale livre en production avant que la coexistence devienne coûteuse — un projet en cours de développement contre l'ancienne spec peut être planifié pour bascule selon le SDK client, le mode de déploiement et la stratégie de repli retenus.

Sources et references

1. [1]
2. [9]
3. [2]
4. [3]
5. [4]
6. [5]
7. [6]
8. [7]
9. [8]