Ce que le transport sans état de MCP change à grande échelle

La plus importante mise à niveau d’entreprise de MCP transforme l’infrastructure

La plus grande évolution du Model Context Protocol depuis sa création remodèle l’infrastructure autour des agents IA. MCP, le standard ouvert créé par Anthropic en novembre 2024 pour connecter des agents IA à des logiciels, est désormais engagé depuis environ vingt mois dans une transition d’un projet Anthropic vers une infrastructure partagée. Sa dernière version modifie les hypothèses concernant les sessions, l’autorisation, les mises à niveau et le contrôle du projet, qui rendaient ce protocole adopté rapidement difficile à exploiter et à fiabiliser à l’échelle de l’entreprise.

David Soria Parra, co-créateur de MCP, mainteneur principal chez Anthropic, employé d’Anthropic et détenteur d’un droit de veto technique sur le projet, a décrit l’ampleur de cette version dans un entretien avec VentureBeat. Anthropic a créé MCP et en tire un avantage lorsque son protocole devient une infrastructure utilisée sur l’ensemble du marché de l’IA, si bien que ses mainteneurs ont un intérêt direct à une adoption plus large. « Certaines personnes l’appellent en plaisantant une v2, et je pense qu’au fond c’est juste », a déclaré Soria Parra. « C’est probablement le plus grand changement que nous ayons jamais apporté au protocole, et c’est une étape majeure dans sa maturation pour un usage par de très grands acteurs. »

La question de l’entreprise a aussi fait entrer en jeu des points de vue au-delà d’Anthropic. VentureBeat a interrogé le mainteneur principal Den Delimarsky ainsi que Mazin Gilbert, directeur exécutif de l’Agentic AI Foundation (AAIF), vétéran de Google et d’AT&T ayant de l’expérience dans la création de fondations avec la Linux Foundation. Gilbert dirige la fondation qui supervise MCP, de sorte que l’AAIF bénéficie institutionnellement à mesure que le protocole gagne en membres, en adoption et en influence. Son critère de confiance pour l’entreprise repose sur trois conditions : un standard ouvert, une scalabilité sans état et une gouvernance neutre, une combinaison qui, selon lui, n’existait ni il y a un an ni même il y a six mois.

Ces conditions transforment la maturité du protocole en question d’infrastructure. Une entreprise qui choisit une dépendance durable a besoin d’instances serveur interchangeables, de contrôles d’identité et de sécurité familiers, d’un préavis suffisant pour gérer les changements incompatibles, et d’une gouvernance capable d’inspirer confiance à travers les fournisseurs. « Si j’étais une entreprise du Fortune 500 en train d’évaluer comment je fais confiance à l’internet, j’aurais besoin que ces trois éléments soient réunis, et ils ne l’étaient pas il y a un an. Ils ne l’étaient pas même il y a six mois. Mais ils le sont aujourd’hui », a déclaré Gilbert. Cette version renforce ces domaines, alors même que l’état existe toujours, que le travail sur la sécurité se poursuit et qu’un employé d’Anthropic conserve un droit de veto formel.

Le transport sans état change le modèle d’exploitation

La première exigence d’entreprise apparaît dans la manière dont une requête MCP atteint un serveur. Auparavant, un client MCP établissait une session persistante avec une instance serveur donnée, ce qui obligeait l’infrastructure à préserver cette relation via un routage sticky, c’est-à-dire en renvoyant les requêtes répétées vers la même instance, ou via un stockage partagé des informations de session. Les flottes cloud-native remplacent couramment les instances de calcul pendant que les load balancers répartissent les requêtes sur la capacité disponible. Dans l’ancienne conception, la perte de l’instance qui détenait une session MCP pouvait interrompre les requêtes ultérieures et faire perdre le travail associé à l’agent.

Delimarsky a décrit ce mode de défaillance au niveau des pods de calcul. « Avant, il fallait disposer d’un magasin de sessions et gérer des identifiants de session, et si l’un de vos pods de calcul tombait, soudain les requêtes commençaient à échouer », a-t-il déclaré. « Ce ne sera pas un problème avec la nouvelle version du protocole. C’est un énorme déblocage, et c’en est un que nous avons élaboré en collaboration avec des équipes de nombreuses entreprises. » Les opérateurs devaient donc préserver suffisamment de continuité pour que les requêtes ultérieures retrouvent l’état associé à l’interaction précédente.

Le transport sans état change l’endroit où cette continuité réside. Une requête peut désormais arriver via un load balancer classique et être traitée par n’importe quel serveur MCP disponible, car les informations nécessaires à l’interaction transitent dans le transport au lieu de dépendre implicitement d’une seule instance serveur. Des instances interchangeables peuvent ainsi s’intégrer aux modèles d’exploitation Kubernetes et cloud-native que de nombreuses organisations utilisent déjà. Gilbert a résumé la conséquence sur l’infrastructure : « Cette capacité sans état permet à votre client MCP de dialoguer avec un load balancer qui se connecte à n’importe quel serveur. Vous n’avez pas besoin de stickiness. »

Le modèle d’exploitation devient plus important à mesure que le nombre d’agents augmente. Gilbert dit avoir rencontré des entreprises déployant « des dizaines de milliers d’agents », où le maintien d’une affinité serveur pour chaque interaction crée une contrainte d’infrastructure indépendante des capacités des agents. « Ce n’était pas la technologie, ce n’était pas le business case, c’étaient vraiment ces changements fondamentaux qui étaient nécessaires », a-t-il déclaré. Pour ces organisations, adopter MCP relevait en partie d’une décision opérationnelle, car le protocole devait se comporter de manière prévisible au sein d’une infrastructure distribuée existante.

Le problème d’échelle était visible presque dès le lancement de MCP. En décembre 2024, quelques semaines seulement après l’apparition du protocole, le co-créateur Justin Spahr-Summers a ouvert une discussion publique de conception sur GitHub identifiant les connexions persistantes avec état comme une limite pour les déploiements serverless. Les participants ont examiné trois voies architecturales, dont l’orientation entièrement sans état aujourd’hui largement adoptée. Des ingénieurs de Vercel, Cloudflare, Shopify et Amazon ont rejoint la discussion au cours des mois suivants, reliant le problème de transport à plusieurs types d’infrastructure et de charges applicatives.

Cette discussion publique est ensuite devenue une orientation de conception formelle. Selon l’annonce de la version, les mainteneurs principaux se sont engagés sur cette approche du transport lors d’une réunion de décembre 2025 consacrée aux futurs transports de MCP. Le temps écoulé entre la première discussion sur GitHub et cette décision est important, car déplacer l’état change qui doit le gérer. MCP peut désormais s’intégrer à un déploiement standard équilibré par load balancer, tandis que les applications continuent à maintenir l’état requis par leurs propres workflows.

Soria Parra explicite cette frontière. « Une grande partie de l’état ne disparaît pas, mais il est déplacé dans les deux sens avec le serveur sur le fil, au niveau même de la couche de transport », a-t-il déclaré. Déplacer davantage d’informations avec une interaction augmente la taille des messages, ce qui crée un coût concret pour le nouveau modèle d’exploitation. « Vous obtenez des payloads plus volumineux en échange de l’absence d’état, mais heureusement ils se compressent très bien, sont très bien compris, et restent assez petits en comparaison d’une requête HTTP sur le web », a-t-il déclaré.

Le coût du transport s’accompagne d’un changement de responsabilité applicative. « Avec l’absence d’état, nous avons transféré la responsabilité de créer et de gérer l’état aux développeurs, mais de manière très intentionnelle », a déclaré Delimarsky. Dans l’ancienne conception, a-t-il expliqué, les développeurs se heurtaient sans cesse à la question de savoir si l’état du protocole était nécessaire, où il devait résider et comment l’utiliser. La nouvelle frontière rend le choix explicite : les développeurs gèrent l’état adapté à leur environnement, tandis que le transport peut acheminer les requêtes entre des instances serveur interchangeables.

Ce transfert de responsabilité réduit aussi les comportements qui dépendaient d’une relation persistante avec le serveur. Un exemple est la journalisation serveur hors bande, qui permettait à un serveur d’envoyer des logs d’information à un client indépendamment du flux normal de requêtes. Avant de supprimer ce comportement, les mainteneurs ont analysé GitHub pour en mesurer l’usage ; Soria Parra a indiqué qu’il était pratiquement inexistant et a estimé la population concernée à « probablement une poignée de personnes, littéralement une poignée de personnes ». Ces données d’usage ont donné aux mainteneurs une base pour choisir une sémantique de transport plus simple malgré le coût de compatibilité.

Soria Parra a également décrit le compromis personnel impliqué par l’abandon d’un comportement qu’il pensait utile. « Je suis triste que des choses que je pensais utiles se soient révélées ne pas l’être », a-t-il déclaré. « Je pense que l’un des plus grands compromis concernait davantage mon ego qu’une quelconque limitation réelle du protocole. » Pour les responsables engineering, la frontière de coût est concrète : le transport sans état entraîne des payloads plus volumineux, une gestion explicite de l’état applicatif et la suppression de certains comportements qui reposaient sur des connexions persistantes.

La préparation à l’entreprise exige aussi identité, sécurité et un contrat de changement stable

La refonte du transport répond aux besoins des grandes flottes, mais des déploiements plus modestes peuvent rencontrer plus tôt des contraintes de sécurité et de cycle de vie. Gilbert affirme que les lacunes en matière d’autorisation et d’identité, ainsi que l’incertitude sur les changements de spécification, ont ralenti ces adopteurs. « Il y a des entreprises qui déploient des choses à plus petite échelle, mais elles sont ralenties à cause du manque de MCP en matière d’autorisation, à cause de l’identité, à cause de la question de savoir si elles font confiance à la politique de dépréciation. Les choses pouvaient changer pratiquement n’importe quel jour », a-t-il déclaré. Ces organisations, a-t-il ajouté, « vont en bénéficier non pas à cause de l’absence d’état. Elles vont en bénéficier à cause de la sécurité. »

Ce travail sur la sécurité aligne de plus en plus MCP sur OAuth 2.0, le framework d’autorisation établi, et OpenID Connect, la couche d’identité couramment utilisée avec lui. Une mesure concrète de durcissement est la validation obligatoire de la valeur émetteur, ou iss, qui identifie le serveur d’identité ayant émis une réponse d’autorisation. Un client doit vérifier que la réponse provient bien du serveur d’identité attendu. Ce contrôle ferme la voie protocolaire aux attaques de confusion de serveur d’identité et donne aux implémentations une exigence définie à appliquer de manière cohérente.

L’exigence relative à l’émetteur reflète une ingénierie préventive. « Ce n’est pas quelque chose qui soit lié à des vulnérabilités existantes ou à une exploitation active », a déclaré Delimarsky. « Il s’agit davantage de nous engager directement avec la communauté de la sécurité. » Il a décrit le principe de conception plus large comme une réutilisation des pratiques de sécurité établies : « MCP, en tant que protocole, établit très clairement le principe suivant : nous ne voulons pas réinventer la roue, mais nous voulons aussi être à l’avant-garde d’une grande partie de l’innovation en matière de sécurité. »

Ce travail sur l’identité s’étend aussi d’une connexion individuelle à une autorisation à l’échelle de l’organisation. Enterprise Managed Authorization, développé avec le fournisseur d’identité Okta, permet au fournisseur d’identité d’une entreprise d’agir comme gardien de référence pour l’accès aux serveurs MCP. Okta peut en tirer un bénéfice commercial à mesure que les contrôles d’identité d’entreprise deviennent plus importants pour les déploiements MCP, tandis que le mécanisme sous-jacent a été développé comme standard ouvert. Un employé peut s’authentifier avec ses identifiants d’entreprise, ce qui permet à l’organisation d’appliquer des règles d’accès communes sur une flotte et de contrôler où les clients peuvent envoyer des données organisationnelles.

Le modèle à l’échelle de l’organisation est important lorsqu’un administrateur gère de nombreux serveurs. « Si je suis quelqu’un qui gère des dizaines, des centaines de serveurs MCP pour mon organisation, je veux m’assurer que j’applique un certain niveau de gouvernance commune, où les gens s’authentifient avec leurs identifiants d’entreprise et non leurs identifiants personnels, afin que le client n’envoie pas de données vers des sources non autorisées », a déclaré Delimarsky. Okta a amorcé le standard ouvert sous-jacent à Enterprise Managed Authorization, après quoi les mainteneurs ont travaillé à soutenir une adoption à l’échelle de l’écosystème chez les fournisseurs d’identité.

Le travail actuel sur l’autorisation crée aussi une base pour des mécanismes plus robustes demandés par les équipes sécurité. Parmi les ajouts proposés figurent la preuve démontrée de possession, où un appelant prouve qu’il contrôle les éléments d’identification associés à une autorisation, et la fédération d’identité des workloads, qui permet à des charges logicielles d’établir leur identité à travers différents environnements. Gilbert soutient que l’ensemble de ces travaux sur l’autorisation a rapproché MCP de ce qu’il appelle le niveau « enterprise ready » et l’a éloigné d’une « sorte d’expérience de laboratoire ouvert ». Son rôle à l’AAIF lui donne un intérêt institutionnel dans cette affirmation de maturité, et ces capacités supplémentaires de sécurité de production restent des propositions.

La sécurité d’une dépendance durable exige aussi une évolution prévisible du protocole. MCP dispose désormais d’une politique formelle de dépréciation sur 12 mois : après la dépréciation formelle d’une fonctionnalité, au moins douze mois doivent s’écouler avant que les mainteneurs puissent la supprimer. La suppression devient possible après cette période et reste une décision distincte. Le processus passe de la dépréciation à une période minimale d’observation et de collecte de retours avant que les mainteneurs décident si la suppression doit avoir lieu.

L’intervalle de douze mois est issu de discussions sur les cycles de déploiement avec Google, Microsoft et Amazon, qui participent tous aux marchés de l’IA et du cloud susceptibles de bénéficier d’une infrastructure MCP prévisible. « Douze mois semblaient constituer un juste milieu raisonnable », a déclaré Delimarsky. Il a également lié la dépréciation à la demande d’implémentation : « Il ne s’agit pas d’arracher des éléments du protocole simplement parce que nous ne les aimons pas. Il existe une traction industrielle très, très forte derrière ces changements. » Pour les adopteurs, cette politique devient une partie du contrat d’exploitation qui régit la rapidité avec laquelle une implémentation peut être contrainte de migrer.

Le comportement observé lors des mises à niveau donne à ce contrat un contexte pratique. La télémétrie des mainteneurs indique que la majeure partie de l’écosystème effectue la mise à niveau en six à huit mois, laissant du temps supplémentaire à l’intérieur de la période minimale de douze mois pour les déploiements plus lents et les retours d’implémentation. « Cela dit simplement que dans 12 mois nous serons ouverts à la suppression, mais Den et moi pouvons changer d’avis en fonction des retours. Je pense qu’il s’agit davantage d’une période de retour qu’une période définitive », a déclaré Soria Parra. La garantie fixe la date de suppression la plus précoce tout en laissant aux mainteneurs la liberté de conserver une capacité dépréciée.

Ce processus de migration dépend aussi de l’écosystème officiel de SDK de MCP, qui comprend TypeScript, Python, C#, Rust, Java et d’autres langages. De nombreuses implémentations s’appuient sur ces kits de développement logiciel, de sorte que certains changements de protocole peuvent être absorbés dans des bibliothèques partagées puis se diffuser dans les applications via des mises à niveau de SDK. « L’une des choses clés que nous faisons en permanence est de vérifier que le chemin de mise à niveau est minimal, au point où n’importe quel modèle au monde pourra probablement le faire en one-shot pour vous », a déclaré Soria Parra. Sa remarque montre aussi que les assistants de codage IA influencent les attentes des mainteneurs en matière d’effort de migration.

Les tâches, les interactions enrichies et les extensions s’appuient sur le nouveau transport

Avec un transport et un comportement de cycle de vie devenant plus prévisibles, MCP peut prendre en charge des opérations qui durent au-delà d’un court échange requête-réponse. Un nouveau framework d’extensions permet à des capacités optionnelles d’évoluer séparément de la spécification centrale, en gardant un cœur plus resserré tandis que les fonctionnalités spécialisées suivent leurs propres calendriers. MCP Tasks et MCP Apps sont désormais devenus des extensions officielles dans cette structure. Tous deux dépendent des règles de cycle de vie situées en dessous d’eux, car leurs interactions sont plus complexes que le simple renvoi d’un résultat textuel.

MCP Tasks gère un travail asynchrone durable, c’est-à-dire un travail qui continue pendant que le client est déconnecté. Un serveur peut lancer une opération longue et renvoyer un handle de tâche durable, permettant au client de se déconnecter, de planter ou de redémarrer avant de reprendre l’interrogation pour vérifier l’achèvement. Delimarsky a pris comme exemple concret le traitement d’audio ou de vidéo de podcast : « Vous avez traité de l’audio pour un podcast ou une vidéo, le serveur peut notifier le client en retour et dire : la tâche est terminée. Vous n’avez pas besoin d’attendre et de garder le flux ouvert. »

Les requêtes à plusieurs allers-retours résolvent une deuxième forme de charge de travail dans laquelle une opération a besoin de plus d’informations avant son exécution. Le client et le serveur peuvent échanger des paramètres ou d’autres entrées nécessaires au cours d’une même opération logique, puis poursuivre une fois les informations requises établies. « Ce n’est pas simplement un one-shot, via le flux, vous obtenez l’entrée et c’est terminé », a déclaré Delimarsky. « Vous pouvez réellement interagir, du serveur vers le client, pour obtenir les bons paramètres afin d’exécuter une action. »

MCP Apps étend le même modèle d’interaction à la présentation. Les serveurs peuvent rendre des interfaces interactives riches au sein des clients IA, en fournissant un tableau de bord pour inspecter des données, un formulaire pour une saisie structurée, ou une visualisation de résultats plus faciles à comprendre graphiquement. Ces interactions orientées utilisateur donnent plus de poids au comportement du transport et du cycle de vie, car la connexion MCP peut se trouver sous des expériences applicatives utilisées directement par des personnes. Les défaillances d’infrastructure peuvent donc devenir des défaillances produit visibles plutôt que de simples erreurs d’outils en arrière-plan.

Ces exigences de production aident à expliquer pourquoi de grandes entreprises technologiques ont influencé cette version. Soria Parra affirme que des experts en systèmes distribués chez Microsoft, Google et d’autres entreprises ont travaillé sur des changements motivés par leurs propres déploiements et par des exigences plus larges du secteur. Microsoft et Google ont des intérêts commerciaux dans les agents et l’infrastructure cloud, de sorte que les améliorations qui facilitent le déploiement de MCP peuvent profiter à leurs produits autant qu’aux autres implémenteurs. Leur implication soulève aussi la prochaine question de dépendance d’entreprise : qui contrôle une spécification façonnée par des fournisseurs concurrents ?

La gouvernance s’est élargie tandis que l’autorité formelle reste concentrée

Cette question du contrôle a changé de manière significative lorsque Anthropic a fait don de MCP en décembre 2025 à l’AAIF nouvellement créée sous l’égide de la Linux Foundation. Anthropic avait créé le protocole en novembre 2024, tandis que Block a apporté un projet fondateur de l’AAIF et OpenAI a fourni un autre projet fondateur. Sept mois après ce don, l’AAIF est l’organisme de supervision de MCP en tant que fonds dirigé, une structure de la Linux Foundation par laquelle des participants désignés supervisent le financement et la gouvernance d’un domaine de projet défini. Cet arrangement place des entreprises d’IA concurrentes dans un cadre institutionnel commun.

Le groupe des mainteneurs s’est élargi en parallèle de ce transfert. Les mainteneurs principaux représentent désormais Anthropic, Microsoft, OpenAI, Google et Amazon, des entreprises en concurrence dans l’IA, le cloud, les modèles et les plateformes développeur, tandis que les contributeurs incluent des entreprises comme Block. Leur participation commune doit donc être lue dans le contexte de la concurrence commerciale plutôt que comme une analyse neutre d’observateurs indépendants. Soria Parra affirme que les décisions importantes sont « généralement unanimes » et décrit ainsi la position d’Anthropic : « Techniquement, nous avons beaucoup d’influence ; de facto, nous ne l’exerçons pas. »

L’autorité formelle reste différente de la participation plus large qui l’entoure. Soria Parra reste un employé d’Anthropic et a reconnu : « J’ai bien des droits de veto, techniquement », tout en ajoutant : « mais je pense que nous ne les avons jamais activement utilisés dans quelque discussion que ce soit. » Un veto inutilisé reste pertinent pour la neutralité institutionnelle, car le consensus dans les décisions actuelles et le pouvoir formel de bloquer une décision sont deux propriétés distinctes. Soria Parra s’attend à ce que les structures de gouvernance s’élargissent avec le temps pour inclure davantage de participants.

La fondation autour de cette structure de gouvernance ajoute aussi rapidement des membres. Gilbert estime que la part de contribution d’Anthropic est tombée sous la moitié, tandis que le nombre d’organisations de l’AAIF et le rythme de recrutement ont évolué comme suit :

Gilbert qualifie l’AAIF de « fondation à la croissance la plus rapide » en nombre de membres dans l’histoire de la Linux Foundation. En tant que directeur exécutif de l’AAIF, il a un intérêt institutionnel à ce que la croissance du nombre de membres soit perçue comme une preuve de la solidité de la fondation. Une base de membres plus large crée davantage de participants potentiels au travail de normalisation, tandis que l’autorité technique continue de suivre les règles de gouvernance du projet.

Le type d’organisation rejoignant l’AAIF ajoute une autre dimension à cette croissance. La participation s’étend désormais au-delà des fournisseurs technologiques classiques vers le retail, la finance et les télécoms, et la liste comprend le CERN et Consumer Reports. Gilbert affirme que les adopteurs veulent de plus en plus façonner les protocoles dès leur création, ce qui leur donne un rôle pendant que les standards sont encore en cours de formation. Il explique la présence de Consumer Reports comme importante « parce que quelqu’un doit défendre les consommateurs lorsque cet internet des agents prendra vie ».

Cette participation élargie soutient aussi la philosophie de Gilbert en matière de normalisation. « Garder le contrôle d’un projet n’en fait pas un standard ouvert », a-t-il déclaré. « Il faut lâcher prise. Il faut contribuer, et il faut agrandir le gâteau et la communauté. Et Anthropic a fait un travail incroyable en faisant exactement cela. » Comme Gilbert dirige la fondation qui reçoit le projet d’Anthropic, son éloge vient d’une organisation qui bénéficie d’un transfert réussi et d’une communauté en expansion.

Le défi de gouvernance est plus difficile parce que les fournisseurs participants restent des concurrents actifs. Gilbert décrit la fondation comme un lieu « où des concurrents qui se livrent une concurrence féroce pendant la journée » peuvent « venir dans une salle neutre et débattre, échanger, s’aligner, consolider et faire avancer des standards ouverts sur la manière dont l’Internet of Agents va évoluer ». Son parcours professionnel chez Google et AT&T, ainsi que son expérience dans la création de fondations avec la Linux Foundation, nourrissent cette approche orientée standards. La trajectoire de MCP passe désormais du don d’Anthropic à une représentation élargie des mainteneurs et à des décisions majoritairement unanimes, vers des structures de gouvernance appelées à inclure encore plus de parties.

L’AAIF étend aussi cette participation sur le plan géographique. Des événements AGNTCon et MCPCon sont prévus cet automne à Shanghai, Tokyo, Amsterdam et San Jose, avec d’autres événements prévus en Corée du Sud, à Nairobi et à Toronto. Gilbert investit également dans la croissance du nombre de membres en Asie et en Inde, qu’il considère comme des marchés encore sous-développés pour l’expansion de la fondation. Cet effort géographique sert les objectifs de croissance de l’AAIF tout en élargissant l’ensemble des écosystèmes technologiques dans lesquels MCP pourrait devenir une infrastructure commune.

Cette poussée géographique est directement liée à l’interopérabilité des modèles. « Nous sommes totalement agnostiques quant au modèle, qu’il s’agisse de Kimi, de Gemma, d’un frontier model d’Anthropic, ou de n’importe qui d’autre », a déclaré Gilbert. « Chaque modèle devra prendre en charge MCP, qu’il s’agisse d’un modèle chinois ou d’un modèle américain, cela n’a pas d’importance. Les protocoles doivent être ouverts, standardisés. » Il soutient que les entreprises choisissent déjà des modèles « dans tous les sens » selon leurs besoins, ce qui accroît la valeur d’interfaces communes à mesure que le choix des modèles se diversifie.

Le comportement en production est le prochain test d’adoption

Cette ambition d’interopérabilité repose déjà sur un vaste écosystème développeur. Soria Parra affirme que les téléchargements de SDK ont doublé au cours des six mois précédents et atteignent désormais environ 250 millions par semaine, des chiffres qu’il a qualifiés de « délirants ». Quand Anthropic a fait don de MCP en décembre 2025, l’entreprise avait indiqué 97 millions de téléchargements mensuels pour les seuls SDK Python et TypeScript. Comme ces chiffres couvrent des périmètres de SDK et des périodes différents, ils décrivent une croissance sans constituer une comparaison de performance strictement comparable.

Cette croissance des téléchargements a accompagné un changement organisationnel rapide. Soria Parra affirme que MCP était un projet exclusivement Anthropic dix-huit mois plus tôt, qu’il bénéficiait d’un engagement externe substantiel douze mois plus tôt, et qu’il est désormais ce qu’il décrit comme une communauté mondiale. Delimarsky affirme que le projet atteint un « point d’inflexion » où il devient un substrate, c’est-à-dire une couche technique partagée, pour les workflows agentiques dans les entreprises, les startups et d’autres organisations. Les deux mainteneurs attribuent aussi ce progrès au grand nombre de bénévoles qui contribuent de leur propre temps aux côtés des grands fournisseurs.

Le déploiement en production fournit désormais une mesure différente de celle des téléchargements de SDK. Les mainteneurs prévoient d’observer combien de serveurs implémentent la nouvelle spécification, si des moteurs majeurs comme Microsoft et Google la déploient, et ce que les implémenteurs remontent via les groupes de travail MCP, GitHub et Discord. Soria Parra affirme que Microsoft et Google ont motivé de nombreux changements et que les premiers signaux d’implémentation sont « très, très positifs ». Ces entreprises bénéficient aussi commercialement d’une infrastructure qui soutient leurs offres IA et cloud, ce qui fait du comportement déployé un contrôle important des attentes des fournisseurs.

Les prochains projets de l’AAIF augmenteront la charge pesant sur cette base de production. Son projet Agent Gateway, nouvellement annoncé, traite de la gestion du trafic et de l’application des politiques, tandis que Gilbert voit dans le commerce agentique un futur cas d’usage de MCP où les marchands exposent produits et services afin que les agents puissent les découvrir. Ces applications pourraient couvrir Kimi, Gemma, les modèles Anthropic, les modèles chinois, les modèles américains et d’autres encore, à mesure que les entreprises sélectionnent différents modèles pour différents usages. L’interopérabilité commune devient plus déterminante à mesure que ce mix s’élargit.

Cette expansion inscrit MCP dans un calendrier d’infrastructure plus long que ne le suggèrent ses premiers chiffres d’adoption. Gilbert compare l’environnement émergent à l’infrastructure web qui a mis environ trente ans à gagner une confiance large, tandis que ce qu’il appelle l’« internet des agents » n’en est encore qu’à sa « première, deuxième année ». Les déploiements en production montreront désormais comment le nouveau transport, les règles d’autorisation, le processus de dépréciation, les extensions et les dispositifs de gouvernance se comportent comme dépendances dans des conditions d’exploitation réelles. Le test de gouvernance se poursuivra en parallèle à mesure que l’AAIF grandira et que l’autorité formelle évoluera autour des entreprises concurrentes qui construisent sur MCP.

Points clés à retenir pour les décideurs

• Concevez MCP pour des opérations à l’échelle du cloud : Le transport sans état permet aux clients MCP d’acheminer les requêtes via des load balancers standard vers des instances serveur interchangeables. Les équipes plateforme qui évaluent MCP à grande échelle doivent tenir compte de payloads plus volumineux et déplacer la gestion de l’état spécifique à l’application dans leur propre architecture.
• Traitez l’identité et la politique de cycle de vie comme des exigences de production : MCP renforce désormais l’intégration avec OAuth et OpenID Connect, prend en charge l’autorisation gérée par l’entreprise et garantit au moins 12 mois entre une dépréciation formelle et une suppression éventuelle. Les équipes sécurité et plateforme peuvent utiliser ces contrôles pour aligner les déploiements MCP sur les politiques d’identité de l’entreprise et les cycles de mise à niveau.
• Utilisez les extensions pour des workflows d’agents durables : MCP Tasks prend en charge le travail asynchrone et les interactions en plusieurs étapes, tandis que MCP Apps permet des interfaces interactives au sein des clients IA. Les équipes produit et engineering peuvent évaluer ces extensions pour des charges de travail qui dépassent une seule requête ou nécessitent une interaction utilisateur structurée.
• Évaluez la gouvernance au même titre que la maturité technique : MCP relève désormais de l’AAIF de la Linux Foundation avec des mainteneurs issus d’Anthropic, Microsoft, OpenAI, Google et Amazon. Les équipes achats et architecture doivent néanmoins tenir compte de la concentration de l’autorité formelle, y compris le veto technique d’un employé d’Anthropic, lorsqu’elles évaluent MCP comme dépendance stratégique.
• Mesurez l’adoption en production comme prochain test de maturité : Les téléchargements des SDK MCP ont augmenté rapidement, mais les déploiements en production fourniront des preuves plus solides que le nouveau transport, les contrôles de sécurité, les extensions et le modèle de gouvernance tiennent à l’échelle de l’entreprise. Les responsables technologiques peuvent suivre l’implémentation côté serveur, les déploiements des grands fournisseurs et les retours opérationnels avant de faire de MCP une dépendance d’infrastructure plus profonde.