MCP expliqué aux entreprises : ce que c'est et comment l'adopter en sécurité

MCP, en termes simples

Une prise standard entre les applications d'IA et les systèmes qu'elles utilisent.

Le Model Context Protocol est un protocole ouvert publié par Anthropic le 25 novembre 2024, avec des SDK et des serveurs de référence pour Google Drive, Slack, GitHub, Git, Postgres et Puppeteer. Auparavant, chaque couple application d'IA et système exigeait sa propre intégration ; avec MCP, un système expose un serveur et tout client compatible peut l'utiliser.

Trois rôles. L'hôte (host) est l'application où travaille l'utilisateur : un assistant conversationnel, un IDE ou votre propre agent. En son sein, un client MCP se connecte à chaque serveur, qui encapsule un système comme une base de données ou une API SaaS. Les serveurs tournent en local, lancés par l'hôte, ou à distance via HTTP, le cas habituel en entreprise.

Un serveur propose des outils (actions que le modèle peut appeler, avec des arguments décrits par un schéma JSON), des ressources (données que l'application peut lire et placer dans le contexte) et des prompts (modèles réutilisables choisis par l'utilisateur). Les outils concentrent l'essentiel de la valeur et du risque, car c'est le modèle qui décide quand les appeler.

Deux ans de spécification : ce qui a changé et quand

Les versions de MCP sont des dates. Cinq révisions comptent pour une entreprise.

La révision 2026-07-28 est la plus importante depuis le lancement, et elle casse la compatibilité : elle supprime les sessions au niveau du protocole et la poignée de main initiale, déprécie Roots, Sampling et Logging, déprécie formellement l'ancien transport HTTP+SSE et fixe une fenêtre de dépréciation d'au moins 12 mois. Les quatre SDK de niveau 1 de l'époque (TypeScript, Python, Go et C#) la prenaient en charge dès sa sortie ; Rust et Ruby ont rejoint ce niveau ensuite, ce qui en faisait six au 30 octobre 2026. Les serveurs bâtis sur des identifiants de session doivent prévoir une migration, plutôt tôt que tard : le blog officiel de MCP situe la révision suivante fin mars 2027.

Les fonctions qui évoluent vite arrivent désormais en extensions officielles : MCP Apps (interfaces interactives dans des iframes isolées, janvier 2026), Tasks (apportée par AWS) et Enterprise Managed Authorization. À AGNTCon + MCPCon (San José, 22 et 23 octobre 2026), Anthropic a annoncé la prise en charge de Tasks dans Claude Code, pour des appels d'outils qui durent des minutes, des heures ou des jours, et indiqué que l'autorisation gérée par l'entreprise fonctionne déjà dans Claude.

Gouvernance, registre et adoption par les grands éditeurs

MCP n'est plus le protocole d'un seul éditeur.

Le 9 décembre 2025, Anthropic a confié MCP à l'Agentic AI Foundation (AAIF), un fonds dédié de la Linux Foundation cofondé par Anthropic, Block et OpenAI, avec MCP, goose et AGENTS.md comme projets fondateurs. Ses membres platine sont AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft et OpenAI. A2A l'a rejointe en août 2026, puis, le 22 octobre, Agent Skills (apporté par Anthropic), Open Responses (OpenAI), OpenEnv (Hugging Face) et OpenSandbox (Alibaba) : dix projets et 305 organisations membres en moins d'un an. MCP garde ses propres mainteneurs et son processus de propositions.

L'adoption a précédé la fondation. OpenAI a annoncé la prise en charge de MCP dans son Agents SDK en mars 2025 puis dans la Responses API en mai ; Google DeepMind a indiqué en avril 2025 que Gemini le prendrait en charge, et Microsoft l'a présenté en mai comme un socle des agents de Windows 11. Au moment du transfert, MCP comptait plus de 97 millions de téléchargements mensuels de SDK et 10 000 serveurs actifs ; en juillet 2026, ses SDK principaux approchaient le demi-milliard de téléchargements par mois. Google a aussi ouvert en préversion publique, en décembre 2025, des serveurs MCP gérés pour Maps, BigQuery, Compute Engine et GKE.

Le registre officiel de MCP a ouvert en préversion le 8 septembre 2025. Les noms de serveurs utilisent des espaces de noms liés à des comptes GitHub ou des domaines vérifiés, une modération communautaire peut bannir les serveurs malveillants ou usurpateurs, et il comptait près de 2 000 entrées en novembre 2025. Il est toujours en préversion mais a vite grandi : un recensement indépendant de LocalCan a compté 43 012 serveurs actifs le 14 octobre 2026, dont 64 % avec une URL distante. Y figurer ne vaut pas revue de sécurité, il vous faut donc votre propre liste blanche.

MCP, A2A, API, Agent Skills et AGENTS.md

Chacune couvre une couche différente, et un même agent en combine souvent plusieurs.

En pratique, elles s'empilent : un agent de support peut suivre une skill décrivant votre procédure de remboursement, consulter le CRM via un serveur MCP et confier une vérification de fraude à l'agent d'une autre équipe via A2A. Pour une application et un modèle, une API maison reste la bonne réponse ; MCP devient rentable quand plusieurs clients d'IA doivent accéder aux mêmes systèmes sous les mêmes contrôles.

Risques de sécurité : ce qui a déjà mal tourné

Chaque serveur MCP est du code ou un service auquel vous confiez le contexte de votre modèle, et souvent des identifiants.

Une prépublication d'un seul auteur (juillet 2026, non relue par des pairs) a recensé plus de 21 000 serveurs MCP exposés sur internet, et 91,8 % des 414 audités n'avaient pas d'OAuth. En septembre 2026, le groupe de renseignement sur les menaces de Google a aussi signalé des copies piégées de serveurs MCP légitimes sur PyPI. Pour aller plus loin : injection de prompt et agents et chaîne d'approvisionnement IA.

Un adjoint confus (confused deputy) est un serveur qui utilise ses propres privilèges pour un utilisateur qui ne devrait pas les avoir, ou qui relaie un token vers un service auquel il n'était pas destiné. La spécification lie chaque token à un serveur par les indicateurs de ressource RFC 8707 (juin 2025) et les identifiants à leur émetteur (juillet 2026) ; vérifier chaque appel au regard des droits de l'utilisateur final reste votre travail.

Les contrôles que nous recommandons

Aucun n'est exotique ; ensemble, ils contiennent la plupart des cas ci-dessus.

• Serveurs sur liste blanche. Seuls les serveurs approuvés par la sécurité, publiés dans un registre privé ; rien n'est installé depuis un lien reçu dans une conversation.
• Versions figées. Figez chaque serveur et relisez les changements de noms et de descriptions d'outils avant toute mise à jour.
• OAuth restreint. Tokens délégués par utilisateur, périmètres étroits, durée de vie courte et aucun relais de token.
• Règles de sortie. Serveurs et agents n'atteignent que les hôtes nécessaires ; les serveurs locaux tournent dans des conteneurs sans accès internet par défaut.
• Confirmation humaine. Les outils destructifs (écrire, envoyer, supprimer, payer) exigent une validation. Les annotations d'outils aident, mais un serveur malveillant peut mal étiqueter les siens : ne vous y fiez que pour vos propres serveurs. En octobre 2026, OpenAI indique que son annuaire de plugins ChatGPT rejette les serveurs qui n'annotent pas tous leurs outils.
• Journalisation. Chaque appel est enregistré avec l'utilisateur, le serveur, l'outil, les arguments et le résultat, en ajout seul, avec une conservation conforme au droit des données personnelles.
• Une passerelle. Un point d'entrée unique qui authentifie, autorise outil par outil, limite le débit et journalise ; depuis juillet 2026, les en-têtes Mcp-Method et Mcp-Name lui permettent de le faire sans analyser le corps des requêtes.

La conception de Microsoft pour Windows (mai 2025) est une bonne référence : un registre central limité aux serveurs conformes à un socle de sécurité, des appels relayés par un proxy de confiance et une approbation de l'utilisateur pour chaque couple client et outil.

Un plan d'adoption pour l'entreprise, étape par étape

D'un premier serveur en lecture seule à une plateforme gouvernée.

1. Choisissez deux ou trois cas d'usage surtout en lecture, avec un responsable et une métrique : fiche client dans le CRM, statut de commande dans l'ERP, recherche dans la documentation interne.
2. Regardez ce que vos éditeurs publient déjà. Les serveurs officiels de vos fournisseurs SaaS et cloud valent généralement mieux que les serveurs communautaires, après revue.
3. Construisez des serveurs internes minces. Le serveur MCP appelle l'API existante de votre CRM ou de votre ERP, qui garde les règles métier, la validation et l'autorisation ; lecture et écriture restent dans des outils séparés.
4. Placez une passerelle en frontal, reliée à votre fournisseur d'identité, avec des tokens par utilisateur, une autorisation outil par outil, des limites de débit et des journaux.
5. Tenez une liste blanche et un registre privé, avec des versions figées et un responsable par serveur.
6. Évaluez et attaquez avant le lancement : précision du choix des outils sur des tâches réelles et cas d'injection cachés dans des documents et des résultats d'outils (voir l'évaluation des LLM).
7. Ouvrez les écritures progressivement, chacune avec confirmation, clés d'idempotence et chemin de retour arrière.
8. Gouvernez-le comme une plateforme d'API : revue trimestrielle des serveurs et des périmètres, politique de dépréciation (la spécification retient 12 mois) et procédure de réponse aux incidents.

En Europe comme en Colombie, les journaux d'appels d'outils contiennent souvent des données personnelles, soumises au RGPD et à la loi 1581 de 2012 : hébergez les serveurs internes et leurs journaux là où votre analyse de protection des données l'exige, et fixez des durées de conservation. Pour les systèmes réglementés, préférez des serveurs qui tournent dans votre propre cloud à des serveurs distants tiers que vous ne pouvez pas auditer.

C'est la séquence que nous recommandons dans nos projets d'agents IA pour les entreprises et de logiciel sur mesure ; le reste de l'architecture est traité dans agents IA en production.