Sécurité Dolibarr : haute disponibilité Comparaison pour réduire les erreurs

Sécurité & Haute Disponibilité de Dolibarr : Guide de Comparaison pour Réduire les Erreurs

Version 1.0 – Novembre 2025 —

1. Introduction

Dolibarr est un ERP / CRM open‑source très répandu dans les PME et les structures associatives. Sa simplicité d’installation et son moteur de base de données (MySQL / PostgreSQL / SQLite) en font une solution attractive, mais la sécurité et la disponibilité restent des défis majeurs lorsqu’on veut garantir un service ininterrompu, surtout en environnement de production.

Ce document propose :

Une cartographie des risques de sécurité propres à Dolibarr.

Les bonnes pratiques de mise en place d’une architecture haute disponibilité (HA).

Une comparaison d’outils et de stratégies (réplication de bases de données, clustering, load‑balancing, sauvegardes automatisées).

Des recommandations concrètes pour réduire les erreurs de configuration et les temps d’indisponibilité.

2. Dolibarr : points forts & faiblesses en termes de sécurité | Composant | Points forts | Points faibles / Risques |

|—|—|—|
| Installation | – Scripts d’installation simple (APT, YUM, Docker). | – Par défaut, les permissions des dossiers sont souvent trop permissives (chmod 777). |
| Authentification | – Support LDAP, 2FA (via plugin). | – Authentification par défaut utilise uniquement le mot de passe stocké en clair dans le fichier conf/conf.php. |
| Gestion des droits | – RBAC (rôles, groupes, utilisateurs). | – Le modèle RBAC n’est pas granularisé ; un dépassement de privilèges peut se produire si les plugins ne sont pas maintenus à jour. |
| Modules | – Plugins officiels et communautaires pour comptabilité, ventes, stocks, etc. | – Plugins non maintenus peuvent introduire des vulnérabilités (XSS, injection SQL). |
| Base de données | – Compatible MySQL, PostgreSQL, SQLite. | – Dépôts de données non chiffrés en transit → risque d’interception. |
| Transport | – Possibilité d’utiliser HTTPS avec certificats SSL. | – Configuration HTTPS souvent laissée à l’appréciation de l’administrateur → erreurs de configuration courantes. |

Conclusion : La plupart des failles proviennent d’une mauvaise configuration initiale et d’un manque de mise à jour des plugins. La sécurité doit donc être intégrée dès le design de l’infrastructure, pas seulement appliquée à la couche applicative.

3. Principes de la Haute Disponibilité (HA) appliqués à Dolibarr

Niveau	Objectif	Mécanisme	Outils courants
1 – Redondance de l’application	Aucun temps d’arrêt lors de la mise à jour ou du remplacement d’un nœud.	– Déploiement en cluster avec load‑balancer.	– HAProxy, NGINX, Traefik.
2 – Redondance de la base de données	Garantir la continuité des écritures même si un serveur DB tombe.	– Réplication synchrone ou asynchrone + failover automatisé.	– MySQL Group Replication, PostgreSQL Patroni, Galera.
3 – Sauvegarde & restauration	Limiter la perte de données en cas de corruption ou de sinistre.	– Backups incrémentaux + snapshots à chaud.	– Percona XtraBackup, pgBackRest, BorgBackup.
4 – Monitoring & automatisation	Détecter rapidement les anomalies et réagir automatiquement.	– Health checks, automatisation des déploiements (Ansible, Terraform).	– Prometheus + Alertmanager, Zabbix, Grafana.
5 – Sécurité intégrée	Protéger les canaux de communication et limiter les vecteurs d’attaque.	– TLS termination côté LB, chiffrement des réplicas, firewall interne.	– cert-manager, OpenSSL, iptables.

4. Comparaison des solutions HA – « Quel approche choisir ? »

Solution	Architecture proposée	Avantages	Inconvénients	Cas d’usage typique
A. Réplication MySQL + HAProxy	Active‑Active : 2 serveurs web + 2 serveurs DB réplicants (synchrone).	– Simple à mettre en place. – Réplication synchrone garantit aucune perte de transaction. – HAProxy assure répartition du trafic et bascule automatique.	– Nécessite mode synchrone → latence plus élevée. – Pas de scalabilité horizontale sans ajout de nouveaux nœuds.	PME qui veulent une solution « plug‑and‑play » sans cloud.
B. PostgreSQL Patroni + Kubernetes	Active‑Passive master‑slave avec Patroni orchestrant le basculement. Cluster de Pods dans un orchestrateur.	– haute résistance aux pannes. – Scalabilité horizontale (ajout de pods). – Gestion du stateful set via Helm.	– Courbe d’apprentissage technique. – Configuration plus lourde (et besoin d’un cluster K8s).	Entreprises déjà investies dans le cloud‑native et nécessitant une haute Résilience.
C. Galera Cluster (MySQL) + Traefik	Tous les nœuds DB sont maîtres et réplicent en multi‑master.	– Réplication synchrone avec consensus multi‑master → aucune perte même sur panne d’un nœud. – Découpage du bottlenecks réseau.	– Complexité de la configuration du wsrep (options `gcomm`). – Nécessite des transactions légères pour éviter le blocage.	Workloads en écriture intensive où la disponibilité absolue prime sur la latence.
D. Solution fully‑managed (Docker Swarm / Managed DB)	Utilisation de Docker Swarm pour le scaling et d’un service DB géré (ex. PlanetScale, Neon).	– Déploiement ultra‑rapide. – Gestion externalisée des backups & réplication. – Sécurité réseau via VPC et Service Mesh.	– Dépendance à un provider externe. – Coût variable selon le volume de trafic.	Start‑ups qui privilégient la rapidité de mise en production et la réduction de la charge d’opération.

Critère de décision :
• Latence → choisir réplication synchrone ou multi‑master seulement si le réseau interne est fiable.
• Scalabilité → opter pour K8s/Patroni si on prévoit de dépasser 5 serveurs web. > • Complexité opérationnelle → les solutions Docker‑Swarm ou Serverless sont plus faciles à gérer pour des équipes petites.

5. Plan de mise en œuvre pas‑à‑pas

5.1. Pré‑requis communs | Élément | Action | Comentaire |

5.2. Architecture type « Docker‑Compose + HAProxy + PostgreSQL Replication »

# docker-compose.yml (extrait)

version: "3.8"

services:

  db-master:

    image: postgis/postgis:15

    environment:

      POSTGRES_PASSWORD: secret

      POSTGRES_DB: dolibarr

    volumes:

      - pg_data_master:/var/lib/postgresql/data

    restart: always
db-slave:

    image: postgis/postgis:15

    environment:

      POSTGRES_PASSWORD: secret

    replicas: 1

    depends_on:

      - db-master    restart: always
dolibarr:

    image: dolibarr/dolibarr:latest

    environment:

      DB_HOST: db-master

      DB_USER: dolibarr

      DB_PASSWORD: secret

    ports: ["80:80"]

    restart: always
haproxy:

    image: haproxy:2.8-alpine    volumes:

      - ./haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg:ro

    ports: ["8080:80"]

    depends_on: ["dolibarr"]

    restart: always
volumes:

  pg_data_master:

haproxy.cfg config en mode « http‑only » avec balance roundrobin et check.

Configurer PostgreSQL Streaming Replication avec primary_conninfo et hot_standby_feedback.

Activer le failover automatiquement via le script repmgr ou Patroni (voir section 5.3).

5.3. Orchestration avec Patroni (option avancée)

# patroni.yml (exemple minimal)

scope: dolibarr

match_path: /etc/patroni/*

name: node1

restart_policy:

  name: restart

  scope: systempostgresql:

  data_dir: /var/lib/postgresql/13/main

  listen: 0.0.0.0

  auth_requires: password

  parameters:

    max_connections: 100

    shared_buffers: 256MB    work_mem: 4MB

    effective_cache_size: 128MB

    max_wal_senders: 5

    wal_level: replica

    max_replication_slots: 5

    hot_standby: "on"

    synchronous_commit: "on"

  connservice:

    url: "etcd://etcd:2379/dolibarr"

    fallback: ["etcd://etcd2:2379/dolibarr"]

    max_retries: 5

  ttl: 30

  loop_wait: 10  postgresql:

    use_pg_rewind: true

    parameters:

      max_connections: 200

    authentication:

      replication:

        username: replicator

        password: secret

Deployer Patroni via Helm chart (helm repo add patroni https://github.com/zalando/charts.git).

Etcd assure la coordination du cluster. – Le scope dolibarr permet à Patroni de gérer automatiquement le leader election lorsqu’un nœud devient indisponible.

5.4. Monitoring & Alerting

Métrique	Seuil Critique	Action automatisée
Latence HTTP (p95)	> 300 ms	Scale‑out du service Dolibarr (Docker Swarm `--replicas`).
Erreurs 5xx (HAProxy)	> 5 % du trafic	Redémarrer le pod problématique; envoyer alerte Slack.
Replication lag (pg_stat_replication)	> 5 s	Basculer sur slave ; alerter l’équipe DBA.
Utilisation CPU > 85 % (sur DB)	> 10 min	Activer le scaling horizontal de la réplication (ajouter nœud).
Certificat expiré	Date d’expiration < 7 jours	Renouveler cert via `certbot` et recharger HAProxy.

Mise en place : Utiliser Prometheus (scrape /metrics de chaque conteneur) + Alertmanager pour les notifications. Grafana pour le tableau de bord Dolibarr‑HA.

6. Étude de cas : Passage d’un serveur unique à un cluster HA en 4 semaines

Phase	Activités	Durée	Résultat attendu
1 – Audit	Analyse des logs, identification des vulnérabilités, revue des permissions.	3 j	Rapport d’audit + liste d’actions prioritaires.
2 – Environnement de tests	Déploiement d’une stack Docker‑Compose en mode « sandbox ».	5 j	Pré‑validation de la réplication et du basculement.
3 – Migration progressive	1) Création du nouveau cluster DB (replication async). 2) Redirection du trafic 10 % → 30 % → 100 % vers le LB. 3) Activation du backup automatisé.	12 j	Aucun incident de perte de données, temps moyen d’indisponibilité < 30 s lors du basculement.
4 – Mise en production & tuning	Optimisation du `max_connections`, réglage des `keepalive` d’HAProxy, mise en place du monitoring.	5 j	SLA HA = 99,9 % (temps d’indisponibilité < 5 min/mois).
5 – Documentation & formation	Rédaction des procédures d’exploitation, formation du support.	5 j	Support capable de gérer le failover sans assistance externe.

Coût estimé : 2 serveurs PostgreSQL (VM 2 vCPU + 8 GiB RAM) + 2 serveurs web (Docker) + 1 LB + stockage distribué (NAS).
ROI : réduction de 70 % des tickets « service indisponible »,gain de 15 h/mois de maintenance.

7. Checklist de Sécurité & HA à valider avant le Go‑Live

✅	Point à vérifier
1	Version LTS de Dolibarr installée, plugins à jour.
2	Authentification 2FA activée (plugin “ldap2fa”).
3	Toutes les connexions DB chiffrées (`sslmode=require`).
4	Certificats SSL/TLS valides et renouvelés automatiquement.
5	`chmod` des dossiers `files/`, `pdf/`, `logo/` limité à `0750`.
6	Firewall : seul le port 443 (ou 8080) ouvert depuis l’Internet.
7	HAProxy/NGINX configuré en mode strict (`http-request deny if { src_port not 443 }`).
8	Réplication DB synchronisée avec checksum (pg_checksums).
9	Backup incrémental testé au moins une fois par mois.
10	Monitoring actif : alertes configurées, seuils critiques testés.
11	Procédure d’urgence documentée (script de basculement, restauration).
12	Tests de pénétration interne (OWASP ZAP) pour détecter XSS/SQLi.

8. Bonnes pratiques à retenir

Domaine	Bonne pratique
Mise à jour	Planifier une fenêtre de maintenance mensuelle pour appliquer les patches de sécurité et de Dolibarr.
Gestion des secrets	Utiliser Vault (HashiCorp) ou AWS Secrets Manager pour le stockage des mots de passe DB et clés API.
Limitation des privilèges	Créer un user DB dédié (`dolibarr_user`) avec uniquement les privilèges `SELECT,INSERT,UPDATE,DELETE` sur le schéma `dolibarr`.
Séparation des environnements	Deployer dev, test et prod sur des clusters distincts ; éviter le partage de bases de données entre environnements.
Tests de charge	Simuler au moins 200 RPS avec k6 ou Locust pour valider la scalabilité avant le déploiement.
Documentation	Conserver un run‑book versionné (Git) décrivant chaque étape de déploiement et de récupération.
Education	Former les équipes IT aux concepts de least privilege et security‑by‑design.

9. Conclusion

La sécurisation et la mise en place d’une haute disponibilité pour Dolibarr ne sont pas une simple addition de serveurs; elles requièrent une architecture pensée en profondeur, où chaque composant – du serveur web à la base de données – est’Isolé, répliqué, monitoré et documenté.

La sécurité passe avant tout par la réduction de la surface d’attaque (plugins désactivés, mots de passe forts, SSL/TLS obligatoire).

La disponibilité s’appuie sur une architecture de réplication adaptée (synchrones ou asynchrones) et un mécanisme de basculement automatisé (HAProxy, Patroni, Galera).

Le choix de l’outil dépend de la taille de l’entreprise, du niveau d’expertise interne et des exigences de SLA.

En suivant le plan détaillé présenté ici, vous pourrez réduire les erreurs de configuration, éviter les pannes imprévues et offrir à vos utilisateurs une plateforme ERP stable, sécurisée et prête à évoluer avec vos besoins métier. > « La meilleure haute disponibilité est celle qui ne se remarque jamais » – Proverbe d’infrastructure.

10. Références & Ressources complémentaires

Documentation	Lien
Dolibarr – Guide d’installation officielle	https://www.dolibarr.org/en/doc/INSTALL
PostgreSQL – Streaming Replication	https://www.postgresql.org/docs/current/warm-standby.html
HAProxy – Configuration basique	https://www.haproxy.org/downloads/
Patroni – GitHub	https://github.com/zalando/patroni
Galera Cluster – Documentation	https://galera.com/documentation/
Prometheus – Alerting	https://prometheus.io/docs/alerting/latest/
OWASP ZAP – Guide de sécurité applicative	https://www.zaproxy.org/
HashiCorp Vault – Secrets Management	https://www.vaultproject.io/

Prepared by the Dolibarr Security & HA Working Group – November 2025.

Sécurité Dolibarr : haute disponibilité Comparaison pour réduire les erreurs

Sécurité & Haute Disponibilité de Dolibarr : Guide de Comparaison pour Réduire les Erreurs

1. Introduction

2. Dolibarr : points forts & faiblesses en termes de sécurité | Composant | Points forts | Points faibles / Risques |

3. Principes de la Haute Disponibilité (HA) appliqués à Dolibarr

4. Comparaison des solutions HA – « Quel approche choisir ? »

5. Plan de mise en œuvre pas‑à‑pas

5.1. Pré‑requis communs | Élément | Action | Comentaire |

5.2. Architecture type « Docker‑Compose + HAProxy + PostgreSQL Replication »

5.3. Orchestration avec Patroni (option avancée)

5.4. Monitoring & Alerting

6. Étude de cas : Passage d’un serveur unique à un cluster HA en 4 semaines

7. Checklist de Sécurité & HA à valider avant le Go‑Live

8. Bonnes pratiques à retenir

9. Conclusion

10. Références & Ressources complémentaires

Dolibarr et la gestion des commandes : Avis et témoignages d’utilisateurs

Pourquoi Dolibarr multi-utilisateurs est le choix idéal pour votre gestion ?

Les fonctionnalités essentielles de Dolibarr et la gestion des relations clients

Dolibarr stock : Astuces et conseils dʼexperts

Comparatif des solutions Dolibarr CRM

Le guide ultime pour comprendre Dolibarr multi-entrepôts

Sécurité & Haute Disponibilité de Dolibarr : Guide de Comparaison pour Réduire les Erreurs

1. Introduction

2. Dolibarr : points forts & faiblesses en termes de sécurité | Composant | Points forts | Points faibles / Risques |

3. Principes de la Haute Disponibilité (HA) appliqués à Dolibarr

4. Comparaison des solutions HA – « Quel approche choisir ? »

5. Plan de mise en œuvre pas‑à‑pas

5.1. Pré‑requis communs | Élément | Action | Comentaire |

5.2. Architecture type « Docker‑Compose + HAProxy + PostgreSQL Replication »

5.3. Orchestration avec Patroni (option avancée)

5.4. Monitoring & Alerting

6. Étude de cas : Passage d’un serveur unique à un cluster HA en 4 semaines

7. Checklist de Sécurité & HA à valider avant le Go‑Live

8. Bonnes pratiques à retenir

9. Conclusion

10. Références & Ressources complémentaires

Publications similaires

4. Comparaison des solutions HA – « Quel approche choisir ? »

5.2. Architecture type « Docker‑Compose + HAProxy + PostgreSQL Replication »

6. Étude de cas : Passage d’un serveur unique à un cluster HA en 4 semaines