Le contrôle d’accès répond à « l’IA peut-elle voir cette fiche ? ». La gouvernance répond à « que se passe-t-il une fois qu’elle l’a vue ? ». Le système de permissions d’Odoo (ACL, règles d’enregistrement, droits par champ) borne déjà ce qu’une IA connectée via MCP peut atteindre — c’est la base, traitée dans notre article sur la sécurité de l’accès IA à Odoo. Cet article porte sur la couche au-dessus : une fois que l’IA peut voir l’historique de facturation d’un client, chaque lecture est-elle journalisée, les champs sensibles sont-ils masqués malgré tout, et peut-elle agir sur ce qu’elle voit sans en demander l’autorisation ?
« L’utilisateur pouvait déjà le voir » est-il une réponse suffisante ?
Non, parce qu’un humain qui navigue dans Odoo et une IA qui interroge Odoo ne se comportent pas du tout de la même façon. Un commercial ouvre dix fiches par jour, n’en retient à peu près rien, et ne touche jamais aux champs hors du formulaire qu’il consulte. Un agent IA peut énumérer des milliers de fiches en quelques secondes, recouper des champs entre modèles que l’interface ne juxtapose jamais et, si vous l’avez configuré ainsi, rédiger un e-mail à partir de ce qu’il a trouvé. Mêmes permissions, profil de risque totalement différent.
C’est exactement la distinction que trace le principe de minimisation des données du RGPD : les données à caractère personnel doivent être « adéquates, pertinentes et limitées à ce qui est nécessaire au regard des finalités pour lesquelles elles sont traitées » (Article 5(1)©). Avoir un droit de lecture sur un champ parce que votre rôle Odoo l’inclut n’équivaut pas à ce que ce champ soit nécessaire pour que l’IA le traite dans le cadre de la tâche en cours. Le contrôle d’accès répond à qui peut entrer dans la pièce. La gouvernance répond à ce qu’on a le droit d’y faire une fois entré, et si l’on peut le prouver après coup.
En quoi consiste concrètement le « contrôle », au-delà des ACL ?
Quatre mécanismes concrets, chacun comblant une lacune que les ACL laissent ouverte par construction :
- Journal d’audit. Chaque lecture et écriture effectuée par l’IA, journalisée et exportable — pas seulement « l’utilisateur X avait accès » mais « l’IA a interrogé cette fiche, à telle heure, et a retourné ces champs ».
- Masquage des données personnelles. Les champs sensibles (numéros d’identité, coordonnées bancaires, données de santé) restent cachés à l’IA même quand l’utilisateur Odoo sous-jacent pourrait techniquement les voir — y compris dans les résultats exportés, pas seulement à l’écran.
- Politiques par utilisateur, sous les ACL. Les ACL d’Odoo disent ce qu’un rôle peut toucher. Une couche de politiques dit ce que l’IA est autorisée à toucher pour ce rôle — plus restreint, et testable avant activation.
- Écritures validées par un humain et garde-fou sortant. Les changements risqués (suppression, ajustement de prix, envoi d’e-mail) attendent une validation humaine au lieu de s’exécuter de façon autonome.
Aucun de ces mécanismes n’existe dans le système ACL natif d’Odoo, parce que les ACL n’ont jamais été conçues pour répondre à « un agent autonome a-t-il fait ceci, et puis-je le voir ». Elles ont été conçues pour des humains cliquant dans une interface.
Pourquoi le journal d’audit compte-t-il davantage pour une IA que pour une personne ?
Parce que lorsque quelque chose tourne mal, « qui a fait ça et pourquoi » est la première question — et avec une IA dans la boucle, la réponse honnête est souvent « on ne sait pas, elle ne s’en souvient pas ». L’Article 32 du RGPD impose « des mesures techniques et organisationnelles appropriées afin de garantir un niveau de sécurité adapté au risque », y compris la capacité de rétablir l’accès après un incident et de tester et évaluer régulièrement l’efficacité de ces mesures. On ne peut pas évaluer ce qu’on ne journalise pas.
L’AI Act européen va plus loin pour les systèmes à haut risque, en imposant « l’enregistrement automatique d’événements (journaux) tout au long de la durée de vie du système » afin que les opérateurs puissent identifier quand le système a présenté un risque et alimenter la surveillance post-commercialisation (Article 12). Un agent IA connecté à un ERP n’est pas automatiquement « à haut risque » au sens des catégories de ce règlement, mais la logique sous-jacente s’applique directement : si un système autonome peut toucher des données clients, des prix ou des données financières, on veut une trace de ce qu’il a touché — avant qu’un régulateur, un auditeur ou un client ne pose la question.
Cledoo MCP Pro journalise chaque lecture et écriture initiée par l’IA dans un journal d’audit complet et exportable : ce qui a été interrogé, ce qui a été modifié, par quelle session d’agent, à quel moment. C’est la différence entre « on fait confiance à l’IA pour avoir bien agi » et « on peut montrer ce qu’elle a fait ».
Pourquoi masquer des champs que l’utilisateur de l’IA pouvait déjà voir ?
Parce que la visibilité dans un formulaire Odoo et l’exposition dans la fenêtre de contexte d’une IA ne sont pas le même risque. Un champ qu’un agent support consulte une fois, en contexte, entouré d’une dizaine d’autres champs à l’écran, n’équivaut pas à ce même champ récupéré dans la réponse d’une IA, potentiellement résumé, potentiellement recité dans un brouillon d’e-mail, potentiellement mis en cache quelque part dans un historique de conversation. La donnée n’a pas bougé, mais sa surface d’exposition s’est multipliée.
C’est précisément ce que la « protection des données dès la conception et par défaut » (Article 25 du RGPD) est censée imposer : des mesures techniques garantissant que « par défaut, seules les données à caractère personnel qui sont nécessaires au regard de chaque finalité spécifique du traitement sont traitées » (Article 25(2)) — et non « les données personnelles qui se trouvaient être accessibles ». Le masquage applique ce principe à un connecteur IA : numéros d’identité, IBAN, notes de santé restent cachés des requêtes de l’IA et de tout ce qu’elle exporte, indépendamment des permissions brutes de l’utilisateur Odoo sous-jacent. C’est le moindre privilège appliqué une seconde fois, pour un acteur au profil de risque différent.
Pourquoi une couche de politiques sous les ACL plutôt que de simplement resserrer les ACL ?
Parce que resserrer les ACL pour l’IA les resserre aussi pour l’humain, ce qui n’est généralement pas ce que vous voulez. Votre comptable a besoin d’un accès complet au modèle account.move pour faire son travail. Vous ne voulez pas forcément que l’IA agisse sur ce même modèle avec la même ampleur — lire chaque facture historique pour répondre à une question est acceptable ; la laisser lettrer silencieusement des écritures ne l’est pas.
Une couche de politiques placée entre les ACL de l’utilisateur et ce que l’IA est réellement autorisée à faire permet de dire : cet humain, avec ce rôle, peut faire X, Y, Z — l’IA, en son nom, ne peut faire que X. Les politiques par utilisateur de Cledoo MCP Pro font exactement cela, avec un simulateur en mode dry-run permettant de voir ce qu’une politique aurait bloqué avant de l’activer — aucune surprise la première fois qu’une vraie requête la rencontre.
Que se passe-t-il quand l’IA veut agir, pas seulement lire ?
C’est là que s’ouvre le plus grand écart entre « accès » et « contrôle ». Lire une fiche et mal la restituer est une mauvaise réponse. Écrire sur une fiche, ou envoyer un e-mail au nom de votre entreprise, est une mauvaise action — et les actions sont bien plus difficiles à annuler que les réponses.
Deux mécanismes referment cet écart dans Cledoo MCP Pro :
- Écritures validées par un humain. Les modifications signalées comme risquées (suppression, mise à jour en masse, modification de champs financiers) se mettent en pause et attendent une validation explicite au lieu de s’exécuter immédiatement.
- Garde-fou sortant (outbound guard). L’IA ne peut pas envoyer d’e-mails, de messages ou toute autre communication sortante de sa propre initiative — un humain autorise ce qui part, et à qui.
C’est de l’endiguement, pas de l’obstruction : les usages en lecture, à faible risque, restent rapides et sans friction ; la poignée d’actions difficiles à annuler obtient un point de contrôle.
À retenir
L’accès répond à peut. La gouvernance répond à a fait, peut-on le prouver, et quelqu’un a-t-il vérifié avant. Les ACL d’Odoo, héritées par Cledoo MCP Classic, vous donnent la première partie gratuitement — l’IA est bornée par ce que l’utilisateur connecté pouvait déjà faire. Cledoo MCP Pro (189 €, paiement unique, sans abonnement) ajoute la seconde partie : un journal d’audit exportable, un masquage des données personnelles au-delà des ACL brutes, des politiques par utilisateur avec simulateur dry-run, des écritures validées par un humain, un garde-fou sortant, et des analyses d’usage pour observer dans la durée comment l’IA se comporte réellement. L’accès sans contrôle, c’est une démo. L’accès avec contrôle, c’est quelque chose qu’on peut montrer à un auditeur.