Le problème que MCP a été conçu pour résoudre
Un modèle de langage, seul, ne sait que générer du texte. Pour qu'il agisse sur une base de données, un dépôt de code ou un CRM, il faut lui construire une connexion. Avant l'apparition du Model Context Protocol, cette connexion s'écrivait à la main pour chaque paire modèle-outil. Le raisonnement est simple : avec M modèles d'IA et N systèmes à connecter, une organisation finit par maintenir M multiplié par N intégrations distinctes. Pour une configuration modeste de trois modèles et dix outils, cela représente déjà une trentaine d'intégrations à faire vivre, chacune susceptible de casser au moindre changement d'un côté ou de l'autre.
MCP transforme ce problème M fois N en un problème M plus N : chaque système expose ses capacités une seule fois via un serveur MCP, et chaque application d'IA n'a qu'un seul protocole à parler pour les consommer toutes. C'est cette économie d'échelle, plus que la technologie elle-même, qui explique la vitesse d'adoption du standard.
Une architecture en trois rôles
Le protocole repose sur trois participants. L'hôte est l'application que l'utilisateur manipule directement : un assistant, un environnement de développement, une plateforme d'agents. Le client vit à l'intérieur de l'hôte et gère la connexion isolée vers chaque serveur. Le serveur, lui, ne contient aucun modèle : il expose des capacités et applique les règles de permission propres au système qu'il représente.
| Rôle | Fonction | Exemple |
|---|---|---|
| Host | Application avec laquelle l'utilisateur interagit, intègre le modèle de langage | Un IDE, un assistant, une plateforme d'agents |
| Client | Composant interne à l'hôte qui gère la connexion à un serveur donné | Un client par serveur connecté |
| Server | Expose les capacités d'un système, applique les permissions, ne contient pas de modèle | Un connecteur vers une base de données, un dépôt de code, un CRM |
Trois types de capacités circulent entre client et serveur. Les tools sont des actions exécutables, comme créer un ticket ou lancer une requête. Les resources donnent un accès en lecture à des données statiques, que l'hôte choisit ou non d'injecter dans le contexte. Les prompts sont des modèles d'instructions réutilisables, par exemple un gabarit de revue de code. Dans la pratique, des clients comme OpenCode permettent de déclarer un serveur MCP local ou distant en quelques lignes de configuration, avec une authentification OAuth gérée automatiquement, ce qui illustre la simplicité de branchement recherchée par le protocole.
De projet Anthropic à standard porté par la Linux Foundation
Anthropic a créé le Model Context Protocol et l'a rendu open source en novembre 2024. L'adoption a été rapide : OpenAI l'intègre en mars 2025, Google confirme le support de MCP pour Gemini le mois suivant, Microsoft suit également. Mi-2025, l'écosystème compte déjà des milliers de serveurs communautaires et éditeurs, couvrant GitHub, Slack, PostgreSQL, Docker, Kubernetes et plusieurs centaines d'autres outils recensés dans un registre public.
En décembre 2025, Anthropic transfère la gouvernance de MCP à l'Agentic AI Foundation, un fonds dirigé placé sous l'égide de la Linux Foundation et co-fondé par Anthropic, Block et OpenAI. Le protocole rejoint ainsi le portefeuille d'infrastructures ouvertes de la fondation, aux côtés d'autres projets largement utilisés dans l'industrie du logiciel. Ce changement de gouvernance vise à garantir que MCP reste indépendant d'un seul éditeur.
L'adoption se lit aussi dans les chiffres de téléchargement des kits de développement. Le protocole démarre autour de cent mille téléchargements mensuels de ses SDK en novembre 2024. En mars 2026, les SDK Python et TypeScript combinés atteignent 97 millions de téléchargements par mois. En juillet 2026, les SDK dits de premier rang approchent les cinq cents millions de téléchargements mensuels, et les SDK TypeScript et Python franchissent chacun le milliard de téléchargements cumulés. La spécification elle-même, publiée sous licence MIT et créée par David Soria Parra et Justin Spahr-Summers chez Anthropic, rassemble plusieurs milliers d'étoiles sur son dépôt public.
La version 2026-07-28 : un socle sans état pour tenir la charge
Publiée fin juillet 2026, la nouvelle spécification transforme le cœur du protocole, jusqu'ici bidirectionnel et à état, en un échange requête-réponse sans état. L'échange d'initialisation et l'identifiant de session disparaissent : chaque requête porte désormais sa propre version de protocole et son identité client, ce qui permet à n'importe quelle requête d'atterrir sur n'importe quelle instance derrière un simple répartiteur de charge round-robin, sans stockage partagé.
| Avant la version 2026-07-28 | Depuis la version 2026-07-28 |
|---|---|
| Session ouverte via un échange initialize/initialized | Chaque requête est autonome, session optionnelle |
| Flux bidirectionnel maintenu ouvert pour les requêtes du serveur | Multi Round-Trip Requests (MRTR) : le serveur redemande via une nouvelle requête |
| Routage basé sur l'analyse du corps JSON | Routage sur les en-têtes HTTP Mcp-Method et Mcp-Name |
| Enregistrement dynamique du client (DCR) comme norme | Migration vers les documents de métadonnées client (CIMD), DCR déprécié |
Parmi les autres évolutions notables : les résultats de listes d'outils, de prompts et de ressources deviennent mettables en cache, grâce à des indicateurs de durée de vie et de portée. L'extension Tasks, contribuée par AWS, sort du cœur expérimental pour permettre des agents fiables et de longue durée. Côté autorisation, la validation de l'émetteur selon la RFC 9207 vient combler une faille de confusion entre serveurs d'autorisation. Enfin, une politique de dépréciation formelle impose désormais une fenêtre minimale de douze mois avant le retrait d'une fonctionnalité, de quoi planifier les migrations plutôt que les subir.
Ce que cela change pour les entreprises françaises en quête d'outils interconnectés mais souverains
Le caractère ouvert et agnostique du protocole est ce qui intéresse le plus une entreprise française qui multiplie les fournisseurs de modèles. Un serveur MCP écrit une fois pour votre outil de ticketing ou votre base documentaire fonctionne indifféremment avec un client Claude, un client GPT ou un agent construit sur un modèle open source. Changer de modèle, ou en faire coexister plusieurs, ne suppose plus de reconstruire l'intégration : c'est précisément ce qui affaiblit la dépendance à un seul éditeur d'IA.
Mais le protocole ne dit rien de l'endroit où transitent les données, ni des règles de conformité applicables. La spécification standardise l'accès aux outils, elle ne décide pas des politiques de gouvernance de l'entreprise qui la déploie. C'est là que la question de la souveraineté reste entière : connecter un agent à des dizaines de modèles hébergés par des fournisseurs étrangers, via des serveurs MCP internes ou tiers, implique de savoir précisément ce qui part, vers qui, et sous quelle forme. Des plateformes multi-modèles françaises comme Moon AI, qui donne accès à plus de soixante-dix modèles sous un abonnement unique, illustrent cette tension entre interconnexion et maîtrise des données : le mécanisme Moon Blur remplace les données personnelles par des jetons avant leur envoi aux modèles tiers, puis les rétablit au retour. Ce procédé étant réversible, il s'agit d'une pseudonymisation au sens de l'article 4-5 du RGPD, non d'une anonymisation. L'application et le stockage sont hébergés chez OVHcloud, à Strasbourg et à Roubaix, mais les requêtes adressées aux modèles tiers partent bien chez leurs fournisseurs respectifs, après cette étape de pseudonymisation. C'est ce type de couche que doit ajouter toute organisation qui veut tirer parti de l'interopérabilité de MCP sans perdre la visibilité sur ses données.
Sécurité : la vigilance ne se délègue pas au protocole
Standardiser l'accès aux outils standardise aussi la surface d'attaque. Des chercheurs indépendants ont documenté en 2025 des vulnérabilités dans des serveurs MCP communautaires, notamment des risques d'injection de prompt, des jetons trop largement autorisés et des cas d'injection de commande dans des serveurs mal construits. D'autres analyses pointent des risques voisins : l'injection de prompt via le contenu renvoyé par un outil, qui peut manipuler le modèle pour qu'il appelle d'autres outils, l'empoisonnement d'outils par un serveur malveillant qui imite un nom de confiance, et l'accès excessif lorsqu'un serveur expose des capacités d'écriture à un agent qui n'a besoin que de lecture. Des failles liées à des configurations par défaut ont également été signalées, ce qui invite à traiter un serveur MCP tiers avec la même rigueur qu'une dépendance logicielle classique.
La spécification elle-même impose que l'hôte obtienne un consentement explicite de l'utilisateur avant d'invoquer un outil. Au-delà de cette exigence minimale, les recommandations qui reviennent le plus souvent sont le moindre privilège par serveur, la vérification systématique des serveurs tiers avant déploiement, l'approbation humaine pour les actions conséquentes comme une écriture, une suppression ou un paiement, et la journalisation complète de chaque appel d'outil, de ses paramètres et de son résultat.
Questions fréquentes
MCP remplace-t-il les API existantes de mon entreprise ?
Non. MCP standardise la façon dont une application d'IA découvre et utilise des capacités que les API continuent de fournir. La plupart des serveurs MCP sont de fines couches posées sur des API existantes, auxquelles elles ajoutent des descriptions lisibles par un modèle et un contrôle des permissions.
Une entreprise française doit-elle héberger ses propres serveurs MCP ?
Les sources ne l'imposent pas, mais elles recommandent de privilégier des serveurs officiels ou auto-hébergés plutôt que des serveurs communautaires non vérifiés, en particulier pour l'accès à des données sensibles. Pour un système interne avec une API correcte, exposer un serveur MCP scopé représente typiquement un projet de quelques jours à quelques semaines, l'essentiel du travail portant sur la gouvernance : quoi exposer, à qui, avec quelle approbation et quelle journalisation.
MCP a-t-il un impact sur le choix du modèle d'IA à utiliser ?
Oui, dans le sens où il réduit la dépendance à un fournisseur unique. Un serveur MCP écrit une fois reste utilisable par n'importe quel client compatible, quel que soit le modèle derrière. Cela permet de changer ou de combiner des modèles sans reconstruire les intégrations, ce qui protège l'investissement d'intégration plutôt que de le lier à un seul vendeur.
Quels sont les risques de sécurité à connaître avant de déployer MCP en entreprise ?
Les risques documentés portent sur l'injection de prompt via le contenu renvoyé par un outil, l'empoisonnement d'outils par un serveur qui imite un nom de confiance, l'octroi de permissions trop larges, et des failles de configuration par défaut dans certains serveurs tiers. Les mesures recommandées sont le moindre privilège, la vérification des serveurs avant usage, l'approbation humaine pour les actions sensibles et la journalisation complète des appels.
Transparence. Cet article a été rédigé par un système d'intelligence artificielle à partir des sources listées ci-dessous, puis vérifié fait par fait par un second système avant publication. Il n'a pas fait l'objet d'une relecture humaine préalable. Les chiffres et citations proviennent des sources ; en cas d'écart, la source fait foi.
Sources. Article rédigé à partir des publications suivantes, consultées le 02/08/2026. En cas d'écart, la source fait foi. Signalez toute inexactitude à contact@stellarrstudio.com.
- https://www.cridutroll.fr/le-protocole-mcp-qui-transforme-les-interactions-des-ia-avec-le-monde-reel/
- https://blog.modelcontextprotocol.io/posts/2026-07-28/
- https://github.com/modelcontextprotocol/modelcontextprotocol
- https://www.techrev.us/blog/model-context-protocol-what-mcp-means-for-enterprise-ai/
- https://opencode.ai/docs/mcp-servers/
- https://towardsdatascience.com/mcp-explained-how-modern-ai-agents-connect-to-the-real-world/