API Dolibarr : facturation électronique Comparaison pour mieux piloter

Version 2025 – Dolibarr 18.0 et supérieures

1. Introduction

Dans le contexte de la transformation digitale, la facturation électronique s’impose comme un standard pour les entreprises soucieuses de réduire leurs coûts, d’améliorer la traçabilité et de se conformer aux exigences légales (SEPA, UBL, norme ISO 20022, etc.). Dolibarr, ERP / CRM open‑source très répandu chez les PME et les associations, propose depuis plusieurs versions une API RESTful riche qui facilite l’intégration de solutions de facturation électronique.

Cet article vise à :

  1. Présenter les principales fonctionnalités d’électronisation de la facturation via l’API Dolibarr.

  2. Comparer ces fonctionnalités avec celles d’autres solutions du marché (SAP, Sage, Odoo, Zoho Invoice).

  3. Proposer un cadre de pilotage (KPIs, gouvernance, étapes de mise en œuvre) pour exploiter pleinement l’API afin de « mieux piloter » votre facturation.

2. Dolibarr : rappel rapide des forces et limites

Point Description
Architecture Open‑source, PHP + MySQL/MariaDB, installation simple (Docker, XAMPP, serveur dédié).
Fonctionnalités de base Gestion des contacts, articles, devis, factures, stocks, tickets, points de vente.
Modularité Plus de 80 modules (facturation, comptabilité, gestion des notes de frais, multidomaines, etc.).
Communauté Plus de 300 000 téléchargements annuels, forums actifs, extensions contributions GitHub.
Limites Pas de nuage « first‑line » (cloud‑first) ; la customisation nécessite des compétences PHP/JavaScript.

Ces points sont cruciaux lorsqu’on envisage d’utiliser l’API pour la facturation électronique : la modularité permet d’ajouter des flux spécifiques, mais il faut anticiper les besoins de développement.

3. L’API REST de Dolibarr : ce qu’elle offre pour la facturation électronique

3.1. Architecture générale

Élément Détails
Base URL https://votre‑domaine.com/dolibarr/api/ (PATH = /api/ par défaut).
Authentification Clé API (apikey) ou session PHP ($user->login()). Support OAuth2 (v2024).
Format de données JSON uniquement (request & response).
Versioning /v1/, /v2/ – chaque version ajoute des champs optionnels ou de nouvelles ressources.
Limites 60 req/min par clé (configurable), pagination (limit/offset).
Documentation Swagger/OpenAPI intégré (/api/swagger), accessible via https://votre‑domaine.com/dolibarr/api/doc.

Astuce : la version v2 (LTS 2025) introduit le support natif des UBL‑XML via un endpoint dédié (/v2/invoice/ubl).

3.2. Ressources clés liées à la facturation

Ressource URL-type Principales actions Exemple de payload
Customer /v2/customers/{id} GET, PUT, POST { "name":"Acme Corp.", "country":"FR" }
Product /v2/products/{id} GET, POST { "label":"Clavier mechanical", "price":45.90, "tax_id":2 }
Invoice /v2/invoices/{id} GET, POST, PUT, DELETE { "invoice_number":"INV-2025-001", "date":"2025-10-31", "currency":"EUR" }
InvoiceLine /v2/invoices/{id}/lines POST (création ligne) { "product_id":3, "quantity":2, "unit_price":45.90 }
InvoiceUBL /v2/invoices/{id}/ubl POST (génération UBL) { "issuer_id":"123456789", "signature":"…"}

3.3. Étapes clés pour créer une facture électronique

  1. Création du client (ou récupération d’un client existant) 

    POST /v2/customers
    
{
    
 "name":"Acme Corp.",
    
 "country":"FR",
    
 "email":"contact@acme.fr"
    
}

  2. Création du produit (ou utilisation d’un produit déjà existant) 

    POST /v2/products
    
{
    
 "label":"Clavier mechanical",
    
 "price":45.90,
    
 "tax_id":2,
    
 "type":"service"
    
}

  3. Création de la facture 

    POST /v2/invoices
    
{
    
 "customer_id":12,
    
 "date":"2025-11-02",
    
 "currency":"EUR",
    
 "lines":[
    
   {"product_id":45, "quantity":1, "unit_price":45.90},
    
   {"product_id":67, "quantity":2, "unit_price":12.50}
    
 ],
    
 "invoice_type":"sale"
    
}

  4. Génération du fichier UBL (ou PDF conforme) 

    POST /v2/invoices/42/ubl
    
{
    
 "output":"xml"
    
}

    La réponse contient le fichier XML signé (ou le lien vers le PDF généré).

  5. Envoi automatisé (via webhook ou appel programmatique à un service de transport) 
    POST /v2/webhooks
    
{
    
 "url":"https://mailing.example.com/notify",
    
 "events":["invoice.created"]
    
}

4. Comparaison avec les principales solutions concurrentes

Critère Dolibarr API SAP Ariba Invoice Odoo e‑Invoicing Sage X3 e‑Invoicing Zoho Invoice (API)
Déploiement On‑prem / Docker / Cloud SaaS/On‑prem SaaS (et on‑prem) SaaS/On‑prem SaaS uniquement
Complexité d’intégration Moyen (PHP + JSON) Élevée (ABAP, OData) Moyenne (REST, GraphQL) Moyenne (REST) Faible (REST simple)
Support natif UBL/UN/CEFACT UBL‑XML & PDF via module Facture Électronique Support complet UBL & CII Support UBL & PDF/A‑3 Support UBL & PDF PDF uniquement (pas d’UBL)
Gestion des flux multi‑devise Oui (multi‑currency dans le même invoice) Oui (mais limité aux modules comptabilité) Oui Oui (mais nécessite paramétrage avancé) Non (devise fixe)
Propriété des données 100 % propriétaire (entreprise uniquement) Cloud provider possède les données Propriété partagée (SaaS) Cloud provider dominant Propriété détenue par Zoho
Extensibilité Plugins PHP, API ouverte, webhooks Extensions SAP, mais avec gouvernance stricte Apps marketplace (Python, Node) Scripts Python, mais limité Webhooks limités, pas de SDK officiel
Coût de licence Open‑source (gratuit) + support commercial payant Licence commerciale très élevée Licence SaaS (abonnement) Licence commerciale + module Abonnement mensuel par utilisateur
Scalabilité Horizontal scaling via Docker/K8s Très haute (data‑center) Haute (cloud) Haute (cloud) Modérée (limite 50 000 factures/mois)
Conformité légale Conformité France/UE via modules (ex. Facturation électronique). Conformité globale, certifications ISO Conformité EU + Canada Conformité EU, mais besoin d’ajouts Pas de conformité officielle (pas de UBL)

4.1. Points forts de Dolibarr dans ce comparatif

Atout Pourquoi c’est pertinent pour la facturation électronique
Coût d’entrée Gratuit, idéal pour les PME qui veulent éviter les licences onéreuses.
Intégration native de modules comptables & logistiques Pas besoin de synchroniser plusieurs systèmes – toutes les données (stock, ventes, achats) sont déjà dans la même base.
API modulaire & open source Possibilité d’ajouter des traitements spécifiques (ex. génération de QR‑code, archivage PDF/A‑3).
Déploiement souverain Peut être installé sur un serveur interne ou sur un cloud souverain (AWS GovCloud, Azure France) – indispensable pour les data‑souveraineté française.
Webhooks & architecture asynchrone Facilite l’automatisation du flux de validation, d’envoi et d’archivage sans polluer l’interface utilisateur.
Écosystème de partenaires Un large panel de partenaires francophones propose des connecteurs pré‑packagés (Banque, comptabilité tiers, hébergeurs de factures).

4.2. Scénarios où Dolibarr est moins adapté

Situation Pourquoi choisir une autre solution
Gestion de millions de factures/mois SAP, Odoo ou Sage offrent une architecture plus robuste au niveau de la base de données et du clustering.
Exigence d’intégration ERP complexe (B2B multi‑site, multi‑entité légale) Les ERP spécialisés offrent des modules dédiés (multi‑legal, multi‑tax) qui sont plus matures.
Usage exclusif de la facturation directe aux consommateurs (B2C) avec grands volumes de paiement Des solutions dédiées (Stripe Billing, Square) sont plus orientées paiement et expérience client.

5. Mettre en place l’API Dolibarr pour piloter la facturation électronique : cadre de pilotage

5.1. Gouvernance & organisation

Rôle Responsabilité
Chef de projet IT Définir les exigences fonctionnelles, valider la roadmap API.
Architecte technique Concevoir le schéma de sécurité (API‑Key + OAuth), plan de mise en cache, scaling.
Opérateur Facturation Valider les modèles de facture, vérifier la conformité UBL/PEPPOL.
Compliance Officer S’assurer que chaque flux respecte la législation locale (TVA, CFDI, etc.).
Support & Maintenance Gérer les incidents d’API, mettre à jour les modules.

5.2. KPI (Key Performance Indicators) à suivre

KPI Objectif typique Méthode de calcul
Taux de factures électroniques créées / totales ≥ 90 % des factures émises via l’API (Factures créées via API ÷ Total factures) * 100
Temps moyen de génération UBL ≤ 2 s Moyenne (timestamp_génération - timestamp_création)
Erreur d’API (4xx/5xx) < 0,5 % des appels (Appels avec error ÷ Total appels) * 100
Taux de rejet par le serveur de facturation externe < 1 % (Rejets ÷ Factures émises) * 100
Coût d’infrastructure API < 0,02 €/facture Calcul based on serveur/CPU‑hours + trafic réseau
Satisfaction des parties prenantes Score ≥ 4/5 (sur 5) Enquêtes trimestrielles auprès des équipes compta/logistique.

5.3. Étapes de mise en œuvre (road‑map 6 mois)

  1. Analyse & cadrage (Mois 1)

    • Recenser les processus de facturation (AP/AR).

    • Identifier les formats légaux (UBL‑XML, PDF/A‑3, QR‑code).

    • Définir les endpoints API à exploiter.

  2. Prototype technique (Mois 2‑3)

    • Installer une instance Docker de Dolibarr v2025.2.

    • Créer des scripts Python (bibliothèque dolibarr-py) pour créer, signer et exporter une facture.

    • Tester en sandbox avec des jeux de données réalistes.

  3. Sécurisation de l’accès (Mois 3‑4)

    • Mettre en place une clé API par service (ex. service comptable, service d’envoi).

    • Configurer OAuth2 (client‑id/secret) pour les partenaires externes.

    • Activer le mode HTTPS‑Only et le rate‑limit dans le reverse‑proxy (NGINX).

  4. Développement du pipeline de facturation (Mois 4‑5)

    • ETL : extraire les devis validés, les transformer en factures via les endpoints /invoices.

    • Génération UBL : appeler /invoices/{id}/ubl et stocker les fichiers dans un bucket S3/MinIO.

    • Notification : configurer les webhooks vers un service de mailing ou vers un système de transport (ex. SFTP vers le client).

  5. Tests de charge & conformité (Mois 5‑6)

    • Simuler 10 000 factures en 1 h avec k6 ou Locust.

    • Valider la signature XML avec le validation schema UBL.

    • Mettre à jour la matrice de conformité légale (TVA intracommunautaire, seuil de franchise).

  6. Mise en production & monitoring (Mois 6+)

    • Déployer sur un cluster Kubernetes avec autoscaling.

    • Activer des alertes Prometheus/Grafana (latence API, erreurs).

    • Réviser les KPI chaque mois et ajuster les seuils.

6. Bonnes pratiques et astuces avancées

Astuce Description
Cache de réponse Mettre en cache les réponses GET /customers/{id} pendant 5 minutes (Redis) pour réduire le temps de résolution de la facture.
Sérialisation UBL normalisée Utiliser les classes PHP internes de Dolibarr (class UBLGenerator) pour garantir que le schéma XML respecte toujours la version du standard.
Gestion des retours Implémenter un endpoint POST /v2/invoices/{id}/return qui crée automatiquement une note de crédit (XML dédié).
Versionning de schéma UBL Stocker la version UBL utilisée (UBLVersion: 2.1) dans les métadonnées de la facture afin de simplifier les audits rétroactifs.
Archivage immuable Script de verrouillage (chmod 0444) et via Object Lock sur S3 pour garantir la non‑altération après archivage.
Mise à jour progressive Passer à la version v2 de l’API en mode blue‑green : les deux versions fonctionnent en parallèle, le trafic est progressivement routé vers la nouvelle version.
Documentation versionnée Conserver un fichier API_CHANGELOG.md dans le repo Git du projet pour tracer chaque évolution d’endpoint.

7. Conclusion

L’API REST de Dolibarr représente une passerelle puissante pour automatiser la facturation électronique tout en bénéficiant d’un coût d’entrée très attractif et d’une totale souveraineté des données. Malgré ses limites en matière de scalabilité massive ou d’intégration ERP ultra‑complexe, elle se distingue par :

  • Une modularité native qui permet d’ajouter rapidement des fonctionnalités spécifiques (signature XML, webhooks, génération de PDF/A‑3).

  • Une conformité légale facilitée grâce aux modules dédiés (UBL, PEPPOL, QR‑code).

  • Une gouvernance simple : API‑Key, OAuth2, webhooks, accompagnée d’une documentation Swagger auto‑générée.

En suivant le cadre de pilotage présenté – définition de KPI, mise en place d’une gouvernance claire, phases de prototypage et de validation – il est possible de piloter de bout en bout le processus de facturation électronique, d’assurer la qualité des flux et d’obtenir des indicateurs de performance mesurables.

Pour les PME, associations ou structures cherchant à réduire leurs coûts de traitement de factures tout en restant en conformité avec la législation européenne, Dolibarr + son API REST constitue aujourd’hui une solution à la fois économique, flexible et prête pour l’avenir.

À retenir : la clé du succès réside dans la combinaison d’une architecture technique solide (Docker/K8s, caching, monitoring) et d’une gouvernance métier rigoureuse (KPIs, conformité). Ainsi, l’entreprise pourra non seulement piloter efficacement la facturation électronique, mais aussi en extraire de la valeur ajoutée (réduction des erreurs, gain de temps, amélioration de la cash‑flow).

Vous avez des questions précises sur l’intégration de l’API Dolibarr dans votre environnement ou sur les meilleures pratiques de génération UBL ? N’hésitez pas à me les poser, je vous fournirai des exemples de code et des recommandations d’outils d’automatisation.

Publications similaires