Connecter Claude Code au SI de l’entreprise avec MCP : ce qu’il faut cadrer

Qu’est-ce que MCP, et que change-t-il pour Claude Code ?

Connecter Claude Code au SI de l’entreprise revient presque toujours à brancher des serveurs MCP. Sans connecteur, l’agent travaille sur les fichiers du dossier qu’on lui ouvre et lance les commandes qu’on l’autorise à exécuter. Dès qu’un connecteur arrive, il peut lire un ticket, interroger une base ou poster un message, avec les droits du compte qui l’a autorisé.

Le Model Context Protocol (MCP) est un standard ouvert publié par Anthropic en novembre 2024 pour relier une application d’IA à des systèmes externes. Chaque branchement passe par un serveur MCP, qu’on appelle aussi connecteur, qui expose au modèle des actions à exécuter, des données à lire et des modèles de consignes réutilisables.

La leçon d’introduction du module MCP de Koneetiv Academy compare le protocole à une prise USB, et le site officiel du protocole parle d’un port USB-C pour les applications d’IA : un format unique, sur lequel chaque outil se branche de la même façon. Depuis décembre 2025, le protocole est confié à l’Agentic AI Foundation, rattachée à la Linux Foundation, pour que sa gouvernance ne dépende plus d’un seul éditeur. Pour une entreprise, l’image de la prise masque pourtant l’essentiel : un connecteur transmet aussi des droits, à cadrer avant de brancher quoi que ce soit.

Outils, ressources, prompts : ce qu’un serveur expose

La spécification MCP (version du 28 juillet 2026) classe ce qu’un serveur peut offrir selon qui le déclenche. Les prompts sont choisis par l’utilisateur, et Claude Code les présente comme des commandes que l’on tape après la barre oblique. Les resources sont des données que l’application attache au contexte : dans Claude Code, on les cite avec une mention @, comme un fichier. Les tools sont appelés par le modèle lui-même, quand il juge qu’une action est utile.

Les outils demandent le plus d’attention, parce que c’est le modèle qui décide de les appeler. Quand un développeur écrit « ouvre un ticket pour ce bug », Claude repère l’outil de création du connecteur de ticketing, remplit les champs et l’exécute, sous réserve des permissions en place. C’est donc le connecteur qui fixe le périmètre de ce que l’agent peut faire, bien plus que la consigne.

Du poste du développeur au système d’information

Les exemples de la formation parlent de messagerie, d’agenda ou de maquettes Figma, parce qu’on peut les essayer sans rien demander à personne. Dans une entreprise, les connecteurs qui comptent touchent le système d’information lui-même, jusqu’au CRM. Une équipe peut aussi écrire son propre serveur MCP pour exposer une API maison, et c’est souvent là qu’une DSI trouve le plus de valeur, sur des données qu’aucun éditeur ne branchera à sa place. MCP relève de l’intégration par API, l’option que nous mettions en balance avec le pilotage d’écran dans notre analyse computer use ou API pour l’architecture des agents IA.

Comment brancher un serveur MCP sur Claude Code ?

La commande claude mcp add déclare un serveur, et /mcp, dans une session, affiche l’état de chaque connexion et lance l’authentification quand elle est requise. Deux décisions se prennent alors, souvent sans y penser : le mode de transport et la portée de la configuration.

Local ou distant : le choix du transport

Un serveur local tourne comme un processus sur la machine du développeur et dialogue avec Claude Code par l’entrée et la sortie standard (stdio). Un serveur distant est joint en HTTP, le transport que la documentation de Claude Code recommande pour les services en ligne. L’ancien transport SSE fonctionne encore, mais il est déclaré obsolète. Côté DSI, la différence dépasse la plomberie : un serveur distant se gouverne à un seul endroit, alors qu’un serveur local vit sur chaque poste, avec ses dépendances et ses mises à jour.

Local, projet, utilisateur : où vit la configuration

Claude Code range chaque serveur dans une portée. La portée locale, par défaut, garde le serveur privé et limité au projet courant, dans le fichier ~/.claude.json de l’utilisateur. La portée utilisateur l’étend à tous ses projets, dans le même fichier. La portée projet l’écrit dans un fichier .mcp.json à la racine du dépôt, destiné à être versionné : toute l’équipe hérite alors des mêmes connecteurs.

En session interactive, Claude Code demande une approbation avant d’utiliser un serveur déclaré dans .mcp.json. En mode non interactif (claude -p, Agent SDK, sessions cloud), il charge ces serveurs sans rien demander. Un dépôt cloné puis lancé dans une chaîne d’intégration continue embarque donc ses connecteurs avec lui, sans personne pour confirmer quoi que ce soit. En CI ou avec claude -p, l’option --strict-mcp-config limite la session aux serveurs passés avec --mcp-config, mais Claude Code s’arrête dès le démarrage si un fichier managed-mcp.json est déployé sur la machine. La liste blanche allowedMcpServers, décrite plus bas, filtre aussi ces serveurs, et l’option ne la contourne pas.

Authentifier sans exposer de secrets

Beaucoup de serveurs distants passent par OAuth 2.0 : l’utilisateur se connecte une fois dans son navigateur depuis /mcp, et Claude Code conserve le jeton. Pour un serveur qui accepte une clé d’API, le fichier .mcp.json sait lire des variables d’environnement, écrites ${NOM_DE_VARIABLE}, ce qui laisse versionner la configuration sans y écrire la clé. Les entreprises qui utilisent Kerberos, des jetons de courte durée ou un SSO interne ont un réglage dédié, headersHelper, qui génère les en-têtes d’authentification au moment de la connexion.

Quels systèmes de l’entreprise connecter en premier ?

Commencez par les systèmes consultés en lecture, dont les données sont déjà accessibles aux équipes qui utilisent Claude Code : outil de tickets, documentation interne, dépôt de code, supervision. Les connecteurs qui écrivent dans un système de référence, comme le CRM, l’ERP ou la paie, viennent ensuite, une fois les permissions, les scopes et la journalisation en place.

L’ordre que nous conseillons pour un premier déploiement :

1. Lister les tâches où les développeurs recopient aujourd’hui à la main des informations d’un outil vers Claude Code.
2. Choisir pour chacune un serveur officiel de l’éditeur, ou un serveur interne relu par l’équipe sécurité.
3. Ouvrir d’abord les outils de lecture, avec un compte ou des scopes limités à ce besoin.
4. Observer l’usage réel pendant une période d’essai, puis décider des outils d’écriture un par un.

Support et exploitation : diagnostiquer sans changer d’outil

Un cas typique, à titre d’illustration : un développeur de l’équipe d’exploitation prend en charge un incident. Avec un connecteur vers l’outil de tickets et un autre vers la supervision, Claude Code lit le ticket, récupère les journaux d’erreur de la période, relie l’erreur au code du dépôt et propose un correctif. Rien n’est écrit hors du dépôt, et le développeur relit la modification avant de la proposer.

Données : écrire une requête sur les vraies tables

Un analyste qui prépare une requête a intérêt à laisser Claude Code lire le schéma de l’entrepôt plutôt qu’à le recopier. Le connecteur doit alors pointer vers un compte en lecture seule, sur une réplique ou un environnement de recette quand c’est possible. La documentation de Claude Code prévoit un avertissement au-delà de 10 000 tokens par résultat d’outil et une limite de 25 000 tokens par défaut, au-delà de laquelle le résultat part dans un fichier : borner les requêtes dès le connecteur évite ces détours.

CRM et outils métier : attendre que le cadre soit posé

Brancher un CRM ouvre des données clients, souvent personnelles au sens du RGPD, à un agent qui peut aussi écrire. Nous avons détaillé les questions à trancher dans notre article sur Salesforce dans Claude et le cadrage de sa bêta côté DSI : où transitent les données, quels profils ouvrir, qui valide les écritures. Ces questions valent pour tout connecteur branché sur un système de référence.

Quels risques de sécurité pose un connecteur MCP ?

Un connecteur donne à Claude un accès réel, avec les droits du compte qui l’a autorisé. Anthropic le rappelle dans sa documentation sur le contrôle des serveurs MCP : l’éditeur examine les connecteurs selon ses critères avant de les inscrire à l’Anthropic Directory, mais n’audite pas la sécurité des serveurs MCP et ne les gère pas. La responsabilité de ce qu’on branche revient donc à l’entreprise.

L’injection de consignes par les données

Un serveur qui ramène du contenu externe, comme une page web, un e-mail ou un ticket rédigé par un client, peut transporter des instructions cachées. La documentation de Claude Code recommande de vérifier que l’on fait confiance à chaque serveur avant de le connecter, car ceux qui récupèrent du contenu externe exposent à un risque d’injection de prompt. Le danger grandit quand le même agent lit des contenus non maîtrisés et a accès à des outils d’écriture. C’est la combinaison à défaire en priorité, en séparant les usages ou en soumettant les écritures à validation humaine.

Ce que le jeton autorise

Un connecteur agit avec le jeton qu’on lui a confié. Si ce jeton ouvre tout le compte d’un administrateur, l’agent hérite de tout. Claude Code sait épingler les scopes OAuth demandés par un serveur (réglage oauth.scopes), et sa documentation présente ce réglage comme le moyen prévu pour restreindre un serveur au sous-ensemble approuvé par l’équipe sécurité. Côté serveur, les bonnes pratiques de sécurité publiées sur modelcontextprotocol.io interdisent d’accepter un jeton qui n’a pas été émis pour le serveur lui-même, et recommandent des scopes minimaux, élargis au cas par cas.

Les serveurs locaux et leur provenance

Un serveur local est un programme exécuté sur le poste, avec les droits de l’utilisateur. Installé depuis un dépôt public sans relecture, il présente les mêmes risques que n’importe quel paquet logiciel : code malveillant, dépendance compromise, mise à jour qui change de comportement. Les bonnes pratiques du protocole traitent d’ailleurs la compromission d’un serveur local comme un risque à part entière. Nous recommandons de n’ouvrir aucun serveur local qui n’ait été relu, épinglé sur une version et inscrit au catalogue interne.

Comment une DSI garde-t-elle la main sur les connecteurs ?

Par défaut, toute personne qui utilise Claude Code peut connecter le serveur MCP de son choix. Selon Deloitte (State of AI in the Enterprise, édition 2026), seules 21 % des organisations disposent d’un modèle de gouvernance mature pour leurs agents IA. Les connecteurs sont un bon point de départ : Claude Code fournit déjà les leviers, et ils se déploient comme une politique de poste de travail.

Un catalogue approuvé plutôt qu’un inventaire après coup

Claude Code lit des paramètres gérés par l’administrateur, qui priment sur ceux des utilisateurs. Le fichier managed-mcp.json, poussé par l’outil de gestion de parc (Jamf, Intune, stratégie de groupe), fixe la liste des serveurs : l’utilisateur ne peut plus en ajouter, et un fichier vide coupe tout, hormis les serveurs fournis par l’administrateur via managedMcpServers et ceux intégrés à l’application hôte. Plus souples, les listes allowedMcpServers et deniedMcpServers filtrent ce que les utilisateurs configurent, de préférence par commande ou par adresse : un filtre par nom se contourne, puisque chacun nomme un serveur comme il veut. Une liste blanche ne fait autorité qu’avec le verrou allowManagedMcpServersOnly : sans lui, un utilisateur peut l’élargir depuis ses propres paramètres.

Faute de magasin intégré, la documentation conseille de publier la liste approuvée sur un wiki interne ou de distribuer les serveurs en plugins via une place de marché interne.

Des permissions outil par outil

Les règles de permission de Claude Code s’écrivent aussi pour les outils MCP, sous la forme mcp__serveur__outil. On peut laisser passer sans confirmation les outils de lecture d’un serveur, garder les écritures soumises à approbation et interdire le reste. Une règle de refus sur mcp__* retire d’un coup tous les outils MCP. Pour les connecteurs gérés depuis claude.ai, l’organisation peut régler un outil sur « ask », qui impose une confirmation à chaque appel même dans les modes les plus permissifs, ou sur « blocked », qui le retire de la liste.

Savoir ce qui sert vraiment

Quand l’export OpenTelemetry est configuré, Claude Code peut consigner les serveurs et les outils MCP que les utilisateurs appellent, avec la variable OTEL_LOG_TOOL_DETAILS=1. C’est la base d’une revue régulière des connecteurs réellement utilisés et de ceux qui écrivent dans un système de référence. Notre approche de la gouvernance des agents IA part de ce type d’observation, et notre grille pour classer les agents IA par zone de confiance aide à décider quels outils d’écriture ouvrir, et sous quel contrôle humain.

Les connecteurs claude.ai dans Claude Code

Quand un utilisateur se connecte à Claude Code avec un abonnement claude.ai, les connecteurs de son compte, ajoutés par les administrateurs sur les offres Team et Enterprise, apparaissent aussi dans Claude Code. Ce n’est pas le cas avec une clé d’API, ni via un fournisseur cloud comme Amazon Bedrock. La politique de connecteurs doit donc couvrir les deux portes d’entrée.

Quelles erreurs éviter au démarrage ?

Versionner une clé d’API dans .mcp.json

Le fichier .mcp.json est fait pour être partagé, donc lu par toute l’équipe et parfois poussé par erreur sur un dépôt public. Une clé écrite en clair y fuit tôt ou tard. La syntaxe ${VARIABLE} existe pour cela, et la documentation de Claude Code déconseille de même de placer des identifiants dans managed-mcp.json, lisible par tout utilisateur de la machine.

Brancher tout ce qui existe

Chaque serveur ajoute des outils que le modèle doit connaître. Claude Code limite ce coût avec la recherche d’outils, activée par défaut : seuls les noms des outils et les instructions des serveurs sont chargés au démarrage, et les définitions complètes arrivent à la demande. La recherche d’outils règle la question du contexte. Celle du risque reste entière, car chaque outil disponible est une action que l’agent peut décider de lancer, et un connecteur inutilisé reste une surface d’attaque.

Comment se former à MCP avec Claude Code ?

Cet article prolonge le module « Les MCP & connecteurs » de la formation Claude Code de Koneetiv Academy. Le module reprend les bases pas à pas : ce qu’est un serveur MCP, la différence entre outils, ressources et prompts, puis l’installation d’un premier connecteur et les réflexes de sécurité qui vont avec. Chaque leçon se termine par des questions de validation, et la leçon d’essai de l’Academy se suit sans créer de compte.

Pour qui, et dans quel ordre

Comme le reste de l’Academy, le module est conçu pour des professionnels non développeurs : aucun langage de programmation n’est requis. Pour une équipe qui déploie Claude Code à plusieurs, développeurs compris, nous conseillons de le faire suivre avant d’ouvrir le premier connecteur partagé, pour que les questions de ce guide trouvent un vocabulaire commun. Quand un connecteur ne répond plus, notre page de dépannage de Claude Code traite ce cas, et le glossaire IA reprend les définitions utilisées ici.

Et pour un déploiement à l’échelle

Former les utilisateurs ne règle pas le cadrage côté DSI. Notre page sur Claude Code en entreprise décrit comment nous accompagnons ces déploiements, en tant que partenaire officiel Anthropic. Et pour situer votre organisation avant d’ouvrir le chantier, le diagnostic de maturité IA la note sur les six axes du référentiel Koneetiv (édition 2026), gouvernance comprise.