Le sigle MCP circule depuis plusieurs mois dans les discussions techniques, souvent cité, rarement expliqué. En rendez-vous, la question revient sous une forme très concrète : « on nous parle de MCP, est-ce que c'est un produit qu'on doit acheter ? ». Non. C'est un protocole, et la nuance change tout ce qui suit.
Cet article pose la définition, montre ce qu'un serveur MCP expose réellement, situe le protocole par rapport à une API, à un RAG et à un agent, et dit surtout ce qu'il ne règle pas.
Le problème que le protocole cherche à résoudre
Un modèle de langage sait raisonner sur ce qu'on lui donne. Il ne sait rien de votre chiffre d'affaires du mois dernier, de vos encours clients ou de l'avancement de vos chantiers. Ces informations existent, elles sont dans une base, un ERP ou un CRM, mais le modèle n'y a aucun accès.
Jusqu'ici, chaque équipe résolvait ce problème à sa façon. On écrivait un connecteur maison pour brancher tel modèle sur telle base, puis un deuxième pour un autre modèle, puis un troisième quand l'outil métier changeait d'API. Chaque combinaison demandait son propre développement, et rien ne se réutilisait.
Le Model Context Protocol, publié par Anthropic et repris depuis par d'autres acteurs, standardise cette liaison. Un serveur écrit une fois expose ses capacités selon un format commun, et n'importe quel client compatible peut s'y brancher. C'est la logique qui a fait le succès des standards réseau : on cesse de recoder l'interface à chaque fois.
Ce qu'est un serveur MCP, concrètement
Un serveur MCP est un composant logiciel installé de votre côté, dans votre périmètre, qui se place entre vos systèmes et l'IA. Il ne stocke rien et ne remplace rien. Il traduit.
Quand un utilisateur pose une question en français depuis Claude, ChatGPT, Mistral ou Gemini, le client interroge le serveur pour savoir ce qui est disponible. Le serveur répond avec une liste précise de ce qu'il accepte de montrer. Le modèle choisit dans cette liste, le serveur exécute la requête correspondante et renvoie le résultat.
Le point important est là : le modèle ne part pas en exploration dans votre système d'information. Il ne voit que ce que le serveur a été configuré pour exposer. Si une table n'a pas été déclarée, elle n'existe pas de son point de vue.
Les trois choses qu'un serveur expose
Le protocole distingue trois catégories, et il vaut la peine de les connaître parce qu'elles n'ont pas les mêmes implications de sécurité.
- Les ressources. De la donnée en lecture, que le modèle peut consulter. Une vue sur vos projets, la liste de vos clients actifs, l'historique d'un compte. Rien n'est modifié.
- Les outils. Des actions que le modèle peut déclencher. Créer un ticket, mettre à jour un statut, envoyer une notification. C'est la catégorie qui demande un arbitrage explicite, parce qu'elle écrit dans vos systèmes.
- Les modèles de requête. Des formulations préparées à l'avance pour les questions récurrentes, qui évitent au modèle de réinventer une requête complexe à chaque fois.
Dans la majorité des projets que nous livrons, la première mise en service ne comporte que des ressources. Aucun outil, donc aucune écriture possible. C'est un choix de prudence qui permet de mesurer l'usage réel avant d'ouvrir quoi que ce soit.
MCP, API, RAG, agent : qui fait quoi
Ces quatre termes se croisent dans les mêmes conversations et finissent par se confondre. Ils ne répondent pourtant pas à la même question.
| Brique | Ce qu'elle fait | Quand elle est le bon choix |
|---|---|---|
| API | Expose des fonctions à un programme, dans un format pensé pour des développeurs | Quand c'est une application, pas un modèle, qui consomme la donnée |
| MCP | Expose de la donnée et des actions à un modèle de langage, dans un format standardisé | Quand la réponse est dans une base, un ERP ou un CRM |
| RAG | Indexe des documents et retrouve le passage pertinent | Quand la réponse est dans un PDF, un contrat ou une procédure |
| Agent | Enchaîne plusieurs étapes pour accomplir une tâche | Quand il faut agir, pas seulement répondre |
La formule que nous utilisons en rendez-vous tient en une phrase : du RAG quand la réponse est dans un document, un MCP quand elle est dans une base. Et les deux se combinent régulièrement dans le même projet, parce qu'une entreprise a les deux.
Quant à l'agent, il ne s'oppose pas au MCP, il s'appuie dessus. Un agent IA a besoin de savoir sur quoi il agit ; le serveur MCP est précisément ce qui le lui expose. De la même façon, un copilote intégré au poste de travail est une interface, pendant que le MCP est la couche d'accès à la donnée derrière cette interface.
À quoi ça sert dans une entreprise
Trois situations reviennent régulièrement, et elles n'ont pas grand-chose à voir avec les démonstrations spectaculaires qu'on voit passer.
Une base historique que plus personne ne sait interroger
C'est le cas le plus fréquent. Une base alimentée depuis dix ou quinze ans, dans un schéma dont la logique tenait dans la tête de deux développeurs, dont l'un est parti. L'information est là. La sortir demande un ticket, une disponibilité et deux jours.
Un serveur MCP posé en lecture par-dessus cette base, avec des vues portant le vocabulaire de l'entreprise plutôt que les noms de colonnes d'origine, redonne l'accès aux équipes métier sans passer par le développement.
Une donnée éclatée entre dix écrans
L'ERP porte la facturation, le CRM porte les opportunités, l'outil interne porte les tickets. Chaque écran est correct pris isolément. Personne ne les croise, parce que croiser trois écrans à la main coûte une demi-journée.
Une question du type « quels clients ont ouvert plus de tickets ce trimestre que l'an dernier, et quel est leur encours ? » devient formulable directement, sans reconstruire un tableau croisé à chaque fois.
Un contrôle qualité de la donnée qui n'arrive jamais
Doublons, montants aberrants, champs obligatoires laissés vides, dates incohérentes. Tout le monde sait que ça existe, personne n'a le temps de chercher. Le sujet remonte à l'occasion d'un audit ou d'une clôture, quand il est tard.
Une fois la donnée interrogeable en langage naturel, ce contrôle cesse d'être un chantier et devient une question qu'on pose. C'est souvent l'usage que les équipes découvrent après coup, alors qu'il ne figurait pas dans le cadrage initial.
Ce que le protocole ne règle pas
Un article honnête sur le sujet doit s'arrêter ici un moment, parce que les limites conditionnent la réussite du projet plus que la technologie elle-même.
Le MCP ne répare pas une donnée fausse. Si deux services saisissent la même information différemment, l'exposer plus facilement ne fera que rendre l'incohérence plus visible. C'est parfois une bonne chose, mais il faut s'y attendre plutôt que le découvrir en comité de direction.
Il ne dispense pas de comprendre le schéma. Exposer une base mal documentée sans avoir reconstitué sa cartographie produit des réponses plausibles et fausses. Cette phase de cartographie représente souvent la part la plus longue du projet, et c'est normal.
Il ne remplace pas un arbitrage sur les droits. Décider qui voit quoi reste une décision d'entreprise. Le protocole permet de la mettre en œuvre proprement, il ne la prend pas à votre place, et il ne faut pas laisser cet arbitrage au modèle.
Il ne rend pas la question toujours bien posée. Une demande ambiguë sur une base volumineuse peut produire une requête coûteuse ou un résultat hors sujet. C'est la raison pour laquelle on plafonne la volumétrie et on borne les vues, plutôt que d'ouvrir la base entière.
Les questions à poser avant de se lancer
Si le sujet vous intéresse pour votre entreprise, quatre questions suffisent à savoir si vous êtes prêt, et elles se posent en interne avant de consulter qui que ce soit.
- Disposez-vous d'un accès en lecture à la base ou à l'outil concerné, et savez-vous qui peut l'accorder ?
- Existe-t-il une documentation du schéma, même partielle, même ancienne ?
- Pouvez-vous citer cinq questions précises que vos équipes posent régulièrement et qui restent sans réponse rapide ?
- Savez-vous quels périmètres devraient rester fermés, et à qui ?
Si les quatre réponses existent, un premier serveur sur un périmètre restreint est un projet raisonnable. Si la troisième reste floue, le besoin n'est probablement pas encore mûr, et un audit préalable sera plus utile qu'un développement.
En résumé
Le MCP n'est ni un produit, ni une solution miracle. C'est une façon standardisée de montrer à un modèle de langage une partie choisie de votre système d'information, sans déplacer la donnée et sans lui donner plus de droits que nécessaire.
Sa valeur ne tient pas à la technologie, qui est relativement simple, mais au travail de cadrage qui la précède : quelles vues, pour quels rôles, avec quelles limites. C'est là que se joue la différence entre un serveur utile et une démonstration qui impressionne trois semaines.
Pour voir comment nous conduisons ce type de mission, du premier regard sur le schéma jusqu'à la maintenance, la page serveur MCP et interrogation des données en langage naturel détaille la méthode et les garde-fous que nous appliquons.
