MCP : donner à Claude un accès borné à vos systèmes existants
Mise à jour le 9 août 2026
Un modèle sans accès à vos données produit du texte générique. Toute la valeur d'une intégration métier vient de ce qu'il peut consulter : votre ERP, votre CRM, votre base documentaire, vos tickets. Le Model Context Protocol, ou MCP, est le standard ouvert qui normalise cette connexion entre applications d'IA et systèmes externes (modelcontextprotocol.io). La documentation officielle le compare à un port USB-C : une prise standard plutôt qu'un connecteur par appareil.
Pourquoi un standard change quelque chose ici
L'argument n'est pas esthétique, il est économique. Un connecteur écrit pour un assistant précis est jetable le jour où vous changez d'assistant. MCP est soutenu par un ensemble de clients et de serveurs qui dépasse un seul éditeur : la documentation cite notamment Claude, ChatGPT, Visual Studio Code et Cursor parmi les clients compatibles. Un serveur MCP écrit devant votre ERP reste utilisable si vous changez d'outil en amont, ce qui déplace l'investissement du côté durable de la chaîne.
Ce qu'un serveur MCP est réellement
C'est un programme qui expose, dans un format normalisé, un ensemble d'opérations : lire une fiche client, chercher dans un catalogue, créer un ticket. Il se place devant vos systèmes et n'expose que ce que vous y déclarez. C'est important pour deux raisons opposées. Il n'y a pas de magie : ce que vous n'exposez pas n'est pas accessible. Et il n'y a pas de filet : ce que vous exposez l'est réellement, avec les droits que porte le serveur.
| Type de système | Ce qu'un accès en lecture apporte | Ce qu'un accès en écriture engage |
|---|---|---|
| ERP, gestion commerciale | Répondre sur un stock, un encours, un historique | Créer ou modifier des pièces de gestion : à réserver au dernier temps du projet |
| CRM | Préparer un contact avec l'historique réel | Écrire dans la fiche client, donc altérer une source de vérité commerciale |
| Base documentaire | Retrouver et citer un document interne | Peu d'intérêt en écriture, beaucoup de risque de pollution |
| Outil de tickets | Qualifier, rapprocher des cas similaires | Créer et transitionner : acceptable si chaque action est journalisée |
| Comptabilité, paie | Consulter un état déjà arrêté | À exclure par défaut : effets juridiques, aucune réversibilité simple |
La règle d'ouverture : lecture d'abord, périmètre nommé
L'ordre qui protège est toujours le même. Vous ouvrez en lecture, sur un périmètre nommé, avec un compte de service dédié dont les droits sont visibles dans votre annuaire. Vous observez ce qui est réellement consulté. Vous n'ouvrez l'écriture qu'ensuite, opération par opération, et jamais sur un système dont les écritures ne se défont pas.
Un serveur MCP hérite des droits du compte qu'il utilise, pas des droits de la personne qui pose la question. C'est le piège classique : un serveur branché avec un compte administrateur donne à tout utilisateur du chemin la visibilité de cet administrateur. Le contrôle d'accès doit rester dans le système source, ou être reproduit explicitement dans le serveur, avec des tests qui le vérifient.
Côté client, des garde-fous existent et méritent d'être connus : Claude Code demande une vérification de confiance lors de la première utilisation d'un nouveau serveur MCP, au même titre que pour un dépôt inconnu (documentation sécurité). Cette vérification protège d'un ajout silencieux, pas d'un serveur mal configuré que vous avez vous-même approuvé.
Quand MCP n'est pas la bonne réponse
Si vous construisez une fonctionnalité précise dans votre propre application, avec un nombre d'opérations connu à l'avance, un appel direct à votre API depuis votre code est plus simple, plus testable et plus facile à sécuriser. MCP prend son intérêt quand plusieurs clients doivent atteindre les mêmes systèmes, ou quand vous voulez que l'outillage interne de vos équipes accède au parc sans écrire un connecteur par usage. Pour une application unique et un besoin unique, le protocole ajoute une couche que vous devrez maintenir.
Depuis une application qui appelle l'API, la connexion à des serveurs MCP distants est possible sans héberger de client dédié (documentation du connecteur MCP). C'est une option d'architecture, pas une obligation : elle se choisit sur le nombre de consommateurs, pas sur la nouveauté du protocole.
Questions fréquentes
Faut-il un serveur MCP par système ?
Pas nécessairement, et le découpage se décide sur les droits plutôt que sur les systèmes. Regrouper dans un même serveur des opérations qui exigent des niveaux d'habilitation différents complique le contrôle et finit par aligner tout le monde sur le droit le plus large. Un serveur par domaine d'habilitation reste plus lisible qu'un serveur par application.
MCP remplace-t-il nos API existantes ?
Non, il se pose devant elles. Un serveur MCP est une façade normalisée qui traduit vos opérations existantes dans un format que les clients savent consommer. Si vos API sont saines, le travail consiste surtout à choisir ce que vous exposez et à écrire les descriptions des opérations. Si elles ne le sont pas, MCP ne réparera rien.
Que voit exactement le modèle ?
Ce que le serveur lui renvoie, et rien d'autre. C'est une raison suffisante pour filtrer les données au niveau du serveur plutôt que de compter sur une consigne : ne renvoyez pas un objet complet quand trois champs suffisent, et excluez à la source les données personnelles qui n'ont pas de raison de circuler.
Comment tracer ce qui a été consulté ?
Par la journalisation côté serveur, comme pour toute autre consommation de vos API : quel compte, quelle opération, quels paramètres, quand. Cette trace n'est pas une formalité de conformité, c'est ce qui vous permettra de répondre à la première question posée en cas d'incident, et de resserrer les droits sur des faits plutôt que sur des suppositions.
Étudier la connexion à vos systèmes
Réponse humaine sous 24 h ouvrées. Prendre contact ne vous engage à rien.
Claude, Claude Code et Claude Cowork sont des marques d'Anthropic, PBC. Smartshift n'est ni affiliée, ni partenaire, ni certifiée, ni mandatée par Anthropic : ces marques sont citées à titre référentiel, pour désigner les produits qu'elles nomment. Les éléments techniques et contractuels cités proviennent de la documentation et des conditions publiques d'Anthropic, relevées le 9 août 2026 ; vérifiez-les avant toute décision engageante, elles évoluent.