MCP évolue pour mieux répondre aux exigences du cloud

Le MCP adopte une architecture sans état afin de lever une contrainte liée à la mise à l’échelle en production

Le Model Context Protocol (MCP) supprime les sessions au niveau du protocole dans sa version candidate prévue pour le 28 juillet. Il s’agit du changement architectural le plus important de cette mise à jour. Il répond à un problème concret : l’ancienne conception basée sur les sessions ne s’intégrait pas parfaitement à une infrastructure cloud standard.

Les versions antérieures nécessitaient un serveur MCP pour gérer les informations relatives à chaque connexion client. Cette approche fonctionnait lorsqu’un serveur MCP s’exécutait en tant que processus local sur l’ordinateur portable d’un développeur. Les systèmes de production sont différents. Les entreprises répartissent généralement les requêtes sur plusieurs serveurs afin de gérer un trafic plus important et de garantir la disponibilité.

L’état de session compliquait cette répartition. Une requête pouvait devoir revenir vers le serveur qui détenait les informations de session pertinentes. Les équipes chargées de l’infrastructure devaient donc mettre en place un routage tenant compte de l’état de session, souvent appelé « sessions collantes », au lieu d’envoyer librement les requêtes vers n’importe quel serveur disponible. Cela ajoutait à la complexité opérationnelle et limitait la possibilité d’une évolutivité horizontale simple.

La nouvelle conception supprime cette exigence au niveau du protocole. Chaque requête contient les informations dont un serveur MCP disponible a besoin pour la traiter de manière autonome. Les équilibreurs de charge peuvent ainsi répartir le trafic MCP entre les instances de serveur sans dépendre d’une session de protocole persistante. Cela rapproche le MCP du modèle opérationnel que les entreprises utilisent déjà pour de nombreux services cloud.

Muskan Bandta, collaboratrice spécialisée dans le cloud chez ZopDev, a qualifié l’architecture précédente de « fardeau opérationnel » dès lors que MCP a dépassé le stade du développement local. Elle a expliqué que la conception sans état change la donne lorsque les équipes chargées de l’infrastructure se demandent si MCP peut évoluer de la même manière que les autres applications cloud : « Avec le passage à une architecture sans état, la réponse est désormais oui. »

Pour les dirigeants, l’essentiel ne réside pas dans l’absence d’état en soi, mais dans la suppression des contraintes liées à l’infrastructure, à mesure que MCP passe de la phase de projets pilotes d’IA à la mise en production. Les entreprises peuvent ainsi s’appuyer sur des pratiques cloud éprouvées en matière d’équilibrage de charge, de mise à l’échelle et de déploiement distribué, plutôt que de s’appuyer sur une exigence de session au niveau du protocole.

Il reste encore du travail à accomplir en matière de migration. Le modèle MCP sans état ne signifie pas que les applications n’ont plus besoin d’état. Cela change simplement qui en assure la gestion. Toute application nécessitant que des informations soient conservées d’une requête à l’autre doit gérer ces informations de manière explicite. Les organisations dont l’infrastructure repose sur l’ancien modèle de session devront donc identifier ces dépendances avant de pouvoir tirer pleinement parti des avantages opérationnels.

La gestion explicite de l’état offre aux entreprises un meilleur contrôle sur le contexte de l’IA

L’architecture sans état modifie également la manière dont les applications MCP gèrent le contexte. Dans la conception précédente, une partie de l’état pouvait être conservée au sein d’une session de protocole. Dans le nouveau modèle, les applications nécessitant un contexte persistant doivent le définir, le stocker et le transmettre explicitement.

Il s’agit d’un changement de conception important pour les systèmes d’IA. Le MCP relie les modèles aux outils et aux données d’entreprise. Ces interactions dépendent souvent du contexte issu des étapes précédentes : ce que l’utilisateur a demandé, quel outil a déjà été exécuté, quelles informations il a renvoyées et quelle doit être la suite du processus. Le fait de rendre cet état explicite offre aux développeurs un meilleur contrôle sur les informations qui circulent entre les modèles et les outils.

Amit Jena, responsable du développement de l’IA au sein du cabinet de conseil en informatique Kanerika, a déclaré que cette évolution permettait aux modèles d’IA d’accéder aux informations contextuelles, de les analyser et de les transmettre d’un outil à l’autre, plutôt que de laisser l’état des applications dissimulé au sein des sessions de protocole. Il estime également que cette conception rendra les flux de travail basés sur l’IA plus portables, plus résilients et plus faciles à orchestrer dans des environnements distribués.

Pour les dirigeants d’entreprise, la définition explicite de l’état peut améliorer la visibilité de l’architecture. Les équipes peuvent décider où le contexte est stocké, quels systèmes peuvent y accéder et à quel moment il doit être transmis à un autre outil. Ces choix sont déterminants pour la sécurité, la gouvernance des données et le dépannage. Ils revêtent également une importance particulière lorsqu’un workflow s’étend sur plusieurs services, environnements cloud ou outils tiers.

Le compromis est clair. Le MCP n’est plus chargé de gérer automatiquement cet état. Les équipes applicatives assument désormais une plus grande part de la conception de la gestion de l’état. Une mauvaise mise en œuvre peut toutefois encore entraîner des incohérences de contexte, une exposition inutile des données ou des défaillances entre les étapes du workflow. La nouvelle architecture offre un meilleur contrôle, mais les entreprises doivent utiliser ce contrôle de manière réfléchie.

La conception de l’état relève ainsi davantage de la responsabilité de l’application que d’une contrainte imposée par le protocole. C’est la bonne orientation à adopter pour les déploiements MCP en production. Cela permet de dissocier la gestion du routage des requêtes indépendantes de la préservation du contexte métier, ce qui donne aux entreprises la possibilité de choisir des méthodes de gestion de l’état adaptées à leurs propres exigences en matière de sécurité, de fiabilité et d’exploitation.

Le MRTR permet de mettre en œuvre des flux de travail d’IA en plusieurs étapes sans connexions persistantes

Le passage de MCP à une infrastructure sans état crée une exigence pratique. Les agents d’IA doivent toujours effectuer des échanges en plusieurs étapes. Un outil peut lancer une tâche, constater qu’il lui manque des informations, demander des données supplémentaires, puis poursuivre son exécution. Le nouveau mécanisme MRTR (Multi Round-Trip Requests) prend en charge ce schéma sans nécessiter de connexion client-serveur persistante.

Dans le cadre du protocole MRTR, un serveur MCP peut demander des informations supplémentaires par le biais d’un échange standard de requêtes et de réponses. Une fois les données requises reçues, le traitement peut se poursuivre. Amit Jena, responsable du développement de l’IA au sein du cabinet de conseil en informatique Kanerika, a expliqué que cela évite d’avoir à maintenir une connexion active pendant toute la durée de l’interaction.

Cette distinction est importante, car le transport « sans état » ne signifie pas que les flux de travail d’IA doivent nécessairement se dérouler en une seule étape. Le MCP peut supprimer les sessions au niveau du protocole tout en continuant à prendre en charge les tâches qui nécessitent plusieurs échanges. La différence réside dans le fait que l’interaction devient une séquence de requêtes explicites plutôt qu’une activité liée à une connexion maintenue en permanence.

Pour les entreprises, cette architecture s’intègre plus naturellement à une infrastructure distribuée. Les requêtes individuelles peuvent transiter par des équilibreurs de charge, des passerelles et d’autres composants réseau standard sans qu’il soit nécessaire de maintenir ouverte la même connexion au serveur pendant toute la durée de la tâche. Cela permet de simplifier le déploiement et de faciliter l’isolation des défaillances.

Les dirigeants ne doivent pas partir du principe que le MRTR réduit automatiquement la latence ou l’utilisation des ressources dans tous les flux de travail. Chaque échange supplémentaire entraîne toujours des coûts liés au réseau et au traitement. Le principal avantage est d’ordre architectural : les applications peuvent prendre en charge des demandes d’entrées supplémentaires tout en préservant le modèle sans état.

Les implications pour l’entreprise sont claires. MCP sépare la logique des workflows d’IA de longue durée des connexions réseau persistantes. Cela offre aux développeurs davantage de flexibilité pour créer des agents interactifs, tandis que les équipes chargées de l’infrastructure continuent de bénéficier des avantages liés à l’évolutivité des services sans état.

MCP intègre des contrôles d’entreprise pour le routage, l’identité et la mise en cache

La mise à jour de MCP répond également à trois préoccupations liées à l’environnement de production : la manière dont les requêtes sont acheminées, la manière dont l’accès est autorisé et la manière dont les informations de protocole répétitives sont mises en cache. Ces modifications facilitent l’utilisation de MCP au sein de l’infrastructure dont disposent déjà les entreprises.

Les en-têtes de transport routables constituent la première amélioration. Elles permettent aux passerelles API et autres infrastructures réseau d’identifier et d’acheminer les requêtes MCP sans en examiner le contenu. Amit Jena, responsable du développement IA chez Kanerika, a déclaré que cela pouvait réduire la charge de traitement et la latence, tout en permettant aux équipes d’appliquer des politiques de routage, de limitation de débit et de sécurité via les systèmes de gestion d’API existants.

Cela revêt une importance particulière à l’échelle de l’entreprise. Les passerelles API servent souvent de points de contrôle pour la gestion du trafic. Le fait de leur fournir des informations de routage dans un en-tête standard réduit le recours à une inspection spécifique au MCP ou à une gestion personnalisée. Les équipes chargées de l’infrastructure peuvent ainsi appliquer des contrôles opérationnels établis au trafic MCP, plutôt que de créer un circuit de gestion distinct.

Le système d’autorisation fait également l’objet d’une mise à jour autour des normes OAuth 2.1 et OpenID Connect. OAuth 2.1 fournit un cadre permettant de contrôler l’accès délégué, tandis qu’OpenID Connect offre une couche d’identité. Leur intégration offre aux entreprises des mécanismes éprouvés pour déterminer qui ou quoi peut accéder aux ressources connectées au MCP. Cette mise à jour inclut également des applications MCP interactives.

La troisième modification concerne la mise en cache déterministe des listes d’outils et de ressources. Les clients MCP ont besoin d’informations décrivant les outils et les ressources disponibles. Le fait de rendre ces listes pouvant être mises en cache de manière prévisible peut augmenter les taux de réussite des requêtes dans le cache des prompts des LLM.

Pour les dirigeants, ces changements revêtent une grande importance, car les contraintes liées à l’IA d’entreprise ne se limitent pas aux seules capacités des modèles. Les systèmes de production nécessitent également un contrôle d’accès, une gestion du trafic et des coûts d’exploitation prévisibles. MCP adapte de plus en plus ces exigences à des formats compatibles avec l’infrastructure d’entreprise existante.

Cette mise à jour ne dispense pas de la nécessité d’une gouvernance. L’autorisation basée sur OAuth doit toujours être configurée correctement. Les politiques de routage doivent refléter les exigences réelles en matière de sécurité. Les stratégies de mise en cache doivent tenir compte des évolutions des outils et des ressources. Le protocole fournit de meilleurs éléments de base, mais l’entreprise reste responsable de la manière dont ces contrôles sont mis en œuvre.

Dans leur ensemble, ces ajouts renforcent les atouts de MCP en matière de production. Le fonctionnement sans état résout les problèmes d’évolutivité, le MRTR préserve les interactions en plusieurs étapes, et les modifications apportées au routage, à l’autorisation et à la mise en cache répondent à des exigences pratiques qui prennent de plus en plus d’importance à mesure que MCP passe du stade des expérimentations des développeurs à celui des systèmes d’IA d’entreprise gérés.

Les modifications liées à la prise en charge obsolète de l’échantillonnage affectent la limite de confiance de MCP

MCP va supprimer progressivement cinq fonctionnalités héritées : Roots, l’échantillonnage, la journalisation, l’ancien protocole de transport HTTP+SSE et l’enregistrement dynamique des clients. Celles-ci continueront de fonctionner dans la version actuelle ainsi que dans les versions qui seront publiées au cours de l’année à venir. Cette période de transition permet de limiter les perturbations immédiates, mais les entreprises devraient en profiter pour identifier dès à présent leurs dépendances.

L’échantillonnage constitue le changement le plus important. Dans le cadre du mécanisme actuel, un serveur MCP peut demander au client d’invoquer un grand modèle linguistique en son nom. Le serveur dispose ainsi d’un chemin de rappel indirect vers le modèle sans avoir à maintenir sa propre connexion avec le fournisseur du modèle.

La mise en déuse du « Sampling » modifie cette architecture. Selon Amit Jena, responsable du développement de l’IA au sein du cabinet de conseil en informatique Kanerika, un serveur ayant besoin d’accéder à un modèle s’adressera désormais directement au fournisseur de ce modèle. Il en a clairement décrit les conséquences : « Cela modifie votre architecture réseau, votre modèle d’authentification et, selon la manière dont vous avez mis en place l’imputation des coûts, votre processus de facturation. »

Pour une entreprise, cela implique un changement au niveau de plusieurs responsabilités. Un serveur se connectant directement à un fournisseur de modèles peut nécessiter son propre accès réseau et ses propres identifiants. Les équipes de sécurité doivent déterminer quels serveurs sont autorisés à effectuer ces appels et quelles autorisations leur sont accordées. Les équipes FinOps peuvent également devoir repenser la manière dont l’utilisation des modèles est mesurée et attribuée aux applications, aux équipes ou aux clients.

La question fondamentale concerne la limite de confiance. L’échantillonnage plaçait le client entre le serveur MCP et le modèle. La suppression de ce mécanisme modifie le composant habilité à utiliser un modèle, ainsi que l’origine du trafic entre le modèle et son fournisseur. Les contrôles de sécurité existants, conçus autour de cette approche impliquant le client, pourraient donc devoir être revus.

Les dépendances vis-à-vis de tiers constituent un risque supplémentaire. Une entreprise peut n’avoir jamais implémenté directement Sampling, mais pourrait néanmoins s’appuyer sur un serveur MCP externe qui l’utilise. Jena a averti que les équipes pouvaient ignorer l’existence de telles dépendances. Une analyse du code source des applications internes pourrait donc s’avérer insuffisante à elle seule. Les organisations doivent disposer d’un inventaire des serveurs MCP et vérifier comment chacun d’entre eux interagit avec les modèles.

Cette période de compatibilité d’environ un an donne aux entreprises le temps de mettre en œuvre ces changements de manière maîtrisée. Elle doit être considérée comme une fenêtre de migration plutôt que comme une raison de reporter toute action. La priorité consiste à identifier les dépendances liées à Sampling, à déterminer quels serveurs nécessiteront un accès direct au modèle, et à mettre à jour les contrôles relatifs au réseau, à l’identité et aux coûts avant la fin de la prise en charge des systèmes existants.

Les SDK rétrocompatibles réduisent le risque immédiat lié à la migration

La mise à jour MCP comprend de nouveaux SDK pour Python, TypeScript, Go et C#. Ceux-ci prennent en charge à la fois les anciennes et les nouvelles versions du protocole. Les nouveaux clients peuvent continuer à communiquer avec les serveurs plus anciens, tandis que les serveurs mis à jour peuvent toujours fonctionner avec les clients plus anciens.

Cette rétrocompatibilité est importante, car elle permet aux entreprises de ne pas avoir à mettre à niveau tous les composants MCP en même temps. Les équipes peuvent mettre à jour les clients, les serveurs et l’infrastructure associée par étapes. Cela réduit le risque d’une interruption immédiate du service et offre aux grandes organisations un meilleur contrôle sur les calendriers de déploiement.

Muskan Bandta, collaboratrice spécialisée dans le cloud chez ZopDev, a déclaré que cela devrait permettre une transition essentiellement progressive. La principale exception concerne les entreprises qui ont mis en place une infrastructure sur mesure autour de l’ancienne architecture basée sur les sessions de MCP. Ces systèmes peuvent reposer sur des hypothèses que la compatibilité des protocoles ne saurait à elle seule résoudre.

La principale difficulté liée à la migration consiste à identifier ces hypothèses. Amit Jena, responsable du développement de l’IA chez Kanerika, a expliqué que la gestion des sessions peut être intégrée dans les configurations des passerelles, les scripts de déploiement et les tableaux de bord de surveillance. Comme il l’a souligné : « La modification du code est minime ; c’est le fait de repérer partout où ces hypothèses se trouvent qui prend du temps. »

Il s’agit là d’une distinction importante pour les dirigeants chargés de planifier les budgets et les calendriers de migration. Une équipe chargée des applications peut mettre à jour rapidement un SDK MCP, tandis que l’environnement de production dans son ensemble continue de partir du principe que les requêtes sont renvoyées vers un serveur spécifique. Les règles d’équilibrage de charge, les systèmes d’observabilité, les configurations de déploiement et les procédures opérationnelles pourraient tous conserver des dépendances vis-à-vis du comportement des sessions.

La compatibilité ascendante porte donc sur l’interopérabilité des protocoles, et non sur l’ensemble du problème de migration. Elle atténue la pression liée à la nécessité de coordonner une mise à niveau immédiate sur l’ensemble des clients et des serveurs. Elle n’identifie ni ne supprime automatiquement les infrastructures construites autour de sessions persistantes.

Les entreprises doivent aborder ce changement comme un audit de l’architecture et des opérations. Les équipes doivent recenser les emplacements où l’état de session est présent, déterminer quels systèmes en dépendent et décider où l’état de l’application sera hébergé après la migration. Les procédures de surveillance et de reprise après sinistre doivent également être testées par rapport à la conception sans état.

Dans l’ensemble, la transition devrait être gérable pour la plupart des organisations, car le MCP préserve la compatibilité entre les différentes générations de protocoles. Les entreprises qui auront le plus de travail à fournir seront celles qui ont procédé à des personnalisations plus poussées autour de l’ancien modèle. Pour elles, la quantité de code d’application à modifier sera peut-être faible, mais c’est la recherche et la suppression des dépendances opérationnelles cachées qui détermineront l’ampleur réelle de l’effort de migration.

Principaux enseignements pour les dirigeants

• Le MCP sans état simplifie la mise à l’échelle dans le cloud : la suppression des sessions au niveau du protocole permet aux requêtes de s’exécuter sur n’importe quel serveur disponible et réduit la complexité de l’infrastructure. Les responsables doivent identifier les systèmes qui dépendent encore d’un routage tenant compte des sessions avant de procéder à la migration.
• L’état explicite confère davantage de contrôle et de responsabilité : les applications doivent désormais gérer un contexte persistant au lieu de s’appuyer sur les sessions MCP. Définissez où le contexte est stocké, qui peut y accéder et comment il circule entre les modèles et les outils.
• Le MRTR préserve les workflows d’IA en plusieurs étapes : les requêtes à allers-retours multiples (Multi Round-Trip Requests) permettent aux serveurs de demander davantage d’informations sans maintenir de connexions persistantes. Cela prend en charge les workflows interactifs des agents tout en conservant les avantages opérationnels d’une infrastructure sans état.
• Les contrôles d’entreprise deviennent plus faciles à intégrer : les en-têtes routables, OAuth 2.1, OpenID Connect et la mise en cache déterministe améliorent la compatibilité avec les systèmes existants d’API, d’identité et de gestion des coûts. Les équipes doivent réutiliser les contrôles de gouvernance établis plutôt que de créer une infrastructure spécifique à MCP lorsque cela n’est pas nécessaire.
• La dépréciation de Sampling nécessite un audit de l’architecture : la suppression de Sampling modifie la manière dont les serveurs MCP accèdent aux modèles, ce qui a des répercussions sur les chemins réseau, l’autorisation et, éventuellement, la facturation. Profitez de la période de transition d’environ un an pour identifier les dépendances directes et tierces avant la fin de la prise en charge des versions héritées.
• La rétrocompatibilité limite les perturbations : les SDK mis à jour pour Python, TypeScript, Go et C# prennent en charge les anciennes et les nouvelles versions du protocole, ce qui permet des mises à niveau progressives. Les responsables doivent toutefois continuer à vérifier les passerelles, les scripts de déploiement et les systèmes de surveillance afin de détecter d’éventuelles hypothèses cachées concernant les sessions persistantes.