Sécurité et disponibilité des données Odoo : guide complet 2026.
Odoo centralise vos données financières, opérationnelles et personnelles (clients, employés, fournisseurs). Il est donc normal de se poser trois questions simples : qui contrôle, qui sécurise, et que se passe-t-il en cas de panne.
Vous donner une lecture claire, sans jargon inutile, pour comprendre : vos droits (propriété des données), les responsabilités (SaaS vs on-premise), et les garanties (sauvegardes, RPO/RTO, SLA).
- Vous restez propriétaire de vos données, quel que soit le mode d’hébergement.
- Le contrôle technique varie fortement : en SaaS, Odoo opère l’infrastructure ; en on-premise, c’est vous (ou votre infogérant).
- La sécurité est une responsabilité partagée : il faut savoir “qui fait quoi”, sinon on se raconte une histoire.
🔑 Introduction : la propriété et le contrôle de vos données sensibles.
En pratique, la question n’est pas seulement “est-ce sécurisé”. La vraie question, c’est : qui a la main sur l’hébergement, les sauvegardes, les accès, les mises à jour, et les plans de reprise.
Bonne nouvelle : vous restez propriétaire de vos données dans tous les modes d’hébergement. Nuance importante : le contrôle technique n’est pas le même, donc la responsabilité opérationnelle non plus.
🧭 Ce qui ne change pas
- Principe
- Vos données vous appartiennent, et vous devez pouvoir les récupérer.
- Enjeu
- Formaliser l’export, les accès, et les délais de restitution.
Action recommandée. Documenter qui exporte, à quelle fréquence, où sont stockées les copies, et qui peut restaurer.
⚖️ Ce qui change selon l’hébergement
- SaaS
- Odoo gère l’infrastructure, la disponibilité, une partie de la sécurité, et la maintenance.
- On-premise
- Vous (ou votre prestataire) gérez tout : patch, réseau, sauvegardes, supervision, reprise.
Piège classique. Croire qu’un hébergement “cloud” suffit à couvrir vos obligations internes (accès, MFA, procédures).
🏗️ L’hébergement de mes données dans Odoo est-il sécurisé.
Pour répondre, il faut distinguer clairement : SaaS (Odoo Online) et on-premise (chez vous ou chez un hébergeur que vous pilotez). Le niveau de contrôle et la charge de sécurité n’ont rien à voir.
SaaS = sécurité industrialisée + responsabilités partagées
On-premise = contrôle total + responsabilité totale
☁️ Sécurité de la formule SaaS.
En SaaS, l’infrastructure et l’exploitation sont opérées par Odoo et ses sous-traitants d’hébergement. Vous gagnez en simplicité, mais vous devez quand même piloter les accès et la gouvernance.
🏷️ Audits, conformité et datacenters
- À savoir
- Odoo mentionne des audits SOC 1 / SOC 2 (accès sous NDA).
- ISO
- Les datacenters des hébergeurs peuvent être certifiés (ex : ISO 27001 selon l’hébergeur).
- RGPD
- La région d’hébergement peut être choisie (ex : Europe) selon la politique de confidentialité.
Action recommandée. Demander les éléments de conformité utiles : SOC sous NDA, clauses RGPD, et région d’hébergement.
🔒 Sécurité applicative “par design”
- Flux
- Communications chiffrées via SSL/TLS.
- Risques
- Protections classiques côté application (XSS, CSRF, injections) via mécanismes du framework.
- Exposition
- Moins d’exposition “infra” pour vous, plus de focus sur comptes et droits.
Décision à déclencher. Si vous avez des données très sensibles, renforcez MFA, politiques de mot de passe, revue des droits et journaux.
🛡️ Segmentation, isolation, anti-abus
- Principe
- Base isolée par client en environnement multi-tenant.
- Défense
- Mesures de protection contre DDoS et attaques communes (selon infrastructure).
- Limite
- Vous ne gérez pas la couche réseau, mais vous devez durcir les accès.
Action recommandée. Limitez les comptes admin, imposez MFA si disponible, et auditez les accès inactifs.
🗄️ Sauvegardes et restauration
- Cadence
- Politique type : 14 sauvegardes (journalières, hebdo, mensuelles) conservées au moins 3 mois.
- RPO
- Objectif : RPO 24h (perte max théorique).
- RTO
- Objectif : RTO 6h (incident serveur) et RTO 24h (sinistre datacenter).
Piège classique. Se reposer uniquement sur le fournisseur : gardez vos exports réguliers et testez une restauration “à blanc”.
Selon les engagements publiés, les sauvegardes peuvent être répliquées sur plusieurs sites et régions. Si votre conformité impose “Europe only”, faites confirmer par écrit la politique appliquée à votre base.
🖥️ Sécurité de l’on-premise.
En on-premise, vous obtenez un contrôle maximal. Mais ce contrôle a un coût : vous portez l’exploitation et la sécurité. Si vous n’avez pas une équipe infra/sécu, il faut un infogérant cadré par un vrai SLA.
🧩 Mises à jour et correctifs
- Obligation
- Appliquer OS, dépendances, Odoo et correctifs de sécurité régulièrement.
- Risque
- Une version non maintenue = surface d’attaque élevée.
Action recommandée. Planifier un cycle patch (mensuel) + patch urgent (48h) + suivi de versions.
🌐 Réseau, pare-feu, accès distants
- À mettre
- Pare-feu, whitelists, IDS/IPS si possible, VPN pour accès admin.
- Durcissement
- Désactiver root, SSH par clés, limitation IP, journalisation.
Décision à déclencher. Si vous exposez Odoo sur internet, mettez un reverse proxy durci + WAF + supervision.
👤 Identités, droits et moindre privilège
- Principe
- Moindre privilège pour tous les utilisateurs.
- Hygiène
- Revues d’accès trimestrielles, suppression des comptes obsolètes.
Action recommandée. Mettre une matrice rôles/permissions + un rituel de revue des accès.
🗄️ Sauvegardes, chiffrement, tests de reprise
- Standard
- Approche 3-2-1 : 3 copies, 2 supports, 1 hors site.
- Tests
- Tester une restauration régulièrement, pas seulement “avoir des backups”.
Piège classique. Découvrir que les sauvegardes ne restaurent pas le jour où on en a besoin.
⏱️ Existe-t-il des garanties contre les interruptions de service.
Aucun système n’est à zéro panne. La question utile : quel niveau de disponibilité, quels délais de reprise, et quel plan B si l’ERP est critique.
📜 SLA 99,9 % (SaaS)
- Niveau
- Objectif mensuel 99,9 % (hors maintenances planifiées).
- Ordre de grandeur
- 99,9 % ≈ 45 min d’arrêt non planifié max par mois.
Action recommandée. Vérifier les clauses de crédit de service et les exclusions (maintenance, force majeure).
🧯 Haute disponibilité et redondance
- Principe
- Datacenters de niveau Tier III (ou équivalent) avec redondance alimentation et réseau.
- Réplication
- Réplication quasi temps réel sur stockage redondant (selon architecture).
Décision à déclencher. Si votre activité ne supporte pas l’arrêt, étudiez une architecture HA + un mode dégradé métier.
🧪 Surveillance et maintenance
- Monitoring
- Supervision continue + alertes sur seuils de performance.
- Maintenance
- Fenêtres planifiées idéalement en heures creuses.
Action recommandée. Définir un canal incident interne : qui alerte, qui décide, qui communique.
🧩 Votre “plan B” métier
- Objectif
- Continuer à vendre, livrer, ou facturer même en mode dégradé.
- Exemples
- Procédures temporaires, exports quotidiens, fichiers de secours, priorités.
Décision à déclencher. Si l’ERP est “arrêt de production”, formaliser un PCA simple et le tester une fois par an.
🗄️ Sauvegardes et reprise après incident : ce que vous devez exiger.
La sécurité, ce n’est pas seulement empêcher l’attaque. C’est aussi être capable de restaurer vite avec un niveau de perte acceptable.
- RPO : combien d’heures de données vous pouvez perdre.
- RTO : en combien de temps vous devez redémarrer.
- Tests : est-ce que vous avez déjà restauré pour de vrai.
🌍 Où sont hébergées mes données.
Le point clé, c’est la région choisie (ex : Europe) et les sous-traitants qui opèrent l’infrastructure. En conformité, vous devez pouvoir répondre : “où”, “chez qui”, “sous quel régime”.
📍 Région d’hébergement
- Principe
- Les bases clientes sont hébergées dans une région définie (ex : Europe) selon les politiques applicables.
- Pratique
- Choisir la région adaptée à vos contraintes (RGPD, clients, secteur).
Action recommandée. Consigner la région dans votre documentation de conformité (et la contractualiser si nécessaire).
🏢 Sous-traitants d’hébergement
- Enjeu
- Connaître les acteurs (hébergement, mitigation, sauvegardes) et leurs certifications.
- Utile
- Faciliter les audits clients et répondre aux exigences sectorielles.
Action recommandée. Conserver la liste des sous-traitants et la version datée des politiques applicables.
Sur Odoo.sh, la région est généralement choisie au moment de la création du projet. Une fois le projet créé, le changement de région est très contraignant, donc il faut l’anticiper dès le cadrage.
✅ Checklist pratique : ce que vous devez mettre sous contrôle.
Si vous ne voulez retenir qu’une chose : la sécurité, c’est une liste de décisions. Voici une checklist terrain pour cadrer vite et bien.
👥 Accès et gouvernance
- À faire
- MFA si possible, admins limités, revues trimestrielles, désactivation des comptes dormants.
- Preuve
- Journal d’accès + procédure d’onboarding/offboarding.
Seuil d’alerte. Un “admin pour tous” = risque immédiat.
🧯 Continuité et reprise
- À faire
- RPO/RTO cibles, exports, test de restauration, mode dégradé métier.
- Preuve
- Compte-rendu de test de restauration, même simple.
Seuil d’alerte. Aucune restauration testée depuis 12 mois = risque élevé.
🔐 Conformité et contractualisation
- À faire
- Vérifier le SLA, la région, la politique de backups, et les clauses de sous-traitance.
- Preuve
- Documents signés + version datée des politiques applicables.
Seuil d’alerte. “On pense que c’est en Europe” sans document = non-auditable.
🛠️ Si vous êtes en on-premise
- À faire
- Cycle patch, supervision, durcissement SSH, pare-feu, sauvegardes 3-2-1, tests.
- Preuve
- Runbook + alerting + tableau de bord infra.
Seuil d’alerte. Absence de monitoring = pannes découvertes “par les utilisateurs”.
🎯 Synthèse : comment choisir (et sécuriser) sans se raconter d’histoires.
Si votre objectif est de réduire la charge technique, le SaaS apporte une exploitation industrialisée et des objectifs de disponibilité clairs. Si votre objectif est le contrôle maximal, l’on-premise est cohérent, mais exige une vraie capacité infra/sécu.
- Entreprise “standard” : SaaS + gouvernance d’accès + exports réguliers + PCA simple.
- Entreprise “réglementée” : contractualiser la région, les sous-traitants, et la politique de backups ; audit sécurité.
- ERP critique : formaliser RPO/RTO, tester la reprise, et préparer un mode dégradé métier.
Atelier court : cartographie des risques, responsabilités, RPO/RTO, checklist et plan d’actions priorisé.
Sécurité et disponibilité des données Odoo : guide complet 2026.
Odoo centralise vos données financières, opérationnelles et personnelles (clients, employés, fournisseurs). Il est donc normal de se poser trois questions simples : qui contrôle, qui sécurise, et que se passe-t-il en cas de panne.
Vous donner une lecture claire, sans jargon inutile, pour comprendre : vos droits (propriété des données), les responsabilités (SaaS vs on-premise), et les garanties (sauvegardes, RPO/RTO, SLA).
- Vous restez propriétaire de vos données, quel que soit le mode d’hébergement.
- Le contrôle technique varie fortement : en SaaS, Odoo opère l’infrastructure ; en on-premise, c’est vous (ou votre infogérant).
- La sécurité est une responsabilité partagée : il faut savoir “qui fait quoi”, sinon on se raconte une histoire.
🔑 Introduction : la propriété et le contrôle de vos données sensibles.
En pratique, la question n’est pas seulement “est-ce sécurisé”. La vraie question, c’est : qui a la main sur l’hébergement, les sauvegardes, les accès, les mises à jour, et les plans de reprise.
Bonne nouvelle : vous restez propriétaire de vos données dans tous les modes d’hébergement. Nuance importante : le contrôle technique n’est pas le même, donc la responsabilité opérationnelle non plus.
🧭 Ce qui ne change pas
- Principe
- Vos données vous appartiennent, et vous devez pouvoir les récupérer.
- Enjeu
- Formaliser l’export, les accès, et les délais de restitution.
Action recommandée. Documenter qui exporte, à quelle fréquence, où sont stockées les copies, et qui peut restaurer.
⚖️ Ce qui change selon l’hébergement
- SaaS
- Odoo gère l’infrastructure, la disponibilité, une partie de la sécurité, et la maintenance.
- On-premise
- Vous (ou votre prestataire) gérez tout : patch, réseau, sauvegardes, supervision, reprise.
Piège classique. Croire qu’un hébergement “cloud” suffit à couvrir vos obligations internes (accès, MFA, procédures).
🏗️ L’hébergement de mes données dans Odoo est-il sécurisé.
Pour répondre, il faut distinguer clairement : SaaS (Odoo Online) et on-premise (chez vous ou chez un hébergeur que vous pilotez). Le niveau de contrôle et la charge de sécurité n’ont rien à voir.
SaaS = sécurité industrialisée + responsabilités partagées
On-premise = contrôle total + responsabilité totale
☁️ Sécurité de la formule SaaS.
En SaaS, l’infrastructure et l’exploitation sont opérées par Odoo et ses sous-traitants d’hébergement. Vous gagnez en simplicité, mais vous devez quand même piloter les accès et la gouvernance.
🏷️ Audits, conformité et datacenters
- À savoir
- Odoo mentionne des audits SOC 1 / SOC 2 (accès sous NDA).
- ISO
- Les datacenters des hébergeurs peuvent être certifiés (ex : ISO 27001 selon l’hébergeur).
- RGPD
- La région d’hébergement peut être choisie (ex : Europe) selon la politique de confidentialité.
Action recommandée. Demander les éléments de conformité utiles : SOC sous NDA, clauses RGPD, et région d’hébergement.
🔒 Sécurité applicative “par design”
- Flux
- Communications chiffrées via SSL/TLS.
- Risques
- Protections classiques côté application (XSS, CSRF, injections) via mécanismes du framework.
- Exposition
- Moins d’exposition “infra” pour vous, plus de focus sur comptes et droits.
Décision à déclencher. Si vous avez des données très sensibles, renforcez MFA, politiques de mot de passe, revue des droits et journaux.
🛡️ Segmentation, isolation, anti-abus
- Principe
- Base isolée par client en environnement multi-tenant.
- Défense
- Mesures de protection contre DDoS et attaques communes (selon infrastructure).
- Limite
- Vous ne gérez pas la couche réseau, mais vous devez durcir les accès.
Action recommandée. Limitez les comptes admin, imposez MFA si disponible, et auditez les accès inactifs.
🗄️ Sauvegardes et restauration
- Cadence
- Politique type : 14 sauvegardes (journalières, hebdo, mensuelles) conservées au moins 3 mois.
- RPO
- Objectif : RPO 24h (perte max théorique).
- RTO
- Objectif : RTO 6h (incident serveur) et RTO 24h (sinistre datacenter).
Piège classique. Se reposer uniquement sur le fournisseur : gardez vos exports réguliers et testez une restauration “à blanc”.
Selon les engagements publiés, les sauvegardes peuvent être répliquées sur plusieurs sites et régions. Si votre conformité impose “Europe only”, faites confirmer par écrit la politique appliquée à votre base.
🖥️ Sécurité de l’on-premise.
En on-premise, vous obtenez un contrôle maximal. Mais ce contrôle a un coût : vous portez l’exploitation et la sécurité. Si vous n’avez pas une équipe infra/sécu, il faut un infogérant cadré par un vrai SLA.
🧩 Mises à jour et correctifs
- Obligation
- Appliquer OS, dépendances, Odoo et correctifs de sécurité régulièrement.
- Risque
- Une version non maintenue = surface d’attaque élevée.
Action recommandée. Planifier un cycle patch (mensuel) + patch urgent (48h) + suivi de versions.
🌐 Réseau, pare-feu, accès distants
- À mettre
- Pare-feu, whitelists, IDS/IPS si possible, VPN pour accès admin.
- Durcissement
- Désactiver root, SSH par clés, limitation IP, journalisation.
Décision à déclencher. Si vous exposez Odoo sur internet, mettez un reverse proxy durci + WAF + supervision.
👤 Identités, droits et moindre privilège
- Principe
- Moindre privilège pour tous les utilisateurs.
- Hygiène
- Revues d’accès trimestrielles, suppression des comptes obsolètes.
Action recommandée. Mettre une matrice rôles/permissions + un rituel de revue des accès.
🗄️ Sauvegardes, chiffrement, tests de reprise
- Standard
- Approche 3-2-1 : 3 copies, 2 supports, 1 hors site.
- Tests
- Tester une restauration régulièrement, pas seulement “avoir des backups”.
Piège classique. Découvrir que les sauvegardes ne restaurent pas le jour où on en a besoin.
⏱️ Existe-t-il des garanties contre les interruptions de service.
Aucun système n’est à zéro panne. La question utile : quel niveau de disponibilité, quels délais de reprise, et quel plan B si l’ERP est critique.
📜 SLA 99,9 % (SaaS)
- Niveau
- Objectif mensuel 99,9 % (hors maintenances planifiées).
- Ordre de grandeur
- 99,9 % ≈ 45 min d’arrêt non planifié max par mois.
Action recommandée. Vérifier les clauses de crédit de service et les exclusions (maintenance, force majeure).
🧯 Haute disponibilité et redondance
- Principe
- Datacenters de niveau Tier III (ou équivalent) avec redondance alimentation et réseau.
- Réplication
- Réplication quasi temps réel sur stockage redondant (selon architecture).
Décision à déclencher. Si votre activité ne supporte pas l’arrêt, étudiez une architecture HA + un mode dégradé métier.
🧪 Surveillance et maintenance
- Monitoring
- Supervision continue + alertes sur seuils de performance.
- Maintenance
- Fenêtres planifiées idéalement en heures creuses.
Action recommandée. Définir un canal incident interne : qui alerte, qui décide, qui communique.
🧩 Votre “plan B” métier
- Objectif
- Continuer à vendre, livrer, ou facturer même en mode dégradé.
- Exemples
- Procédures temporaires, exports quotidiens, fichiers de secours, priorités.
Décision à déclencher. Si l’ERP est “arrêt de production”, formaliser un PCA simple et le tester une fois par an.
🗄️ Sauvegardes et reprise après incident : ce que vous devez exiger.
La sécurité, ce n’est pas seulement empêcher l’attaque. C’est aussi être capable de restaurer vite avec un niveau de perte acceptable.
- RPO : combien d’heures de données vous pouvez perdre.
- RTO : en combien de temps vous devez redémarrer.
- Tests : est-ce que vous avez déjà restauré pour de vrai.
🌍 Où sont hébergées mes données.
Le point clé, c’est la région choisie (ex : Europe) et les sous-traitants qui opèrent l’infrastructure. En conformité, vous devez pouvoir répondre : “où”, “chez qui”, “sous quel régime”.
📍 Région d’hébergement
- Principe
- Les bases clientes sont hébergées dans une région définie (ex : Europe) selon les politiques applicables.
- Pratique
- Choisir la région adaptée à vos contraintes (RGPD, clients, secteur).
Action recommandée. Consigner la région dans votre documentation de conformité (et la contractualiser si nécessaire).
🏢 Sous-traitants d’hébergement
- Enjeu
- Connaître les acteurs (hébergement, mitigation, sauvegardes) et leurs certifications.
- Utile
- Faciliter les audits clients et répondre aux exigences sectorielles.
Action recommandée. Conserver la liste des sous-traitants et la version datée des politiques applicables.
Sur Odoo.sh, la région est généralement choisie au moment de la création du projet. Une fois le projet créé, le changement de région est très contraignant, donc il faut l’anticiper dès le cadrage.
✅ Checklist pratique : ce que vous devez mettre sous contrôle.
Si vous ne voulez retenir qu’une chose : la sécurité, c’est une liste de décisions. Voici une checklist terrain pour cadrer vite et bien.
👥 Accès et gouvernance
- À faire
- MFA si possible, admins limités, revues trimestrielles, désactivation des comptes dormants.
- Preuve
- Journal d’accès + procédure d’onboarding/offboarding.
Seuil d’alerte. Un “admin pour tous” = risque immédiat.
🧯 Continuité et reprise
- À faire
- RPO/RTO cibles, exports, test de restauration, mode dégradé métier.
- Preuve
- Compte-rendu de test de restauration, même simple.
Seuil d’alerte. Aucune restauration testée depuis 12 mois = risque élevé.
🔐 Conformité et contractualisation
- À faire
- Vérifier le SLA, la région, la politique de backups, et les clauses de sous-traitance.
- Preuve
- Documents signés + version datée des politiques applicables.
Seuil d’alerte. “On pense que c’est en Europe” sans document = non-auditable.
🛠️ Si vous êtes en on-premise
- À faire
- Cycle patch, supervision, durcissement SSH, pare-feu, sauvegardes 3-2-1, tests.
- Preuve
- Runbook + alerting + tableau de bord infra.
Seuil d’alerte. Absence de monitoring = pannes découvertes “par les utilisateurs”.
🎯 Synthèse : comment choisir (et sécuriser) sans se raconter d’histoires.
Si votre objectif est de réduire la charge technique, le SaaS apporte une exploitation industrialisée et des objectifs de disponibilité clairs. Si votre objectif est le contrôle maximal, l’on-premise est cohérent, mais exige une vraie capacité infra/sécu.
- Entreprise “standard” : SaaS + gouvernance d’accès + exports réguliers + PCA simple.
- Entreprise “réglementée” : contractualiser la région, les sous-traitants, et la politique de backups ; audit sécurité.
- ERP critique : formaliser RPO/RTO, tester la reprise, et préparer un mode dégradé métier.
Atelier court : cartographie des risques, responsabilités, RPO/RTO, checklist et plan d’actions priorisé.
Est-ce qu'Odoo garantit la sécurité et la disponibilité de mes données ?