MCP 2.0 : le protocole d’agents IA renaît en mode « stateless »

Le 31 juillet 2026, le Model Context Protocol (MCP) fait son grand retour avec sa version 2.0. Éclipsé en 2025 par les Skills d’Anthropic, ce standard qui connecte les agents IA aux outils externes se réinvente avec une architecture « stateless ». Un changement technique majeur qui ravive l’intérêt des développeurs et pourrait redéfinir la manière dont nous construisons les agents IA.

Un protocole qui renaît de ses cendres

« Tuesday was Stateless MCP day », écrit Ade Oshineye sur X le 31 juillet 2026. Ce jour-là marque le déploiement officiel de la spécification MCP 2026-07-28, rebaptisée MCP 2.0 par la communauté. Pour Simon Willison, développeur reconnu dans l’écosystème IA, c’est un tournant : « This is the most significant change to the MCP spec since it first launched, and has also served to reignite my personal interest in the protocol. »

Le Model Context Protocol, rappelons-le, est un standard ouvert créé par Anthropic en novembre 2024. Son objectif : permettre aux assistants IA comme Claude de se connecter à des outils externes (bases de données, APIs, fichiers) de manière uniforme et sécurisée. Pensez-y comme à une « prise universelle » pour agents IA — au lieu de programmer manuellement chaque connexion, MCP fournit un protocole commun que tout le monde peut utiliser.

Après un pic d’intérêt massif en 2025, MCP a connu une période de déclin. Selon Willison, le protocole a été « éclipsé par Skills » — une approche alternative lancée par Anthropic elle-même en octobre 2025. Les Skills permettent à un agent d’accéder directement à un terminal et à curl, rendant apparemment inutile un protocole standardisé. Pourquoi construire un adaptateur complexe quand un simple accès système suffit ?

Stateless : la révolution architecturale

La version 2.0 change radicalement la donne en supprimant le cœur « stateful » (avec état) du protocole. Concrètement, qu’est-ce que cela signifie ?

Dans MCP 1.0, connecter un agent à un serveur MCP nécessitait d’établir une session. Le client et le serveur effectuaient une poignée de main (« handshake ») via un échange initialize/initialized, puis chaque requête portait un identifiant de session (Mcp-Session-Id). Cette session vivait dans la mémoire du serveur — ou dans un store partagé type Redis — et le load balancer devait maintenir un routage « sticky » pour que les requêtes successives d’un même client arrivent toujours sur le même serveur.

Selon plusieurs sources techniques, cette architecture posait problème en production : autoscaling difficile (tuer un serveur tuait ses sessions), nécessité de routage complexe, impossibilité d’utiliser des load balancers classiques en round-robin. Comme l’explique un article de Digital Applied : « Your load balancer needed session affinity, autoscaling was hard, and multi-region routing was a nightmare. »

MCP 2.0 balaie tout cela. La spécification 2026-07-28, finalisée après un release candidate verrouillé le 21 mai 2026, supprime :

• Le handshake initialize/initialized
• L’en-tête Mcp-Session-Id
• Toute notion de session au niveau du protocole

Désormais, chaque requête HTTP est autonome. Elle porte toutes les informations nécessaires (version du protocole, capacités du client, métadonnées) via un champ _meta et de nouveaux en-têtes comme Mcp-Method et Mcp-Name. Résultat : n’importe quelle instance de serveur peut traiter n’importe quelle requête. Les serveurs MCP deviennent des workloads HTTP ordinaires, compatibles avec les load balancers standards et les infrastructures cloud classiques.

D’après Microsoft, qui a publié la version 2.0 de son SDK C# pour MCP le 28 juillet : « This release makes the protocol stateless by default, standardizes the HTTP surface so ordinary load balancers work without deep packet inspection. »

Une adoption immédiate par les développeurs

La réaction de la communauté ne s’est pas fait attendre. Simon Willison, le jour même du déploiement, a publié trois nouveaux projets :

• mcp-explorer : un outil pour découvrir et tester les serveurs MCP depuis le navigateur, sans installation locale
• datasette-mcp : un serveur MCP qui expose les bases de données Datasette (son projet phare) aux agents IA via des requêtes SQL en lecture seule
• Un serveur MCP non authentifié pour son blog personnel, accessible à https://datasette.simonwillison.net/-/mcp

Willison a également documenté comment configurer des serveurs MCP personnalisés dans Claude.ai et ChatGPT — deux interfaces qui supportent désormais MCP mais dont la configuration n’est pas intuitive. Pour Claude, il suffit de naviguer dans le menu « + » puis « Connectors » ; pour ChatGPT, c’est plus enfoui dans les paramètres « Apps » après avoir activé le mode développeur.

Les SDK officiels (TypeScript, Python, Go, C#) ont tous publié leur support de la spec 2026-07-28 dans la fenêtre de validation de dix semaines suivant le release candidate. Selon le blog officiel MCP, les téléchargements mensuels dépassent 400 millions pour les SDK Tier 1, avec plus d’un milliard de téléchargements cumulés pour TypeScript et Python. L’écosystème compte désormais plus de 950 serveurs MCP compatibles avec Claude Code.

MCP vs Skills : un paradoxe stratégique

La question demeure : pourquoi Anthropic maintient-il deux approches apparemment concurrentes ? D’un côté, MCP propose un protocole structuré avec des primitives standardisées (tools, resources, prompts). De l’autre, Skills mise sur la simplicité radicale : donner à l’agent un accès terminal et le laisser appeler directement curl, git ou n’importe quelle commande.

Selon plusieurs analystes, ce paradoxe révèle une incertitude stratégique. Anthropic lui-même ne sait peut-être pas encore quelle architecture dominera. MCP offre structure, sécurité et interopérabilité — idéal pour les déploiements entreprise avec gouvernance stricte. Skills offre flexibilité et rapidité — parfait pour les développeurs qui veulent juste « faire fonctionner » quelque chose rapidement.

Comme le note un article de ByoBot AI : « That is what a field looks like right before the interesting part stops being the models and starts being how the pieces fit together. » Nous sommes à un moment charnière où l’infrastructure compte autant que les modèles eux-mêmes.

Les implications pour l’écosystème

L’architecture stateless de MCP 2.0 apporte des bénéfices concrets :

• Scalabilité simplifiée : déploiement derrière des load balancers round-robin classiques, sans sticky sessions ni coordination entre réplicas
• Coûts réduits : pas besoin de Redis ou d’un store de sessions partagé, réduction de la complexité opérationnelle
• Résilience accrue : les requêtes peuvent survivre aux redémarrages de serveurs, aux timeouts réseau, aux migrations d’instances
• Multi-région facilitée : routage géographique sans contrainte de session

Mais la migration n’est pas sans coût. Selon plusieurs guides techniques, les serveurs MCP 1.0 qui s’appuyaient sur des sessions pour maintenir un contexte (transactions ouvertes, états conversationnels) doivent repenser leur architecture. La spécification introduit un système d’extensions pour gérer les cas d’usage complexes (tâches longues, applications interactives) sans alourdir le cœur du protocole.

La spec 2026-07-28 introduit également une politique de dépréciation formelle : 12 mois minimum entre l’annonce de la dépréciation d’une fonctionnalité et sa suppression effective. Trois primitives historiques sont dépréciées : roots, sampling et logging. Les développeurs ont jusqu’à mi-2027 pour migrer.

Vers une standardisation de l’écosystème agents ?

MCP 2.0 arrive à un moment où l’écosystème des agents IA cherche désespérément ses standards. Chaque acteur majeur a sa propre approche : OpenAI avec Function Calling, LangChain et LlamaIndex avec leurs frameworks respectifs, Anthropic avec MCP et Skills. Cette fragmentation rappelle les guerres de standards du web des années 2000 — avant que HTTP, REST et JSON ne s’imposent.

Plusieurs observateurs notent que la vraie bataille n’est pas technique mais philosophique : abstraction vs simplicité. MCP incarne l’abstraction — un protocole riche qui gère tous les cas d’usage. Skills incarne la simplicité — des outils Unix et de la débrouille. Historiquement, c’est souvent la simplicité qui gagne (voir le triomphe de REST sur SOAP), mais l’abstraction trouve sa place dans les contextes exigeants (entreprise, sécurité, gouvernance).

Comme le souligne un article de LinkedIn par Aditya Singhal, qui a assisté à l’événement de lancement MCP 2.0 à New York : « No handshake state, no session IDs, no sticky routing — just plain HTTP that any load balancer understands. » Cette simplicité retrouvée pourrait être la clé de l’adoption massive.

Les zones d’ombre persistent

Plusieurs questions restent ouvertes. Premièrement, l’adoption réelle : au-delà du buzz initial et de l’engagement de quelques développeurs influents, combien de projets migreront effectivement vers MCP 2.0 ? Les early adopters de MCP 1.0 ont investi du temps et du code — la migration représente un coût non négligeable.

Deuxièmement, la réaction des autres acteurs. OpenAI, Google, Microsoft vont-ils adopter MCP comme standard commun, ou lancer leurs propres protocoles ? L’interopérabilité promise par MCP ne se matérialisera que si l’industrie converge. Pour l’instant, seul Anthropic pousse activement le protocole.

Troisièmement, les limitations de l’architecture stateless. Certains cas d’usage complexes — transactions multi-étapes, contexte conversationnel riche, états partagés entre outils — bénéficiaient de sessions. La nouvelle architecture, même avec le système d’extensions, impose-t-elle des compromis que certains développeurs jugeront inacceptables ?

Enfin, la sécurité. Donner à un agent IA accès à des dizaines de serveurs MCP — bases de données, APIs internes, outils cloud — crée une surface d’attaque considérable. Les mécanismes d’authentification et d’autorisation de MCP 2.0 sont-ils suffisamment robustes pour l’entreprise ? Plusieurs chercheurs en sécurité ont déjà identifié des vecteurs d’attaque par prompt injection dans les systèmes MCP.

Conclusion : renaissance ou faux départ ?

MCP 2.0 marque indéniablement un tournant. En abandonnant les sessions, Anthropic reconnaît implicitement que l’architecture originale était trop complexe pour l’adoption de masse. Cette simplification rapproche philosophiquement MCP de Skills, brouillant la distinction entre les deux approches.

L’engagement immédiat de développeurs influents comme Simon Willison est un signal positif — dans l’écosystème IA, ce que construisent les « taste makers » techniques prédit souvent mieux les tendances que les communiqués officiels. Mais la vraie épreuve viendra dans les 6 à 12 prochains mois : MCP 2.0 deviendra-t-il le « HTTP des agents IA », ou connaîtra-t-il une nouvelle éclipse ?

Une chose est certaine : nous assistons à la maturation de l’IA générative. Après la course aux capacités (modèles plus puissants), vient la phase d’intégration (comment connecter l’IA au monde réel). Les standards qui émergeront maintenant détermineront l’architecture de l’IA pour la décennie à venir. MCP 2.0 est un candidat sérieux — mais le match est loin d’être joué.

La question reste ouverte : dans un monde où un simple accès terminal suffit souvent, avons-nous vraiment besoin d’un protocole standardisé ? Ou MCP trouvera-t-il sa niche dans les déploiements entreprise exigeant gouvernance et sécurité, laissant Skills dominer l’usage général ? L’année 2027 nous le dira.