Un assistant IA est utile quand il a le bon contexte, et dangereux quand on lui colle des exports un peu partout. Le Model Context Protocol, ou MCP, propose un standard ouvert pour relier un assistant à des outils et à des données, de façon structurée, plutôt que par copier-coller. Voici ce que c’est, ce que nous en faisons déjà, et ce que nous refusons de lui laisser décider tout seul.
Un protocole, pas un modèle
Le MCP est un standard ouvert, documenté sur modelcontextprotocol.io, pour connecter des applications d’IA à des systèmes externes : des données, des outils, des déroulements de travail. La documentation officielle le compare souvent à un port USB-C pour les applications d’IA : une manière commune de se brancher, plutôt qu’un adaptateur différent pour chaque couple assistant-logiciel.
Le protocole s’appuie sur des messages JSON-RPC 2.0. Il distingue typiquement l’hôte (l’application qui parle au modèle), le client (le connecteur dans cet hôte) et le serveur (le service qui expose des capacités). Un serveur peut proposer des ressources, des prompts, des outils. C’est cette dernière brique que l’on voit le plus dans les usages métier : lister, lire, parfois écrire, via des fonctions décrites, avec une authentification.
Le MCP n’est pas un modèle de langage. Il n’est ni ChatGPT, ni Claude, ni Mistral Vibe. C’est le rail qui peut les relier à un logiciel que vous tenez. Des assistants et des environnements de développement l’implémentent déjà, chacun à sa manière. La spécification, elle, reste la référence quand on implémente un serveur.
À quoi ça sert, concrètement, dans un métier
Sans protocole commun, on envoie à l’assistant un export, un copier-coller, un fichier. On lui demande de « regarder ça ». Le contexte est figé, souvent trop large, parfois trop vieux. Avec un serveur MCP, l’assistant peut demander, au moment utile, la liste des dossiers, le détail d’une fiche, une synthèse, dans le périmètre que la clé autorise.
L’intérêt n’est pas de parler à un robot pour le plaisir. C’est d’éviter de sortir les données de leur lieu de vérité, et de les faire circuler dans des documents sans droits. Une clé, un serveur, des outils nommés, valent mieux qu’un tableur envoyé par message.
Cela suppose, évidemment, que le serveur soit conçu avec des droits, des journaux, un périmètre étroit. Un MCP trop puissant, branché sur une base entière, avec une clé trop large, n’est pas une avancée. C’est une nouvelle porte. Nous appliquons ici la même prudence que pour n’importe quelle API.
Un exemple typique : interroger un outil de questionnaires pour lire une synthèse, ou un CRM pour retrouver une affaire, sans exporter toute la base. L’assistant prépare une lecture. Il n’envoie pas un message au client, il ne clôture pas une opportunité, sauf si l’on a explicitement prévu cet outil, et une validation.
Ce que nous exposons déjà
Sur le plan Pro de CRM by Le Beau Digital, nous proposons un accès MCP, aux côtés de l’API, de la prospection et de l’enrichissement. L’idée est de pouvoir interroger le CRM, et éventuellement y agir, depuis un assistant compatible, dans le cadre des droits accordés. Ce n’est pas un pilote automatique des ventes.
Nous travaillons aussi ce type de porte dans d’autres outils, quand le plan le prévoit, avec une clé dédiée, un transport authentifié, une liste d’outils limitée. Chaque produit documente les siens. Cette note n’est pas un inventaire à jour de toutes les fonctions. Elle pose le principe : un serveur MCP est une API pensée pour un assistant, pas une exception à nos règles de données.
Quand nous aidons un client à en exposer un, sur son propre outil, nous commençons par la liste des actions vraiment utiles. Lire, chercher, parfois créer un brouillon. Les actions irréversibles restent derrière une confirmation humaine, ou hors du serveur, dans un écran métier. L’IA prépare. La décision reste chez vous.
Sécurité, clés, périmètre
Un serveur MCP se protège comme n’importe quel service exposé : authentification, transport chiffré, journalisation, révocation des clés. On ne colle pas une clé dans un prompt, dans un dépôt public, ou dans un canal trop ouvert. On la tourne si elle a fuité. On lui donne le moins de pouvoirs possible.
Il faut aussi penser à ce que l’assistant va envoyer au modèle. Même si le serveur est chez vous, le texte lu par le modèle peut partir vers le prestataire de l’assistant, selon l’outil choisi. Le MCP standardise l’accès. Il ne rend pas magiquement confidentiel un usage d’assistant grand public. Le choix de l’outil, du contrat, des options de conservation, reste un sujet à part, que nous traitons dans le cadrage.
Enfin, on documente les outils exposés, pour les humains autant que pour le modèle. Un nom vague, une description pauvre, poussent l’assistant à trop deviner, ou à appeler le mauvais outil. Une description nette, avec les limites, réduit ce risque. Elle n’enlève pas la relecture sur les actions sensibles.
Quand le MCP n’est pas le bon premier pas
Si une équipe n’a pas encore d’outil métier stable, le MCP n’arrangera rien. Il faut d’abord un lieu de vérité, des droits, des données à peu près propres. Si le besoin est un simple export mensuel, un rapport figé peut suffire. Si personne n’est prêt à relire ce que l’assistant propose, brancher un serveur revient à accélérer le désordre.
Nous ne présentons donc pas le MCP comme une obligation de 2026. C’est un standard utile, de plus en plus présent dans les assistants et les environnements de développement, que nous utilisons quand il évite des exports, et quand le périmètre est tenu. La référence reste la documentation du protocole.
Un point de méthode, enfin, concerne les tests. Avant de donner une clé à toute une équipe, on essaie le serveur avec un compte restreint, sur des données que l’on a le droit de voir, en regardant les appels réellement émis. On vérifie qu’un outil d’écriture ne s’exécute pas par surprise, qu’une recherche ne remonte pas plus que le périmètre prévu, qu’une révocation de clé coupe bien l’accès. Ce n’est pas très spectaculaire. C’est le même travail que pour une API classique, et il évite de découvrir le périmètre réel en incident.
Nous distinguons aussi, dans les discussions, le MCP local et le MCP distant. Un serveur peut tourner sur le poste, près des fichiers de la personne, ou sur Internet, devant un service métier. Les deux existent dans l’écosystème décrit par la documentation officielle. Pour un outil d’équipe, c’est souvent le serveur distant, authentifié, que l’on vise. Pour un usage de développement sur une machine, un serveur local peut suffire. On ne mélange pas les deux sans le dire : les données n’ont pas le même chemin, et les responsabilités non plus.
Si un éditeur annonce « on a le MCP » sans lister les outils, sans parler d’authentification, sans dire ce qui est journalisé, nous posons des questions. Le mot, à lui seul, ne dit rien de la qualité du branchement. Comme pour n8n, comme pour une API, nous voulons un contrat lisible avant d’ouvrir la porte.
Relier, sans abdiquer
Relier un outil métier à un assistant, via MCP, peut simplifier le quotidien : une question, une lecture à jour, une préparation de réponse. Cela ne dispense pas de décider qui a la clé, ce qui est exposé, et ce qui exige encore un humain. Si vous voulez poser ce branchement sur un outil existant, ou sur l’un des nôtres, nous pouvons l’écrire avec vous.
Un message sur la page contact, ou un rendez-vous, suffit pour partir du besoin, pas d’une démo de connecteur.