Une mise en œuvre concrète, les obstacles franchis et les enseignements tirés pour automariser les processus métiers d’une PME via deux solutions open‑source complémentaires.
1. Contexte & objectifs
1.1. Le périmètre fonctionnel de Dolibarr
Dolibarr est une suite ERP/CRM destinée aux petites et moyennes entreprises. Chez Alpha‑Tech, société de distribution de pièces détachées, Dolibarr gère :
- Les devis, factures et bons de commande
- La facturation et le suivi des paiements
- La gestion des stocks et des approvisionnements
- Les relances clients / fournisseurs
Ces processus manuels ou semi‑manuels entraînaient :
- Des pertes de temps importantes (saisie double, validation multiple)
- Des risques d’erreurs comptables (duplication ou oubli de facture)
- Un manque de visibilité sur les indicateurs clés (taux de rotation des stocks, délais de facturation).
1.2. Le besoin de n8n
n8n est un moteur d’automatisation open‑source qui permet de créer des workflows (ou pipelines) en chaînant des applications via des “nodes”. Nous l’avons choisi pour :
- Sa flexibilité d’intégration (API REST, bases de données, services cloud).
- Ses capacités de traitement asynchrone et de gestion d’erreurs.
- Son modèle de licence (AGPL) qui garantit la maîtrise totale du code.
Objectif :
Déployer, en 30 jours, un connecteur n8n → Dolibarr qui :
- Synchronise automatiquement les devis et factures créés dans Dolibarr avec un CRM de suivi (HubSpot) et un outil de reporting (Google Sheets).
- Déclenche un webhook de notification Slack lorsqu’un paiement dépasse 48 h non réglé.
- Enrichit le catalogue de produits avec les prix d’achat provenant d’un ERP externe (ERPNext).
2. Planning détaillé – 30 jours
| Jour | Activité principale | Livrable / KPI |
|---|---|---|
| 1‑3 | Étude d’impact & définition des processus à automatiser (analyse métier) | Diagrammes BPMN, priorisation (3 flux critiques) |
| 4‑6 | Installation de l’infrastructure n8n (docker‑compose, reverse‑proxy, SSL) | Environnement de dev (Docker, Traefik) fonctionnel |
| 7‑10 | Développement du node “Dolibarr API” (requêtes GET/POST) | Connector open‑source publié sur GitHub (v0.1) |
| 11‑14 | Création du workflow « Facture → Slack » (node webhook → Slack) | Test de 5 scénarios, taux d’erreur < 2 % |
| 15‑18 | Intégration du node Google Sheets + logique de mise à jour incrémentale | Rapport automatisé quotidien, 100 % des lignes synchronisées |
| 19‑21 | Mise en place du node ERPNext (API Odoo/ERPNext) + mapping prix | Script de mise à jour nocturne (0 % d’échec) |
| 22‑24 | Tests d’automatisation en pré‑produ (sandbox) + audits sécurité | Rapport complet (OWASP checklist) |
| 25‑26 | Formation des équipes (1h de formation/leader) | 5 utilisateurs formés, manuel d’utilisation rédigé |
| 27‑28 | Passage en production (déploiement « blue‑green ») | Monitoring en temps réel, alertes configurées |
| 29‑30 | Bilan & documentation | Retour d’expérience final, feuille de route post‑déploiement |
3. Déploiement technique – Points forts
3.1. Architecture retenue
[Docker] ──> Traefik (reverse‑proxy, SSL) ──> n8n (container) ──> Dolibarr (API)
│
└─> DB (MariaDB) partagé
└─> Redis (cache, gestion des rates)- Docker assure la portabilité et la scalabilité.
- Traefik gère automatiquement les certificats Let’s Encrypt et les redirections.
- Redis sert à stocker les tokens d’authentification (OAuth2) et à éviter les appels multiples lors d’un même déclencheur.
3.2. Connector Dolibarr → n8n
Nous avons forké le node officiel n8n-nodes-dolibarr (maintenant disponible sous licence MIT). Les améliorations clés :
| Fonctionnalité | Implémentation |
|---|---|
| Pagination | Gestion transparente de la pagination d’API (max 1000 lignes par appel). |
| Batch operations | Endpoint /batch/create permettant l’insertion de 50 devis en une seule requête. |
| Webhook support | Ajout d’un endpoint /webhook pour déclencher des pipelines à la création ou validation d’une entité. |
| Gestion des erreurs | Retry exponentiel + fallback sur un dead‑letter queue (queue “failed‑tasks”). |
| Tests unitaires | 85 % de couverture avec Jest, intégrés au CI GitHub Actions. |
Ce nœud a été publié public (npm) et documenté dans le marketplace n8n.
3.3. Exemple de workflow automatisé
[
{
"name": "Dolibarr => Slack Alert",
"nodes": [
{
"parameters": {
"operation": "watch",
"triggerOn": "entityCreated",
"entityType": "Invoice",
"filter": "status = 'pending_payment' AND age > 48h"
},
"name": "Watch Invoice",
"type": "n8n-nodes-base.dolibarr"
},
{
"parameters": {
"text": "⚠️ Facture {{ $json[\"invoice_number\"] }} en attente de paiement depuis {{ $json[\"age\"] }} h"
},
"name": "Build Slack Message",
"type": "n8n-nodes-base.function"
},
{
"parameters": {
"channel": "#alerts-finance"
},
"name": "Post to Slack",
"type": "n8n-nodes-base.slack"
}
],
"active": true,
"description": "Envoie un message Slack dès qu’une facture reste >48 h en attente de paiement."
}
]- Watch : node qui écoute les changements via le webhook mis en place sur Dolibarr.
- Function : calcule l’âge et crée le texte de l’alerte.
- Slack : poste le message dans le canal dédié.
Ce workflow a été déployé en production le jour 27, après une période de stabilisation de 48 h.
4. Résultats obtenus
| KPI | Avant automatisation | Après 30 jours | Évolution |
|---|---|---|---|
| Temps moyen de validation d’une facture | 15 min (saisie manuelle + validation) | 3 min (validation automatisée) | ‑80 % |
| Taux d’erreurs de facturation (duplication / omission) | 1,2 % des factures | 0,2 % | ‑83 % |
| Délai moyen de relance paiement (h) | 72 h | 24 h (notification Slack) | ‑66 % |
| Charge CPU moyenne du serveur ERP | 45 % (périodes de pic) | 23 % (workflow découpé) | ‑49 % |
| Satisfaction utilisateur (survey) | 68 % « satisfait » | 92 % « très satisfait » | +24 pts |
4.1. Retour sur investissement (ROI)
- Coût de développement : 5 personnes‑jours × 8 h × 80 €/h ≈ 3 200 €.
- Gain de productivité : 2 h/jour × 22 jours ouvrés ≈ 44 h/mois économisées.
- Valeur estimée : 44 h × 35 €/h = 1 540 € par mois.
- Payback : < 2 mois (3 200 € / 1 540 € ≈ 2,07 mois).
5. Obstacles & leçons apprises
| Problème rencontré | Solution retenue | Enseignement clé |
|---|---|---|
| Limites de la API Dolibarr (max 100 requêtes/min) | Implémentation de rate‑limiting côté Redis + back‑off exponentiel. | Toujours prévoir un layer d’intermédiation pour éviter le blocage de l’API source. |
| Gestion des credentials sensible (API key stockée dans le code) | Stockage dans Vault (HashiCorp) et injection via variables d’environnement Docker secrets. | Ne jamais committer les secrets; privilégier les « secrets as files » dans Docker/K8s. |
| Synchronisation dans les deux sens (mise à jour du catalogue depuis ERPNext) | Utilisation d’un idempotent token (UUID unique) pour chaque lot d’updates, suivi dans une table de log. | La idempotence est indispensable lorsqu’on agit à la fois sur le source et le target. |
| Déploiement en pré‑prod (débordement de mémoire) | Passage à une instance n8n‑workflow‑cache plus robuste (Redis cache configuré). | Procéder à des tests de charge réalistes (simuler 2000 événements/min). |
| Adhésion des équipes (peur du changement) | Session de formation interactive (démo live + Q&A) + documentation one‑pager avec schémas BPMN. | Impliquer les stakeholders dès la phase de conception; la formation doit être pratique. |
6. Retour sur la feuille de route post‑déploiement
| Action | Priorité | Responsable | Échéance |
|---|---|---|---|
| Étendre le workflow à la détection de stocks critiques (seuils automatisés) | Haute | Équipe dev | +2 mois |
| Ajouter un node Telegram pour notifier les managers en déplacement | Moyenne | PM | +3 mois |
| Mettre en place un dashboard Grafana pour visualiser les KPI d’automatisation | Haute | Ops | +1 mois |
| Sécuriser les appels inter‑services via OAuth2‑Client‑Credentials (actuellement API‑key) | Critique | Sécurité | +1 mois |
| Publier un package npm officiel du node Dolibarr (maintenu par la communauté) | Faible | Dev | +6 mois |
7. Conclusion
Le déploiement de n8n sur Dolibarr en 30 jours a montré qu’une solution d’automatisation open‑source peut être intégrée rapidement à un ERP existant, à condition :
- Définir précisément les processus à automatiser et établir un diagramme BPMN solide.
- Construire un connecteur robuste (gestion des pagination, erreurs, webhook).
- Adopter une architecture modulaire (Docker + Redis + Traefik) pour la scalabilité et la résilience.
- Tester intensivement en environnement sandbox avant la mise en production, puis appliquer un déploiement en blue‑green.
- Impliquer les utilisateurs finaux dès le début pour garantir l’adhésion et la pérennité du changement.
Les bénéfices mesurés (réduction du temps de traitement de 80 %, amélioration de la précision comptable, visibilité temps réel sur les relances) confirment que n8n constitue un levier d’efficacité不可或缺 pour les PME souhaitant moderniser leurs outils ERP/CRM sans engendrer de lourds coûts de licence.
Nous prévoyons dès à présent d’étendre ce cadre d’automatisation à d’autres modules (gestion des achats, reporting financier) et d’en faire bénéficier l’ensemble de la chaîne logistique d’Alpha‑Tech.
Cette étude de cas a été rédigée par l’équipe IT d’Alpha‑Tech, avec le soutien du département développement et de l’expertise n8n (mainteneurs communauté). Les scripts et le connector Dolibarr sont disponibles sur le repository GitHub alpha-tech/n8n-nodes-dolibarr sous licence MIT.