Odoo et RGPD : contrats, modules et copies de données

Odoo peut réunir gestion commerciale, comptabilité, ressources humaines et services clients dans une même base. Cette centralisation facilite les échanges, mais oblige à distinguer les finalités, accès et durées. La revue doit aussi couvrir l’intégrateur, les copies de maintenance et les services connectés.

Décrire le déploiement et les acteurs

Identifiez l’offre et la version utilisées : Odoo Online, Odoo.sh ou installation hébergée par votre organisation ou un tiers. Ajoutez les prestataires qui administrent, maintiennent ou développent les modules. Votre entreprise peut être responsable de ses traitements ou agir pour le compte d’un client ; la qualification suit les opérations réelles.

L’auto-hébergement ne permet pas d’affirmer qu’Odoo ne reçoit jamais de données. Un service de mise à niveau, une demande de support accompagnée d’une copie de base ou un service connecté peut créer un flux. Le contrat Enterprise publié dans la documentation officielle, sections 4.3 et 6.5, envisage notamment l’envoi de bases pour mise à niveau et les traitements qui en résultent.

La qualification des rôles proposée par la CNIL permet de raisonner à partir des finalités et moyens. Un intégrateur mandaté pour administrer la base peut nécessiter un encadrement de sous-traitance ; un destinataire qui poursuit une finalité propre demande une autre analyse.

Vérifier l’encadrement contractuel

Rapprochez le contrat effectivement souscrit des exigences de l’Art. 28(3) : instructions, confidentialité, sécurité, assistance, suppression ou restitution et contrôle. Les clauses de protection des données peuvent être intégrées à un contrat plus large ; l’existence d’un document séparé appelé « DPA » n’est pas une exigence de forme autonome. RGPD, chapitre IV.

La section 6.5 du contrat Enterprise décrit notamment les opérations sur les bases client, la confidentialité, les demandes de droits, les audits et la restitution ou suppression. Examinez également les documents auxquels elle renvoie et les prestations de l’intégrateur. Si vous intervenez vous-même comme sous-traitant, assurez-vous que le dossier reflète cette chaîne et les instructions de votre donneur d’ordre.

Conservez une copie datée des conditions applicables, la liste des prestataires et les réponses aux points non couverts. Notre modèle de questionnaire sous-traitant aide à demander les informations adaptées à votre usage.

Vérifier production, sauvegardes et support

Il est insuffisant de décrire tout Odoo hébergé comme reposant exclusivement sur Google Cloud. La politique de confidentialité publiée par Odoo présente plusieurs prestataires et distingue hébergement, sauvegardes et accès internationaux. Demandez une confirmation du périmètre applicable à votre instance et de la version documentaire en vigueur.

Votre fiche doit préciser le pays de production, les copies de secours, les opérations de mise à niveau et les accès de support. Le choix d’une région principale ne prouve pas que chaque copie ou accès respecte le même périmètre. Ne confondez pas certification d’un centre de données et certification de l’ensemble de votre service.

Pour les transferts concernés, les Art. 44–46 imposent un mécanisme adapté aux destinataires et opérations. Une implantation belge du cocontractant ne clôt pas l’analyse de ses prestataires et accès. RGPD, chapitre V. Utilisez la cartographie de la chaîne de sous-traitance pour conserver les relations entre Odoo, hébergeurs, intégrateurs et services annexes.

Cartographier les finalités, sans créer une fiche par bouton

Le registre décrit les activités de traitement selon l’Art. 30(1), pas nécessairement chaque module installé. Une finalité peut mobiliser plusieurs modules ; inversement, un même module peut servir des finalités et catégories de personnes différentes.

La base légale doit correspondre à la finalité, selon l’Art. 6(1). Le fait de disposer d’un contact dans le module commercial ne permet pas toutes les réutilisations ; notre guide de prospection commerciale détaille les conditions propres aux sollicitations. Les données particulières appellent aussi une condition de l’Art. 9(2). RGPD, chapitre II.

Contrôler les permissions et les copies de préproduction

La documentation officielle des droits Odoo distingue droits d’accès et règles sur les enregistrements. Vérifiez les résultats obtenus par des comptes représentatifs : commercial, comptable, RH, prestataire et utilisateur du portail. Le seul nom du groupe ne prouve pas l’absence d’accès transversal.

Examinez aussi les pièces jointes, champs libres, exports et droits d’administration. Une vue masquée n’est pas nécessairement une restriction sur toutes les voies d’accès. Limitez les privilèges des personnes qui peuvent modifier les règles elles-mêmes.

Sur Odoo.sh, la documentation des branches explique que la préproduction utilise une copie neutralisée de la base de production : certaines actions, courriels et services sont désactivés. Cette neutralisation fonctionnelle n’est pas une anonymisation. Les données personnelles copiées restent à protéger.

Exemple hypothétique : un intégrateur doit reproduire une erreur de calcul. Au lieu de lui ouvrir toute la base RH, l’entreprise fournit un jeu fictif reproduisant le problème. Si une copie réelle est nécessaire, elle documente les champs, personnes habilitées, durée et suppression, ainsi que les éventuelles copies téléchargées.

Préparer conservation, droits et réversibilité

Définissez une durée et un point de départ pour chaque catégorie. Une archive comptable ne justifie pas de garder toutes les notes commerciales sur le même contact. Inversement, une demande d’effacement ne conduit pas automatiquement à supprimer des pièces soumises à une obligation légale : examinez notamment l’Art. 17(3)(b). RGPD, chapitre III.

Préparez une recherche transversale : fiches contacts, factures, candidatures, messages, pièces jointes et copies chez les prestataires. Distinguez désactivation, archivage et suppression effective. Pour la sortie, vérifiez la restitution exploitable, les modules nécessaires à sa lecture et le calendrier d’effacement des copies, avec les exceptions justifiées. Consignez les résultats dans une preuve d’exécution de l’effacement.

En auto-hébergement, attribuez également les correctifs, sauvegardes et restaurations à un responsable identifié. L’Art. 32(1) concerne la sécurité effective selon les risques ; disposer du serveur ne la démontre pas à lui seul.

Ce qu’il faut retenir

• Cartographiez le déploiement, les intégrateurs et les flux de support.
• Le contrat doit couvrir les opérations réellement confiées.
• Les finalités structurent le registre ; les modules seuls ne suffisent pas.
• Une copie Odoo.sh neutralisée peut toujours contenir des données personnelles.

FAQ

L’auto-hébergement évite-t-il toute sous-traitance ?

Non. Examinez l’hébergeur, la maintenance, le support et les services connectés. Seule l’absence effective d’opération confiée permet d’écarter une relation donnée.

Faut-il une fiche de registre pour chaque module ?

Le registre suit les activités de traitement. Regroupez ou distinguez les usages selon leurs finalités et caractéristiques, en conservant un lien clair avec les modules utilisés.

Une base de préproduction neutralisée est-elle anonyme ?

Non. Désactiver les envois ou paiements évite certaines actions, sans retirer nécessairement les informations identifiantes de la base copiée.

Recevez nos analyses pratiques sur la conformité RGPD dans la newsletter.

Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.