Optimisation Dolibarr : personnalisation orienté performance

Dolibarr est un ERP/CRM open‑source très flexible, mais comme tout logiciel, il ne rend pleinement ses ressources que lorsqu’il est correctement configuré et adapté à votre contexte.
Cet article propose un guide complet pour personnaliser Dolibarr en mettant l’accent sur la performance. Nous aborderons les leviers les plus efficaces : architecture, configuration, requêtes, caches, extensions, scripts, déploiement et monitoring.

1. Choisir la bonne architecture d’hébergement

Option Points forts Points faibles recommmendations
Serveur dédié / VPS Full control, ressources réservées, possibilité d’install RDBMS dédié Coût, maintenance Idéal pour > 10 000 lignes transactionnelles ou trafic important.
Partage d’hébergement (mutualisé) Peu cher, installation simple Ressources partagées, I/O limité À éviter si le volume de transactions dépasse quelques centaines par jour.
Cloud (AWS, Azure, GCP) Elasticité, bandes passantes élevées, stockage objet Coûts variables, complexité de config réseau Utiliser un instance de type "compute optimisé CPU" + RDS dédié pour les bases.
Docker / Kubernetes Isolation, déploiement reproducible Overhead de management si non maîtrisé À envisager pour des environnements multi‑sites ou pour automatiser le scaling.

Bon à savoir : Dolibarr fonctionne parfaitement avec MariaDB/MySQL et PostgreSQL. Le choix du SGBD est déterminant pour les performances de l’optimisation.

2. Optimiser la base de données

2.1 Choisir et paramétrer le SGBD

Paramètre Valeur conseillée (MariaDB) Valeur conseillée (PostgreSQL) Impact
innodb_buffer_pool_size 60‑80 % de la RAM si seul DB serveur shared_buffers = 25‑30 % de RAM Accélère les scans de tables InnoDB / autovacuum less stress.
max_connections 151 (par défaut) → 300‑500 selon charge max_connections = 200‑400 Plus de connexions simultanées évite les files d’attente.
query_cache_type (MySQL) ON (mais à désactiver si version ≥ 8) N/A Désactiver le query cache si version MySQL 8+, il a tendance à créer des goulots d’étranglement.
work_mem (PostgreSQL) N/A 8‑16 Mo (par connexion) Augmente le traitement des jointures lourdes.
autovacuum — autovacuum_vacuum_scale_factor = 0.01 Réduit les blocages de tables pendant les gros vidages.

Tip : Utilisez le profilateur du SGBD (EXPLAIN, SHOW PROCESSLIST, performance_schema en MySQL ou pg_stat_statements en PostgreSQL) pour identifier les requêtes les plus coûteuses.

2.2 Indexation fine

  • Index composés sur les champs de filtre les plus fréquents (ex. client_id, status, date_create).

  • Index partiels (MySQL 8+ / PostgreSQL) pour les requêtes ponctuelles : 
    CREATE INDEX idx_invoice_status ON llx_element invoice(status) 
    
WHERE status='paid';

  • Ne pas sur‑indexer : chaque index supplémentaire ralentit les écritures. Limitez-en le nombre à ce qui est réellement utilisé dans les rapports et les écrans.

2.3 Optimiser les requêtes « gourmandes »

  • **Éviter les SELECT *** : ne récupérer que les champs demandés.

  • Limiter les JOIN inutiles avec LEFT JOIN quand vous n’avez besoin que de lignes principales.

  • Paginer les résultats (LIMIT … OFFSET … ou cursor en PostgreSQL) pour éviter de charger des milliers de lignes.

3. Ajuster la configuration Dolibarr (php.ini & .htaccess)

Directive Valeur recommandée Pourquoi
memory_limit 512 M – 2 G (selon volume) Évite les débordements lors d’imports massifs.
max_execution_time 120‑300 s Permet le traitement de longues batchs (ex. réconciliation comptable).
upload_max_filesize 200 M Nécessaire pour les pièces jointes lourdes (factures PDF).
post_max_size 250 M Alignement avec upload_max_filesize.
opcache.enable 1 Compile en mémoire les scripts PHP, réduit le temps d’interprétation.
upload_tmp_dir /tmp/dolibarr_upload (et créer le dossier) Empêche les failles de sécurité liées à des uploads malveillants.
session.gc_maxlifetime 1800 (30 min) Réduit la taille du répertoire de sessions, améliore le nettoyage.

Dolibarr spécifique : Dans le fichier conf/dolibar.conf.php, désactivez les modules inutiles (ex. module_eventpos, module_pointcloud). Un module désactivé ne charge pas ses classes, ce qui diminue la consommation mémoire et le temps d’inclusion.

4. Stratégie de caching

Niveau Méthode Avantages Mise en œuvre
PHP OPcache opcache.enable=1 + cache d’opcodes Réduction du temps de compilation Activer directement dans php.ini ou php.ini du pool FPM.
Cache HTTP Varnish / Nginx FastCGI Cache Cache des pagesigas (liste d’articles, historiques) Configurer fastcgi_cache_key "$scheme$request_method$host$request_uri"; invalider après actions admin.
Cache système Dolibarr Cache ($conf->global->cache_*) Stocke les résultats de recherche, les listes de contacts Dans conf/settings.php : $conf->global->cache_ttl = 3600; (1 h) – réinitialiser manuellement en cas de mise à jour.
Base de données Query Cache (MySQL) ou pg_stat_statements (PostgreSQL) Réduit les re‑exécutions de requêtes récurrentes Nécessite un monitor interne ou un outil externe.
Cache d’objets Redis / Memcached (à installer séparément) Stockage de sessions, files de verrou, ou des résultats de jointure lourde Utiliser la fonction dolibarr_set_cache_* du core (ex. $db->fetch_object($result, 0, 'cache')).

Bonne pratique : désactivez le cache lorsque vous effectuez des mises à jour majeures ($conf->global->cache_ttl = 0 puis réinitialisez à la valeur normale après).

5. Automatiser les tâches non‑critiques

Dolibarr possède plusieurs cron jobs :

  • cron.php (références de prix, promotions)

  • cron_clean.php (nettoyage des anciens fichiers, archivage)

  • cron_backup.php (copies de sauvegarde)

5.1 Planification optimale

Tâche Fréquence Méthode Astuce de performance
cron.php (Calcul de stocks, prix) Quotidien, à minuit php /chemin/dolibarr/cron.php Limiter le nombre d’itérations ($conf->cron->frequency = 86400;).
cron_clean.php Hebdomadaire php /chemin/dolibarr/cron_clean.php --delete-old-files Utiliser --delete-old-files avec --dry-run pour tester avant.
cron_backup.php Hebdomadaire php /chemin/dolibarr/cron_backup.php --compress Compresser les backups (--compress) et les envoyer sur stockage distant (S3).

5.2 Runner via systemd

[Unit]

Description=Dolibarr Cron Jobs

After=network.target
[Service]

Type=oneshot

ExecStart=/usr/bin/php /var/www/dolibarr/cron.php

User=www-data

Group=www-data
[Install]

WantedBy=multi-user.target

Le passage à un service systemd évite les multiples appels simultanés et permet de garantir que chaque job se termine avant le lancement du suivant.

6. Personnalisation du code (sans toucher au cœur)

6.1 Utiliser les hooks (event_*)

Dolibarr propose plus de 250 hooks (hook拦截) qui permettent d’intercepter des points clés :

  • hookHeader (chargement du template)

  • hookFormDocumentOpen (juste avant le traitement d’un formulaire)

  • hookDisplayTabContent (affichage d’un onglet)

Exemple : injecter un WHERE supplémentaire dans les recherche de factures pour filtrer par client uniquement lorsqu’on travaille sur un compte spécifique, évitant ainsi de charger tout le jeu de data inutilement. 

function dolibarr_hookDisplayTabContent($params) {

    if ($params->tab->id == 'Invoices') {

        $params->fields['filter_client'] = $_SESSION['user_token']; // Filtre dynamique

    }

    return $params;

}

6.2 Créer un module dédié léger

  • Module « Performance » : Regroupez les fonctions de reporting lourds dans un module séparé qui se charge uniquement quand il est demandé ($user->id==1 par ex.).

  • Paramétrisation : ajoutez des paramètres ($conf->myperf->enable_stats) pour désactiver les traitements lourds en production.

6.3 Utiliser la couche $db->... avec des Prepared statements

Dolibarr utilise déjà PDO, mais lorsqu’on ajoute des requêtes très spécifiques, assurez‑vous d’utiliser :

$sql = "SELECT id FROM llx_sales WHERE date_exp > ? AND status = ?";

$stmt = $db->prepare($sql);

$stmt->execute([$dateExp, 'paid']);

$ids = $stmt->fetchAll(PDO::FETCH_COLUMN);

  • Pourquoi ? Évite le parsing répété et limite le risque de concaténation SQL qui déclencherait des scans full‑table.

7. Prototyper et mesurer les gains

Outil Usage Mise en place
Google PageSpeed / WebPageTest Temps de réponse des pages frontales Capture avant/après des changements de cache ou de module.
php‑benchmark (ab) ou wrk Charge simultanée de requêtes GET/POST ab -n 500 -c 50 http://dolibarr.tld/index.php
MySQL/MariaDB Performance Schema ou pg_stat_statements Identifier les requêtes lentes Activer dans my.cnf (performance_schema=ON) ou postgresql.conf (track_counts=top).
Grafana + Prometheus Visualiser le débit DB, latence PHP-FPM Exporter les métriques via prometheus-dolibarr-exporter.
Xdebug Profiler Analyse détaillée du temps passé dans chaque fonction $ XDEBUG_PROFILE=1 php cron.php puis analyser le fichier via KCacheGrind.

Règle d’or : Mesurez avant et après chaque modification. Une amélioration de 10‑20 % de latence ou une réduction de 0,5 s du temps moyen de requête est souvent le fruit d’une petite optimisation indexée ou d’un cache activé.

8. Exemple concret : Réduire le temps de génération de facture PDF

  1. Problème : La génération du PDF d’une facture avec 300 lignes de facturation prend 8 s.

  2. Diagnostic (via Xdebug + performance_schema) →

    • 3 requêtes lourdes sur les tables llx_invoice_line, llx_categorie, llx_product.

    • Aucun index sur llx_invoice_line.status.

  3. Actions :

    • CREATE INDEX idx_invoice_line_status ON llx_invoice_line(status);

    • Ajouter SELECT ... FROM llx_invoice_line li INNER JOIN llx_product p ON p.rowid = li.fk_product WHERE li.fk_invoice = ?; avec un prepared statement.

    • Activer le template cache des PDF ($conf->global->pdf_caching = 1).

  4. Résultat : Le temps passe à 2,7 s (≈ 66 % de gain).

Ce cas montre comment un index ciblé combiné à un cache de rendu peut transformer un point de friction majeur.

9. Checklist rapide de performance Dolibarr

✅ Action
1 Héberger sur un serveur dédié/VPS avec I/O SSD.
2 Choisir MariaDB/PostgreSQL et ajuster innodb_buffer_pool_size / shared_buffers.
3 Supprimer les modules inutiles dans conf/dolibar.conf.php.
4 Activer OPcache + config php.ini (memory, upload, max_execution_time).
5 Créer des index sur les colonnes filtrées et join‑clés.
6 Désactiver le SELECT * dans les custom scripts.
7 Utiliser les hooks pour injecter des filtres sans charger des tables entières.
8 Implémenter un cache de niveau application ($conf->global->cache_ttl).
9 Configurer les Cron via systemd ou un scheduler dédié (pas de sleep entre chaque appel).
10 Mettre en place un monitoring (Grafana/Prometheus) et mesurer avant/après chaque modification.

10. Conclusion

Optimiser Dolibarr ne consiste pas seulement à « tirer le maximum de la machine », mais à adapter chaque couche (serveur, base, code, cache) au profil d’utilisation de votre entreprise. En suivant les principes décrits ci‑dessus :

  • Architecture adaptée,

  • Base de données correctement dimensionnée et indexée,

  • Configuration PHP fine‑tuned,

  • Caching multi‑niveau exploité,

  • Personnalisation par hooks et modules légers,

  • Mesure continue grâce à des outils de monitoring,

vous pouvez réduire de façon significative les temps de réponse, les charges serveur et les coûts d’infrastructure, tout en conservant la souplesse et la richesse fonctionnelle de Dolibarr.

Performance = (Code léger) + (Base bien configurée) + (Cache intelligent) + (Monitoring rigoureux.

Bonne optimisation ! 🚀

Publications similaires