Nouvelle spécification MCP : le pari du stateless en entreprise
- Abdoul Diallo
- 2 hours ago
- 4 min read
MCP, ou Model Context Protocol, est le standard ouvert qui permet à un modèle de langage d'appeler des outils externes : une base de données, un fichier, une API métier. Sa version de juillet 2026 change une donnée structurelle : le protocole devient stateless, c'est-à-dire qu'il ne conserve plus d'état de session entre deux échanges. Au 2 août 2026, cette évolution est documentée par Ars Technica dans un article du 25 juillet 2026, et intégrée à la spécification publique disponible sur le dépôt GitHub officiel du projet.
Ce que MCP change dans l'intégration IA
Le rôle du protocole entre modèles et outils externes
MCP standardise la façon dont un modèle IA découvre et invoque des outils tiers : lister les fonctions disponibles, envoyer des paramètres, recevoir un résultat structuré. Avant son existence, chaque intégration nécessitait un connecteur sur mesure entre un modèle et un système d'information. Le protocole évite de refaire ce travail à chaque nouvel outil ou à chaque nouveau modèle.
Pourquoi la version stateful bloquait la montée en charge
La version précédente de MCP maintenait une connexion persistante et un état de session propre à chaque serveur, selon Ars Technica (25 juillet 2026). Concrètement, un client restait attaché au serveur qui avait initié l'échange. Impossible de router une requête vers une autre instance sans perdre le contexte de la session. Pour une entreprise qui veut faire tourner plusieurs répliques d'un serveur MCP derrière un répartiteur de charge, cette contrainte posait un problème d'architecture classique, déjà résolu depuis longtemps pour les API web traditionnelles.
Le tournant stateless : ce qui est vraiment nouveau
Du protocole bidirectionnel au modèle requête/réponse
Le changement central : MCP abandonne son modèle de connexion bidirectionnelle persistante au profit d'un échange requête/réponse classique, plus proche de ce que fait une API REST. Chaque appel porte désormais l'information nécessaire pour être traité indépendamment des précédents. Un serveur n'a plus besoin de se souvenir de qui a demandé quoi cinq minutes plus tôt.
Les autres ajouts : routage par en-tête, requêtes multi-aller-retour, cache des listes
La mise à jour de juillet 2026 introduit un routage par en-tête HTTP, qui permet de diriger une requête vers l'instance de serveur appropriée sans dépendre d'une session ouverte. Elle ajoute aussi la prise en charge de requêtes multi-aller-retour, utile quand un outil a besoin de plusieurs échanges pour compléter une tâche, et un cache pour les listes d'outils et de ressources, qui évite de redemander la même liste à chaque appel.
Le durcissement de l'autorisation et la politique de non-suppression des fonctionnalités
Deux ajouts moins visibles mais structurants pour une adoption en entreprise. D'abord, un renforcement des mécanismes d'autorisation, qui touche directement la question de sécurité déjà soulevée par les travaux sur les risques des agents IA. Ensuite, une politique explicite de non-suppression des fonctionnalités existantes : les mainteneurs du protocole s'engagent à ne pas retirer de capacités déjà publiées, ce qui rassure les équipes qui ont investi dans une intégration.
Pourquoi ce virage vise l'échelle entreprise
Fiabilité et répartition de charge entre instances serveur
Le stateless permet de répartir les requêtes sur plusieurs instances d'un même serveur MCP sans coordination complexe entre elles. C'est le principe qui a permis aux architectures web de scaler horizontalement depuis des années : ajouter des instances plutôt que grossir une seule machine. Pour une direction technique qui prévoit d'exposer des dizaines d'outils internes via MCP, cette capacité conditionne la fiabilité en cas de pic de charge.
Ce que gagnent les équipes qui déploient des serveurs MCP
Concrètement, une équipe qui opère un serveur MCP en production gagne en résilience : une instance qui tombe n'emporte plus l'état des sessions en cours. Elle gagne aussi en simplicité opérationnelle, puisque le déploiement se rapproche des pratiques déjà maîtrisées pour les API HTTP classiques, avec les outils de supervision et d'équilibrage de charge existants.
Les limites et ce que la spec ne règle pas
Le stateless lève un frein technique précis, pas tous les obstacles à l'adoption. Trois points méritent d'être vérifiés avant de miser sur cette nouvelle version.
Migration des serveurs existants et compatibilité
Les serveurs MCP déployés sur la version stateful ne basculent pas automatiquement. La migration implique de revoir la gestion de session côté serveur et, potentiellement, côté client. Pour une entreprise qui a déjà investi dans une intégration MCP en 2025, cet effort de migration a un coût réel, qu'il faut chiffrer avant d'annoncer un passage en production sur la nouvelle spec.
Maturité des SDK Tier 1 et zones encore mouvantes
La qualité et la maturité des kits de développement (SDK) qui implémentent la nouvelle spécification varient selon les langages. Une vérification s'impose avant tout engagement : le SDK utilisé par l'équipe supporte-t-il réellement le mode stateless, ou reste-t-il calé sur l'ancien modèle. Le protocole reste jeune, sa politique de non-suppression rassure sur la stabilité de l'existant, mais elle ne garantit pas que toutes les couches de l'écosystème aient rattrapé leur retard au même rythme.
Le sujet de la sécurité des agents qui s'appuient sur ces intégrations reste distinct de la question du scaling. Le durcissement de l'autorisation dans la nouvelle spec aide, mais ne remplace pas un audit des permissions accordées à chaque outil exposé.
Par où commencer
Auditer les serveurs MCP déjà en production dans l'entreprise et lister ceux qui dépendent du modèle stateful pour identifier l'effort de migration réel.
Tester la nouvelle spécification sur un serveur non critique, avec le SDK correspondant au langage utilisé, avant d'envisager un déploiement multi-instances.
Revoir les permissions et l'autorisation accordées à chaque outil exposé via MCP, en s'appuyant sur les recommandations déjà documentées sur la sécurisation des agents IA.
MCP reste un standard ouvert, porté par une communauté et non par un seul éditeur. Le passage au stateless répond à un problème d'architecture concret : la répartition de charge entre serveurs. Il ne dispense pas d'un travail de migration ni d'une vérification de la maturité des outils avant tout déploiement à l'échelle d'une entreprise.
Sources
With a stateless makeover, new MCP spec targets enterprise scale — Ars Technica, Ars Technica, 25/07/2026
modelcontextprotocol/modelcontextprotocol — Model Context Protocol (dépôt officiel), GitHub, 25/07/2026
Model Context Protocol — Documentation officielle — Model Context Protocol, modelcontextprotocol.io, 25/07/2026
Cet article a été rédigé et illustré par un système d'intelligence artificielle à partir des sources citées ci-dessus, puis publié automatiquement, sans relecture humaine préalable. Si vous relevez une erreur factuelle, merci de nous la signaler.
Comments