LLM Tools · 8 November 2026

MCP 2026-07-28 : la fin des sessions, et ce que la refonte sans état change vraiment pour vos agents en production

Le 28 juillet 2026, le Model Context Protocol a débranché la session. En une révision — la 2026-07-28 — le standard le plus adopté de l’écosystème agentique a jeté par-dessus bord son modèle stateful, son handshake d’initialisation et son en-tête de session. Promesse : un scaling enfin horizontal, des serveurs recyclables à volonté, une surface d’attaque plus nette. Friction : tout le contexte implicite qu’il faut désormais porter soi-même, à chaque requête. Trois mois plus tard, alors que les SDK de niveau 1 l’implémentent et que les extensions Tasks et Apps se déploient, voici le décryptage pour les équipes qui font tourner des agents en production aujourd’hui.

Le jour où MCP a débranché la session

Il y a des bascules qui ne font pas de bruit et qui changent tout. La révision 2026-07-28 de la spécification MCP est de celles-là. Publiée le 28 juillet 2026 par les mainteneurs du protocole, elle supprime purement et simplement le mécanisme de session côté serveur : un serveur MCP distant n’a plus rien à retenir entre deux requêtes, et n’importe quelle requête peut désormais tomber sur n’importe quelle instance de serveur. Autrement dit, le protocole qui servait de « port USB-C pour les applications d’IA » — l’analogie est de la documentation officielle — vient de troquer son câble propriétaire contre un fil nu, standardisé, interchangeable.

Pour comprendre l’ampleur du geste, il faut se souvenir d’où l’on vient. MCP a été lancé par Anthropic en novembre 2024, avec une ambition claire : offrir un langage commun entre les modèles et le monde extérieur. En deux ans, il est devenu le standard de facto pour brancher un LLM sur des outils externes. Les serveurs pré-construits livrés à l’origine — Google Drive, Slack, GitHub, Git, Postgres, Puppeteer — ont essaimé en une collection communautaire foisonnante (awesome-mcp-servers), et l’on a vu débarquer des serveurs MCP partout : chez Algolia pour le commerce agentique, chez Maxon dans Cinema 4D 2026.4, jusque dans Safari 27, livré en septembre 2026 avec iOS 27 et macOS 27 et ses 17 outils d’automatisation exposés aux agents (forkast.news). Quand un navigateur grand public embarque un serveur MCP natif — et, comme l’a relevé la presse spécialisée, sans mécanisme MDM pour le désactiver en entreprise — c’est que le protocole a quitté la phase expérimentale.

L’échelle, elle, n’est plus discutable. Les responsables du protocole font état de près de 400 millions de téléchargements de SDK par mois, soit environ quatre fois plus en un an, les SDK TypeScript et Python dépassant chacun le milliard de téléchargements cumulés, et plus de 950 serveurs MCP référencés dans le seul annuaire de connecteurs de Claude (YuSMP). À ce volume, une révision qui refond le cœur du standard n’a rien d’anecdotique : elle touche des milliers de serveurs en exploitation.

Mais cette adoption massive a révélé la faille structurelle du modèle stateful. Un serveur MCP « classique » devait se souvenir de vous : il ouvrait une session, négociait des capacités via un handshake initialize/initialized, puis maintenait un identifiant de session (Mcp-Session-Id) pour retrouver le fil. Pratique pour un agent qui discute avec un seul serveur sur son laptop. Cauchemardesque dès qu’il faut passer à l’échelle : sessions collantes obligatoires, load balancers configurés en sticky, mémoire serveur qui gonfle avec le nombre de clients connectés, instances impossibles à recycler sans casser une conversation en cours. Le modèle stateful transformait chaque serveur MCP en petit serveur d’application avec son état à gérer — l’exact opposé de ce qu’on attend d’une brique d’infrastructure moderne.

La bascule était dans l’air. L’annonce officielle, relayée par plusieurs observateurs (OIA, BlueOnyx, runbookly.io), pose le changement central en une phrase : le passage d’un modèle stateful à un modèle requête/réponse sans état. Les mainteneurs eux-mêmes décrivent ce virage comme la suppression de « beaucoup de choses qui faisaient MCP » tel qu’on le connaissait — c’est à la fois la promesse et l’avertissement. L’enjeu est double, et il est tendu : d’un côté, une scalabilité enfin digne de ce nom ; de l’autre, la perte du contexte conversationnel implicite que la session offrait gratuitement. Tout l’article tient dans cette tension.

Anatomie d’un protocole qui oublie tout entre deux requêtes

Que reste-t-il d’un protocole quand on lui retire sa mémoire ? La réponse tient en trois rôles, inchangés, et un cycle de vie radicalement simplifié. MCP définit toujours un hôte (l’application d’IA — Claude Code, Claude Desktop, VS Code, Cursor, un agent maison), un client (composant interne à l’hôte, une connexion par serveur) et un serveur (le programme qui fournit contexte et actions, local ou distant). Un serveur expose toujours ses trois primitives : outils (fonctions exécutables), ressources (données de contexte) et prompts (gabarits d’interaction). Rien ne bouge de ce côté — et c’est heureux, car c’est la stabilité de ce vocabulaire qui a fait la force du standard.

Ce qui disparaît, en revanche, c’est toute la mécanique d’établissement de session. Selon les analyses techniques disponibles, l’en-tête Mcp-Session-Id est supprimé et le handshake initialize/initialized retiré de la spécification. Fini le rituel d’ouverture où client et serveur se présentaient, échangeaient leurs versions et capacités respectives, puis scellaient une session. À la place, un cycle requête/réponse pur : chaque appel transporte avec lui sa propre version de protocole, son identité et ses capacités. La négociation de capacités, autrefois faite une fois pour toutes à l’ouverture, se rejoue à chaque requête — ou s’appuie sur des métadonnées embarquées dans l’appel.

Le transport suit la même logique. MCP a toujours su parler HTTP, SSE et streamable HTTP ; dans le monde sans-état, c’est la dimension « streamable » qui prend tout son sens : on peut streamer une réponse sans maintenir une connexion persistante porteuse d’identité. Le serveur reçoit une requête autonome, la traite, renvoie une réponse — et peut être détruit dans la seconde qui suit sans que personne ne s’en aperçoive. C’est exactement le contrat d’un runtime serverless. La révision ajoute d’ailleurs un routage par en-têtes et des résultats de liste cachables (listes d’outils et de ressources), deux optimisations qui n’ont de sens que dans un monde où la réponse à « quels outils exposes-tu ? » ne dépend plus d’une session particulière.

Schématiquement, une requête type de bout en bout ressemble désormais à ceci : l’hôte assemble un appel contenant l’identité de l’appelant (jeton OAuth/OIDC), les capacités requises, les paramètres de l’outil visé et, le cas échéant, un identifiant de conversation géré côté client. Le client MCP route cet appel vers n’importe quelle instance du serveur. Le serveur valide le jeton, exécute l’outil, renvoie le résultat. Aucune mémoire partagée, aucun état à réconcilier. La contrepartie est nette : ce que le serveur savait implicitement, c’est maintenant au client de le dire explicitement, à chaque fois. Le contexte conversationnel, jadis implicite dans la session, devient un bagage que l’appelant doit transporter lui-même.

Cette redéfinition a une conséquence souvent sous-estimée : elle déplace la complexité de l’infrastructure vers le code applicatif. On ne configure plus des sessions collantes ; on conçoit des requêtes autoportantes. Pour les équipes, c’est un changement de métier autant qu’un changement de protocole. Et c’est précisément là que la préparation du contexte — ce que notre dossier appelle « mâcher le travail à l’agent » — cesse d’être un raffinement pour devenir une nécessité structurelle.

Multi Round-Trip Requests : le tour de passe-passe pour garder le fil sans mémoire

Comment un agent peut-il enchaîner plusieurs allers-retours avec un outil — poser une question de clarification, attendre une validation humaine, revenir avec une précision — si le serveur ne retient rien ? C’est ici qu’entrent en scène les Multi Round-Trip Requests (MRTR), l’une des innovations les plus intéressantes de la révision. L’idée : au lieu de maintenir une connexion ouverte pour dialoguer, on encapsule la possibilité d’un échange multi-tours dans la mécanique même de la requête/réponse. Les MRTR remplacent précisément les anciens appels initiés par le serveur, qui exigeaient un flux ouvert pour fonctionner.

Concrètement, un serveur peut, en réponse à un premier appel, ne pas clore l’interaction mais signaler qu’il attend un complément — une information manquante, une confirmation, un choix parmi plusieurs options. Le client, qui détient le fil, relance un nouvel appel contenant l’élément demandé. Chaque « tour » reste une requête autonome, servable par n’importe quelle instance. La conversation existe, mais elle est entièrement portée par le client, jamais par le serveur.

Le contraste avec l’ancien modèle est frappant. En stateful, le serveur gardait un pointeur vers l’échange en cours ; il suffisait de renvoyer une réponse courte et il savait à quoi elle se rattachait. En sans-état, chaque tour doit être auto-suffisant : l’identifiant de conversation, l’historique pertinent, le contexte de la demande voyagent dans la requête. C’est plus verbeux, plus coûteux en tokens, mais infiniment plus robuste : une instance qui meurt entre deux tours ne fait perdre aucune donnée, puisque rien n’y était stocké.

Les limites existent, et il faut les nommer. D’abord, le surcoût de transport : répéter le contexte à chaque tour alourdit les payloads et la facture de tokens — un point d’autant plus sensible que nos mesures maison montrent qu’un agent enchaînant 8 appels d’outils séquentiels dépasse déjà les 6 secondes de latence avant première réponse (à 800 ms par appel). Ensuite, la latence cumulée : là où une session persistante enchaînait les échanges sans re-négociation, chaque tour MRTR repasse par une validation d’identité complète. Enfin, les cas où ça coince vraiment : les workflows longs avec état intermédiaire volumineux — un agent qui construit progressivement un gros artefact sur vingt tours — deviennent coûteux à transporter intégralement à chaque étape. Pour ces scénarios, la réponse du protocole passe par une autre brique : les extensions, et notamment les Tasks.

Authentification sans état : OAuth 2.1, OIDC et la fin des sessions collantes

Si le serveur ne se souvient plus de vous, il doit vous reconnaître à chaque requête. C’est tout le chantier de la refonte de l’authentification, et c’est probablement la partie qui demandera le plus de travail aux équipes. La révision formalise un modèle d’autorisation aligné sur OAuth 2.1 / OIDC, avec plusieurs durcissements rapportés par les analyses techniques : la validation de l’issuer selon la RFC 9207 devient obligatoire, et le Dynamic Client Registration est déprécié au profit des Client ID Metadata Documents.

Le premier changement corrige une faille classique : sans validation stricte de l’émetteur du jeton, un serveur MCP pouvait accepter un jeton émis par un acteur malveillant se faisant passer pour un fournisseur d’identité légitime. La RFC 9207 impose d’annoncer explicitement l’iss et de le vérifier — une parade directe à la confusion d’émetteur. Le second changement simplifie et durcit à la fois : plutôt qu’un enregistrement dynamique de client (pratique mais permissif, source de clients fantômes), on s’appuie sur des documents de métadonnées de Client ID, plus contrôlables et auditables.

Mais l’auth sans état ouvre aussi de nouveaux pièges. Le replay d’abord : un jeton capté peut être rejoué sur n’importe quelle instance, puisque aucune session ne le lie à un contexte particulier. La parade passe par des jetons à durée de vie courte, des audiences strictes et, idéalement, une liaison cryptographique à la requête. La confusion de client ensuite : dans un monde sans session, rien n’empêche a priori un client de présenter un jeton obtenu pour un autre usage — d’où l’importance des scopes précis et de la vérification systématique. La propagation d’identité enfin, qui devient le nerf de la guerre : quand un agent agit pour le compte d’un utilisateur auprès de plusieurs serveurs en cascade, il faut propager l’identité et les autorisations de façon vérifiable à chaque saut, sans qu’aucun intermédiaire ne puisse se les approprier.

Ce durcissement s’inscrit dans un mouvement plus large, et c’est ici que les dossiers du magazine se recoupent. Le OWASP LLM Top 10 2026, publié le 3 août 2026 pendant la semaine de Black Hat USA, intègre pour la première fois des données d’incidents réels — 6 639 cas documentés, pondérés à 25 % du classement aux côtés du consensus d’experts — et place l’injection de prompt en tête des vulnérabilités. L’Agent Control Standard qui l’accompagne pose quatre contrôles qui se traduisent directement en exigences MCP : un manifeste versionné déclarant outils, domaines et effets de bord autorisés ; des scopes granulaires (read:orders ≠ write:orders ≠ refund:orders) ; une allowlist de couples outil + paramètres (montant plafonné, order_id de l’utilisateur courant, devise restreinte) ; enfin sandbox d’exécution, journalisation traçable et approbation humaine pour les actions à fort impact. Dans un protocole qui fait transiter identité et autorisations à chaque requête, ces contrôles ne sont plus optionnels. La bonne nouvelle : le sans-état rend chaque appel auditable isolément, ce qui colle parfaitement au contrôle 4. La mauvaise : il ne pardonne plus l’à-peu-près.

Tasks, MCP Apps, Enterprise Managed Authorization : le framework d’extensions entre en scène

Le sans-état seul ne suffit pas à tout faire. C’est pourquoi la révision inaugure un framework officiel d’extensions versionné, qui sort du cœur du protocole ce qui n’a pas vocation à y rester. Trois extensions inaugurales viennent compenser ce que la disparition de la session fait perdre.

La première, Tasks (io.modelcontextprotocol/tasks), s’attaque au problème des opérations longues. Elle introduit des primitives dédiées — tasks/get et tasks/update — qui permettent de créer une tâche, d’en suivre l’avancement et de la mettre à jour, sans maintenir de session ouverte. C’est la réponse directe au cas qui faisait dérailler les MRTR : un agent qui construit un gros artefact sur vingt tours n’a plus à transporter l’intégralité de l’état intermédiaire à chaque étape ; il crée une tâche, la référence par identifiant, et consulte son avancement. L’état existe, mais il est explicitement modélisé et adressable, pas enfoui dans une session implicite.

La deuxième, MCP Apps, sort du cœur les applications interactives qui s’exécutent à l’intérieur des clients d’IA. La documentation officielle distingue désormais explicitement « Build servers », « Build clients » et « Build MCP Apps » : l’interface riche qu’un serveur peut proposer à l’utilisateur devient une extension versionnée, avec son propre cycle de vie, plutôt qu’une couche noyée dans la spécification principale. Pour les éditeurs, c’est un signal clair : la partie « UI dans le client » évolue à son rythme, découplée du protocole de transport.

La troisième, Enterprise Managed Authorization, vise le scénario grand compte : celui où une organisation veut contrôler centralement quels serveurs MCP sont autorisés, avec quelle identité, et sous quelles conditions. C’est le pendant administratif du durcissement OAuth décrit plus haut — la brique qui manquait pour que le sans-état soit déployable en entreprise sans que chaque équipe réinvente sa politique d’autorisation.

Ce découpage n’est pas cosmétique. Il acte que MCP n’est plus un protocole monolithique mais une plateforme à noyau stable et extensions versionnées. Les SDK de niveau 1 — TypeScript, Python, Go et C# — implémentent déjà la révision 2026-07-28, un SDK Rust étant en bêta (YuSMP). Pour une équipe en production, la conséquence pratique est double : la migration du cœur (sessions, handshake, auth) est à faire une fois ; l’adoption des extensions (Tasks, Apps) peut se faire par étapes, en fonction des besoins réels.

Ce que ça change dans la vraie vie : du terminal au logiciel métier

La théorie est séduisante ; la pratique l’est moins si l’on n’anticipe pas les conséquences. Car la refonte sans état ne touche pas que les serveurs : elle rebat les cartes de la façon dont les LLM agissent sur les outils externes, et donc de la façon dont ils nous aident au quotidien.

Premier point de bascule : le sans-état rend le serverless réellement viable. Jusqu’ici, faire tourner un serveur MCP distant derrière un répartiteur de charge ordinaire ou en serverless exigeait des contorsions — sticky sessions, stockage de sessions partagé. Désormais, un serveur MCP peut être une simple fonction : elle reçoit une requête autoportante, exécute, répond, meurt. C’est ce qui permet à un serveur MCP de tenir la charge d’un navigateur grand public comme Safari 27, ou d’un logiciel métier comme Cinema 4D 2026.4, sans infrastructure dédiée. Pour les équipes, c’est un gain opérationnel direct : moins cher à faire monter en charge, plus facile à sécuriser, plus simple à recycler.

Deuxième point : la propagation des intégrations métier. Le mouvement décrit dans notre dossier sur MCP dans les logiciels métiers ne faiblit pas. Le Journal du Net posait en octobre 2026 la bonne question aux éditeurs de logiciels de gestion : quelle place leur restera-t-il si l’on n’a plus besoin d’ouvrir leur interface ? La réponse tient dans la typologie des quatre patterns d’intégration — serveur embarqué, API éditeur, bridge, workflow automation — et la refonte sans état favorise clairement les deux derniers : un bridge serverless et une automatisation de workflow n’ont plus à maintenir d’état de session pour fonctionner. Les projections d’adoption sont d’ailleurs sans ambiguïté : Forrester, repris par Studeria, anticipe 30 % d’adoption de MCP par les éditeurs SaaS en 2026, puis 60 % en 2027. Le sans-état lève précisément l’obstacle qui freinait les éditeurs hésitants.

Troisième point, plus subtil : le sans-état déplace la charge vers la préparation du contexte. C’est le cœur de notre dossier « Mâcher le travail à un LLM ». En 2026, deux agents bâtis sur le même modèle peuvent afficher des taux de réussite du simple au triple — la différence ne se joue plus dans la fenêtre de contexte, mais dans la chaîne de préparation qui l’entoure. La refonte MCP amplifie ce phénomène : puisque le serveur ne porte plus le contexte, c’est le client qui doit le préparer, le compresser, le valider. Les chiffres de terrain sont têtus : un agent de support client non surveillé échoue sur plus de 30 % des tâches après trois semaines d’exploitation ; un agent branché sur 15 serveurs MCP n’en sollicite en réalité qu’une demi-douzaine par tâche ; et le seuil de casse en production se situe au passage de 12 à 13 outils déclarés. Autrement dit : déclarer moins d’outils, mieux préparés, avec un contexte pré-digéré, devient non pas une bonne pratique mais une condition de survie dans un monde sans session.

Quatrième point : les MCP Events complètent le modèle. Officialisés à l’OpenAI DevDay du 29 septembre 2026, ils donnent au protocole sa troisième jambe de communication — après le requête/réponse et les MRTR — et permettent à un agent de réagir au monde au lieu de simplement l’interroger (forkast.news). Combinés au sans-état, ils dessinent une architecture où le serveur peut pousser un événement sans avoir à maintenir de session : l’événement est un message autonome, traité par n’importe quelle instance. C’est la pièce qui manquait pour que l’agent cesse de « poser des questions dans le vide ».

Cinquième point, et il est économique : le coût d’un agent dépend désormais de son architecture, pas de son modèle. Un agent correctement architecturé coûte 29 à 50 dollars par mois ; un agent mal conçu dépasse les 200 dollars par mois. La refonte sans état, en déplaçant la complexité vers le code applicatif, rend cet écart plus visible — et plus punitif pour les équipes qui n’ont pas repensé leur chaîne de contexte.

Ce qu’il faut réécrire dans un harnais existant (et ce qu’on peut garder)

Pour une équipe qui exploite déjà des agents en production, la question n’est pas « faut-il migrer ? » mais « que faut-il réécrire ? ». La bonne nouvelle, c’est que la réponse est plus circonscrite qu’on ne le craint.

Ce qu’on peut garder. Les trois primitives — outils, ressources, prompts — ne bougent pas. Les serveurs qui exposent des outils simples, sans état intermédiaire, fonctionnent tels quels une fois le SDK mis à jour. Les clients qui gèrent déjà leur propre historique de conversation (Claude Code, VS Code, Cursor) sont déjà, dans les faits, des clients « porteurs de contexte » : ils n’ont qu’à cesser de compter sur la session serveur pour retrouver le fil. Et les intégrations métier décrites plus haut — Cinema 4D, Safari, Webflow — continuent de fonctionner : c’est le transport qui change, pas le contrat d’outil.

Ce qu’il faut réécrire. D’abord, la gestion de session côté client : là où le code s’appuyait sur Mcp-Session-Id pour retrouver un échange, il faut désormais transporter explicitement l’identifiant de conversation et l’historique pertinent dans chaque requête. Ensuite, l’authentification : passage à OAuth 2.1 / OIDC avec validation RFC 9207 obligatoire et migration du Dynamic Client Registration vers les Client ID Metadata Documents. Puis, les workflows multi-tours : réécriture des appels initiés par le serveur en MRTR, et bascule vers Tasks pour les opérations longues. Enfin, la couche de préparation du contexte : c’est le chantier le plus lourd, et le plus rentable — compresser, valider, pré-digérer ce qui entre dans la fenêtre, plutôt que de compter sur une session pour le faire à votre place.

Ce qu’il faut surveiller. Les pièges de l’auth sans état (replay, confusion de client, propagation d’identité) ; le surcoût de transport des MRTR ; et surtout, la surface d’attaque que représente un serveur MCP sans état exposé publiquement. Notre dossier sur les pipelines LLM et MCP le rappelait : l’infrastructure IA est la nouvelle cible des attaquants en 2026. Un serveur qui accepte n’importe quelle requête autoportante doit être irréprochable sur la validation — sinon, il accepte n’importe quoi.

Le calendrier réaliste. Les SDK de niveau 1 sont prêts depuis l’été ; le SDK Rust est en bêta. Les extensions Tasks et Apps se déploient progressivement. Pour une équipe en production, une migration en trois temps — cœur du protocole d’abord, auth ensuite, extensions enfin — est tenable sur un trimestre. L’erreur serait de vouloir tout faire d’un coup, ou de croire que le sans-état est un simple changement de configuration : c’est un changement de modèle mental.

Le verdict : moins de magie, plus de discipline

La révision 2026-07-28 de MCP n’est pas une révolution ; c’est une maturation. En retirant la session, les mainteneurs ont retiré la magie — ce petit miracle par lequel un serveur se souvenait de vous sans que vous ayez à le lui dire. Ce qu’ils ont gagné en échange est considérable : un protocole qui scale horizontalement, qui tourne en serverless, qui se recycle sans casser de conversation, qui s’audite requête par requête. Ce qu’ils ont perdu est tout aussi réel : le contexte implicite, désormais à la charge du client.

Pour les équipes, la leçon est claire et elle rejoint celle de tous nos dossiers de l’année : en 2026, la performance d’un agent ne se joue plus dans le modèle, mais dans la chaîne qui l’entoure. La refonte MCP ne fait qu’accentuer ce basculement. Un agent bien architecturé — contexte pré-digéré, outils peu nombreux et bien préparés, auth irréprochable, extensions choisies avec soin — coûte 29 à 50 dollars par mois et réussit. Un agent mal architecturé — quinze serveurs branchés, treize outils déclarés, sessions implicites — coûte plus de 200 dollars par mois et échoue sur un tiers de ses tâches.

Le sans-état ne pardonne plus l’à-peu-près. Mais pour qui accepte de mâcher le travail à son agent, il ouvre une échelle qu’on n’avait jamais atteinte.

Sources

• Model Context Protocol — documentation officielle 2026-07-28
• MCP sans état : ce qui change pour les agents IA — YuSMP
• MCP 2026-07-28 : la refonte sans état expliquée aux équipes en production — runbookly.io
• Model Context Protocol — Wikipédia
• Model Context Protocol — GitHub
• MCP : quand l’IA entre dans vos logiciels de gestion par la porte de service — Journal du Net, 12 octobre 2026
• MCP Events Complete the Agent Communication Model — forkast.news, 29 septembre 2026
• Safari 27 Ships a Native MCP Server — forkast.news, 20 septembre 2026
• Maxon intègre un serveur MCP dans Cinema 4D 2026.4 — render.ru, 30 septembre 2026
• MCP Webflow : comment les IA lisent et modifient un site — agence-synqro.fr, 7 septembre 2026
• LLM pipelines et MCP : la surface d’attaque que personne ne surveille — ayinedjimi-consultants.fr, 19 septembre 2026
• [OWASP LLM Top 10 2026 — dossier du magazine, 3 août 2026]
• [Mâcher le travail à un LLM : le guide de terrain du contexte pré-digéré (2026) — dossier du magazine]
• [MCP dans les logiciels métiers : Cinema 4D, Safari, Webflow — dossier du magazine]
• [MCP Events : quand le serveur parle le premier — dossier du magazine]
• [Benchmarks LLM 2026 : ce que les classements mesurent vraiment — dossier du magazine]

Article recherché et rédigé automatiquement · Magazine Electrosens