Data / IA
MCP 2026 remet les compteurs à zéro pour mieux connecter des milliards d’agents IA aux entreprises
Par Laurent Delattre, publié le 29 juillet 2026
Le Model Context Protocol vient de publier sa révision la plus importante depuis sa création. Fin des sessions, fin de la négociation initiale, durcissement de l’autorisation et politique formelle de dépréciation : la spécification 2026-07-28 transforme le standard qui relie les agents IA au système d’information en une brique d’infrastructure plus souple, plus sûre et moins coûteuse.
Un modèle de langage, seul, ne sait rien faire. Il raisonne, il rédige, mais il n’ouvre pas un ticket ServiceNow, ne lit pas une base Snowflake et ne déclenche aucun virement. Toute la valeur des agents IA tient dans leur capacité à manipuler outils et données. Encore fallait-il définir un moyen universel pour interconnecter modèles IA et données. C’est tout l’objectif du Model Context Protocol, ou MCP, introduit par Anthropic fin 2024 et devenu le standard de fait du marché.
Passé depuis sous gouvernance Linux Foundation via l’Agentic AI Foundation, MCP décrit une grammaire commune : comment un serveur expose ses outils, ses ressources et ses invites, comment un client les découvre, comment un modèle les appelle. Un connecteur écrit une fois fonctionne avec n’importe quel agent conforme.
L’adoption de ce protocole ouvert a suivi une pente rare, le genre de croissance hyperbolique comme seule l’IA en a. connu. Les mainteneurs revendiquent près d’un demi-milliard de téléchargements mensuels sur leurs seuls SDK de premier rang, les bibliothèques TypeScript et Python ayant chacune franchi le milliard cumulé. AWS, Microsoft, Google Cloud, Cloudflare, Figma ou Supabase ont bâti leurs passerelles agentiques dessus. MCP n’est plus une convention de développeurs. Le protocole est devenu une dépendance de production.
La taxe cachée des sessions MCP
Sauf que le protocole avait été conçu pour un tout autre décor : une application de bureau dialoguant avec un processus local. Ouvrir une connexion persistante et maintenir une session ne coûtait alors rien. Mais l’ère agentique a changé la donne.
Jusqu’ici, chaque serveur émettait une en-tête Mcp-Session-Id qui épinglait le client à l’instance émettrice. Pour tenir la charge, les équipes devaient déployer de l’affinité de session, un magasin d’état partagé ou une passerelle capable d’inspecter le corps JSON des requêtes pour router correctement. Au lieu de laisser l’infrastructure répartir simplement les requêtes entre serveurs, MCP obligeait à gérer l’état et le routage entre plusieurs instances. comme chaque client était lié à une session et donc souvent à une instance précise du serveur, les équipes devaient ajouter des mécanismes d’infrastructure (affinité de session, stockage d’état partagé, passerelles intelligentes) pour que le système fonctionne à grande échelle. Une complexité coûteuse en temps, en exploitation et donc forcément facturée aux utilisateurs.
Chaque requête se suffit à elle-même
La nouvelle spécification publiée le 28 juillet supprime le mécanisme. La séquence initialize/initialized disparaît, l’en-tête de session également. Version du protocole, identité et capacités du client voyagent désormais dans le champ _meta de chaque appel, et une méthode server/discover permet d’interroger les capacités du serveur à la demande. Toute requête peut atterrir sur n’importe quelle instance, derrière un simple répartiteur en tourniquet. Le déploiement sans serveur ou en périphérie redevient trivial.
Deux ajouts complètent le tableau. Les en-têtes Mcp-Method et Mcp-Name deviennent obligatoires, ce qui autorise passerelles, pare-feu applicatifs et limiteurs de débit à router et à mesurer sans ouvrir la charge utile. Les réponses de listage embarquent un ttlMs et un cacheScope calqués sur Cache-Control, et les serveurs doivent renvoyer leurs outils dans un ordre déterministe. Gain direct : les catalogues se mettent en cache et les caches d’invites restent stables, donc moins de latence et moins de jetons facturés.
Restaient les échanges initiés par le serveur. Les Multi Round-Trip Requests remplacent les flux SSE maintenus ouverts. Le serveur renvoie un résultat de type input_required, le client collecte les réponses puis rejoue l’appel initial avec l’état renvoyé. N’importe quelle instance reprend le fil.
Autrement dit, cette nouvelle version rend MCP beaucoup plus simple à faire fonctionner à grande échelle : chaque demande contient désormais tout ce qu’il faut pour être comprise, sans devoir retrouver une conversation précédente ou un serveur précis. Les requêtes peuvent donc être réparties librement entre plusieurs machines, ce qui facilite les déploiements, réduit les coûts cachés et rend les échanges plus rapides et plus fiables.
Ce que les RSSI doivent retenir
Le volet autorisation concentre six propositions. Les clients doivent valider le paramètre iss selon la RFC 9207 avant d’échanger un code, ce qui referme une classe d’attaques par confusion de serveur d’autorisation, particulièrement pertinente dans un modèle où un client dialogue avec des dizaines de serveurs. Les identifiants délivrés sont liés à l’émetteur qui les a créés. Et l’enregistrement dynamique de clients passe en dépréciation au profit des Client ID Metadata Documents.
Trois fonctions du cœur suivent le même chemin : Roots, Sampling et Logging. Le cas de Sampling mérite attention. Un serveur qui déléguait la génération au client ne détenait aucun secret et ne payait aucun jeton. En appelant directement l’API d’un fournisseur, il devient porteur de secrets, partie facturée et sous-traitant de données personnelles. La bascule n’a rien d’anodin sur le plan juridique.
Dit autrement, cette mise à jour majeure de MCP renforce au passage les contrôles de sécurité et clarifie qui a le droit de faire quoi, afin d’éviter qu’un agent se connecte au mauvais service ou utilise des autorisations mal attribuées. Elle retire aussi progressivement certaines fonctions jugées trop sensibles ou trop ambiguës : lorsqu’un serveur appelle directement un fournisseur d’IA, il ne se contente plus de relayer une demande, il porte des clés d’accès, engage des coûts et peut traiter des données personnelles, ce qui change fortement ses responsabilités.
Une gouvernance enfin lisible
L’argument le plus solide devant un comité d’architecture ne figure pourtant dans aucune fonctionnalité. MCP se dote d’un cycle de vie formel, « Actif, Déprécié puis Retiré », assorti d’une fenêtre minimale de douze mois avant tout retrait. Le transport HTTP+SSE historique bénéficie du même sursis. Les extensions deviennent par ailleurs des objets de premier plan, identifiées en DNS inversé et versionnées indépendamment. Tasks, sorti du cœur après avoir révélé ses limites en production, y rejoint MCP Apps et Enterprise Managed Authorization.
Le prix à payer existe. Tout code dépendant des sessions, toute implémentation de l’API Tasks expérimentale et tout serveur émettant des requêtes vers le client devront migrer. Les quatre SDK de premier rang, TypeScript, Python, Go et C#, sont alignés depuis le jour de publication, Rust suivant en bêta.
Une nuance, enfin, pour les DSI tentés d’y voir une garantie d’exploitation. L’absence d’état au niveau protocolaire achète de la routabilité, pas du déterminisme. Deux instances accepteront la même requête sans se consulter, et répondront différemment si elles tournent des versions différentes. Quant à l’état applicatif, paniers, jetons de tâche ou clés d’idempotence, il ne disparaît pas. Le protocole a simplement cessé de le gérer à votre place.
À LIRE AUSSI :
À LIRE AUSSI :
À LIRE AUSSI :
