.png)
Plus simple à déployer, plus facile à gouverner et mieux adapté aux entreprises : MCP commence à ressembler à une véritable infrastructure de production.
Nous suivre
Imaginez deux collaborateurs qui demandent au même agent de rechercher une information dans leur CRM.
Jusqu’ici, le serveur MCP pouvait avoir besoin de se souvenir de la connexion de chacun. Une requête commencée sur un serveur devait parfois continuer sur ce même serveur. Si l’entreprise ajoutait de nouvelles instances pour absorber la charge, elle devait aussi organiser le partage des sessions entre elles.
Depuis la mise à jour du 28 juillet 2026, la logique change : chaque requête peut transporter les informations nécessaires à son traitement. Elle peut être envoyée vers n’importe quelle instance disponible.
Ce changement paraît discret. Pourtant, il rapproche MCP du fonctionnement normal du Web et du cloud. Il devient plus facile à répartir, à superviser et à intégrer aux systèmes d’identité d’une entreprise.
La mise à jour ne rend pas MCP plus spectaculaire en démonstration. Elle le rend beaucoup plus crédible en production.
MCP — Model Context Protocol — standardise la manière dont une application d’IA se connecte à des outils et à des sources de données.
Un agent peut ainsi rechercher un document, consulter une base de données, créer un ticket ou déclencher un workflow sans nécessiter une intégration différente pour chaque assistant d’IA.
C’est ce qui a accéléré son adoption. Mais standardiser l’appel d’un outil ne suffit pas. Une entreprise doit aussi pouvoir répondre à des questions moins visibles :
La nouvelle spécification s’attaque à cette seconde moitié du problème : non plus seulement connecter les agents, mais exploiter leurs connexions à grande échelle.
Les premières versions de MCP reposaient davantage sur des sessions. Le client ouvrait une relation avec un serveur, puis le serveur conservait certaines informations pendant la durée de cette relation.
Pour une utilisation locale ou une démonstration, ce fonctionnement était naturel. Dans une infrastructure distribuée, il créait plusieurs contraintes.
Le répartiteur de charge devait souvent renvoyer l’utilisateur vers la même instance. Les serveurs pouvaient avoir besoin d’une mémoire commune pour partager les sessions. Les connexions longues étaient plus difficiles à déplacer, à redémarrer ou à déployer dans plusieurs régions.
Autrement dit, l’architecture ressemblait parfois à ceci :
Utilisateur
↓
Répartiteur avec affinité
↓
Serveur associé à la session
↓
Mémoire partagée
Plus l’usage augmentait, plus cette mémoire invisible devenait une contrainte pour toute la plateforme.
Le cœur du nouveau MCP devient stateless, ou « sans état » au niveau du protocole.
Cela ne signifie pas que l’application n’a plus de mémoire. Un panier, une recherche en cours ou un workflow de validation ont toujours besoin d’un état. La différence est que cet état n’est plus caché dans la connexion.
Lorsqu’une application doit conserver un contexte, elle utilise une référence explicite — par exemple un identifiant de panier ou de tâche — que l’agent transmet lors de l’appel suivant.
Cette évolution produit un effet très concret : deux requêtes successives peuvent être traitées par deux instances différentes.
Utilisateur
↓
Répartiteur standard
├── Serveur A
├── Serveur B
└── Serveur C
Pour une entreprise, cela simplifie plusieurs opérations :
La mémoire n’a pas disparu. Elle se trouve simplement au bon endroit : dans l’application, sous une forme explicite, plutôt que dans le transport.
Le passage à un protocole sans état soulevait une question importante : comment un serveur peut-il demander une information supplémentaire au milieu d’une action ?
Prenons un exemple simple. Un agent s’apprête à supprimer un projet cloud. Le serveur MCP ne doit pas exécuter immédiatement l’opération. Il veut d’abord obtenir l’accord de l’utilisateur.
Le nouveau mécanisme MRTR — Multi Round-Trip Requests — permet cette séquence :
MRTR permet donc d’intégrer du Human-in-the-Loop sans maintenir une connexion ouverte pendant toute l’attente.
Mais MRTR ne se limite pas aux humains. L’information complémentaire peut également venir du client, d’un modèle ou d’un autre système. Il faut le voir comme un mécanisme général de pause et de reprise, dont la validation humaine est l’un des usages les plus importants.
Pour les opérations qui durent plusieurs minutes, MCP introduit aussi une extension dédiée aux tâches longues. Le serveur peut rendre une référence de tâche, laisser le travail continuer en arrière-plan, puis permettre au client d’en consulter l’avancement. Là encore, la durée du travail n’est plus confondue avec celle de la connexion.
Un autre changement concerne les passerelles de sécurité, les répartiteurs de charge et les outils de supervision.
Les requêtes MCP indiquent désormais plus clairement le type d’opération et le nom de l’outil appelé. Une passerelle peut reconnaître une recherche, une création de facture ou une action de suppression sans devoir comprendre toute la conversation de l’agent.
Une entreprise peut alors appliquer des règles comme :
MCP s’intègre ainsi plus naturellement aux composants déjà utilisés par les équipes plateforme et sécurité.
La mise à jour améliore également le cache. Les listes d’outils et de ressources peuvent indiquer combien de temps elles restent valides et si elles peuvent être partagées. À grande échelle, cela évite de redemander constamment les mêmes catalogues et réduit le trafic inutile.
Le changement le plus directement « corporate » vient d’EMA — Enterprise-Managed Authorization.
EMA a été stabilisée peu avant la mise à jour de juillet. Ce n’est pas une fonction obligatoire du cœur stateless, mais une extension officielle qui s’intègre au nouveau cadre d’extensions de MCP.
Sans EMA, chaque collaborateur peut être amené à autoriser séparément chaque serveur MCP. Cela fonctionne pour un utilisateur individuel. Dans une organisation qui déploie des dizaines de serveurs auprès de milliers d’employés, l’expérience devient vite difficile à administrer.
EMA place le fournisseur d’identité de l’entreprise — son système de SSO — au centre du processus.
L’équipe IT peut alors :
Pour l’utilisateur, l’expérience devient plus simple : il se connecte avec son identité professionnelle et retrouve les outils autorisés pour son rôle, sans répéter une procédure différente pour chaque serveur.
Pour l’équipe sécurité, MCP ne forme plus une collection de connexions individuelles difficiles à suivre. Il rejoint le plan de gouvernance existant de l’entreprise.
La nouvelle spécification renforce aussi les mécanismes d’autorisation de base. Elle vérifie mieux l’identité du système qui délivre une autorisation, empêche de réutiliser des identifiants auprès du mauvais fournisseur et encourage des identités de clients plus stables et vérifiables.
Ces changements sont peu visibles pour l’utilisateur. Ils réduisent pourtant des ambiguïtés dangereuses dans les environnements qui combinent plusieurs fournisseurs d’identité, applications et organisations.
Les bénéfices deviennent plus clairs lorsqu’on compare les deux modèles :
La « révolution » est volontairement peu spectaculaire. MCP devient compatible avec les habitudes d’une plateforme moderne : répartition de charge, montée en capacité, contrôle d’accès centralisé, cache, supervision et déploiements progressifs.
Un standard devient mature lorsque son infrastructure cesse d’être exceptionnelle.
Un protocole plus simple à exploiter n’est pas automatiquement un protocole sans risque.
La mise à jour ne supprime pas :
Elle offre de meilleurs points de contrôle : une identité centralisée, des politiques plus lisibles, des opérations plus faciles à tracer et des validations humaines plus naturelles.
Les entreprises doivent toujours appliquer le principe du moindre privilège, vérifier les arguments envoyés aux outils, demander une confirmation pour les actions sensibles et surveiller les séquences d’actions des agents.
La nouvelle spécification améliore l’infrastructure de sécurité. Elle ne remplace pas les garde-fous applicatifs.
MCP avait déjà standardisé la façon dont un agent découvre et appelle ses outils.
La mise à jour du 28 juillet s’attaque à l’étape suivante : faire fonctionner ces connexions de manière fiable, observable et gouvernable dans une organisation.
Le cœur sans état facilite la répartition du trafic. MRTR préserve l’interactivité et le Human-in-the-Loop. Le cache réduit les échanges inutiles. EMA rattache les serveurs MCP à l’identité et aux politiques de l’entreprise.
Ce n’est pas la disparition de l’état. C’est l’état au bon endroit, l’identité au bon niveau et le contrôle au bon moment.
C’est souvent ainsi qu’une technologie passe de la démonstration à la plateforme : non pas en ajoutant une capacité spectaculaire, mais en retirant les contraintes qui empêchaient son exploitation normale.
Article par B.ERRAJI, consultant data OSSIA - SONATE
🚀 Pour devenir AI Engineer, maîtrisez : Software Engineering, System Design, Machine Learning et LLM Engineering. Découvrez sa roadmap complète : https://www.dataunboxed.io/blog/roadmap-to-ai-engineering
Chaque fin de mois retrouvez une sélection de l'info du monde de l'IT et de la tech !
