Dolibarr est souvent au cœur de l’activité (factures, clients, devis, stocks, documents). Une instance exposée sur Internet sans durcissement, c’est une cible facile : tentatives de connexion en rafale, vol de comptes, fuites de données, et parfois arrêt total du service.
Dans ce guide, on voit comment sécuriser Dolibarr de façon pragmatique : accès web, comptes utilisateurs, serveur, base de données, sauvegardes et mises à jour.
Si vous voulez une voie simple pour héberger Dolibarr (déploiement 1 clic, facturation à l’heure, stop/start, sauvegardes automatiques, scaling), vous pouvez démarrer ici : Dolibarr sur adgents.cloud.
1) Commencer par une base saine : architecture et surface d’exposition
La règle d’or : exposer le minimum. Dans la plupart des cas, Dolibarr doit être accessible :
- uniquement en HTTPS,
- derrière un reverse proxy (Nginx/Traefik/Caddy),
- avec un filtrage contre le bruteforce,
- avec une politique de sauvegarde testée.
Si vous partez d’une installation Docker, ce guide de déploiement vous donne une base solide (HTTPS + persistance + sauvegardes) : Installer Dolibarr avec Docker Compose (HTTPS + sauvegardes).
2) HTTPS + reverse proxy : l’indispensable
Forcer HTTPS partout
- Redirection 80 → 443
- HSTS (si vous maîtrisez votre domaine)
- Cookies en mode sécurisé (via configuration PHP et proxy)
Ajouter des barrières simples contre les attaques courantes
Quelques protections côté reverse proxy font une énorme différence :
- limitation de débit sur / (et surtout sur l’écran de connexion)
- blocage des user-agents aberrants
- règles anti-scan (requêvos suspectes, endpoints inexistants)
Pour aller plus loin, un WAF (ex : Cloudflare ou ModSecurity) est un bon complément, surtout si votre Dolibarr est très exposé.
3) Comptes, permissions et 2FA : réduire l’impact d’un compte compromis
Appliquer le principe du “strict nécessaire”
- 1 compte admin (ou très peu)
- des rôles par métier (commercial, compta, support…)
- pas de droits “fourre-tout”
Renforcer l’authentification
- mots de passe robustes (longs + uniques)
- 2FA si disponible dans votre contexte
- verrouillage après échecs répétés
Si vous avez des automatisations autour de Dolibarr (emails, webhooks, synchronisations), isolez-les via un compte technique dédié et limitez les droits à ce qui est strictement nécessaire. Pour cadrer l’usage côté PME, vous pouvez relire : Dolibarr pour TPE/PME : modules clés + cas d’usage.
4) Durcir le serveur Web et PHP (sans casser l’app)
Même si Dolibarr est “bon”, une configuration serveur trop permissive annule tous vos efforts. À viser :
- pas de listing de répertoires
- affichage d’erreurs désactivé en production
- versions à jour (OS, serveur web, PHP)
- droits fichiers/dossiers restrictifs (écriture seulement là où c’est nécessaire)
Astuce : évitez d’exposer le répertoire de documents dans la racine web. Dolibarr stocke des pièces jointes et des PDF générés : si ce répertoire est accessible directement, vous créez un point de fuite.
5) Base de données : limiter le rayon d’explosion
La base de données, c’est le coffre-fort. Bon réflexes :
- utilisateur dédié Dolibarr (pas root)
- privilèges minimaux
- accès réseau restreint (idéalement, DB non exposée à Internet)
- sauvegardes automatisées
6) Sauvegardes : ce qu’il faut vraiment conserver
Une restauration fiable passe par trois éléments :
- la base de données
- le répertoire de documents (PDF, fichiers téléversés, médias)
- le fichier de configuration (conf.php)
Objectif : pouvoir revenir en arrière après incident, migration ou mise à niveau.
Conseil simple : stocker au moins une copie hors serveur (externalisation), et faire un test de restauration périodique (même sur une instance temporaire).
7) Mises à jour sans stress : verrouiller l’install après opération
Les mises à jour corrigent des failles : il faut les faire, mais sans prendre de risque. Process efficace :
- tester sur une instance de pré-production si possible
- sauvegarder avant
- déployer la nouvelle version
- valider
Point important : après l’installation ou une mise à niveau, Dolibarr recommande de verrouiller le processus d’installation via un fichier de verrouillage (install.lock). Cela évite qu’un chemin d’installation reste exploitable “par accident”.
Pour un guide global sur la gestion de la prod (journalisation, mises à jour, supervision), vous pouvez aussi vous inspirer de : Odoo en production : hardening, mises à jour et monitoring (les principes sont identiques).
8) Logs et supervision : détecter tôt plutôt que réparer tard
Deux signaux à surveiller :
- pics d’échecs de connexion
- erreurs 4xx/5xx inhabituelles
Avec une brique type Fail2ban (ou équivalent) et une centralisation simple des logs (même “maison”), vous bloquez automatiquement les IP agressives et vous gardez une trace exploitable en cas d’incident.
Lancez-vous avec Dolibarr.
Envie de vous lancer avec Dolibarr ? Créez votre site web en quelques clics.
Dolibarr
ERP/CRM open-source
Vidéo (FR) : tutoriels Dolibarr
Pour compléter avec des démonstrations, voici une playlist en français :
Tutoriels Dolibarr (FR) — playlist
Conclusion
Sécuriser Dolibarr, ce n’est pas “ajouter un plugin” : c’est un ensemble cohérent (HTTPS + reverse proxy, rôles stricts, serveur durci, base protégée, sauvegardes testées, mises à niveau régulières).
Si vous voulez démarrer vite sans gérer l’infra, vous pouvez essayer Dolibarr sur adgents.cloud (déploiement en 1 clic, facturation à l’heure, stop/start, sauvegardes automatiques, scaling CPU/RAM).
