MCP 2026-07-28 : ce que le protocole sans état signifie pour les déploiements d'agents B2B

Pourquoi cette version change l'équation de déploiement

Le Model Context Protocol (MCP) est un standard ouvert pour connecter les agents IA aux systèmes externes. Le 28 juillet 2026, il publie sa plus grande révision depuis son lancement — un candidat à la publication qui rend la couche de protocole sans état, introduit des extensions de premier ordre et déprécie trois fonctionnalités qui ajoutaient de la complexité sans justifier leur place en production.

Pour les équipes qui déploient des serveurs MCP derrière des systèmes d'agents B2B, l'impact pratique est concret : vous n'avez plus besoin de sessions persistantes, de magasins de sessions partagés ou d'équilibreurs de charge sensibles aux sessions. L'état dont un agent a besoin à travers plusieurs appels d'outils devient un handle explicite — visible pour le modèle, auditable dans les journaux et mettable en cache par les intermédiaires. Cet article parcourt les changements qui comptent pour les déploiements B2B et leur correspondance avec le pattern de module MCP que nous livrons déjà.

La couche de protocole sans état

Le changement principal : la poignée de main initialize / initialized et l'en-tête Mcp-Session-Id sont supprimés. Les requêtes sont désormais autonomes. La version du protocole, les informations client et les capacités transitent dans _meta sur chaque requête, pas dans une session négociée que le serveur doit mémoriser.

Ce que cela élimine dans un déploiement B2B :

• Équilibreurs de charge à sessions persistantes. Les serveurs MCP distants peuvent se trouver derrière des équilibreurs de charge en simple tourniquet. N'importe quelle instance de serveur peut traiter n'importe quelle requête car aucun état côté serveur n'est requis pour l'interpréter.
• Magasins de sessions partagés. Si vous mettez à l'échelle horizontalement aujourd'hui, chaque instance de serveur MCP a besoin d'accéder au même état de session — généralement Redis ou une base de données. Le protocole sans état supprime cette dépendance.
• Infrastructure de rejeu de session. Lorsqu'une session tombe en cours de flux de travail, le client doit réinitialiser et réétablir le contexte. Le protocole sans état n'a pas de session à faire tomber ; chaque requête transporte ce dont elle a besoin.

La forme du déploiement devient plus simple : un pool d'instances de serveurs MCP sans état derrière un équilibreur de charge, sans tier d'état partagé entre elles. C'est la même forme que n'importe quelle API HTTP sans état — éprouvée, observable et peu coûteuse à mettre à l'échelle.

Le pattern de handle explicite pour les flux de travail avec état

Sans état ne signifie pas que l'état disparaît. Les flux de travail qui s'étendent sur plusieurs appels d'outils — une réception de RFQ, une négociation de devis, une réservation de disponibilité — ont toujours besoin de continuité. Le candidat à la publication remplace l'état de session caché par le pattern de handle explicite : un outil crée un handle (un order_id, un quote_id, un basket_id) et le modèle le repasse comme argument ordinaire lors des appels suivants.

C'est un changement significatif pour les déploiements B2B pour trois raisons.

L'état est visible pour le modèle. Aujourd'hui, l'état de session vit dans des métadonnées de transport que le LLM ne voit jamais. Avec les handles explicites, le modèle détient et référence le handle dans son raisonnement. Lorsque le modèle appelle get_quote(quote_id="q-7f3a"), il sait sur quel devis il opère. Cela améliore la précision de sélection d'outils dans les flux de travail à étapes multiples.

L'état est auditable dans les journaux. Chaque requête transporte son handle dans le corps de la requête, pas dans un en-tête que le journaliseseur d'application supprime. Un trail d'audit peut reconstruire l'état complet du flux de travail à n'importe quel point en lisant les arguments de la requête — aucune corrélation avec les journaux du magasin de sessions n'est nécessaire.

L'état est mettable en cache par les intermédiaires. Parce que le handle fait partie de la requête, une passerelle ou une couche de cache peut s'y fier. Les résultats de liste et de ressource portent les champs ttlMs et cacheScope, donc une requête de catalogue avec un handle stable peut être servie depuis le cache sans solliciter le système en amont.

Comment cela correspond à un flux de travail RFQ

Considérez un flux de travail de devis qui s'exécute sur cinq appels d'outils : créer la demande, chercher dans le catalogue, générer le devis, réserver la disponibilité, appliquer le palier de prix. Sous le protocole basé sur session, ces cinq appels partagent une session côté serveur. Sous le pattern de handle explicite :

1. create_request(buyer_id, line_items) → request_id="r-1042"
2. search_catalog(request_id="r-1042", query="industrial pump 220V")
3. generate_quote(request_id="r-1042", supplier_ids=["s-12", "s-19"])
       → quote_id="q-7f3a"
4. hold_availability(quote_id="q-7f3a", hold_duration="48h")
       → hold_id="h-3391"
5. apply_pricing_tier(quote_id="q-7f3a", tier="volume-3")

Chaque appel transporte le handle dont il a besoin. Aucun serveur ne mémorise quoi que ce soit entre les appels. Si l'équilibreur de charge achemine l'appel 4 vers une instance différente de l'appel 3, cela fonctionne toujours — le handle est dans la requête. Si l'équipe d'audit doit reconstruire ce flux de travail une semaine plus tard, les handles dans les arguments de requête racontent toute l'histoire.

Extensions : de premier ordre et versionnées indépendamment

Le candidat à la publication introduit les extensions comme concept de premier ordre. Les extensions reçoivent des identifiants reverse-DNS (par ex. com.example.workflow), possèdent des dépôts ext-*, ont des responsables délégués et sont versionnées indépendamment du protocole central.

Les deux premières extensions sont concrètes :

• MCP Apps — des UI HTML rendues côté serveur livrées dans des iframes bac à sable. Un serveur MCP peut livrer une UI qu'un client affiche, permettant des surfaces d'approbation humaine dans la boucle sans que le client construise un frontend personnalisé.
• Tasks — des travaux longs avec des handles de tâche. Un outil peut renvoyer un handle de tâche immédiatement et le client interroge l'achèvement, plutôt que de maintenir une connexion ouverte pendant des minutes.

Pour les déploiements B2B, MCP Apps comptent là où un humain doit approuver une transaction avant que l'agent ne poursuive — un bon de commande au-dessus d'un seuil, un devis avec une remise non standard. La surface d'approbation peut être livrée avec le module MCP plutôt que de nécessiter un frontend séparé. Tasks comptent pour les flux de travail qui dépassent un seul délai de requête : un devis fournisseur qui prend 90 secondes à générer, une synchronisation de catalogue qui dure des minutes.

Déprécations : Roots, Sampling, Logging

Trois fonctionnalités sont dépréciées (en annotation seule pendant 12 mois ; la suppression nécessite un processus de normes séparé) :

• Roots → remplacés par les paramètres d'outil et les URI de ressource. Roots étaient un moyen pour les clients d'indiquer aux serveurs des emplacements de système de fichiers ; la même intention s'exprime désormais en arguments d'outils qui lisent des fichiers.
• Sampling → remplacé par l'intégration directe avec l'API du fournisseur LLM. Les serveurs qui ont besoin d'appels LLM les font directement au fournisseur, plutôt que de demander au client d'effectuer un aller-retour de sampling.
• Logging → remplacé par stderr et OpenTelemetry. La journalisation du serveur passe à la sortie de processus standard et au traçage distribué, pas au canal de journalisation MCP.

La dépréciation de Logging est la plus pertinente pour les déploiements B2B. Le pattern de journalisation d'audit — où chaque appel d'outil journalise la requête, la réponse, la latence et le résultat — s'aligne désormais avec OpenTelemetry plutôt qu'avec un canal de journalisation spécifique au protocole. Cela signifie que les journaux du serveur MCP s'intègrent aux pipelines d'observabilité existants (Datadog, CloudWatch, Honeycomb) sans transport personnalisé.

Routable, mettable en cache, traçable

Trois ajouts qui affectent les opérations de production :

• Les en-têtes Mcp-Method et Mcp-Name permettent le routage par passerelle sans inspection du corps. Une passerelle peut router par méthode et nom d'outil au niveau des en-têtes — pas de parsing JSON dans la couche de routage.
• ttlMs et cacheScope sur les résultats de liste/ressource donnent aux intermédiaires un contrat de mise en cache standard. Une réponse de liste de catalogue peut déclarer un TTL de 5 minutes, et n'importe quelle passerelle sur le chemin peut le respecter.
• La propagation du W3C Trace Context est documentée pour la compatibilité OpenTelemetry. Une trace initiée par le client agent se propage à travers le serveur MCP et dans les appels système en amont, de sorte qu'un seul flux de travail RFQ apparaît comme une seule trace à travers chaque système qu'il touche.

Pour un déploiement B2B qui exécute des serveurs MCP pour NetSuite, HubSpot et un catalogue fournisseur, cela signifie : une passerelle peut router par nom d'outil sans parser les corps, mettre en cache les réponses de catalogue pour un TTL déclaré et tracer une seule demande de devis de l'agent à l'ERP à l'API fournisseur dans un seul arbre de spans.

Renforcement de l'autorisation pour la forme un-à-plusieurs

Le candidat à la publication améliore OAuth et OpenID Connect pour la forme de déploiement que les systèmes d'agents B2B utilisent réellement : un client (l'agent) se connectant à de nombreux serveurs (NetSuite, HubSpot, BigCommerce, un catalogue fournisseur). L'actualisation des jetons, la gestion des scopes et le traitement multi-serveurs des identifiants sont traités dans la spécification plutôt que laissés à chaque intégration à résoudre indépendamment.

Cela compte parce que les systèmes d'agents B2B ne se connectent pas à un seul système. Un agent RFQ typique se connecte à un ERP (NetSuite), un CRM (HubSpot), une plateforme e-commerce (BigCommerce) et deux ou trois catalogues fournisseurs — chacun avec son propre flux OAuth, sa durée de vie de jeton et son ensemble de scopes. Le protocole fournit désormais un pattern standard pour gérer cette complexité, plutôt que chaque module MCP implémentant son propre cycle de vie d'identifiants.

Ce qui change pour les modules MCP existants

Si vous livrez déjà des modules MCP — par exemple, le pattern de processeur RFQ à 38 outils où les outils sont enregistrés via MCP_CONFIGURATION et les mixins de domaine composent sur un client GraphQL partagé — le protocole sans état change le déploiement, pas le code du module.

L'enregistrement des outils du module, les schémas d'entrée/sortie, les limites de débit et la journalisation d'audit restent les mêmes. Ce qui change :

• Pas d'initialisation de session au démarrage. Le module ne participe pas à une poignée de main initialize. Il reçoit des requêtes avec _meta portant la version du protocole et les capacités, et répond.
• Les outils avec état créent des handles. Si un outil s'appuie aujourd'hui sur une session côté serveur pour suivre un flux de travail à étapes multiples, il doit créer un handle explicite et le renvoyer. Le client le repasse à l'appel suivant. Pour un processeur RFQ, le request_id, le quote_id et le hold_id sont déjà les handles — le pattern est naturel au domaine.
• La journalisation passe à OpenTelemetry. Si le module journalise via le canal de journalisation MCP, migrez vers stderr et les spans OpenTelemetry. Le contenu d'audit (requête, réponse, latence, résultat) reste ; le transport change.
• La mise en cache est déclarative. Les endpoints de liste et de ressource peuvent déclarer ttlMs et cacheScope sur leurs réponses, permettant aux intermédiaires de mettre en cache sans deviner.

La conclusion pour les équipes B2B

Le protocole sans état réduit l'infrastructure qu'un déploiement d'agent basé sur MCP nécessite. Vous échangez les sessions persistantes et les magasins de sessions partagés contre des handles explicites dans les arguments de requête — un échange qui rend le système plus simple à mettre à l'échelle, plus facile à auditer et plus observable dans des outils standard.

Si votre équipe délimite un déploiement d'agent basé sur MCP, le candidat à la publication du 28 juillet est la version à cibler. Concevoir pour des handles explicites dès le départ évite la migration depuis un état basé sur session plus tard.

---

Un distributeur qui exploite NetSuite, BigCommerce et trois catalogues fournisseurs obtient un agent qui reçoit un RFQ par e-mail ou portail, résout les produits et substituts contre le graphe de catalogue, fixe les prix par palier client, réserve le stock avec une expiration et écrit le devis accepté dans NetSuite — chaque étape journalisée. Cette construction correspond aux phases 2-3 de la méthode en quatre étapes et est généralement en ligne en 5-8 semaines.

Demandez une construction délimitée. Découverte d'une semaine. Vous obtenez un inventaire des systèmes, une cartographie des flux de travail et un périmètre fixe — que vous construisiez avec nous ou non.