Diagnostiquer Dolibarr : performance Comparaison pour équipes hybrides

À l’ère du travail hybride, les solutions ERP/CRM comme Dolibarr deviennent le spine numérique des organisations. Lorsque les équipes sont réparties entre le bureau et le domicile, les performances de la plateforme peuvent se dégrader de manière critique, impacting directement la productivité. Cet article propose un cadre structuré pour diagnostiquer, mesurer et optimiser les performances de Dolibarr dans un contexte hybride.

Pourquoi le contexte hybride est un défiunique pour Dolibarr ?

Le modèle hybride exacerbe des facteurs de latence et de congestion qui peuvent passer inaperçus en environnement bureautique mono-site :

  • Latence réseau variable : Les connexions à domicile (Wi-Fi, partage de bande passante) ajoutent des délais aux requêtes HTTP/API.

  • Concurrence des ressources : Les pics d’utilisation simultanée (ex: fin de mois pour la compta) peuvent saturer les serveurs ou les bases de données.

  • Expérience utilisateur disparate : Un commercial en déplacement ne subit pas les mêmes temps de réponse qu’un assistant au siège.

  • Complexité de l’infrastructure : Accès via VPN,.reverse proxy, ou solutions cloud (type OVH, Scaleway) ajoutent des couches d’échanges.

Étape 1 : Le diagnostic performance – Une approche méthodique

A. Mesurer l’expérience utilisateur réelle (RUM – Real User Monitoring)

  • Outils simples : Intégrez des outils comme Google PageSpeed Insights, WebPageTest ou Lighthouse pour mesurer les Core Web Vitals (LCP, FID, CLS) sur les pages clés de Dolibarr (listes de contacts, bons de commande, factures).

  • Focus hybride : Testez depuis différents réseaux (4G/5G, Wi-Fi domestique, fibre entreprise). Une différence de LCP > 2s entre deux configurations est un indicateur fort de problème réseau ou de cache inadapté.

  • Point de vigilance : Le module "Agenda" ou "Projets" peut paraître réactif au bureau mais devenir lent à distance à cause d’appels AJAX fréquents.

B. Analyser la pile technique côté serveur

  1. Serveur Web (Apache/Nginx) :

    • Vérifiez les logs d’accès (access_log) pour identifier les pics de requêtes et les temps de réponse (%D ou %T dans le format de log).

    • Utilisez mod_status (Apache) ou stub_status (Nginx) pour voir les connexions actives et les requêtes en attente.

    • Hybride : Une hausse anormale de requêtes provenant de plages IP externes (VPN des téléworkers) peut indiquer une mauvaise configuration de cache ou des appels redondants.

  2. Base de données (MySQL/MariaDB/PostgreSQL) :

    • Activez et analysez le slow query log (long_query_time = 1 par défaut).

    • Exécutez SHOW PROCESSLIST; pendant les heures de forte activité pour identifier les requêtes bloquantes ou longues.

    • Point clé : Les requêtes sur les tables llx_societe, llx_projet, llx_facture sont souvent critiques. Vérifiez les index (SHOW INDEX FROM table;).

  3. PHP ( environnement Dolibarr) :

    • Vérifiez la configuration opcache.enable=1 et sa mémoire (opcache.memory_consumption). Sans OPcache, chaque page doit recompiler le code PHP, un désastre en environnement distribué.

    • Utilisez des profilers comme Xdebug (en dev) ou Blackfire pour identifier les fonctions PHP gourmandes.

C. Analyser le réseau et l’infrastructure

  • Traceroute / MTR depuis un poste distant vers le serveur Dolibarr pour identifier les sauts de latence ou les pertes de paquets.

  • VPN : Si l’accès passe par un VPN, testez la bande passante et la latence directement vs via le VPN. Un VPN surchargé ou mal configuré peut doubler les temps de réponse.

  • CDN / Cache : Pour les assets statiques (images, CSS, JS), un CDN (Cloudflare, etc.) est indispensable en mode hybride. Vérifiez les en-têtes de cache (Cache-Control, Expires).

Étape 2 : Comparaison des configurations – On-premise vs Cloud vs Hébergé

Critère On-premise (Serveur interne) Cloud Public (OVH, AWS, etc.) Hébergement mutualisé/Spécialisé
Latence réseau Variable selon la localisation des équipes. Le bureau = excellente, téléworker = dépend de sa connexion + VPN. Potentiellement meilleure si le datacenter est proche des utilisateurs. À vérifier avec des tests RUM. Souvent médiocre depuis l’extérieur (partage de ressources, IP partagée).
Scalabilité Limitée par la硬件 physique. À planifier (mise à niveau CPU/RAM/SSD). Très bonne. possibilité d’ajuster ressources (vertical) et load balancer (horizontal). Nulle ou très limitée par le contrat.
Maintenance/Coût Coût humain élevé (admin système), mais contrôle total. Coût prévisible (abonnement), maintenance externalisée (mises à jour OS/DB parfois). Coût bas, mais performance imprévisible ("noisy neighbor").
Bon pour hybrides Oui, si : IT compétent, bande passante stable, et serveur sur site près des bureaux. Souvent le meilleur choix pour équipes géographiquement dispersées (choisir région proche). Déconseillé pour plus de 10 utilisateurs hybrides, sauf pour de la consultation légère.
Control total Maximum. On peut tout optimiser (kernel, DB, PHP). Moyen. Accès root/SSH selon l’offre (VPS vs PaaS). Minimal. Seul le paramétrage Dolibarr est accessible.

Recommandation clé : Pour des équipes hybrides stables (>50% de temps à distance), privilégiez une instance cloud (type VPS) dans une région géographique centrale pour vos utilisateurs. Évitez l’hébergement mutualisé bas de gamme.

Étape 3 : Plan d’optimisation ciblé pour le hybride

  1. Cache, cache, cache :

    • Activez le cache OPcache (PHP) et configurez-le avec une haute mémoire.

    • Utilisez un reverse proxy cache (Varnish) en frontal Dolibarr. Il peut servir des pages entières statiques (comme le portal public) sans toucher à PHP/DB, réduisant drastiquement la charge.

    • Pour Dolibarr 15+, le cache d’objets natif ($dolibarr_main_cache) peut être pointé vers Redis ou Memcached (beaucoup plus rapide que fichier) pour partager le cache entre les processus PHP.

  2. Base de données :

    • Passez à MariaDB 10.6+ ou MySQL 8.0 pour les améliorations de performances.

    • Ajoutez des index manquants sur les colonnes de WHERE, JOIN et ORDER BY fréquentes. La table llx_element_element (liens entre objets) est souvent mal indexée.

    • séparer les reads/writes : Si la charge est élevée, envisagez une réplication simple (un serveur principal pour écriture, un second pour lecture).

  3. Front-end & Réseau :

    • Minifiez et fusionnez les assets CSS/JS via le module dolibarr_压缩 ou en pré-production.

    • Activez la compression Gzip/Brotli sur le serveur web.

    • Configurez HTTP/2 (ou HTTP/3) pour réduire la latence des multiples requêtes parallèles.

    • Désactivez les modules Dolibarr inutiles depuis la page d’administration (Accueil -> Configuration -> Modules). Chaque module actif charge du code PHP et des assets.

  4. Paramètres Dolibarr spécifiques :

    • Dans conf.php, ajustez main_db_character_set et main_db_collation pour correspondre à votre DB (souvent utf8mb4).

    • Pour les listes longues, réduisez main_limit_size si besoin, mais attention aux impacts UX.

    • Désactivez le mode "debug" en production ($dolibarr_main_prod = 1;). Il alourdit considérablement les pages.

Étape 4 : Surveillance continue et alerting

Mettre en place un monitoring proactif est crucial pour anticiper les problèmes avant qu’ils n’affectent les équipes.

  • Stack simple : NetData ou Grafana + Prometheus + Node Exporter sur le serveur. Cela donne en temps réel : CPU, RAM, I/O disque, requêtes HTTP/s, processus PHP.

  • Alertes sur :

    • Temps de réponse 95e percentile HTTP > 2s.

    • CPU du serveur > 70% pendant 5 min.

    • Nombre de requêtes lentes en DB (> 5s) > 10/min.

    • Espace disque < 15%.

  • Utilisez les logs Dolibarr : Le fichier dolibarr.log (si activé) peut contenir des erreurs PHP fatales ou warnings.

Checklist rapide de diagnostic hybride

  • [ ] Test RUM depuis 3 réseaux différents (bureau, domicile, 4G).

  • [ ] Slow query log activé en DB, avec analyse hebdomadaire.

  • [ ] OPcache configuré et rempli à > 80% (opcache_get_status()).

  • [ ] Reverse proxy (Varnish/Nginx cache) en place avec règles de cache pour les pages anonymes ou peu dynamiques.

  • [ ] CDN configuré pour tous les assets statiques (dossier documents/, js/, css/).

  • [ ] VPN : Le trafic Dolibarr bénéficie-t-il de la priorité ? La bande passante est-elle suffisante ?

  • [ ] Version Dolibarr : Êtes-vous sur une version LTS stable (ex: 16.x) ? Les versions majeures apportent souvent des optimisations.

  • [ ] Modules inutiles désactivés.

  • [ ] Monitoring avec alertes sur les métriques clés.

Conclusion : La performance comme avantage compétitif

Pour les équipes hybrides, Dolibarr n’est pas qu’un outil : c’est le système nerveux de l’entreprise. Une plateforme lente génère de la frustration, des erreurs de saisie et une perte de temps colossale. Un diagnostic régulier, une comparaison objective des configurations (on-premise vs cloud) et l’application des optimisations cache/base de données sont non négociables.

En adoptant cette approche structurée, vous transformez Dolibarr d’un simple ERP en une plateforme agile et réactive, qui permet à vos équipes, où qu’elles soient, de se concentrer sur leur cœur de métier, et non sur l’attente d’une page qui se charge.

Article rédigé par un expert en infrastructure open source. Pour toute analyse approfondie (audit de logs, benchmark), consultez un intégrateur Dolibarr certifié.

Publications similaires