MCP : le protocole qui rend les agents branchables

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.

Un protocole commun ne rend pas les modèles plus intelligents. Il rend l'intégration transposable : le serveur qui expose votre outil de gestion documentaire est écrit une fois, et sert quel que soit le modèle placé en face.

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.

Rendre les outils faciles à brancher rend aussi facile de brancher trop d'outils.

Un agent qui dispose de vingt actions prend de moins bonnes décisions qu'un agent qui en a cinq, parce que le choix lui-même devient une source d'erreur. Et chaque action supplémentaire élargit la surface de ce qui peut mal se passer.

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.

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, la propreté des données, la précision des actions, la fiabilité des droits.

Autrement dit, elle retourne exactement là où elle était avant l'IA générative : dans le système d'information.

Brancher un outil devient trivial ; décider qu'un modèle a le droit de l'appeler reste une décision de gouvernance. La facilité technique déplace le risque, elle ne le réduit pas.

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. Le cadre complet figure dans le périmètre avant l'autonomie.

Au-delà d'une dizaine d'outils exposés, le modèle choisit mal et les erreurs deviennent difficiles à diagnostiquer. C'est une limite d'exploitation, pas une contrainte du protocole.

Les agents qui atteignent la production ont trois ou quatre outils. Ce n'est pas une frilosité : c'est ce qui rend le périmètre lisible par le responsable métier qui doit le valider, et diagnosticable par l'équipe qui l'exploite.

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, le constat détaillé dans agents en entreprise : où s'arrêtent les projets.

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. Cette structure se teste comme le reste, selon la méthode de construire un jeu de tests en une journée.