Oui, à condition que l’IA passe par le système de permissions de votre ERP et non à côté. La vraie question n’est pas « peut-on faire confiance à une IA avec ses données » — c’est « qu’hérite-t-elle, et que se passe-t-il si on la manipule ». Avec Cledoo MCP, l’IA hérite exactement des droits d’accès de l’utilisateur Odoo qui l’a connectée, rien de plus. Le risque résiduel, c’est l’injection de prompt, et il est borné — pas éliminé — par ces mêmes droits.
Que signifie concrètement « l’IA a accès à mon ERP » ?
Cela dépend entièrement de l’architecture, et il existe deux modèles fondamentalement différents :
- Modèle export. Vos données Odoo sont synchronisées ou copiées vers une plateforme IA externe — une base vectorielle, un connecteur tiers, un middleware. L’IA interroge cette copie. Vos données vivent désormais à deux endroits, peuvent fuiter de deux endroits, et la synchronisation échappe généralement à votre contrôle.
- Modèle accès direct. L’IA se connecte directement à votre Odoo en production via un protocole — MCP — et chaque lecture ou écriture passe par les contrôles de permission natifs d’Odoo, en temps réel, sur la base de données réelle. Aucune copie n’existe.
Cledoo MCP applique le second modèle. L’IA atteint votre Odoo via le point
d’accès /mcp exposé par le module, et à partir de là elle n’est qu’un
client Odoo comme un autre — soumise aux mêmes règles que l’onglet navigateur
que vous avez ouvert en ce moment.
L’IA peut-elle voir ou faire plus que l’utilisateur connecté ?
Non. C’est la garantie centrale, et il vaut la peine d’être précis sur ce qui la fonde. Le contrôle d’accès d’Odoo est structuré en couches, et aucune n’est spécifique à MCP — ce sont les mêmes qui régissent depuis des années tous les clients Odoo (web, mobile, API), telles que documentées dans la référence développeur officielle d’Odoo :
- Les droits d’accès (
ir.model.access) décident, par modèle, si les groupes d’un utilisateur peuvent créer, lire, modifier ou supprimer, tout court. - Les règles d’enregistrement (
ir.rule) filtrent quels enregistrements — un commercial voit ses propres opportunités, pas tout le pipeline, si la règle est configurée ainsi. - La sécurité au niveau des champs masque ou bloque certains champs précis — un champ de salaire qu’un groupe donné ne doit pas voir reste invisible, quel que soit le demandeur.
Quand l’IA appelle un outil Cledoo MCP, cet appel s’exécute en tant qu’utilisateur connecté, via l’ORM d’Odoo — le même chemin de code qu’un clic manuel. Il n’y a ni compte de service privilégié, ni contournement. Si l’utilisateur ne voit pas le champ salaire RH dans l’interface, l’IA ne peut pas non plus le récupérer. Si l’utilisateur ne peut pas supprimer de factures, l’appel de suppression de l’IA est rejeté par la même règle qui rejetterait sa propre tentative. C’est pourquoi la formulation honnête est « bornée par les droits de l’utilisateur », pas « l’IA a été entraînée à bien se comporter » — le comportement n’est pas le mécanisme d’application, le système de permissions d’Odoo l’est.
Des données sortent-elles de l’instance Odoo ?
Non, et c’est là que le modèle d’accès direct fait toute la différence. Il n’y a pas de serveur externe qui conserve une copie de vos enregistrements, pas de courtier de données entre Odoo et l’IA, pas de tâche de synchronisation avec sa propre politique de rétention et d’accès à auditer. Le contexte de l’IA — ce qu’elle peut lire dans une conversation donnée — provient d’appels d’outils en direct sur votre instance, et disparaît avec la session. Ce que vous auditez tient en une chose : votre Odoo, et qui s’est connecté en tant que qui.
Cela ne veut pas dire que rien n’est exposé au fournisseur de l’IA — toute donnée que l’IA lit pour répondre à une question est, par définition, transmise au modèle pour traitement, comme lorsqu’on colle une capture d’écran dans une conversation. Ce que cela veut dire, c’est qu’il n’y a pas de copie supplémentaire qui traîne dans un second système avec sa propre surface de fuite.
Ce qui peut vraiment mal tourner — sans détour
Le modèle de permissions écarte le scénario « l’IA dépasse les droits de l’utilisateur ». Il n’écarte pas une autre catégorie de risque que l’OWASP Gen AI Security Project classe comme risque numéro un pour les applications LLM dans son Top 10 2025 : l’injection de prompt. Selon l’OWASP, une vulnérabilité d’injection de prompt survient lorsque « des prompts utilisateur modifient le comportement ou la sortie du LLM d’une manière non prévue », et elle prend deux formes — directe (un utilisateur rédige délibérément un prompt manipulateur) et indirecte (l’IA lit un contenu provenant d’une source externe — un document, un e-mail, une page web — qui contient des instructions cachées qu’elle suit ensuite).
Appliqué à Odoo : imaginez un e-mail client, ingéré comme ticket support, qui contient un texte conçu pour faire dévier l’IA la prochaine fois qu’on lui demande de résumer les tickets. C’est un risque réel, classé n°1 par l’OWASP pour les applications LLM, et aucun éditeur ne devrait prétendre le contraire.
Voici ce qui limite réellement les dégâts : l’instruction injectée s’exécute toujours en tant qu’utilisateur connecté, dans ses droits d’accès existants. Une injection de prompt visant une IA connectée en tant que commercial en lecture seule ne peut pas la faire supprimer une facture ni lire la table des salaires — les règles d’enregistrement et les droits d’accès décrits plus haut s’appliquent quel que soit le pourquoi de l’appel de l’IA, seulement en tant que qui elle le fait. Le rayon d’action d’une injection réussie est plafonné à ce que cet utilisateur pouvait déjà faire à la main. C’est une vraie atténuation, pas une élimination complète — un utilisateur aux droits d’écriture larges qui se fait piéger par du contenu injecté peut toujours causer de vrais dégâts, dans les limites de ses propres droits.
La documentation officielle de la spécification MCP est elle aussi franche sur cette catégorie de problèmes, avec des sections détaillées sur le détournement de session, le « token passthrough » et la minimisation des scopes — le fil conducteur : le moindre privilège d’abord, la surveillance ensuite, parce qu’aucun contrôle isolé n’élimine le risque à lui seul.
Et si j’ai besoin d’un contrôle plus strict que « les droits normaux de l’utilisateur » ?
Certaines données sont assez sensibles pour que vous ne vouliez pas les voir apparaître dans le contexte d’une IA, même si l’utilisateur connecté est techniquement autorisé à les voir, et certaines actions sont assez lourdes de conséquences pour que vous vouliez une confirmation humaine avant que l’IA ne les exécute, quels que soient les droits de l’utilisateur. C’est un besoin légitime, et c’est une couche différente de celle décrite ici — le module de base vous donne un accès fidèle, borné par les ACL ; Cledoo MCP Pro ajoute de la gouvernance en dessous de ces droits (masquage, politiques de refus, écritures confirmées, audit complet). Nous traitons cette couche dans un autre article ; ce qu’il faut retenir ici, c’est qu’elle s’ajoute, elle ne remplace pas la frontière des ACL — Pro rétrécit ce que le module de base borne déjà correctement.
À retenir
Une IA connectée à Odoo via MCP n’est pas un nouvel acteur sans limites dans votre système — c’est l’utilisateur connecté, agissant via les droits d’accès qui le régissent déjà, sans qu’aucune copie de vos données ne traîne ailleurs. Le risque résiduel honnête, c’est l’injection de prompt, qui est réel et à prendre au sérieux, mais dont le rayon d’action est plafonné par ce même système de permissions. Si vous avez besoin de le plafonner davantage — plus étroitement que les droits propres de l’utilisateur — c’est le rôle des contrôles de gouvernance, pas une raison de douter de l’architecture de base.