MCP

Un contrat plutôt qu'une intégration

Sans standard, chaque connexion entre un assistant et un logiciel demande un développement dédié. Un accès au système de fichiers, au courriel, à une base de données ou à un outil métier se code au cas par cas, avec ses formats et ses erreurs. MCP définit un vocabulaire commun : quels outils existent, quels paramètres ils attendent, ce qu'ils renvoient. Un serveur conforme expose ces informations, et un client peut les découvrir à l'exécution.

Le protocole repose sur des messages structurés, généralement transportés en JSON, sur une connexion locale ou distante. Il prévoit la découverte des capacités, l'appel d'outils, la lecture de ressources et la récupération de modèles de consignes. L'intérêt est la réutilisation : un même serveur sert plusieurs assistants, et un assistant peut se connecter à plusieurs serveurs sans code spécifique pour chacun. La norme est ouverte et plusieurs éditeurs la mettent en œuvre.

Trois rôles

Un hôte est l'application que l'utilisateur manipule : un éditeur de code, un logiciel de bureau, un chat interne. Il contient un ou plusieurs clients, qui maintiennent chacun une connexion vers un serveur. Le serveur expose des outils, des ressources ou des consignes, et exécute les demandes. Cette séparation permet de cloisonner les droits : un serveur pour les fichiers du projet, un autre pour la messagerie, un troisième en lecture seule sur une base.

La découverte est dynamique. L'hôte interroge le serveur, reçoit la liste des outils et leurs schémas, puis les présente au modèle ou les utilise selon sa politique. Ce fonctionnement explique l'intérêt pour les agents : l'outillage devient une configuration, non un développement. Il explique aussi le risque : un serveur ajouté sans contrôle élargit immédiatement ce que l'assistant peut faire, y compris lire des fichiers ou envoyer des messages au nom de l'utilisateur.

Sécurité et périmètre

Un serveur MCP est un programme qui agit avec les droits de l'utilisateur ou du service qui le lance. Sa compromission, ou sa mauvaise configuration, ouvre un accès direct. Trois précautions s'imposent : n'installer que des serveurs dont la source est connue, limiter les identifiants aux opérations nécessaires, et journaliser les appels. Les outils en écriture méritent une confirmation explicite, surtout lorsqu'ils touchent à des données clients ou à des systèmes de production.

Le contenu renvoyé par un serveur peut aussi porter une instruction malveillante. Si un document récupéré contient une phrase qui incite l'assistant à effectuer une action, le modèle peut la suivre. Cette faille recoupe l'injection de prompt et ne se règle pas par le protocole. Il faut traiter les données externes comme non fiables, séparer la lecture de l'exécution et valider les paramètres côté serveur, indépendamment de ce que le modèle demande.

Ce que cela change

Pour un éditeur de logiciel métier, exposer un serveur MCP revient à rendre ses fonctions utilisables par des assistants, sans construire une intégration par client. Pour une entreprise, cela permet de brancher un assistant interne sur ses outils existants avec un travail d'adaptation limité. La condition reste la même : les droits, les journaux et les procédures d'incident doivent être définis avant la mise en service, pas après le premier incident venu.

Le protocole ne dit rien de la qualité des outils exposés. Un outil mal nommé, mal documenté ou aux paramètres ambigus sera mal utilisé, quel que soit le modèle. La description destinée au modèle fait partie de l'interface et mérite le même soin qu'une documentation d'API. Une entreprise qui adopte MCP gagne à désigner un responsable du catalogue d'outils, chargé de vérifier les ajouts et de retirer les accès devenus inutiles.