« Ce serveur MCP ajoute une intégration CRM en quelques clics » : cette promesse, affichée sur la page de présentation d’un serveur MCP tiers destiné à connecter un agent IA à un CRM, mérite le même niveau de scepticisme qu’une extension WordPress promettant une fonctionnalité complexe en une seule installation. Le Model Context Protocol facilite la connexion d’agents à des services externes, mais cette facilité ne dispense d’aucune vérification préalable, particulièrement quand le serveur en question va lire ou écrire dans un CRM contenant des données commerciales sensibles.
Cette checklist s’adresse à tout prestataire technique sur le point d’installer, pour le compte d’un client, un serveur MCP tiers destiné à interagir avec un CRM. La performance de ce serveur, en termes de rapidité ou de qualité des réponses générées, ne fait pas l’objet de cette checklist ; l’accent porte exclusivement sur les signaux à vérifier avant toute autorisation.
1. Identifier l’éditeur et le mode d’hébergement du serveur
Un serveur MCP peut fonctionner en local, exécuté directement sur l’infrastructure du client, ou à distance, hébergé par un tiers et accessible via une connexion réseau. Cette distinction change radicalement le niveau de confiance requis : un serveur local, dont le code est inspectable et l’exécution maîtrisée, expose un risque différent d’un serveur distant, dont le comportement dépend entièrement d’un éditeur externe et de son infrastructure.
- Identifier si le serveur est un projet open source consultable, avec un historique de contributions vérifiable, ou une boîte noire propriétaire.
- Vérifier, pour un serveur distant, la localisation d’hébergement et la politique de conservation des données transitant par lui.
- Rechercher des signalements de sécurité ou des discussions communautaires évoquant des comportements anormaux du serveur.
2. Examiner précisément la liste des outils exposés et leurs portées
Un client MCP correctement configuré permet d’interroger la liste des outils (tools) qu’un serveur expose, avant même de l’autoriser à interagir avec un agent en production. Cette liste doit être examinée outil par outil, en vérifiant que chaque capacité correspond bien à un besoin identifié, et qu’aucun outil d’écriture non annoncé ne se cache derrière une description vague.
# Inspection de la liste des outils exposés avant toute connexion en production
mcp-inspector --server https://exemple-serveur-mcp.tld --list-toolsTrois signaux d’alerte reviennent fréquemment lors de cette inspection : un outil unique couvrant à la fois lecture et écriture sans distinction de portée, une description d’outil trop vague pour comprendre précisément son comportement, et l’absence totale de fonction de permission vérifiable côté serveur, laissant à l’agent seul la responsabilité de ne pas dépasser son cadre.
3. Tester le comportement du serveur en environnement isolé
Avant toute connexion à un CRM de production, un environnement de test disposant de données fictives permet d’observer le comportement réel du serveur MCP : quels outils sont effectivement appelés par l’agent au fil d’une conversation type, dans quel ordre, et si des appels en écriture surviennent de façon inattendue lors de simples demandes de consultation.
- Créer un jeu de données de test représentatif mais fictif dans le CRM cible.
- Dérouler plusieurs scénarios de conversation courants avec l’agent connecté au serveur MCP.
- Vérifier, après chaque scénario, qu’aucune modification non désirée n’a été appliquée au jeu de données de test.
4. Vérifier la traçabilité et la possibilité de révocation immédiate
Un serveur MCP fiable permet de journaliser chaque appel d’outil de façon consultable indépendamment de l’agent lui-même, et offre un mécanisme de révocation immédiate de la connexion en cas de comportement suspect détecté après la mise en production. L’absence de l’un ou l’autre de ces deux éléments doit suffire à reporter l’adoption du serveur, quelle que soit la qualité apparente de ses fonctionnalités.
Un serveur MCP qui refuse de révéler la liste précise de ses outils avant connexion ne mérite pas la confiance d’un CRM ; c’est une porte qu’on ouvre sans savoir combien de pièces elle dessert.
En résumé
L’identification de l’éditeur et du mode d’hébergement, l’examen précis des outils exposés, un test en environnement isolé et la vérification de la traçabilité forment une checklist qui se déroule en une petite heure, pour un serveur MCP qui restera ensuite connecté au CRM du client pendant des mois, voire des années. Un prestataire qui néglige cette vérification transfère, sans le vouloir, sa confiance envers un serveur externe directement sur les données commerciales de son client.
