Dolibarr en production : webhooks et bonnes pratiques orienté performance

Dolibarr est un ERP/CRM open source puissant et polyvalent, mais son déploiement en environnement de production exige une attention particulière pour garantir performance, stabilité et évolutivité. Au-delà de l’installation standard, l’utilisation stratégique des webhooks et le respect de bonnes pratiques d’optimisation sont essentiels pour tirer pleinement parti de l’outil dans un contexte professionnel exigeant.

1. Comprendre le contexte "production" pour Dolibarr

Contrairement à un environnement de test ou de démonstration, la "production" implique :

  • Des utilisateurs simultanés (équipes commerciales, comptabilité, gestion de stock).

  • Des données critiques et volumineuses (historique, fichiers joints, transactions).

  • Des besoins de disponibilité élevée (temps de réponse < 2s).

  • Une intégration avec d’autres systèmes ( sites e-commerce, outils de paie,_LOGICIELS comptables).

C’est ici que les webhooks et l’optimisation deviennent stratégiques.

2. Les Webhooks dans Dolibarr : Automatisation et intégration temps réel

Qu’est-ce qu’un webhook Dolibarr ?

Un webhook est une notification HTTP automatique envoyée par Dolibarr lorsqu’un événement spécifique se produit (ex. : création d’une facture, ajout d’un contact, changement de statut de commande). C’est un push vers une URL externe, évitant ainsi les requêtes polling coûteuses.

Événements exploitables (extraits) :

  • ACTION_CREATE / ACTION_UPDATE / ACTION_DELETE sur tout objet (facture, commande, produit, etc.)

  • MEMBER_SUBSCRIPTION (adhésion à une association)

  • BILL_PAYED (facture payée)

  • PROJECT_TASK (tâche de projet créée/modifiée)

Cas d’usage concrets en production :

  1. Synchronisation avec un outil de business intelligence : Envoi automatique des nouvelles factures vers un dashboard Power BI/Tableau.

  2. Alertes métier : Notifier un canal Slack/Teams lors de l’ajout d’un gros client ou d’une facture impayée.

  3. Workflows externes : Déclencher la préparation d’une commande dans un système de gestion d’entrepôt (WMS) dès qu’une commande est validée.

  4. Audit et conformité : Envoyer une copie sécurisée de chaque document sensible vers un système d’archivage à valeur probante.

Configuration et bonnes pratiques :

  • Sécurité : Toujours utiliser des URLs HTTPS avec authentification (token dans l’en-tête, Basic Auth, ou vérification de signature HMAC).

  • Fiabilité : Configurer un système de file d’attente (comme RabbitMQ ou Redis) côté récepteur pour éviter la perte de notifications en cas de pic de charge. Dolibarr n’attend pas la réponse du webhook ; il le lance et passe à la suite.

  • Filtrage : Ne déclencher les webhooks que pour les événements utiles, avec des filtres sur les objets/statuts (ex. : seulement pour les factures > 1000€).

  • Test et monitor : Simuler les événements via l’interface d’administration (Accueil > Outils > Webhooks) et logger systématiquement les réponses des endpoints distants.

  • Logique de rejeu : Prévoir un mécanisme pour renvoyer les webhooks échoués (via une table de log dédiée).

3. Bonnes pratiques de performance pour Dolibarr en production

A. Infrastructure et serveur

  1. Stack recommandée :

    • PHP : Version 8.1+ (OPcache activé et optimisé).

    • MySQL/MariaDB : Version 10.6+ avec innodb_buffer_pool_size réglé à 70-80% de la RAM.

    • Web server : Nginx (plus performant que Apache pour PHP-FPM en charge).

    • PHP-FPM : Ajuster pm.max_children, pm.start_servers, pm.min_spare_servers selon la RAM et le nombre de cœurs. Surveiller max_execution_time (300s pour les exports lourds).

  2. Cache applicatif :

    • OPcache : opcache.memory_consumption=512, opcache.max_accelerated_files=10000.

    • Cache de session : Stocker les sessions PHP en Redis ou Memcached, pas en fichiers (surtout en cluster).

    • Cache Dolibarr : Activer le cache de résultats dans dokuwiki/htdocs/conf/extra/conf.php (si utilisé) ou via des extensions tierces.

  3. Fichiers statiques et sessions :

    • Servir les documents stockés (documents/) via un CDN ou un sous-domaine dédié (ex. : files.monentreprise.com).

    • Configurer un domaine de session séparé pour éviter les conflits de cookies si plusieurs applications PHP sur le même serveur.

B. Configuration Dolibarr

  1. Désactiver le debug : En production, $dolibarr_main_prod = 1; dans conf.php.

  2. Limiter les logs : Niveau WARNING ou ERROR pour les logs système (dolibarr.log), rotation automatique.

  3. Optimiser les modules :

    • Désactiver les modules inutilisés (réduit la charge mémoire et le chargement des menus).

    • Éviter les champs personnalisés inutiles sur les tables principales (ralentissent les requêtes).

  4. Gestion des images et documents :

    • Limiter la taille des uploads (upload_max_filesize, post_max_size).

    • Ne pas stocker de fichiers binaires en base (Dolibarr les stocke en fichiers par défaut, c’est bon).

C. Base de données

  1. Indexation :

    • Vérifier régulièrement les requêtes lentes (slow_query_log).

    • Indexer les champs fréquemment utilisés en WHERE/JOIN (ex. : fk_soc sur les tables de transactions).

  2. Archivage :

    • Mettre en place une politique d’archivage des données anciennes (ex. : déplacer les factures de +10 ans vers une base séparée ou un stockage froid).

    • Utiliser les sauvegardes incrémentielles (xtrabackup, dump partiel).

  3. Nettoyage :

    • Programmer le nettoyage des tables temporaires (llx_cronqueue, llx_action_trigger).

    • Purger les emails logs (llx_societe_mailing) après envoi.

D. Surveillance et maintenance

  1. Monitoring :

    • APM (Application Performance Monitoring) : utiliser New Relic, Datadog ou Scout APM pour tracer les transactions Dolibarr et identifier les slow endpoints.

    • Infra :监控 CPU/RAM/Disque (Prometheus/Grafana).

    • Logs : Centraliser les logs Dolibarr et PHP vers ELK ou Graylog.

  2. Cronjobs :

    • Limiter les tâches planifiées (dolibarr_cron) aux strictes nécessités (envoi d’emails massifs, calculs de com, génération de PDF).

    • Les exécuter hors heures de pointe.

    • Éviter les cron qui recalculent des totaux sur de grandes périodes en une fois (préférer des traitements par lots).

  3. Mises à jour :

    • Toujours mettre à jour (correctifs de sécurité et performance).

    • Tester en pré-production avec un jeu de données réaliste.

    • Sauvegarder base et dossiers documents avant toute MAJ.

4. Checklist démarrage en production

Point de contrôle Priorité
PHP-FPM paramétré selon la RAM ⭐⭐⭐⭐
Cache OPcache + Redis sessions ⭐⭐⭐⭐
HTTPS partout (web + webhooks) ⭐⭐⭐⭐⭐
Authentification webhook (token HMAC) ⭐⭐⭐⭐⭐
Backup automatique (base + documents/) ⭐⭐⭐⭐⭐
Monitoring temps de réponse (APM) ⭐⭐⭐⭐
Modules inutiles désactivés ⭐⭐⭐⭐
Logs rotés, niveau WARNING ⭐⭐⭐⭐
Archivage des données anciennes planifié ⭐⭐⭐
Tests de charge avec ab ou k6 ⭐⭐⭐⭐

5. Conclusion : Performance rime avec anticipation

Dolibarr en production n’est pas une simple application que l’on "lance". C’est un écosystème qui doit être :

  • Connecté via des webhooks fiables et sécurisés pour s’intégrer à votre paysage IT.

  • Observable avec des métriques claires (temps de réponse, erreurs, charge DB).

  • Maintenu avec des mises à jour régulières, un nettoyage périodique et une infrastructure adaptée.

En appliquant ces pratiques, vous transformez Dolibarr d’un ERP "gratuit" en un système d’information robuste et performant, capable de supporter la croissance de votre activité sans crispation. L’objectif n’est pas seulement de "faire tourner" Dolibarr, mais de le faire tourner vite et bien — au service de vos processus métier, et non l’inverse.

Article rédigé par un expert en déploiement de solutions open source pour les PME/ETI. Les réglages précis dépendent de votre volumétrie et de votre hébergement ( mutualisé, VPS, dédié, cloud ).

Publications similaires