Dolibarr en production : modules et bonnes pratiques orienté performance

Version 23.x – 2025

1. Introduction

Dolibarr est un ERP/CRM open‑source « tout‑en‑un » qui se veut simple à installer et à configurer.
Sa force réside dans sa modularité : chaque fonctionnalité (achat, vente, stocks, facturation, énergie, etc.) est proposée sous forme de module que l’on peut activer ou désactiver à la volée.

Dans un contexte production, la performance ne dépend pas seulement du code ; elle repose sur :

Axe Impact
Modularité Charger uniquement les modules réellement nécessaires évite des requêtes inutiles et allège le front‑office.
Configuration serveur PHP, MySQL/MariaDB, le serveur web et le garbage collector influencent les temps de réponse.
Cache & CDN Réduction du nombre de requêtes SQL et du temps de délivrance des assets statiques.
Scalabilité Architecture adaptée (single‑node, réplication, clustering) pour supporter la montée en charge.

Cet article passe en revue les modules critiques pour la performance, puis détaille les bonnes pratiques à implémenter avant, pendant et après le déploiement en production.

2. Les modules « gourmands » et comment les maîtriser

Module Rôle Pourquoi il peut impacter la performance Astuces d’optimisation
Orders / Invoices (Ventes) Gestion des devis, factures, commandes, paiements. Traitement de nombreuses lignes de produits, génération de PDF, calcul de taxes, envoi d’emails. • Limiter le nombre de lignes affichées (pagination).
• Désactiver la génération automatique de PDF pour les devis non soumis.
• Configurer le cron pour le calcul des taxes hors pic horaire.
Stocks Suivi des articles, emplacements, mouvements, seuils. Requêtes lourdes sur product, stock, product_price + déclencheurs de mise à jour du stock à chaque vente. • Activer le batch mode (exécution toutes les 5 min) plutôt que « real‑time ».
• Utiliser les index sur product_id, location_id.
• Désactiver la synchronisation multi‑entreprise si non requise.
Invoices / Payments (Clients / Fournisseurs) Création de factures récurrentes, prélèvements SEPA, paiements. Génération de racks de factures, envoi d’emails, notifications de paiement en temps réel. • Mettre en place un queue (RabbitMQ, Redis) pour les emails.
• Limiter le nombre d’emails par heure (rate‑limit).
Recurring Invoices / Subscriptions Facturation périodique (abonnements, maintenance). Boucle de création & envoi d’une facture chaque mois → potentiel de spam si mal configuré. • Planifier le job à 02 h du matin.
• Utiliser le mode test en pré‑production pour valider le volume.
Shopping Cart / Cart Rules Promotions, remises, coupons, packs. Calcul de remises à chaque ajout au panier → appels répétés aux fonctions PHP. • Activer le cache des règles (APCu) pour les règles statiques.
• Privilégier les règles simples (pourcentage vs montants complexes).
Project / Task Management Gestion de projets internes, temps passés. Création massive de tickets → impact DB si les tables d’activités ne sont pas indexées. • Créer index sur project_id, status.
• Limiter le nombre de champs affichés dans le tableau de bord.
HRM / Employee Management Suivi des salariés, congés, contrats. Fonctionnalités de rapports lourds (tableaux croisés). • Utiliser les rapports PDF seulement sur demande.
• Activer la compression des rapports (gzip).

Règle d’or : Ne chargez pas un module tant que vous n’en avez réellement besoin.
Dans la plupart des déploiements, les modules Supplier / Purchase, Bank, Time & Expense, Affiliate, Knowledge base, Emailing sont désactivés dès le départ.

3. Configuration serveur : les fondations de la performance

composant réglage recommandé (PHP 8.2) Pourquoi
PHP-FPM pm.max_children = 30 (ou pm.process_idle_timeout = 10s) Ajuster en fonction du nombre de cœurs et de la charge moyenne.
opcache.enable = 1
opcache.memory_consumption = 256
opcache.max_accelerated_files = 10000		 Cache byte‑code : indispensable pour éviter la recompilation des scripts.
realpath_cache_size = 4096K
realpath_cache_ttl = 3600		 Accélère la résolution des chemins de fichiers.
MySQL / MariaDB innodb_buffer_pool_size = 70% de la RAM
query_cache_type = OFF (déconseillé depuis 8.0, désactiver)
max_allowed_packet = 64M		 Optimise le pool de caches et décide de la taille maximale des paquets.
thread_cache_size = 10
table_open_cache = 2000		 Réduit le coût de création de nouvelles connexions.
Web server (NGINX) keepalive_timeout 75;
gzip on;
gzip_types text/css application/javascript image/svg+xml;		 Réduction du temps de connexion TCP et compression des assets.
Redis (cache) Utiliser Redis comme session store et bytecode cache (opcache → redis extension) Permet de partager l’état entre plusieurs workers PHP‑FPM.
File system Stocker le répertoire uploads/ et les PDF générés sur un volume SSD ou tmpfs (si peu d’écritures) Accélère l’accès aux fichiers temporaires.
Security Désactiver allow_url_fopen
expose_php = Off
open_basedir limité au répertoire Dolibarr		 Limite les vecteurs d’attaque et évite des surcharges inutiles.

Astuce : Créez un fichier php.ini.prod avec ces paramètres et utilisez php -i pour vérifier que les valeurs sont bien appliquées en production.

4. Bonnes pratiques orientées performance

4.1. Nettoyage et désactivation des modules inutiles

  1. Audit initial – Parcourir les _MODULES_ du répertoire core/modules pour identifier les modules réellement utilisés par l’entreprise. 2. Désactivation – Exécuter php bin/dolibarr.php --disable <module> ou via l’interface « Modules » → Désactiver.

  2. Suppression du code – Supprimer le dossier du module désactivé du répertoire htdocs/core/modules/<module>/ pour réduire les appels de __autoload.

4.2. Optimisation de la base de données | Action | Commande / Exemple | Impact |

|——–|——————-|——–|
| Indexation | ALTER TABLE llx_sales_entradas ADD INDEX idx_sales_date (date); | Accélère les filtres temporels (ex : factures du mois). |
| Partitionnement | ALTER TABLE llx_product_stock PARTITION BY RANGE (id_product) (PARTITION p0 VALUES LESS THAN (10000), PARTITION p1 VALUES LESS THAN (20000)); | Réduit le temps de scan pour les gros volumes (> 1 M d’articles). |
| Analyse régulière | OPTIMIZE TABLE llx_product; | Récupère l’espace fragmenté et met à jour les statistiques. |
| Nettoyage des tables temporaires | DELETE FROM llx_session WHERE timestamp < NOW() - INTERVAL 30 DAY; | Évite l’accumulation de sessions mortes qui alourdissent le cache. |
| Limitez les @ undef | Désactivez le slow query log : SET GLOBAL slow_query_log = 'ON'; | En production, un slow_query.log est indispensable pour repérer les requêtes qui dépassent 1 s. |

4.3. Cache et Filesystem

Cache Configuration Particularité
OPcache opcache.enable=1 opcache.memory_consumption=256 opcache.max_accelerated_files=10000 Faut-il tuner la opcache.file_update_check à 0 en production (pas de re‑vérification des fichiers).
APCu apc.enabled=1 apc.shm_segments=1 apc.ttl=3600 Cache d_variables PHP pour les calculs récurrents (ex : calcul des taxes).
Filesystem tmpfs sur /var/lib/dolibarr/files pour les fichiers temporaires Accélère la création de PDF ou la génération d’images.
Reverse proxy Nginx proxy_cache_path /var/cache/nginx/dolibarr levels=1:2 keys_zone=100m:10m max_size=1g inactive=60m use_temp_path=off; Cache des assets statiques (CSS/JS) pour les pages récurrentes.

4.4. Gestion des processus asynchrones

Processus Implémentation Pourquoi
Mail Queue via RabbitMQ ou Beanstalkd (ex : php queue.php --queue mail) Évite la latence du temps réel et empêche la surcharge du sendmail pendant les pics.
Facturation récurrente Planifier cron toutes les 5 min : */5 * * * * php /var/www/dolibarr/cron.php -f Réduit le nombre d’appels simultanés au serveur de facturation.
Synchronisation multi‑site Utiliser Redis Streams pour propager les changements d’inventaire entre plusieurs instances. Évite les verrous DB sur de grosses tables.

4.5. Monitoring et traçabilité

Outil Utilisation Métrique clé
Grafana + Prometheus Scrape les métriques PHP‑FPM (php_fpm_updates, php_fpm_active), MySQL (mysql_global_status) Latence des requêtes, taux d’erreurs 5xx.
New Relic / Instana (APM) Installe le APM agent sur le serveur PHP pour obtenir des traces de chaque requête HTTP. Temps moyen de réponse par endpoint (/index.php, /main.php).
Fail2Ban Bloquer les IPs génèrent des requêtes lourdes ou des tentatives de bruteforce. Réduction des logs d’erreurs 500.
Logs Dolibarr Activer debug:0 et log_level: 3 (warning). Rotater avec logrotate pour éviter la croissance infinie. Volume de logs, fréquence d’erreurs.

5. Stratégie de déploiement & mise à jour

  1. Environnement de pré‑prod

    • Clone complet du dépôt git avec le même plan de base de données.

    • Exécuter php bin/dolibarr.php --install et vérifier que tous les modules inutiles sont désactivés.

    • Réaliser un stress‑test (ex : ab -n 5000 -c 50 http://demo.local/menu.php) et analyser les réponses via k6 ou Locust.

  2. Versionnage & rollback – Utiliser Git tags pour chaque version stable (ex : v23.0.3).

    • En cas de problème, revenir rapidement à la version précédente avec git checkout tags/v22.5.

  3. CI/CD

    • Pipeline : lint PHP → tests unitaires (PHPUnit) → déploiement sur serveur de staging → déploiement automatisé en production via Ansible ou Terraform.

    • Inclure dans le pipeline une étape php bin/dolibarr.php --install --reset suivi d’une vérification de l’intégrité du cache (opcache_get_status). 4. Rollback de la base

    • Toujours prendre un snapshot complet (xtrabackup ou mysqldump --single-transaction).

    • Conserver les binary logs pour pouvoir restaurer jusqu’au point d’échec.

6. Exemple d’une architecture production optimisée

┌─────────────────────────────────────────────────────────────┐

│                         Load‑Balancer (NGINX)              │

│  ├─ Keepalive → 2 × php-fpm (Docker) → Redis Session Store  │

│  └─ Cache (static assets) → CDN (CloudFront)               │

└─────────────────────────────────────────────────────────────┘
│                         │

   ▼                         ▼

┌─────────────┐           ┌─────────────┐

│   PostgreSQL│           │   Redis     │

│ (Read‑Replica)│        │ (Cache +    │

│   (Read‑Only │          │  Queue)    │└─────────────┘           └─────────────┘
│   ▼

┌─────────────────────┐

│   MySQL Primary      │  Tables partitionnées,

│   (MariaDB 10.11)    │  indexés, buffer_pool > 2 GB

└─────────────────────┘

  • Frontend : CDN distribue css, js, images.

  • PHP‑FPM ⟶ OPcache + APCu ⟶ Redis pour les sessions et le queue.

  • Workers asynchrones (cron, queue) sont exécutés sur des containers séparés afin de ne pas saturer le pool web.

  • Monitoring : Grafana dashboards affichent les métriques en temps réel ; alertes envoyées via Opsgenie.

7. Checklist “Performance en production”

✅ Action
Modules Auditer, désactiver tout ce qui n’est pas utilisé.
Configuration PHP OPcache, APCu, realpath_cache, memory_limit ≥ 256 M.
DB Indexer les colonnes de jointure, activer le slow query log, surveiller les innodb_* variables.
Cache OPcache + APCu activés, Redis pour les sessions et le queue.
Web Gzip, Keepalive, HTTP/2, CDN, proxy_cache.
Async Jobs Queue (RabbitMQ/Beanstalk) pour les mails, planification de cron.php toutes les 5 min.
Monitoring Prometheus + Grafana + APM configurés, seuils d’alerte définis.
Backup Snapshots tous les jours + sauvegarde hors‑site, test de restauration mensuel.
Scaling Possibilité d’ajouter des replicas MySQL et des workers PHP‑FPM via Docker‑Compose/K8s.
Testing Load test (k6, ab) avant chaque mise en prod importante.
Documentation Script README.md décrivant chaque paramètre de tuning et les commandes de maintenance.

8. Conclusion

Dolibarr est une solution très souple, mais sa performance en production dépend avant tout d’une approche disciplinée :

  1. Ne pas surcharger l’instance avec des modules inutilisés.

  2. Tuner le serveur (PHP, MySQL, Web) en fonction du profil de charge réel.

  3. Externaliser les traitements asynchrones (mail, facturation récurrente) pour éviter les blocages en temps réel.

  4. Mettre en place un pipeline de monitoring & alerte pour détecter tôt les dérives de latence.

En appliquant les bonnes pratiques décrites ci‑dessus – déclaration explicite des modules, indexation ciblée, cache OPcache/Redis, usage de queues,以及 un monitoring continu – vous obtiendrez une plateforme Dolibarr capable de gérer des charges importantes tout en restant rapide et fiable pour les utilisateurs finaux.

Tip ultime : Le secret d’une Dolibarr ultra‑performante réside dans la règle du « moins c’est plus » : limitez le nombre de modules, optimisez les requêtes, et déplacez le travail lourd vers des canaux asynchrones.

Vous êtes prêt à mettre Dolibarr en production avec des performances qui rivalisent avec des ERP propriétaires ? 🎯

Ressources complémentaires

Par [Nom du Consultant DevOps] – spécialiste ERP open‑source, 2025.

Publications similaires