Dolibarr et e-commerce : erreurs fréquentes et solutions orienté performance

Version 2025 – Guide pratique pour optimiser la boutique en ligne de Dolibarr

1. Introduction Dolibarr est une solution ERP/CRM légère, mais très modulable, qui peut couvrir l’ensemble du besoin e‑commerce : catalogue, paiement, gestion des stocks, facturation et suivi des expéditions. Malgré sa simplicité d’utilisation, de nombreux professionnels rencontrent des goulots d’étranglement lorsqu’ils poussent le système à son maximum de charge (pic de trafic, catalogue de plusieurs dizaines de milliers de références, multi‑shop).

Cet article passe en revue les erreurs les plus récurrentes et propose des solutions concrètes orientées performance, afin de garantir un temps de réponse sous‑seconde même sous forte charge.

2. Configuration initiale – les bonnes pratiques dès le départ

Étape Action Pourquoi cela a un impact sur la performance
2.1. Utiliser la dernière version stable (≥ 19.0) avec le patch de sécurité HTTP/2 Les améliorations du core éliminent des requêtes bloquantes (ex. : réduction du nombre de redirects)
2.2. Déployer sur un serveur dédié ou un VPS avec SSD, RAM ≥ 4 Go et CPU ≥ 2 cœurs (voir tableau plus bas) Les accès disque et les calculs PHP sont souvent les premiers points de saturation.
2.3. Activer le mode système « apache2handler » ou php‑fpm avec un pool de processus adapté Le nombre de processus PHP doit suivre le trafic attendu (voir § 3.3).
2.4. Configurer le serveur MySQL/MariaDB en innodb avec buffer pool ≥ 50 % de la RAM et innodb_flushlog_at_trx_commit = 2 Accélère les lectures/écritures de la base de données (essentiel pour le paiement et le stock).
2.5. Mettre en place un cache HTTP (Varnish, Cloudflare) ou reverse‑proxy (NGINX) devant Dolibarr Réduit drastiquement les appels PHP pour les pages statiques (catalogue, comptes).

3. Erreurs fréquentes et leurs symptômes

3.1. Over‑configuration du module e‑commerce

Erreur Symptôme Conséquence
Activation inutile de tous les modules (ex. : “Languid”, “Multicurrency”, “PDF Invoice”) Charge CPU élevée même lorsqu’aucun client ne consomme Gaspi de ressources et temps de réponse ↑
Solution Désactiver modules inutilisés via le menu Modules → Gestion des modules Réduction de ~15‑30 % de la charge PHP.

3.2. Problèmes de configuration du serveur web

Erreur Symptôme Conséquence
Utilisation d’Apache avec .htaccess activé sur la racine Chaque requête déclenche de nombreux appels .htaccess Latence réseau + CPU
Timeout PHP (max_execution_time < 30 s) 504 Gateway Timeout sur paiement Panne des transactions en cours
Solution Passer à NGINX + php‑fpm avec fastcgi_read_timeout 300; et désactiver .htaccess Latence réduite, robustesse des paiements.

3.3. Mauvaise gestion du cache

Erreur Symptôme Conséquence
Cache opcache désactivé ou opcache.enable=0 Chaque page inclut de nouveaux require_once → surcharge du moteur PHP TPS ↑ de 200 ms à 800 ms sur catalogue
Aucun reverse‑proxy (Varnish/Redis) pour les pages catalogues Le même rendu HTML est généré à chaque visite Charge serveur proportionnelle au trafic
Solution Activer opcache (OPCache 3.2+) et configurer php.ini : opcache.memory_consumption=256, opcache.max_accelerated_files=20000; installer Varnish en front‑end et activer le cache d’HTML (Cache-Control: public, max-age=3600) Temps de réponse catalogue < 200 ms même sous 10 k RPM.

3.4. Gestion inadequée des stocks et des commandes

Erreur Symptôme Conséquence
Synchronisation asynchrone de la table llx_stock via plusieurs processus PHP simultanés Verrous de table, erreurs “deadlock” Baisse du débit d’import/export de stocks
Trigger excessif (ex. : llx_price_update à chaque modification) Temps d’insertion commande > 5 s Impact direct sur le taux de conversion
Solution Désactiver les triggers non‑essentiels en production; préférer jobs CRON nocturnes pour les recalculs de prix/poids; mettre en place un table de queue (RabbitMQ ou Redis) pour les insertions massives.

3.5. Problèmes de base de données | Erreur | Symptôme | Conséquence |

|——–|———-|————-|
| Utilisation du moteur MyISAM pour certaines tables (ex. : llx_user) | Verrouillage de table lors de l’ajout de panier | Pics de latence sous 500 RPS |
| Absence d’indexes sur les colonnes product_ref, order_date | Scans séquentiels = temps de requête ×5 | Latence élevé sur recherche produit |
| Solution | Convertir toutes les tables critiques en InnoDB; ajouter des indexes composés (INDEX idx_product_ref (entity_ref, rowid)); exécuter régulièrement ANALYZE TABLE. |

3.6. Serveur hors‑synchronisation avec le fuseau horaire

Erreur Symptôme Conséquence
Horloge serveur non‑NTP → calendriers de paiement & factures erronés Erreurs de facturation et re‑tentatives de paiement
Solution Synchroniser via systemctl enable --now chronyd ou ntpdate -u pool.ntp.org

4. Solutions orientées performance

4.1. Optimisation du code PHP

  1. Profiler avec Xdebug ou Blackfire

    • Identifier les fonctions appelées le plus souvent (ex. : getProductByRef() sur le catalogue).

    • Appliquer le micro‑caching : stocker le résultat HTML dans Redis (TTL 10 s) en cas de trafic similaire. 2. Réduire le nombre de require_once

    • Consolidation des fonctions communes dans un fichier autoload.php dédié au e‑commerce.

  2. Utiliser les fonctions natives plutôt que les loops personnalisés

    • array_column() au lieu de boucles manuelles pour extraire les prix. 4. Éviter les appels SQL inutiles

    • $db->fetch($res) plutôt que $db->query($sql)->fetchAll().

  3. Déplacer les traitements lourds en batch

    • Générer les fiches prix par cron toutes les heures au lieu d’en temps réel. ### 4.2. Architecture réseau Élément Configuration recommandée
      NGINX worker_processes auto;
      keepalive_timeout 65;
      PHP‑FPM pm.max_children = 30 (basé sur la RAM)
      pm.start_servers = 5
      Varnish backend default { .host = "127.0.0.1"; .port = "8080"; }
      TTL 3600
      Redis (cache) maxmemory 8gb + maxmemory-policy allkeys-lru
      MySQL innodb_buffer_pool_size = 4G (sur serveur 8 GB)

Astuce : si le serveur héberge plusieurs boutiques (multishop), utilisez socket Unix entre NGINX et PHP‑FPM pour réduire le passage par le réseau TCP.

4.3. Optimisation du schéma DB

-- Exemple d'index sur table de produits

CREATE INDEX idx_prod_ref ON llx_product (entity_id, ref);

CREATE INDEX idx_prod_cat ON llx_product (category);

ANALYZE TABLE llx_product;

  • Partitionnement de llx_order par année (PARTITION BY RANGE (year(order_date))) pour réduire la taille de chaque scan.

  • Compression des tables temporaires (ALTER TABLE llx_tmp ENGINE=InnoDB;) afin de diminuer l’I/O en cas de gros imports de commandes.

4.4. Gestion des paiements

  1. Externaliser le paiement via un gateway (Stripe, PayPal, Mollie) qui propose un iframe. Le trafic ne touche plus le serveur Dolibarr que pour la génération de la facture.

  2. Activer le mode « batch » de webhook : chaque webhook déclenche un script CRON dédié (php se/prop.php --process-payments) plutôt que d’appeler le code interne de Dolibarr.

4.5. Outils de monitoring en production

Outil Fonction Utilité
Prometheus + Grafana Métriques temps de réponse, erreurs 5xx Détection précoce des goulots.
New Relic (APM) Profilage de chaque route PHP Identifier rapidement les fonctions lentes.
Fail2Ban Bloque les IP avec trop de requêtes Limite les attaques DDoS et les scrapers.
php -d opcache.enabled=1 -r ‘print opcache_get_status();’ Stats OPCache temps réel Ajuste memory_consumption en fonction du taux d’utilisation.

5. Checklist de performance (à déployer en 30 minutes)

✔️ Action
1 Désactiver les modules inutiles (multilingue, PDF, etc.)
2 Activer OPCache & configurer memory_consumption ≥ 128 M
3 Passer le serveur web en NGINX + php‑fpm, désactiver .htaccess
4 Configurer Varnish (ou Cloudflare) pour mettre en cache les pages catalogue/
5 Ajouter des index sur llx_product.ref, llx_order.status
6 Convertir toutes les tables critiques en InnoDB
7 Vérifier innodb_buffer_pool_size = 50 % de la RAM
8 Redémarrer les services : systemctl restart nginx php-fpm mysql
9 Lancer un test de charge (ab -n 5000 -c 100 http://shop.example.com/)
10 Analyser le temps moyen de réponse < 300 ms et ajuster le pool PHP si nécessaire
11 Activer le monitoring (Prometheus) et mettre en place des alertes sur 5xx_error_total
12 Scheduler un Cron de nettoyage des sessions (php -f /path/to/dolibarr/cron.php clean_sessions)

6. Conclusion

Dolibarr est une plateforme e‑commerce robuste, mais sa performance dépend fortement de l’optimisation de l’infrastructure et de la gestion fine des dépendances.

  • Prioriser la désactivation des modules superflus, le cache (opcache + Varnish) et la configuration DB (InnoDB, index, buffer pool).

  • Séparer les traitements lourds (calculs de prix, batch de stock) du flux transactionnel grâce aux cron et aux queues.

  • Monitorer en continu pour anticiper les pics et ajuster les ressources avant que les utilisateurs ne perçoivent un ralentissement.

En appliquant les correctifs présentés dans cet article, votre boutique Dolibarr pourra supporter plusieurs dizaines de milliers de requêtes par minute sans sacrifier la latence, tout en conservant la simplicité d’administration qui fait la force de la solution.

🚀 Bonne optimisation !

Sources complémentaires : – Documentation officielle Dolibarr : https://www.dolibarr.org/doc/en_US/

  • Blog « Performance Dolibarr » – article 2024 « Optimiser le cache HTTP avec Varnish »

  • Guide MySQL Performance (Percona) – chap. 4 sur innodb_* parameters.

Publications similaires