L’IA devient mature pour les entreprises : le Model Context…

L’essentiel en bref

• Gouvernance plutôt qu’initiative isolée : depuis peu, le protocole MCP (Model Context Protocol) est désormais porté par la Linux Foundation sous licence Apache-2.0. Ce changement permet de s’affranchir de la dépendance à un seul éditeur.
• Cycle de vie planifiable : la spécification stable, datée du 25 novembre 2025, est accompagnée d’une version candidate publiée le 28 juillet 2026. Une nouveauté majeure réside dans une période de dépréciation d’au moins douze mois.
• Adoption large : avec neuf SDK officiels, un registre serveur officiel et le soutien annoncé d’OpenAI et de Google, les entreprises disposent désormais d’une couverture suffisante pour une intégration en production.

Articles associés :AWS retire l’infrastructure sous-jacente de ses agents  /  Les agents Cursor Cloud en pratique

Du protocole d’Anthropic à la Linux Foundation

L’étape la plus importante des derniers mois n’est pas technique, mais organisationnelle. Le projet MCP (Model Context Protocol) a été transféré en tant que projet au sein de la Linux Foundation, et les contributions sont désormais sous licence Apache-2.0. Pour un protocole qui régit la connexion entre les modèles d’IA et les données d’entreprise, cette transition représente le véritable test de maturité. Lorsqu’une entreprise construit une intégration, elle ne souhaite pas qu’un fournisseur unique modifie du jour au lendemain les règles du jeu.

Les mainteneurs restent proches de la pratique. Le mainteneur principal est David Soria Parra d’Anthropic, épaulé par Den Delimarsky, issu de l’écosystème Microsoft. Le SDK C# et l’intégration .NET portent clairement l’empreinte de Microsoft. Selon des rapports sectoriels, OpenAI et Google ont annoncé leur soutien à leurs plateformes d’agents. Lorsque les trois plus grands fournisseurs de modèles parlent le même langage d’interface, celle-ci devient un standard.

Pour les services informatiques des entreprises, un mot compte à ce stade : l’indépendance vis-à-vis des éditeurs. Une spécification ouverte, sous licence neutre et gérée par une entité neutre, peut être intégrée dans les décisions d’architecture sans que les changements de licence ou de stratégie d’un éditeur ne remettent en cause l’ensemble de l’infrastructure.

Ce que signifie concrètement « prêt pour l’entreprise »

La maturité ne se mesure pas à l’étendue des fonctionnalités, mais à la prévisibilité d’un protocole dans le temps. C’est précisément ce que le MCP a démontré récemment. La spécification stable du 25 novembre 2025 sert aujourd’hui de base aux équipes pour leurs développements. La prochaine version, disponible depuis fin mai sous forme de version candidate, est datée du 28 juillet 2026.

Un élément nouveau et déterminant a été introduit : le cycle de vie. Les fonctionnalités passent par des états clairement définis, allant d' »actif » à « déprécié » puis « supprimé ». Une fonctionnalité dépréciée reste disponible pendant au moins douze mois. Pour une intégration en production, cela fait toute la différence entre une planification sereine et une course effrénée à chaque mise à jour.

S’ajoute à cela la couverture linguistique. Neuf SDK officiels couvrent Python, TypeScript, Java, Kotlin, C#, Go, Rust, Swift et Ruby. Une pile technologique d’entreprise dispose ainsi presque toujours d’une connectivité prise en charge, sans avoir à recourir à des solutions artisanales communautaires.

Le Registre et le problème de confiance

Avec la maturité vient un nouveau chantier. Depuis le 8 septembre 2025, il existe un Registre MCP officiel en version Preview, et l’API a été figée à la version v0.1 le 24 octobre. Son objectif ? Devenir l’équivalent des registres de paquets pour les langages de programmation : un point central où l’on découvre et intègre des serveurs.

Mais le MCP hérite ainsi de leur problème central. Un registre rempli de serveurs qui connectent des modèles à des systèmes réels représente une cible de choix. Intégrer un serveur manipulé ouvre la porte à un modèle de langage pour accéder à des données et exécuter des actions. Les attaques sur la chaîne d’approvisionnement des derniers mois dans l’écosystème npm illustrent bien les risques encourus. Pour les serveurs MCP, la même vigilance s’impose.

Il n’est pas anodin que des entreprises axées sur la sécurité siègent au groupe de travail sur le Registre. La question de savoir à qui une entreprise fait confiance dans ce registre n’est pas un détail périphérique. Elle doit figurer au cœur de toute implémentation du MCP.

Ce que les équipes IT devraient évaluer dès maintenant

Le MCP (Model Context Protocol) est désormais à un stade où une évaluation sérieuse s’impose. Quatre questions guident cette décision.

1. Curater les serveurs. Tous les serveurs issus du registre ne conviennent pas à la production. Une entreprise a besoin de sa propre liste de serveurs validés et approuvés, plutôt que d’un accès ouvert à l’ensemble.
2. Anticiper les dépréciations. Le cycle de vie de douze mois invite à planifier les migrations à l’avance. Une surveillance active des états permet d’éviter toute surprise liée aux mises à jour.
3. Clarifier la confiance dans le registre. L’origine, la maintenance et les autorisations de chaque serveur intégré doivent être documentées. Un serveur doté de droits étendus nécessite la même vérification qu’une nouvelle dépendance dans le code.
4. Choisir le SDK. Le langage de la stack technique détermine le SDK à adopter. Une intégration officiellement maintenue est préférable à une solution maison, car elle suit automatiquement le cycle de vie.

Stand improvisé contre déploiement d’entreprise

L’évolution des derniers dix-huit mois peut se résumer en quelques points clés.

Ce que cela implique en pratique

Le protocole MCP (Model Context Protocol) a franchi le pas, passant d’une simple expérimentation intéressante à une base planifiable. La gouvernance neutre écarte l’un des principaux arguments des sceptiques, tandis que le cycle de vie rend les intégrations maintenables. Le protocole devient ainsi une option que les comités d’architecture peuvent sérieusement envisager.

Le reste relève du savoir-faire. Aujourd’hui, ceux qui construisent avec MCP tirent le meilleur parti de ce protocole en traitant le registre (registry) avec la même prudence que toute autre chaîne d’approvisionnement. La maturité du protocole ne transfère pas la responsabilité, elle la rend simplement planifiable. C’est précisément à ce stade que ce qui n’était qu’une tendance se transforme en une décision d’infrastructure.

Questions fréquentes

Source de l’image : générée par IA (Juli 2026)