À quoi sert exactement MCP ?
MCP standardise la façon dont une application qui utilise un modèle découvre et appelle des outils et des sources de contexte externes. Avant lui, connecter un agent à dix systèmes demandait dix intégrations spécifiques. Après lui, il reste une interface commune, et dix décisions d’autorisation à prendre.
La spécification a connu une révision d’ampleur le 28 juillet 2026, et sa direction est parlante : un cœur désormais sans état, la prise en charge des échanges à plusieurs allers-retours, un durcissement de l’autorisation et l’introduction d’un cadre d’extensions. Ces choix racontent une trajectoire : MCP passe d’un mécanisme de connexion à une couche que des organisations doivent pouvoir administrer.
La distinction avec A2A reste utile à garder en tête. MCP relie un agent à un outil, quand A2A relie un agent à un autre agent, ainsi que nous l’avons détaillé dans la répartition des rôles dans un système multi-agents. Les questions de sécurité, elles, se posent d’abord au niveau des outils, parce que c’est là que se produisent les effets.
Savoir qu’un outil existe ne donne pas le droit de l’utiliser
Imaginons un agent RH. Pour être utile, il pourrait avoir besoin de retrouver un collaborateur, de consulter certaines données, de générer une attestation, éventuellement de corriger une information. Un serveur MCP peut exposer ces quatre capacités sous forme d’outils, et le modèle choisira lequel appeler selon la demande.
La capacité du modèle et l’autorisation du système sont deux choses distinctes. MCP décrit ce qui est appelable ; c’est votre politique d’accès, et elle seule, qui décide de ce qui est permis.
La spécification prévoit des mécanismes d’autorisation pour les transports HTTP, adossés à OAuth, et impose notamment d’empêcher qu’un jeton émis pour une ressource soit réutilisé auprès d’une autre. C’est une garantie de plomberie, indispensable et insuffisante : elle protège le transport du droit, pas la pertinence du droit accordé.
Concrètement, qu’est-ce qu’un serveur MCP ?
Le mot serveur induit en erreur, parce qu’il évoque une machine. Un serveur MCP est un programme qui déclare une liste d’outils et de ressources, et qui répond quand on les appelle. Il peut tourner sur le poste du collaborateur, à côté de l’application qui l’utilise, ou être exposé à distance derrière une adresse HTTP.
Cette distinction est la première décision de gouvernance à prendre, et elle est souvent prise par défaut. Un serveur local hérite des droits de la personne qui l’exécute, ce qui est commode et rend l’inventaire impossible : rien ne le déclare à personne. Un serveur distant est administrable, journalisable et révocable, au prix d’une exposition réseau à protéger. Les deux modes se justifient selon les cas ; ce qui ne se justifie pas, c’est de ne pas savoir lequel est en place.
Le risque ne vient pas des briques, il vient de la chaîne
Prise isolément, chaque brique paraît raisonnable. Un modèle lit du contenu. Un serveur MCP expose des outils. Une API modifie une donnée. C’est leur enchaînement qui crée le risque :
contenu externe → interprétation par le modèle → choix d’un outil → action dans le système d’information.
Supposons un agent qui lit des documents venus de l’extérieur et qui dispose par ailleurs d’un outil d’envoi. Une instruction dissimulée dans un document peut chercher à détourner son comportement. Si ses permissions sont larges, une faiblesse au niveau du modèle devient une action réelle dans le SI.
Anthropic insiste sur ce point : l’injection de prompt change de nature avec les agents. Plus l’environnement est ouvert et plus l’agent dispose d’outils, plus les conséquences d’une manipulation réussie sont importantes.
Nous en tirons une conséquence de conception : la parade ne consiste pas à espérer que le modèle se laisse moins souvent manipuler, mais à réduire ce qu’une manipulation réussie permet d’atteindre.
La description d’un outil est aussi une entrée non fiable
Un modèle choisit un outil en lisant sa description. Cette description est du texte, fourni par le serveur, et elle entre dans le contexte au même titre qu’un document. Elle peut donc, elle aussi, porter des instructions.
C’est ce qu’on appelle l’empoisonnement d’outil, et le mécanisme est déroutant de simplicité. Un serveur déclare un outil d’apparence anodine, dont la description contient des consignes destinées au modèle plutôt qu’à l’utilisateur. Le modèle lit la description, la traite comme une instruction légitime puisqu’elle vient de son propre contexte, et modifie son comportement.
Deux conséquences pratiques en découlent. La première : ajouter un serveur MCP à une configuration n’est pas un geste plus anodin qu’installer une dépendance logicielle, et mérite le même niveau d’examen. La seconde : la description des outils exposés par vos propres serveurs devrait être revue comme du code, pas rédigée à la volée par la personne qui a écrit le connecteur.
Tous les outils ne présentent pas le même risque
Une entreprise n’a aucune raison de traiter uniformément les outils qu’elle expose. Cinq niveaux suffisent à ordonner le sujet, et le degré d’autonomie accordé devrait suivre cette échelle.
| Niveau | Exemple | Autonomie raisonnable |
|---|---|---|
| Lecture sans donnée sensible | Consulter un catalogue produit public | Autonome |
| Lecture de données internes | Rechercher un dossier client | Autonome, tracée |
| Création réversible | Créer un brouillon de ticket | Autonome, tracée |
| Modification d’un système | Corriger une fiche CRM | Validation humaine |
| Action externe ou difficilement réversible | Envoyer un courriel, annuler une commande, déclencher un paiement | Validation humaine obligatoire |
Ce découpage n’est pas qu’un exercice de classement : il fournit la matière de la décision traitée dans quelles actions exigent encore une main humaine.
Le moindre privilège n’a pas été rendu obsolète par les agents
L’arrivée des agents ne périme aucun principe historique de sécurité. Elle les rend plus difficiles à appliquer, ce qui n’est pas la même chose. Un agent devrait disposer des seuls outils nécessaires à sa mission, des seules données nécessaires à la tâche, des seules permissions nécessaires à l’action, et pendant la seule durée nécessaire.
Un agent chargé d’analyser des factures n’a aucune raison de pouvoir supprimer un fournisseur. Un agent chargé de préparer une réponse client n’a pas nécessairement besoin du droit de l’envoyer. Cette séparation suppose que l’agent soit reconnu pour lui-même et non sous les droits de l’utilisateur qui l’a déclenché, ce qui est le sujet de l’identité propre de chaque agent IA. La feuille de route publiée par le projet MCP en août 2026 va d’ailleurs dans ce sens, en plaçant l’identité des charges de travail et la délégation d’autorisation parmi ses chantiers prioritaires.
Que faut-il journaliser, et à quoi cela sert-il ?
La journalisation d’un agent est presque toujours sous-dimensionnée, parce qu’elle est conçue pour le débogage et non pour la reconstitution. Or le jour où l’on cherche à comprendre pourquoi une fiche client a été modifiée, la question n’est pas de savoir si le code a planté, mais de savoir ce que l’agent avait sous les yeux au moment de décider.
| À journaliser | Ce que cela permet de répondre |
|---|---|
| Identité appelante | Qui a agi : l’agent, avec quels droits, pour le compte de qui |
| Outil appelé et arguments | Ce qui a été demandé au système, exactement |
| Résultat retourné | Ce que le système a répondu, y compris en cas d’erreur |
| Élément déclencheur | La demande ou le contenu qui a motivé l’appel |
| Décision de validation | Qui a autorisé l’action à impact, et quand |
Ce socle est le même que celui décrit dans reconstruire la trajectoire d’un agent après coup, appliqué au point précis où l’agent touche le système d’information.
Combien de serveurs MCP tournent chez vous aujourd’hui ?
Presque aucune organisation ne sait répondre, et c’est précisément le problème. Un serveur MCP s’installe en quelques minutes, sans demande préalable, et il ouvre à l’agent des capacités que personne n’a inscrites nulle part.
C’est la question qui fâche, et elle arrive plus vite qu’on ne le croit. Un collaborateur connecte un outil pratique. Un agent y découvre de nouvelles capacités. Des données deviennent atteignables. Des permissions sont accordées au fil de l’eau. Au bout de quelques mois, plus personne n’a une vision complète des connexions.
Le schéma est exactement celui du Shadow AI, l’IA qui entre dans l’entreprise sans passer par la porte, avec une aggravation : ici, l’outil non déclaré ne consomme pas des données, il agit dessus.
Le projet MCP a pris le sujet au sérieux. L’extension Enterprise-Managed Authorization, passée au statut stable en juin 2026, existe précisément pour qu’une organisation reprenne la main sur les autorisations MCP de façon centralisée, plutôt que serveur par serveur.
Les six contrôles à poser avant d’ouvrir MCP largement
Le dernier point est celui qu’on repousse toujours. Une révocation qui n’a jamais été exécutée n’est pas une procédure, c’est une intention.
À retenir
MCP est une vraie avancée d’intégration : il remplace des connecteurs propriétaires par une interface commune, et il fait gagner un temps considérable. Cette facilité est précisément ce qui rend la question des droits centrale.
Plus il devient simple de connecter un agent au système d’information, plus la seule question qui compte est celle-ci : à quoi cet agent a-t-il réellement le droit d’accéder, et qui l’a décidé ? Dans l’entreprise, MCP n’est pas seulement un protocole d’intégration, c’est une couche de contrôle des capacités accordées aux agents.
