Réponse en bref
Un serveur MCP est un petit programme qui donne à un assistant d’IA, comme Claude ou ChatGPT, un accès contrôlé à un système : un CRM, un tableau ou une base de données. Il propose des outils, des données et des modèles via un standard ouvert. Commencez en lecture sur des données de test, ajoutez l’écriture action par action et gardez les identifiants sur le serveur seul.
Un serveur MCP en mots simples : une prise standard pour votre assistant
MCP signifie Model Context Protocol, et sa documentation officielle le décrit comme un standard ouvert pour relier des applications d’IA à des systèmes externes. Un serveur MCP est le petit programme placé de l’autre côté de cette liaison. Il détient l’accès à un système précis et le propose à l’assistant sous une forme que celui-ci comprend. La documentation compare MCP à un port USB-C pour l’IA : une prise standard au lieu d’un câble différent pour chaque appareil.
Anthropic a annoncé le protocole le 25 novembre 2024. Son annonce pose le problème sans détour : chaque nouvelle source de données exigeait sa propre implémentation, et MCP remplace les intégrations fragmentées par un protocole unique. Pour un dirigeant, la conséquence pratique est simple. Quand votre CRM ou votre base de données dispose d’un serveur, tout assistant compatible avec le protocole peut s’en servir sans nouvelle intégration pour chaque outil.
Hôte, client et serveur : qui fait quoi dans la liaison
La page d’architecture nomme trois parties. L’hôte est l’application d’IA, comme Claude Desktop ou Claude Code. À l’intérieur, un client maintient une connexion dédiée avec chaque serveur. Le serveur est le programme qui fournit du contexte. La documentation souligne que le mot ne dit rien de l’endroit où il tourne : un serveur local peut se trouver sur le même ordinateur, un serveur distant fonctionne sur une plateforme et sert de nombreux clients.
Un serveur peut proposer trois sortes de choses. Les outils sont des fonctions que l’assistant peut appeler, comme une requête de base de données ou un appel d’API. Les ressources sont des données qui donnent du contexte : contenu de fichiers, enregistrements, schéma. Les modèles sont des gabarits réutilisables qui structurent la conversation. L’exemple de la documentation est un serveur de base de données avec un outil de requête, une ressource portant le schéma et un modèle contenant des exemples de bonnes questions.
La liaison emprunte l’un de deux transports. Stdio relie des processus locaux sur une même machine. Streamable HTTP sert des clients distants et, selon la documentation, accepte les jetons porteurs, les clés d’API et des en-têtes personnalisés, OAuth étant recommandé pour obtenir les jetons.
Ce que peut faire un assistant relié à votre CRM ou à un tableau
Imaginez une responsable commerciale qui tape une question simple : quelles affaires n’ont eu aucune activité depuis trois semaines, et qui les suit. Avec un serveur devant le CRM, l’assistant appelle un outil de recherche, reçoit les fiches et répond en quelques lignes, sans export vers un tableur.
La même liaison peut aussi écrire, et c’est là que l’histoire change. Lire une fiche répond à une question. Créer une affaire, changer un statut ou supprimer une ligne est une action aux conséquences. Un serveur tout fait pour un outil général peut ne pas convenir aux champs propres à votre CRM ni à vos règles sur qui peut quoi, et cet ajustement est le vrai travail.
Droits de lecture et d’écriture : commencer en lecture seule
Le guide de sécurité du protocole nomme le principe de minimisation du périmètre. Il décrit le risque concrètement : si un jeton porte de larges droits sur des fichiers, des bases ou l’administration, une fuite livre tout. La conception recommandée part d’un ensemble minimal d’opérations de découverte et de lecture à faible risque et n’élargit les droits qu’à la première tentative d’une opération privilégiée.
La documentation d’OpenAI sur MCP montre la même séparation en pratique. Son serveur d’exemple expose deux outils en lecture seule, rechercher et récupérer, et le guide dit de garder l’approbation activée pour les outils pouvant modifier des données ou avoir d’autres conséquences importantes. Il précise aussi que ChatGPT exige actuellement une confirmation manuelle dans chaque conversation avant les actions d’écriture. Cela peut changer, consultez donc la page au moment de décider.
La spécification du protocole place la responsabilité sur l’hôte. Les utilisateurs doivent consentir explicitement à l’accès aux données et aux opérations, les hôtes doivent obtenir un consentement explicite avant d’invoquer un outil. La spécification admet aussi que le protocole ne peut pas faire respecter ces principes de lui-même. Les droits relèvent donc d’une décision de conception sur vos données. Pour un premier projet, prenez un compte, un rôle et la lecture seule, avec une liste écrite des actions d’écriture pour plus tard et une personne qui approuve chacune.
Injection de prompt et jetons trop larges : les deux risques à prévoir
L’OWASP décrit l’injection indirecte de prompt comme le cas où un modèle accepte des entrées de sources externes, sites web ou fichiers, et ajoute que ces entrées peuvent fonctionner même si les humains ne les voient pas. Imaginez une note dans la fiche d’un contact qui contient une phrase adressée à l’assistant plutôt qu’à un collègue. L’assistant lit la note comme une donnée, mais le modèle peut la prendre pour une consigne.
L’OWASP dit qu’on ne sait pas si l’injection de prompt peut être entièrement évitée, et conseille donc d’en réduire l’impact. Limiter l’accès du modèle au minimum nécessaire à ses opérations, exiger l’approbation humaine pour les actions à haut risque ou privilégiées, et traiter le modèle comme un utilisateur non fiable. La documentation d’OpenAI sur MCP dit la même chose de son côté : faire confiance au développeur d’un serveur ne rend pas l’injection de prompt sans danger.
Les jetons méritent leur propre paragraphe. Le guide de sécurité de MCP qualifie d’antimodèle le transfert direct de jetons, où un serveur accepte des jetons qui ne lui ont pas été délivrés et les transmet à un autre service, et pose que les serveurs ne doivent pas accepter de jetons non délivrés explicitement pour eux. OpenAI ajoute qu’elle ne développe ni ne vérifie les serveurs personnalisés et conseille de ne se connecter qu’à une application que vous connaissez et en laquelle vous avez confiance.
Local ou distant : où doit vivre le serveur
Un serveur local lancé sur un ordinateur via stdio sert un seul assistant de cette machine et n’a pas besoin d’adresse publique, ce qui convient à un essai personnel. Un serveur distant utilise Streamable HTTP, sert beaucoup de monde et demande un hébergement, une connexion et un lieu sûr pour les jetons.
Pour une équipe, le choix dépend de qui l’utilisera. Si toute l’équipe commerciale doit interroger le CRM depuis ses assistants, la forme naturelle est un serveur distant avec connexion par personne, car les actions sont alors enregistrées sous l’identité de chacun et leurs droits peuvent différer. Si un analyste travaille sur un seul tableau, un serveur local peut suffire. Dans les deux cas, le serveur doit être le seul endroit qui garde les identifiants du CRM, jamais les réglages de l’assistant ni une conversation partagée.
Comment une petite entreprise démarre sans gros projet
Choisissez une question posée chaque semaine, une source de données et une copie avec des clients inventés. Donnez au serveur le seul accès en lecture, essayez-le avec deux ou trois collègues et tenez un journal de ce que l’assistant a demandé. Quand les réponses sont justes, ajoutez une action d’écriture, par exemple créer une tâche, avec confirmation par une personne.
Avant de construire quoi que ce soit, cherchez un serveur déjà fait par l’éditeur de votre outil. Le projet du protocole tient des implémentations de référence de serveurs, un point de départ raisonnable. Un serveur tout fait convient pour un essai sur des données de test. Pour de vraies fiches clients, lisez ce qu’il peut faire, qui le maintient et ce qu’il journalise.
Que préparer avant de commander un serveur MCP
Notez les cinq questions que votre équipe pose le plus souvent et le système qui détient les réponses. Créez pour l’intégration un compte distinct aux droits limités plutôt que d’utiliser l’identifiant du propriétaire. Dressez la liste des champs qui ne doivent jamais parvenir à l’assistant et des actions d’écriture voulues plus tard, avec la personne qui approuve chacune. Si les données comprennent des données personnelles, faites vérifier vos obligations par un avocat.
VITON13 Studio propose un forfait intitulé Connecteur d’IA pour votre CRM. Il construit un serveur MCP qui relie un assistant d’IA à votre CRM, vos tableaux ou votre base de données, avec les droits de lecture et d’écriture de votre choix, le configure dans l’assistant que vous utilisez déjà et ajoute un court guide sur la façon de poser les questions et ce qui est permis. Avant tout paiement, le studio montre un brouillon gratuit : une démonstration en lecture seule sur des données de test. Le prix est fixe, 213 $, et le travail prend de 7 à 12 jours ouvrés.
Checklist pratique
- Notez les cinq questions les plus fréquentes de votre équipe et le système qui détient les réponses.
- Créez un compte d’intégration en lecture seule plutôt que d’utiliser l’identifiant du propriétaire.
- Listez les champs et fiches qui ne doivent jamais atteindre l’assistant et excluez-les sur le serveur.
- Testez sur une copie de clients inventés avant de brancher les données réelles et gardez un journal des requêtes.
- Ajoutez chaque action d’écriture séparément, avec une personne désignée qui la confirme avant exécution.
Questions et réponses
ChatGPT ou Claude peuvent-ils modifier des fiches de mon CRM via un serveur MCP ?
Seulement si le serveur propose des outils d’écriture et que vous les autorisez. Selon la documentation d’OpenAI, ChatGPT demande aujourd’hui une confirmation manuelle avant d’écrire. Le plus prudent est de commencer en lecture et d’ajouter chaque action d’écriture à part.
Dois-je héberger moi-même le serveur MCP ou peut-il tourner sur un portable ?
Un serveur local tourne sur un seul ordinateur et y sert un assistant. Pour toute une équipe, il en faut en général un distant, avec hébergement, connexion et stockage sûr des jetons. Le choix dépend de qui doit s’en servir.
Est-il sûr de relier un serveur MCP à des données de clients ?
Il peut l’être, avec des limites. Donnez-lui les droits les plus étroits, gardez les identifiants sur le serveur, exigez une approbation pour les actions à risque et surveillez les journaux. La spécification dit elle-même que le protocole ne peut pas imposer la sécurité : c’est à la conception autour de le faire.
En quoi un serveur MCP diffère-t-il d’une intégration classique par API ?
Une intégration par API se construit à part pour chaque paire d’outils. Un serveur MCP expose un système de façon standard et tout assistant compatible peut l’utiliser. L’assistant découvre en outre de lui-même les outils disponibles.
Que se passe-t-il si l’assistant lit une note ou un e-mail piégé ?
Le modèle peut prendre le texte des données pour une consigne. L’OWASP appelle cela l’injection indirecte de prompt et admet qu’on ne peut peut-être pas l’éviter entièrement : limitez ce que le serveur peut faire et gardez un humain pour tout ce qui modifie ou envoie des données.