Votre CRM Dolibarr contient sans doute le capital informationnel le plus précieux de votre entreprise : fiches clients, historiques de commandes, contrats fournisseurs, factures, données comptables, voire informations bancaires. Une faille de sécurité, une corruption de base de données ou un simple oubli de sauvegarde peut entraîner une catastrophe : pertes financières, atteinte à la réputation, sanctions RGPD, voire cessation d'activité.
Pourtant, beaucoup d'entreprises sous-estiment encore cette dimension critique. Dans ce guide fonctionnel complet, NEXT GESTION vous livre toutes les bonnes pratiques pour sécuriser durablement votre instance Dolibarr et garantir la continuité de vos données. Nous aborderons aussi bien la sécurité périmétrique (serveur, réseau) que la sécurité applicative (Dolibarr, base de données) et les stratégies de sauvegarde et de reprise d'activité conformes à l'état de l'art, en restant orientés métier et décisionnel.
Sommaire
- Pourquoi la sécurité de Dolibarr est-elle stratégique ?
- Comprendre l'architecture de Dolibarr
- Durcissement du système d'exploitation
- Sécurisation du serveur web
- Mise en place du HTTPS et des certificats SSL/TLS
- Sécurisation de la base de données
- Configuration sécurisée de l'environnement applicatif
- Sécurité applicative dans Dolibarr
- Authentification forte : 2FA, LDAP, SSO
- Sauvegarde de la base de données
- Sauvegarde des fichiers et documents
- La règle d'or 3-2-1 et le stockage hors site
- Tests de restauration et plan de reprise d'activité
- Journalisation, monitoring et détection d'incidents
- Conformité RGPD et obligations légales
- Erreurs critiques à éviter
- Conclusion : adopter une posture proactive
1. Pourquoi la sécurité de Dolibarr est-elle stratégique ?
Dolibarr étant un ERP/CRM web accessible via un navigateur, il est exposé par nature à toutes les menaces du web : attaques par force brute, injections SQL, cross-site scripting (XSS), exfiltration de données, ransomwares, etc. À cela s'ajoutent les risques internes : erreurs humaines, suppressions accidentelles, pannes matérielles ou logicielles, sinistres physiques (incendie, dégât des eaux, vol).
Les conséquences d'une compromission ou d'une perte de données peuvent être dramatiques :
- Pertes financières directes : impossibilité de facturer, retards de paiements, sanctions contractuelles.
- Atteinte à la réputation : perte de confiance des clients et fournisseurs.
- Sanctions RGPD : jusqu'à 4 % du chiffre d'affaires mondial ou 20 millions d'euros.
- Cessation d'activité : selon plusieurs études, 60 % des PME victimes d'une cyberattaque majeure font faillite dans les 6 mois.
Sécuriser Dolibarr n'est donc pas une option, c'est une obligation stratégique et légale.
2. Comprendre l'architecture de Dolibarr
Avant de sécuriser, il faut comprendre. Dolibarr s'appuie sur une pile logicielle classique composée de quatre couches : un système d'exploitation Linux (Debian, Ubuntu, RHEL, AlmaLinux), un serveur web (Apache ou Nginx), une base de données relationnelle (MySQL, MariaDB ou PostgreSQL) et un environnement d'exécution PHP. Chacune de ces couches doit être sécurisée individuellement car la compromission d'une seule peut suffire à mettre en péril l'ensemble.
Trois zones de stockage sont à protéger en priorité :
- La base de données : elle contient toutes vos données métier (clients, produits, commandes, factures, comptabilité).
- Le répertoire des documents : il contient les fichiers générés par Dolibarr (factures PDF, justificatifs, gestion électronique de documents, photos produits) ainsi que les fichiers temporaires.
- Le code source et la configuration : il contient le code de Dolibarr, vos modules personnalisés et surtout le fichier de configuration qui détient les identifiants de connexion à la base de données.
Le fichier de configuration mérite une attention particulière : sa fuite équivaut à compromettre l'intégralité du système. Il doit donc être protégé par des permissions strictes et placé dans un répertoire non accessible depuis le web.
3. Durcissement du système d'exploitation
La sécurité commence au niveau du système d'exploitation. Voici les actions de durcissement (« hardening ») incontournables sur un serveur Linux hébergeant Dolibarr.
Mises à jour systématiques
Les correctifs de sécurité doivent être appliqués sans délai. Configurez un mécanisme de mises à jour automatiques des paquets critiques (Ubuntu et Debian disposent d'un service dédié, RHEL et AlmaLinux également). Au minimum une fois par semaine, validez manuellement que les mises à jour ont bien été appliquées.
Pare-feu et ports ouverts
Le serveur ne doit exposer que les ports strictement nécessaires : HTTPS (443), éventuellement HTTP (80) pour la redirection vers HTTPS, et SSH (22) restreint aux seules adresses IP des administrateurs. Tous les autres ports sont fermés. Un pare-feu logiciel comme UFW ou firewalld permet d'appliquer cette règle simplement.
L'accès SSH lui-même doit être renforcé : connexion par clé cryptographique uniquement (pas de mot de passe), désactivation de la connexion directe en root, changement éventuel du port par défaut, et restriction aux adresses IP de confiance.
Protection contre les attaques par force brute
Un outil de détection d'intrusion comme Fail2ban analyse en continu les journaux de connexion et bannit automatiquement les adresses IP qui multiplient les tentatives échouées (sur SSH, sur le formulaire de connexion Dolibarr, sur les API). Configurez plusieurs « jails » dédiées pour couvrir l'ensemble des points d'entrée.
Gestion des comptes et privilèges
Appliquez le principe du moindre privilège : pas de connexion directe en root, des comptes utilisateur nominatifs avec sudo pour les opérations d'administration, désactivation des comptes système non nécessaires. Chaque action sensible doit pouvoir être tracée à un utilisateur identifié.
Cloisonnement des processus
Activez SELinux (sur RHEL/AlmaLinux) ou AppArmor (sur Debian/Ubuntu) en mode strict (« enforcing »). Ces mécanismes cloisonnent les processus et limitent considérablement l'impact d'une compromission : même si un attaquant prend le contrôle d'un processus web, il ne pourra pas accéder à des ressources système qui ne lui sont pas explicitement autorisées.
4. Sécurisation du serveur web
Le serveur web est la porte d'entrée de Dolibarr. Sa configuration doit être rigoureuse.
Masquer les informations sensibles
Par défaut, Apache et Nginx exposent leur version dans les en-têtes HTTP et les pages d'erreur. Cette information facilite le travail des attaquants en leur permettant de cibler des vulnérabilités connues. Désactivez systématiquement l'affichage de la version du serveur et des modules installés.
Activer les en-têtes de sécurité HTTP
Plusieurs en-têtes HTTP modernes améliorent significativement la sécurité applicative :
- HSTS force le navigateur à utiliser exclusivement le HTTPS.
- X-Content-Type-Options empêche l'interprétation incorrecte des types de fichiers.
- X-Frame-Options protège contre les attaques par clickjacking.
- Content-Security-Policy restreint les sources de scripts, de styles et d'images, prévenant ainsi de nombreuses attaques XSS.
- Referrer-Policy contrôle les informations transmises lors des navigations.
- Permissions-Policy désactive les fonctionnalités sensibles non utilisées (caméra, microphone, géolocalisation).
L'activation de ces en-têtes est un quick win essentiel.
Protection des répertoires sensibles
Le répertoire des documents et le répertoire de configuration ne doivent jamais être directement accessibles depuis le web. La meilleure pratique consiste à les placer en dehors de la racine web : ainsi, même en cas de mauvaise configuration, ils restent invisibles depuis l'extérieur. Si ce n'est pas possible, configurez le serveur web pour bloquer explicitement leur accès.
Suppression de l'installeur
Une fois Dolibarr installé, le répertoire d'installation doit être supprimé ou bloqué. Sans cette précaution, un attaquant pourrait relancer l'installation et écraser votre base de données. Créez également un fichier de verrou empêchant toute réinstallation involontaire.
Pare-feu applicatif (WAF)
Pour aller plus loin, déployez un pare-feu applicatif comme ModSecurity couplé au OWASP Core Rule Set. Ce dispositif inspecte chaque requête HTTP et bloque les comportements suspects (injections SQL, XSS, scans de vulnérabilités). Pour les sites les plus exposés, un service de WAF cloud type Cloudflare offre une protection complémentaire contre les attaques DDoS.
5. Mise en place du HTTPS et des certificats SSL/TLS
Aucune installation de Dolibarr en production ne devrait fonctionner en HTTP. Le HTTPS est obligatoire pour chiffrer les flux et protéger les sessions, les mots de passe, les données clients et les documents échangés.
Obtenir un certificat
L'obtention d'un certificat SSL/TLS est aujourd'hui simple et gratuite grâce à Let's Encrypt, autorité de certification reconnue par tous les navigateurs. Un outil comme Certbot automatise l'émission, l'installation et le renouvellement du certificat tous les 90 jours. Vérifiez régulièrement que le renouvellement automatique fonctionne pour éviter une expiration imprévue.
Pour les organisations qui le souhaitent, des certificats payants (DV, OV ou EV) restent disponibles auprès d'autorités commerciales et peuvent être pertinents dans certains contextes (validation étendue affichée dans le navigateur).
Configuration TLS moderne
Désactivez les protocoles obsolètes (SSL, TLS 1.0, TLS 1.1) qui présentent des vulnérabilités connues. N'autorisez que TLS 1.2 et TLS 1.3. Sélectionnez des suites cryptographiques modernes (ECDHE avec AES-GCM ou ChaCha20) et désactivez les algorithmes faibles. Testez votre configuration sur SSL Labs (ssllabs.com/ssltest) et visez la note A+.
Forcer la redirection HTTP vers HTTPS
Toute requête HTTP doit être automatiquement redirigée vers HTTPS. Cette règle est la première ligne de défense : elle garantit qu'aucun trafic ne transite en clair.
HSTS et HSTS preload
Le HSTS (HTTP Strict Transport Security) impose au navigateur l'usage exclusif du HTTPS pour votre domaine, même si l'utilisateur tape l'URL sans préciser le protocole. Une fois la valeur stable, vous pouvez soumettre votre domaine à la HSTS Preload List, ce qui inscrit la règle directement dans les navigateurs et bloque toute connexion HTTP, y compris la première.
6. Sécurisation de la base de données
La base de données est le trésor de Dolibarr. Sa protection est critique.
Initialisation sécurisée
À l'installation, lancez le script d'initialisation sécurisée fourni par MySQL ou MariaDB. Il vous permet de définir un mot de passe robuste pour le compte d'administration, de supprimer les utilisateurs anonymes, d'interdire la connexion à distance pour les comptes privilégiés et de supprimer les bases de test.
Compte dédié à Dolibarr
Ne jamais utiliser le compte d'administration de la base pour Dolibarr. Créez un compte dédié avec les privilèges strictement nécessaires : lecture, écriture, modification des structures de tables uniquement sur la base Dolibarr, pas d'accès aux autres bases ni aux droits d'administration globaux. Ce cloisonnement limite considérablement l'impact d'une éventuelle compromission de l'application.
Restriction de l'écoute réseau
Si la base de données est sur le même serveur que Dolibarr, configurez-la pour n'écouter que sur l'interface locale (loopback). Aucune connexion distante n'est ainsi possible. Si la base est déportée sur un autre serveur, utilisez impérativement un canal chiffré : VPN, tunnel SSH ou TLS natif sur la base de données.
Chiffrement au repos
Pour les données les plus sensibles, activez le chiffrement transparent au repos (TDE) au niveau du moteur de base de données. Cela protège vos fichiers de données en cas de vol physique du disque ou de compromission de la sauvegarde brute. Les clés de chiffrement doivent être stockées sur un support distinct, idéalement dans un coffre-fort numérique.
Journalisation des accès
Activez le journal d'audit de la base de données. Il enregistre toutes les connexions et requêtes sensibles, permettant de détecter a posteriori une intrusion ou un usage anormal. Ces journaux doivent être eux-mêmes protégés et conservés de manière sécurisée.
7. Configuration sécurisée de l'environnement applicatif
L'environnement PHP qui exécute Dolibarr doit faire l'objet d'un durcissement spécifique.
Désactivation des fonctions dangereuses
PHP propose de nombreuses fonctions susceptibles d'être détournées par un attaquant (exécution de commandes système, lecture de fichiers arbitraires, etc.). Désactivez explicitement celles qui ne sont pas nécessaires à Dolibarr. Attention toutefois : certains modules Dolibarr (export, mailing, OCR) peuvent en avoir besoin. Testez toujours en pré-production avant la mise en production.
Masquer les erreurs
En production, n'affichez jamais les erreurs PHP au visiteur. Elles pourraient révéler des informations sensibles (chemins, identifiants, requêtes SQL). Les erreurs doivent être consignées dans un journal accessible uniquement aux administrateurs.
Sessions sécurisées
Les cookies de session doivent être marqués comme HttpOnly (inaccessibles en JavaScript), Secure (transmis uniquement en HTTPS) et SameSite Strict (non envoyés par les sites tiers). Ces drapeaux préviennent de nombreuses attaques de vol de session. La durée de vie des sessions doit également être limitée (30 minutes d'inactivité maximum).
Limites raisonnables
Configurez des limites de ressources adaptées : taille maximale d'upload, durée maximale d'exécution, mémoire allouée. Ces paramètres protègent à la fois contre les abus volontaires (déni de service) et les bugs accidentels.
Cache et performance
Activez OPcache pour mettre en cache le code PHP compilé. Cela améliore les performances, réduit la charge serveur et limite la fenêtre exploitable lors d'une attaque par épuisement des ressources.
8. Sécurité applicative dans Dolibarr
Dolibarr propose nativement plusieurs mécanismes de durcissement à activer.
Paramètres de sécurité globaux
Dans le menu de configuration de la sécurité, plusieurs leviers sont à activer :
- Délai d'expiration de session : 30 minutes maximum, idéalement 15 pour les comptes administrateurs.
- Politique de mots de passe : longueur minimale de 12 caractères, exigence de complexité (majuscules, minuscules, chiffres, caractères spéciaux), expiration tous les 90 jours, interdiction de réutiliser les anciens mots de passe.
- Protection anti-CSRF : activée par défaut, à conserver impérativement et à étendre au niveau le plus élevé pour exiger un jeton sur tous les formulaires sensibles.
- Blocage automatique des comptes après plusieurs tentatives infructueuses (5 par défaut), avec déblocage manuel ou temporisé.
Permissions granulaires
Dolibarr propose un système de permissions par module et par action très fin. Appliquez le principe du moindre privilège : chaque utilisateur n'a que les droits strictement nécessaires à sa fonction. Un commercial n'a pas accès à la comptabilité, un comptable n'a pas accès aux données RH, etc. Cette discipline limite les fuites de données internes et l'impact d'une compromission de compte.
Multi-sociétés et cloisonnement
Si vous gérez plusieurs entités juridiques avec le module multi-sociétés, veillez à l'isolation stricte des données entre sociétés. Configurez les groupes utilisateurs pour éviter toute fuite latérale, et auditez régulièrement les accès croisés.
Désactivation des modules inutiles
Chaque module activé augmente la surface d'attaque. Faites un audit régulier et désactivez tout ce qui n'est plus utilisé. Moins il y a de code actif, moins il y a de vulnérabilités potentielles.
Forcer le HTTPS au niveau applicatif
Au-delà de la redirection serveur, Dolibarr peut être configuré pour refuser les connexions non sécurisées au niveau applicatif. Cette double protection garantit qu'aucun accès direct en HTTP ne peut compromettre les sessions.
9. Authentification forte : 2FA, LDAP, SSO
Le mot de passe seul n'est plus suffisant. Plusieurs options de renforcement de l'authentification s'offrent à vous.
Double authentification (2FA / MFA)
L'activation de la double authentification est aujourd'hui le minimum pour les comptes sensibles (administrateurs, comptables, dirigeants). Elle ajoute un second facteur de vérification, généralement un code temporaire généré par une application mobile (Google Authenticator, Authy, Microsoft Authenticator, FreeOTP). Même si un mot de passe est compromis, l'attaquant ne peut pas se connecter sans accès physique au téléphone de l'utilisateur. Un module dédié, disponible sur le Dolistore, permet de l'activer simplement.
Authentification LDAP / Active Directory
Pour les entreprises disposant d'un annuaire centralisé, Dolibarr propose un connecteur natif vers LDAP/Active Directory. Les utilisateurs se connectent à Dolibarr avec leurs identifiants d'entreprise, gérés centralement par la DSI. Avantages : application automatique des politiques de mot de passe d'entreprise, désactivation immédiate du compte Dolibarr en cas de départ d'un collaborateur, traçabilité unifiée.
Single Sign-On (SSO) via SAML ou OpenID Connect
Pour aller plus loin, des modules permettent de connecter Dolibarr à un fournisseur d'identité (Keycloak, Azure AD, Okta, Google Workspace) via les standards SAML 2.0 ou OpenID Connect. Vos utilisateurs se connectent une fois pour accéder à l'ensemble de leurs outils, le MFA est centralisé et appliqué uniformément, la conformité est simplifiée. C'est la meilleure pratique pour les organisations ayant plusieurs applications métier.
10. Sauvegarde de la base de données
La sauvegarde régulière de la base de données est l'opération la plus critique.
Fréquence et rétention
Au minimum, planifiez une sauvegarde complète quotidienne, exécutée pendant une période de faible activité (en général la nuit). Pour les environnements critiques, complétez par des sauvegardes incrémentielles plus fréquentes (toutes les heures, voire en continu). La rétention recommandée : 30 jours pour les sauvegardes opérationnelles, 1 à 10 ans pour les sauvegardes archivées en fonction de vos obligations légales.
Méthodes de sauvegarde
Plusieurs approches coexistent :
- Sauvegarde logique (export SQL) : produit un fichier texte lisible, idéal pour les petites et moyennes bases. Avantages : portabilité, possibilité de restauration partielle. Limites : lent au-delà de quelques gigaoctets.
- Sauvegarde physique à chaud : copie les fichiers binaires de la base sans interruption de service. Outils recommandés : Mariabackup (MariaDB) ou Percona XtraBackup (MySQL). Indispensable pour les grosses bases.
- Réplication vers un serveur secondaire en temps réel, qui peut servir à la fois de redondance et de cible pour les sauvegardes (sans impact sur la production).
- Snapshots au niveau du système de stockage ou de la machine virtuelle.
Compression et chiffrement
Toutes les sauvegardes doivent être compressées (réduction de taille) puis chiffrées (protection contre la fuite). Le chiffrement utilise idéalement une clé asymétrique (GPG par exemple) dont la clé privée est stockée séparément, dans un coffre-fort numérique. Vérifiez systématiquement l'intégrité des sauvegardes avec une empreinte cryptographique (somme de contrôle).
Restauration à un point dans le temps
Activez les journaux binaires (binary logs) sur le moteur de base de données. Ils permettent la restauration à un point précis dans le temps (Point-In-Time Recovery, PITR), par exemple « ramener la base à l'état de 14h32 hier, juste avant l'erreur ». Cette capacité est précieuse pour récupérer une suppression accidentelle sans perdre toutes les données ultérieures.
11. Sauvegarde des fichiers et documents
La base de données ne suffit pas : le répertoire des documents contient les PDF de factures, les justificatifs comptables, les fichiers GED et les photos produits. Sa perte serait tout aussi grave qu'une perte de base de données.
Sauvegardes incrémentielles
Pour les fichiers, privilégiez les sauvegardes incrémentielles avec versionnement : seuls les fichiers modifiés sont sauvegardés à chaque cycle, et chaque version reste accessible. Cette approche permet de conserver de nombreuses versions sans exploser l'espace disque, grâce à des mécanismes de liens durs ou de déduplication.
Code source et configuration
N'oubliez pas de sauvegarder également le code source (modules personnalisés, surcharges) et le fichier de configuration. Sans eux, une restauration de la base ne suffit pas à remettre le système en route.
Automatisation et planification
Toutes les sauvegardes doivent être automatisées et planifiées via un ordonnanceur (cron, timer systemd, planificateur Windows…). L'exécution manuelle est à proscrire : elle finit toujours par être oubliée. Mettez en place un compte technique dédié à ces opérations, avec les permissions strictement nécessaires.
Surveillance des sauvegardes
Chaque exécution doit produire un rapport indiquant son statut (succès, échec, durée, taille). En cas d'échec, une alerte doit être envoyée à l'administrateur. Une sauvegarde dont on ne sait pas si elle s'est déroulée correctement n'est pas une sauvegarde fiable.
12. La règle d'or 3-2-1 et le stockage hors site
La règle 3-2-1 de la sauvegarde est universellement reconnue :
- 3 copies des données (l'original + deux sauvegardes).
- sur 2 supports différents (disque local + NAS, par exemple).
- dont 1 copie hors site (cloud, datacenter distant, coffre-fort numérique).
Pourquoi cette règle ?
Cette règle protège contre les principaux scénarios de sinistre. Une seule copie peut être perdue dans un crash disque. Deux copies sur le même serveur sont perdues en cas d'incendie ou de ransomware. Une copie hors site garantit la continuité même en cas de destruction physique du site principal.
Synchronisation cloud chiffrée
Utilisez un fournisseur cloud souverain (OVHcloud, Scaleway, Outscale, Infomaniak) ou un service de stockage objet (S3, Backblaze B2, Wasabi) pour héberger la copie hors site. Les données doivent être chiffrées côté client avant l'envoi : ainsi, même le fournisseur cloud ne peut pas les lire. Des outils comme rclone ou restic automatisent cette synchronisation chiffrée.
Stockage immuable (Object Lock / WORM)
Activez le mode immuable (WORM, Write Once Read Many) sur votre stockage cloud : les sauvegardes ne pourront être ni modifiées ni supprimées pendant la période de rétention définie, même par un administrateur. C'est votre dernière ligne de défense contre les ransomwares modernes qui cherchent désormais à détruire les sauvegardes avant de chiffrer la production.
Air gap pour les données critiques
Pour les données les plus sensibles, conservez une copie sur un support physiquement déconnecté (disque externe ou bande LTO stockée dans un coffre). Cette copie « hors ligne » ne peut être atteinte par aucune attaque informatique. Sa rotation manuelle (hebdomadaire ou mensuelle) ajoute une couche de sécurité ultime.
13. Tests de restauration et plan de reprise d'activité
Tester ses sauvegardes
Une sauvegarde non testée n'est pas une sauvegarde.
C'est l'une des règles les plus violées en pratique. Beaucoup d'entreprises découvrent que leurs sauvegardes étaient corrompues ou incomplètes le jour où elles en ont besoin. Planifiez des tests de restauration trimestriels sur un serveur de pré-production : restauration complète de la base, restauration des documents, vérification de l'intégrité des données et de la cohérence applicative. Documentez les résultats et les éventuels problèmes rencontrés.
Plan de reprise d'activité (PRA / DRP)
Documentez un plan de reprise d'activité précisant :
- Le RPO (Recovery Point Objective) : la perte de données maximale tolérable. Par exemple, « nous acceptons de perdre au maximum 4 heures de données ».
- Le RTO (Recovery Time Objective) : la durée maximale d'interruption de service. Par exemple, « nous devons être de nouveau opérationnels en 2 heures ».
- Les rôles et responsabilités en cas de sinistre : qui décide, qui exécute, qui communique aux clients.
- Les procédures pas-à-pas de restauration, suffisamment détaillées pour qu'un administrateur de remplacement puisse les exécuter.
- Les coordonnées des prestataires (hébergeur, intégrateur Dolibarr, expert-comptable) accessibles même hors connexion.
Bascule sur serveur de secours
Pour les environnements critiques, mettez en place un serveur de secours synchronisé en quasi-temps réel via la réplication de base de données et la synchronisation continue des fichiers. En cas de sinistre, la bascule peut s'effectuer en quelques minutes par redirection DNS ou bascule automatique d'un load balancer. Cette architecture haute disponibilité est devenue accessible à des budgets PME.
Exercices de crise
Une fois par an, organisez un exercice de crise simulant un sinistre majeur. Toutes les équipes concernées (technique, métier, direction) participent et appliquent le plan. Ces exercices révèlent les manquements, les hypothèses fausses et les opportunités d'amélioration. Mieux vaut découvrir un problème lors d'un exercice qu'en situation réelle.
14. Journalisation, monitoring et détection d'incidents
Centralisation des journaux
Centralisez tous les journaux (serveur web, base de données, environnement PHP, Dolibarr, fail2ban) dans un outil dédié : Graylog, ELK (Elasticsearch + Logstash + Kibana) ou Loki + Grafana. Cette centralisation permet de corréler les événements et de détecter des anomalies invisibles à l'œil nu (multiples connexions échouées suivies d'une connexion réussie, requêtes inhabituelles, pics de trafic).
Monitoring des services
Surveillez en continu la disponibilité et les performances avec Zabbix, Prometheus + Grafana ou Netdata. Les indicateurs clés à surveiller :
- Charge CPU, mémoire, entrées/sorties disque.
- Temps de réponse des pages Dolibarr.
- Volume des sauvegardes et succès/échec des tâches planifiées.
- Espace disque restant (alerter à 80 % d'occupation).
- Validité des certificats SSL (alerter 30 jours avant expiration).
Détection d'intrusion fichier (HIDS)
Déployez un outil de détection d'intrusion fichier comme AIDE, Tripwire ou Wazuh. Il calcule régulièrement l'empreinte de tous les fichiers système et applicatifs, et alerte en cas de modification non prévue. C'est le moyen le plus efficace de détecter l'installation d'une porte dérobée (« webshell ») par un attaquant.
Alerting et astreinte
Configurez des alertes par email, Slack, Microsoft Teams ou solution d'astreinte (PagerDuty, Opsgenie). Définissez des seuils de criticité : information, avertissement, critique. Une intrusion détectée tôt est une intrusion contenue ; une intrusion détectée tard peut coûter très cher.
15. Conformité RGPD et obligations légales
Si vous traitez des données personnelles dans Dolibarr (clients, prospects, salariés), vous êtes soumis au RGPD. Et la sécurité technique est une exigence explicite de ce règlement.
Mesures techniques requises
Le RGPD exige des mesures techniques et organisationnelles « appropriées » au regard du risque :
- Chiffrement des données au repos et en transit.
- Contrôle d'accès par rôle, avec principe du moindre privilège.
- Journalisation des accès aux données personnelles.
- Pseudonymisation des données lorsque possible.
- Sauvegardes chiffrées et stockées de manière sécurisée.
- Tests réguliers d'efficacité des mesures de sécurité.
Droits des personnes
Dolibarr dispose de fonctions natives pour répondre aux droits RGPD des personnes concernées :
- Droit d'accès : export de toutes les données d'un contact dans un format lisible.
- Droit à la portabilité : export structuré (CSV, JSON) transmissible à un autre responsable de traitement.
- Droit à l'effacement : anonymisation ou suppression d'un tiers, avec traçabilité de l'opération.
- Droit de rectification : modification simple des données erronées.
- Droit à la limitation : désactivation de fiches tout en conservant l'historique pour des raisons légales.
Registre des traitements et analyse d'impact
Tenez un registre des traitements documentant l'usage de Dolibarr : finalités (gestion commerciale, comptabilité, RH), catégories de données collectées, durées de conservation, destinataires, mesures de sécurité. Pour les traitements à risque élevé (volumes importants, données sensibles), réalisez une analyse d'impact (AIPD) avant la mise en production.
Hébergement souverain
Pour les données sensibles, privilégiez un hébergement européen (OVHcloud, Scaleway, Outscale, Infomaniak) afin d'éviter les conflits avec le Cloud Act américain et de garantir la souveraineté des données. Un hébergeur certifié HDS (Hébergeur de Données de Santé) ou SecNumCloud offre des garanties supplémentaires pour les secteurs réglementés.
Notification en cas de violation
En cas de violation de données personnelles, vous avez 72 heures pour notifier la CNIL (en France) et, si le risque est élevé, informer les personnes concernées. Préparez à l'avance les modèles de communication et la procédure interne pour respecter ce délai.
16. Erreurs critiques à éviter
Notre expérience d'intégrateur Dolibarr nous a permis d'identifier les pièges récurrents :
- Ne jamais tester les restaurations. Le jour J, on découvre que les sauvegardes étaient corrompues ou incomplètes.
- Stocker les sauvegardes sur le même serveur que la production. Un ransomware ou un sinistre physique chiffrera et détruira tout d'un coup.
- Laisser le répertoire d'installation accessible. Un attaquant peut alors réinstaller Dolibarr et écraser votre base.
- Utiliser le compte administrateur pour le quotidien. En cas de compromission, l'attaquant a tous les pouvoirs. Réservez ce compte aux opérations d'administration explicites.
- Négliger les mises à jour. Les versions Dolibarr corrigent régulièrement des vulnérabilités critiques. Tester en pré-production puis appliquer rapidement.
- Mots de passe faibles ou partagés. Imposez un gestionnaire de mots de passe type Bitwarden, KeePass ou 1Password à toute l'équipe.
- Ignorer les journaux. Ils contiennent souvent les premiers signes d'une intrusion. Sans monitoring actif, l'alerte arrive trop tard.
- Exposer la base de données sur Internet. Restreignez systématiquement l'accès aux IP autorisées et passez par un VPN.
- Confondre redondance et sauvegarde. Un cluster en haute disponibilité ne protège pas contre une suppression accidentelle ou un ransomware.
- Ne pas former les utilisateurs. La majorité des compromissions débutent par un phishing réussi. La sensibilisation est aussi importante que la technique.
17. Conclusion : adopter une posture proactive
La sécurité et la sauvegarde de votre CRM Dolibarr ne sont pas des projets ponctuels mais une démarche continue. Elles reposent sur trois piliers indissociables : la prévention (durcissement, mises à jour, formation), la détection (monitoring, journalisation, audits) et la réaction (sauvegardes, plan de reprise, plan d'incident).
Chez NEXT GESTION, nous accompagnons les entreprises dans la sécurisation complète de leur instance Dolibarr : audit technique et organisationnel, durcissement serveur, mise en place de sauvegardes automatisées chiffrées, plan de reprise d'activité, conformité RGPD et infogérance proactive. Notre offre d'hébergement managé Dolibarr intègre nativement toutes les bonnes pratiques décrites dans ce guide, vous permettant de vous concentrer sur votre cœur de métier en toute sérénité.
Vous souhaitez auditer la sécurité de votre Dolibarr ? Contactez NEXT GESTION pour un diagnostic gratuit et personnalisé. Mieux vaut prévenir aujourd'hui que regretter demain.
FAQ : Sécurité et sauvegarde de Dolibarr
À quelle fréquence sauvegarder Dolibarr ? Au minimum une sauvegarde complète quotidienne de la base et des documents, complétée par des sauvegardes incrémentielles toutes les heures pour les environnements critiques.
Combien de temps conserver les sauvegardes ? Au moins 30 jours pour les sauvegardes opérationnelles, et 1 à 10 ans pour les sauvegardes archivées (selon vos obligations comptables et légales).
Le module de sauvegarde natif de Dolibarr suffit-il ? Il dépanne pour de petites instances, mais reste limité. Pour la production, privilégiez une stratégie professionnelle avec chiffrement et déport hors site.
Comment se protéger contre les ransomwares ? Sauvegardes chiffrées immuables (Object Lock), copie déconnectée (air gap), MFA généralisé, segmentation réseau, EDR sur les postes administrateurs et formation des équipes.
Dolibarr est-il conforme RGPD ? Dolibarr fournit les outils techniques (chiffrement, droits d'accès, export, anonymisation), mais la conformité dépend de votre paramétrage, de vos process et de votre hébergement.
Faut-il un hébergement managé ou peut-on s'auto-héberger ? L'auto-hébergement reste possible si vous disposez des compétences en interne. Sinon, l'hébergement managé professionnel offre un meilleur rapport sécurité/coût et libère vos équipes.
Article rédigé par NEXT GESTION, expert en intégration, sécurisation et infogérance Dolibarr ERP/CRM. Pour un audit ou un accompagnement, contactez-nous à contact@nextgestion.com.