ninog - Fotolia

Actualites

IA en entreprise : MCP mûrit et se convertit au « stateless »

Les experts saluent cette évolution, plus adaptée aux usages en production, mais attention au changement cassant pour les systèmes MCP déjà en place.

Beth Pariseau
par
Publié le: 29 juil. 2026

Le 28 juillet, la communauté derrière MCP a publié une mise à jour majeure de la spécification. Pour les experts, cette évolution du protocole open source le plus populaire de l’IA agentique (les SDK Python et TypeScript ont franchi le cap du milliard de téléchargements par mois) marque « une étape clé vers la maturité de l’IA en entreprise ».

Model Context Protocol (MCP) a été créé par Anthropic et a été cédé l’année dernière à l’Agentic AI Foundation, une filiale de la Linux Foundation. Il définit un format standard utilisé par les serveurs MCP pour mettre à disposition des outils, des données et des prompts aux hôtes MCP, ou clients, qui envoient des requêtes pour le compte d’agents d’IA.

À l’origine, les serveurs et clients MCP utilisaient des « sessions persistantes ». Elles devaient être explicitement activées dans le code pour permettre la communication entre clients et instances spécifiques de serveurs MCP.

La mise à jour majeure adopte désormais une architecture de transport sans état (« stateless »). Elle dissocie les clients MCP de serveurs MCP back-end spécifiques et permet la communication via des répartiteurs de charge avec des pools de serveurs, ce qui facilite le passage à l’échelle.

« Cette architecture correspond davantage au mode de fonctionnement de la plupart des applications d’entreprise », déclare Nate Barbettini, fondateur et membre de l’équipe technique d’Arcade.dev (fournisseur de passerelles MCP) et contributeur en amont du projet MCP, lors d’un entretien avec Informa TechTarget [propriétaire du MagIT].

« La conception initiale de MCP s’inspirait fortement du Language Server Protocol, qui n’est vraiment pertinent que lorsque l’on communique avec une machine locale », poursuit-il. « À mesure que MCP a évolué et qu’il a commencé à être utilisé non seulement sur une machine locale, mais aussi à distance, et désormais via HTTP. […] Cela nous a contraints à repenser le protocole. Je vois cela comme un signe de maturité, un passage à l’âge adulte ».

Selon un professionnel IT qui a développé ses propres serveurs MCP, ne plus inclure d’informations spécifiques sur les serveurs dans les échanges répond aux bonnes pratiques de performance et de sécurité dans les SI infusés à l’IA.

« Avec la gestion des états, il y a une authentification bidirectionnelle, et chaque requête doit comporter un identifiant de session spécifique, ce qui nécessite une négociation entre le serveur et le client », explique Suresh Gangula, ingénieur DevOps dans une entreprise du Fortune 100 dont il a demandé à taire le nom en raison de politiques lui interdisant de la représenter dans la presse. « C’est une charge pour le service de l’envoyer à chaque fois. Avec la nouvelle approche sans état, la requête ne contient qu’un champ méta “underscore”, ce qui est à la fois plus sécurisé et plus rapide ».

Plus précisément, les flux bidirectionnels sont remplacés par des requêtes à allers-retours multiples.

Le champ méta « underscore » masque les informations de serveur et de session aux yeux d’un attaquant potentiel, qui pourrait autrement les exploiter pour accéder au système back-end.

Ces informations doivent toutefois être fournies via un système distinct.

« Supprimer la session au niveau du protocole n’oblige pas votre application à être “stateless” », précise le billet de blog qui accompagne la mise à jour. « Si votre serveur doit conserver un état entre les appels, créez un identifiant explicite à partir d’un outil et faites en sorte que le modèle le renvoie en tant qu’argument. Nous avons constaté que cela fonctionne mieux qu’un état de session masqué dans le transport : le modèle peut voir l’identifiant et le faire circuler entre les outils ».

MCP peaufine ses spécifications d’authentification et gagne en stabilité

« MCP est en train d’être repensé pour s’adapter au fonctionnement réel des systèmes web modernes », salue Rob Strechay, analyste, fondateur et directeur du cabinet Smuget Consulting. « La suppression des sessions au niveau du protocole signifie que les requêtes peuvent être traitées par n’importe quelle instance de serveur derrière un équilibreur de charge classique, ce qui élimine le besoin d’un routage persistant et de magasins de sessions partagés, et permet une évolutivité horizontale plutôt que des serveurs de plus en plus puissants. »

La version du MCP publiée le 28 juillet met également à jour la spécification afin de l’aligner plus explicitement sur les pratiques d’autorisation et d’authentification d’OAuth 2.0 et d’OpenID Connect.

« C’est une clarification importante », juge Nate Barbettini. « Nous l’avons en quelque sorte appris à nos dépens : nous gérons un déploiement MCP assez important, et nous avons reçu très tôt de nombreux rapports de bogues de la part de nos clients. […] Nous avons remonté la piste jusqu’au fait que certains clients MCP ne suivaient pas à la lettre les directives strictes figurant, par exemple, dans la spécification OpenID Connect ou la spécification OAuth concernant la manière dont il est censé gérer certains cas limites ».

Un an pour s’adapter à ce changement cassant

Si les éditeurs et les analystes saluent cette évolution, cette mise à jour constitue un changement « cassant ».

« L’adoption de la nouvelle version nécessite une refonte pour tirer parti de ses avantages, et les fournisseurs MCP devront s’y atteler à court terme – dans les 12 mois – pour mettre en œuvre ces changements », souligne Jim Mercer, analyste chez IDC. « Nous avons clairement constaté la prolifération des solutions MCP : cela pourrait donc poser des problèmes aux entreprises une fois la période de grâce terminée ».

Il existe également un risque de perturbation et de fragmentation entre les différentes versions des clients et serveurs MCP à mesure que les développeurs procèdent aux mises à jour, reconnaît Nate Barbettini.

« Si les entreprises disposent de clients ou d’agents personnalisés, ceux-ci doivent être mis à jour pour prendre en charge le nouveau protocole, et ce n’est pas une mince affaire », précise-t-il. « C’est un changement assez important ».

Cela dit, la mise à jour du 28 juillet introduit des mécanismes destinés à rendre les futures mises à jour moins perturbantes. Elle décrit un cycle de vie formel qui prévoit un délai de douze mois entre la dépréciation d’une fonctionnalité et sa suppression. Par ailleurs, les contributeurs peuvent développer des extensions optionnelles indépendamment de la spécification principale.

« Oui, c’est une rupture brutale, mais comme les deux versions peuvent coexister pendant la transition, et que les ajustements à apporter au serveur nécessitent principalement une recompilation basée sur la nouvelle version du SDK, l’impact semble plutôt limité », considère Torsten Volk, analyste chez Omdia, une division d’Informa TechTarget. « Certes, il faudra encore régler d’éventuelles limites budgétaires ou de débit, ou d’autres détails mineurs liés à la session côté serveur, mais cela ne me semble pas insurmontable ».

L’ajout d’un délai de dépréciation d’un an confirme, selon lui, la maturation de MCP. Cela ne veut pas dire que le protocole ne doit pas encore grandir, signale l’analyste.

« Pour atteindre sa pleine maturité, MCP doit également prendre en charge l’identité native de l’agent plutôt que l’identité déléguée de l’utilisateur humain. L’agent n’a pas forcément besoin de disposer des mêmes privilèges que son donneur d’ordre », déclare-t-il. « Les agents doivent essentiellement pouvoir se présenter à MCP avec une partie des autorisations de leur utilisateur, puis recevoir des réponses en conséquence ».

Pour approfondir sur IA appliquée, GenAI, IA infusée