MCP : le protocole qui rend les agents branchables

Le Model Context Protocol, ou MCP, est un protocole ouvert porté par Anthropic qui standardise la façon dont une application d’IA accède à des outils, à des données et à des modèles d’instructions externes. Il remplace une intégration écrite à la main pour chaque couple modèle et outil par une interface commune.

Son architecture tient en trois rôles. L’hôte est l’application dans laquelle travaille l’utilisateur, un assistant ou un environnement de développement. Le client est la partie de l’hôte qui parle le protocole. Le serveur est un petit programme qui expose un système, une base documentaire, un outil de tickets, un référentiel produit, sous une forme que n’importe quel client compatible sait lire.

Un serveur peut exposer trois types d’éléments : des outils, c’est-à-dire des actions que le modèle peut appeler ; des ressources, c’est-à-dire des données qu’il peut lire ; et des invites, des modèles d’instructions prêts à l’emploi. Les échanges suivent un format de messages standard, en local comme à travers le réseau.

L’idée n’est pas neuve. Les plugins ChatGPT avaient déjà montré qu’un modèle pouvait appeler des services décrits par un contrat. Ce que vise un protocole ouvert, c’est que ce contrat ne dépende plus d’un fournisseur.

Un protocole d’outils s’attaque à la dette d’intégration, ce code sur mesure qui s’accumule entre les modèles et les outils internes d’une organisation et qu’il faut sans cesse reprendre.

Jusqu’ici, brancher un modèle sur un outil interne demandait du code spécifique : une couche d’appel, une conversion de format, une gestion d’erreurs, une reprise des droits d’accès. Ce code était refait pour chaque outil, et il était à reprendre à chaque changement de modèle.

Dans une organisation qui a une dizaine d’outils métier, cela produit une dette d’intégration qui dépasse rapidement le coût du système lui-même. Le phénomène est connu côté modèles, où une couche d’abstraction rend le modèle remplaçable ; il restait entier côté outils.

Un protocole commun ne rend pas les modèles plus intelligents : il rend l’intégration transposable, parce que le serveur qui expose un outil est écrit une fois et sert quel que soit le modèle placé en face.

Le serveur qui expose votre outil de gestion documentaire devient un actif durable. C’est un déplacement du même ordre que celui qu’on a connu sur les bases de données quand un pilote standard s’est imposé. L’intérêt n’est pas conceptuel, il est comptable : la valeur de ce qu’on écrit ne s’évapore plus au changement de fournisseur.

La dernière ligne est la plus importante. Le protocole supprime une partie du travail d’écriture ; il ne supprime aucune des décisions sur ce qu’on expose, à qui, et avec quels droits.

Rendre les outils faciles à brancher rend aussi facile d’en brancher trop, et chaque outil ajouté rend le choix du modèle plus incertain et élargit la surface de ce qui peut mal se passer.

Un agent qui dispose de nombreuses actions voisines prend de moins bonnes décisions qu’un agent qui en a peu, parce que le choix lui-même devient une source d’erreur. Deux outils dont les descriptions se recouvrent, « rechercher un dossier » et « consulter un dossier », suffisent à créer une ambiguïté que le modèle tranchera au hasard.

La discipline reste donc la même que celle décrite dans le périmètre avant l’autonomie : on n’expose que ce qui est nécessaire au cas d’usage, et on justifie chaque ajout.

Il n’existe pas de nombre idéal d’outils à exposer à un modèle, mais un critère : le périmètre doit rester lisible par le responsable métier qui le valide et diagnosticable par l’équipe qui l’exploite. Plus la liste s’allonge, plus le modèle hésite et plus les erreurs deviennent difficiles à attribuer.

La parade la plus efficace consiste à regrouper les opérations proches en un outil unique aux paramètres clairs, plutôt que de multiplier des outils qui se ressemblent. Les agents qui atteignent la production ont en général un périmètre court. Ce n’est pas une frilosité : c’est ce qui rend ce périmètre validable.

Un périmètre qu’un non-technicien ne peut pas lire en cinq minutes ne sera pas validé, et le projet s’arrêtera au déploiement. C’est le constat détaillé dans agents en entreprise : où s’arrêtent les projets.

La description d’un outil exposé à un modèle doit donner le nom, les paramètres admissibles, ce que l’appel modifie, et ce qu’il faut faire en cas de doute. Le dernier point est celui qui manque partout.

Une description qui explique ce que l’outil fait sans dire ce qu’il modifie laisse le modèle décider seul du caractère engageant de l’action. Une description qui ne prévoit pas le doute pousse à l’improvisation.

J’ajoute systématiquement une ligne indiquant si l’appel est réversible, information que le système utilise pour déclencher une validation humaine. Les paramètres gagnent à être contraints par un schéma strict, dans l’esprit des sorties structurées. Cette structure se teste comme le reste, selon la méthode de construire un jeu de tests en une journée.

Brancher un outil devient trivial ; décider qu’un modèle a le droit de l’appeler reste une décision de gouvernance, et la facilité technique déplace le risque sans le réduire.

Le schéma que je rencontre est constant : une équipe expose cinq outils parce que c’est simple, puis découvre que l’un d’eux permet une écriture qu’aucun responsable métier n’a validée.

La parade tient en une demi-journée d’atelier au cadrage : lister les outils exposés, classer leurs actions par réversibilité, faire valider le classement par celui qui en répondra. Certaines actions ne doivent tout simplement pas être confiées au modèle, pour les raisons exposées dans ce qu’on ne délègue jamais à un modèle. Le cadre complet figure dans le périmètre avant l’autonomie.

Exposer un outil métier à un agent par un protocole commun se fait en six étapes, dont la moitié relève de la décision métier et non de l’écriture de code.

1. Partir du cas d’usage : quelles questions ou quelles tâches l’agent doit-il traiter, et lesquelles sont hors périmètre.
2. Choisir le domaine métier et lui consacrer un serveur : les dossiers clients, le référentiel produit, les contrats.
3. Lister les actions nécessaires et elles seules, en séparant les lectures des écritures, puis regrouper celles qui se recouvrent.
4. Classer chaque action par réversibilité et faire valider ce classement par le responsable métier ; les actions irréversibles appellent une validation humaine.
5. Rédiger les descriptions : nom, paramètres admissibles, effet de l’appel, réversibilité, conduite en cas de doute, réponse en cas d’erreur.
6. Journaliser et tester : chaque appel est tracé avec sa demande d’origine, et un jeu de cas vérifie que le modèle choisit le bon outil et s’abstient quand il le doit.

Les étapes 1, 3 et 4 sont celles qu’un audit IA vérifie en premier, parce que ce sont celles qu’on saute quand le branchement devient facile.

Les erreurs les plus fréquentes quand on expose des outils à un agent viennent de la facilité même du branchement : on expose trop, trop largement, et on laisse au modèle des décisions qui reviennent au système.

• Exposer un accès générique, une requête libre sur une base, au lieu d’actions nommées et bornées.
• Confier les droits au modèle en lui demandant de ne pas faire certaines choses, plutôt que de les interdire côté serveur.
• Découper par système technique plutôt que par domaine métier, ce qui oblige à tout reprendre quand l’outillage change.
• Laisser des outils qui se recouvrent, source d’hésitation et d’appels erronés.
• Oublier le cas d’erreur : un outil qui renvoie une réponse vague pousse le modèle à inventer une suite.
• Ne pas journaliser la demande d’origine, ce qui rend impossible de comprendre après coup pourquoi un appel a eu lieu.

Ces erreurs ne sont pas propres à un protocole. On les retrouve à l’identique quand un agent pilote un écran au lieu d’appeler une interface.

Avec un protocole d’outils, la valeur quitte le connecteur et retourne dans le système d’information : dans la propreté des données, la précision des actions et la fiabilité des droits exposés.

La conséquence à moyen terme est que la valeur se déplace encore. Elle n’est plus dans l’accès au modèle, ni même dans le connecteur : elle est dans la qualité de ce que l’outil expose.

Autrement dit, elle retourne exactement là où elle était avant l’IA générative : dans le système d’information. Une organisation dont les référentiels sont tenus et les droits clairement définis tirera parti d’un protocole commun beaucoup plus vite qu’une organisation qui découvrira, en branchant, l’état réel de ses données.