Dans Odoo 19, un agent IA n'est plus seulement un assistant qui répond. Avec la bonne configuration, il crée et met à jour des enregistrements dans votre base. La documentation officielle le dit sans détour : sans Topic assigné, un agent « ne peut que fournir de l'information, pas accomplir de tâches ni modifier la base de données »1. Dès qu'on lui donne un Topic, il peut écrire.
Pour un intégrateur, la question change donc de nature. Elle n'est plus « est-ce que l'agent est utile », mais « qu'est-ce qu'il peut atteindre, et qu'est-ce qu'il peut modifier ». Passons en revue les leviers pour le border, du plus simple au plus structurel.
Le premier verrou est dans l'agent : les Topics
C'est le réglage le plus direct, et il est natif. Un agent sans Topic reste en lecture seule, cantonné à l'information1. Chaque Topic que vous ajoutez est une autorisation d'agir : la doc les décrit comme ce qui « guide les conversations, en disant à l'agent ce qu'il peut faire, comment et quand le faire »1.
Le réflexe de moindre privilège commence ici. On démarre un agent sans aucun Topic, on vérifie qu'il se contente de répondre, puis on ajoute les Topics un par un, en sachant que chacun ouvre une capacité d'action. On n'attribue jamais un Topic « au cas où ».
Cadrer ce que l'agent lit : Restrict to Sources
Côté lecture, Odoo 19 propose un onglet Sources et une bascule Restrict to Sources1. Activée, elle empêche l'agent de répondre en dehors des ressources que vous lui avez fournies, qu'il s'agisse de PDF, de liens web, de documents ou d'articles Knowledge1. Pour un agent qui doit seulement exploiter une base documentaire, c'est le bon cadran. Il ne part pas chercher ailleurs.
L'agent passe par votre modèle de sécurité
Beaucoup oublient ce point. Un agent qui agit le fait à travers la sécurité Odoo habituelle, pas à côté. Les couches officielles s'appliquent à lui comme à n'importe quel utilisateur2.
Les groupes définissent des ensembles de permissions par application3. Les droits d'accès, portés par ir.model.access, autorisent ou non les quatre opérations de base, lecture, écriture, création et suppression, modèle par modèle23. Les record rules, portées par ir.rule, filtrent ligne à ligne avec un domaine, et peuvent affiner ou restreindre ce que le groupe permet23. Tout cela vaut pour vos modèles custom autant que pour les modèles standard2.
La conséquence est directe. Si un de vos modules livre un ir.model.access trop large, par exemple un droit d'écriture accordé à group_user sur un modèle sensible, l'agent exploitera ce trou aussi sûrement qu'un humain, et plus littéralement. Il ne devine pas vos intentions, il lit vos ACL.
Le piège : la sécurité se joue côté serveur
La documentation insiste sur un point que l'IA rend brûlant : cacher un champ ou un menu dans une vue n'est pas une protection, la sécurité doit être posée côté serveur2. Un humain qui ne voit pas un bouton renonce. Un agent, lui, ne raisonne pas en boutons. Si l'enregistrement est accessible par les droits réels, il peut le lire ou l'écrire, que le champ soit masqué à l'écran ou non. Les agents de la 19 transforment chaque raccourci de sécurité pris en vue en dette exploitable.
La checklist avant de lâcher un agent en prod
On peut s'en tenir à quelques vérifications, dans l'ordre.
On démarre l'agent sans Topic et on n'en ajoute qu'au strict besoin. Pour chaque Topic qui écrit, on contrôle que les modèles visés ont des ir.model.access serrés et des ir.rule en place, modèles custom compris. On relit les fichiers d'accès de ses propres modules à la recherche de droits d'écriture trop généreux sur group_user. On vérifie qu'une record rule existe sur les modèles sensibles, pour limiter l'exposition ligne à ligne. On ne se repose jamais sur un masquage en vue pour protéger une donnée.
Notre lecture
L'agent IA d'Odoo 19 est un révélateur de votre modèle d'accès. Des ir.model.access propres et des record rules pensées, c'était déjà de la bonne hygiène. Cela devient la différence entre un assistant utile et un assistant trop puissant. La bonne nouvelle, c'est qu'il n'y a rien de neuf à apprendre côté sécurité. Les outils sont les mêmes depuis des années, l'IA ne fait qu'augmenter le coût de les négliger.
Sources
- Odoo, documentation officielle « AI agents » (19.0) : https://www.odoo.com/documentation/19.0/applications/productivity/ai/agents.html
- Odoo, tutoriel développeur « Restrict access to data » (19.0) : https://www.odoo.com/documentation/19.0/developer/tutorials/restrict_data_access.html
- Odoo, documentation officielle « Access rights » (19.0) : https://www.odoo.com/documentation/19.0/applications/general/users/access_rights.html
- Certum Solutions (partenaire Odoo), Set up your own AI agents : https://www.certumsolutions.com/library/odoo-ai-setup-your-own-agents
Footnotes
-
Odoo, documentation officielle « AI agents » (Odoo 19.0). Champs de configuration (Agent Name, LLM Model, Response Style, System Prompt), Topics et bascule Restrict to Sources. Citation : « If an agent is not assigned any Topics, it is only able to provide information, not complete tasks or make changes to the database. » https://www.odoo.com/documentation/19.0/applications/productivity/ai/agents.html ↩ ↩2 ↩3 ↩4 ↩5
-
Odoo, tutoriel développeur officiel « Restrict access to data » (Odoo 19.0). Trois couches : groupes, droits d'accès
ir.model.access(lecture, écriture, création, suppression), record rulesir.rule(filtrage par domaine). Applicable aux modèles custom. La sécurité doit être appliquée côté serveur, le masquage en vue n'est pas une protection. https://www.odoo.com/documentation/19.0/developer/tutorials/restrict_data_access.html ↩ ↩2 ↩3 ↩4 ↩5 -
Odoo, documentation officielle « Access rights » (Odoo 19.0). Groupes via Settings > Users & Companies > Groups (mode développeur). Quatre opérations par modèle : lecture, écriture, création, suppression. Les record rules « overwrite, or refine, the group's access rights ». https://www.odoo.com/documentation/19.0/applications/general/users/access_rights.html ↩ ↩2 ↩3