Serveur MCP : ce que c’est, à quoi ça sert, et pourquoi un service de vérification en propose un

Le problème que MCP résout

Avant, brancher un assistant sur un service extérieur demandait une intégration sur mesure : un développeur écrivait, pour chaque assistant et chaque service, le code qui traduit une demande en appel d’API. Multipliez le nombre d’assistants par le nombre de services et vous obtenez le nombre d’intégrations à écrire, puis à maintenir.

MCP, pour Model Context Protocol, remplace cette multiplication par une addition. Un service publie un serveur MCP une fois ; tout assistant compatible sait s’y connecter. C’est le même principe que le port USB : le fabricant de clavier n’écrit pas un pilote par ordinateur.

Comment ça marche

Un serveur MCP annonce ce qu’il sait faire. L’assistant lui demande la liste, la reçoit, et décide au fil de la conversation d’appeler l’un ou l’autre. Trois notions suffisent à comprendre l’essentiel.

• Les outils. Une action que le serveur sait exécuter, avec un nom, une description en langage courant et la liste de ses paramètres. C’est la description que lit l’assistant pour décider s’il doit l’appeler : elle compte autant que le code derrière.
• Les ressources. Des contenus que le serveur met à disposition, désignés par une adresse. Un fichier, un enregistrement, ou dans notre cas une page web à afficher.
• Les invites. Des modèles de demandes préparés par le serveur, que l’utilisateur peut déclencher directement.

Le dialogue lui-même est du JSON-RPC : des messages nommés, une requête, une réponse. Rien d’exotique, et c’est voulu : le protocole est délibérément ennuyeux pour que n’importe quel langage puisse l’implémenter.

Local ou distant : deux serveurs, deux usages

Un serveur MCP peut tourner à deux endroits, et le choix n’est pas cosmétique : il décide de ce que le serveur peut voir.

Le serveur local lit les fichiers de la machine : on lui donne un chemin, il travaille. Le serveur distant, lui, est joint depuis l’infrastructure de l’éditeur de l’assistant, et non depuis l’appareil de l’utilisateur. Il ne voit donc jamais le disque de personne, ce qui est une bonne chose pour la sécurité et un vrai problème quand le service a justement besoin d’un fichier.

Le cas d’un service de vérification de documents

Vérifier un document suppose de l’avoir. C’est exactement ce qu’un serveur distant ne peut pas obtenir. Et un document déposé dans une conversation ne résout rien : l’assistant en voit le contenu extrait, pas le fichier d’origine, donc il ne peut pas le transmettre tel quel.

L’extension applicative de MCP lève l’obstacle. Un outil peut déclarer une interface, que l’assistant affiche dans une page isolée à l’intérieur de la conversation. Cette page est une vraie page web : elle peut contenir une zone de dépôt. L’utilisateur y glisse son avis d’imposition, la page l’envoie au service, et le verdict remonte dans le fil.

La nuance est importante : ce n’est pas le serveur qui va chercher le fichier, c’est l’utilisateur qui le donne, dans une interface isolée du reste de la conversation. La différence est la même qu’entre une perquisition et un dépôt volontaire.

Ce que l’assistant apporte alors n’est pas la vérification, qui reste faite par le service : c’est le contexte autour. Vous pouvez lui demander d’expliquer un écart, de comparer trois bulletins de salaire au revenu fiscal signé, ou de rédiger la réponse au candidat. Le contrôle cryptographique reste déterministe et vérifiable ; le commentaire, lui, profite du langage.

Ce qu’il faut regarder avant de brancher un serveur MCP

Un connecteur donne à un assistant la capacité d’agir. Quelques questions valent d’être posées avant d’en ajouter un.

• Que reçoit le serveur, exactement ? Un serveur distant ne voit que ce que vous lui envoyez. Un serveur local voit ce que vous lui donnez comme chemin. Dans les deux cas, la question est ce que l’éditeur en fait ensuite, et son engagement de conservation.
• Qui peut l’appeler ? Un connecteur sans authentification est ouvert à tous, ce qui convient à une lecture gratuite et sans risque, moins à une opération coûteuse ou sensible.
• Que peut-il faire ? Un outil qui lit est sans danger. Un outil qui écrit, envoie ou supprime mérite qu’on lise sa description avant de l’autoriser.
• Les descriptions des outils sont lues par le modèle. Un serveur malveillant pourrait tenter d’y glisser des instructions. Les hôtes s’en prémunissent, mais n’ajoutez que des connecteurs dont vous connaissez l’éditeur.

Questions fréquentes

MCP, qu’est-ce que c’est ?

Le Model Context Protocol est une norme ouverte qui permet à un assistant conversationnel d’utiliser des services extérieurs : lire des données, appeler une API, exécuter une action. Le service publie un serveur MCP une seule fois, et tout assistant compatible sait s’y connecter, sans intégration sur mesure.

Quelle différence entre un serveur MCP local et distant ?

Un serveur local tourne sur votre machine et peut donc lire vos fichiers ; il s’installe en une commande et s’utilise dans les applications de bureau et les éditeurs de code. Un serveur distant est joint par l’éditeur de l’assistant depuis ses propres serveurs : il s’ajoute en collant une adresse, fonctionne aussi sur le web et le mobile, mais n’a aucun accès à votre disque.

Un serveur MCP peut-il lire les fichiers de mon ordinateur ?

Seulement s’il tourne sur votre ordinateur, et seulement les fichiers que vous lui désignez. Un connecteur distant n’a aucun accès à votre disque : s’il a besoin d’un document, il doit vous demander de le déposer.

Faut-il un compte pour utiliser un connecteur MCP ?

Cela dépend de l’éditeur. Certains connecteurs demandent une authentification, d’autres sont ouverts. Celui de Trust My Docs est ouvert et ne demande ni compte ni clé ; son quota est partagé entre tous ses utilisateurs.

À quoi sert un connecteur MCP pour vérifier un document ?

À faire la vérification sans quitter la conversation, et à pouvoir enchaîner : demander une explication d’un écart, comparer plusieurs pièces entre elles, ou rédiger la réponse. La vérification elle-même reste faite par le service, de manière déterministe ; l’assistant apporte le raisonnement autour.