Le protocole MCP expliqué : brancher une IA sur vos outils

Le MCP, protocole IA porté par le projet Model Context Protocol, répond à un problème d’une banalité absolue : un assistant conversationnel ne sert pas à grand-chose s’il ne voit rien de votre entreprise. Pour qu’il devienne utile, il faut lui donner accès à vos documents, à votre outil de gestion, à votre messagerie. Et jusqu’ici, chaque équipe rebranchait tout cela à sa façon, pour chaque assistant.

MCP est une spécification ouverte qui normalise ce branchement. L’idée n’a rien de révolutionnaire, et c’est précisément sa qualité : c’est le même raisonnement que celui qui a produit les connecteurs de bases de données standardisés ou les formats d’échange communs. On ne gagne pas en puissance, on gagne en fatigue évitée.

Cet article explique ce que le protocole normalise, ce qu’il ne règle pas du tout, à quoi ressemble un branchement simple, et pourquoi la vraie question à trancher avant de l’ouvrir n’est pas technique mais concerne les droits accordés au modèle.

Ce que le MCP, protocole IA d’intégration, normalise

MCP décrit une relation entre deux rôles. D’un côté un client : l’application qui héberge le modèle (un assistant de bureau, un environnement de développement, un agent maison). De l’autre un serveur : un petit programme qui expose une capacité, par exemple l’accès à un dossier de documents, à une base de données ou à une interface de programmation métier.

Les échanges suivent un format de messages standard, et la spécification définit trois choses qu’un serveur peut mettre à disposition :

• Des outils : des actions que le modèle peut déclencher, avec leurs paramètres décrits (créer un ticket, rechercher un client, envoyer un message).
• Des ressources : des contenus que le modèle peut lire (un fichier, un enregistrement, le résultat d’une requête).
• Des modèles d’invite : des consignes préparées et paramétrées, proposées par le serveur pour un usage donné.

Le protocole prévoit également la découverte : le client demande au serveur ce qu’il sait faire, et reçoit la liste avec la description de chaque capacité. C’est ce mécanisme qui rend les connexions interchangeables, puisque le client n’a rien à savoir d’avance du serveur qu’il rencontre.

Deux modes de transport coexistent : une communication locale entre deux processus sur la même machine, et une communication par HTTP pour un serveur distant. Le premier convient à un poste de travail, le second à un service partagé par une équipe.

Pourquoi une interface commune change la vie des équipes

Le bénéfice ne se voit pas sur le premier branchement, il se voit sur le dixième. Sans standard, connecter cinq assistants à six systèmes internes demande trente intégrations à écrire et à maintenir. Avec une interface commune, vous écrivez six serveurs, et n’importe quel client compatible s’y branche : onze objets à maintenir au lieu de trente.

Ce calcul est le même que celui qui justifie tous les standards d’intégration. Il produit trois effets concrets pour une équipe technique :

1. L’intégration d’un assistant IA cesse d’être un projet jetable. Vos connecteurs survivent au changement d’outil, ce qui réduit fortement la dépendance à un fournisseur.
2. Les connecteurs deviennent des composants avec un cycle de vie propre : versionnés, testés, documentés, avec un propriétaire identifié, au lieu d’être noyés dans la configuration d’un produit.
3. L’écosystème existant devient réutilisable. Le projet publie un dépôt de serveurs de référence pour des systèmes courants, et beaucoup d’éditeurs fournissent désormais le leur, ce qui évite de partir d’une page blanche.

Pour une équipe qui a déjà bâti des intégrations à la main, notamment autour d’un outil de gestion commerciale, la logique est très proche de celle décrite dans notre article sur la connexion d’un CRM à ses autres outils : ce qui coûte cher, ce n’est jamais la première connexion, c’est le maintien des vingt suivantes.

À quoi ressemble un branchement simple

Prenons un cas courant : donner à un assistant l’accès en lecture aux comptes rendus de projet stockés dans un dossier partagé, pour qu’il réponde aux questions de l’équipe sur l’historique des décisions.

1. Choisir ou écrire le serveur. Pour un accès à des fichiers, un serveur de référence existe. Pour un système métier interne, vous en écrivez un : c’est un programme d’une centaine de lignes qui déclare deux ou trois outils et les implémente à l’aide de bibliothèques officielles, disponibles dans plusieurs langages.
2. Décrire les capacités. Chaque outil porte un nom, une description en langage naturel et un schéma de paramètres. Cette description est lue par le modèle : elle fait partie du travail de conception, pas de la documentation. Une description floue produit des appels approximatifs.
3. Déclarer le serveur auprès du client. L’application hôte reçoit l’adresse du serveur et ses paramètres de connexion. Elle interroge le serveur, découvre les capacités et les met à disposition du modèle.
4. Restreindre. Le serveur n’expose que le dossier concerné, en lecture seule, avec un compte de service dédié. C’est l’étape que l’on saute en démonstration et qu’il ne faut jamais sauter en production.

Une fois branché, l’assistant peut lister les comptes rendus, lire ceux dont il a besoin, et citer ses sources. On retrouve exactement la logique décrite dans notre article sur le RAG appliqué aux documents d’entreprise, avec une différence de tuyauterie : ici, le modèle demande le document au moment où il en a besoin, au lieu de recevoir des extraits préparés à l’avance. Les deux approches se complètent plus qu’elles ne s’opposent.

Les droits accordés au modèle : la vraie décision

Brancher un serveur MCP, c’est accorder des droits à un système qui décide seul quand les utiliser. La question n’est pas « que peut faire l’outil ? » mais « qu’est-ce que je consens à ce qu’il fasse sans me demander ? ».

Quatre règles minimales, valables quel que soit le serveur :

• Compte dédié et périmètre réduit. Jamais le compte d’un administrateur, jamais un accès à toute une base quand un sous-ensemble suffit.
• Séparation lecture et écriture. Commencez en lecture seule. Les actions qui modifient quelque chose méritent une validation humaine explicite, au moins pendant les premières semaines.
• Journalisation systématique. Chaque appel, avec ses paramètres, son horodatage et son résultat. C’est indispensable pour comprendre un incident, et pour prouver ce qui s’est passé.
• Méfiance envers les contenus lus. Un document, un ticket ou un courriel peut contenir un texte rédigé pour piéger le modèle et lui faire déclencher une action. Un serveur qui lit des contenus externes ouvre cette porte, et elle se referme par des droits restreints plus que par des consignes.

Ces précautions rejoignent celles que nous détaillons dans notre article sur la façon de sécuriser un agent IA. Le protocole ne dispense d’aucune d’entre elles.

Ce que MCP ne règle pas

Un standard d’intégration ne résout que le problème de l’intégration. Il ne dit rien de la pertinence de ce que le modèle décide d’en faire.

Concrètement, connecter une IA à ses outils par ce biais ne garantit pas que l’assistant appellera le bon outil au bon moment, ne réduit pas le coût d’usage (au contraire, un modèle qui a beaucoup d’outils à disposition consomme davantage), ne remplace pas la gouvernance des données, et ne dispense pas de mesurer si l’usage apporte réellement quelque chose. La normalisation des interfaces entre agents et systèmes reste par ailleurs un chantier plus large, que nous suivons dans notre article sur l’interopérabilité des agents IA.

Un point de conception souvent découvert trop tard : au-delà d’une quinzaine d’outils exposés simultanément, la qualité du choix se dégrade. Mieux vaut plusieurs serveurs spécialisés, activés selon le contexte de travail, qu’un serveur universel qui expose tout.

Faut-il s’en occuper maintenant ?

Si vous exploitez déjà des assistants connectés à vos systèmes, oui : le protocole MCP standardise ce que vous faites déjà, et l’effort de reprise est modeste comparé au coût de maintenance de connecteurs propriétaires. Si vous n’avez encore rien branché, la question prioritaire reste ailleurs : quel usage, pour qui, avec quel gain attendu.

La bonne façon de commencer tient en un après-midi : un serveur en lecture seule sur une source documentaire limitée, un usage précis, des journaux activés, et une évaluation à quatre semaines. Le reste, y compris la question de savoir quel assistant utilisera ce serveur, se décidera plus facilement une fois que la connexion existe et qu’elle appartient à votre équipe plutôt qu’à un produit. Pour le vocabulaire sous-jacent, notre article qu’est-ce qu’un agent IA pose les briques que ce protocole vient relier.