Version Dolibarr ≥ 22.0 – mise à jour avril 2025
1. Introduction
Dolibarr est un ERP/CRM léger, mais très complet, qui peut être déployé tant sur un serveur local que dans le cloud. Son succès repose sur sa modularité : on ajoute ou désactive les modules selon les besoins métier.
Cependant, deux défis majeurs apparaissent lorsqu’on veut exploiter pleinement l’outil :
- Performance & gestion des ressources – limiter l’empreinte serveur (CPU, mémoire, I/O) tout en assurant un temps de réponse acceptable.
- Sécurité – protéger les données sensibles (clients, factures, paiements) contre les attaques web classiques (SQLi, XSS, CSRF, ransomware, fuite de données, etc.).
Cet article propose une approche globale d’optimisation des ressources avec une logique de sécurité intégrée pour les administrateurs, développeurs et responsables IT qui souhaitent exploiter Dolibarr en production.
2. Architecture & Ressources : les leviers d’optimisation
| Élément | Impact sur les ressources | Bonne pratique |
|---|---|---|
| Base de données | CPU/IO lors de requêtes lourdes (clients, factures, paiements). | • Utiliser MySQL 8/InnoDB avec innodb_buffer_pool_size ≥ 50 % de la RAM.• Activer le query cache uniquement si le volume est faible. • Configurer max_connections en fonction du nombre de connexions simultanées (ex. 150). |
| PHP | Taille des workers, cache opcodes. | • OpCache (PHP‑FPM) activé, opcache.enable=1 et opcache.max_accelerated_files > nombre de fichiers PHP (≈ 3000).• Augmenter pm.max_children (ou pm.max_spare_servers) pour éviter le dépassement de la RAM.• Utiliser le socket Unix au lieu du TCP pour les appels locaux. |
| Web server (NGINX/Apache) | Traitement des requêtes statiques et des sessions. | • Configurer worker_connections et worker_processes en fonction du nombre de cœurs.• Activer la compression gzip et la mise en cache expires pour les assets immutables. |
| Stockage | I/O disque (photos, documents). | • Stockage en SSD pour les répertoires files/ et dolibarr_data.• Utiliser le répertoire uploads dédié avec des quotas ou des politiques de rotation. |
| Cron jobs | Charge ponctuelle (synchros, nettoyage). | • Factoriser les exécutions (ex. toutes les 5 min au lieu de 1 min), regrouper les tâches similaires. • Loguer les sorties pour détecter les blocages. |
Astuce : créez un tableau de suivi des indicateurs (CPU, RAM, I/O, temps de réponse) via
htop,iostat, ou le module Monitoring de Dolibarr (menu →Administration > Monitoring).
3. Stratégie de Sécurité des Ressources
La sécurité n’est plus uniquement une question « patcher », elle doit être intégrée au pipeline d’optimisation. Voici les étapes clés :
3.1 Gestion des droits d’accès (RBAC)
- Principe du moindre privilège : chaque utilisateur possède uniquement les droits nécessaires à ses fonctions (ex. read‑only pour les auditeurs, edit uniquement sur ses propres factures).
- Rôles types : Admin, Manager, Accounting, Viewer.
- Audit interne : activer la fonction
Log history(Menu →Administration > Logs). Conserver les logs 90 jours minimum pour analyses rétro‑actives.
3.2 Sécurisation du serveur d’application
| Besoins | Mise en œuvre |
|---|---|
| HTTPS | Terminer le TLS à NGINX/Apache (certificat Let’s Encrypt ou interne). Forcer le HSTS. |
| Headers de sécurité | Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy. Ajouter via le fichier de configuration ou le module Security Headers de NGINX. |
| Protection contre les injection | Désactiver le magic_quotes (déjà obsolète) et assurer le prepared statements côté PHP (Dolibarr utilise PDO). |
| WAF | Déployer ModSecurity en mode “OWASP CRS 3.3”. Règles : 950100 – Requests with malformed request et 981176 – SQL injection. |
| Fail2Ban | Filtrer les requêtes brutes (POST /htdocs/c/multiusers/action_login.php). Créer un filtre pour bloquer les IP après 5 tentatives infructueuses. |
| Chroot / sandbox | Exécuter PHP‑FPM et le serveur web dans un chroot limité (/srv/dolibarr). Réduire la surface d’attaque en bloquant l’accès aux répertoires systèmes. |
3.3 Gestion des secrets & des accès
- Variables d’environnement : stocker les credentials DB (
DOL_DBHOST,DOL_DBNAME,DOL_DBPASS) hors du code source. - Secrets Manager (Vault, AWS Secrets Manager) : les récupérer au démarrage de PHP‑FPM.
- Permissions de fichiers :
chmod 640sur les fichiers de configuration (conf/interfaces.d/*,conf/clients.sql, etc.) ; le groupewww-datadoit être le propriétaire.
3.4 Sauvegarde & récupération sécurisée
| Aspect | Recommandation |
|---|---|
| Plan de backup | Utiliser mysqldump --single-transaction + tar -czf du répertoire files/. Planifier la sauvegarde incrémentale (daily) et la full hebdomadaire. |
| Chiffrement | Crypter le fichier backup avec gpg (clé RSA 4096) avant de le transmettre à un stockage externe (S3, Azure Blob). |
| Rotation | Conserver 30 jours de sauvegardes complètes, 7 jours de sauvegardes différentielles. |
| Test de restauration | Automatiser un job de restauration testée chaque mois dans un environnement de staging. |
NOTE : Une sauvegarde non testée ne sert à rien en cas d’incident.
4. Tableau de bord d’optimisation & de suivi continu
4.1 Métriques essentielles
| Métrique | Valeur cible | Outil de mesure |
|---|---|---|
| CPU | < 70 % d’utilisation moyenne | htop / top / Grafana (Prometheus) |
| RAM | < 75 % de la capacité | free -h |
Latence HTTP (GET /) |
< 200 ms | ApacheBench (ab) ou curl |
| Temps de réponse page facture | < 500 ms | Dolibarr → Reporting > Performance |
| Taux d’erreurs 5xx | < 0,1 % | Logs NGINX / mod_status |
| Nombre de requêtes SQL par seconde | < 150 | SHOW PROCESSLIST; MySQL |
| État du verrouillage de tables | 0 timeout | performance_schema MySQL |
4.2 Automatisation des alertes
- Grafana (datasource Prometheus) : panels pour CPU, Memory, MySQL QPS, Latence.
- Alertmanager : seuils déclenchent des e‑mails ou Slack. Exemple :
groups:
- name: dolibarr.metrics
rules:
- alert: HighCpuUsage
expr: node_cpu_seconds_total{mode="system"} > 0.7
for: 5m
labels:
severity: warning
annotations:
summary: "CPU system > 70 % sur le serveur Dolibarr" - Fail2Ban : notifications immediate lorsqu’un IP est banni.
5. Checklist d’optimisation sécurisée pour une production typique
| # | Action | Justification | Vérification |
|---|---|---|---|
| 1 | Activer OpCache et configurer opcache.memory_consumption ≥ 128 Mo |
Réduit le parsing PHP | php -i | grep opcache.memory_consumption |
| 2 | Configurer NGINX gzip on; + expires 30d; sur les assets |
Diminution du trafic réseau | Test curl -I sur fichiers statiques |
| 3 | Augmenter worker_processes à 2 (ou au nombre de cœurs) |
Utilisation optimale du CPU | grep worker_processes /etc/nginx/nginx.conf |
| 4 | Clôturer les droits d’écriture sur conf/ (chmod 640) |
Éviter la modification non autorisée | ls -l conf/ |
| 5 | Implémenter un WAF (ModSecurity) avec CRS 3.3 | Bloquer injection SQL / XSS | Test de injection manuelle sur formulaire client |
| 6 | Désactiver les modules PHP inutiles (ex. php_curl si non utilisé) |
Moins de surface d’attaque | php -m |
| 7 | Séparer les bases de données de production et de test | Limiter les fuites d’informations | SHOW CREATE DATABASE depuis chaque serveur |
| 8 | Mettre en place des backups chiffrés + test de restauration | Garantir continuité d’activité | Lancer gpg --decrypt backup.sql.gpg |
| 9 | Activer les logs d’audit (auditd) et exporter vers SIEM |
Détection précoce d’anomalies | Vérifier /var/log/audit/audit.log |
| 10 | Appliquer régulièrement les patches de sécurité de PHP, MySQL et NGINX | Réduction des vulnérabilités connues | apt list --upgradable ou yum update |
6. Bonnes pratiques complémentaires
- Utiliser les listes de diffusion et les forums : Dolibarr dispose d’une communauté active où l’on partage des scripts d’optimisation ou des patches de sécurité.
- Versionner les configurations : placer
conf/,interfaces.d/et les fichiers de base de données (*.sql) sous contrôle de version (Git). - Migrer progressivement vers la version LTS : chaque release LTS corrige les failles critiques et introduit des optimisations de requêtes.
- Limiter les API publiques : si vous exposez des Web‑services (ex. API de facturation), les placer derrière un API Gateway avec OAuth2.
- Restreindre l’accès au back‑office : IP whitelisting ou VPN pour les accès d’administration.
7. Conclusion
Optimiser Dolibarr ne se résume pas à « lancer top et faire du scaling ». C’est une synergie entre :
- Gestion fine des ressources (DB, PHP, serveur web, stockage) afin de garantir des temps de réponse rapides même sous charge.
- Intégration de la sécurité dès la conception : droits RBAC, configuration TLS, WAF, gestion des secrets, sauvegardes chiffrées et plan de reprise d’activité.
En suivant la checklist et le tableau de bord présentés, les équipes peuvent :
- Réduire les goulets d’étranglement sans recourir à des serveurs plus puissants.
- Limiter les surfaces d’attaque et répondre rapidement aux incidents de sécurité.
- Maintenir la conformité (RGPD, PCI‑DSS) grâce à une traçabilité des logs et à la chiffrement des données sensibles.
Adoptez dès aujourd’hui une culture d’optimisation proactive, où chaque modification de configuration passe par un audit de performance et une vérification d’impact sécurité. Ainsi, votre instance Dolibarr restera rapide, fiable et résiliente face aux menaces émergentes.
À votre succès !
Sources : Dolibarr Documentation 22.0, OWASP Testing Guide 4.6, “Hardening Linux Servers” (NIST SP 800‑123), best‑practice NGINX & PHP‑FPM (2024).