Architecture Dolibarr : performance pour mieux piloter

Comment concevoir, configurer et tuner une instance Dolibarr qui supporte la croissance de votre activité tout en offrant un pilotage fluide.

1. Introduction : pourquoi la performance compte dans Dolibarr

Dolibarr est un ERP/CRM open‑source très modulable, mais comme tout logiciel, ses temps de réponse dépendent de plusieurs leviers : architecture technique, traitement des données, configuration serveur et pratiques d’exploitation.
Une mauvaise configuration peut entraîner des ralentissements lors de la facturation, de la gestion des stocks ou de la production de rapports—des processus qui sont au cœur du pilotage opérationnel.

Cet article décortique les bonnes pratiques d’architecture pour maximiser les performances de Dolibarr, afin de garantir :

  • une réactivité instantanée même avec des volumes élevés,

  • une scalabilité adaptée aux PME comme aux grandes entreprises,

  • une visibilité claire sur les indicateurs clés (KPIs) du système.

2. Principes d’architecture de base

Niveau Description Impact sur la performance
1️⃣ Front‑end (Web) Navigateur + assets (CSS/JS) servis par le serveur web (Apache/Nginx). Réduction de la latence grâce à la mise en cache et à la compression (gzip/ Brotli).
2️⃣ Application PHP (Dolibarr) exécuté via FastCGI (php‑fpm) ou mod_php. Contraste avec le modèle mod_php : meilleure isolation et scalabilité avec php‑fpm.
3️⃣ Base de données MySQL / MariaDB / PostgreSQL. Optimisation des index, réglage du buffer pool, utilisation de réplication si besoin.
4️⃣ Stockage Fichiers (PDF, images, pièces jointes) stockés sur disque ou sur objet storage (S3, Ceph). Découplage du serveur applicatif quand on utilise un NFS ou un bucket dédié.
5️⃣ Serveur de tâches asynchrones (optionnel) Queues (RabbitMQ, Redis) ou cron jobs gérés séparément. Découpage des traitements lourds (envois d’emails, génération de rapports).

Bonne pratique : séparer les rôles (Web, API, Worker) dans des containers Docker distincts ou des VM dédiées. Cette isolation rend chaque composant plus facilement monitorable et extensible.

3. Choix du moteur de base de données et optimisation

Option Avantages Considérations
MariaDB 10.6+ Compatibilité avec MySQL, amélioration des performances avec le moteur Aria et InnoDB Buffer Pool dynamique. Nécessite un réglage du innodb_buffer_pool_size (≈ 50 % de la RAM serveur).
PostgreSQL 15 Gestion avancée des transactions, réplication logique, support natif du JSON. Configuration du shared_buffers et du work_mem pour les requêtes complexes.
SQLite Ultra‑légère, idéal pour les tests ou les petits déploiements embarqués. Pas de scalabilité multi‑utilisateur ni de verrous avancés.

3.1. Indexation ciblée

  • palm_search (champ plein texte) : précompute les index FULLTEXT sur les colonnes de recherche (designation, label, reference).

  • *`fk_` : assurez‑vous que chaque clé étrangère possède un index ; sinon les requêtes de jointure sont O(N) au lieu de O(log N)**.

  • tickets, purchase, sales_invoice : indexez les colonnes de filtrage fréquentes (date, status, client_id).

Astuce : Utilisez EXPLAIN sur les requêtes les plus lentes (rapport de performance via le module Dolibarr > Maintenance > Performance) pour identifier les scans de tables non indexés.

3.2. Paramètres de connexion

Paramètre Valeur recommandée Impact
max_allowed_packet 256M ou 512M Accueil de gros BLOB (documents, factures PDF).
connect_timeout 10 s Réduit les blocages lors de pics de connexion.
table_open_cache 2000 Permet de garder plusieurs tables ouvertes en même temps.
query_cache_type = 0 (MySQL) Désactive le cache de requêtes obsolète sur MySQL 8+. Empêche les bugs liés aux invalidate.

4. Configuration du serveur d’application PHP

  1. Utiliser php‑fpm plutôt que mod_php.

    • Permet le scaling horizontal (plus de workers selon la charge).

    • Séparer le pool par version de PHP (ex. php-fpm-8.1, php-fpm-8.2) pour évoluer progressivement.

  2. Tuning du pool 

; /etc/php/8.2/fpm/pool.d/dolibarr.conf

pm = dynamic

pm.max_children = 25          ; nombre max de workers (ajustable)

pm.start_servers = 5

pm.min_spare_servers = 2

pm.max_spare_servers = 8

request_terminate_timeout = 300s

request_slowlog_timeout = 10s

  1. Cache d’opcode – Activez OPcache avec les paramètres suivants :

opcache.enable=1

opcache.memory_consumption=128

opcache.max_accumulated_files=10000

opcache.revalidate_freq=3

  1. Compression HTTP – Activez mod_deflate ou ngx_http_brotli_static pour les réponses JSON et HTML (réduction du trafic de ~30 %).

  2. Limitation de la taille des uploads – Ajustez upload_max_filesize et post_max_size à 50 M (ou le besoin métier) afin d’éviter les erreurs d’injection de fichiers volumineux.

5. Gestion des pièces jointes et des fichiers

  • Stockage hors‑serveur : stockez les fichiers dans un bucket S3 compatible (MinIO, Ceph).

    • Avantages : scalabilité quasi‑infini, délivrance directe via CDN, déchargement du serveur PHP.

    • Implémentation : activez le module Dolibarr > PDF > Use external storage et définissez les clés d’accès.

  • Cache de fichiers : créez un répertoire filerepos dédié sur un SSD dédié pour les téléchargements/exports.

    • Activez auto_prepend_file pour les scripts de traitement afin de réduire les appels file_get_contents() répétés.

  • Prévisualisation : si vous proposez des aperçus PDF/PNG, générez les miniatures en batch via un worker (ex. Symfony Messenger) et conservez-les en mémoire cache (sys_temp).

6. Traitement asynchrone : éviter le blocage du user‑flow

Action Méthode Exemple d’implémentation
Envoi d’emails de factures Queue Asynchrone Utiliser RabbitMQ ou Redis Queue avec le module mailqueue.
Génération de rapports PDF massifs Cron dédié Programme dolibarr_cron.php lancé toutes les 5 min avec --quiet.
Import/export de gros lots de données Batch via CLI php cli.php -c import/2025/2025-03-21-articles.csv -n 500.

  • Bénéfice : Le temps de réponse de l’interface utilisateur reste < 2 s, même lorsqu’un lot de 10 000 lignes est traité en arrière‑plan.

7. Monitoring & alerting pour maintenir la performance

Outil Métrique clé Action d’alerte
Grafana + Prometheus php_fpm_up, mysql_global_status_Slow_queries, http_request_duration_seconds Email si Slow_queries > 10/min.
Zabbix Utilisation du disque I/O (iostat), latence réseau Redémarrage du worker + scaling automatique.
Dolibarr → Maintenance → Performance Temps de réponse des actions (index.php?main=...) Export CSV pour analyser les retours > 3 s.
PHP‑FPM Status idle processes, active processes Ajuster pm.max_children lorsqu’on approche 95 % d’occupation.

Bonnes pratiques : Centralisez les logs (syslog → Loki) et créez des dashboards KPIs spécifiques à chaque couche (Web, DB, Workers). Cela rend la détection précoce des anomalies possible avant qu’elles n’impactent les utilisateurs.

8. Exemple de mise en place d’une architecture « cloud‑native »

version: "3.8"

services:

  db:

    image: mariadb:10.11

    environment:

      MYSQL_ROOT_PASSWORD: secret

      MYSQL_DATABASE: dolibarr

      MYSQL_USER: dolibarr

      MYSQL_PASSWORD: dolibarr

    volumes:

      - mariadb-data:/var/lib/mysql

    command: --innodb_buffer_pool_size=2G --max_connections=400

    healthcheck:

      test: ["CMD", "mariadb-admin", "ping", "-h", "localhost"]

      interval: 30s

      timeout: 5s

      retries: 3
app:

    image: dolibarr/dolibarr:latest

    depends_on:

      db:

        condition: service_healthy

    ports:

      - "8080:80"

    environment:

      - APACHE_DOCUMENT_ROOT=/var/www/html/htdocs

      - PHP_FPM_CHILDREN=20

    volumes:

      - ./files:/var/www/html/files

      - ./custom:/var/www/html/custom

    restart: unless-stopped
worker:

    image: dolibarr/dolibarr:latest

    command: php cli.php -c worker

    depends_on:

      - db

      - app

    environment:

      - CRON=*/5 * * * * php cli.php -c cron

    volumes:

      - ./files:/var/www/html/files

    restart: unless-stopped
volumes:

  mariadb-data:

  • Scalabilité : Augmentez le nombre de réplicas du service app via docker-compose scale app=3.

  • Résilience : Le worker exécute les tâches asynchrones, évitant ainsi de bloquer le front‑end.

9. Checklist de performance (avant mise en production)

✅ Action
1 Vérifiez que chaque table possède les index recommandés (SHOW INDEX FROM <table>).
2 Paramétrez php-fpm avec un pm.max_children adéquat (synchronisé sur la RAM disponible).
3 Activez OPcache et testez le temps de réexécution d’un script après modification (opcache.revalidate_freq=0 pendant les tests).
4 Lancez le script php dolibarr/scripts/dolibarr_perf.php (script interne de Dolibarr) pour obtenir un rapport détaillé.
5 Simulez un pico de charge avec JMeter ou Locust : 200 requêtes concurrentes sur /index.php?main=home et mesurez p95 response time.
6 Comparez les temps de génération de rapports PDF (sans vs avec batch worker).
7 Activez la journalisation des requêtes lentes (log_slow_queries=ON) pendant 24 h.
8 Configurez un tableau de bord Grafana pour les métriques clés et validez les seuils d’alerte.
9 Documentez les paramètres my.cnf / php.ini et versionnez-les dans un dépôt Git.
10 Testez le restore d’une sauvegarde complète (DB + filerepos) sur un serveur de test.

10. Conclusion

La performance de Dolibarr n’est pas seulement une question de code, mais d’architecture holistique : du choix du SGBD à la gouvernance des workers, en passant par le dimensionnement du serveur d’application et la surveillance proactive. En suivant les bonnes pratiques présentées :

  • Vous obtenez un temps de réponse inférieur à 500 ms pour les actions critiques.

  • Vous bénéficiez d’une architecture évolutive capable de scaler horizontalement sans interruption de service.

  • Vous disposez d’un pilotage transparent grâce à des indicateurs clairs et à des alertes précoces.

En résumé, une architecture bien pensée transforma Dolibarr d’un simple outil de gestion en un véritable moteur de pilotage performant, capable de soutenir la croissance de votre entreprise tout en restant agile et fiable.

Prêt à passer à l’action ?
Commencez par auditer votre configuration actuelle avec la checklist ci‑dessus, puis implémentez les optimisations graduelles décrites. Vous verrez rapidement une nette amélioration du Taux de réponse et, surtout, un pilotage plus précis et plus rapide qui fera la différence pour vos équipes opérationnelles.

Article rédigé par l’équipe d’architecture open‑source, spécialisée dans les ERP légers et les solutions de gestion intégrée.

Publications similaires