MCP : ce que le protocole change pour les intégrations

Un agent n’est utile que s’il atteint les outils où se fait le travail. Chaque plateforme d’agents doit donc se connecter à des dizaines de logiciels, chacun avec son API, son authentification et ses particularités. Le Model Context Protocol, ou MCP, propose un contrat commun pour ces connexions. Précisons-le d’emblée : Scalt n’intègre pas MCP aujourd’hui. Nous suivons le protocole de près, et cet article explique ce qu’il change, ce qu’il ne règle pas, et ce que nous en attendons.

Le problème des intégrations sur mesure

Chaque connecteur maison est une dette. Il faut gérer l’authentification, la pagination, les limites d’appels, les changements de version de l’API, et recommencer pour l’outil suivant. Et le jour où l’API change, c’est souvent en production qu’on le découvre. Quand chaque application d’IA écrit ses propres connecteurs vers chaque outil, le travail se multiplie, et les mêmes erreurs se répètent d’un connecteur à l’autre.

Chaque connecteur doit aussi reproduire les mêmes garanties : respecter les droits de l’utilisateur, tracer les appels, résister aux erreurs et aux pannes de l’outil. Ce sont ces garanties, plus que le code lui-même, qui coûtent cher à maintenir.

Ce qu’est le protocole

MCP est un protocole ouvert, fondé sur des messages JSON-RPC 2.0, qui standardise la façon dont une application d’IA se connecte à des sources de données et à des outils. Il s’inspire du Language Server Protocol, qui a fait la même chose pour la prise en charge des langages de programmation dans les éditeurs de code. Il distingue trois rôles :

• L’hôte : l’application d’IA qui ouvre les connexions, par exemple un assistant ou une plateforme d’agents.
• Le client : le connecteur, à l’intérieur de l’hôte, qui parle à un serveur.
• Le serveur : le service qui expose du contexte et des capacités.

Un serveur peut offrir trois choses : des ressources, c’est-à-dire des données à consulter ; des prompts, des modèles de messages ou de tâches ; et des outils, des fonctions que le modèle peut exécuter. La spécification est versionnée par date ; la plus récente, au moment où nous écrivons, est datée du 28 juillet 2026.

Ce qu’il change

Le changement principal est un déplacement du travail. Un serveur écrit une fois pour un outil peut servir à toutes les applications compatibles. L’éditeur de l’outil peut maintenir son propre serveur, au plus près de son API. Et l’application d’IA découvre les outils disponibles et leur description, au lieu de les coder un par un.

Pour une entreprise, cela promet plus de choix : brancher un nouvel outil sans attendre qu’un éditeur ait écrit le connecteur, ou exposer ses propres systèmes internes une fois pour toutes. C’est une promesse réelle, à condition de ne pas oublier ce que le protocole ne règle pas.

Les questions de sécurité

La spécification le dit elle-même : un outil exposé par un serveur revient à de l’exécution de code arbitraire, et doit être traité avec prudence. Les descriptions d’outils doivent être considérées comme non fiables, sauf si elles viennent d’un serveur de confiance. L’hôte doit obtenir le consentement explicite de l’utilisateur avant d’appeler un outil ou de partager ses données. Le protocole ne peut pas imposer ces principes lui-même : c’est aux applications qui l’implémentent de le faire.

Les bonnes pratiques publiées avec la spécification détaillent les attaques connues. Un serveur ne doit pas accepter un jeton d’accès qui n’a pas été émis pour lui, ni le transmettre tel quel à un autre service. Un serveur intermédiaire mal conçu peut devenir un « adjoint confus » qui agit avec des droits qui ne sont pas ceux de l’utilisateur. Et des droits trop larges accordés d’emblée transforment un jeton volé en accès à tout. S’y ajoute un risque que nous connaissons bien côté données : le contenu renvoyé par un outil peut contenir des instructions cachées, qui se retrouvent dans le contexte de l’agent.

Ce que nous en attendons

Si nous intégrons MCP, ce sera à ces conditions :

• L’agent agit au nom de l’utilisateur, avec ses droits, et jamais avec un compte technique aux droits étendus.
• Les actions en écriture restent soumises aux validations que vous avez définies.
• Chaque appel d’outil est tracé dans le dossier de l’exécution.
• Le contenu renvoyé par un outil est contrôlé comme n’importe quelle autre entrée.

Nous ne donnons pas de date. Nous préférons annoncer une intégration quand elle respecte ces conditions, plutôt qu’une compatibilité de principe. Si votre équipe utilise déjà des serveurs MCP, parlez-nous de vos usages : ils nous aident à décider.

Questions fréquentes