MCP en entreprise : connecter tous vos outils n’est pas une stratégie

Connecter un assistant IA à Slack, au CRM, au support client, aux documents internes et à la facturation paraît être le raccourci évident vers une entreprise « augmentée ». Le Model Context Protocol (MCP) rend techniquement ce scénario bien plus accessible : un même client compatible peut découvrir des outils, lire des ressources et appeler des fonctions exposées par des serveurs MCP.

Mais l’accessibilité technique ne constitue pas une stratégie produit ni une politique de sécurité. Quand un modèle peut agir dans tes systèmes, le sujet ne se limite plus à la qualité de ses réponses. Il devient une question de droits d’accès, de périmètre d’action, de validation humaine et de preuve. La mauvaise approche consiste à brancher tous les connecteurs disponibles. La bonne consiste à concevoir une capacité opérationnelle étroite, observable et réversible.

MCP standardise l’accès aux capacités, pas la décision métier

Une intégration API classique est généralement écrite pour un flux précis : une application appelle un endpoint identifié, avec des paramètres connus et des règles codées. Le MCP change l’ergonomie de cette intégration pour les assistants et les agents. Un serveur MCP expose des capacités que le client peut interroger : des tools (actions appelables), des resources (contenus ou données à consulter) et, selon les implémentations, des modèles de prompts.

Le modèle ne se connecte donc pas directement à ton CRM ou à ta base de données. En pratique, le client d’agent orchestre les échanges avec un ou plusieurs serveurs MCP, puis présente au modèle les descriptions des outils disponibles. La spécification publique du protocole détaille cette architecture client-serveur et les mécanismes de découverte des capacités. Elle ne décide pas, à ta place, quel employé ou quel agent a le droit de modifier une fiche client.

C’est la nuance à garder en tête : MCP réduit le coût de connexion ; il ne réduit ni le risque métier, ni le besoin de contrôle. Un outil décrit comme update_customer peut être techniquement simple à appeler, mais il porte des questions très concrètes : quelles colonnes sont modifiables ? Peut-il toucher à un statut de consentement ? Quel est le compte de service utilisé ? Une double validation est-elle requise ?

Les plateformes d’agents et d’automatisation s’inscrivent dans ce mouvement en proposant des connecteurs, des actions et des mécanismes de gouvernance autour de l’IA. La documentation de Microsoft Copilot Studio, par exemple, présente la création d’agents connectés à des sources de connaissances et à des actions. La catégorie Zapier AI documente de son côté des fonctions d’automatisation assistées par IA. Ces produits peuvent accélérer un pilote ; ils ne remplacent pas la définition de tes règles d’autorisation.

Les cinq risques à cartographier avant le premier connecteur

Le risque d’un agent connecté vient moins d’un unique modèle que de la chaîne complète : instructions, données entrantes, descriptions d’outils, identités, API et processus métier. Voici une cartographie utilisable avant toute mise en production.

• Permissions excessives : un jeton administrateur ou le compte d’un salarié donne souvent davantage de droits que le cas d’usage n’en exige. Un assistant chargé de retrouver une commande n’a pas besoin d’exporter toute la base clients, ni de rembourser un paiement.
• Outils mal décrits : le modèle se guide sur les noms, descriptions et schémas de paramètres. Une action ambiguë, telle que archive_project, peut être confondue avec une action bénigne. Documente l’effet réel, les préconditions, les champs sensibles et le résultat attendu.
• Actions non réversibles : suppression, envoi d’e-mail, changement de prix, publication ou remboursement peuvent avoir un effet externe immédiat. L’agent ne doit pas être le dernier garde-fou sur ce type d’opération.
• Manque de traçabilité : sans journal qui relie l’utilisateur, la requête, la décision, l’appel d’outil, les paramètres et le résultat, tu ne peux ni enquêter sur une erreur ni améliorer le système de façon fiable.
• Dépendance à des serveurs tiers : installer un serveur MCP revient à introduire un composant qui peut recevoir des requêtes et manipuler des identifiants. Vérifie son éditeur, son code ou ses garanties contractuelles, son hébergement, ses mises à jour et les données qu’il traite.

Ajoute un sixième risque transversal : l’injection d’instructions. Un contenu lu par l’agent — ticket, page web, pièce jointe ou document interne — peut contenir un texte tentant de le pousser à ignorer ses consignes ou à exfiltrer des données. Traite les contenus externes comme des données non fiables, jamais comme une autorité.

Concevoir des outils que l’agent peut appeler sans deviner

Un bon outil MCP n’est pas un miroir brut de ton API. Il exprime une intention métier étroite. Au lieu d’exposer un endpoint générique capable de modifier n’importe quel champ CRM, crée une action comme prepare_customer_address_update. Elle accepte un identifiant client, une nouvelle adresse et une justification ; elle renvoie un aperçu et demande une confirmation dans l’interface avant l’écriture.

Pour chaque outil, rédige une fiche courte :

• Objectif : quelle tâche métier autorise-t-il exactement ?
• Lectures et écritures : quelles données consulte-t-il ou modifie-t-il ?
• Identité : quel compte, quel rôle et quel périmètre de données sont utilisés ?
• Préconditions : quels contrôles doivent réussir avant l’appel ?
• Réversibilité : comment annuler, corriger ou compenser l’action ?
• Validation : l’exécution est-elle automatique, confirmée par l’utilisateur ou soumise à un approbateur ?
• Journalisation : quels éléments sont conservés, et combien de temps ?

Applique aussi le principe du moindre privilège. Préfère un jeton de service dédié, limité à un environnement ou à un sous-ensemble de ressources, à l’authentification personnelle d’un administrateur. Sépare les outils de lecture des outils d’écriture. Et évite de fournir des secrets au modèle : le serveur ou la couche d’exécution doit gérer les identifiants.

Un agent peut proposer une action large. Ton système doit n’autoriser qu’une action précisément définie, dans le périmètre du rôle qui l’exécute.

Un pilote réaliste : un cas d’usage, deux outils, un responsable métier

Pour démarrer, ne lance pas un « assistant d’entreprise ». Choisis un irritant fréquent, mesurable et à faible conséquence. Exemple : aider l’équipe support à préparer une réponse sur le statut d’une commande, sans envoyer de message ni modifier la commande.

Le pilote tient volontairement dans un périmètre réduit :

1. Un cas d’usage : répondre plus vite aux demandes « où en est ma commande ? » après vérification de l’identité du client.
2. Deux outils : find_order_by_reference et get_shipment_status, tous deux en lecture seule.
3. Un propriétaire métier : un responsable support, qui valide les règles de réponse, les cas d’escalade et les indicateurs de succès.

Fixe des critères avant le lancement : taux de réponses correctement préparées, nombre d’escalades, délai moyen de traitement, appels d’outil refusés, erreurs de données et retours des agents humains. Échantillonne les conversations et les journaux chaque semaine. Si l’assistant doit ensuite déclencher un remboursement ou modifier une adresse, traite cette étape comme un nouveau produit : analyse de risque, simulation, validation humaine puis déploiement progressif.

Faire de MCP une brique contrôlée de ton système d’information

MCP est utile lorsqu’il évite de reconstruire une intégration spécifique pour chaque interface conversationnelle ou chaque agent. Mais le protocole doit rester derrière tes frontières de contrôle : catalogue d’outils approuvés, comptes dédiés, environnements séparés, quotas, listes d’actions interdites et journal d’audit exploitable.

Commence par inventorier les actions que tu accepterais qu’un assistant prépare, puis celles qu’il pourrait exécuter sous confirmation. Écarte au départ les actions financières, juridiques, irréversibles ou impliquant des données sensibles. Ensuite, livre un pilote à deux outils et nomme clairement la personne qui possède le résultat métier. Ce n’est qu’après des preuves d’usage, des logs relus et des contrôles testés que l’élargissement des connecteurs devient défendable.