Dolibarr : comment réussir scalabilité pour passer à l’échelle

1. Introduction

Dolibarr est un ERP / CRM open‑source très populaire auprès des PME et des start‑ups grâce à sa simplicité d’usage, son extensibilité et son coût quasi nul. Mais, comme tout logiciel, il possède des limites lorsqu’il passe d’un environnement de test à 10 ou 100 sites, de quelques dizaines d’utilisateurs à plusieurs centaines.

Scalabilité : la capacité d’un système à augmenter ses performances, sa capacité de traitement et son stockage sans devoir revoir l’architecture de bout en bout.

Dans cet article, nous vous présentons :

  1. ✅ Les points de friction les plus courants dans Dolibarr. 2. 🔧 Les leviers techniques (code, configuration, infrastructure) pour y remédier.

  2. 📈 Les bonnes pratiques pour anticiper la croissance et préparer un scaling fonctionnel.

Objectif : passer de “ça marche” à “ça marche à 10 000 requêtes simultanées et plusieurs millions d’enregistrements sans faille”.

2. Les goulots d’étranglement typiques de Dolibarr

Domaine Symptomes d’échec Racine du problème
Base de données Temps de réponse > 2 s sur les listes de contacts, verrous bloquant les écritures simultanées Requêtes non‑indexées, tables MyISAM, absence de partitionnement
Cache Multiples requêtes identiques re‑exécutées, load CPU > 80 % Aucun cache (ou seulement le cache du navigateur)
Application Processus PHP “zombie”, dépassement du temps d’exécution, erreurs 500 Logique métier lourde (ex : génération de devis avec 10 000 lignes), appels externes synchrones
Stockage I/O disque élevé, latence sur les fichiers annexes (factures PDF, pièces jointes) SGBD sur disque mécanique, sauvegarde/archivage non optimisé
Infrastructure Saturation du CPU ou de la RAM sur le serveur web, temps d’attente réseau Manque de ressources (CPU, RAM), utilisation d’un serveur partagé sans scaling horizontal

Connaître ces goulots permet d’agir de façon ciblée.

— ## 3. Stratatégies de scalabilité : approche “là où ça compte le plus”

3.1 Optimisation du SGBD (MySQL / MariaDB)

Action Pourquoi Comment le mettre en œuvre
Choisir InnoDB plutôt que MyISAM Verrouillage transactionnel, réplication, crash‑safe Dans my.cnf : default-storage-engine=InnoDB
Indexer les colonnes de recherche fréquente (ex. fk_user, status, date) Accélère les SELECT … WHERE … ALTER TABLE llx_customer ADD INDEX idx_customer_status (status);
Partitionner les tables volumineuses (ex. journaux de paiement, factures) Limite les scans complets, facilite la maintenance ALTER TABLE llx_invoice PARTITION BY RANGE(id_facture) (…) ;
Activer le buffer pool (70‑80 % de la RAM si serveur dédié) Cache d’instructions et de données innodb_buffer_pool_size = 12G (exemple pour 16 GB RAM)
Activer le query cache (MySQL 5.6‑8.0, mais déconseillé) Historique des requêtes fréquentes, mais attention à la bricole Alternativement, privilégier Redis ou Memcached pour les résultats de requêtes

Exemple de configuration MySQL optimale pour Dolibarr (serveur dédié)

[mysqld]

max_connections = 500                # si > 200 utilisateurs simultanés

innodb_buffer_pool_size = 60% RAM    # 10 GB sur serveur 16 GB RAM

innodb_log_file_size = 2G

innodb_flush_method = O_DIRECT

table_open_cache = 2000

query_cache_type = 0                 # désactivé, on utilise Redis

3.2 Mise en place d’un cache externe

Dolibarr ne possède pas de cache natif intégré, mais il interagit avec les principaux résultats de requêtes :

Type de donnée Cache recommandé Implémentation rapide
Listes de contacts / produits Redis (hashes) Installez Redis, activez apc.enable_cli=1 et créez un petit module d’interfaçage (dolibarr-redis-cache)
Sessions PHP Redis Session (ou memcached) Ajoutez session.save_handler = redis dans php.ini
Résultats de requêtes lourdes OPcache + varnish (proxy HTTP) Configurez Varnish en front‑end, TTL 5 min sur /list/*

Cache « Redis » minimal

# installation sur Debian 12

apt-get install redis-server

systemctl enable redis-server

systemctl start redis-server
# config de php (apache)

echo "extension=redis.so" >> /etc/php/8.2/apache2/php.ini

echo "redis.host = 127.0.0.1" >> /etc/dolibarr/conf/conf.php

Astuce : Dolibarr permet d’ajouter des “hooks” PHP. Vous pouvez intercepter getTableSqlResult() pour placer les résultats dans Redis avant de les renvoyer au client.

3.3 Architecture “Front‑End + Back‑End” (Horizontal Scaling)

Niveau Rôle Technologies proposées
Load‑Balancer Répartition du trafic HTTP HAProxy, NGINX ou AWS ALB (mode L7)
Webservers (PHP‑FPM) Exécution du code Dolibarr 3–5 pods (Docker) scaldé via Kubernetes ou Docker Swarm
App‑Cache Cache d’objets stateless Redis ou Memcached partagé
DB Stockage persistant MySQL Galera Cluster ou MariaDB Cluster (multi‑master)
File storage Documents attachés (PDF, pièces jointes) MinIO (S3‑compatible) ou NFS partagé

Resultat : chaque appel HTTP peut atterrir sur n’importe quel serveur web, tant que le cache partagé (Redis) et la base de données sont synchronisés.

Exemple de déploiement Docker‑Compose minimal

version: "3.8"

services:

  db:

    image: mariadb:10.11

    environment:

      MYSQL_ROOT_PASSWORD: secret

      MYSQL_DATABASE: dolibarr

    volumes:

      - db_data:/var/lib/mysql

    command: --wsrep-cluster-name="galera" --wsrep-cluster-address="gcomm://node1,node2,node3"

  redis:

    image: redis:7-alpine

    volumes: ["redis_data:/data"]

  web:

    build: .

    environment:

      - REDIS_HOST=redis

      - DB_HOST=db

    depends_on: [db, redis]

    ports: ["80:80"]

    deploy:

      replicas: 3

      resources:

        limits:

          cpus: "0.75"

          memory: 1G
volumes:

  db_data:

  redis_data:

Note : Dans ce schéma, le code source de Dolibarr doit être monté en read‑only (read_only: true) afin d’éviter la duplication des écritures.

3.4 Optimisation du serveur web| Configuration | Impact |

|—————|——–|
| Nginx + PHP‑FPM via socket Unix | Réduction du nombre de connections TCP, latence plus faible |
| Gzip + Brotli | Diminution du volume de payload, meilleur temps de réponse |
| HTTP/2 + TLS 1.3 | Connexions multiples sans overhead supplémentaire |
| Compression des pages (output buffering) | Réduction du nombre de requêtes PHP ob_end_flush() |

Exemple Nginx (site-preset)

server {

    listen 80;

    server_name dolibarr.example.com;
root /var/www/dolibarr/htdocs;

    index index.php index.html;
location / {

        try_files $uri $uri/ /index.php?$args;

    }
location ~ \.php$ {

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

        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;

        include fastcgi_params;

    }
# Compression

    gzip on;

    gzip_types text/css application/javascript image/svg+xml;

    gzip_proxied any;

}

4. Guide pas à pas : Passer à la scalabilité étape par étape

Prérequis : votre instance Dolibarr fonctionne déjà sur un serveur unique (monolithique).

Étape 1 – Audit des requêtes lentes

# MySQLslow_query_log_file = /var/log/mysql/mysql-slow.log

long_query_time = 2

# Puis analyser avec ptquery (Percona Toolkit)

pt-query-digest /var/log/mysql/mysql-slow.log

Corrigez les index manquants, regroupez les SELECT identiques dans des fonctions réutilisables.

Étape 2 – Mise en place du cache Redis (5 jours)

  1. Installez Redis sur un serveur dédié ou comme conteneur.

  2. Installez le module PHP phpredis.

  3. Créez un fichier src/Kernels/Cache.php qui encapsule Redis::set/get. 4. Modifiez les modèles Product, Customer pour appeler ce cache avant chaque fetch() lourd.

Étape 3 – Séparation des services (10 jours)

Créez un fichier docker-compose.yml comme ci‑dessus, lancez docker compose up -d.

Testez le débit avec ab ou wrk :

wrk -t12 -c400 -d30s http://localhost/

Notez le Requests per second et la latence moyenne.

Étape 4 – Ajouter un Load‑Balancer externe (5 jours)

Déployez HAProxy en front de vos pods web.
Ajoutez un certificate TLS Let’s Encrypt via certbot.

Configurez un health‑check : GET /status.php → 200 OK.

Étape 5 – Passer à une base de données clusterisée (2 semaines)

Si vous avez > 200 000 enregistrements, migrez vers Galera Cluster.
Utilisez les scripts de migration mysqldump => mysqlimport sur chaque nœud.

Vérifiez la réplication avec :

SHOW GLOBAL STATUS LIKE 'wsrep_%';

Étape 6 – Automatisation du monitoring

  • Prometheus + Grafana : créez des exporters pour PHP‑FPM, Redis, MySQL.

  • Alertmanager : déclenche une alerte sur > 90 % CPU ou latence > 500 ms.

5. Bonnes pratiques « Scalabilité durable »

Pratique Raison Astuce d’implémentation
Déployer les mises à jour de façon immutable Réduit les dérives de configuration Utilisez Docker image tag: v9.0.2-production
Séparer les environnements (dev, stg, prod) Évite les impacts de charge réelle sur la prod Docker‑Compose distincts ou Helm charts K8s
Versionner les schémas de base Permet des roll‑backs rapides Flyway ou Liquibase pour appliquer les migrations
Documenter les limites de charge attendues Souvent oublié, pourtant indispensable Tableau de SLA : 100 req/s, 5 ms latence, 99,9 % uptime
Test pré‑production avec la même charge que prévue Découvre les bottlenecks réels Utilisez k6, JMeter avec un script réaliste (catalogue + facturation)
Plan de sauvegarde et réplication Réduit le risque de perte de données mysqldump --single-transaction --quick | gzip > backup.sql.gz + réplication Redis

6. Conclusion

Dolibarr n’est pas conçu d’emblée pour gérer « des millions de lignes », mais avec les bons leviers d’optimisation – indexes, cache externe, séparation des services et architecture de conteneurs – il est possible d’atteindre une scalabilité horizontale comparable à celle d’ERP professionnels.

Résumé des actions clés
1️⃣ Audit des requêtes lentes → index + requêtes optimisées.
2️⃣ Cache des listes de données via Redis.
3️⃣ Déploiement en conteneurs avec LB et DB clusterisée. > 4️⃣ Monitoring & alerting pour garder le contrôle en production.

En suivant ce plan en 6 étapes, vous passerez d’une petite installation « en local » à une plateforme robuste capable de supporter plusieurs dizaines de milliers d’utilisateurs simultanés et plusieurs millions d’enregistrements sans devoir changer d’architecture majeure.

Bonne scalabilité ! 🚀

À propos de l’auteur
Le contenu de cet article a été rédigé par [Nom], architecte cloud senior spécialisé en solutions ERP open‑source. Passé 10 ans dans la mise en production d’applications métier à forte intensité de transaction, il accompagne aujourd’hui les PME dans leur transformation digitale. Sources et lecture complémentaire

Vous avez trouvé cet article utile ?
Partagez-le avec votre communauté, posez vos questions en commentaire et n’hésitez pas à m’envoyer votre propre version de cet article pour le faire évoluer en fonction des retours d’expérience.

Merci de votre lecture, et à très vite pour vos projets de scalabilité !

Mot‑clé : scalabilité Dolibarr, architecture microservices, cache Redis, MySQL optimisation, Docker‑Compose, monitoring Prometheus

Publications similaires