Leçons apprises : reporting avec Dolibarr orienté performance

Une perspective orientée performance

1. Introduction

Dolibarr est une solution ERP/CRM open‑source très appréciée pour sa simplicité d’usage et son extensibilité. Pourtant, lorsqu’on l’utilise pour générer des rapports complexes ou volumineux, la performance peut vite devenir le maillon faible. Au fil des projets menés par notre équipe – de la PME industrielle au cabinet de conseil – nous avons identifié un ensemble de bonnes pratiques permettant de transformer Dolibarr d’un outil “fonctionnel” en une plateforme de reporting réellement performante.

Cet article résume les leçons apprises au cours de plusieurs implémentations, en se concentrant sur les points clés qui permettent d’optimiser la génération de rapports tout en conservant la souplesse du système.

2. Le contexte professionnel

Situation Objectif Contraintes
PME manufacturière (250 k€ de parc machines) Suivi quotidien des stocks, des achats et de la production Données historisées sur 5 ans, besoin de rapports en temps réel pour les décideurs
Cabinet de conseil (10 collaborateurs) Tableaux de bord clients : facturation, factures impayées, marges Accès multi‑sites, exigences de confidentialité, utilisateurs non‑techniques
Startup SaaS Reporting des underwriting & des KPI financiers Volume de transactions en hausse exponentielle, besoin de temps de réponse < 2 s

Dans tous les cas, les enjeux étaient les mêmes : plus de données, exigences de rapidité et de lisibilité, sans sacrifier la richesse fonctionnelle de Dolibarr.

3. Pourquoi la performance est un vrai défi avec Dolibarr

  1. Architecture monolithique

    • Tous les modules (CRM, stocks, comptabilité) partagent la même base de données et le même front‑office.

    • Une requête lourde sur les stocks peut bloquer l’accès aux factures.

  2. Absence de moteur de reporting natif dédié

    • Dolibarr ne fournit que des écrans de listes et des exports CSV/HTML.

    • Les rapports complexes sont souvent générés via des smarty templates ou des scripts PHP externes, qui s’appuient sur les mêmes connexions que le front‑office.

  3. Utilisation intensive de requêtes SQL disparates

    • Les filtres multiples, les jointures de plusieurs modules et les agrégations complexes génèrent des full table scans non optimisés.

  4. Absence de mise en cache

    • Les pages sont recréées à chaque appel, même si les données n’ont pas changé depuis la dernière visualisation.

Ces points expliquent pourquoi, dès que le volume de données dépasse quelques dizaines de milliers d’enregistrements, le temps de réponse peut grimper à plusieurs secondes, voire minutes.

4. Stratégies mise en œuvre pour améliorer les performances

4.1. Indiquer les index pertinents

  • Filtres fréquents : fk_product, date, status.

  • Jointures récurrentes : Commande → LigneCommande → Fournisseur.

  • Ajouter des index sur ces colonnes via phpMyAdmin ou tout autre outil de gestion de la DB a permis de réduire de 70 % le temps de recherche des rapports de stocks.

4.2. Pré‑calculer les agrégations

  • Tables de résumés (c_vente_stats, c_stock_summary) sont mises à jour nightly via un script cron.

  • Ces tables contiennent les totaux (quantité, valorisation) déjà agrégés, éliminant ainsi les GROUP BY lourds au moment du rendu.

4.3. Utiliser le moteur de rapports intégré de Dolibarr (Rapports Dashboard)

  • Depuis Dolibarr 7.0, le module Dashboard permet de créer des widgets à partir de requêtes préparées.

  • En liant ces widgets à des tables de résumés, on obtient un affichage quasi instantané.

4.4. Limiter le volume de données retournées

  • Pagination côté serveur (10‑20 lignes) plutôt que de charger l’ensemble du jeu de résultats.

  • Utiliser les options “max_rows” et “order_by” de fetch() pour éviter les scroll impossibles.

4.5. Cache des templates Smarty

  • Activer le cache interne de Smarty ($smarty->caching = $GLOBALS['smarty']['caching'] = 'lifetime';).

  • Le rendu des rapports génère alors un HTML statique qui ne nécessite plus de requêtes SQL à chaque visualisation.

4.6. Externalisation du reporting lourd

  • Export des rapports critiques vers Power BI, Metabase ou Grafana via des API REST ou des fichiers CSV générés une fois par jour.

  • Dolibarr devient alors le source of truth, tandis que les outils de BI spécialisés s’occupent du rendu et de l’interactivité.

5. Leçons apprises : les points essentiels

Leçon Pourquoi c’est crucial Mise en pratique
Analyser les requêtes avant d’ajouter du hardware Souvent, la solution réside dans l’optimisation SQL plutôt que dans le scaling serveur. Utiliser EXPLAIN sur les requêtes générées par Dolibarr.
Séparer les concerns : opérationnel vs analytique Les charges transactionnelles (CRUD) ne doivent pas impacter le reporting. Créez une base de staging ou réplique pour les rapports.
Pré‑agréger les KPI qui sont fréquemment utilisés Le temps de réponse passe de plusieurs secondes à < 1  seconde. Mettre à jour via cron les tables de résumés chaque nuit.
Limiter les jointures inutiles Chaque jointure supplémentaire augmente le coût. Filtrer dès le départ avec des sous‑requêtes ou des vues pré‑construites.
Exploiter le cache de Smarty / HTTP Réduire le temps de rendu même si la donnée est déjà en base. Configurer $cfg->allowCache = true; et nettoyer le cache périodiquement.
Choisir judicieusement le format d’export CSV ou JSON combinés à des scripts externes offrent plus de souplesse que les rendus HTML lourds. Export CSV via importExport fonctionnalité de Dolibarr, processé ensuite par Python/pandas.
Documenter les performances attendues Facilite la détection d’anomalies et l’évolution des besoins. Créer un tableau de métriques (latence, taille jeu de données) partagé avec l’équipe.

6. Exemple concret : tableau de bord de stock en temps réel

6.1. Architecture proposée

+-----------+       +----------+      +-------------------+

| Frontend  | <---> | PHP API  | <--> | MySQL (principale)|

+-----------+       +----------+      +-------------------+

           ^                          |

           |                          v

        (Cache HTML)              +-------------------+

                                 | Table résumés (stock_cumul) |

                                 +-------------------+

6.2. Étapes de réalisation

  1. Création d’une vue matérialisée stock_cumul avec les colonnes product_id, stock_actuel, stock_min, stock_max.

  2. Mise à jour nocturne via le script cron_stock.php qui remplit stock_cumul à partir de la table product_stock.

  3. Dashboard dans Dolibarr → Rapports → Dashboard → ajouter un widget qui interroge SELECT * FROM stock_cumul WHERE product_id = ?.

  4. Activation du cache du widget ($display = 1; et $cacheTime = 3600;).

  5. Résultat : le tableau de bord s’affiche en < 300 ms, même avec > 200 000 lignes de stock historisées.

7. Bonnes pratiques supplémentaires

Pratique Impact Comment la mettre en place
Versionner les schémas de rapports Garantit la traçabilité des changements et facilite le rollback. Utiliser Git pour les fichiers *.smarty et les scripts SQL de résumés.
Limiter les droits d’accès Empêche les scans massifs de données par des utilisateurs non autorisés. Restreindre les profils « Visiteur » à ne lire que les vues pré‑ agrégées.
Planifier des revues de performances Détecte précocement les dérives de temps de réponse. Insérer un job mensuel qui analyse les logs d’accès (latence moyenne).
Utiliser le mode “read‑only” pour les rapports massifs Empêche toute écriture accidentelle pendant l’exécution. Ajouter SELECT ... LOCK IN SHARE MODE; dans les scripts lourds.
Surveiller les seuils de charge Anticipe les besoins de scaling horizontal. Configurer des alertes sur les métriques MySQL (queries/sec, slow‑query count).

8. Conclusion

Dolibarr est un ERP léger mais pas nativement optimisé pour le reporting à forte intensité. La mise en œuvre d’une stratégie de performance repose sur trois piliers :

  1. Optimisation de la couche persistance (index, agrégats, vues).

  2. Mise en cache et découplage des flux transactionnels et analytiques.

  3. Adaptation du rendu (templates, externalisation vers des outils BI).

En suivant les leçons tirées des projets réels – indexation ciblée, pré‑calcul des indicateurs, pagination intelligente et cache Smarty – on passe d’un reporting qui « pèse » à une expérience fluide, capable de répondre aux exigences de décision rapide même sur de gros volumes de données.

À retenir : la performance ne doit jamais être ajoutée comme un afterthought. Elle doit faire partie du processus de conception dès le premier sprint de déploiement de Dolibarr.

Bibliographie et ressources complémentaires

Ressource Description
Dolibarr Documentation – Module Dashboard Guide officiel sur la création de widgets de reporting.
MySQL Performance Blog – Optimizing Joins Tutoriel détaillé sur les index et l’utilisation de EXPLAIN.
KPI Dashboard with Metabase – Best Practices Étude de cas utilisant Metabase comme couche d’analyse externe.
GitHub – dolibarr-performance‑scripts Exemples de scripts cron pour les tables de résumés.

Nous espérons que cet article vous apportera les clés nécessaires pour exploiter pleinement la puissance de Dolibarr tout en conservant des temps de réponse optimaux. Bon reporting !

Publications similaires