MCP en entreprise : connecter CRM et documents

En entreprise, MCP (Model Context Protocol) sert à donner aux assistants d'IA un accès contrôlé aux outils internes : CRM (logiciel de gestion de la relation client), base documentaire, outil de tickets, base de données. La documentation officielle cite justement des assistants d'entreprise reliés à plusieurs bases de données de l'organisation. Le travail ne s'arrête pas au code du serveur : il faut décider quoi exposer, où faire tourner les serveurs, qui y a droit et comment retirer un accès. Voici les briques disponibles, relevées le 15/11/2026.

1. Choisir ce que vous connectez

Commencez petit et en lecture. Deux exemples illustratifs :

• Un CRM : des outils en lecture (« chercher un client », « voir l'historique d'un compte ») avant tout outil d'écriture (« créer une opportunité »). Les fiches clients peuvent aussi être des ressources.
• Une base documentaire : une ressource par document ou un modèle de ressource par identifiant, plus un outil de recherche. Les droits d'accès aux documents doivent rester ceux du système d'origine.

Pour chaque outil, posez trois questions : que peut-il modifier ? Qui doit confirmer ? Que se passe-t-il si un contenu piégé le pousse à agir ? La page outils, ressources et prompts aide à faire le tri.

2. Local ou distant

Pour des applications métier partagées, le serveur distant est en général plus simple à gouverner. Voir stdio ou Streamable HTTP.

3. Contrôler quels serveurs sont autorisés

Les clients d'Anthropic proposent des contrôles d'administration :

• Claude (connecteurs personnalisés) : sur l'offre Team, seuls les propriétaires (Owners et Primary Owners) ajoutent un connecteur ; sur Enterprise, les propriétaires ou un rôle personnalisé disposant du droit « Manage access to Libraries ». Les membres s'y connectent ensuite chacun avec leurs identifiants.
• Claude Desktop (extensions) : sur Team et Enterprise, les propriétaires peuvent activer ou désactiver les extensions publiques et téléverser des extensions personnalisées. Les politiques posées au niveau de la machine, y compris listes de blocage et d'autorisation, l'emportent sur les réglages de l'application.
• Claude Code : une configuration gérée (managed-mcp.json) peut imposer un ensemble de serveurs, et les listes allowedMcpServers et deniedMcpServers restreignent ceux qu'on peut connecter.

4. Centraliser l'autorisation

Dans le modèle standard, chaque utilisateur autorise chaque serveur. La documentation de l'extension Enterprise-Managed Authorization (io.modelcontextprotocol/enterprise-managed-authorization) en liste les limites en entreprise : l'équipe sécurité ne peut pas imposer une politique cohérente, l'arrivée d'un salarié demande des dizaines d'autorisations manuelles, son départ demande autant de révocations.

Le principe de l'extension :

1. Le salarié se connecte au client avec son compte professionnel, via le fournisseur d'identité de l'entreprise (IdP).
2. Le client demande à l'IdP un jeton spécial, l'ID-JAG (Identity Assertion JWT Authorization Grant, une assertion d'identité signée).
3. L'IdP applique la politique (groupes, rôles, règles d'accès conditionnel) avant de l'émettre.
4. Le client échange l'ID-JAG contre un jeton d'accès auprès du serveur d'autorisation du serveur MCP.
5. Retirer un accès se fait une fois, dans l'IdP.

C'est une extension facultative : elle n'est jamais active par défaut et sa prise en charge varie selon les clients. La documentation tient un tableau des produits d'identité qui émettent ou acceptent des ID-JAG, avec leur niveau de disponibilité ; vérifiez-le pour le vôtre.

5. Tenir un registre interne

Le registre officiel ne prend pas les serveurs privés (réseau interne, paquets privés). Sa documentation recommande d'héberger un registre privé ; elle publie une spécification OpenAPI que d'autres registres peuvent implémenter, mais précise que le code du registre officiel n'est pas conçu pour être auto-hébergé. Le billet d'annonce du 08/09/2025 mentionne ces sous-registres privés, pour les entreprises aux exigences fortes de confidentialité et de sécurité. Voir le registre des serveurs MCP.

6. Sécuriser et tracer

Avant toute mise en service : validation des entrées, limitation des appels, droits minimaux, confirmation humaine pour les écritures, journal des appels d'outils. La liste complète est sur la page sécurité des serveurs MCP. Pour les questions de données personnelles, rapprochez-vous de votre délégué à la protection des données : cette page décrit des mécanismes techniques, pas une analyse juridique.

Une démarche en quatre temps

1. Un serveur pilote, en lecture seule, sur une source peu sensible.
2. L'ajout des outils d'écriture, avec confirmation.
3. La mise sous contrôle : liste des serveurs autorisés, autorisation centralisée si votre client la prend en charge.
4. L'ouverture à d'autres équipes, avec un registre interne.