MCP en entreprise : connecter vos outils à un agent IA sans ouvrir de faille

MCP en entreprise consiste à exposer vos outils internes, CRM, outil de support, ERP, base documentaire, à un agent IA par des serveurs dédiés qui suivent le Model Context Protocol. Le protocole règle la plomberie de la connexion, pas la gouvernance : le périmètre des outils, les permissions et la journalisation restent à votre charge. Ce sont ces trois points, plus que le choix du modèle, qui décident si le branchement tiendra en production.

Avant MCP, chaque agent réintégrait chaque outil séparément, avec son propre code d’accès et ses propres jetons. Un serveur MCP change cela : il expose une fois des fonctions précises (lire une fiche, créer un ticket, chercher un document), et tout client compatible peut les appeler. Claude, ChatGPT ou un agent construit avec LangGraph passent alors par le même point d’entrée. La surface à sécuriser se déplace : elle n’est plus dans le nombre d’intégrations, mais dans ce qu’un serveur rend accessible.

Cet article détaille les décisions à prendre avant d’ouvrir un serveur MCP en entreprise : outils exposés, permissions, injection de prompt, journalisation, arbitrage avec l’automatisation classique. Le protocole publie de son côté des bonnes pratiques de sécurité du Model Context Protocol qui complètent utilement cette grille de lecture.

Qu’est-ce que MCP apporte à un agent IA en entreprise ?

Un serveur MCP fait gagner trois choses concrètes : la réutilisation, la séparation et la standardisation. La réutilisation, parce qu’un serveur branché sur HubSpot, Zendesk ou Odoo sert autant au copilote commercial qu’à l’agent de support. La séparation, parce que le code qui parle à l’outil vit dans le serveur, et non dans le prompt de l’agent. La standardisation, parce que l’on change de client sans réécrire la connexion.

Le point d’attention est ailleurs. MCP décrit comment un agent appelle un outil, jamais si cet appel est légitime. Un serveur qui expose « supprimer la fiche client » rend cette action disponible au même titre que « lire le solde ». Le panorama des outils IA par usage situe MCP parmi les briques d’un projet : le protocole est un moyen de connexion, pas une politique d’accès.

Quels outils exposer, avec quel périmètre ?

La règle tient en une phrase : exposez le minimum d’outils nécessaires au cas d’usage, et donnez à chacun une action étroite. Cinq points suffisent à couvrir la plupart des revues.

1. Un outil, une action, un objet. « Ajouter une note à une fiche » se limite et se teste ; « modifier le client » non.
2. Lecture d’abord, écriture ensuite. On ouvre la lecture, on mesure, puis on autorise quelques écritures sur des champs nommés.
3. Pas de requête libre. Un outil qui accepte du SQL ou du code arbitraire transforme l’agent en accès direct à la base.
4. Paramètres typés et validés côté serveur. La validation ne peut pas reposer sur la bonne volonté du LLM (grand modèle de langage).
5. Index restreint pour les documents. Un agent qui cherche dans vos procédures n’a pas besoin de voir tout le partage de fichiers : un index dédié, avec pgvector ou Qdrant, suffit.

Le raisonnement vaut pour l’ensemble du système. L’IA agentique ne change pas la question du moindre privilège, elle la rend plus visible, puisque chaque droit accordé devient un outil que le modèle peut appeler. La démarche d’intégration à un outil métier est détaillée dans comment intégrer un agent IA à votre CRM ou votre outil métier.

Comment se protéger de l’injection de prompt venue d’un outil ?

Le principe est simple : toute donnée qui revient d’un outil est une entrée non fiable, jamais une instruction. Une fiche client, un ticket, un e-mail contiennent du texte rédigé par quelqu’un d’extérieur, et rien n’empêche ce texte de porter une consigne adressée au modèle.

Trois protections se cumulent. La séparation des rôles, d’abord : un contenu d’outil reste une donnée, il n’est jamais fusionné avec les instructions système du prompt. La confirmation humaine, ensuite, sur les enchaînements sensibles : lire une donnée puis envoyer un message, rembourser ou modifier une commande suppose une validation par une personne. Les permissions côté serveur, enfin, font que même un agent manipulé ne peut pas appeler ce qu’il n’a pas le droit d’appeler.

Ajoutez deux précautions d’exploitation. Un serveur MCP tiers est du code que vous exécutez : il se lance dans un conteneur (Docker), avec un accès réseau restreint et un compte de service dédié. Et les réponses d’outil gagnent à passer par un filtre de sortie, par exemple Guardrails, avant de revenir vers l’agent. Le sujet est proche de la prévention des injections de prompt dans vos agents, avec une différence : ici l’attaque arrive par une donnée métier, pas par la question d’un utilisateur.

MCP ou n8n : comment choisir ?

MCP donne à un agent un accès direct et structuré à vos outils ; n8n, Make ou Zapier enchaînent des étapes dans un ordre fixé à l’avance, sur un déclencheur.

• Serveur MCP : le choix de l’action se fait à l’exécution, sur un contenu qui varie. Convient à l’assistance dans un outil métier, quand l’agent doit lire, croiser et proposer.
• Workflow n8n : le chemin est connu d’avance (facture reçue, extraction, écriture comptable, notification). Convient aux traitements répétitifs, plus faciles à tester et à rejouer.

L’erreur courante consiste à confier à un agent MCP un process d’automatisation IA qui ne varie jamais. Un workflow y répond avec moins de surface de risque et des tests plus simples. L’inverse est fréquent aussi : un workflow saturé de conditions finit par réimplémenter un raisonnement que l’agent fait mieux.

Ce qu’il faut journaliser pour expliquer une décision

Journalisez chaque appel d’outil : identité de l’agent, nom de l’outil, paramètres utiles, statut, latence, coût, identifiant de conversation. Sans cette trace, une question du type « pourquoi cette fiche a-t-elle été modifiée mardi » reste sans réponse.

La journalisation sert à trois choses : répondre à un métier ou à un auditeur, alimenter les evals (les tests qui mesurent ce que l’agent fait réellement sur vos cas), et détecter une dérive, par exemple un outil appelé dix fois plus souvent qu’avant. On outille ces traces avec Langfuse, LangSmith ou OpenTelemetry, complétées par les journaux du serveur MCP lui-même. Cette partie, que l’on range dans le LLMOps, rejoint les sujets plus larges d’evals, garde-fous et observabilité d’un service d’IA en production.

La checklist avant d’ouvrir un serveur MCP

Cinq questions à trancher avant la première mise en production. Chaque point laissé de côté devient un incident à traiter plus tard.

1. Chaque outil exposé est-il nécessaire au cas d’usage retenu ?
2. Les écritures sont-elles limitées à des champs nommés, avec validation humaine sur les actions sensibles ?
3. Un agent manipulé par une donnée piégée peut-il faire autre chose que ce que son compte de service autorise ?
4. Les appels sont-ils tracés, avec de quoi reconstituer une décision ?
5. Le serveur tourne-t-il isolé, avec un accès réseau et un compte dédiés ?

Un premier serveur MCP bien borné se conçoit en quelques jours : lecture seule au départ, un ou deux outils d’écriture proposés à la validation, traces activées. On élargit ensuite le périmètre à mesure que les mesures le justifient, jamais sur une impression. C’est le travail que l’on mène sur les agents IA sur mesure : cadrage du cas d’usage et des données accessibles, écriture des serveurs MCP concernés, tests sur des cas réels, puis mise en production avec les garde-fous ci-dessus. Le cadrage d’un premier serveur prend une séance : cas d’usage, outils concernés, données réellement nécessaires.