Prenons un exemple : une entreprise veut fluidifier son processus commercial, elle souhaite qu’un assistant IA rédige automatiquement un compte-rendu à partir des notes prises dans son CRM après chaque rendez-vous client, puis mette à jour le tableau de suivi tenu sous Excel par l’équipe commerciale.
Cette tâche est très simple pour un humain, mais sans MCP, elle peut pourtant vite devenir compliquée pour un agent IA.
Pour que l’assistant IA accède à ces deux outils, il faut en théorie construire deux connexions distinctes, l’une pour lire et écrire dans le CRM, l’autre pour agir sur le fichier Excel, chacune avec son propre format d’échange et sa propre maintenance dans le temps. Ajouter un troisième outil à ce schéma suppose de construire une troisième connexion, et ainsi de suite à chaque nouvel outil que l’on voudrait relier.
Une telle mission pourrait rapidement mobiliser une petite équipe de développeurs web backend à plein temps.
Résultat : l’entreprise se retrouve à financer des développements spécifiques pour brancher l’IA à chacun de ses outils. Impossible d’obtenir un retour sur investissement positif, et l’IA reste cantonnée à des usages très limités.
Le Model Context Protocol, que l’on désigne presque toujours par son sigle MCP, est la réponse qu’Anthropic a proposée à ce problème dès 2024, sous la forme d’un standard ouvert.
Que fallait-il faire avant l’existence de MCP ?
Dans son annonce, Anthropic décrit le problème auquel l’entreprise cherchait à répondre en des termes très concrets : “chaque nouvelle source de données nécessite sa propre implémentation personnalisée, ce qui rend les systèmes véritablement connectés difficiles à mettre à l’échelle”.
Le problème n’était donc pas que les modèles de langage manquaient de capacités de raisonnement, mais que la plomberie nécessaire pour les relier au reste du système d’information d’une entreprise se multipliait à chaque nouvelle combinaison entre un assistant et un outil.
Avec dix outils et trois assistants IA différents à connecter, une organisation pouvait se retrouver à financer jusqu’à trente intégrations distinctes, chacune à maintenir séparément.
C’est ce travail de connexion, et non la capacité de raisonnement des modèles, que MCP a été conçu pour simplifier : proposer une manière unique de décrire comment un assistant IA peut accéder à des données et déclencher des actions, quel que soit l’assistant et quel que soit l’outil de l’autre côté.
Ce que le protocole MCP standardise concrètement
La documentation officielle du protocole résume son rôle par une comparaison désormais reprise presque partout : MCP fonctionnerait “comme un port USB-C pour les applications IA”.
De la même façon que l’USB-C a remplacé une multitude de connecteurs propriétaires par un seul standard physique, MCP propose un format unique pour connecter un assistant IA à des systèmes externes, plutôt qu’un branchement sur-mesure par combinaison.
Concrètement, l’application IA que la personne utilise au quotidien (Claude Desktop, ChatGPT, ou tout autre assistant capable de se connecter à des outils externes) se connecte au serveur MCP de l’outil qu’elle souhaite utiliser : le serveur MCP est le programme, fourni par cet outil, qui rend ses données ou ses actions accessibles à l’assistant.
Dans l’exemple pris plus haut, cela signifie que l’assistant IA se connecte, d’un côté, au serveur MCP proposé par le CRM, et de l’autre, à celui proposé par Excel, si chacun de ces outils met un MCP à disposition.
Comme cette connexion doit rester active tant que l’assistant échange avec l’outil, l’application IA crée, pour chaque serveur auquel elle se connecte, un client MCP dédié : un client pour la connexion au CRM, un autre pour la connexion à Excel.
C’est cette application IA elle-même, celle que la personne utilise au quotidien, que le vocabulaire du protocole désigne par le terme d’hôte MCP (MCP host) : elle pilote la conversation avec l’utilisateur et gère, en arrière-plan, l’ensemble de ces connexions.
Pour reprendre l’exemple du départ : l’hôte MCP est l’application IA elle-même, les deux clients MCP sont les deux connexions qu’elle établit, et les deux serveurs MCP sont ceux fournis respectivement par le CRM et par Excel. Ajouter un troisième outil reviendrait à ajouter un troisième client relié à un troisième serveur, sans toucher aux deux premiers.
Principaux éléments d’une architecture MCP (source : https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture)
Les trois briques que propose un serveur MCP
Le protocole définit trois types d’éléments qu’un serveur peut mettre à disposition d’un assistant IA.
Les outils (tools) sont des actions que l’assistant peut déclencher : interroger une base de données, envoyer une requête à une API, effectuer un calcul. Les ressources (resources) sont des données mises à disposition pour donner du contexte à l’assistant, comme le contenu d’un fichier ou le résultat d’une requête. Les invites (prompts) sont des modèles de formulation réutilisables, pensés pour structurer certains types d’interactions avec le modèle de langage.
Cette distinction a une conséquence pratique importante : un même serveur MCP peut à la fois donner accès à de l’information (les ressources) et permettre d’agir sur un système (les outils), le tout décrit dans un format que n’importe quel hôte compatible avec le protocole sait interpréter, sans développement spécifique à cet hôte.
Un framework tel que mcp-use facilite la création de serveurs MCP par les développeurs JavaScript et Python.
Pourquoi le standard MCP s’est diffusé aussi rapidement
Un protocole ouvert n’a de valeur que si plusieurs acteurs l’adoptent. C’est ce qui s’est produit dans le cas de MCP.
Dès l’annonce initiale, Anthropic citait des entreprises comme Block ou Apollo parmi les premiers utilisateurs, et des éditeurs d’outils de développement comme Zed, Replit, Codeium ou Sourcegraph parmi les premiers partenaires techniques.
Depuis, le protocole a été adopté au-delà de l’écosystème Anthropic : des environnements de développement comme Visual Studio Code ou Cursor, mais aussi des assistants concurrents, l’ont intégré à leur tour. Le WebMCP permet même de transformer un site web en serveur MCP exploitable par les IA des navigateurs.
Ce type de dynamique n’est pas propre à l’intelligence artificielle. Un standard ouvert, dès lors qu’il résout un problème réel et qu’il n’avantage pas exclusivement son créateur, tend à être adopté plus largement qu’une solution propriétaire, parce que chaque nouvel adoptant réduit le coût d’adoption pour les suivants : un outil qui expose un serveur MCP devient utilisable par tous les assistants compatibles, et non par un seul.
Ce que cela change pour une organisation sans équipe de développement dédiée
Pour une entreprise qui n’a pas vocation à développer elle-même des intégrations sur mesure, l’intérêt de ce standard tient moins à sa mécanique interne qu’à ce qu’il permet d’éviter : financer un développement spécifique à chaque fois qu’elle souhaite connecter un assistant IA à un nouvel outil métier. Dans un contexte où de plus en plus d’éditeurs logiciels proposent leur propre serveur MCP, une organisation peut, en théorie, brancher un assistant sur ses outils existants sans repartir d’une page blanche technique.
Cette perspective mérite cependant d’être nuancée à deux niveaux : d’une part, la question de savoir dans quels cas cet usage a réellement un intérêt pour une organisation, et d’autre part celle des risques que soulève le fait de donner à un assistant IA un accès direct à des données et à des systèmes internes.
Un protocole, mais pas une garantie de résultat
MCP répond à un problème d’interopérabilité technique, pas à une question de jugement ou de fiabilité des assistants IA eux-mêmes.
Standardiser la façon dont un assistant se connecte à un outil ne dit rien de la pertinence des actions qu’il choisira d’y effectuer, ni des précautions à prendre avant de lui ouvrir cet accès. Comprendre ce que le protocole fait, et surtout ce qu’il ne fait pas, est un préalable utile avant d’évaluer s’il a sa place dans l’organisation d’une entreprise.
