Sécurité et contrôle d'accès Odoo
Le modèle de sécurité d'Odoo est plus puissant que la plupart des équipes ne le réalisent — et plus souvent mal configuré que les gens ne l'admettent. Bien fait, il donne un contrôle fin par utilisateur, par enregistrement, par société. Mal fait, le CEO voit les rapports du stagiaire et le commercial voit les prix fournisseurs.
On nous appelle régulièrement pour réparer des configurations de sécurité Odoo qui ont dérivé : trop d'admins, des groupes custom dont personne n'est propriétaire, des règles d'enregistrement ajoutées en panique qui se contredisent, des fuites multi-société. Le pattern est toujours le même — la sécurité n'a pas été conçue au départ, juste rajoutée quand quelque chose a cassé.
Ce guide est la référence que nous utilisons pour concevoir ou auditer la sécurité d'une instance Odoo. Il couvre les concepts (groupes, ACL, règles d'enregistrement), le modèle multi-société, la piste d'audit, les essentiels RGPD et les pratiques opérationnelles qui maintiennent la sécurité propre dans le temps.
Groupes, ACL, règles d'enregistrement — les trois couches
La sécurité Odoo a trois couches. Les groupes (utilisateur → appartenance) définissent ce qu'est un utilisateur. Les ACL (groupe → modèle) définissent ce que chaque groupe peut lire, écrire, créer, supprimer sur chaque modèle. Les règles d'enregistrement (groupe → sous-ensemble d'enregistrements) raffinent à des enregistrements spécifiques — uniquement les leads de votre équipe, uniquement les achats de votre département.
La plupart des incidents de sécurité que nous enquêtons remontent à deux patterns : trop d'utilisateurs dans les groupes 'Settings' ou 'Admin' (donc les ACL ne mordent pas), ou des règles d'enregistrement contradictoires entre groupes (un utilisateur hérite de 'Sien seulement' et 'Tout', la logique OR lui donne tout). La discipline sur l'appartenance aux groupes est la moitié de la bataille.
- Trois couches : groupes (qui), ACL (peut faire quoi sur quel modèle), règles (quels enregistrements)
- Discipline d'appartenance = moitié de la bataille — trop d'admins = pas de sécurité
- Règles d'enregistrement en logique OR entre groupes — les contradictions donnent l'accès le plus large
- Groupes Odoo standard (Utilisateur/Manager/Settings) couvrent 80% des besoins
- Groupes custom rares et bien documentés — chacun ajoute du coût de maintenance
Isolation multi-société — le piège dans lequel beaucoup tombent
Le multi-société dans Odoo peut signifier isolation (données de chaque société invisibles aux autres) ou partage (données niveau groupe visibles partout). Le défaut penche vers le partage, ce qui convient à la plupart des groupes mais peut faire fuir des informations non voulues — chiffres financiers de la société A visibles à un utilisateur de la société B.
Nous lançons toujours un 'audit multi-société' sur les setups existants : se logger comme utilisateur de chaque société, parcourir les menus, vérifier ce qui est visible et ce qui ne l'est pas. Les surprises sont communes. La correction est généralement un resserrage des règles d'enregistrement par société et une revue des modèles qui supportent l'isolation nativement.
- Multi-société peut être isolation ou partage — défaut penche vers le partage
- Certains modèles (partenaires, produits) partagés par défaut ; d'autres (factures, ventes) par société
- Auditer en se loggant comme utilisateur de chaque société et en parcourant les menus
- Resserrer les règles par société là où on trouve des fuites
- Transactions inter-société = setup propre — visibilité partielle par design
Piste d'audit et la question 'qui a fait quoi'
Le mail thread d'Odoo capture la plupart des actions utilisateur sur les enregistrements — qui a créé, qui a modifié, qui a posté quel message. Pour un audit plus profond (qui a changé quel champ à quelle heure), un module d'audit log (OCA ou payant) est nécessaire. Pour les secteurs sensibles (finance, santé, industries régulées), ce n'est pas optionnel.
La piste d'audit n'est utile que si elle est consultée. Nous mettons en place une cadence de revue avec nos clients — coup d'œil mensuel sur les enregistrements les plus modifiés, les utilisateurs les plus actifs, les patterns inhabituels. Ça attrape les soucis tôt et démontre la gouvernance aux auditeurs.
- Mail thread capture la plupart des actions nativement — audit basique de base
- Audit champ-par-champ nécessite un module (OCA ou payant) — non optionnel en secteur régulé
- Audit log utile seulement s'il est revu — cadence mensuelle attrape les soucis tôt
- Logs de connexion et tracking de session disponibles via les outils admin Odoo
- Intégration SIEM externe possible via les logs et webhooks Odoo
Authentification, SSO, MFA — la baseline moderne
L'authentification native Odoo est correcte mais la baseline moderne est le single sign-on (SSO) via SAML ou OAuth, idéalement avec MFA imposé. Odoo supporte les deux nativement ou via modules. Pour les PME belges Microsoft-centriques, le SSO Azure AD est le setup le plus courant que nous déployons.
Le MFA doit être obligatoire pour quiconque a des droits admin ou manager, idéalement pour tous les utilisateurs. Politiques de mot de passe, timeouts de session et whitelisting IP là où c'est pertinent complètent la baseline. Rien d'exotique — c'est le standard pour toute appli métier en 2026.
- Auth native correcte pour les petites équipes — SSO + MFA est la baseline moderne
- SAML et OAuth supportés — SSO Azure AD est le setup PME belge typique
- MFA obligatoire pour admins et managers minimum — tous les utilisateurs idéalement
- Politiques mot de passe, timeouts session, whitelisting IP complètent la baseline
- Intégrer les logs Odoo dans votre SIEM si vous en avez un — les webhooks rendent ça facile
Essentiels RGPD — ce qu'Odoo donne et ce que vous devez ajouter
Odoo donne le socle technique RGPD : inventaire des données personnelles (Contacts, RH, partenaires), piste d'audit, chiffrement en transit, backups, suppression via procédures standard ou custom. Ce qu'il ne donne pas : la politique, la gestion du consentement, les règles de rétention documentées.
Nous aidons les clients sur le chevauchement RGPD-Odoo : demandes d'accès des personnes concernées (export et suppression), calendriers de rétention (auto-archivage après X années), tracking de consentement marketing, DPA avec Odoo / Odoo.sh / l'hébergeur. La partie technique se résout ; la partie processus a besoin d'un porteur dans votre organisation.
- Odoo donne le socle technique — inventaire, audit trail, chiffrement, backups
- Demandes d'accès personnes concernées (export, suppression) implémentables avec procédure
- Calendriers de rétention via jobs d'auto-archivage — explicites par catégorie de données
- Tracking de consentement marketing — supporté par module, à configurer
- DPA avec Odoo / Odoo.sh / hébergeur obligatoire — à signer avant go-live
Erreurs de sécurité que nous voyons en audits
Voici les patterns qui produisent une vraie exposition — parfois réglementaire, parfois commerciale.
- Trop d'utilisateurs en admin/settings — les ACL ne mordent pas.
- Groupes custom ajoutés au fil des ans sans doc — personne ne sait ce qu'ils accordent.
- Multi-société supposé isolé quand il ne l'est pas — fuite financière entre sociétés.
- Pas de MFA sur les comptes admin — un mot de passe compromis = accès complet.
- Audit trail activé mais jamais revu — utile uniquement après incident, pas avant.
Métriques qui prouvent que la posture sécurité Odoo est saine
Suivies trimestriellement avec l'IT et le DPO. Métriques stables = posture stable.
- Nombre d'admins < 5% des utilisateurs — privilège minimum respecté.
- MFA imposé à 100% pour admins/managers, >80% pour tous les utilisateurs.
- Groupes custom inventoriés avec but documenté — zéro groupe orphelin.
- Audit multi-société fait au moins annuellement sans fuite trouvée.
- Cadence de revue d'audit log respectée (mensuelle typiquement) avec findings documentés.
Comment nous concevons et auditons la sécurité Odoo chez Flydoo
Sur les nouvelles implémentations, nous concevons la sécurité dès le jour 1 : matrice utilisateurs par rôle, héritage de groupes, design d'ACL, règles d'enregistrement. Les setups multi-société ont un plan d'isolation explicite. SSO et MFA sont configurés avant le go-live, pas après.
Sur les setups existants nous lançons un audit sécurité : revue des groupes, ACL, règles, configuration multi-société, couverture MFA, revue de l'audit log. Sortie : un plan de remédiation priorisé. La plupart des audits remontent une ou deux vraies expositions plus une poignée d'items de cleanup.
- Matrice utilisateurs par rôle conçue avant que la configuration commence
- Groupes custom limités et documentés ; groupes standard préférés
- Plan d'isolation multi-société explicite, audité en parcourant les menus en utilisateur de test
- SSO et MFA configurés avant go-live, obligatoires pour admins et managers
- Cadence de revue d'audit log convenue avec le DPO et la finance — mensuelle minimum
Checklist sécurité pratique pour une instance Odoo
À dérouler avec IT, RSSI et DPO. La majorité cochée = posture saine.
- Matrice utilisateurs par rôle documentée et appliquée
- Admins < 5% des utilisateurs — privilège minimum respecté
- Groupes custom inventoriés avec but documenté
- Isolation multi-société auditée en parcourant les menus en utilisateur de test
- MFA imposé pour tous les admins et managers, idéalement tous les utilisateurs
- SSO configuré (Azure AD, Okta, Google) là où applicable
- Cadence de revue d'audit log convenue et documentée
- DPA signé avec Odoo / Odoo.sh / l'hébergeur
À retenir
- La sécurité Odoo a trois couches : groupes, ACL, règles — les concevoir, pas les rajouter
- Discipline d'appartenance (surtout admin) = moitié de la bataille
- Le défaut multi-société penche vers le partage — auditer explicitement pour confirmer ce qui fuit
- Le MFA est obligatoire pour admins et managers en 2026 — sans exception
- RGPD : Odoo donne les outils, vous devez porter la politique et la cadence de revue
- Les audit logs ne sont utiles que s'ils sont revus — cadence mensuelle attrape les soucis tôt
Questions fréquentes
À quel point les règles d'enregistrement Odoo peuvent-elles être granulaires ?
Très. On peut limiter la visibilité aux enregistrements possédés par l'utilisateur, par son équipe, par sa société, par n'importe quelle combinaison de champs. Nous avons construit des règles du genre 'les commerciaux managers voient tous les leads de leur région sauf ceux taggés confidentiels'. Le risque n'est pas 'Odoo ne peut pas' — c'est 'on a empilé dix règles et personne ne comprend plus le résultat'. Garder les règles minimales et documentées.
Le multi-société Odoo est-il assez fort pour une holding avec filiales ?
Pour la plupart des holdings, oui. Chaque filiale comme société, règles d'isolation resserrées, finance par société. Pour une holding régulée (banque, assurance) avec exigences strictes, vous pouvez avoir besoin de contrôles additionnels et possiblement de bases Odoo séparées. Nous évaluons cas par cas selon votre cadre réglementaire.
Odoo supporte-t-il SAML / OAuth / Azure AD SSO ?
Oui — SAML et OAuth supportés nativement en Enterprise ; Community a des modules. Azure AD est le SSO le plus courant que nous configurons pour les PME belges. Nous le couplons typiquement avec MFA imposé au niveau Azure AD, donc l'expérience Odoo c'est 'cliquer → entrer', et la barrière sécurité est à l'IdP.
Quelle est l'histoire de la rétention RGPD pour Odoo ?
Odoo n'impose pas la rétention par lui-même — vous décidez. Nous configurons typiquement des jobs d'auto-archivage qui passent les enregistrements en archivé après une période définie (par ex. 7 ans pour la finance, 3 ans pour les leads marketing). La suppression dure des données personnelles est implémentée via procédure DSAR. Les mécanismes techniques sont là ; la politique vous appartient.
Comment auditer une Odoo existante pour des soucis sécurité ?
Commencer par cinq choses : (1) lister tous les utilisateurs avec droits admin ou settings, (2) inventorier tous les groupes custom et ce qu'ils accordent, (3) parcourir les menus multi-société en utilisateur de test, (4) vérifier la couverture MFA, (5) vérifier que l'audit log est réellement revu. À partir de là, notre audit standard prend 2-5 jours pour une instance PME et produit un plan de remédiation priorisé.
Besoin d'aide pour appliquer tout cela à votre contexte ? Parlons-en.