La documentation Odoo 19 décrit désormais des agents capables de comprendre une demande en langage naturel, de consulter des sources et d’utiliser des outils dans Odoo. La nouveauté importante n’est donc pas seulement conversationnelle : selon les sujets qui lui sont attribués, un agent peut ouvrir une vue ou déclencher une action métier, par exemple créer une piste CRM.
Pour une entreprise belge ou française, ce passage de la réponse à l’action change le cadrage du projet. Un prompt utile ne remplace ni les droits d’accès, ni les règles métier, ni les contrôles de données. Avant de déployer un agent dans Odoo 19, il faut définir ce qu’il sait, ce qu’il peut faire et comment prouver ce qu’il a fait.
Comprendre l’architecture avant de choisir un cas d’usage
Dans le modèle documenté par Odoo, l’agent possède une mission et un prompt système. Des sujets précisent ses instructions et regroupent les outils qu’il peut appeler. Des sources — PDF, liens web, fichiers Documents ou articles Knowledge — fournissent le contexte indexé. Sans sujet, l’agent peut informer mais ne peut pas exécuter d’action.
Cette séparation doit devenir la frontière de gouvernance : une source étend ce que l’agent peut connaître ; un outil étend ce qu’il peut modifier. Les deux risques sont différents et ne doivent pas être validés dans le même geste.
Trois niveaux de risque opérationnel
Répondre à partir d’un corpus contrôlé
Un agent de support interne peut être limité aux procédures approuvées grâce à l’option de restriction aux sources. Il faut néanmoins gérer les propriétaires, versions, dates d’expiration et droits des documents. Une réponse fondée sur une procédure périmée reste une erreur industrialisée.
Orienter l’utilisateur dans Odoo
La recherche en langage naturel et l’ouverture de vues paraissent peu risquées, mais elles peuvent révéler des enregistrements sensibles si la matrice d’accès est trop large. Les tests doivent être exécutés avec les profils réels — commercial, comptable, RH, responsable multi-sociétés — et inclure des contrôles négatifs.
Déclencher une action métier
Les actions serveur IA séparent le « manager », qui choisit un outil et ses arguments, du « worker », une action serveur standard qui exécute la logique. Odoo précise que l’outil s’exécute sans condition supplémentaire si son propre code ne la prévoit pas. Les plafonds, états autorisés, contrôles d’existence, séparation des rôles et mécanismes d’idempotence doivent donc vivre dans l’outil, pas seulement dans le prompt.
Documents : un bon pilote, à condition de conserver une file d’exception
L’automatisation documentaire peut classer des fichiers, ajouter des étiquettes, créer des activités ou des enregistrements métier tels que des factures fournisseurs. Elle se configure par dossier, ce qui permet de construire un flux progressif. Un pilote raisonnable commence par le tri et l’étiquetage, mesure les erreurs, puis n’autorise la création d’un objet comptable qu’avec validation humaine et rapprochement.
Le cas des PDF contenant plusieurs pièces illustre cette prudence : la documentation propose de détecter le document multipage, de lui ajouter une étiquette « à séparer », puis d’arrêter le traitement. Un bon agent sait aussi quand ne pas continuer.
Helpdesk et Live Chat : formaliser la sortie vers un humain
La documentation Odoo 19 détaille désormais deux usages orientés support. Dans Helpdesk, les agents, automatisations et champs IA peuvent résumer, catégoriser ou préparer le traitement d’un ticket. Dans Live Chat, un agent peut répondre, qualifier la conversation et déclencher une création de piste lorsque la demande exige un prix personnalisé, une intervention, une modification de compte ou lorsque sa confiance est insuffisante.
Ce passage ne doit pas être conçu comme une simple phrase dans un prompt. Il faut définir les critères d’escalade, les informations minimales à recueillir, le propriétaire de la file humaine, le délai de reprise et la manière d’éviter les doublons. Odoo décrit d’ailleurs un sujet de création de piste qui collecte les coordonnées une par une, les confirme et appelle l’outil une seule fois. Cette discipline conversationnelle doit être testée comme une règle métier.
Champs IA : une donnée générée reste une donnée à gouverner
Odoo permet d’ajouter des champs IA via Studio ou comme champs de propriété. Leur valeur peut être générée à partir du contexte de l’enregistrement et des champs référencés dans le prompt. Une action planifiée, active par défaut, complète une fois par jour certains champs texte et champs de propriété encore vides.
Avant d’utiliser ces valeurs pour une priorité, une date, un montant ou une catégorie, l’équipe doit décider si le champ est une suggestion ou une donnée faisant foi. Elle doit aussi contrôler les entrées autorisées, les valeurs possibles, le déclenchement après modification et les corrections humaines. Pour une migration Odoo, les champs IA personnalisés, leurs prompts et l’action planifiée entrent dans l’inventaire des personnalisations et dans la recette de non-régression.
Analyse Underside : gouverner la capacité, pas seulement le modèle
Le choix du modèle de langage compte, mais le risque ERP se concentre ailleurs : périmètre des outils, qualité des sources, droits de l’utilisateur, règles codées et journalisation. Nous recommandons un registre par agent indiquant propriétaire métier, finalité, sociétés concernées, sources, outils, données sensibles, validation humaine, métriques et procédure de désactivation.
En Belgique comme en France, les traitements qui touchent la comptabilité, les données RH ou les contacts clients doivent être rapprochés de la gouvernance des accès et de la protection des données de l’entreprise. Il ne faut pas attribuer à Odoo une garantie juridique automatique : l’organisation reste responsable de son cas d’usage, de sa configuration et de ses contrôles.
Feuille de route de mise en production
- Choisir un processus fréquent, réversible et mesurable.
- Limiter le premier agent à une société, un rôle et un corpus nommé.
- Séparer les tests de qualité des réponses des tests d’autorisation des actions.
- Implémenter les règles métier et les blocages dans chaque outil.
- Définir l’escalade humaine, son propriétaire et son délai de reprise.
- Qualifier chaque champ IA comme suggestion ou donnée de référence.
- Prévoir une validation humaine pour toute écriture financière ou sensible.
- Tester erreurs, doublons, demande ambiguë, source absente et révocation d’accès.
- Mesurer les exceptions et décider explicitement avant d’élargir le périmètre.
Cette démarche complète un modèle robuste de sécurité et de droits Odoo et un plan de test des évolutions Odoo 19.4.
Sources officielles
- Odoo 19 — agents IA, sujets, outils et sources.
- Odoo 19 — actions serveur IA.
- Odoo 19 — automatisation documentaire par IA.
- Odoo 19 — IA dans les processus Helpdesk.
- Odoo 19 — agent IA dans Live Chat et escalade.
- Odoo 19 — configuration et calcul des champs IA.
Underside accompagne le cadrage, le prototypage et la sécurisation des automatisations Odoo. Un pilote court doit produire autant de preuves de contrôle que de gains de productivité.