Anthropic a introduit le Model Context Protocol le 25 novembre 2024 comme standard ouvert pour connecter les agents IA aux outils et sources de données externes. Il répondait à ce que les ingénieurs appellent le problème M-fois-N : l’explosion combinatoire de la connexion de M modèles d’IA différents avec N outils différents, chacun nécessitant du code d’intégration personnalisé. MCP a réduit cela à : implémenter le protocole client une fois, implémenter le protocole serveur une fois, et tout se connecte.
Le protocole a gagné en traction rapidement. OpenAI a adopté MCP dans son Agents SDK, son Responses API et son application de bureau ChatGPT en mars 2025. Google DeepMind a confirmé le support Gemini en avril 2025. Microsoft a annoncé l’intégration de MCP pour Windows 11, Azure et Foundry lors de Build 2025. En décembre 2025, Anthropic a fait don de MCP à la nouvelle Agentic AI Foundation sous la Linux Foundation, cofondée avec OpenAI et Block, avec le soutien d’AWS, Google, Microsoft, Cloudflare et Bloomberg. Le protocole avait atteint 97 millions de téléchargements mensuels du SDK et plus de 10 000 serveurs actifs.
Mais derrière les chiffres d’adoption, la spécification elle-même a subi une évolution significative. Quatre versions ont été publiées en un peu plus d’un an : la version initiale (2024-11-05), une refonte majeure du transport et de l’authentification (2025-03-26), un passage de raffinement (2025-06-18), et une version anniversaire (2025-11-25). La couche de transport a changé. L’authentification a été standardisée. L’une des trois primitives fondamentales a glissé vers l’inutilité pratique. Et un nouveau défi — la surcharge de la fenêtre de contexte — a émergé lorsque les équipes ont poussé MCP en production à grande échelle.
Ce ne sont pas des mises à jour cosmétiques. Elles reflètent les leçons difficiles sur la façon dont les agents IA utilisent réellement les protocoles en production et ont des implications directes pour quiconque construit ou consomme des serveurs MCP aujourd’hui.
La conception originale : trois primitives
MCP a été lancé avec trois primitives fondamentales, chacune conçue pour un modèle d’interaction différent :
Tools sont des fonctions contrôlées par le modèle que l’agent peut invoquer. Créer un ticket, envoyer un e-mail, interroger une base de données. Chaque outil a un nom, une description et un schéma de paramètres. Le LLM lit les descriptions des outils et décide quand les appeler. C’est la primitive active et agentique — celle qui permet aux systèmes d’IA d’agir dans le monde.
Resources sont des sources de données contrôlées par l’application. Documents, enregistrements, fichiers de configuration. Contrairement aux outils, c’est l’application qui décide quand récupérer les ressources et les transmettre comme contexte au modèle. Resources a été conçu comme un mécanisme navigable, en lecture seule, pour exposer des informations sans nécessiter d’appels de fonctions.
Prompts sont des modèles d’instructions prédéfinis que les serveurs MCP exposent pour structurer le comportement de l’agent pour des tâches spécifiques. Ils standardisent la façon dont les modèles abordent les opérations courantes et assurent la cohérence entre les équipes utilisant le même serveur.
Le transport initial utilisait HTTP avec Server-Sent Events (SSE) pour le streaming serveur-vers-client. L’authentification était laissée aux implémentations individuelles — généralement des jetons API stockés dans des variables d’environnement.
Virage 1 : la primitive Resources que les développeurs ont contournée
La primitive Resources était conceptuellement solide. Au lieu d’encapsuler chaque accès aux données dans un appel d’outil, les agents pouvaient découvrir et lire des ressources comme des fichiers dans un système de fichiers. La spécification traçait une ligne architecturale claire : les outils sont contrôlés par le modèle (le LLM décide quand les invoquer), tandis que les ressources sont contrôlées par l’application (l’application hôte décide quand les récupérer).
En pratique, la distinction s’est avérée moins utile que prévu. Une requête de données — « obtenir l’enregistrement client pour l’ID 12345 » — fonctionne de manière identique en tant qu’appel d’outil avec des paramètres. La primitive Tools est suffisamment flexible pour gérer à la fois les actions (créer, mettre à jour, supprimer) et les requêtes (lire, rechercher, lister). Tout acheminer via les outils donne au LLM une interface unique et cohérente pour interagir avec les systèmes externes.
Cela est visible dans l’écosystème des serveurs MCP. Examinez les implémentations communautaires, les services cloud et les projets open source : les conceptions centrées sur les outils dominent. Resources existe dans la spécification et est supporté par les SDK conformes, mais la communauté a largement convergé vers les outils comme primitive universelle.
Le schéma est familier de l’histoire des protocoles. Les spécifications initiales ratissent large — plusieurs primitives couvrant différents modèles d’interaction théoriques. La pratique simplifie. La communauté découvre quelles abstractions justifient leur poids en production et lesquelles ajoutent de la surface sans valeur proportionnelle.
Resources n’est pas déprécié. Il reste dans chaque version de la spécification jusqu’à 2025-11-25 et est documenté avec un support SDK complet. Mais son inutilité pratique est un signal important pour les développeurs : quand vous concevez des serveurs MCP, investissez dans les outils.
Virage 2 : Streamable HTTP remplace SSE
Le transport original utilisait Server-Sent Events — un protocole de streaming unidirectionnel nécessitant que le serveur maintienne une connexion persistante pour pousser les mises à jour vers le client. Cela fonctionnait pour les agents exécutés localement mais créait de sérieux problèmes à grande échelle.
Pourquoi SSE a échoué en production
SSE nécessite des connexions persistantes. Dans les environnements serverless — AWS Lambda, Cloudflare Workers, Vercel Functions — maintenir des connexions persistantes est soit impossible, soit d’un coût prohibitif. Les organisations voulant déployer des serveurs MCP comme fonctions serverless étaient contraintes à des contournements ou ne pouvaient tout simplement pas utiliser MCP.
Même dans les environnements serveur traditionnels, les connexions persistantes créent une charge opérationnelle : le pooling de connexions, la gestion des délais d’expiration, la logique de reconnexion et l’équilibrage de charge deviennent tous plus difficiles quand les connexions doivent rester actives indéfiniment. La feuille de route MCP 2026 reconnaît explicitement cela, notant que l’exécution de streamable HTTP à grande échelle a révélé des lacunes où les sessions avec état entrent en conflit avec les équilibreurs de charge et la mise à l’échelle horizontale nécessite des contournements.
Ce qui a changé
La version de spécification 2025-03-26, publiée en mars 2025, a déprécié HTTP+SSE et introduit le transport streamable HTTP. Le SDK TypeScript a ajouté le support dans la version 1.10.0 le 17 avril 2025.
Le nouveau transport prend en charge les opérations avec et sans état. Un serveur MCP simple peut traiter chaque requête indépendamment — pas de connexion persistante requise, entièrement compatible avec le déploiement serverless. Les serveurs plus complexes nécessitant le streaming ou les messages initiés par le serveur peuvent optionnellement mettre à niveau la connexion pour utiliser SSE dans le nouveau cadre de transport.
Le serveur fournit un point de terminaison HTTP unique (le point de terminaison MCP) supportant les méthodes POST et GET. La gestion des sessions est optionnelle — les serveurs peuvent attribuer un identifiant de session via l’en-tête Mcp-Session-Id, mais les serveurs sans état peuvent ignorer les sessions entièrement. Cela signifie que les serveurs MCP peuvent désormais être déployés comme :
- Fonctions serverless — Lambda, Cloud Functions, Vercel
- Services web traditionnels — Express, FastAPI, Spring Boot
- Microservices conteneurisés — Kubernetes, Cloud Run, ECS
- Fonctions edge — Cloudflare Workers, Vercel Edge
La contrainte des connexions persistantes a disparu. Les serveurs MCP peuvent être déployés partout où HTTP fonctionne — c’est-à-dire partout.
Compatibilité ascendante
Les serveurs souhaitant supporter les anciens clients peuvent héberger simultanément les points de terminaison SSE dépréciés et le nouveau point de terminaison streamable HTTP. Cela permet une migration progressive sans casser les intégrations existantes.
Impact pratique
Pour les développeurs, ce changement est immédiatement exploitable. Les nouveaux serveurs MCP devraient cibler streamable HTTP dès le premier jour. Même pour un déploiement local initial, la conception HTTP sans état permet une migration future vers des environnements serverless ou edge sans restructuration.
Pour les consommateurs évaluant des serveurs MCP, le support du transport est désormais une question de compatibilité. Les serveurs utilisant encore le transport SSE uniquement créeront des contraintes de déploiement dans les environnements cloud natifs.
Publicité
Virage 3 : OAuth 2.1 comble le vide d’authentification
La spécification MCP initiale (2024-11-05) n’avait pas de mécanisme d’authentification standardisé. Les développeurs implémentaient leurs propres schémas, passant généralement des jetons API dans des variables d’environnement. Cela était acceptable pour les serveurs exécutés localement où le développeur contrôlait l’environnement, mais inacceptable pour les déploiements cloud multi-locataires.
Le problème des identifiants partagés
Considérons une entreprise déployant un serveur MCP pour l’accès à GitHub. Avec l’ancien modèle, le serveur a besoin d’un jeton GitHub — soit un jeton d’accès personnel limité à un utilisateur, soit un jeton de compte de service avec des permissions plus larges. Aucune des deux options n’est sécurisée pour un service multi-utilisateurs.
Un jeton personnel signifie que toutes les requêtes passent par les permissions d’un seul utilisateur, sans piste d’audit distinguant qui a fait quoi. Un jeton de compte de service a généralement plus d’accès que n’importe quel utilisateur individuel ne devrait en avoir, violant le principe du moindre privilège.
Comment OAuth 2.1 résout le problème
La version de spécification 2025-03-26 a introduit un cadre d’autorisation complet basé sur OAuth 2.1. L’architecture s’aligne proprement sur les rôles OAuth établis : les serveurs MCP agissent comme des serveurs de ressources OAuth 2.1, les clients MCP agissent comme des clients OAuth 2.1, et un serveur d’autorisation séparé gère l’émission des jetons.
Le flux fonctionne comme suit :
- L’agent d’un utilisateur se connecte à un serveur MCP hébergé dans le cloud
- Le serveur répond avec HTTP 401 Unauthorized, déclenchant le flux OAuth
- Le client redirige l’utilisateur vers l’écran de consentement du serveur d’autorisation
- L’utilisateur autorise l’accès avec des portées spécifiques
- Le serveur MCP reçoit un jeton d’accès limité à cet utilisateur spécifique
- Les appels d’outils suivants utilisent le jeton de l’utilisateur, pas un identifiant partagé
La spécification impose plusieurs mesures de sécurité. Les clients doivent implémenter les Resource Indicators (RFC 8707) pour empêcher les serveurs malveillants d’obtenir des jetons d’accès destinés à d’autres services. Les serveurs doivent implémenter OAuth 2.0 Protected Resource Metadata (RFC 9728) pour indiquer l’emplacement de leurs serveurs d’autorisation. Les jetons doivent être validés pour l’audience prévue.
Chaque utilisateur contrôle son propre accès. Les jetons peuvent être limités aux permissions minimales nécessaires. Il y a une piste d’audit claire par utilisateur. Aucun identifiant partagé ne réside dans les variables d’environnement.
Pourquoi cela débloque l’adoption en entreprise
L’objection la plus courante des entreprises envers MCP était la sécurité. OAuth 2.1 élimine cette objection. Chaque utilisateur s’authentifie indépendamment via des flux que l’entreprise fait déjà confiance. Les équipes informatiques peuvent appliquer des politiques d’accès par utilisateur. Les équipes de conformité peuvent auditer les actions par utilisateur.
La version de novembre 2025 (2025-11-25) a affiné davantage le modèle d’autorisation, et la feuille de route 2026 liste une sécurité renforcée et l’authentification intégrée SSO parmi ses priorités de préparation entreprise. C’est le virage qui fait passer MCP d’un outil de développeur à une infrastructure d’entreprise.
Le défi émergent : la surcharge de la fenêtre de contexte
Alors que MCP passait en production à grande échelle, un nouveau problème a émergé que les concepteurs originaux n’avaient pas anticipé : les définitions d’outils consomment des jetons de la fenêtre de contexte.
Chaque description d’outil, schéma de paramètres et format de réponse empiète sur la mémoire de travail du modèle. Pour les agents connectés à plusieurs serveurs MCP, la surcharge se compose rapidement. Des rapports industriels indiquent que la connexion à six serveurs MCP avec 84 outils au total consomme environ 15 500 jetons au démarrage de la session — avant que l’agent ne fasse le moindre travail réel. Certaines équipes rapportent que MCP consomme 40 à 50 pour cent des fenêtres de contexte disponibles.
Le problème est suffisamment important pour que le CTO de Perplexity ait annoncé en mars 2026 que l’entreprise s’éloignait de MCP en faveur des API et CLI traditionnels, citant la surcharge de jetons et les frictions d’authentification comme problèmes fondamentaux.
La communauté répond avec plusieurs approches. Un modèle d’exécution de code a démontré des réductions de jetons allant jusqu’à 98 pour cent en laissant les agents écrire et exécuter du code plutôt que de faire des appels d’outils individuels. La divulgation progressive envoie un manifeste minimal au moment de la connexion — juste les noms des outils et des descriptions d’une ligne — chargeant les schémas complets uniquement quand c’est nécessaire. Le projet mcp2cli convertit les serveurs MCP en interfaces CLI que les agents appellent à la demande, évitant entièrement l’injection de schémas en amont.
Anthropic eux-mêmes ont publié des conseils d’ingénierie sur le modèle d’exécution de code, reconnaissant le problème et fournissant une implémentation de référence. La feuille de route 2026 liste des améliorations de l’évolutivité du transport et de la gestion des sessions qui devraient aider à adresser la surcharge de contexte au niveau du protocole.
Cela mérite attention. L’efficacité du contexte pourrait devenir aussi importante que le transport et l’authentification pour déterminer la viabilité de MCP en production.
Le schéma de maturation
L’évolution de MCP suit un schéma familier de l’histoire des protocoles. HTTP a commencé simplement, puis s’est développé pour gérer les connexions persistantes, le streaming et le multiplexage. Les API REST étaient initialement libres de forme, puis se sont consolidées autour des spécifications OpenAPI. GraphQL a été lancé avec toutes les fonctionnalités exposées, puis la communauté a convergé vers un sous-ensemble pratique.
MCP suit la même maturation. La spécification initiale a ratissé large — outils, resources, prompts, transport SSE, pas d’authentification standard. Quatre versions de spécification plus tard, la communauté a réduit la surface effective : les outils via streamable HTTP avec OAuth 2.1, gouverné par la Linux Foundation à travers la Agentic AI Foundation.
La prochaine version de spécification est provisoirement prévue pour juin 2026, avec un focus sur l’évolutivité du transport pour les déploiements équilibrés, la sémantique de communication agent-à-agent, et les fonctionnalités entreprise comme les pistes d’audit et la portabilité de configuration.
Que faire maintenant
Si vous construisez des serveurs MCP
- Construisez des outils, pas des ressources. Acheminez toute fonctionnalité — actions et requêtes de données — via la primitive Tools. C’est là que la communauté a convergé.
- Concevez pour streamable HTTP. Construisez sans état quand c’est possible, même pour un déploiement local initial. Cela garde les options de déploiement futures ouvertes.
- Implémentez OAuth 2.1 pour tout serveur accédant à des données spécifiques à l’utilisateur dans des scénarios multi-locataires. La spécification impose les RFC 8707 Resource Indicators et RFC 9728 Protected Resource Metadata.
- Minimisez les descriptions d’outils. La surcharge de la fenêtre de contexte est une vraie préoccupation en production. Gardez les descriptions concises et les schémas de paramètres serrés.
Si vous consommez des serveurs MCP
- Évaluez les catalogues d’outils. Les outils qu’un serveur expose sont ses vraies capacités. Le support des ressources est sans importance pour la plupart des cas d’usage.
- Vérifiez la compatibilité du transport. Les serveurs utilisant uniquement le transport SSE limiteront vos options de déploiement. Préférez streamable HTTP.
- Exigez OAuth pour tout serveur touchant des données sensibles. Les clés API partagées dans les variables d’environnement sont un risque de sécurité.
- Surveillez la surcharge de jetons. Les connexions MCP multiples composent la consommation de contexte. Prévoyez la surcharge des schémas dans votre planification de fenêtre de contexte.
Si vous évaluez MCP pour votre organisation
- Le protocole est prêt pour la production et soutenu par tous les principaux fournisseurs d’IA sous la gouvernance de la Linux Foundation.
- Commencez par consommer, pas par construire. Utilisez les serveurs MCP existants pour les intégrations courantes (plus de 10 000 sont disponibles) avant d’investir dans le développement de serveurs personnalisés.
- Planifiez pour le multi-locataire. Même si votre premier déploiement est mono-utilisateur, une architecture prête pour OAuth évite une mise à niveau douloureuse par la suite.
Conclusion
MCP début 2026 est un protocole plus ciblé, déployable et sécurisé que celui lancé en novembre 2024. Quatre versions de spécification ont affiné le protocole sur la base de l’expérience en production. La communauté a convergé vers les outils comme primitive principale, streamable HTTP comme transport, et OAuth 2.1 comme standard d’authentification. La primitive Resources reste dans la spécification mais est effectivement en sommeil. Et un nouveau défi — la surcharge de la fenêtre de contexte — anime la prochaine vague d’innovation du protocole.
Pour les développeurs, la voie est claire : construisez des outils, déployez partout, authentifiez correctement, et gardez vos schémas d’outils légers. Le protocole a trouvé sa forme prête pour la production, et l’écosystème mûrit rapidement.
Questions Fréquemment Posées
L’API Resources de MCP est-elle dépréciée ?
Pas officiellement. La primitive Resources reste dans chaque version de spécification jusqu’à 2025-11-25 et est supportée par les SDK conformes. Cependant, l’adoption par la communauté a été minimale — la plupart des serveurs MCP acheminent toutes les fonctionnalités via la primitive Tools. La distinction clé est que Resources est contrôlé par l’application (l’application hôte décide quand récupérer) tandis que Tools est contrôlé par le modèle (le LLM décide quand invoquer). En pratique, cette distinction ne s’est pas avérée suffisamment précieuse pour justifier une primitive séparée. Pour le développement de nouveaux serveurs MCP, investir dans Resources n’est généralement pas recommandé.
Pourquoi MCP est-il passé de SSE à streamable HTTP ?
Server-Sent Events nécessitait des connexions persistantes, rendant les serveurs MCP incompatibles avec les plateformes serverless comme AWS Lambda et Cloudflare Workers où les connexions sont de courte durée. La version de spécification 2025-03-26 a déprécié SSE et introduit streamable HTTP, qui supporte les opérations avec et sans état. Les serveurs simples traitent chaque requête indépendamment sans connexion persistante, tandis que les serveurs complexes peuvent optionnellement passer au streaming. Cela a ouvert le déploiement MCP aux fonctions serverless, à l’informatique edge, aux conteneurs et aux serveurs traditionnels.
Comment OAuth 2.1 change-t-il la sécurité de MCP pour les entreprises ?
Avant OAuth 2.1, les serveurs MCP accédant à des services spécifiques à l’utilisateur avaient besoin d’identifiants partagés — des jetons API dans les variables d’environnement. Cela empêchait le contrôle d’accès par utilisateur et créait des risques de sécurité dans les environnements multi-locataires. La version de spécification 2025-03-26 a introduit OAuth 2.1 avec les serveurs MCP agissant comme des serveurs de ressources et les clients implémentant les Resource Indicators (RFC 8707). Chaque utilisateur s’authentifie indépendamment via les flux standard de consentement OAuth. Le résultat : un cadrage des jetons par utilisateur, des pistes d’audit claires, et aucun identifiant partagé — exactement ce que les équipes de conformité en entreprise exigent.
Sources et lectures complémentaires
- Model Context Protocol — Official Specification
- MCP Streamable HTTP Transport Specification (2025-03-26)
- MCP Authorization Specification — OAuth 2.1
- Why MCP Deprecated SSE and Went with Streamable HTTP — fka.dev
- The 2026 MCP Roadmap — Model Context Protocol Blog
- Anthropic Donates MCP to the Agentic AI Foundation
- MCP Authentication and Authorization — Stack Overflow Blog
- Code Execution with MCP: Building More Efficient AI Agents — Anthropic Engineering
🔗 Intelligence Connexe
MCP : comment le Model Context Protocol devient l’USB-C de l’intégration IA
L’écosystème du codage IA en 2026 : Skills, MCPs et frameworks décryptés
L’économie des API en 2026 : couche d’infrastructure
Les bases de données vectorielles à l’ère du contexte d’un million de tokens : toujours essentielles ou technologie du passé ?
