Ce que le noyau sans état et l’autorisation gérée de MCP signifient pour les équipes d’intégration
La gouvernance de la Linux Foundation, le transport HTTP sans état et l’autorisation gérée par un fournisseur d’identité rendent MCP viable pour l’intégration enterprise. Voici ce qui a changé.
Le protocole Model Context Protocol standardise la manière dont les agents d’IA se connectent aux systèmes qui les entourent, de façon similaire à la manière dont les API ont autrefois standardisé les interactions entre applications. Pour les spécialistes de l’intégration et des opérations informatiques, il a fait l’objet d’une surveillance à distance pendant deux ans : prometteur, en plein essor, mais ressemblant davantage à un outil de développement qu’à quelque chose que un comité d’évaluation architecturale serait prêt à approuver. Cette distance s’est réduite. En huit mois, le MCP a franchi trois étapes qui rappellent les débuts de la gestion des API vers 2010, se reproduisant ainsi pour les agents d’IA.
Trois changements en huit mois
Gouvernance neutre. Anthropic a transféré MCP à la Agentic AI Foundation en décembre 2025. Il s’agit d’un fonds géré au sein de la Linux Foundation, créé par Anthropic, Block et OpenAI, avec le soutien de Google, Microsoft, AWS, Cloudflare et Bloomberg. Grâce à cela, MCP n’est plus soumis aux plans d’un seul fournisseur et bénéficie d’une gestion impartiale similaire à celle qui a permis le développement de Kubernetes et Node.js.
Autorisation centralisée. Le 18 juin 2026, l’extension Enterprise-Managed Authorization (EMA) est devenue stable. Elle remplace les écrans d’approbation par serveur par un système piloté par le fournisseur d’identité, et Anthropic, Microsoft et Okta ont été parmi les premiers à l’adopter.
Un noyau sans état. La version du 28 juillet 2026 représente la plus importante révision des spécifications depuis l’apparition du protocole ; elle remplace un design basé sur des sessions et doté d’un état par un modèle sans état fonctionnant uniquement avec HTTP.
Ces changements ne sont pas purement esthétiques. Chacun élimine un obstacle spécifique qui empêchait jusqu’alors MCP d’être utilisé sérieusement en production, et ils sont particulièrement importants pour ceux dont le métier consiste à relier des systèmes plutôt qu’à créer des démos d’IA.
Une définition rapide
MCP est une norme ouverte définissant la manière dont une application d’IA, par exemple un agent basé sur un LLM, trouve et invoque des outils externes, lit des ressources extérieures et échange du contexte avec des systèmes autres que le modèle lui-même. Une interface unique remplace ainsi les intégrations personnalisées nécessaires pour chaque source de données.
Une comparaison approximative : MCP permet aux connexions entre l’IA et les systèmes ce que REST et OpenAPI ont fait entre les applications. Les systèmes intégrés restent tels qu’ils sont. Ce qui est standardisé, c’est le contrat entre le client IA et ce que le serveur MCP expose, qu’il s’agisse d’un outil de gestion des tickets, d’une CMDB, d’une plateforme de surveillance ou d’une base de données interne.
Changement 1 : plus de sessions
Pendant ses deux premières années, MCP via HTTP fonctionnait comme de nombreux protocoles en temps réel. Un client se connectait, effectuait une séquence d’initialisation et recevait un ID de session que chaque requête ultérieure devait inclure. La session liait le client à l’instance de serveur qui l’avait créée. Toute personne ayant mis un service WebSocket derrière un équilibreur de charge connaît les difficultés associées. L’extension horizontale nécessitait un routage persistant, un stockage de sessions partagé ou un gateway capable d’analyser le trafic pour identifier l’instance unique gérant la connexion.
La spécification du 28-07-2026 élimine tout cela. Il n’y a plus de procédure d’initialisation ni d’échange d’informations d’initialisation, et pas non plus d’en-tête Mcp-Session-Id. Chaque requête apporte désormais sa propre version de protocole, son identité de client ainsi que ses capacités. Par conséquent, n’importe quelle instance serveur peut répondre à n’importe quelle requête, de sorte que les sessions persistantes et les bases de données de sessions partagées ne sont plus exigées par le protocole. Les clusters sans serveur, multi-instances et le routage edge fonctionnent alors de la même manière que les API HTTP ordinaires, car structurellement c’est ce à quoi MCP est devenu.
Sans sessions protocolaires, les applications ne deviennent pas sans état. Lorsqu’un serveur doit réellement mémoriser quelque chose entre plusieurs appels, comme une exportation en cours ou une tâche de correction longue, il suit l’ancienne pratique REST : il crée un identifiant explicite que le client lui renvoie ensuite en tant qu’argument normal. Les ingénieurs familiers avec les points d’accès de pagination et d’état des tâches le reconnaîtront ; il s’agit d’un choix réfléchi adapté aux balanceurs de charge, et non d’une correction de dernière minute.
La même mise à jour a renforcé la sécurité autour de la nouvelle forme. Les clients doivent valider l’émetteur dans les réponses d’autorisation, ce qui empêche le vol de session par redirection dans les configurations multi-serveurs. Ils doivent également indiquer quel serveur est destiné à un jeton, ce qui comble une faille de délégation que les équipes de sécurité avaient identifiée comme un risque réel dans les déploiements multi-locataires. De plus, MCP dispose désormais pour la première fois d’une politique officielle de dépréciation, de sorte que les changements perturbateurs suivent un véritable cycle de vie et ne sont pas supprimés de manière ad hoc.
Changement 2 : accès géré par le fournisseur d’identité
Le deuxième changement concerne moins le transport que plutôt les difficultés quotidiennes liées au déploiement d’agents au sein d’une entreprise. Avec l’approche d’autorisation de première génération, chaque employé devait effectuer personnellement une étape de consentement OAuth pour chaque serveur MCP utilisé par son client d’IA. Avec une centaine de personnes et six ou sept outils internes, l’intégration des nouveaux employés cesse de fonctionner efficacement. Les équipes de sécurité perdent également une vue d’ensemble de ceux qui sont connectés à quoi, et il n’existe pas de méthode simple pour restreindre l’accès lorsque quelqu’un change de poste ou quitte l’entreprise.
EMA transfère la décision d’autorisation au fournisseur d’identité de l’entreprise. Un administrateur décide une fois, dans le IdP, quels serveurs MCP un groupe de collaborateurs peut utiliser. Par la suite, l’accès s’active automatiquement la première fois que quelqu’un se connecte via un client pris en charge, sans demande de consentement ni configuration supplémentaire.
Okta a été le premier des fournisseurs d’identité à le prendre en charge, en s’appuyant sur son produit Cross App Access. Cette extension est basée sur l’Identity Assertion JWT Authorization Grant, une spécification ouverte de l’IETF et non propriétaire d’Anthropic. Anthropic l’a intégrée à Claude, Claude Code et Cowork via une couche MCP partagée, tandis que Microsoft a intégré ce support directement dans Visual Studio Code. Parmi les serveurs qui le prennent déjà en charge figurent Asana, Atlassian, Canva, Figma, Granola, Linear et Supabase, et la liste continue de s’allonger.
L’identifiant fournisseur termine son rôle une fois qu’il a émis l’autorisation. Il n’apparaît nulle part dans la requête elle-même, ce qui est un avantage en matière de sécurité : l’IdP ne proxye pas chaque flux de données entre l’intelligence artificielle et le système, mais décide uniquement qui obtient des identifiants. Comme l’accès est centralisé, la révocation l’est également. Désactiver le compte d’une personne qui quitte l’entreprise coupe simultanément tous les serveurs connectés à EMA, évitant ainsi de devoir annuler et révoquer manuellement sept intégrations distinctes.
Le single sign-on pour l’ensemble des solutions SaaS d’une entreprise fonctionne de la même manière, ce qui lui confère un aspect familier, et c’est intentionnel. Les équipes de sécurité n’ont pas besoin d’inventer un nouveau modèle de gouvernance pour ces agents ; elles peuvent simplement étendre celui qui est déjà en place.
Conséquences pour les équipes utilisant des solutions personnalisées
De nombreuses équipes d’intégration et de plateforme n’ont pas attendu que MCP se développe. Lorsqu’on leur demandait de permettre à un assistant IA interne de lire des données Jira, d’envoyer des messages sur Slack ou de consulter un outil de surveillance, elles écrivaient leur propre code d’intermédiation : un wrapper sur mesure pour chaque API, un flux d’autorisation personnalisé et une gestion manuelle des sessions, car aucun outil standard n’existait. Cela fonctionnait. Mais chaque nouvel outil devenait une solution unique, l’autorisation était réinventée pour chaque système, et cette approche échouait dès qu’une deuxième équipe souhaitait la même fonctionnalité.
La maturité nouvellement acquise atténue ces problèmes de trois manières :
- Moins de code d’intermédiation développé manuellement par intégration. Un transport stable et sans état basé sur HTTP pur permet aux équipes d’arrêter de développer leur propre gestion des connexions et de traiter un serveur MCP comme n’importe quelle API REST derrière une passerelle API.
Le travail d’intégration lui-même ne disparaît pas. La traduction des données entre un schéma de gestion des tickets et un schéma de surveillance, ainsi que la transformation au niveau des champs, le dédoublonnage et les logiques métier qui s’étendent sur plusieurs systèmes, exigent toujours des compétences d’ingénierie réelles, quel que soit le protocole utilisé pour transmettre les requêtes. Ce qui diminue, c’est l’infrastructure associée : le transport des données, la gestion des sessions et le flux d’authentification. Cela réduit considérablement les efforts non différenciés, mais pas l’ensemble du travail.
Une histoire ancienne avec une nouvelle étiquette
En mettant de côté la dimension liée à l’IA, cette situation nous est familière. Depuis une vingtaine d’années, les entreprises développent ou achètent des plateformes d’intégration pour gérer les connexions API-à-API : une authentification standardisée, un mappage et une transformation des données gérés de manière centralisée, un volume d’opérations qui augmente sans nécessiter de code personnalisé pour chaque nouvelle paire de systèmes, ainsi qu’un endroit unique où les équipes de sécurité peuvent voir et contrôler ce qui est connecté.
MCP semble suivre la même approche disciplinée pour les connexions entre agents IA, mais de manière plus rapide. Un noyau sans état fonctionnant sur HTTP classique permet à un serveur MCP d’avoir l’aspect et la capacité de scalage de n’importe quel service backend. L’autorisation gérée par le IdP rend l’octroi et le contrôle d’accès aux outils IA une tâche courante dans les systèmes de gestion des accès d’entreprise. De plus, une gouvernance neutre sous l’égide de la Linux Foundation fait que l’adoption du protocole ressemble à un choix en faveur de Kubernetes, et non au plan stratégique d’une seule entreprise.
Pour les équipes d’intégration, la leçon n’est pas que les agents nécessitent un nouveau guide opérationnel. Les méthodes déjà utilisées pour relier des systèmes de manière fiable, sécurisée et à grande échelle s’appliquent désormais directement aux agents également. La couche de protocole s’intègre dans l’infrastructure que les gens comprennent déjà, et ce qui distingue les équipes se situe à un niveau supérieur : la cartographie des données, l’application des règles de gouvernance et la gestion des changements au sein des systèmes concernés, ce qui a toujours été la partie la plus difficile.