Le MCP n'est pas neutre : ce que Montesquieu enseigne sur la souveraineté de vos intégrations IA

Un connecteur qui ne pose aucune question

La semaine dernière, j'ai branché un serveur MCP tiers à un agent, pour un client. Un connecteur vers sa base documentaire, trouvé en quelques minutes, installé en quelques lignes. En dix minutes, l'agent listait, lisait, recoupait des documents métier qu'il n'avait jamais vus.

Et là, une inquiétude sourde. À aucun moment le protocole ne m'a demandé qui avait le droit d'appeler quoi. Aucune authentification fine, aucune trace lisible des appels, aucun garde-fou sur le périmètre. Le MCP, ou Model Context Protocol, standardise la prise de courant — pas ce qui passe dans le câble.

Ce silence n'est pas un bug. C'est une propriété du protocole. Et pour comprendre ce qu'il implique, il faut relire un magistrat bordelais du XVIIIᵉ siècle.

Le doux commerce, ou la séduction de l'interopérabilité

En 1748, dans De l'esprit des lois, Montesquieu formule une idée devenue célèbre : « le commerce guérit des préjugés destructeurs », et « partout où il y a des mœurs douces, il y a du commerce ». C'est la thèse du doux commerce : l'échange marchand tisse une interdépendance qui rend la guerre coûteuse, donc improbable. Le négoce adoucit les nations en les rendant nécessaires les unes aux autres.

Cette promesse est exactement celle du MCP. Un standard unique pour brancher n'importe quel agent sur n'importe quel outil — un CRM, une base SQL, un dépôt Git, un service de paiement. Fini les intégrations sur mesure, coûteuses et fragiles. On ouvre une frontière commerciale, et l'écosystème de serveurs explose : registres publics, connecteurs communautaires, catalogues d'éditeurs.

Je suis le premier séduit. J'opère moi-même des agents et des automatisations, et le MCP a réellement raccourci mes délais d'intégration. La fluidité est un gain net. Mais Montesquieu, lu jusqu'au bout, dit autre chose que le slogan qu'on lui prête.

Le revers : l'interdépendance est aussi une dépendance

Car le doux commerce a un envers que Montesquieu voyait bien. L'interdépendance qui pacifie crée aussi de la dépendance. Celui qui ne peut plus se passer de son partenaire commercial a cédé une part de sa souveraineté. Ouvrir une frontière, c'est décider qui peut la franchir — et parfois découvrir trop tard qui l'a franchie.

Un serveur MCP tiers en production, c'est exactement cela : une frontière ouverte sur votre système d'information. Le protocole ne dit rien sur la confiance. Il ne vous protège ni du serveur malveillant, ni du serveur compromis, ni du serveur qui, après six mois de bons services, change silencieusement le comportement de ses outils.

Les travaux de sécurité de 2026 ont nommé ces menaces. Le MCP Security Cheat Sheet de l'OWASP recense le tool poisoning — une description d'outil piégée qui détourne l'agent —, les rug pulls — un serveur qui altère ses outils après adoption —, l'agrégation de credentials et l'échappement de sandbox. La Cloud Security Alliance va plus loin et parle d'une surface d'attaque systémique de l'infrastructure agentique : serveurs publics sans authentification, cross-server shadowing, exécution de commandes via STDIO.

Le scénario qui me préoccupe le plus reste le confused deputy — le « délégué confus ». L'agent dispose de permissions légitimes ; un serveur malveillant les détourne à son profit. C'est le principe même que j'ai décrit dans mon analyse des failles de persuasion des grands modèles de langage : on ne force pas un LLM, on le persuade. Un outil MCP mal intentionné ne pirate pas votre agent — il lui parle, et l'agent obéit avec ses propres droits.

La gouvernance se joue à l'extérieur du protocole

Voici la thèse que je défends auprès des dirigeants qui croient que « c'est standardisé, donc c'est sûr ». Le MCP standardise la plomberie, pas la politique. Le bilan de sécurité MCP publié par Microsoft en 2026 le répète sans détour : le protocole ne fait pas la sécurité à votre place.

La confiance, l'audit, le périmètre des permissions — tout cela vit hors du protocole. Un standard technique règle la question du comment on se parle. Il ne règle jamais celle du qui a le droit de parler à qui, et de quoi. Confondre les deux, c'est confondre l'existence d'une langue commune avec la garantie que personne ne mentira dans cette langue.

La vraie question n'est donc pas technique mais politique, au sens de Montesquieu : quelle est votre balance commerciale de données ? Que laissez-vous sortir de votre système, par quels canaux, sous quelle surveillance ? Un serveur MCP mal cadré exfiltre par un canal parfaitement légitime.

Quatre garde-fous avant d'ouvrir la frontière

En pratique, avant de mettre un serveur MCP tiers en production, je pose systématiquement quatre décisions. Elles ne relèvent pas du protocole : elles relèvent de votre politique interne.

1. L'allowlist d'outils et le moindre privilège. L'agent n'accède qu'aux outils explicitement autorisés, avec des permissions minimales. Pas de token universel : un jeton par serveur, lié à son audience, comme le recommandent l'OWASP et Microsoft. La frontière est ouverte pour ce qui doit passer, fermée pour tout le reste.

2. Le pinning des définitions d'outils. On fige la description des outils au moment de l'adoption et on surveille tout changement. C'est la parade directe au rug pull : un serveur qui modifie ses outils après coup déclenche une alerte, pas une exécution silencieuse.

3. La journalisation de chaque appel. Qui a appelé quoi, quand, avec quels arguments, pour quel résultat. Sans trace, pas d'audit ; sans audit, pas de souveraineté. Une frontière sans douane n'est plus une frontière.

4. L'auto-hébergement des serveurs critiques. C'est le garde-fou le plus structurant. Un serveur MCP que j'opère moi-même n'a pas la même surface de risque qu'un serveur tiers dont j'ignore la chaîne d'approvisionnement. Pour les outils qui touchent aux données sensibles, je préfère l'artisanat interne au connecteur sur étagère — une exigence qui structure aussi notre façon de construire des agents sur mesure.

La distinction est cardinale : serveur que l'on opère contre serveur tiers. Ce n'est pas une nuance technique, c'est une frontière de souveraineté.

L'interopérabilité est un choix politique

Montesquieu ne condamnait pas le commerce — il l'estimait civilisateur. Mais il savait qu'une nation qui ouvre ses frontières sans en maîtriser les termes finit dépendante de plus fort qu'elle. Le doux commerce adoucit les mœurs à condition de rester un choix, pas une reddition.

Le MCP reste un excellent standard, et je continue de l'utiliser tous les jours. L'erreur n'est pas de l'adopter — c'est de croire que son adoption tient lieu de politique de sécurité. La souveraineté de vos intégrations IA ne se lit pas dans la fiche technique du protocole ; elle se lit dans les frontières que vous décidez d'ouvrir et dans celles que vous gardez fermées.

Brancher un serveur MCP, ce n'est pas cocher une case d'interopérabilité. C'est signer un traité commercial. Et un traité, cela se négocie, cela se surveille, cela se dénonce — jamais cela ne se subit.