Dolibarr : améliorer les performances (cron, base de données) + nettoyage + monitoring
Dolibarr devient rarement lent “d’un coup” : c’est presque toujours un cumul (tâches planifiées qui s’empilent, base qui grossit, fichiers de documents, logs, emails, cache, etc.). La bonne nouvelle : en appliquant une méthode simple (mesurer → corriger → surveiller), on récupère vite une application fluide, stable et prévisible.
Si vous cherchez un hébergement prêt pour la production (HTTPS, sauvegardes, scaling CPU/RAM, rétention longue), jetez un œil à adgents.cloud pour Dolibarr.
1) Diagnostiquer avant d’optimiser (sinon on se trompe de combat)
Avant de modifier quoi que ce soit, identifiez où le temps est consommé :
- Front : pages lourdes (listes, recherches), lenteurs ponctuelles, lenteurs sur PDF / emails.
- Serveur web / PHP : saturation CPU, temps de réponse long, files d’attente PHP-FPM.
- Base de données : requêtes lentes, verrous, tables qui gonflent, index manquants, buffer insuffisant.
- Tâches planifiées : jobs en double, jobs trop fréquents, jobs bloqués, exécutions longues.
Actions rapides utiles :
- Activez un slow query log côté MariaDB/MySQL (même temporairement).
- Surveillez la latence DB et le nombre de connexions en pointe.
- Vérifiez la santé du stockage (I/O) : sur un disque trop lent, aucune optimisation SQL ne “sauvera” la situation.
Pour poser une base propre côté déploiement (HTTPS, volumes, bonnes pratiques), vous pouvez repartir de ce guide : Installer Dolibarr avec Docker Compose (HTTPS + sauvegardes).
2) PHP et serveur : les gains les plus simples (OPcache, workers, limites)
Si votre instance est sous PHP-FPM, 3 leviers font souvent la différence :
- OPcache activé (indispensable)
- Vérifiez qu’il est bien actif en prod. Sans OPcache, chaque requête recompile des scripts → temps CPU inutile.
- Dimensionner les workers
- Trop peu de workers : ça “queue”, tout devient lent.
- Trop de workers : vous saturez la RAM → swap → catastrophe.
- Limiter les gros traitements
- Génération de PDF, import/export et emails peuvent monopoliser PHP. Quand possible, poussez ces traitements vers des jobs planifiés bien contrôlés.
Sur adgents.cloud, vous pouvez ajuster CPU/RAM à la demande pour absorber un pic (facturation à l’heure) et revenir ensuite à un dimensionnement nominal.
3) Base de données : stabilité, index et entretien
Dans beaucoup de cas, Dolibarr “rame” parce que la base a grandi sans entretien : historiques, logs, documents, pièces jointes, etc.
A) Réglages DB qui comptent (sans sur-optimiser)
- Buffer InnoDB suffisamment grand : si le serveur a de la RAM, il faut la donner à InnoDB (sans tuer le reste).
- Disque : une DB sur stockage lent se sent immédiatement (surtout en listes et recherches).
- Connexions : trop de connexions concurrentes + requêtes lentes = effet domino.
B) Requêtes lentes : corriger ce qui se voit
- Lisez les requêtes lentes et cherchez :
- filtrages sur colonnes non indexées
- tris sur de gros volumes
- jointures non sélectives
- Appliquez ensuite des corrections ciblées (index, réglages, ou parfois nettoyage de données).
C) Entretien régulier
- Vérifiez l’état des tables et l’évolution des volumes.
- Planifiez un entretien DB (selon votre moteur et votre politique) et surtout testez l’impact en heures creuses.
4) Cron Dolibarr : éviter les jobs fantômes et les exécutions qui s’empilent
Quand les tâches planifiées sont mal gérées, les symptômes typiques sont :
- ralentissements “par vagues”
- emails en retard
- actions automatiques qui partent en double
- pics CPU à heures fixes
Bonnes pratiques :
- Une seule source de planification : évitez d’avoir plusieurs cron qui lancent la même chose (ex : doublon entre système et interface).
- Verrouillage : assurez-vous qu’un job ne peut pas démarrer si le précédent n’a pas terminé.
- Fréquence raisonnable : certains jobs n’ont pas besoin de tourner toutes les minutes.
- Logs exploitables : loggez durée, statut, et erreurs (sinon vous “devinez” dans le noir).
Astuce : si vous utilisez des automatisations externes, vous pouvez aussi orchestrer certains traitements via n8n — voir : Connecter Dolibarr à n8n (sync prospects, factures, emails).
5) Nettoyage : ce qui fait grossir Dolibarr (et comment le maîtriser)
Le nettoyage n’est pas glamour, mais c’est un levier énorme :
- Documents : pièces jointes, PDFs, exports, scans…
- Logs : applicatifs, emails, erreurs, traces de debug.
- Historique : événements, actions, tracking interne (selon modules).
Stratégie simple :
- Définir une politique de rétention (ex : 12–24 mois pour certains journaux).
- Automatiser l’archivage ou la purge (en heures creuses).
- Mesurer l’impact (DB + stockage).
Si vous n’êtes pas à l’aise avec les purges (risque métier), commencez par du soft cleanup : compresser/archiver les logs, déplacer des exports, mieux séparer stockage documents et DB, etc.
6) Monitoring : l’assurance-vie des performances
Sans surveillance, vous allez subir des lenteurs au lieu de les anticiper. Un monitoring minimal doit suivre :
- CPU/RAM (dont swap)
- latence disque
- temps de réponse HTTP (p50/p95)
- temps de requêtes DB et requêtes lentes
- durée des jobs planifiés + taux d’échec
L’objectif : repérer tôt un indicateur qui dérive (ex : un job qui passe de 30s à 5 min) avant que les utilisateurs ne se plaignent.
7) Hébergement : quand scaler plutôt que bricoler
Certaines lenteurs sont “structurelles” : un pic de facturation, clôture comptable, import massif, génération d’un lot de documents…
Dans ces cas-là, le bon move est souvent :
- Scaler temporairement CPU/RAM
- Lancer les traitements
- Puis revenir au dimensionnement normal
C’est exactement l’intérêt d’une plateforme comme adgents.cloud :
- déploiement rapide
- scaling à la demande
- sauvegardes automatiques (jusqu’à 1/h)
- rétention longue
- stop/start (compute non facturé à l’arrêt)
Et pour compléter côté sécurité (qui impacte aussi la stabilité), ce guide est un bon compagnon : Sécuriser Dolibarr (mises à jour, permissions, sauvegardes, reverse proxy).
Vidéo (FR) : Dolibarr en pratique
Pour une prise en main (et voir les écrans avant d’optimiser), voici une vidéo en français : 
Conclusion
Pour remettre Dolibarr d’aplomb, ne cherchez pas “la” optimisation magique :
- rendez les jobs planifiés fiables
- stabilisez la base (requêtes lentes + entretien)
- contrôlez la croissance des données
- surveillez en continu
Si vous voulez une base d’hébergement solide (prod, sauvegardes, scaling), démarrez ici : Héberger Dolibarr sur adgents.cloud.