Une question revient à chaque mission où le sujet de l'IA arrive sur la table. Un dirigeant, un DAF, parfois le responsable SI, finit par poser la vraie : « Si j'active l'IA dans mon Odoo, mes données partent où ? » C'est une bonne question, et la réponse honnête est : ça dépend de ce que vous activez et de comment c'est configuré. Personne ne vous le dit clairement au moment de cocher la case.
Odoo 19 a intégré une couche IA un peu partout. On l'a déjà évoqué côté fonctionnel, et la 19.3 a même poussé des agents qui agissent sur la base, en avant-goût de la version 20 attendue à l'automne. Ici on laisse de côté ce que l'IA fait pour regarder par où transitent vos écritures, vos fiches clients et vos pièces comptables quand elle travaille. Parce que c'est ça qui détermine si vous êtes en règle avec le RGPD, pas la promesse marketing.
Ce qui sort de votre base, et ce qui n'en sort pas
Premier réflexe à corriger : non, activer l'IA d'Odoo n'envoie pas toute votre base à OpenAI. L'architecture est plus fine que ça, et c'est plutôt rassurant.
Quand vous indexez des sources (articles Knowledge, PDF, documents), Odoo en calcule des représentations vectorielles et les stocke dans un modèle interne, ai.embedding, à l'intérieur de votre propre base PostgreSQL. Ces vecteurs ne partent pas sur un serveur externe. Au moment où un agent répond, Odoo récupère par similarité les morceaux pertinents de vos sources et les injecte dans le prompt, avec le contexte de l'enregistrement en cours. C'est ce prompt assemblé qui part chez le fournisseur de modèle, pas votre dataset entier. (analyse technique Much Consulting)
La nuance compte pour votre analyse RGPD. Ce qui « part », ce sont des extraits choisis plus le texte de votre requête. Si un de ces extraits contient une donnée personnelle, un nom de client, un montant nominatif, une adresse, alors cette donnée précise quitte votre périmètre. La granularité ne vous dispense pas de l'analyse, elle la rend juste plus ciblée.
Le vrai sujet : qui est le fournisseur, et sous quelle juridiction
Odoo 19 supporte officiellement deux fournisseurs dans l'app AI : OpenAI (ChatGPT) et Google Gemini. Vous choisissez dans les réglages, vous pouvez même affecter un modèle différent par agent. (documentation Odoo 19, AI API keys) Sur le papier vous n'êtes donc pas verrouillé sur un seul prestataire. En pratique, c'est moins ouvert que ça en a l'air. Sur le forum officiel, des intégrateurs constatent que certaines actions, comme les AI fields ou le web grounding, ne fonctionnent qu'avec OpenAI, parce que la couche de compatibilité de Gemini n'implémente pas encore l'API attendue. (forum Odoo) Autrement dit, pour plusieurs usages, vous reparlez à OpenAI que vous le vouliez ou non.
OpenAI comme Google sont des fournisseurs américains. Les données envoyées dans le prompt sont régies par leurs conditions à eux, pas par les vôtres. C'est le point que la documentation rappelle d'ailleurs noir sur blanc : quand vous utilisez un fournisseur tiers, ce sont ses propres termes qui gouvernent le traitement, et il vous revient de les relire avant d'envoyer la moindre donnée personnelle ou confidentielle. (synthèse OEC sur l'IA Odoo 19) Pour un transfert hors UE, ça veut dire vérifier les clauses contractuelles types, la base légale, et documenter tout ça dans votre registre. Ce n'est pas une formalité qu'on coche, c'est une analyse à faire en amont.
La clé du client ou le compte par défaut : deux régimes très différents
Il y a deux façons d'alimenter l'IA d'Odoo, et elles ne se valent pas du tout côté données.
Vous pouvez mettre votre propre clé API. Dans les réglages, l'option « Utiliser votre propre compte ChatGPT » vous laisse coller une clé OpenAI ou Gemini que vous gérez. Dans ce cas, la relation contractuelle est directe entre vous et le fournisseur, vous maîtrisez le compte, et vous savez exactement quel contrat s'applique. C'est le mode que je recommande de regarder en premier dès qu'il y a de la donnée sensible, parce qu'il vous rend lisible la chaîne de responsabilité.
L'autre voie, c'est le mécanisme d'In-App Purchase d'Odoo. Certaines fonctions IA et assimilées, typiquement la digitalisation de documents par OCR, passent par les crédits IAP sans que vous ayez à configurer quoi que ce soit. La donnée transite alors par les serveurs d'Odoo avant d'atteindre le prestataire. Bonne nouvelle pour la localisation : les serveurs IAP d'Odoo sont situés en Belgique et en France, et pour l'OCR la pièce est conservée temporairement à des fins de modération et de prévention d'abus. (politique de confidentialité IAP Odoo) Pour les fonctions de génération qui s'appuient sur OpenAI, la donnée finit malgré tout chez un prestataire américain. Le détour par la Belgique et la France ne change pas la juridiction finale du modèle.
Concrètement, sur une instance, l'OCR des factures fournisseurs est le cas le plus courant où de la donnée part sans que personne n'ait coché « activer l'IA » de façon consciente. La case était là par défaut. Ça vaut le coup de la regarder.
Les pistes souveraines, et ce qu'elles coûtent vraiment
Si votre exigence est de garder l'inférence en Europe ou en interne, des options existent. Aucune n'est gratuite, ni en argent ni en effort.
La première consiste à brancher un modèle auto-hébergé ou un endpoint européen. Techniquement, Odoo laisse changer l'URL de base du fournisseur. Mais une bonne partie des points d'accès sont calés en dur sur les structures d'OpenAI et de Google, donc un modèle local demande de la personnalisation pour coller aux attentes d'Odoo. (Much Consulting, sur le self-hosted) C'est faisable, ce n'est pas du paramétrage. Il faut un serveur d'inférence, des compétences pour le maintenir, et accepter qu'un modèle open weight hébergé chez vous n'aura pas toujours le niveau du dernier GPT sur les tâches difficiles.
La deuxième piste passe par des connecteurs tiers présents sur l'Apps Store, du type passerelle multi-modèles, qui ajoutent d'autres fournisseurs à la liste, dont certains modèles européens. Ça élargit le choix, mais vous déplacez la question de confiance vers un intermédiaire de plus, et la plupart de ces modules réclament l'édition Enterprise puisqu'ils étendent la couche IA native.
La troisième option est la plus simple et la plus sous-estimée : ne pas tout envoyer. Réserver l'IA aux tâches où elle apporte vraiment, exclure les modèles de données les plus sensibles, et garder l'humain en validation sur ce qui touche la paie, le client nominatif ou les pièces comptables. La souveraineté la moins chère reste celle de ce que vous décidez de ne pas exposer.
Aucune de ces pistes ne se choisit dans l'absolu. Elle dépend de la sensibilité réelle de vos données, de votre secteur, et de ce que votre DPO est prêt à documenter. Notre rôle, en intégration, c'est de poser ces arbitrages avant d'activer quoi que ce soit, pas après le premier contrôle.
Ce sujet rejoint deux choses qu'on a déjà traitées ici : la certification ISO 27001 d'Odoo et son impact NIS2 et RGPD, et ce que la version 20 prépare côté agents IA. Le socle de sécurité et la trajectoire produit sont une chose. Savoir où vont vos données quand l'IA tourne en est une autre, et celle-là se règle dans la configuration, pas dans la plaquette.
Côté code Odoo cette semaine
Sur le dépôt public odoo/odoo, branche master, la semaine du 12 au 19 juin a surtout charrié du correctif e-invoicing et un changement silencieux dans le traitement des emails comptables. Deux commits méritent qu'on s'y arrête.
Les factures envoyées en masse à un alias comptable ne reviennent plus en bounce
Dans le module account, un correctif réglé le 19 juin traite un bug pénible : lorsqu'un client envoyait de gros lots d'emails vers un alias comptable, environ 5 % revenaient en échec. La cause venait de l'OCR automatique déclenché en IAP de façon asynchrone, dont les rappels frappaient la base en parallèle d'un autre email en cours de traitement. Une erreur de sérialisation non rattrapée s'ensuivait. Le correctif sécurise ces mises à jour concurrentes. Si vous recevez vos factures fournisseurs par email avec OCR activé, c'est exactement le genre de bug invisible qui faisait perdre des pièces sans alerte claire. À noter, le lien direct avec l'IA via l'OCR IAP. e6a1680
Les unités de mesure récupèrent un code UNECE pour la facture électronique
Toujours le 19 juin, sur account_* et les localisations, Odoo remplace un dictionnaire statique par un vrai champ de code UNECE sur les unités de mesure. Avant, certaines unités n'avaient pas de code, ce qui faisait échouer la validation des factures UBL et CII. Le changement touche aussi le constructeur XML du module PDP français. Pour qui se prépare à l'échéance de septembre, c'est une brique de fiabilité de plus sur la génération conforme. f65a3ae
Vous préparez l'activation de l'IA dans votre Odoo et vous voulez cadrer la question des données avant de cocher la case ? Parlons-en.
Sources
- Documentation Odoo 19, AI API keys (fournisseurs OpenAI et Gemini, clé propre) : odoo.com/documentation/19.0
- Forum Odoo, limites de Gemini sur les AI fields et le web grounding : odoo.com/forum
- Politique de confidentialité IAP Odoo (serveurs en Belgique et en France, usage OpenAI) : iap.odoo.com/privacy
- Much Consulting, protection des données de l'IA Odoo (embeddings dans ai.embedding, self-hosted) : muchconsulting.com
- OEC, fonctionnalités IA d'Odoo 19 (termes du fournisseur tiers, PII) : oec-eg.com
- Commit account, traitement concurrent des emails : github.com/odoo/odoo/commit/e6a1680
- Commit code UNECE pour les unités de mesure UBL/CII : github.com/odoo/odoo/commit/f65a3ae