Se rendre au contenu

Sécurité MCP : brancher l'IA sur son ERP, oui, mais pas n'importe comment

Failles publiées, ce que dit la spécification, et les six garde-fous que j'applique à mon propre ERP.
10 novembre 2026 par
Sécurité MCP : brancher l'IA sur son ERP, oui, mais pas n'importe comment

Le 15 avril 2026, OX Security a décrit une faille « par conception » dans la manière dont les serveurs MCP locaux sont lancés ; le 16 mai, la Cloud Security Alliance a publié un livre blanc sur la surface d'attaque des agents IA. Faut-il renoncer à brancher un agent sur votre ERP ? Non : la sécurité MCP tient moins au protocole qu'à la façon de le brancher. Droits minimaux, lecture par défaut, essai à blanc, sauvegarde, journal et validation humaine des écritures : c'est ce que je pratique chaque jour avec mon propre ERP.

L'essentiel

  • MCP (Model Context Protocol) est devenu la prise standard entre les agents IA et les logiciels. Il est gouverné depuis décembre 2025 par une fondation de la Linux Foundation, et Odoo 20 le propose pour se connecter à la base.
  • Les failles publiées en 2025 et 2026 ne cassent aucun chiffrement : elles exploitent la confiance accordée à un serveur installé, à la description d'un outil ou à un compte trop puissant.
  • La spécification elle-même le dit : un humain devrait toujours pouvoir refuser l'appel d'un outil, et l'usage des outils devrait être journalisé.
  • Un agent n'a jamais plus de droits que le compte avec lequel il se connecte. C'est là que tout se joue.
  • Six garde-fous suffisent à rendre le branchement raisonnable pour une PME, et aucun ne demande d'outil coûteux.

Ce qui se passe : MCP s'impose, les chercheurs testent ses limites

Anthropic a présenté le Model Context Protocol le 25 novembre 2024 comme « un nouveau standard pour connecter les assistants IA aux systèmes où vivent les données ». Le principe : un petit programme, le serveur MCP, expose à l'IA des « outils » (chercher une facture, créer un contact, lire une base) qu'elle peut appeler d'elle-même. Le 9 décembre 2025, le protocole a été confié à l'Agentic AI Foundation, créée au sein de la Linux Foundation avec Anthropic, OpenAI et Block ; le communiqué recensait alors plus de 10 000 serveurs MCP publiés. Les éditeurs suivent : les notes de version d'Odoo 20, publiées en septembre 2026, annoncent la connexion à la base « via MCP ». La version actuelle de la spécification date du 28 juillet 2026.

Les chercheurs en sécurité ont suivi le mouvement. Trois épisodes résument les risques.

Un faux connecteur qui copiait les e-mails

En septembre 2025, un paquet npm nommé « postmark-mcp », qui se faisait passer pour le connecteur du service d'e-mails Postmark, a ajouté dans sa version 1.0.16 une ligne qui envoyait en copie cachée chaque e-mail vers un serveur externe. Le 25 septembre 2025, Postmark a confirmé n'avoir rien à voir avec ce paquet, qui avait gagné la confiance de ses utilisateurs pendant quinze versions. Personne n'a piraté l'IA : on lui a fourni un outil piégé, et elle s'en est servie normalement.

Une faille « par conception » dans le lancement local

Le 15 avril 2026, OX Security a publié une recherche sur le transport STDIO, celui qui lance un serveur MCP comme un programme sur votre machine à partir d'un fichier de configuration. Si une donnée non maîtrisée atteint cette configuration, elle peut faire exécuter n'importe quelle commande. OX estime l'exposition à plus de 150 millions de téléchargements et jusqu'à 200 000 instances. Selon OX, Anthropic a refusé de modifier l'architecture du protocole, jugeant ce comportement « attendu » : c'est au développeur de contrôler ce qu'il lance.

Le « confused deputy » et l'empoisonnement d'outils

Le 16 mai 2026, la Cloud Security Alliance a publié un livre blanc sur trois familles de risques : l'empoisonnement d'outils (des instructions cachées dans la description d'un outil, que l'IA lit et suit), le « confused deputy » (un serveur qui agit avec des droits plus larges que ce que l'utilisateur voulait réellement) et la chaîne d'approvisionnement (paquets et registres publics). Le document, que la CSA présente elle-même comme une recherche rapide assistée par IA, pas encore validée par ses processus officiels, recommande quatre contrôles : approuver et versionner les définitions d'outils, limiter les droits de chaque appel, appliquer une politique au moment où l'outil est appelé, et journaliser tous les appels.

Ce que ça change pour vous : la sécurité MCP se joue à l'installation

Pour un dirigeant de PME, la leçon n'est pas « MCP est dangereux ». C'est que brancher un agent sur votre ERP revient à signer une procuration. L'agent lit ce que son compte peut lire et modifie ce que son compte peut modifier. S'il reçoit une instruction piégée, cachée dans un e-mail, une facture en PDF ou la description d'un outil, il l'exécutera avec ces mêmes droits.

La spécification MCP le reconnaît en toutes lettres. Elle demande qu'il y ait « toujours » un humain capable de refuser l'appel d'un outil, que les applications demandent confirmation pour les opérations sensibles et journalisent l'usage des outils, et que les descriptions fournies par un serveur soient tenues pour non fiables tant que ce serveur ne l'est pas. Le protocole ne peut pas imposer ces règles : c'est à celui qui installe de les appliquer.

Trois questions suffisent pour savoir où vous en êtes. Avec quel compte l'agent se connecte-t-il ? Peut-il écrire sans que personne ne valide ? Saurez-vous dire demain ce qu'il a fait aujourd'hui ?

Ce que j'en ai appris

Je pilote mon ERP en langage naturel depuis ma migration vers Odoo Community, racontée dans Odoo Community vs Enterprise : ma migration : un serveur MCP relie Odoo à Claude, je demande, l'IA fait le travail, je vérifie. J'ai aussi écrit un serveur MCP pour l'outil de notes SiYuan, publié en open source (SiYuan MCP Server). En l'écrivant, j'ai vu un serveur MCP de l'intérieur : un programme qui traduit les demandes de l'IA en appels au logiciel, avec exactement les droits qu'on lui donne. Le mien écrit directement dans les fichiers des bases de données de SiYuan, parce que l'API officielle ne le permettait pas. C'est utile, et cela montre bien qu'un serveur fait ce que ses accès autorisent, pas seulement ce que sa description promet.

Le cadre le plus abouti est celui de ma comptabilité, décrit dans Automatiser la comptabilité avec l'IA. L'agent rédige un plan, l'exécute d'abord à blanc (tout est calculé puis annulé), je relis, puis il le joue pour de vrai après une sauvegarde automatique de la base. Les contrôles d'import refusent d'écrire au moindre écart, et aucune dépense sans pièce n'est saisie sans mon accord.

Cette règle, je l'ai apprise à mes dépens. Pendant la migration, un premier test de synchronisation avec mon agenda personnel a effacé quatre événements. Un test sur un système externe reste une écriture. Depuis, rien ne s'y écrit sans validation explicite.

Que faire concrètement

1. Donner à l'agent son propre compte, avec des droits minimaux

Créez un utilisateur technique dédié, limité aux applications et aux sociétés dont l'agent a besoin, sans droits d'administration. Jamais le compte du dirigeant ni celui de l'administrateur : en cas d'instruction piégée, c'est ce périmètre qui limite les dégâts.

2. Commencer en lecture seule

Les premières semaines, l'agent cherche, résume, rapproche et propose, mais n'écrit pas. Vous ouvrez l'écriture ensuite, application par application, quand vous savez ce que vous en attendez.

3. Exiger un essai à blanc avant chaque écriture

Toute modification passe d'abord par une simulation qui montre ce qui serait créé ou changé, puis qui est annulée. Si l'outil ne sait pas simuler, l'agent présente au moins la liste exacte des écritures prévues.

4. Sauvegarder avant d'écrire

Une sauvegarde de la base, dont la restauration a été testée, avant tout lot d'écritures. C'est elle qui transforme une erreur en simple contretemps.

5. Tenir un journal des actions

Chaque appel d'outil doit laisser une trace : qui, quand, quoi, avec quel résultat. Un compte dédié aide déjà, puisque toutes ses modifications portent son nom dans l'historique de l'ERP.

6. Garder un humain pour valider les écritures

L'agent prépare, une personne valide. N'installez que des serveurs MCP de source vérifiée, celle de l'éditeur ou un code que vous avez relu, et considérez tout document entrant comme une source possible d'instructions piégées.

Questions fréquentes

Est-ce sûr de connecter un agent IA à mon ERP par MCP ?

Oui, si vous le traitez comme un nouveau collaborateur à qui l'on confie une procuration : un compte à son nom, des droits limités, des écritures validées et un journal. Les incidents publiés exploitent des comptes trop puissants ou des serveurs installés sans vérification.

Le serveur MCP fourni par mon éditeur est-il plus sûr ?

Il écarte le risque du faux connecteur, ce qui compte. Mais il agit toujours avec les droits du compte que vous lui confiez : les garde-fous restent de votre ressort.

Faut-il héberger l'IA chez soi pour être tranquille ?

Pas forcément. Le modèle peut être un service externe si les données qu'il voit sont acceptables pour vous et si les droits, la validation et le journal restent de votre côté. La vraie question est ce que l'agent peut faire, plus que l'endroit où il réfléchit.

Pour aller plus loin

Je mets en place des agents IA branchés sur Odoo et sur vos outils métier, avec ces garde-fous dès le départ : voyez les applications métier et l'infrastructure qui les porte. Pour en parler sur votre cas, réservez un appel de 20 minutes.

Sources

Tags : sécurité MCP, Model Context Protocol, agents IA, ERP, Odoo, cybersécurité, PME

nLPD et intelligence artificielle : la loi s'applique déjà, une loi IA se prépare pour 2027
Ce que la loi suisse exige déjà quand vous utilisez l'IA, ce que le Conseil fédéral prépare, et six étapes pour être en règle sans attendre.