Brancher l’agent sur vos outils avec MCP

Un agent qui n’a pas accès à vos outils fait de vous son presse-papiers : vous exportez la vue du CRM, vous la collez, vous recopiez la réponse. MCP supprime cette étape. C’est un protocole ouvert qui permet à un client IA (Claude, Claude Code, ChatGPT ou tout autre client compatible) d’appeler des outils exposés par un serveur : chercher dans le CRM, lire un tableur, interroger une base de données, appeler une API. Ma règle pour brancher un agent tient en trois points. Ne connecter que les systèmes que la tâche touche, commencer en lecture seule, et tester chaque connexion sur un enregistrement que vous connaissez déjà avant de lui confier quoi que ce soit de réel.

Ce que MCP change concrètement

Trois éléments entrent en jeu. Le client, c’est là où tourne l’agent. Le serveur est un petit programme placé devant un système, qui expose une liste d’outils, chacun avec un nom, une description et les paramètres qu’il accepte. Le modèle lit ces descriptions et décide quel outil appeler, avec quels arguments, et quoi faire du résultat.

Sans MCP	Avec MCP
Vous exportez un CSV et le collez dans la conversation	L’agent interroge la source quand il en a besoin
La donnée date du moment où vous l’avez copiée	La donnée est lue au moment de la tâche
L’agent rédige un résumé que vous ressaisissez dans le CRM	L’agent propose la mise à jour et, une fois autorisé, l’écrit
Personne ne sait quelles lignes l’agent a vraiment vues	Chaque appel d’outil est visible dans la session, avec ses arguments

La dernière ligne compte plus qu’il n’y paraît. Quand une réponse est fausse, vous voyez si l’agent a appelé le mauvais outil, passé le mauvais filtre ou mal lu un résultat correct. Avec le copier-coller, vous ne voyez que la mauvaise réponse. Le site du protocole détaille l’architecture si vous voulez aller plus loin.

Listez les outils que votre process touche

Ne branchez pas tout ce que vous possédez. Reprenez le process que vous avez décrit dans le chapitre sur le process existant et, pour chaque étape, notez le système concerné et s’il s’agit de lire ou d’écrire.

Étape	Système	Lecture ou écriture	Connecteur	Risque en cas d’erreur
Trouver les comptes qui collent à l’ICP	Fournisseur de données	Lecture	Serveur MCP de l’éditeur	Crédits gaspillés
Vérifier si le compte est déjà client	CRM	Lecture	Serveur MCP de l’éditeur	Prospecter un client
Consigner la qualification	Tableur partagé	Écriture	Serveur MCP du tableur	Lignes écrasées
Récupérer les deals du dernier trimestre	Base de données	Lecture	Serveur MCP de base, utilisateur en lecture seule	Requêtes lentes sur la prod
Créer la tâche pour le commercial	CRM	Écriture	Serveur MCP de l’éditeur	Tâches en double

Prenons un éditeur de logiciel de paie qui vend aux PME françaises et veut un agent pour qualifier les inscriptions entrantes. Ce tableau lui dit qu’il faut trois serveurs, dont deux en lecture seule, et exactement une écriture capable de faire des dégâts. Les cases vides servent aussi : une étape sans connecteur est soit candidate à votre propre serveur MCP, soit une étape qui reste manuelle pour l’instant.

Câbles réseau branchés sur un panneau de brassage

Lire d’abord, écrire ensuite

Chaque connexion reçoit l’accès le plus étroit qui permet à la tâche de tourner. Concrètement :

Créez un compte ou une clé API dédiés à l’agent, jamais vos propres identifiants administrateur. Le jour où quelque chose déraille, vous voulez révoquer une clé, pas votre accès.
Donnez-lui un périmètre en lecture seule les premières semaines. Pour une base de données, c’est un utilisateur qui ne peut faire que des SELECT, sur les tables dont la tâche a besoin.
Ajoutez l’écriture une action à la fois, une fois que les lectures ont été justes sur quelques dizaines de cas réels.
Laissez le client de l’agent demander confirmation avant chaque appel en écriture, tant que vous n’avez pas confiance dans cette action précise.

Les secrets restent hors du fichier d’instructions et hors de la conversation. Ils vivent dans des variables d’environnement ou dans le coffre d’identifiants du client. Les règles plus larges sur les clés, les données personnelles et ce qu’un agent ne fait jamais seul sont dans le chapitre sécurité.

Configurez la connexion

Chaque client a son propre endroit pour déclarer les serveurs. Dans Claude Code, un projet peut partager ses serveurs avec l’équipe via un fichier .mcp.json à la racine du dépôt, qui accepte les variables d’environnement : le fichier peut donc être commité sans les clés. Un serveur distant se déclare par son URL, un serveur local par la commande qui le lance.

{
  "mcpServers": {
    "crm": {
      "type": "http",
      "url": "https://mcp.your-crm.example/mcp"
    },
    "analytics_db": {
      "command": "npx",
      "args": ["-y", "your-database-mcp-server"],
      "env": {
        "DATABASE_URL": "${ANALYTICS_READONLY_URL}"
      }
    }
  }
}

Les noms de serveurs et le package sont des exemples : utilisez ceux que documente votre éditeur. La documentation MCP de Claude Code (en anglais) couvre les portées (vous seul, le projet, tous vos projets) et la commande claude mcp add si vous préférez le terminal. Dans un client de conversation comme Claude ou ChatGPT, la même chose se fait depuis un écran de connecteurs : vous collez l’URL du serveur et vous vous connectez à l’outil.

Une habitude évite beaucoup de confusion. Nommez chaque serveur d’après le système qu’il sert (crm, analytics_db, sheets_pipeline) et écrivez une ligne dans les instructions de l’agent qui dit à quoi sert chacun. Sinon, deux serveurs qui exposent chacun un outil search finiront par être confondus.

Testez chaque connexion avant la tâche

Une connexion listée n’est pas une connexion qui marche. Avant que l’agent ne travaille pour de vrai, passez ce contrôle sur chaque serveur et notez le résultat.

Contrôle	Comment	Validé quand
Le serveur répond	Demander au client l’état de ses serveurs	Connecté, outils listés
Les outils sont ceux attendus	Lire la liste des outils et leurs descriptions	Aucun outil d’écriture surprise
Une lecture renvoie la vérité	Demander un enregistrement que vous connaissez par cœur	Mêmes valeurs que dans l’interface de l’outil
Le volume est complet	Demander un total que vous pouvez vérifier	Le total correspond à la source
Une action interdite échoue	Demander une écriture sur un serveur en lecture seule	Le serveur refuse, l’agent le signale
Les erreurs sont lisibles	Demander un enregistrement qui n’existe pas	Un « introuvable » clair, pas un enregistrement inventé

La quatrième ligne est celle qu’on saute. Un agent annoncera volontiers un succès sur 200 lignes quand la source en compte 1 400, parce qu’un outil a renvoyé la première page et que rien ne lui a dit qu’il y en avait d’autres. La cinquième vérifie vos permissions, pas la bonne volonté de l’agent. Quand une routine planifiée dépend de ces serveurs, ces mêmes contrôles deviennent sa première étape, avant toute autre action.

Rangée de connecteurs avec câbles branchés

Un exemple : le serveur MCP de Derrick

J’ai cofondé Derrick, un outil d’enrichissement de données et de prospection B2B, et j’en ai construit moi-même le serveur MCP. Il permet à Claude, ChatGPT ou n’importe quel client MCP d’appeler les fonctions de données de Derrick depuis une conversation, à partir du plan Plus à 47,50 € par mois. L’usage type est exploratoire : « trouve des entreprises proches de ces trois clients, puis le responsable commercial de chacune », sur quelques dizaines de lignes, pour tester une idée de ciblage avant de construire la liste complète.

C’est aussi une bonne illustration du choix de la surface selon le travail. Pour une liste de milliers de lignes que vous voulez filtrer et inspecter, l’application web ou un tableur font mieux. Pour enrichir dans un produit ou un workflow planifié, c’est l’API. MCP sert au travail où une personne et un agent réfléchissent ensemble. Construire un TAM avec des agents IA montre un passage complet avec ce découpage.

Quand MCP n’est pas le bon choix

MCP laisse au modèle le choix de l’outil à appeler. C’est ce que vous voulez quand les étapes dépendent de ce que l’agent trouve, et ce que vous ne voulez pas quand les étapes ne changent jamais. Une synchronisation nocturne de 10 000 lignes du CRM vers l’entrepôt de données, c’est un script ou un scénario Make ou n8n : même entrée, même sortie, pas de modèle, pas de tokens dépensés. Gardez MCP pour les étapes où le jugement est justement l’enjeu.

Votre prochaine étape : reprenez le tableau des étapes de votre process, remplissez pour chacune le système, lecture ou écriture, et le connecteur, puis branchez d’abord les serveurs en lecture seule et passez les six contrôles sur chacun. Gardez les résultats : vous en aurez de nouveau besoin quand l’agent tournera seul, sur un planning.