Model Context Protocol : le contexte, grand oublié du débat

Amanda Rueda, Staff Product Manager, AI, chez GitLab partage son analyse sur le sujet.

Pour certains cas d’utilisation à petite échelle, les sceptiques n’ont pas tout à fait tort, mais leur argumentation ne tient pas dès lors que l’on dépasse le cadre du projet individuel pour aborder les systèmes agentiques que les entreprises cherchent à construire.

Là où les sceptiques marquent un point

Lorsqu’un seul utilisateur est impliqué et que la confiance est implicite, recourir à un serveur MCP peut introduire une complexité inutile. Pour connecter un assistant d’IA local, automatiser une tâche personnelle ou exécuter un script isolé sur sa propre machine virtuelle, un appel d’API direct est généralement le choix le plus simple et le plus efficace. Dans ce contexte précis, les développeurs n’ont pas tort.

Là où l’argument ne tient pas

Les systèmes agentiques d’entreprise ne reposent pas sur un modèle à développeur et à périmètre de confiance uniques. Les agents opèrent à travers des équipes, des systèmes et des organisations, souvent au nom d’utilisateurs qui ignorent même qu’un agent est impliqué. Dans ces environnements, les appels d’API directs commencent à poser des problèmes qu’aucune liste d’autorisation ne peut résoudre de manière fiable.

La délégation d’identifiants constitue l’un des premiers points de friction. Construire une plateforme qui exécute des agents pour le compte de clients d’entreprise soulève rapidement des questions concernant l’identité de l’agent, l’héritage des autorisations et le fait de savoir s’il s’exécute en tant que compte de service. Il n’existe pas d’approche universelle, mais un mauvais choix peut avoir de lourdes conséquences.

Un agent avec un accès excessif expose l’entreprise à des risques en matière d’audit et de conformité. À l’inverse, un accès insuffisant l’amène à échouer silencieusement, ce qui érode progressivement la confiance dans la plateforme. Les acheteurs en entreprise dans les secteurs réglementés soulèvent cette problématique avant même la revue de sécurité officielle.

Amanda Rueda, Staff Product Manager, AI, chez GitLab

En France, cette préoccupation n’est pas abstraite. Selon une étude de l’INSEE, 58 % des entreprises françaises de 250 salariés ou plus utilisent déjà au moins une technologie d’IA. Le cabinet de conseil et d’audit Deloitte, quant à lui, constate que le principal défi des entreprises n’est plus l’adoption, mais la mise à l’échelle, et que la gouvernance représente désormais le principal goulot d’étranglement.

Dans les environnements réglementés, la mention « c’est l’IA qui l’a fait » ne constitue pas une donnée suffisante pour un audit. Les équipes doivent être en mesure de répondre à trois questions fondamentales : qu’a fait l’agent, pour le compte de qui, et en vertu de quelle autorité. Ces informations doivent être intégrées au système dès sa conception, et non reconstituées à partir des logs après un incident. Une intégration directe via API est incapable de fournir cette traçabilité, contrairement à une implémentation MCP bien conçue, qui met en évidence le contexte nécessaire au niveau de l’appel d’outil et capture le serveur sollicité, les identifiants utilisés et le périmètre ayant autorisé chaque action.

Une liste d’autorisation n’est pas synonyme de gouvernance

Lorsqu’on s’interroge sur la capacité d’un agent à accéder à des ressources auxquelles il ne devrait pas avoir accès, le réflexe consiste à recourir à une liste d’autorisation. Définir les outils autorisés, les vérifier avant chaque exécution, et accomplir la tâche. Cette approche donne l’apparence d’une gouvernance parce qu’elle s’apparente à une politique. Or, la puissance d’une politique dépend du système chargé de la faire respecter. En pratique, les listes d’autorisation échouent en raison de configurations erronées, de comportements inattendus des agents et de cas limites que personne n’avait anticipés lors de leur rédaction initiale.

L’option la plus durable est le principe du moindre privilège structurel. Lorsque la connexion MCP d’un agent n’expose que les outils strictement nécessaires à sa tâche, l’agent ne peut pas dépasser ce périmètre. Pour les équipes de sécurité évoluant dans des environnements réglementés, il existe une différence fondamentale entre « l’agent est conçu pour ne pas dépasser son périmètre » et « l’agent respecte les règles ».

Ce qui reste à améliorer

Le MCP génère encore des frictions dans deux domaines.

Le provisionnement de serveurs à périmètre de capacités reste trop manuel. Lorsqu’une configuration correcte exige une connaissance approfondie de l’infrastructure, les administrateurs ont souvent tendance à l’ignorer et à se rabattre sur des connexions à large portée, avec une liste d’autorisation comme filet de sécurité. Tant que le secteur ne rendra pas ce provisionnement accessible aux non-spécialistes, l’adoption à grande échelle restera bloquée.

La couche opérationnelle de gestion des connexions MCP doit être accessible aux équipes de sécurité et de plateforme, et non uniquement aux équipes de développement ayant réalisé l’intégration initiale. Un administrateur devrait pouvoir visualiser toutes les connexions actives de son environnement, comprendre ce que chacune d’entre elles expose et identifier qui l’utilise, sans avoir à lire un fichier de configuration ni à retrouver le développeur d’origine.

Pour les organisations qui déploient des agents à grande échelle, ces exigences sont essentielles.

Ce qu’exige réellement le passage à l’échelle en entreprise

La défaillance d’un modèle de gouvernance se manifeste par des incidents. Des agents autonomes qui opèrent à l’échelle de l’entreprise détecteront ces failles avant vous. Si votre entreprise ne dispose que d’une liste d’autorisation, la marche à suivre est claire : vérifiez les données auxquelles vos agents ont accès, comparez-les à leurs besoins réels, et mettez en place des contrôles structurels avant que les failles ne se transforment en incidents.