Le MCP en une phrase : le Model Context Protocol est un standard ouvert qu’Anthropic a publié en novembre 2024 pour que n’importe quel modèle d’IA se connecte à tes outils et à tes données par un seul câble, au lieu d’un connecteur sur mesure par intégration. Il baisse le coût de connecter. Il ne baisse pas le coût d’avoir un mauvais processus ni des données sales. C’est toute la thèse — le reste de l’article la démontre sans fumée.
Qu’est-ce que le MCP (Model Context Protocol)
MCP veut dire Model Context Protocol. C’est un protocole ouvert —spécification et code publics— qui définit une façon standard pour une application d’IA de demander du contexte (fichiers, enregistrements d’une base de données, messages) et d’invoquer des actions (outils, fonctions) sur des systèmes externes. L’analogie que tout le monde répète, c’est « l’USB-C de l’IA » : une seule prise pour tout. Elle aide à comprendre et trompe si on la prend au pied de la lettre, car une prise ne répare pas ce qu’il y a au bout du câble. La spécification et les SDK officiels sont dans la documentation du MCP.
Le vrai problème qu’il résout : l’intégration N×M
Avant le MCP, connecter chaque modèle à chaque outil était un connecteur sur mesure. Avec N modèles et M outils, on se retrouve avec N×M intégrations à maintenir, chacune avec son format, son authentification et sa façon de casser. Le MCP transforme ce N×M en N+M : chaque outil expose un serveur MCP une fois, chaque modèle parle MCP une fois, et au milieu il y a un contrat commun. Ce n’est pas magique — c’est ce qu’un chargeur universel a fait pour le tiroir de câbles. L’économie porte sur l’intégration, pas sur le jugement.
| Axe | Sans MCP (connecteurs sur mesure) | Avec MCP |
|---|---|---|
| Coût d’intégration | N×M connecteurs propres | N+M (un protocole) |
| Format | Un différent par outil | JSON-RPC standard |
| Maintenance | Chaque changement casse un connecteur | Le contrat absorbe le changement |
| Réutilisation | Quasi nulle entre projets | Un serveur sert plusieurs clients |
| Ce qu’il ne résout PAS | Le processus et les données | Le processus et les données |
Comment ça marche : client, serveur et trois primitives
L’architecture est client-serveur, inspirée du Language Server Protocol qu’utilisent déjà les éditeurs de code. L’application d’IA joue le rôle de client MCP et ouvre une connexion vers un ou plusieurs serveurs MCP, qui exposent des capacités du monde réel. Les messages voyagent en JSON-RPC 2.0 sur différents transports. Ce qu’un serveur peut offrir se résume à trois primitives :
- Tools (outils) : des actions que le modèle peut invoquer —créer un ticket, consulter une commande, déplacer une ligne—. C’est ce que la plupart entendent par « l’agent fait des choses ».
- Resources (ressources) : des données que le modèle peut lire comme contexte —un document, le résultat d’une requête, un fichier—. Lire, pas agir.
- Prompts : des modèles d’interaction réutilisables que le serveur offre au client pour les tâches répétées.
Il existe des SDK officiels en TypeScript, Python, Java, Kotlin et C#, donc monter un serveur MCP aujourd’hui, c’est une affaire d’heures, pas de semaines. Et voilà le piège confortable : comme c’est facile à monter, on est tenté de croire que le travail est fait alors qu’il vient de commencer.
Qui l’a adopté (et pourquoi ça compte)
Le MCP a vite cessé d’être une affaire d’Anthropic. Tout au long de 2025, il a été adopté nativement par des clients d’OpenAI, Google et Microsoft, entre autres, et en fin d’année Anthropic a fait don du protocole à une fondation sous l’égide de la Linux Foundation, avec ces mêmes acteurs comme membres fondateurs (bilan du premier anniversaire). Un standard tenu par des concurrents plutôt que par un seul propriétaire, c’est justement ce qui le rend pariable : tu ne dépends pas de l’intérêt continu d’une seule entreprise. Pour une entreprise qui décide où investir, cette gouvernance partagée pèse plus que n’importe quelle démo.
Ce qui change vraiment pour les agents d’entreprise
Le concret : la colle entre ton agent et tes systèmes cesse d’être un projet d’intégration par outil et devient une pièce réutilisable. Connecter un agent à ton CRM, ton ERP ou ta base de données ne justifie plus à lui seul un budget à cinq chiffres. C’est réel et c’est bien. On le détaille dans le guide sur connecter un agent d’IA à ton CRM, où le câble compte moins que décider ce que l’agent peut toucher et ce qu’il ne peut pas.
Mais connecter n’est pas construire. Un serveur MCP te donne l’accès ; il manque encore l’agent qui décide bien quoi faire de cet accès, avec ses garde-fous, ses évaluations et son humain dans la boucle là où le jugement compte. Cette partie —celle qui fait vraiment le travail— n’est pas résolue par le protocole, et c’est celle qu’on décortique dans comment construire un agent d’IA qui tourne en production.
Ce qu’un serveur MCP ne répare PAS
C’est là que l’enthousiasme s’écrase contre un vrai mardi. Un serveur MCP connecte le modèle à tes données exactement telles qu’elles sont. Si le processus derrière est un chaos, le MCP te donne un chaos accessible par API — plus vite, pas mieux. Trois fronts que le protocole ne touche pas :
- Le processus. Si personne n’a décidé comment le travail se fait aujourd’hui —qui le touche, où ça bloque, avec quel critère on tranche—, le MCP ne fait qu’automatiser le désordre. Ce diagnostic, c’est la moitié du travail, et c’est ce qui sépare automatiser un processus avec des agents d’acheter de la techno et prier.
- Les données. Un serveur MCP sur des données dupliquées, sans propriétaire et sans définition sert des réponses sûres d’elles et fausses. La qualité de la donnée n’est pas fixée par le protocole ; tu la fixes avant.
- La gouvernance. Ce que l’agent peut lire, ce qu’il peut écrire, qui répond quand il se trompe. Le MCP déplace le contexte ; il ne décide pas les permissions à ta place. Sans cette couche, une prise universelle est aussi un trou universel.
Quand monter un MCP a du sens (et quand c’est du théâtre)
- Tu as cartographié le processus. Tu sais quelle tâche précise l’agent va toucher et quelle métrique devrait bouger. Si ça ne tient pas en deux phrases, ce n’est pas encore l’heure du protocole.
- Tu vas réutiliser la connexion. Un serveur MCP rentabilise quand plusieurs agents ou équipes vont l’utiliser. Pour une intégration unique et jetable, un connecteur direct est parfois plus honnête.
- Tu as décidé la gouvernance. Permissions, limites et responsable avant d’ouvrir le câble, pas après la première frayeur.
- Tu ne le montes pas pour la démo. Si l’objectif est de montrer en réunion qu’« on parle déjà MCP », c’est du théâtre avec un nom technique. Le système se juge un mardi ordinaire, en tournant seul, pas dans la salle.
Autrement dit : le MCP est une très bonne nouvelle pour qui a déjà fait le travail à l’intérieur, et un piège coûteux pour qui croyait que le câble était le problème. On utilise le MCP là où il économise des semaines d’intégration, et on ne l’utilise pas pour maquiller un processus qui n’existe pas encore. Si la douleur, c’est connecter l’IA aux systèmes que tu utilises déjà et la laisser mesurée, c’est de l’infrastructure d’IA pour l’entreprise ; si c’est un cas précis —par exemple mettre de l’IA dans HubSpot sans rien casser—, regarde IA pour HubSpot. Le protocole est le moyen. Le travail, comme toujours, c’est ce qu’on facture.