Dolibarr en production : cache et bonnes pratiques avec une approche sécurité

Version : 1.0 – 3 Novembre 2025

1. Introduction

Dolibarr est un ERP/CRM open‑source très répandu pour les PME et les associations. Sa simplicité d’installation et son architecture modulaire en font une solution idéale pour être mise en production rapidement.
Toutefois, comme tout logiciel serveur, la performance (cache, temps de réponse) et la sécurité (protection des données, durcissement de l’environnement) doivent être pensées dès le déploiement.

Cet article propose :

  1. Les mécanismes de cache les plus pertinents pour Dolibarr.

  2. Les bonnes pratiques d’administration en production.

  3. Une approche de sécurité « defense‑in‑depth » adaptée à Dolibarr.

2. Architecture de Déploiement Type

Couche Technologie recommandée Rôle
Web server Nginx (ou Apache) configuré en mode reverse‑proxy + PHP‑FPM Serve les requêtes, termine TLS, distribue les appels à PHP‑FPM.
Exécution PHP PHP 8.2 (ou 8.3) + PHP‑FPM Interprète le code Dolibarr.
Cache d’opcodes OPcache (extension PHP) Cache les scripts compilés.
Cache de données APCu (pour les sessions et variables temporaires) ou Redis (cache partagé multi‑instances) Accélère les requêtes PHP qui manipulent des tableaux.
Cache HTTP Varnish ou NGINX FastCGI Cache Met en cache les pages publiques (catalogue, listes, etc.).
Base de données MySQL 8 / MariaDB 10.6 ou PostgreSQL 15 Persistance des données.
Stockage de fichiers Répertoire dédié (files/), souvent en tmpfs ou sur un volume GFP (Growth‑FS) partagé Pièces jointes, fichiers générés.
Superviseur systemd, Supervisor, ou pm2 (pour les workers background) Assure la redémarrage automatique.
HTTPS Let’s Encrypt (certificat auto‑renouvelé) + HSTS Sécurisation du transport.

Schéma simplifié 

Client ── HTTPS ──► Nginx ──► PHP‑FPM ──► OPcache/APCu/Redis ──► MySQL/PostgreSQL

3. Mise en Place du Cache dans Dolibarr

3.1. Cache d’OPcache (PHP)

; php.ini

opcache.enable=1

opcache.enable_cli=0          ; on désactive sur la CLI

opcache.memory_consumption=128

opcache.max_accelerated_files=10000

opcache.validate_timestamps=1   ; 1 = vérifier la date des fichiers (production)

opcache.revalidate_freq=60      ; 60 s → rafraîchit le cache si un fichier change

opcache.fast_shutdown=1

Impact : compilation PHP évitée à chaque requête, réduction de 30‑50 % du temps de response.

3.2. Cache APCu (variables PHP)

Utilisé par défaut dans l’installation de plusieurs extensions Dolibarr (ex : dolibarr_cart) :

// Dans config.php ou un fichier d'init

$setup['SYS']['CACHE_TYPE'] = 'APCu';

$setup['SYS']['CACHE_APC_ENABLED'] = 1;

Bonne pratique : désactiver le cache de sessions stockées en fichiers (session.save_handler) au profit d’Redis ou APCu pour éviter les verrous PHP.

3.3. Cache HTTP (Varnish / NGINX FastCGI Cache)

3.3.1. Exemple de configuration NGINX FastCGI Cache

# /etc/nginx/conf.d/dolibarr-cache.conf

fastcgi_cache_path /var/cache/nginx/dolibarr levels=1:2 keys_zone=DOLI:100m inactive=60m use_temp_path=off;

fastcgi_cache_key $scheme$host$request_uri;
server {

    listen 443 ssl http2;

    server_name dolibarr.example.com;
ssl_certificate /etc/letsencrypt/live/dolibarr.example.com/fullchain.pem;

    ssl_certificate_key /etc/letsencrypt/live/dolibarr.example.com/privkey.pem;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
location / {

        try_files $uri $uri/ =404;

    }
location ~ \.php$ {

        fastcgi_pass unix:/run/php/php8.2-fpm.sock;

        fastcgi_index index.php;

        include fastcgi_params;

        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

        fastcgi_param HTTPS $https;
# Active le cache uniquement pour les méthodes GET

        if ($request_method !~ ^(GET|HEAD)$) {

            set $fastcgi_no_cache 1;

        }

        # Cache les pages publiques (ex : /index.php?main=...), exclure l’admin

        if ($request_uri ~* "main=List") {

            set $fastcgi_no_cache 0;

        }

        fastcgi_cache_bypass $fastcgi_no_cache;

        fastcgi_cache dolibarr_cache;

        fastcgi_cache_valid 200 10m;

        fastcgi_cache_use_stale error timeout updating;

    }

}

Notes

  • Exclusion : le dossier admin ne doit jamais être mis en cache (sécurité).

  • Headers : ajouter Cache-Control: private, no-store aux pages sensibles pour forcer le non‑cache des navigateurs.

3.3.2. Option Varnish (alternative)

vcl 4.0;

backend default {

    .host = "127.0.0.1";

    .port = "8080";

}

sub vcl_recv {

    if (req.url ~ "^/admin") {

        deny;

    }

}

sub vcl_backend_response {

    if (resp.status == 403) {

        set beresp.ttl = 0s;

        return (deliver);

    }

}

Bonus : Varnish permet de configurer des bans (ban req.url == "/index.php" ) pour rafraîchir rapidement les pages critiques.

3.4. Cache des pièces jointes

  • Stockage en dehors du webroot (/var/www/dolibarr/files/)

  • Serveur de fichiers dédié (ex : MinIO en mode “gateway”) ou simplement Nginx X-Accel-Redirect pour débloquer la lecture directement par le web server avec authentification. 

location /files/ {

    internal;

    alias /var/www/dolibarr/files/;

    # Authentification HTTP BASIC ou token URL signé

}

4. Bonnes Pratiques de Production

Domaine Action Pourquoi
Mise à jour Planifier des patches mensuels (Dolibarr + dépendances PHP) Réduire la surface d’attaque.
Versionnage Utiliser Git avec tag v7.5-production et CI/CD (GitLab CI) Garantir traçabilité et rollback rapide.
Configuration Centraliser les paramètres sensibles (db.conf, dolibarrcfg.php) via Ansible ou Terraform Éviter les erreurs manuelles.
Tests Suite d’intégration automatisée (PHPUnit, Behat) sur un environnement staging. Détecter les régressions fonctionnelles avant mise en production.
Monitoring – Prometheus + Grafana (latence, erreur 5xx)
– ELK ou Graylog (logs)		 Détection précoce d’anomalies.
Sauvegarde 1. DB : mysqldump --single-transaction (ou pg_dump).
2. Files : rsync vers un bucket S3 glacier.
3. Cron : quotidien + rétention 30 jours.		 Récupération en < 15 min.
Logs error_log PHP → syslog; access.log Nginx → rotation (logrotate). Traçabilité des accès & erreurs.
Gestion des sessions Utiliser Redis (session.save_handler = redis) avec TLS. Empêcher le vol de session.
Permissions – Répertoire files/ en 0750 (propriétaire du Web)
– config.php en 0640 (root uniquement)
– dolibarr.conf en 0600		 Limiter l’accès en écriture aux seules parties nécessaires.
Hardening PHP Désactiver allow_url_fopen, expose_php, disable_functions critiques (exec, shell_exec, proc_open). Réduire les vecteurs d’attaque.
Sécurité du serveur – Désactiver les comptes inutiles.
– Appliquer Fail2Ban pour bloquer les tentatives de brute‑force (ex: /admin.php).		 Bloquer les attaques de force brute.

5. Approche Sécurité «  Défense en profondeur »

5.1. Sécurisation du réseau

Action Détails
Segmentation Placer Dolibarr sur un VLAN dédié, uniquement accessible depuis le reverse‑proxy des applications métier.
Firewall Bloquer tout port autre que 80/443 vers le serveur. Autoriser seulement les IP du load‑balancer interne si vous en avez un.
VPN Autoriser les accès uniquement via un réseau VPN ou accès Zero‑Trust (ex: Cloudflare Access).

5.2. Protection des applications

Technique Mise en œuvre
TLS 1.3 & HSTS add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
Headers de sécurité Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN.
CSRF Protection Dolibarr possède déjà un token CSRF ($sess->protectontiplication) — assurez‑vous que la session est sécurisée (cookie Secure; HttpOnly).
Rate‑limiting Utiliser limit_req_zone (NGINX) ou mod_evasive (Apache) pour limiter les appels POST /admin.php.
Scanning de vulnérabilités Intégrer OWASP ZAP ou Nikto dans le pipeline CI/CD.
Gestion des droits – Permissions minimalistes sur les tables SQL (ex.: SELECT/INSERT uniquement pour l’utilisateur dédié).
– Revocation de FILE privilege si vous ne lisez pas de fichiers serveur.
Audits de configuration – Désactiver display_errors en production (php.ini: display_errors = Off).
– Activer log_errors et pointer vers un fichier dédié.

5.3. Hardening de la base de données

Paramètre Valeur recommandée
bind-address 127.0.0.1 (ou uniquement l’IP du serveur web)
max_connections Limité à la charge prévisionnelle (ex.: 150)
sql_mode STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION
innodb_file_per_table Activer pour économiser les IOPS
User Un compte dédié dolibarr_user avec SELECT,INSERT,UPDATE uniquement sur les bases nécessaires.

6. Checklist de Déploiement en Production

✅ Action
1 Compiler/installer PHP 8.2 avec OPcache, APCu, pdo_mysql/pdo_pgsql.
2 Configurer php.ini – désactiver expose_php, allow_url_fopen, disable_functions.
3 Stocker config.php en chmod 0600 et hors du répertoire web.
4 Créer le virtual host NGINX avec TLS (Let’s Encrypt) et activer HSTS.
5 Configurer FastCGI cache (ou Varnish) – exclure /admin, /index.php?main=User.
6 Activer OPcache + Ajuster memory_consumption selon le nombre de fichiers.
7 Installer Redis et configurer session.save_handler = redis.
8 Créer la base de données avec un user limité.
9 Rendre read‑only le répertoire files/ pour le serveur web (chmod 750).
10 Mettre en place logrotate pour les logs PHP/Nginx.
11 Planifier des backups incrémentaux (DB + files) et tester la restauration.
12 Configurer Prometheus + Grafana et créer un dashboard “Dolibarr KPI”.
13 Intégrer Fail2Ban avec une jail dolibarr.conf (bannir /admin.php répété).
14 Exécuter OWASP ZAP scan et corriger toutes les vulnérabilités critiques.
15 Documenter les procédures de rollback et de mise à jour.

7. Exemple de Script d’Initialisation (Ansible)

- name: Deploy Dolibarr – Production

  hosts: dolibarr_srv

  become: yes

  vars:

    dolibarr_version: "23.0.3"

    php_version: "8.2"

    db_name: "dolibarr"

    db_user: "dolibarr_user"

    db_pass: "{{ vault_db_pass }}"

  tasks:

    - name: Install required packages

      apt:

        name:

          - nginx

          - php-fpm

          - php-{{ php_version }}-opcache

          - php-{{ php_version }}-apcu

          - php-{{ php_version }}-redis

          - mariadb-client

          - certbot

        state: present
- name: Download Dolibarr source

      get_url:

        url: "https://github.com/Dolibarr/dolibarr/archive/refs/tags/v{{ dolibarr_version }}.tar.gz"

        dest: "/tmp/dolibar-{{ dolibarr_version }}.tar.gz"

        checksum: "sha256:{{ checksum_url }}"
- name: Extract & install

      unarchive:

        src: "/tmp/dolibar-{{ dolibarr_version }}.tar.gz"

        dest: /var/www/

        remote_src: yes

        creates: /var/www/dolibarr
- name: Set permissions

      file:

        path: "{{ item.path }}"

        owner: www-data

        group: www-data

        mode: "{{ item.mode }}"

      loop:

        - { path: /var/www/dolibarr, mode: "0755" }

        - { path: /var/www/dolibarr/files, mode: "0750" }
- name: Configure nginx site

      template:

        src: dolibarr.conf.j2

        dest: /etc/nginx/sites-available/dolibarr.conf

        owner: root

        group: root

        mode: "0644"

      notify: Reload nginx
- name: Enable PHP CLI cache settings

      lineinfile:

        path: /etc/php/{{ php_version }}/fpm/php.ini

        regexp: '^opcache\\.'

        line: 'opcache.enable=1'

        state: present

      notify: Restart php-fpm
- name: Create db and user

      mysql_db:

        name: "{{ db_name }}"

        state: present

      become_user: mysql

      vars:

        mysql_root_password: "{{ vault_mysql_root }}"

        mysql_user: "{{ db_user }}"

        mysql_password: "{{ db_pass }}"

        mysql_host: "localhost"
- name: Copy config.php (secure)

      template:

        src: config.php.j2

        dest: /var/www/dolibarr/htdocs/config.php

        owner: www-data

        group: www-data

        mode: "0600"

(Le template dolibarr.conf.j2 inclut le bloc de cache FastCGI présenté plus haut).

8. Conclusion

Dolibarr peut être exécuté en production de façon fiable, rapide et sécurisée dès lors que l’on met en place :

  1. Un stack de cache complet – OPcache + APCu + (optionnel) FastCGI Cache/Varnish – afin de réduire la latence et de protéger le serveur de charge.

  2. Des bonnes pratiques d’administration – versionnage, sauvegardes, monitorage, permissions strictes – pour garder le système stable sur le long terme.

  3. Une approche de sécurité en profondeur – TLS, headers de sécurité, segmentations réseau, contrôles d’accès à la base de données, et audit continu des vulnérabilités.

En suivant la checklist et les exemples de configuration présentés, vous disposerez d’un déploiement Dolibarr résilient, performant et conforme aux exigences de sécurité des environnements d’entreprise modernes.

Bon déploiement ! 🚀

Publications similaires