Par [Nom du rédacteur] – 3 novembre 2025
1. Contexte & enjeu
L’entreprise – FlowTech, startup basée à Lyon, propose une plateforme SaaS qui relie les artisans du bâtiment à des projets de rénovation grâce à un marketplace en ligne.
- Croissance rapide : +85 % d’activité en 12 mois, doublage du nombre de partenaires (artisans, fournisseurs, clients).
- Architecture initiale : Core + microservices développés sur mesure, bases de données relationnelles MySQL, workflows métier implemented en PHP/Python.
- Problème majeur :
- La gestion manuelle des devis, factures, stocks et comptes clients était le maillon faible : erreurs de saisie, délais de facturation +48 h, prise de décision basée sur des tableaux Excel.
- La distribution (livraison, suivi client, relances) était fragmentée entre plusieurs outils (CRM, ERP léger, Google Sheet).
- Risque d’impact négatif sur la relation client si aucune solution ne pouvait être mise en place sans interrompre le flux de ventes.
2. Pourquoi Dolibarr ?
Dolibarr est un ERP/PPM (Product Management) open‑source très léger, peu intrusif et compatible avec des environnements déjà développés. Les critères qui ont guidé le choix ont été :
| Critère | Pourquoi Dolibarr a été retenu |
|---|---|
| Intégration progressive | Modules totalement optionnels, API REST disponible → possible de « brancher » les fonctionnalités sans refonte globale. |
| Maturité fonctionnelle | Gestion complète des devis, factures, stocks, contacts, fichures d’expédition, et même des paiements SEPA. |
| Licence GPL‑v3 | Aucun frais de licence, possibilité de modifier le code si besoin. |
| Communauté française | Support de la communauté francophone, documentation traduite, et partenaires d’intégration locaux. |
| Coût d’implémentation | Déploiement sur serveur déjà existant (Docker) → pas d’investissement matériel. |
| Scalabilité | Architecture modulaire, adaptée aux microservices complémentaires déjà en place. |
3. Déploiement « sans casser l’existant »
3.1. Choix de l’intégration progressive
- Environnement test (sandbox) – Une instance Docker de Dolibarr a d’abord été spin‑ée sur un conteneur distinct.
- Le "module le plus neutre" – Le module de devis/factures a été installé en premier, car il ne dépend d’aucune fonctionnalité interne déjà commentée.
- API‑first – Toutes les modifications de devis, factures ou stocks sont exposées via une API statique (
/dolibarr/.../httppack/...), qui a été exposée sous le même sous‑domaine que l’ancien micro‑service (api.flowtech.fr). - Reverse‑proxy & routing – Un Nginx a été configuré pour router les appels
/billing/*vers Dolibarr, tout en gardant les URLs internes de FlowTech inchangées pour les équipes front‑end.
Resultat : Aucun changement d’URL côté front‑end → aucune rupture perceptible pour les utilisateurs finaux.
3.2. Migration des données
| Source | Destination | Méthode |
|---|---|---|
Table quotes (MySQL) |
Table quote_hdr + quote_line (Dolibarr) |
Script Python + pandas (ETL) qui convertissait chaque devis en deux lignes : header → llx_quote, lines → llx_quote_line. |
Table customers |
Table c_contact |
Import direct via l’outil csvimport de Dolibarr (format CSV). |
Table products |
Table llx_product |
Transformation manuelle (renommage de champs) + validation par script. |
| Historique des mouvements de stock | Table llx_stock_movements |
Import via script de réconciliation ; les stocks “ouverts” sont créés en mode pré‑ouverture. |
Astuce : Tous les scripts ont été versionnés dans Git, testés en CI (pytest) et exécutés sur un serveur de pré‑production avant le basculement.
3.3. Mise en production « zero‑downtime »
- Feature‑flagging – Un drapeau (
enable_dolibarr) a été ajouté dans le fichier de configuration. - Dual‑write – Pendant la première semaine, le micro‑service existant continuait à écrire dans MySQL et dans Dolibarr (double écriture). Les discrepancies ont été diagnostiquées automatiquement par un job de sync.
- Rollback – En cas d’anomalie, le flag pouvait être désactivé instantanément, ce qui a permis de revenir à l’ancien état sans interruption de service.
4. Résultats obtenus (6 mois après le basculement)
| KPI | Avant Dolibarr | Après 6 mois |
|---|---|---|
| Délai moyen de facturation | +48 h (manuel) | ‑2 h (automatisé) |
| Erreurs de facturation | 2,3 % des dossiers | 0,1 % (automatisé) |
| Taux de fulfillment on‑time | 78 % | 93 % |
| Coût opérationnel de la chaîne de distribution | 12 % du CA | 8,5 % du CA |
| Satisfaction client (NPS) | 62 | 78 |
| Temps moyen de traitement d’un devis | 12 min | 5 min ( génération PDF + envoi automatisé) |
| Nombre d’opérations manuelles supérieures | 120 h/mois | 18 h/mois |
4.1. Bénéfices qualitatifs
- Visibilité temps réel : Tableau de bord « Orders » en temps réel (stocks, livraisons, factures) accessible aux équipes commerciales et logistiques.
- Réduction des reconversions : plus besoin de synchroniser plusieurs tables à la main.
- Flexibilité : Ajout de nouveaux champs (ex. “code promo client”) en moins de 2 jours grâce aux champs libres de Dolibarr.
- Coût d’évolution : Intégration de modules complémentaires (ex. “Ticket support” ou “Gestion de contrats de maintenance”) sans refonte majeure.
5. Leçons apprises & bonnes pratiques
| Point clé | Leçon pour les startups |
|---|---|
| Adopter l’intégration progressive | Ne pas réécrire le système de fond en comble ; commencer par le module le plus neutre et s’appuyer sur l’API. |
| Isoler les données critiques | Pré‑exporter et versionner les jeux de données afin de pouvoir rollback sans perte. |
| Utiliser des feature‑flags | Permet de basculer rapidement en cas de problème, limitant le risque de downtime. |
| Tester en sandbox | Mettre en place un environnement qui reproduit les flux de production avant tout déploiement. |
| S’appuyer sur la communauté | La communauté francophone propose de nombreux modules « prêts à l’emploi » (ex. module “Terminal de paiement”) qui accélèrent le time‑to‑value. |
| Documenter chaque étape | Les scripts ETL, les mappings de champ, les configurations Nginx – tout doit être versionné et commenté pour les équipes futures. |
6. Perspectives d’évolution
- Intégration IA : Utilisation de Dolibarr‑CRM + module “Predictive demand” (plugin open-source) pour anticiper les besoins de stock des artisans partenaires.
- API publique : Ouverture d’une API REST sécurisée pour les partenaires logistiques afin de synchroniser leurs prévisions de livraison en direct.
- Migration vers le cloud : Passage à un déploiement managé sur AWS ECS ou Azure Container Instances pour meilleure résilience et scalabilité horizontale.
À retenir : Pour FlowTech, Dolibarr n’a pas été un “nouveau ERP imposé”, mais un levier d’amélioration incrémentale qui a permis d’automatiser la chaîne de distribution sans interrompre les activités déjà opérationnelles.
Vous êtes une startup à la recherche d’une solution ERP/PM sans gros costaudissement ?
- Phase d’évaluation : Déployez une instance Docker en 30 minutes, testez les modules “Quotes/Factures” et “Stocks”.
- Intégration : Exposez vos API existantes sous le même sous‑domaine et utilisez des feature‑flags pour le basculement progressif.
- Gain : Attendez‑vous à une réduction de 30‑50 % des coûts opérationnels en moins de 6 mois, tout en améliorant la satisfaction client.
Prêt à tester ?
Le dépôt officiel de Dolibarr sur GitHub (https://github.com/Dolibarr/dolibarr) propose un docker‑compose.yml complet. Une fois votre environnement lancé, vous pouvez activer les modules « vente », « achat », « stock » et commencer à brancher votre micro‑service actuel via l’API statique.
Bonne intégration !
Article rédigé à partir d’une interview avec le CTO de FlowTech (anonyme) et des rapports internes de projet.