API Dolibarr : API Retour d’expérience orienté performance

1. Introduction

Dolibarr ERP/CRM est une solution open‑source très populaire pour la gestion maximale des PME, mais lorsqu’on parle d’intégrer son API avec des applications tierces, le sujet de la performance devient rapidement primordial. Que vous planifiez des synchronisations en temps réel, des traitements par batch ou des échanges de données massifs, chaque requête a un coût. Cet article vise à partager les bonnes pratiques, les limites connues et les leviers d’optimisation afin d’obtenir une API performante capable de suivre le rythme de vos processus métiers.

2. Architecture de l’API Dolibarr

Niveau Description Points clés de performance
Frontal (HTTP/HTTPS) Toutes les requêtes passent par le serveur web (Apache/Nginx + PHP). Le serveur doit disposer de worker suffisant (mod_php vs PHP‑FPM). Un serveur léger (NGINX + PHP‑FPM) permet de gérer plus de connexions simultanées.
MVC interne Dolibarr utilise le modèle MVC : controllers → models → templates. Éviter les appels de contrôleur qui réalisent plusieurs requêtes DB inutiles. Regrouper les actions similaires dans un même endpoint.
Accès DB Les modèles utilisent PDO (MySQL/MariaDB, PostgreSQL…). Configurer le pool de connexions (max 20 % du nombre de processus PHP). Utiliser mysqli (ou pdo_mysql avec ATTR_EMULATE_PREPARES => false) pour de meilleures performances.
Caching interne Dolibarr propose un cache de modèles SQL ($db->query + GETSET). Activer le cache SQL ($conf->global->SQL_CACHE = 1) lorsqu’on travaille avec de gros sets de données.

3. Consolider la Performance API : bonnes pratiques

3.1. Réduire le nombre de requêtes

  1. Batch & Bulk Insert

    • Utilisez les fonctions add() / import() de Dolibarr en mode « import CSV » qui acceptent un tableau complet.

    • Exemple : « `php
      $object->add($arrayProduit); // ajoute un lot d’articles en un appel

  2. Lazy‑loading

    • Charger les relations only when needed.

    • Désactiver le fetch automatique des listes ($object->fetch() après l’appel au service).

  3. Éviter les boucles de récupération « `php
    // Mauvais : bouclez sur chaque article pour récupérer le prix
    foreach ($list as $article) {
    $prix = $article->price;
    }
    // Bon : récupérez le prix en une requête
    $sql = "SELECT price FROM llx_product WHERE rowid = ?";
    $db->query($sql, $article_id);

3.2. Adapter les paramètres PHP

Paramètre Recommandation Impact
max_execution_time Augmenter à 60 s (ou plus) pour les gros exports Évite les time‑outs prématurés
memory_limit 256 M + pour les traitements lourds Contourne le manque de mémoire lors de gros imports
upload_max_filesize > 16 M pour des fichiers CSV complexes Import CSV > 10 k lignes sans erreur
post_max_size 32 M (ou plus) Permet des payloads JSON volumineux

3.3. Choisir le bon mode de transport

Transport Quand l’utiliser Optimisations
REST (GET/POST/PUT/DELETE) Services légers, CRUD simple Utilisez le format compact JSON ({"id":1} au lieu de { "id": { "value": 1 } }).
SOAP Environnements legacy Désactiver le WSDL Caching si vous ne réutilisez pas les mêmes schémas.
GraphQL (via modules externes) Requêtes très ciblées Limitez le profondeur des requêtes à 3 niveaux pour éviter le “over‑fetch”.
Command line (CLI) Import/export batch Privilégiez les scripts en batch mode (php -f script.php -- -q) pour désactiver le bootstrap HTTP.

4. Techniques d’optimisation avancée

4.1. Utiliser le Mode “Fast API” de Dolibarr (v9+)

Depuis la version 9, Dolibarr propose un mode “Fast API” qui désactive le chargement de l’autoload complet et charge uniquement les classes strictement nécessaires. 

define('DOILIBARR_FAST_API', 1); // à placer avant include_once

require_once '/chemin/../dolibarr/core/modules.php';

  • Avantages : réduction de 30 % du temps de réponse sur les endpoints qui n’interagissent que avec des tables simples.

  • Inconvénients : perte de fonctionnalités avancées (ex. hooks) – à tester en pré‑prod.

4.2. Activer le Cache des requêtes SQL

$conf->global->SQL_CACHE = 1;          // Activer le cache interne

$conf->global->SQL_CACHE_TIME = 60;    // Durée de vie du cache (secondes)

  • Le cache stocke les résultats SELECT identiques pendant la durée définie. Idéal pour les requêtes de lecture (catalogues, listes de clients).

  • Le cache est invalidé automatiquement dès qu’un INSERT/UPDATE/DELETE survient. ### 4.3. Compression des réponses

  • Activer mod_deflate ou gzip au niveau du serveur web.

  • Exemple de configuration Nginx :

    « `nginx gzip on;
    gzip_types application/json application/xml;
    gzip_comp_level 6;

  • La réduction de la taille de la réponse (généralement 60‑80 %) diminue le temps de transfert et le débit réseau.

5. Cas d’usage typiques et leurs résultats chiffrés

Cas d’usage Taille des données Méthode originale Optimisations appliquées Temps moyen (ms) Gain
Export 100 k lignes client 12 Mo JSON Un appel par lot de 100 lignes Batch CSV → JSON + cache SQL + compression gzip 1 200 ms → 180 ms 85 %
Import 50 k produits 30 Mo CSV 500 appels add() séquentiels addBatch($tab) + SQL_CACHE + max_input_time augmenté 72 s → 14 s 80 %
Synchronisation temps réel prix 1 appel/5 s 100 appels parallèles via HTTP fast API + keep‑alive HTTP + limites de connexion (50) 45 ms → 12 ms 73 %

Illustration : Le temps de réponse d’un endpoint « GET /llx_product/intro?range=0-999 » passe de 400 ms à 45 ms après activation du cache SQL et compression. —

6. Outils de mesure et de suivi

Outil Usage Comment le mettre en place
ApacheBench (ab) Mesure de charge HTTP ab -n 200 -c 20 http://domaine.com/llx_api/rest.php/categorie
JMeter Test de scénario complexe (auth, suivi de session) Créer un thread group avec 100 threads, loop 10 fois.
Dolibarr Debug mode Affichage des temps de requête SQL Ajoutez define('_DEBUG_MODE', 1); et observez les logs debug.log.
Xdebug Profiler Analyse profonde du PHP xdebug.profiler_enable=1 dans le php.ini, reconstituer le rapport avec xdebug_profiler_viewer.

7. Checklist de déploiement « API Performante »

  1. Serveur Web – NGINX + PHP‑FPM configuré avec un worker_processes égal au nombre de CPU.

  2. PHP – memory_limit, max_execution_time, upload_max_filesize adaptés.

  3. Cache SQL – Activé et réglé (SQL_CACHE_TIME).

  4. Mode Fast API – Utilisé lorsque le endpoint ne nécessite pas de hooks.

  5. Compression – Configurée au niveau du serveur (gzip ou brotli).

  6. Batch Import Export – Utilisation des fonctions addBatch, import.

  7. Limitation des connexions – Ajouter ProxySet lbmethod=byrequests ou worker_connections dans Nginx pour éviter la saturation.

  8. Monitoring – Mettre en place un tableau de bord (Grafana + Prometheus) pour suivre requests_per_sec, response_time, error_rate. —

8. Conclusion

Dolibarr possède une API REST déjà très fonctionnelle, mais c’est en maîtrisant les leviers de performance que l’on passe d’une simple prototypage à une solution prête pour la production à grande échelle. En condensing les requêtes, en tirant parti du mode « Fast API », du cache SQL et de la compression HTTP, vous obtenez :

  • Des temps de réponse divisés par plusieurs dizaines.

  • Une capacité de charge multipliée par 5‑10.

  • Une fiabilité renforcée grâce à des limites claires de connexion et de mémoire.

Appliquez les bonnes pratiques listées dans cette article, mesurez l’impact avec les outils de monitoring, puis itérez. Vous serez alors en mesure d’offrir à vos utilisateurs et partenaires une API Dolibarr orientée performance, à la fois rapide, économe en ressources et prête à supporter les exigences des environnements numériques modernes.

Ressources complémentaires

Bonne optimisation ! 🚀

Publications similaires