Version 1.0 – Novembre 2025
1. Introduction
Dolibarr est une solution ERP / CRM open‑source très populaire pour les PME et les associations. Sa souplesse d’extension (plugins, modules) en fait un outil idéal pour gérer finance, stocks, ventes, contacts, etc.
Cependant, lorsqu’il s’agit d’obtenir des indicateurs de pilotage (BI, reporting, prévisions) ou de concilier plusieurs sources de données (ERP, CRM, plateformes externes), la simple interface web de Dolibarr montre rapidement ses limites.
C’est là qu’un processus ETL (Extract‑Transform‑Load) bien pensé permet de :
- extraire les données de façon fiable,
- les transformer pour les adapter aux besoins analytiques,
- les charger dans un entrepôt de données ou un outil de visualisation.
Cet article décrit comment diagnostiquer l’état actuel de Dolibarr, concevoir une roadmap ETL adaptée, puis mettre en œuvre les étapes clés pour obtenir une visibilité optimale et une prise de décision plus agile.
2. Diagnostic de l’environnement Dolibarr
| Axe | Points de contrôle | Question clé | Impact si non résolu |
|---|---|---|---|
| Architecture technique | Version (cloud‑only, on‑prem, hybride) Base de données (MySQL, PostgreSQL, SQLite) Hébergement (dedicated server, VPS, Docker) |
La base de données est‑elle accessible en lecture seule ? | Impossible d’extraire les données sans impacts sur la production. |
| Modélisation des données | Schéma des tables (ex. tribal, products, invoices, c_departements) Clé primaires / étrangères bien définies |
Existe‑t‑il des tables “orphan” ou des doublons de champs ? | Risque de perte d’information ou d’erreurs de transformation. |
| Gestion des extensions | Plugins installés, version, état (activé/désactivé) | Tous les plugins sont‑ils compatibles avec la version courante ? | Bugs d’incompatibilité pouvant interrompre les flux de données. |
| Performance | Temps de réponse (consultes lourdes) Indexation des champs clés |
Les requêtes sont‑elles optimisées (indices, partitions) ? | Extraction lente → pipelines ETL inefficaces ou timeout. |
| Sécurité & conformité | Accès réseau (firewall), chiffrement SSL, contrôle d’accès | Les droits de lecture en base sont‑ils limités au strict nécessaire ? | Risque de fuite de données sensibles lors du rejet vers l’ETL. |
| Qualité des données | Taux de nulls, incohérences (ex. dates mal formatées), doublons | Existe‑t‑il des règles métier non respectées (ex. price > 0, stock ≥ 0) ? |
Transformations qui corrigent ou rejettent des lignes invalides. |
| Processus de mise à jour | Procédures de backup, restauration, mise à jour du core et des plugins | Les backups sont‑ils automatisés et testés ? | Risque de perte de données lors d’une migration ETL. |
2.1. Méthodologie de diagnostic
-
Cartographie rapide
- Utiliser
SHOW TABLES;ou le module Administration → Outils → Export pour identifier les tables clés. - Exporter le schéma (
mysqldump --no-data) pour un audit du typage.
- Utiliser
-
Audit de qualité
- Script Python/Pandas ou SQL (
SELECT COUNT(*) FROM <table> WHERE <col> IS NULL) pour mesurer les nulls. - Exemple de requête de validation des dates :
SELECT COUNT(*) FROM invoices
WHERE invoice_date NOT REGEXP '^[0-9]{4}-[0-9]{2}-[0-9]{2}$';
- Script Python/Pandas ou SQL (
-
Analyse de performance
- Activer le slow query log de MySQL (ou équivalent) pendant 48 h.
- Identifier les requêtes > 500 ms et analyser les plans (
EXPLAIN EXTENDED).
-
Inventaire des plugins
- Lister les modules actifs, leurs dépendances et le emplacement de leurs tables/évènements.
- Vérifier que les événements déclenchés (ex. “order.created”) sont documentés pour un event‑driven extraction.
- Validation sécurité
- Tester avec
nmapouSQLMap(en environnement de test uniquement) pour s’assurer qu’il n’y a pas de ports ouverts non nécessaires. - Vérifier les droits MySQL :
SELECT User, Host FROM mysql.user;
- Tester avec
3. Principes de base d’un processus ETL pour Dolibarr
| Étape | Description | Outils typiques |
|---|---|---|
| Extract | Extraction des données de Dolibarr (tables, API, eventos) | – Scripts SQL (SELECT) – API REST de Dolibarr (v9 +) – Connecteurs ODBC/JDBC – CDC (Change Data Capture) via Debezium |
| Transform | Nettoyage, agrégation, enrichissement, joindre plusieurs tables, calculs métiers | – dbt (data build tool) – Apache Spark / PySpark – Pandas (Python) – Talend Data Preparation |
| Load | Chargement dans le système cible (entreposage, data‑lake, BI) | – PostgreSQL / Snowflake / BigQuery – Tableau, PowerBI, Looker – Flat files (Parquet/Avro) pour Data Lake |
3.1. Choisir le mode d’extraction
| Mode | Avantages | Inconvénients | Quand le privilégier |
|---|---|---|---|
| Direct DB access | Simple, temps réel, pas de dépendance aux plugins | Accès direct à la base → besoin de permission | Environnements on‑prem où le serveur est stable et les droits sont clairement définis. |
| API REST (v9+) | Séparation claire, possibilités de pagination, authentification OAuth | Nécessite activation du serveur API et gestion des quotas | Cloud‑first ou Dockerised où l’accès réseau direct à la DB n’est pas recommandé. |
| Event Bus (Dolibarr Event Hooks) | Extraction incrémentale, faible charge | Dépend du hook installé et de la mise à jour du plugin | Scénarios nécessitant realtime (ex. suivi des stocks) et où l’on veut limiter le volume de data transféré. |
Best Practice : Combinez API + CDC. L’API permet de récupérer les nouvelles entités (ex.
customers), tandis que CDC capture les changements en temps réel sur les tables critiques (invoices,products).
4. Roadmap ETL – 6 étapes clés
Étape 1 – Définir les Objectifs Métriques
| KPI | Source Dolibarr | Fréquence | Destination analytique |
|---|---|---|---|
| CA mensuel par catégorie | invoices + products |
quotidiens | Tableau de bord finance |
| Rotation des stocks | products, stock, invoices |
heures | Optimisation des réapprovisionnements |
| Taux de conversion leads → clients | cicd (contacts) + invoices |
hebdomadaires | Campagnes marketing ROI |
| Temps moyen de traitement d’une commande | orders, invoicing |
en temps réel | SLA operations |
Livrable : Document de spécifications fonctionnelles (FS) incluant les maps de tables, les règles de transformation et les fréquences de rafraîchissement.
Étape 2 – Choisir l’architecture cible
| Architecture | Cas d’usage | Points forts | Points faibles |
|---|---|---|---|
| Data Warehouse (PostgreSQL dédié) | Reporting structuré, requêtes complexes | ACID, performance OLAP | Coût de licences (si commercial) |
| Data Lake (Minio + S3 + Delta Lake) | Stockage brut, évolutif, data‑science | Coût minime, flexibilité | Nécessite gouvernance des métadonnées |
| Hybrid OLTP/OLAP (PostgreSQL + materialized views) | BI temps réel + historique | Simplicité | Scalabilité limitée à plusieurs TB |
| Cloud Data Platform (Snowflake, BigQuery) | Scale‑out, multi‑team | Serverless, zéro admin | Coût variable, dépendance vendor |
Recommandation 2025 : Hybrid avec PostgreSQL comme entrepôt + Materialized Views pour les rapports les plus lourds, complété par un lake sur MinIO pour l’archivage des logs d’évènements.
Étape 3 – Construire les Pipelines d’Extraction
| Pipeline | Méthode | Exemple de code (Python + SQLAlchemy) |
|---|---|---|
| Full Load (catalogue produits) | SELECT * FROM products (ou appel API /products) |
python\nengine = create_engine("postgresql+psycopg2://user:pwd@host/db")\ndf = pd.read_sql("SELECT id, label, price, stock FROM products", engine)\n |
| Incremental Load (invoices) | CDC via Debezium sur la log invoices (timestamp updated_at) |
sql\nSELECT id, updated_at FROM invoices WHERE updated_at > :last_extraction;\n |
| Real‑time Event (order created) | Activation du plugin Event Hook → webhook → queue (Kafka) | Utiliser FastAPI pour expose /webhook/orders et pousser dans Kafka topic order_events. |
Astuce : Utiliser des paramètres de versionnage (ex.
:last_extraction) pour éviter le ré‑lecture de lignes déjà traitées.
Étape 4 – Élaborer les Transformations
| Transformation | Exemple métier | Implémentation (dbt) |
|---|---|---|
| Normaliser les devises (EUR, GBP, USD) | Convertir toutes les price en EUR |
sql\nSELECT id, price * CASE currency WHEN 'GBP' THEN 1.15 WHEN 'USD' THEN 1.07 ELSE 1 END AS price_eur FROM stg_products;\n |
| Calculer le taux de rotation | (stock_initial - stock_final) / lead_time |
sql\nWITH stock_delta AS (\n SELECT product_id, SUM(stock_in) - SUM(stock_out) AS delta\n FROM stock_log\n GROUP BY product_id\n)\nSELECT p.id, p.label, (p.stock - stock.delta) / NULLIF(p.lead_time,0) AS rotation_rate\nFROM products p LEFT JOIN stock_delta ON p.id = stock_delta.product_id;\n |
| Enrichir les clients | Ajouter le segment (B2C/B2B) via règles de scoring | Utilisation d’un model de scoring (logistic regression) stocké dans un modèle dbt (via ref('client_scoring')). |
Bonnes pratiques :
- Staging : tables temporaires (
stg_*) pour chaque source. - Tests dbt :
unique,not_null,relationshipsafin d’assurer la qualité dès le pipeline. - Documentation :
dbt docs generate→ intégrer dans le portail interne.
Étape 5 – Déployer le chargement (Load)
| Destination | Méthode de chargement | Fréquence |
|---|---|---|
| PostgreSQL (entrepôt) | INSERT ... ON CONFLICT (id) DO UPDATE SET ... (UPSERT) |
Toutes les 15 min (incremental) |
| Parquet / Delta Lake (data lake) | COPY INTO lake/table FROM staging (Spark) |
Hebdomadaire (batch complet) |
| BI (Looker/PowerBI) | Direct Query via connecteur PostgreSQL | Temps réel (cache Looker) |
| Data Science | Export CSV/Parquet vers Jupyter / Databricks | Mensuel / à la demande |
Sécurité : Utiliser TLS pour les connexions PostgreSQL et IAM / Service Accounts pour les accès S3/MinIO.
Étape 6 – Mise en place du monitoring & gouvernance
| KPI de suivi ETL | Outils | Action corrective |
|---|---|---|
| Latence d’extraction | Prometheus + Grafana (temps de requête) | Ajouter des indexes ou ré‑architecturer le pipeline |
| Taux d’erreur (rows rejected) | dbt --vars + logs |
Implémenter un schema validation supplémentaire |
| Volume de données chargé | CloudWatch / pg_stat_user_tables | Ajuster le scaling des workers |
| Frais de coût cloud | AWS Cost Explorer / GCP Billing | Rightsizing des instances Spark/EMR |
Governance : Créer une Data Stewardship Board (responsable BI, devOps, compliance) avec un cadence de revue mensuelle des métriques ETL et des changements de modèle.
5. Plan de mise en œuvre détaillé (timeline – 12 semaines)
| Semaine | Activité | Livrable |
|---|---|---|
| 1‑2 | Audit complet de Dolibarr (sections 2) | Rapport d’audit + matrice de dépendances |
| 3 | Définition des KPI et validation avec les parties prenantes | Document de spécifications fonctionnelles |
| 4‑5 | Provisioning de l’infrastructure (DB cible, lake, CI/CD) | Environnement de test prêt |
| 6 | Mise en place du mode extraction (API + CDC) | Connecteurs fonctionnels, scripts d’extraction |
| 7‑8 | Développement des transformations (dbt models) | Modèles dbt versionnés, tests unitaires |
| 9 | Chargement initial et validation de la cohérence (row‑count, checksums) | Rapport de validation post‑load |
| 10 | Construction du dashboard BI (ex. PowerBI) | Dashboard pilotage (CA, stocks, conversion) |
| 11 | Monitoring & alerting (Prometheus/Grafana) | Playbooks d’incident |
| 12 | Go‑live en production + formation des équipes | Documentation finale, formation utilisateurs |
Ressources recommandées :
- Chef de projet : 0,5 FTE (business analyst)
- Data Engineer : 1 FTE (SQL + Python/Scala)
- DevOps : 0,3 FTE (CI/CD, monitoring)
- Consultant BI : 0,5 FTE (visualisation)
6. Bonnes pratiques spécifiques à Dolibarr
-
Utiliser les “hooks” natifs –Depuis Dolibarr 9, on peut enregistrer des action callbacks (ex.
order.created). Exploiter ces hooks pour publier un message sur RabbitMQ et consommer dans le pipeline d’extraction sans toucher à la base de données. -
Limiter les jointures – Dolibarr stocke souvent des données redondantes (ex.
invoice_lines→product_id). Privilégier des vues matérialisées plutôt que des jointures lourdes en transformation. -
Versionner les scripts – Placés sous Git avec un tag
dolibarr-etl-vX.Y. Chaque mise à jour du core de Dolibarr doit entraîner une revue des modèles dbt (ex. changement de champprice) . -
Gestion des traductions – Les champs texte (
label,note) sont souvent en plusieurs langues. Normaliser en UTF‑8 et appliquer un language‑filter pour les dashboards ciblés. - Sécuriser les exports – Ne jamais exporter de données sensibles (ex. numéros de carte bancaire) via des scripts non‑chiffés. Utiliser PGP ou AWS KMS pour chiffrer les fichiers
.csvavant leur dépôt dans le lake.
7. Exemple de tableau de bord BI (PowerBI) issu de l’ETL
| Visualisation | Source | Maintenance |
|---|---|---|
| CA mensuel par catégorie | stg_invoices → agrégation SUM(price) GROUP BY category, month |
Refresh 15 min (Direct Query) |
| Rotation des stocks (Heatmap) | stg_stock_log → calcul du delta hebdomadaire |
Refresh 1 h |
| Taux de conversion leads → clients | cicd_contacts + invoices |
Fresque 30 min |
| SLA de traitement des commandes | orders + timestamps created_at / shipped_at |
Temps réel via PowerBI streaming dataset |
Chaque visuel inclut une alerte dynamique (ex. couleur rouge si le CA du mois dépasse –5 % du budget) grâce à des règles Conditional Formatting construite via DAX.
8. Conclusion
Diagnostiquer Dolibarr est la première étape indispensable pour mettre en place un processus ETL robuste. En suivant la méthodologie décrite :
- Cartographier les tables, les performances et la qualité des données.
- Choisir le mode d’extraction le plus adapté (API + CDC).
- Construire une chaîne de transformation (dbt, Python) centrée sur les KPI métier.
- Déployer le chargement dans un entrepôt ou un lake adapté.
- Mettre en place le monitoring, la gouvernance et les alertes.
Vous obtenez ainsi :
- Une visibilité temps réel sur vos indicateurs clés.
- Une fiabilité des flux de données (reprise automatique en cas d’erreur).
- Une flexibilité pour ajouter de nouveaux indicateurs ou sources sans refonte majeure.
Le ETL Roadmap présenté, découpé en 6 étapes clairement définies et accompagnée d’un planning détaillé, permet de passer d’une visibilité limitée à une gouvernance data complète capable de soutenir la stratégie de croissance de votre organisation.
À retenir :
“Un bon ETL n’est pas seulement technique ; il est avant tout aligné avec la façon dont votre métier consomme l’information.”
Pour toute question détaillée sur la mise en place d’un connecteur spécifique (ex. Debezium sur MySQL) ou la configuration d’un job dbt, n’hésitez pas à nous le préciser !