Architecture Dolibarr : web service pour gagner du temps

Dolibarr est un ERP‑CRM open‑source très apprécié des PME, artisans et associations pour sa simplicité d’utilisation et sa modularité. Au‑delà de son interface web « tout‑en‑un », l’une de ses forces réside dans son architecture orientée services qui permet d’automatiser, d’interconnecter et de rationaliser les processus métiers. Dans cet article, nous décortiquons les différents blocs de l’architecture de Dolibarr, démontrons comment le web‑service intégré peut faire gagner un temps précieux, et proposons quelques bonnes pratiques pour l’exploiter au mieux.

1. Principes de base de l’architecture de Dolibarr

Niveau Description Impact sur le gain de temps
Core (núcleo) Application PHP monolithique, mais extensible par modules (menus, objects). Structure claire → moins de temps à chercher où modifier.
Modules Fonctionnalités découpées (ex. Clients, Factures, Produits, Projets). Chaque module possède son API interne. Réutilisation des fonctions → suppression de code redondant.
Base de données SGBD unique (MySQL, PostgreSQL, SQLite…) contenant toutes les tables. Un point de persistance centralisé évite les synchronisations multiples.
Web‑service (REST/SOAP) Expose les objets métier ($object->get, $object->add, $object->exists, …) via des URLs standardisées. Permet d’appeler Dolibarr depuis des scripts externes ou d’autres applications sans réécrire la logique métier.
Interface graphique HTML/Bootstrap + plugins. UI unique → pas de double formation pour les utilisateurs.

Le fil conducteur : chaque fonctionnalité métier possède une API publique (REST) qui agit comme un point d’accès aux services de Dolibarr. C’est exactement ce qui permet de gagner du temps lorsqu’on veut automatiser ou synchroniser avec d’autres outils.

2. Comment le web‑service de Dolibarr accélère le quotidien

2.1. Un point d’entrée unique pour plusieurs tâches

  • Facturation & devis : Poster un tableau JSON contenant les lignes de facturation crée un devis ou une facture en une requête HTTP POST /mymodule/dongle.

  • Gestion des stocks : Un simple GET /product récupère le stock actuel, évitant tout script de lecture de tables.

  • Notifications : Utiliser le endpoint /tool/email pour envoyer des mails sans toucher au code PHP de Dolibarr.

Résultat : Une seule requête couvre plusieurs étapes qui, dans un scénario manuel, nécessiteraient plusieurs vérifications et appels de fonctions PHP séparées.

2.2. Automatisation des flux récurrents

Processus Script externe (exemple) Temps moyen manuel Temps automatisé via API
Création d’un client + devis curl -XPOST http://dolibarr.com/thirdparty --data '{"name":"Alice", "currency":"EUR"}' 5 min (saisie + sauvegarde) 30 s
Export des ventes du mois GET /salesreport?date_start=2025-10-01&date_end=2025-10-31 10 min (rapport PDF) 15 s (JSON + export CSV)
Synchronisation ERP externe PUT /order/confirm 20 min (vérif. stock + mise à jour) 1 min (requête + validation côté serveur)

Bilan : En moyenne, une tâche automatisée via le web‑service réduit le temps de 3 à 10 fois par rapport à une exécution manuelle.

2.3. Intégration facile avec d’autres systèmes

  • Zapier / Integromat : Utilisation des webhooks Dolibarr (eventtrigger) pour déclencher des flux lorsqu’un bon de commande est créé.

  • CRM : Synchronisation bidirectionnelle entre un CRM (HubSpot, Salesforce) et dolibarr via des appels GET/POST.

  • BI : Extraction des performances (chiffre d’affaires, marge) via /reports et connexion directe à un outil comme Power BI ou Metabase.

Gain : Pas besoin de développer un connecteur spécifique ; les API sont documentées et RESTful, donc compatibles avec tout client HTTP standard.

3. Architecture détaillée du web‑service Dolibarr

3.1. Modèle de requête

GET /product/list?range=0-10POST /invoice/create

PUT /order/{id}

DELETE /payment/{id}

  • URL = module/action → lecture (list, get) ou écriture (create, update, delete).

  • Headers : Accept: application/json, Authorization: Bearer <token> (si OAuth ou token interne). – Body : JSON représentant les champs du modèle (label, price, quantity, …).

Sécurité : L’accès est limité à des profil du système Dolibarr (ex. Admin, Seller, Viewer).

3.2. Cycle de vie d’une requête

  1. Route déclenchée par le routeur interne ($dolibarrContext->route).

  2. Vérification des droits (module‑permission).

  3. Appel du service (ProductCore::get($id), etc.).

  4. Rendu JSON via $json_result = array('status'=>1,'data'=>…).

  5. Cache (optionnel) : utilisation de dol_cache_set() pour éviter de recomposer le même résultat si les données n’ont pas changé.

3.3. Exemple de code d’appel (PHP)

function createInvoiceFromWebservice($clientId, $lines) {

    $url = "https://dolibarr.example.com/invoice/create";

    $data = [

        'client' => $clientId,

        'currency' => 'EUR',

        'lines'  => $lines

    ];

    $options = [

        'http' => [

            'header'  => "Content-Type: application/json\r\n",

            'method'  => 'POST',

            'content' => json_encode($data)

        ]

    ];

    $context  = stream_context_create($options);

    $result   = file_get_contents($url, false, $context);

    $response = json_decode($result, true);

    return $response['valid'] ? $response['invoice_id'] : false;

}

Tip : Centraliser les appels dans un wrapper (ex. DolibarrApiClient) vous évite de répéter les en‑têtes et la gestion d’erreur dans chaque service externe.

4. Stolon et les bonnes pratiques pour maximiser le gain de temps

Pratique Pourquoi c’est efficace Exemple concret
Utiliser les actions batch (/product/batchUpdate) Traite 500 lignes en un seul appel plutôt que 500 appels individuels. Import de 1 200 tarifs en 10 s au lieu de 15 min.
Sauvegarder les tokens Évite de devoir ré‑authentifier à chaque appel. Stocker le token OAuth dans Redis, la durée de vie = 12 h.
Mettre en cache les réponses GET (Cache-Control: max-age=3600) Réduit le nombre de requêtes serveur pour les mêmes données. Connexion client → 1 requête, ensuite 10 000 affichages instantanés.
Déclencher des jobs asynchrones (queue RabbitMQ) Le client reçoit immédiatement « OK », la tâche lourde s’exécute en arrière‑plan. Génération de factures PDF à la volée, pas de blocage du front‑office.
Structurer les réponses ({status, data, error}) Uniformise la logique de traitement côté client, pas de if/else partout. Front‑office simplifie l’affichage des messages.

5. Scénario complet : Automatiser la facturation d’un site e‑commerce

  1. Étape 1 – Création du panier

    • Le client finalise son achat sur la boutique (Magento, WordPress WooCommerce…).

    • Un webhook envoie le payload à Dolibarr (POST /order/create).

  2. Étape 2 – Vérification du stock

    • Le script appelé récupère le stock via /product/get.

    • Si le stock est insuffisant, une notification est renvoyée à l’e‑commerçant.

  3. Étape 3 – Génération de la facture

    • Un appel POST /invoice/create avec les lignes du panier crée automatiquement la facture.

  4. Étape 4 – Envoi du PDF

    • Le service invoice/pdf/{id} renvoie l’URL du PDF.

    • Un Webhook déclenche l’envoi du mail (SMTP ou SendGrid) avec le PDF en pièce jointe.

  5. Étape 5 – Retour d’état

    • Le client reçoit un statut « Facture générée » sur son tableau de bord. – Le statut est enregistré dans la table invoice et visible via /invoice/list.

Temps total : ~30 secondes (ou moins) contre plusieurs minutes lorsqu’on procède manuellement via l’admin Dolibarr.

6. Limites et points d’attention

Limite Solution / contournement
Taux de limitaçãoon API (si le serveur expose une petite charge) Activer le modulo cache et réduire la granularité des appels.
Authentification Utiliser des tokens à durée limitée ou la fonction dol_get_http_token.
Versioning Les API sont liées à la version du module ; prévoir un layer de compatibilité (ex. façade DolibarrApiV1).
Gestion des erreurs Documenter les codes HTTP (400, 401, 403, 404, 500) et implémenter un mécanisme de retry.

7. Conclusion

L’architecture de Dolibarr n’est pas uniquement un ERP « tout‑en‑un ». Son web‑service REST constitue un véritable moteur d’automatisation, capable de :

  • Raccourcir les cycles de processus (création de devis, factures, bons de commande).

  • Éliminer les saisies redondantes grâce à un accès direct et normalisé aux objets métier.

  • Faciliter l’intégration avec d’autres outils (CRM, BI, ERP externes) sans développer de connecteurs spécifiques.

  • Optimiser les performances grâce au cache, aux batchs et aux appels asynchrones.

En résumé, exploiter le web‑service de Dolibarr, c’est profiter d’une couche d’abstraction qui transforme des tâches manuelles fastidieuses en flux automatisés, générant ainsi de nombreuses heures économisées chaque mois. Pour les PME qui cherchent à digitaliser leurs opérations sans complexifier leur stack technologique, l’architecture orientée services de Dolibarr est un atout décisif pour gagner du temps et, par ricochet, de l’argent.

🎯 À retenir

  1. API = point d’entrée unique → pas de code dupliqué.

  2. REST + JSON → interopérable avec tout langage.

  3. Gestion fine des droits → sécurité intégrée.

  4. Automatisation des flux → réduction de 3 à 10× du temps de traitement.

N’attendez plus : déployez le web‑service Dolibarr, définissez vos endpoints clés, testez en mode batch, puis laissez la mécanique s’enclencher. Vous verrez rapidement combien de temps vous pouvez récupérer chaque jour.

Vous avez besoin d’un exemple de code ou d’un schéma d’intégration ? N’hésitez pas à me le préciser, je vous préparerai un mini‑dossier « starter‑kit ».

Publications similaires