Un assistant qui connaît la procédure commerciale mais ne peut ni vérifier un stock, ni ouvrir un dossier client, ni préparer une action reste un outil de consultation. Dès qu'il accède aux logiciels de l'entreprise, le problème change de nature : il faut relier un modèle de langage à des données et à des fonctions sans construire un connecteur particulier pour chaque combinaison d'outils. C'est le rôle du Model Context Protocol, ou MCP.

La promesse est technique, mais le choix est métier. MCP peut simplifier la manière dont une application IA découvre une ressource, appelle une fonction ou utilise un modèle de message. Il ne décide pas, en revanche, si l'assistant doit voir un dossier RH, modifier une commande ou envoyer un courriel. Un protocole enlève une part de la répétition dans les intégrations ; il ne remplace ni une politique d'habilitation ni un responsable qui accepte les conséquences d'une action.

La spécification MCP le décrit comme un protocole ouvert pour connecter les applications de modèles de langage à des sources de données et à des outils externes. Cette précision compte. MCP n'est pas un modèle, pas une base documentaire, pas un agent autonome et pas une solution de sécurité prête à l'emploi. C'est un langage commun entre plusieurs composants.

MCP organise le passage entre le modèle et le système d'information

Dans l'architecture prévue par le protocole, l'application qui porte l'expérience utilisateur est l'hôte. Elle crée un client pour chaque serveur MCP auquel elle se connecte. Le serveur expose alors des capacités ciblées : des ressources, des outils ou des prompts. La documentation d'architecture insiste sur une relation isolée entre un client et un serveur, tandis que l'hôte garde la coordination et les décisions d'autorisation.

Prenons un assistant de support interne. Un serveur peut lui présenter les procédures du service client comme ressources. Un autre peut fournir un outil de recherche dans le CRM. Un troisième peut proposer une fonction qui prépare un brouillon de ticket. L'assistant n'a pas besoin de connaître les détails de chaque API pour voir ce qui est disponible : il interroge les capacités annoncées par les serveurs et utilise le format défini par le protocole.

Cela ne signifie pas que tout devient interchangeable. Un serveur MCP peut envelopper une API existante, mais il faut toujours définir ses paramètres, ses erreurs, ses droits et les données qu'il retourne. Surtout, le modèle conserve sa part d'incertitude. Il peut choisir un outil inutile, mal interpréter une réponse ou proposer une action qui ne convient pas au dossier. MCP standardise l'accès ; il ne rend pas le raisonnement du modèle plus fiable.

Pour un projet d'agents IA et d'automatisation, cette distinction évite deux malentendus. Le premier serait de croire qu'un assistant relié à plus d'outils devient automatiquement utile. Le second serait de confondre la connexion à une fonction avec l'autorisation de l'exécuter. Une fonction de lecture d'un solde et une fonction qui modifie une adresse de livraison n'exposent pas le même risque, même si elles empruntent le même protocole.

La standardisation ne dispense pas de dessiner les frontières

MCP prévoit deux transports standards : stdio pour une communication directe entre processus locaux, et Streamable HTTP pour des échanges réseau. La spécification des transports demande notamment de valider l'en-tête `Origin` pour un serveur HTTP et recommande de limiter un serveur local à `127.0.0.1` plutôt qu'à toutes les interfaces réseau. Ce sont des détails d'implémentation, mais ils traduisent une réalité simple : une intégration peut élargir la surface d'accès avant même qu'un utilisateur n'ait posé sa première question.

Dans une entreprise, le point de départ doit donc être l'inventaire des capacités nécessaires. L'assistant doit-il lire une procédure, chercher un statut de commande, créer un brouillon, ou transmettre une demande ? Pour chacune, il faut définir quelle identité l'appelle, quelles données sortent du système, quelle trace est conservée et comment l'accès est retiré. Donner à un serveur un jeton valable pour un périmètre trop large parce que l'intégration est plus rapide revient à déplacer le risque dans un composant plus difficile à observer.

Les recommandations de sécurité du protocole sont explicites : les outils peuvent ouvrir des chemins d'exécution de code et les utilisateurs doivent comprendre et approuver les accès ou opérations concernés. Elles rappellent aussi qu'une configuration locale en un clic doit recueillir un consentement clair avant d'exécuter des commandes. La documentation de sécurité MCP ne transforme donc pas un serveur en produit sûr ; elle fixe un niveau d'exigence pour ceux qui le conçoivent.

Le bon périmètre est souvent plus étroit que la démonstration. Un serveur qui lit uniquement une base de procédures, avec des réponses sourcées, peut suffire à tester l'utilité d'un assistant. Une action sur le CRM peut rester en brouillon, soumise à validation, tant que les erreurs et les cas ambigus ne sont pas connus. Cette progression donne aussi une base solide à un développement IA sur mesure : l'intégration devient une suite de responsabilités explicites, pas une liste de connecteurs.

Avant d'ajouter un serveur, choisir l'action qu'il ne doit jamais faire

La question utile n'est pas "avons-nous un serveur MCP pour cet outil ?". Elle est : quelle action cet assistant peut-il préparer sans difficulté, laquelle doit-il soumettre à une personne, et laquelle doit-il ignorer ? La réponse dépend de l'impact sur un client, de la confidentialité des données, de la réversibilité et de la capacité d'une équipe à contrôler le résultat.

Cette discipline vaut aussi pour les tâches apparemment banales. Lire une documentation peut exposer des informations qui ne doivent pas circuler entre équipes. Créer un ticket peut déclencher un engagement de service. Envoyer un message peut engager l'entreprise auprès d'un client. Le protocole rend ces opérations plus accessibles à une application IA ; il ne les rend pas anodines.

Un cadrage IA permet de poser ces limites avant d'installer des serveurs et de distribuer des accès. Il commence par un cas d'usage, une source de données et une action limitée. Puis il vérifie les journaux, les erreurs, les refus et les possibilités d'arrêt. MCP est alors à sa juste place : une brique pour connecter proprement un assistant au travail réel, pas un raccourci pour lui déléguer ce que l'entreprise n'a pas encore décidé de contrôler.