Publié le 21 septembre 2026 à 11:00 · Publication originale
Chaque outil peut être exposé par un serveur MCP.
Tant que quelques utilisateurs expérimentent, l'architecture paraît simple.
À 50.000 employés, un problème apparaît.
Des milliers de requêtes arrivent simultanément. L'entreprise veut répartir le trafic entre plusieurs copies du même serveur. Mais si chaque connexion conserve sa propre session, la requête suivante doit retrouver la bonne machine ou son état doit être partagé ailleurs.
Le 28 juillet 2026, la nouvelle spécification MCP a précisément supprimé cette contrainte.
Le cœur du protocole devient sans état.
Chaque requête transporte désormais les informations nécessaires à son traitement. Elle peut arriver sur n'importe quelle instance disponible derrière un répartiteur de charge ordinaire.
C'est une transformation discrète mais importante.
MCP avait été conçu pour permettre à une IA de découvrir et utiliser des outils. Il commence à acquérir des propriétés attendues d'une infrastructure distribuée.
Les noms des méthodes et outils peuvent maintenant voyager dans les en-têtes HTTP. Une passerelle peut donc router, limiter ou contrôler certains appels sans devoir analyser le contenu JSON de chaque requête.
Les catalogues d'outils deviennent également mémorisables en cache. Un client n'a plus besoin de redemander constamment au serveur la liste de ses capacités.
L'autorisation évolue elle aussi. MCP se rapproche des mécanismes OAuth et OpenID Connect déjà utilisés dans les systèmes d'identité des entreprises.
Un protocole né pour connecter un modèle à quelques outils rencontre ainsi les mêmes problèmes que le Web avant lui: équilibrage de charge, cache, identité, autorisation, compatibilité et dépréciation.
Le passage de l'agent expérimental à l'agent industriel se joue aussi dans ces détails invisibles.
ULTRA®
La disparition des sessions produit un effet très concret: un serveur MCP peut devenir horizontalement interchangeable.
Dans la spécification 2026-07-28, chaque requête indique notamment version du protocole et identité du client. Les en-têtes "Mcp-Method" et "Mcp-Name" exposent méthode et outil avant même la lecture du corps.
Un WAF ou une passerelle API peut donc appliquer une règle telle que: cet utilisateur peut appeler "search", mais jamais "delete_customer".
Les réponses de découverte reçoivent aussi "ttlMs" et "cacheScope": le client sait combien de temps conserver un catalogue d'outils sans le redemander.
Plus surprenant, l'autorisation d'entreprise possède désormais une extension dédiée, EMA. L'accès aux serveurs MCP peut être provisionné centralement par le fournisseur d'identité plutôt que négocié application par application.
Le véritable passage à l'échelle d'un agent dépend donc aussi d'une question très ancienne: qui peut appeler quelle fonction, pendant combien de temps et comment le réseau peut-il le vérifier?