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

Sessions, poignée de main, autorisation : trois ruptures d'un coup

Le 28 juillet 2026, le Model Context Protocol publie sa version finale 2026-07-28. Ses mainteneurs la décrivent comme le plus gros changement depuis le lancement du protocole, en novembre 2024.¹² La version candidate était figée depuis le 21 mai 2026, les bêtas des kits de développement officiels depuis le 29 juin.¹³ Trois ruptures rendent le code existant incompatible.

La première supprime les sessions. L'en-tête Mcp-Session-Id et la session au niveau du protocole disparaissent.⁴⁵ Chaque requête peut donc atterrir sur n'importe quelle instance de serveur. Vous n'avez plus besoin de routage persistant ni de magasin de sessions partagé. Un serveur MCP distant qui exigeait hier un routeur intelligent tourne aujourd'hui derrière un simple répartiteur de charge, en lisant le nouvel en-tête Mcp-Method.⁴

La deuxième retire la négociation d'ouverture, ce que le protocole appelait initialize.¹⁶ Chaque requête porte désormais elle-même la version du protocole, l'identité du client et ses capacités.

Sur le transport Streamable HTTP (la connexion HTTP en flux continu), chaque envoi doit ajouter trois en-têtes.¹ Ce sont MCP-Protocol-Version, Mcp-Method, puis Mcp-Name quand la requête nomme un outil, une ressource ou un prompt. Si la version annoncée dans l'en-tête et celle déclarée dans la requête diffèrent, l'appel est rejeté.

La troisième touche l'autorisation, la plus lourde en secteur régulé. Elle reste optionnelle dans le protocole : un mécanisme d'authentification maison demeure possible. Un serveur MCP distant protégé qui adopte OAuth 2.1, le protocole qui vérifie qui a le droit d'appeler un serveur, doit tenir le rôle de serveur de ressources.⁷ Il valide donc lui-même les autorisations qu'on lui présente.

Trois normes publiques deviennent alors obligatoires (les RFC 9728, 8707 et 9207). Elles permettent de découvrir automatiquement le serveur d'autorisation, de destiner chaque jeton à un serveur précis, et de vérifier qui l'a émis.⁴⁷

Trois fonctions entrent en dépréciation, avec douze mois de protection.¹

Vos serveurs MCP gardent presque tous un état caché

« Sans état » ne vaut qu'au niveau du protocole. Un serveur écrit contre la version 2025-11-25 garde souvent des choses en mémoire entre deux requêtes d'un même client. Quatre exemples reviennent.

• La liste des outils que le client a le droit d'appeler.
• La version négociée à l'ouverture.
• Une file de messages en attente.
• Un contexte d'autorisation qui s'enrichit.

C'est cet état implicite qui casse. Dans la version 2026-07-28, le protocole ne transporte plus rien de tout cela.⁴⁵ L'état applicatif reste permis, par un identifiant passé en argument d'outil ou par un stockage en base. Il devient explicite dans votre code au lieu d'être implicite dans la session. Les flux d'événements, eux, ne disparaissent pas tous : un nouveau mécanisme de requêtes en plusieurs étapes en remplace certains, pas la totalité.

Dès qu'un serveur couvre plusieurs outils, plusieurs identités et plusieurs systèmes, la relecture du code devient intrusive. Un serveur interne qui portait sa politique d'accès dans l'état de session demande plus de travail. Il faut refondre les outils concernés, écrire un plan de migration OAuth, puis tester sur deux instances derrière un répartiteur de charge.⁴⁷ C'est un chantier, pas un correctif.

Le prix de l'attente n'est pourtant pas immédiat. La documentation officielle précise qu'aucun serveur existant ne s'arrête le 28 juillet, et que les bêtas restent optionnelles.¹³ Les clients récents gardent un repli vers l'ancienne négociation. La coexistence des deux versions tiendra donc plusieurs trimestres. Je n'y vois pas une raison d'attendre, plutôt une raison de planifier.

Quatre questions à poser avant votre prochaine revue

Un dirigeant qui a des serveurs MCP en production tranche avec quatre questions, d'ici la prochaine revue trimestrielle. Aucune ne se délègue à l'équipe qui a écrit le code, parce que chacune touche une fonction transverse différente. Chaque serveur ressort en rouge, orange ou vert. Un rouge traité cette semaine devient un vert avec un plan calé pour le trimestre, quand un rouge ignoré devient une dette qui grossit.

• Combien de serveurs MCP tournent chez vous, qui les maintient, et lesquels sont critiques pour la continuité d'activité ? Un serveur qui alimente un chatbot RH n'a pas le profil d'un serveur qui déclenche des virements. La liste ne sort pas d'un outil d'audit : elle vient des équipes plateforme et des éditeurs qui ont exposé un connecteur.
• Chacun dépend-il d'un état partagé entre requêtes ? Déployez-le sur deux instances derrière un répartiteur qui alterne les appels.⁴ Si les enchaînements passent, c'est bon signe. S'ils échouent, la refonte sera lourde : perte de contexte, erreurs d'accès refusé, code 401, comportement qui change selon l'instance. Ce test rapide ne suffit pas à classer un serveur en vert. Ajoutez des scénarios de reprise, de concurrence, d'autorisation et de requêtes en plusieurs étapes.
• Où en êtes-vous sur OAuth ? Beaucoup de déploiements internes vivent encore avec un jeton fixe ou un mot de passe partagé, derrière un réseau privé d'entreprise. La nouvelle version impose OAuth 2.1 et la vérification stricte de l'émetteur du jeton.⁷ La question tient en une ligne pour votre équipe sécurité : notre fournisseur d'identité parle-t-il OAuth 2.1 et OpenID Connect, ou faut-il en ajouter un ?
• Utilisez-vous Roots, Sampling ou Logging ? Ces trois fonctions ont douze mois de protection, donc la bascule se planifie sans urgence.¹ Elle doit entrer dans votre feuille de route 2027 dès maintenant. Sampling passe par un appel direct au modèle du fournisseur, ce qui change votre façon de facturer et de journaliser les appels.

Votre trajectoire dépend de l'état de votre projet

Trois situations reviennent, et elles n'appellent pas le même geste. En production, vous cadrez la migration serveur par serveur. Un projet encore en développement, lui, bascule tout de suite sur la nouvelle version. Et en appel d'offres, tout se joue dans le contrat.

Un chatbot ou un callbot en production dépend d'abord de la bibliothèque cliente de votre fournisseur. Le risque à documenter est le rebond invisible. Si LangGraph ou Microsoft Agent Framework passe à la nouvelle version avant vos serveurs, les appels peuvent se dégrader sans erreur explicite.

Un chatbot relation client qui répond « je n'ai pas accès à cette information » sur des cas traités la veille est le symptôme à guetter. Ce risque se gère en cadrant la migration côté serveur, pas en subissant le changement.

Un projet d'agents IA encore en développement est le meilleur cas. Basculez maintenant sur les kits stables, plutôt que finir contre l'ancienne version et migrer ensuite. Python, TypeScript et C# sont en v2.0.0, Go en v1.7.0, avec des guides de migration officiels et un mode de négociation entre les deux versions.⁹ Cela compte surtout quand une équipe d'agents IA orchestrés sollicite plusieurs serveurs MCP à la fois.

Un projet en appel d'offres se protège par une ligne de plus dans la grille : à quelle date les serveurs du fournisseur seront-ils compatibles bout en bout ? Un plan trimestriel écrit est une réponse acceptable. « Nous étudions la migration » vaut un point noir. « Nous n'utilisons pas MCP » en vaut deux, car LangGraph, AutoGen, Microsoft Agent Framework et CrewAI intègrent déjà ce standard. Un fournisseur qui utilise un protocole propriétaire ignore un standard largement adopté et vous verrouille sur plusieurs cycles.

Banques et assurances : la migration devient traçable

DORA, le règlement européen sur la résilience numérique du secteur financier, couvre les banques, les assurances, les mutuelles et les opérateurs de paiement. Il impose un plan de continuité écrit et testé pour chaque prestataire informatique critique.⁸ Un serveur MCP interne, ou un connecteur tiers, peut entrer dans ce périmètre selon son rôle et selon les termes du contrat, après validation juridique.

Quand c'est le cas, un serveur qui casse pendant la migration OAuth devient un incident technique. Il devient aussi un point à documenter en revue devant l'ACPR, le régulateur des banques et des assurances. Pour un assureur ou une mutuelle, la revue peut aussi venir de l'EIOPA, l'autorité européenne des assurances. S'y ajoute Solvabilité II, la réglementation européenne sur les fonds propres des assureurs.⁸

L'exigence OAuth 2.1 est une bonne nouvelle sur le fond, et un vrai chantier pour la direction informatique, la sécurité et la conformité. Une migration disciplinée évite que ce point devienne une réserve d'audit.

Migrer à froid vaut mieux que migrer dans l'urgence

Je ne lis pas cette publication comme un ultimatum. C'est une occasion rare de traiter une dette technique à froid, avant qu'elle ne devienne un incident de production. Le pire scénario est connu : on attend l'incident pour lire la spécification. On découvre alors qu'une refonte de plusieurs serveurs internes bloque la mise à jour d'un chatbot en production. Trois décisions tiennent dans la semaine qui vient.

1. Confiez à un architecte l'audit des serveurs MCP actifs, avec les quatre questions ci-dessus comme grille. Le périmètre dépend du nombre de serveurs en production, à cadrer avec l'équipe plateforme.
2. Alignez les achats et la sécurité sur une grille d'appel d'offres à jour. Un contrat cadre agents IA signé sans clause sur la version 2026-07-28 vous laisse absorber seul le coût de la migration.
3. Vous ne mesurez pas encore ce que coûte un projet d'agents IA en production ? Notre simulateur de retour sur investissement chatbot et callbot donne un ordre de grandeur. Il part du volume mensuel, du coût d'un agent humain et du taux de résolution visé.

Webotit déploie des chatbots, des callbots, des mailbots et des équipes d'agents IA pour des ETI et des grands comptes français. Nous nous appuyons nous-mêmes sur des serveurs MCP internes et des connecteurs tiers. Cette version change la façon dont nous versionnons nos serveurs et nos contrats, pas la valeur livrée aux directions relation client, e-commerce ou back-office.

La question à poser cette semaine à votre fournisseur tient en une phrase : à quelle date votre socle passe en 2026-07-28, et qu'est-ce qui bouge chez moi ?

Questions frequentes

La spec MCP publiée le 28 juillet 2026 est-elle finale ou encore candidate ?+

Elle est finale. La version candidate avait été figée le 21 mai 2026. Elle a ensuite été testée pendant dix semaines, sur des charges réelles, par les mainteneurs des kits officiels (Python, TypeScript, Go, C#) et par des équipes en entreprise.¹³ La publication 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 indique que les clients récents gardent un repli vers l'ancienne négociation, donc rien ne casse le 28 juillet.¹ Le risque est progressif. À mesure que LangGraph, CrewAI, Microsoft Agent Framework ou l'un des Managed Agents Anthropic passent à la nouvelle version, votre serveur peut être appelé de façon dégradée. Négociation perdue, en-têtes manquants, incompréhension sur les nouveaux champs.⁴ Planifier la bascule sur le trimestre coûte moins cher que corriger un incident.

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

Rien pour l'utilisateur final, si le repli côté client et la gestion de l'état applicatif tiennent. Votre fournisseur d'agent bascule sur des appels sans session et sans routage persistant. Si votre serveur MCP gardait un état en mémoire entre deux requêtes, il faudra le refondre. Une migration incomplète, elle, produit des réponses dégradées ou des erreurs d'accès refusé (code 401) visibles côté client. Premier test : deux instances derrière un répartiteur qui alterne les appels, puis une relecture du code.⁴

Pourquoi OAuth 2.1 pèse-t-il plus lourd dans un secteur régulé ?+

Les banques et les entités financières soumises à DORA documentent l'authentification et la gestion des accès de chaque prestataire informatique critique. Les assurances et les mutuelles y ajoutent Solvabilité II et les guides de l'EIOPA.⁸ Le cadre français de certification des hébergeurs de données de santé, lui, ne concerne qu'un serveur qui héberge effectivement ce type de donnée. Devant un auditeur, un jeton fixe ou un mot de passe partagé derrière un réseau privé se défend mal. La nouvelle version impose OAuth 2.1 et les RFC 9728, 8707 et 9207, un cadre qui simplifie la revue une fois en place.⁷

Faut-il déclencher la migration en urgence maintenant que la spec est publiée ?+

Non. La documentation officielle précise qu'aucun serveur existant ne s'arrête le 28 juillet et que les bêtas restent optionnelles.¹³ La coexistence reste possible tant qu'un client garde son repli. Un projet démarré aujourd'hui contre la version finale livrera avant que cette coexistence coûte cher. Un projet en cours contre l'ancienne version se planifie selon la bibliothèque cliente, le mode de déploiement et la stratégie de repli retenue.

Sources et references

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