Le 9 décembre 2025, Anthropic a donné le Model Context Protocol (MCP) à la Linux Foundation, au sein de la nouvelle Agentic AI Foundation (AAIF). Un an après son lancement, MCP revendique plus de 10 000 serveurs actifs et un SDK téléchargé plus de 97 millions de fois par mois.
Ce mouvement acte une bascule. On sort des connecteurs bricolés par équipe, pour entrer dans une logique d’infrastructure partagée et gouvernée de façon neutre. Avec MCP, les agents IA gagnent une interface standard pour accéder à vos outils et à vos données, sans dépendre d’un seul éditeur.
Vous allez comprendre ce que ce transfert change concrètement pour votre architecture et vos budgets, pourquoi le risque de fragmentation baisse, et quels points de vigilance sécurité et conformité anticiper avant un déploiement à l’échelle.
Ce que change l’Agentic AI Foundation (AAIF) pour l’écosystème agentique
Pourquoi le transfert de MCP à la Linux Foundation est un signal fort (neutralité, gouvernance, pérennité)
Quand un protocole devient critique, la question n’est plus “est-ce que ça marche ?” mais “qui le contrôle ?”. Le transfert du Model Context Protocol (MCP) à la Linux Foundation via l’Agentic AI Foundation (AAIF) répond à ce point. Vous sortez d’un standard piloté par une seule entreprise. Vous entrez dans une gouvernance plus neutre, avec des règles de contribution, de maintenance et d’évolution plus prévisibles.
Pour une organisation, la valeur est immédiate. Un protocole d’intégration touche à vos systèmes sources, à vos identités, à vos autorisations. C’est un point de passage. Le voir se stabiliser sous une fondation réduit le risque de revirement stratégique, de licence qui change, ou de feuille de route orientée par un seul produit.
Prenez un cas simple. Vous avez un assistant interne branché à votre base de connaissances, à Jira et à votre CRM. Si ce “câblage” dépend d’une implémentation propriétaire, la migration coûte cher. Si le protocole est géré comme une infrastructure commune, vous pouvez changer de modèle, d’éditeur, voire d’environnement d’exécution sans réécrire toute la couche d’accès aux outils.
Les autres briques fondatrices : goose (Block) et AGENTS.md (OpenAI) comme socle de conventions
L’AAIF ne se limite pas à MCP. Elle regroupe des briques complémentaires. goose, côté Block, vise la construction et l’orchestration d’agents. AGENTS.md, côté OpenAI, sert de convention lisible par humains et machines pour décrire comment un agent doit interagir avec un dépôt, un projet, une base de code. Le signal est clair : l’industrie ne veut pas seulement des modèles plus forts. Elle veut des interfaces et des conventions partagées, qui rendent les agents déployables et maintenables.
Pour vous, ça ressemble à une normalisation “à l’open source”. Des pièces séparées, mais compatibles. Un protocole de connexion, une manière de décrire le contexte d’un projet, et des outils d’orchestration. Ce trio réduit la multiplication de formats maison et de connecteurs jetables.
L’objectif implicite : éviter la fragmentation propriétaire de “l’infrastructure agentique”
Sans socle commun, chaque plateforme pousse son runtime, son format de tool calling, son catalogue de connecteurs. Vous payez alors une taxe permanente d’intégration. Vous multipliez les couches de traduction. Vous introduisez des zones grises de sécurité, parce que chaque connecteur a sa propre logique d’autorisations.
L’AAIF vise l’effet inverse. Un standard commun, adopté largement, pour que la concurrence se fasse sur l’expérience, la performance et la sécurité, pas sur des “prises” incompatibles. C’est la différence entre un marché d’accessoires et un marché de formats. Dans le premier, vous choisissez librement. Dans le second, vous êtes enfermé.
MCP en clair : le standard de connexion modèles ↔ outils ↔ données
La promesse “USB‑C de l’IA” : une interface universelle plutôt que des intégrations sur mesure
MCP joue le rôle d’interface. Il standardise la façon dont un modèle ou un agent accède à des outils et à des données. La comparaison “USB‑C de l’IA” tient parce qu’elle capture l’essentiel : vous n’avez pas besoin d’un câble différent pour chaque appareil. Vous avez une forme de contrat d’échange.
Concrètement, au lieu d’implémenter une intégration spécifique “LLM ↔ Salesforce”, puis une autre “LLM ↔ ServiceNow”, puis une autre “LLM ↔ Databricks”, vous exposez des capacités via un serveur MCP. L’agent consomme ces capacités de manière uniforme. Vous déplacez l’effort du côté “outil”, là où il doit être : près des permissions, des schémas de données et des contraintes métier.
Exemple. Une équipe support veut un agent qui propose des réponses et crée des tickets. Avant, on empilait des scripts, des webhooks, des SDK différents selon le modèle choisi. Avec MCP, vous publiez un serveur MCP qui expose “rechercher dans la base”, “créer un ticket”, “récupérer le statut”, avec des garde-fous. Si vous remplacez le modèle, vous gardez la même interface. Vous ne cassez pas le support.
Indicateurs d’adoption qui comptent pour un décideur (10 000 serveurs actifs, 97M téléchargements SDK/mois)
Les chiffres ne prouvent pas la qualité, mais ils prouvent la dynamique. Plus de 10 000 serveurs MCP actifs et plus de 97 millions de téléchargements mensuels du SDK indiquent une adoption large. Pour un décideur, ce sont des signaux de disponibilité de compétences, d’outillage et de retours terrain. C’est aussi un proxy de compatibilité future : plus un standard est utilisé, plus son évolution est contrainte par la réalité.
L’adoption change aussi la négociation. Si vos fournisseurs exposent des connecteurs MCP, vous évitez une intégration sur mesure facturée à chaque changement de périmètre. Vous pouvez demander un “MCP-first” dans vos RFP. C’est un levier très concret pour réduire les coûts cachés.
Effet réseau : support multi-plateformes (Claude, ChatGPT, Copilot, Gemini, Cursor, VS Code)
Le point décisif, c’est la multi-plateforme. Quand un protocole est reconnu par plusieurs environnements majeurs, il cesse d’être une “feature” d’un produit. Il devient un standard de marché. MCP est déjà présent dans des contextes très différents : assistants, IDE, environnements de développement. Cette ubiquité crée un effet réseau : les éditeurs d’outils ont intérêt à publier un serveur MCP, parce qu’il peut servir plusieurs clients.
Pour vous, ça veut dire une intégration que vous réutilisez. Le même serveur MCP peut alimenter un agent interne, un copilote dans VS Code, ou un workflow automatisé côté support. Vous centralisez les règles d’accès et les logs d’usage au même endroit, au lieu de les disperser par interface.
Pourquoi c’est “le moment” côté entreprise : de l’expérimentation à l’infrastructure
Réduction du risque de vendor lock‑in et meilleure portabilité des agents entre clouds et outils
Le moment est favorable parce que les agents passent du PoC à la production. À ce stade, le lock‑in n’est plus un débat idéologique. C’est un risque financier. Si votre agent est câblé au modèle et au cloud via des APIs spécifiques, chaque changement de fournisseur devient un projet. Avec un standard ouvert connecter LLM aux outils et données, vous isolez la couche volatile (le modèle) de la couche durable (vos systèmes).
Exemple concret. Une équipe marketing automatise la qualification de leads : lecture d’emails entrants, enrichissement, création d’opportunités CRM, notification Slack. Si l’agent est lié à un seul fournisseur, vous ne testez jamais une alternative, même si elle est moins chère ou mieux adaptée. Si l’accès aux outils passe par MCP, vous pouvez changer de modèle pour réduire les coûts, améliorer la latence, ou répondre à une exigence de souveraineté, sans réécrire les intégrations CRM et messagerie.
Cette portabilité devient stratégique quand plusieurs équipes construisent des agents en parallèle. Sans standard, vous obtenez un patchwork. Avec MCP, vous obtenez une colonne vertébrale.
Accélération time‑to‑value : standardisation des connecteurs pour CRM, data, tickets, DevOps, BI
Le gain principal n’est pas “faire plus d’IA”. C’est livrer plus vite des agents utiles. Les cas d’usage à ROI rapide sont ceux qui traversent plusieurs outils : CRM + support, data + BI, tickets + runbooks DevOps. MCP réduit la friction sur ce “dernier kilomètre” qui consomme le plus de temps : connecter proprement, avec des droits et des erreurs gérées.
Vous pouvez industrialiser. Une fois un serveur MCP stabilisé pour un outil clé, vous le réutilisez. Vous versionnez. Vous testez. Vous observez. Vous passez d’un projet artisanal à un produit interne.
Implications budgétaires et d’architecture : rationaliser les intégrations et préparer l’agent operating model
Côté budget, MCP aide à déplacer les coûts. Vous investissez dans quelques connecteurs robustes plutôt que dans une multitude d’intégrations ad hoc. Vous réduisez aussi les coûts de maintenance, parce que vous corrigez et auditez au même endroit.
Côté architecture, vous préparez un “agent operating model”. Qui publie les serveurs MCP. Qui valide les outils exposés. Qui gère les identités et les scopes. Qui suit l’usage et les dérives. Sans cette couche, l’agentique devient vite ingérable.
Un indicateur simple : si deux équipes différentes exposent deux connecteurs différents vers le même outil, vous êtes déjà en train de perdre. MCP donne un cadre pour mutualiser.
- Moins d’intégrations ad hoc à maintenir
- Connecteurs réutilisables et versionnés
- Gouvernance plus claire (publication, validation, ownership)
Les points de vigilance à anticiper (sécurité et maturité enterprise)
Surface d’attaque élargie : permissions, exécution d’outils, exfiltration de données (rôle des gateways type AgentGateway)
Brancher un modèle sur des outils, c’est ouvrir une surface d’action. L’agent ne “répond” plus seulement. Il exécute. Il peut créer, modifier, supprimer. Le risque n’est pas théorique : un prompt injecté, une instruction ambiguë, ou un contexte mal filtré peuvent déclencher une action non désirée.
La réponse n’est pas de renoncer. Elle est d’encadrer. Vous devez traiter les serveurs MCP comme des APIs critiques. Authentification forte. Autorisations minimales. Scopes par action. Et surtout, une couche de contrôle qui filtre et valide. Les approches type gateway (souvent citées autour d’AgentGateway) servent à appliquer des politiques : validation humaine pour certaines actions, règles sur les données sensibles, limites de débit, inspection des sorties.
Exposer un outil via MCP accélère l’accès, mais ne remplace pas votre modèle de sécurité : identités, scopes, audit et garde-fous restent indispensables.
Exemple. Autoriser “lire les tickets” n’implique pas “clore un ticket”. Exposer “rechercher clients” n’implique pas “exporter la liste complète”. MCP facilite l’accès. Il ne remplace pas votre modèle de sécurité.
Conformité et environnements régulés : observabilité, audit, séparation des contextes (exemples type finance)
En environnement régulé, la question est la traçabilité. Qui a demandé quoi. Quelles données ont été consultées. Quelles actions ont été effectuées. Quel modèle a produit la décision. Sans audit, vous ne passez pas en production, même si le cas d’usage est excellent.
Il faut donc instrumenter. Logs détaillés. Corrélation entre requête, contexte fourni, outils appelés et réponse. Conservation alignée avec vos politiques. Séparation stricte des contextes entre équipes et entre clients. Et un contrôle explicite des données envoyées au modèle, surtout quand elles sortent de votre périmètre.
Un exemple parlant est la finance. Un agent d’analyse peut accélérer la recherche, mais vous devez prouver qu’il n’a pas mélangé des informations entre entités, et que les accès étaient autorisés. MCP peut s’insérer proprement, à condition de l’entourer d’observabilité et de politiques.
Ce qu’il faut surveiller en 2026 : roadmap AAIF, retours terrain, événements structurants (MCP Dev Summit NY, avril 2026)
Le passage sous AAIF ouvre une phase de consolidation. Surveillez trois choses. La cadence de standardisation et la stabilité des versions. La qualité des implémentations côté outils, parce que le protocole n’est utile que si les serveurs MCP sont bien faits. Et l’émergence de patterns sécurité “par défaut”, pour éviter que chaque entreprise réinvente ses garde-fous.
Les retours terrain vont se formaliser. Des événements comme le MCP Dev Summit (New York, avril 2026) seront des points de cristallisation : meilleures pratiques, références, et signaux sur la maturité enterprise. Si vous prenez MCP au sérieux, ce sont ces signaux opérationnels, plus que les annonces, qui doivent guider vos décisions d’industrialisation.
MCP qui rejoint la Linux Foundation marque le passage d’un bon protocole à une brique d’infrastructure : un standard neutre pour brancher des agents IA à vos outils et à vos données, sans verrou propriétaire. La suite se jouera sur la qualité de la gouvernance AAIF, l’industrialisation de la sécurité (permissions, audit, gateways) et la capacité des grands acteurs à converger plutôt qu’à dupliquer. Si vous préparez une stratégie agentique, identifiez dès maintenant vos cas d’usage à forte valeur, cartographiez les accès nécessaires, et testez MCP sur un périmètre maîtrisé pour valider performance, traçabilité et conformité.