Un guide pratique pour les organisations qui souhaitent concilier performance fonctionnelle et exigences réglementaires.
1. Introduction
Dolibarr est un ERP open‑source très répandu dans les PME et les associations. Sa modularité, sa simplicité d’usage et son coût maîtrisé en font un choix évident pour automatiser la comptabilité, la gestion des stocks, les ventes ou encore la relation client.
Pourtant, dans un contexte où les exigences de conformité (RGPD, ISO 27001, SOX, etc.) se renforcent, les organisations ne peuvent plus se contenter d’un simple « ça marche ». La sécurité des données, la traçabilité des actions et la maîtrise des accès deviennent des critères décisifs.
Cet article s’appuie sur le retour d’expérience d’une PME française (secteur distributif, 120 collaborateurs) qui a implémenté Dolibarr 7.0 en mode production. Nous détaillons :
- Les contraintes de conformité rencontrées.
- Les mesures de sécurité mises en œuvre sur la plateforme.
- Les processus de contrôle et de gouvernance mis en place.
- Les leçons apprises et les bonnes pratiques à reproduire.
2. Cadre de conformité : quelles obligations ?
| Référence | Objectif principal | Impact sur Dolibarr |
|---|---|---|
| RGPD (UE) | Protection des données à caractère personnel | chiffrement, droit à l’oubli, registre des traitements. |
| ISO 27001 | Système de management de la sécurité de l’information (SMSI) | politique de sécurité, gestion des risques, continuité d’activité. |
| SOX (USA) | Fiabilité des rapports financiers | contrôle des accès aux écritures comptables, journalisation des transactions. |
| PCI‑DSS (si paiement carte) | Sécurisation des données de carte bancaire | besoins de segmentation, chiffrement TLS, logs d’accès. |
| Loi française « Informatique et Libertés » | Conformité RGPD | même exigences que le RGPD, mais sanctions locales. |
En résumé : si Dolibarr est utilisé pour stocker des données personnelles (clients, fournisseurs, salariés) ou des informations comptables sensibles, il faut s’assurer que chaque exigence de chaque référentiel est respectée.
3. Analyse de risque et axes de sécurisation
| Risque | Probabilité | Impact | Mesure de mitigation | Rôle concerné |
|---|---|---|---|---|
| Accès non autorisé aux données comptables | Moyenne | Élevé (perturbation financière) | Contrôle d’accès basé sur les rôles (RBAC), authentification forte (2FA), journalisation des changements. | Responsable comptabilité, admin serveur. |
| Fuite de données personnelles | Faible | Très élevé (amendes RGPD) | Chiffrement des colonnes sensibles (email, numéro de SIRET), stockage crypté, DPO en charge du registre des traitements. | DPO, admin application. |
| Altération de la comptabilité | Moyenne | Élevé (fraude) | Signature numérique destransactions, audit trail immutable (ex: MariaDB binlog + archivage). | Auditeur interne. |
| Dégradation du service (DDoS, panne) | Moyenne | Modéré | Load‑balancing, sauvegardes incrémentales journalières, plan de reprise d’activité (PRAs). | Responsable IT. |
| Exfiltration de données de facturation | Faible | Élevé (conformité PCI‑DSS) | Ségrégation du module facturation sur serveur dédié, tokens de paiement externes, TLS 1.3 obligatoire. | Responsable paiement. |
Ces risques ont été classé, mesurés, puis traités par l’approche « risk‑aware » du projet, conformément à l’ISO 27001.
4. Architecture sécurisée de Dolibarr
4.1. Séparation physique / logique
- Serveur d’application : instance Docker isolée (PHP 8.2, Apache 2.4) avec accès limité au réseau interne via un firewall applicatif.
- Base de données : MariaDB 10.11 en mode master‑slave, chiffrée au repos (AES‑256) et auditée via MariaDB Audit Plugin.
- Stockage des fichier : répertoire
files/monté sur volume chiffré (LUKS) et protégé par ACL Linux.
Bénéfice : même en cas de compromission du serveur d’application, les données de la base restent inaccessibles sans la clé de chiffrement.
4.2. Authentification et autorisation
| Élément | Implémentation | Justification |
|---|---|---|
| Login | Auth LDAP (Active Directory) + 2FA (TOTP) | Centralisation des comptes, conformité aux politiques password. |
| Rôles | 8 rôles prédéfinis (Admin, Comptable, Manager, Viewer, …) + personnalisation | Le principe du moindre privilège (PoLP) est appliqué à chaque opération (ex: création de facture). |
| Permissions | Tableau de contrôle d’accès (ACL) au niveau des modules (CRM, Compta, Stock) | Déclenchement d’évènements de sécurité (alerte si un “Viewer” tente d’ajouter une écriture). |
4.3. Cryptographie et transmission
- TLS 1.3 obligatoire sur toutes les communications (certificat Let’s Encrypt renouvelé automatiquement).
- Chiffrement des colonnes sensibles :
email,nom_client,TVA intracommunautairechiffrés via AES‑GCM avec clé stockée dans HashiCorp Vault. - Sauvegarde : dumps chiffrés (
mysqldump --encrypt) et archivés hors‑site (S3 avec SSE‑KMS).
4.4. Journalisation et audit
- Logs applicatifs (syslog + journald) agrégés dans ELK (Elastic + Logstash + Kibana).
- Logs base de données (binlog + audit plugin) conservés 90 jours, signés digitalement (SHA‑256).
- Alertes : dépassement de seuil de connexion échouée → ticket ITSM ; modification d’un rôle critique → notification au DPO.
5. Processus de gouvernance et contrôle continu
| Processus | Fréquence | Responsable | Outils |
|---|---|---|---|
| Revue de conformité | Trimestrielle | Comité Qualité & Sécurité | Checklist RGPD / ISO 27001, tableau de suivi. |
| Test d’intrusion | Annuel (ou à chaque évolution majeure) | Fournisseur externe certifié | OWASP ZAP, Nessus. |
| Mise à jour de version | Tous les 6 mois | Équipe DevOps | Ansible playbook, tests automatisés. |
| Gestion des incidents | En continu | Responsable IR (Incident Response) | Playbook IR conforme à ISO 27035. |
| Formation utilisateurs | Semi‑annuelle | RH + Sécurité IT | Module e‑learning « Bonnes pratiques Dolibarr ». |
| Audit interne | Tous les 12 mois | Auditeur interne | Rapport d’audit ISO 27001. |
Ces processus assurent un cycle PDCA (Plan‑Do‑Check‑Act) qui aligne les exigences de conformité sur le cycle de vie du logiciel.
6. Leçons apprises – Bonnes pratiques à retenir
| Leçon | Description | Action concrète |
|---|---|---|
| 1️⃣ Ne pas confondre « open‑source » et « sans risque ». | Même si Dolibarr est gratuit, la sécurité dépend de la configuration et des processus. | Documenter chaque changement de configuration (version, paramètres de sécurité). |
| 2️⃣ Séparer les environnements de production et de test. | Un bug de test qui supprime les écritures en prod est catastrophique. | Utiliser des bases de données distinctes, désactiver le module de facturation en test. |
| 3️⃣ Mettre en place une politique de mots de passe forte dès le départ. | Les comptes par défaut (« admin », « password ») sont souvent exploités. | Désactiver les comptes système, forcer le changement de mot de passe au premier login. |
| 4️⃣ Chiffrer les données sensibles au repos. | Une fuite de backup non chiffré peut exposer des milliers d’enregistrements. | Utiliser LUKS + clés du HSM, ou services de chiffrement cloud. |
| 5️⃣ Automatiser la journalisation. | Sans logs centralisés, il est impossible de prouver la traçabilité lors d’un audit. | Configurer Filebeat → Elasticsearch → Kibana avec rétention définie. |
| 6️⃣ Impliquer le DPO dès la phase de conception. | La protection des données personnelles ne peut être un « post‑it ». | Intégrer le DPO aux revues de nouveaux modules (CRM, paiement). |
| 7️⃣ Tester les sauvegardes régulièrement. | Une sauvegarde corrompue rend le plan de reprise impossible. | Restaurer mensuellement une sauvegarde aléatoire sur serveur de test. |
| 8️⃣ Faire des revues de droit d’accès à chaque changement de rôle. | Un accès dépassé crée une faille de sécurité. | Utiliser les rapports d’audit RBAC avant toute promotion d’un collaborateur. |
| 9️⃣ Planifier une migration progressive. | Passer d’une version ancienne à la dernière peut introduire des incompatibilités. | Phase pilote : 3 mois de tests sur un sous‑ensemble de collaborateurs. |
| 🔟 Documenter tous les processus de sécurité (politiques, procédures, matrices de risque). | La conformité se prouve par la documentation. | Stocker les documents dans un espace de gestion documentaire (e.g., Nextcloud) avec contrôle de version. |
7. Checklist de mise en conformité pour un déploiement Dolibarr
| ✅ | Point à vérifier |
|---|---|
| 1 | La version installée est ≥ 7.2 (correction de vulnérabilités critiques). |
| 2 | Le serveur web est exposé uniquement en HTTPS avec certificat valide. |
| 3 | Les logs d’accès sont centralisés, horodatés et non réinitialisables. |
| 4 | Les rôles et permissions sont alignés sur le principe du moindre privilège. |
| 5 | Les données personnelles sont chiffrées et le registre des traitements est à jour. |
| 6 | Les journaux de base de données sont archivés et signés. |
| 7 | Un plan de récupération (backup + restore) est testé au moins une fois par trimestre. |
| 8 | La politique de mot de passe impose une longueur minimale de 12 caractères + expiration 90 jours. |
| 9 | Un processus d’authentification forte (2FA) est obligatoire pour les comptes à privilèges. |
| 10 | Un processus de revue de sécurité est mis en place (minimum annuel). |
8. Conclusion
Le retour d’expérience montre qu’il est tout à fait possible de faire de Dolibarr une plateforme ERP fiable et conforme, à condition d’appliquer une démarche rigoureuse de gouvernance de la sécurité.
Les points clés à retenir sont :
- Architecture en profondeur (séparation physique, chiffrement, TLS).
- Contrôle d’accès granulaire (RBAC + 2FA).
- Traçabilité exhaustive (journaux, signature des transactions).
- Processus de gouvernance (revues, audits, formation).
- Implication transverse (DPO, audit interne, responsables IT).
En suivant cette feuille de route, les organisations peuvent exploiter les avantages fonctionnels de Dolibarr tout en respectant les exigences de RGPD, ISO 27001 ou tout autre référentiel applicable.
« La sécurité ne se construit pas en un jour, elle se gère au quotidien. »
À propos de l’auteur
Jean‑Marc Lenoir, consultant en sécurité des systèmes d’information, spécialisé en ERP Open‑Source et conformité. Il accompagne depuis plus de 10 ans des PME dans la mise en conformité de leurs solutions Dolibarr, Odoo et Miracle‑Group.
Document rédigé le 3 novembre 2025, version 1.0.