Le Model Context Protocol (MCP) est un standard ouvert qui connecte les modèles de langage à des outils et à des données externes. Avant MCP, chaque intégration entre un assistant IA et un service était du code sur mesure. MCP remplace ce bricolage par un contrat universel : un serveur MCP est écrit une fois, et n'importe quel client compatible peut l'utiliser. Ce guide explique sans jargon ce qu'est MCP, le problème concret qu'il résout, son architecture et ses trois primitives. Public visé : développeur ou ingénieur qui veut comprendre MCP avant de l'utiliser ou d'en construire un serveur.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Comprendre le problème que MCP résout — et pourquoi il est apparu.
- Distinguer les trois rôles de l'architecture MCP : hôte, client, serveur.
- Connaître les trois primitives : tools, resources, prompts.
- Situer MCP par rapport au function calling classique.
- Identifier les pièges courants avant de vous lancer.
Qu'est-ce que le Model Context Protocol
Section intitulée « Qu'est-ce que le Model Context Protocol »Un modèle de langage, seul, ne sait que générer du texte. Il ne peut pas lire vos fichiers, interroger une base de données ni appeler une API. Pour qu'il agisse sur le monde réel, il faut le connecter à des outils. Le MCP est le protocole qui standardise cette connexion.
Créé par Anthropic et open-sourcé en novembre 2024, MCP définit un langage commun entre deux camps : d'un côté les applications d'IA (un assistant, un agent, un IDE), de l'autre les services (un système de fichiers, un dépôt Git, une API métier). Tout service qui « parle MCP » devient utilisable par toute application qui « parle MCP », sans code d'intégration spécifique.
Pourquoi MCP : le problème N×M
Section intitulée « Pourquoi MCP : le problème N×M »Pour saisir l'intérêt de MCP, il faut voir le problème qu'il y avait avant.
Imaginez N applications d'IA (Claude Desktop, un IDE, votre agent maison) et M services à connecter (fichiers, Git, Jira, une base PostgreSQL). Sans standard, chaque application doit coder sa propre intégration pour chaque service. Cela fait N × M intégrations à écrire et à maintenir. Cinq applications et dix services, c'est cinquante bouts de code sur mesure, chacun à corriger quand un service change.
MCP transforme ce N × M en N + M. Chaque service écrit un seul serveur MCP. Chaque application écrit un seul client MCP. N'importe quelle application se branche alors sur n'importe quel service. Le service serveur Git écrit une fois fonctionne dans Claude Desktop, dans votre IDE et dans votre agent, sans une ligne de code supplémentaire.
C'est exactement le gain d'un standard : il déplace l'effort de l'intégration point à point vers une interface partagée.
L'architecture : hôte, client, serveur
Section intitulée « L'architecture : hôte, client, serveur »MCP repose sur trois rôles. Les confondre est la première source de malentendus, donc prenons-les un par un.
L'hôte (host) est l'application qui contient le modèle de langage et que l'utilisateur manipule : Claude Desktop, Claude Code, un IDE comme Cursor ou VS Code, ou votre propre agent. C'est l'hôte qui décide quels serveurs utiliser.
Le client (client) est un composant interne à l'hôte. L'hôte crée un client par serveur auquel il se connecte. Chaque client maintient une connexion isolée avec son serveur — un serveur ne voit jamais les autres. Cette isolation est un choix de sécurité.
Le serveur (server) est un programme externe qui expose des capacités : lire des fichiers, lancer des commandes Git, interroger une API. Le serveur ne contient aucun modèle de langage — il fournit seulement des fonctions et des données. C'est la brique réutilisable de l'écosystème.
Les trois primitives : tools, resources, prompts
Section intitulée « Les trois primitives : tools, resources, prompts »Un serveur MCP peut exposer trois types de capacités. Les distinguer permet de bien concevoir un serveur — et de comprendre ce qu'un serveur tiers vous apporte.
Les tools (outils) sont des fonctions que le modèle peut appeler pour agir : créer un fichier, lancer une requête, envoyer un message. Un tool a un nom, une description et des paramètres. C'est la primitive la plus utilisée, car c'est elle qui donne au modèle un pouvoir d'action.
Les resources (ressources) sont des données que l'hôte peut lire pour enrichir le contexte : le contenu d'un fichier, un enregistrement de base, une page de documentation. Contrairement à un tool, une resource ne fait rien — elle fournit du contexte. L'hôte décide quand l'injecter dans la conversation.
Les prompts sont des modèles de prompts réutilisables, paramétrables, que le serveur met à disposition. Par exemple un prompt « résume ce ticket » prêt à l'emploi. C'est la primitive la moins répandue, mais elle évite de réécrire les mêmes instructions partout.
| Primitive | Rôle | Initiative |
|---|---|---|
| Tools | Agir (appeler une fonction) | Le modèle décide |
| Resources | Fournir du contexte (lire une donnée) | L'hôte décide |
| Prompts | Réutiliser des instructions toutes prêtes | L'utilisateur choisit |
Sous le capot, ces échanges utilisent JSON-RPC 2.0, un format de messages simple et éprouvé. Vous n'avez pas à le manipuler à la main : les bibliothèques MCP s'en chargent.
MCP face au function calling classique
Section intitulée « MCP face au function calling classique »Si vous connaissez le function calling des API LLM (décrire des fonctions au modèle pour qu'il les appelle), une question se pose : qu'apporte MCP de plus ?
Le function calling « classique » définit les fonctions dans le code de l'application. Chaque application redéfinit ses fonctions, et ce travail n'est pas réutilisable : les outils de votre agent ne servent qu'à votre agent.
MCP déplace les outils hors de l'application, dans des serveurs autonomes. Les capacités sont découvertes dynamiquement : l'hôte interroge le serveur au démarrage pour savoir ce qu'il propose. Le même serveur sert plusieurs hôtes, évolue indépendamment, et se teste séparément.
Les deux ne s'opposent pas : MCP s'appuie sur le mécanisme de function calling du modèle. Il ne le remplace pas — il le rend standard, réutilisable et découvrable. Le guide Panorama IA situe ces briques les unes par rapport aux autres.
L'écosystème MCP
Section intitulée « L'écosystème MCP »MCP est jeune mais son adoption est rapide. Côté hôtes, on trouve Claude Desktop, Claude Code, et des IDE comme Cursor, VS Code ou Windsurf — sans compter les agents que vous écrivez vous-même.
Côté serveurs, Anthropic et la communauté publient des serveurs prêts à l'emploi : système de fichiers, Git, GitHub, bases de données, outils de recherche. Vous pouvez aussi écrire le vôtre : le guide reShapr montre comment transformer une API existante en serveur MCP.
Pièges et idées fausses
Section intitulée « Pièges et idées fausses »Quelques raccourcis trompeurs reviennent souvent chez ceux qui découvrent MCP.
- « MCP, c'est un modèle d'IA. » Non. MCP est un protocole de communication. Aucun serveur MCP ne contient de modèle ; le modèle est dans l'hôte.
- « Le serveur décide quoi faire. » Non. Le serveur expose et exécute. C'est le modèle qui décide d'appeler un outil.
- « MCP remplace le function calling. » Non. Il le standardise et le rend réutilisable, en s'appuyant dessus.
- « Installer un serveur MCP est sans risque. » Faux. C'est exécuter du code tiers — à traiter comme une dépendance, avec la même prudence.
À retenir
Section intitulée « À retenir »- MCP est un standard ouvert (Anthropic, 2024) qui connecte les LLM aux outils et aux données.
- Il transforme le problème N × M des intégrations sur mesure en N + M grâce à un contrat universel.
- Trois rôles : l'hôte (l'app avec le LLM), le client (un par serveur, isolé), le serveur (les capacités).
- Trois primitives : tools (agir), resources (contexte), prompts (instructions réutilisables).
- MCP ne remplace pas le function calling : il le rend standard et découvrable.
- Un serveur MCP exécute du code — à installer avec la prudence d'une dépendance.