Vous ouvrez la liste des factures et il faut attendre dix secondes. Vous générez un rapport et le navigateur affiche un écran blanc avant de charger les données. Vous lancez une recherche produit et tout se fige pendant que la base de données moud les requêtes. Si ces situations vous parlent, votre instance Dolibarr souffre d'un problème de performances. Et dans plus de quatre-vingts pour cent des cas, le coupable n'est pas PHP ni le navigateur, mais bien la base de données MySQL ou MariaDB qui se trouve derrière votre ERP/CRM.

Une base de données mal configurée transforme un Dolibarr réactif en un outil que vos équipes finissent par contourner. Elles préfèrent retomber sur Excel, sur des notes manuscrites ou sur des outils tiers, et la promesse d'un système d'information unifié s'effondre. La bonne nouvelle, c'est que la grande majorité des problèmes de lenteur proviennent de causes connues, identifiables et corrigeables. Dans ce guide, NEXT GESTION partage cinq astuces techniques éprouvées sur des centaines d'instances Dolibarr de production, allant du commerçant à dix utilisateurs jusqu'à l'industriel à plusieurs centaines de connexions simultanées. Ces astuces couvrent la configuration du moteur, les indexes, la maintenance, les caches et l'architecture serveur. Appliquées correctement, elles peuvent diviser par trois, cinq, voire dix les temps de réponse de votre application.

Sommaire

1. Pourquoi Dolibarr ralentit avec le temps : comprendre les causes
2. Diagnostic préalable : mesurer avant d'optimiser
3. Astuce n°1 : Optimiser la configuration MySQL/MariaDB
4. Astuce n°2 : Travailler les indexes et la structure des tables
5. Astuce n°3 : Maintenance régulière de la base de données
6. Astuce n°4 : Activer et configurer les caches applicatifs
7. Astuce n°5 : Adapter l'architecture serveur à la charge
8. Optimisations spécifiques côté Dolibarr
9. Surveillance et monitoring continu
10. Erreurs classiques à éviter
11. Études de cas concrètes
12. Quand faut-il faire appel à un expert ?
13. FAQ : questions fréquentes sur les performances Dolibarr

1. Pourquoi Dolibarr ralentit avec le temps : comprendre les causes

Quand vous démarrez avec Dolibarr, l'application est rapide. Tout va vite, les pages s'affichent instantanément et l'expérience utilisateur est agréable. Six mois, un an ou deux ans plus tard, la même application met cinq, dix ou vingt secondes à afficher la même liste. Que s'est-il passé ?

Plusieurs phénomènes se cumulent. D'abord, le volume de données augmente : factures, propositions commerciales, commandes, mouvements de stock, écritures comptables, courriels archivés, fichiers attachés. Une table qui contenait dix mille lignes en compte désormais cinq cent mille, et certaines requêtes mal écrites passent d'une milliseconde à deux secondes. Ensuite, le nombre d'utilisateurs simultanés progresse à mesure que l'entreprise grandit, multipliant les connexions concurrentes et les verrous sur les tables. Les modules complémentaires installés au fil des besoins ajoutent leurs propres requêtes et leurs propres tables. Les indexes initialement présents ne suffisent plus pour les nouveaux usages. Le cache applicatif n'est pas activé ou est mal dimensionné. Enfin, la configuration MySQL livrée par défaut sur votre hébergement, conçue pour fonctionner sur un serveur de un gigaoctet de mémoire, n'a jamais été ajustée à la réalité de votre infrastructure.

Comprendre ces mécanismes est essentiel avant d'agir. La performance n'est pas un état statique mais un équilibre dynamique entre le volume de données, la charge utilisateur, la qualité du code, les indexes disponibles et les ressources matérielles allouées. Une optimisation efficace agit sur plusieurs de ces axes simultanément, et c'est précisément ce que nous allons détailler dans les cinq astuces qui suivent.

2. Diagnostic préalable : mesurer avant d'optimiser

La règle d'or de toute optimisation s'énonce simplement : on n'optimise pas ce qu'on ne mesure pas. Avant de modifier la moindre ligne de configuration, prenez le temps d'établir un diagnostic chiffré et reproductible de votre situation actuelle. Sans baseline, vous serez incapable de savoir si vos modifications ont apporté un gain réel ou si vous avez simplement déplacé le problème.

Commencez par identifier les pages les plus lentes du point de vue utilisateur. Les outils de développement intégrés à votre navigateur, accessibles par la touche F12, affichent le temps de chargement complet de chaque page, le temps passé sur le serveur et le temps de rendu côté client. Notez ces mesures pour cinq à dix actions critiques de votre quotidien : ouverture de la liste des factures, recherche client, génération d'un rapport, validation d'une commande, accès à la fiche d'un produit avec ses stocks. Ces chiffres constituent votre point de référence.

Activez ensuite le journal des requêtes lentes côté MySQL ou MariaDB, en fixant un seuil bas, par exemple une seconde. Ce journal capture toutes les requêtes qui dépassent ce délai et révèle immédiatement les goulets d'étranglement. Couplé à un outil d'analyse comme pt-query-digest ou mysqldumpslow, il classe les requêtes par temps cumulé, par fréquence et par temps moyen, vous indiquant exactement où concentrer vos efforts. Examinez également les statistiques globales du serveur : ratio de hit du cache InnoDB, ratio des connexions abandonnées, requêtes en attente de verrou, tables temporaires écrites sur disque. Ces indicateurs orientent immédiatement le diagnostic.

Côté Dolibarr, activez le mode debug dans la configuration et consultez le journal applicatif pour repérer les modules ou les hooks qui ajoutent du temps à chaque page. Mesurez la taille de votre base de données, la taille de chaque table principale et le nombre de lignes contenues. Une table de logs qui pèse plusieurs gigaoctets ou une table d'événements qui contient plusieurs millions de lignes est un signal d'alerte immédiat. Une fois ce panorama dressé, vous savez où vous en êtes et vous pouvez attaquer les optimisations en toute connaissance de cause.

3. Astuce n°1 : Optimiser la configuration MySQL/MariaDB

La configuration par défaut de MySQL ou MariaDB est l'un des leviers les plus rapides et les plus rentables pour gagner en performances. Elle est volontairement conservatrice, prévue pour fonctionner sur un serveur modeste sans risque de saturation mémoire. Sur un serveur dédié à Dolibarr disposant de huit, seize ou trente-deux gigaoctets de RAM, cette configuration laisse littéralement quatre-vingt-dix pour cent des ressources inutilisées.

Le paramètre le plus impactant est sans conteste la taille du buffer InnoDB. InnoDB est le moteur de stockage utilisé par toutes les tables Dolibarr modernes, et son buffer est la zone mémoire dans laquelle MySQL met en cache les pages de données et d'index. Plus ce buffer est grand, moins le serveur a besoin de lire le disque, et plus les requêtes sont rapides. La règle généralement admise consiste à allouer environ soixante-dix à quatre-vingts pour cent de la RAM totale du serveur à ce buffer si la machine est dédiée à la base de données. Sur un serveur mutualisé hébergeant aussi PHP et le serveur web, on descendra à cinquante ou soixante pour cent, en veillant à laisser suffisamment de mémoire au reste du système.

D'autres paramètres méritent un ajustement attentif. La taille du log InnoDB influence directement les performances en écriture : un log trop petit provoque des flush trop fréquents et ralentit les insertions massives. Le nombre de connexions maximales doit refléter la réalité de votre charge sans être démesuré, car chaque connexion consomme de la mémoire. Le tampon de tri, le tampon de jointure et le cache de tables temporaires doivent être adaptés à vos requêtes les plus complexes, sans pour autant être surdimensionnés au point de saturer la RAM en pic de charge. Le mode de flush des transactions InnoDB peut être ajusté en fonction de votre tolérance au risque : la valeur la plus sûre garantit la durabilité de chaque transaction au prix d'écritures disque plus nombreuses, tandis qu'une valeur intermédiaire offre un excellent compromis pour la plupart des PME.

Enfin, n'oubliez pas le moteur de cache de requêtes, désormais désactivé par défaut sur les versions récentes de MariaDB et carrément supprimé sur MySQL. Si vous êtes encore sur une version ancienne avec ce cache activé et que votre charge est majoritairement de l'écriture, il peut paradoxalement ralentir l'application. Un audit de configuration permet de déterminer précisément ce qui doit être activé, ajusté ou désactivé. NEXT GESTION pratique cet exercice systématiquement lors de ses interventions et fournit des fichiers de configuration adaptés à chaque taille d'instance.

4. Astuce n°2 : Travailler les indexes et la structure des tables

Si la configuration du moteur est le levier le plus rapide, les indexes sont le levier le plus puissant. Un index bien posé peut transformer une requête de cinq secondes en une requête d'un millième de seconde. À l'inverse, un index manquant sur une colonne fréquemment filtrée force la base à parcourir l'intégralité de la table, opération dont le coût explose à mesure que les données grossissent.

Dolibarr est livré avec un jeu d'indexes raisonnable couvrant les usages standards. Cependant, dès que vous ajoutez des modules tiers, des champs personnalisés ou des extensions développées sur mesure, ces indexes peuvent devenir insuffisants. Une recherche par référence interne sur la table des produits, un filtre par statut sur la table des factures combiné à un tri par date, une jointure entre deux tables filles d'un module additionnel : autant de scénarios où un index complémentaire fait la différence entre une expérience fluide et une expérience laborieuse.

L'identification des indexes manquants se fait à partir du journal des requêtes lentes et de l'outil EXPLAIN intégré à MySQL. EXPLAIN détaille la stratégie d'exécution choisie par le moteur pour chaque requête : utilisation d'un index, lecture séquentielle complète, jointure imbriquée, table temporaire en mémoire ou sur disque. Une requête qui affiche le mot ALL dans la colonne type ou plusieurs millions de lignes scannées est un candidat évident à l'optimisation. La création d'un index ciblé, parfois composite sur plusieurs colonnes dans le bon ordre, suffit alors à corriger le problème.

Attention toutefois à ne pas tomber dans l'excès. Chaque index a un coût en écriture : à chaque insertion, mise à jour ou suppression, MySQL doit mettre à jour les indexes concernés. Ajouter dix indexes sur une table très sollicitée en écriture peut dégrader les performances globales. La bonne pratique consiste à indexer ce qui est réellement utilisé, à supprimer les indexes redondants ou inutilisés, et à privilégier les indexes composites bien pensés plutôt qu'une multiplication d'indexes simples. Côté structure, vérifiez également que vos colonnes utilisent les bons types : un VARCHAR généreusement dimensionné consomme plus de mémoire de tri qu'un VARCHAR ajusté, un TEXT là où un VARCHAR suffit empêche certaines optimisations, un type DATE est toujours plus rapide qu'une date stockée sous forme de chaîne. Un audit de schéma par un expert Dolibarr permet de détecter ces points d'amélioration souvent invisibles depuis l'interface.

5. Astuce n°3 : Maintenance régulière de la base de données

Une base de données est un organisme vivant. Les insertions, mises à jour et suppressions successives fragmentent les pages, font enfler les indexes au-delà de leur taille optimale, désynchronisent les statistiques utilisées par l'optimiseur de requêtes et accumulent des données obsolètes que personne ne consulte plus jamais. Sans maintenance régulière, ces phénomènes finissent par dégrader sensiblement les performances, même sans aucune nouvelle activité métier.

La première opération de maintenance est la défragmentation des tables. Sur InnoDB, cette opération est réalisée par une commande qui reconstruit la table et ses indexes en récupérant l'espace libre, en réorganisant les pages et en réajustant la taille du fichier de données. Réalisée trimestriellement sur les tables principales, elle limite l'expansion artificielle de la base et préserve la localité des données, c'est-à-dire la proximité physique des lignes fréquemment lues ensemble. Les tables très sollicitées en écriture, comme la table des écritures comptables, la table des journaux ou la table des stocks, profitent particulièrement de cette défragmentation.

La seconde opération est la mise à jour des statistiques. L'optimiseur de MySQL choisit son plan d'exécution en se basant sur des statistiques estimant la cardinalité des indexes et la distribution des valeurs. Si ces statistiques sont obsolètes, l'optimiseur peut prendre des décisions absurdes, par exemple refuser d'utiliser un index parfaitement adapté parce qu'il pense que la table contient encore mille lignes alors qu'elle en a maintenant un million. La commande de mise à jour des statistiques, exécutée périodiquement, garantit que les plans d'exécution restent pertinents.

La troisième opération est l'archivage et la purge des données obsolètes. Les journaux applicatifs, les sessions expirées, les pièces jointes des courriels d'il y a cinq ans, les documents intermédiaires non validés, les rapports générés à la volée : autant de données qui occupent de la place sans valeur métier réelle. Une politique de rétention claire, documentée et automatisée permet de maintenir le volume sous contrôle. Sur certaines bases que NEXT GESTION a auditées, plus de soixante pour cent du volume était consacré à des données qu'aucun utilisateur ne consultait depuis des années. Une simple purge avec archivage hors ligne a permis de diviser par trois la taille de la base et d'accélérer mécaniquement toutes les opérations.

Enfin, n'oubliez pas la vérification d'intégrité. Une corruption silencieuse, même mineure, sur une table critique peut générer des comportements aberrants difficiles à diagnostiquer. Une vérification mensuelle des tables principales et un suivi des journaux d'erreurs MySQL préviennent les incidents avant qu'ils ne deviennent visibles côté utilisateur.

6. Astuce n°4 : Activer et configurer les caches applicatifs

La meilleure requête est celle qu'on n'exécute pas. Cette maxime résume parfaitement la logique du cache : conserver en mémoire le résultat d'opérations coûteuses pour les servir instantanément lors des requêtes suivantes. Dolibarr et son écosystème PHP offrent plusieurs niveaux de cache qui, correctement configurés, peuvent réduire drastiquement la charge sur la base de données.

Le premier cache à activer est l'opcache de PHP. Sans opcache, PHP relit, parse et compile chaque fichier source à chaque requête, consommant CPU et temps de manière significative. Avec opcache activé, le bytecode compilé est conservé en mémoire et réutilisé, ce qui peut diviser par deux le temps de réponse global de l'application. La configuration consiste à allouer suffisamment de mémoire pour stocker l'ensemble des fichiers de Dolibarr, à autoriser un nombre de fichiers cohérent avec la taille de votre installation et à ajuster les paramètres de validation pour éviter les vérifications inutiles en production. C'est une optimisation simple, gratuite et au gain quasi systématiquement spectaculaire.

Le deuxième niveau concerne le cache applicatif de Dolibarr lui-même. Plusieurs zones de l'application peuvent être mises en cache : les listes de pays, de devises, de types de paiement, de droits utilisateurs, les paramètres de configuration globaux, les traductions. Ces données sont lues à presque chaque page mais changent très rarement. Les conserver en mémoire évite des dizaines, voire des centaines de requêtes redondantes à chaque chargement. Selon les modules installés et la version utilisée, ces caches peuvent être activés via les paramètres avancés ou via des extensions dédiées.

Pour les instances à plus forte charge, il est pertinent d'aller plus loin avec un cache externe partagé entre les processus PHP. Des solutions comme Redis ou Memcached permettent de mettre en cache des résultats de requêtes complexes, des sessions utilisateur ou des objets métier reconstitués. Le gain est particulièrement net sur les tableaux de bord, les agrégations de chiffres et les pages chargées à la fois par de nombreux utilisateurs. La mise en place demande une configuration soignée, une stratégie d'invalidation rigoureuse et une supervision active pour garantir la cohérence des données affichées. C'est typiquement une intervention que NEXT GESTION accompagne de bout en bout sur les instances Dolibarr les plus exigeantes.

N'oublions pas le cache navigateur et le cache HTTP. Les ressources statiques de Dolibarr, comme les feuilles de style, les scripts JavaScript et les images, doivent être servies avec des en-têtes de cache appropriés pour éviter qu'elles ne soient retéléchargées à chaque page. Une configuration soignée du serveur web, complétée éventuellement par un CDN pour les déploiements multi-sites, allège la charge réseau et améliore la perception de rapidité côté utilisateur.

7. Astuce n°5 : Adapter l'architecture serveur à la charge

Toutes les optimisations logicielles du monde ne peuvent compenser un serveur sous-dimensionné ou une architecture inadaptée. À partir d'un certain volume de données, d'utilisateurs simultanés ou d'intégrations connectées, il devient nécessaire de revoir la fondation matérielle sur laquelle repose votre Dolibarr.

Le premier paramètre à examiner est la mémoire vive disponible. Une base de données performante a besoin de RAM en abondance, principalement pour le buffer InnoDB évoqué plus haut. La règle empirique consiste à viser une RAM totale au moins égale à la taille de la partie active de votre base, c'est-à-dire les tables et indexes que vous consultez régulièrement. Un serveur de huit gigaoctets pour une base de quinze gigaoctets active passera la moitié de son temps à lire le disque, quel que soit votre tuning. Augmenter la RAM est souvent l'investissement matériel le plus rentable.

Le second paramètre est le sous-système de stockage. Le passage d'un disque mécanique à un SSD divise généralement par dix les latences de lecture aléatoire, ce qui transforme l'expérience utilisateur sur les requêtes complexes. Le passage d'un SSD SATA à un SSD NVMe apporte un gain supplémentaire significatif sur les charges intensives en écriture. Sur les hébergements virtualisés, vérifiez la classe de stockage proposée et n'hésitez pas à monter en gamme si vos mesures pointent un goulet d'étranglement disque.

Le troisième paramètre concerne le CPU. Dolibarr et son moteur PHP sont sensibles à la fréquence d'horloge, encore plus qu'au nombre de cœurs, pour les requêtes individuelles. En revanche, sur les charges multi-utilisateurs, le nombre de cœurs devient déterminant pour absorber les requêtes en parallèle. Un audit de la charge moyenne, des pics et de la nature des opérations permet de choisir la bonne combinaison.

Au-delà du dimensionnement vertical d'une seule machine, il existe des architectures plus avancées pour les instances très sollicitées. La séparation du serveur web et du serveur de base de données sur deux machines distinctes répartit la charge et évite les conflits de ressources. La mise en place d'une réplication primaire-secondaire permet de décharger les requêtes de lecture lourdes vers une réplique tout en conservant les écritures sur le serveur principal. L'usage d'un proxy de connexion pour mutualiser les connexions PHP côté MySQL réduit la charge en pic. Ces architectures se justifient à partir d'un certain seuil de criticité ou de volumétrie et s'inscrivent dans une réflexion globale sur la haute disponibilité que NEXT GESTION conduit avec ses clients ETI et grands comptes.

Enfin, le réseau joue un rôle souvent sous-estimé. Une latence excessive entre le navigateur de l'utilisateur, le serveur web et le serveur de base de données dégrade considérablement l'expérience, surtout sur les pages qui multiplient les allers-retours. Un hébergement situé à proximité géographique de vos utilisateurs principaux et un réseau interne à faible latence entre les différentes briques de l'architecture font souvent la différence sur les workflows métier intensifs.

8. Optimisations spécifiques côté Dolibarr

Au-delà du moteur de base de données et de l'architecture, Dolibarr lui-même offre plusieurs leviers d'optimisation. La désactivation des modules inutilisés est probablement le plus simple et le plus efficace. Chaque module activé charge ses propres bibliothèques, exécute ses hooks à chaque page et consomme des ressources même si vous ne l'utilisez pas. Faire le tri des modules réellement nécessaires réduit le nombre de requêtes par page et accélère le chargement global.

La gestion des champs personnalisés mérite également une attention particulière. Un champ personnalisé mal conçu, par exemple une liste déroulante alimentée par une requête lourde sans cache, peut ralentir significativement chaque ouverture de fiche. Privilégiez les champs ciblés, les listes statiques quand c'est possible et les requêtes optimisées avec des indexes appropriés.

Les exports massifs et les rapports lourds doivent être pensés en termes d'impact système. Un export de cent mille lignes lancé en pleine journée par un utilisateur peut paralyser l'application pour tous les autres. La mise en place de files d'attente, de planification nocturne ou de génération en arrière-plan permet d'isoler ces opérations sans impacter l'expérience interactive.

Côté interface, certaines listes affichent par défaut des informations agrégées coûteuses à calculer, comme le total des factures en cours ou le stock valorisé d'un produit. Quand ces informations ne sont pas critiques pour l'usage quotidien, leur désactivation ou leur calcul à la demande allège le rendu de chaque ligne et accélère la navigation. NEXT GESTION accompagne ses clients dans la personnalisation fine de ces affichages pour aligner la performance sur les vrais besoins métier.

9. Surveillance et monitoring continu

Optimiser une fois ne suffit pas. Une instance Dolibarr évolue constamment : nouveaux utilisateurs, nouveaux modules, nouvelles données, nouveaux usages. Sans surveillance continue, les gains durement acquis se dégradent insidieusement. Mettre en place un monitoring permanent est donc une étape indispensable de toute démarche de performance durable.

Le monitoring couvre plusieurs axes. Au niveau système, on suit l'utilisation CPU, la mémoire libre, la latence et le débit du stockage, la charge moyenne et le nombre de processus actifs. Au niveau base de données, on surveille le ratio de hit du buffer InnoDB, le nombre de requêtes lentes par minute, les connexions actives, les verrous en attente et la taille des tables principales. Au niveau applicatif, on instrumente les pages les plus utilisées pour mesurer leur temps de réponse et détecter les régressions.

Ces métriques doivent être collectées dans un outil centralisé permettant de visualiser les tendances dans le temps, de définir des alertes sur dépassement de seuil et de corréler les événements. Des outils open source comme Prometheus avec Grafana, ou des solutions tout-en-un comme Zabbix ou les offres SaaS dédiées, permettent de mettre en place ce dispositif sans investissement démesuré. Un tableau de bord clair, consulté hebdomadairement, donne une vue d'ensemble de la santé de la plateforme et oriente les actions correctives.

Le suivi des incidents complète la photographie. Chaque ralentissement signalé par un utilisateur doit être consigné, daté, mis en relation avec les métriques système du moment et analysé. Avec le temps, des motifs émergent : le lundi matin sature toujours, la fin de mois alourdit la comptabilité, certains utilisateurs déclenchent des opérations atypiques. Cette connaissance fine du comportement réel de votre instance est précieuse pour anticiper plutôt que subir.

10. Erreurs classiques à éviter

Dans l'urgence d'un problème de performance, certaines tentatives bien intentionnées font plus de mal que de bien. La première erreur consiste à modifier plusieurs paramètres en même temps sans mesurer l'impact de chaque changement. Si la situation s'améliore, vous ne saurez pas lequel a fonctionné. Si elle se dégrade, vous serez incapable de revenir précisément en arrière. Toute modification doit être isolée, mesurée et validée avant de passer à la suivante.

La deuxième erreur est de copier-coller une configuration MySQL trouvée sur un blog sans la comprendre. Une configuration optimisée pour un serveur web à fort trafic n'a rien à voir avec une configuration adaptée à un ERP transactionnel. Un fichier de paramètres mal compris peut multiplier les bugs, saturer la RAM ou même empêcher le démarrage du service.

La troisième erreur est de surindexer. Devant des requêtes lentes, la tentation est d'ajouter un index sur chaque colonne mentionnée dans un WHERE. C'est rarement la bonne réponse. Un index bien pensé vaut mieux que dix indexes redondants, et chaque index ajouté pénalise les écritures.

La quatrième erreur est d'ignorer les sauvegardes avant intervention. Une optimisation, surtout sur les indexes ou la structure des tables, doit être précédée d'une sauvegarde complète, vérifiée et restaurable. Travailler sans filet sur une base de production est un risque que personne ne devrait prendre.

Enfin, la cinquième erreur est de sous-estimer l'effet d'apprentissage. Une optimisation produit son plein effet une fois que les caches sont chauds, que les statistiques sont à jour et que les utilisateurs ont retrouvé leurs habitudes. Mesurer l'impact dans la première heure peut donner une image trompeuse. Laissez tourner pendant plusieurs jours avant de tirer des conclusions définitives.

11. Études de cas concrètes

Pour ancrer ces principes dans la réalité, voici trois exemples tirés des interventions de NEXT GESTION, anonymisés mais fidèles aux situations rencontrées.

Premier cas, un négociant en matériel professionnel utilisant Dolibarr depuis cinq ans, avec une base de douze gigaoctets et environ vingt-cinq utilisateurs simultanés. Le diagnostic révèle un buffer InnoDB de cent vingt-huit mégaoctets, soit la valeur par défaut, sur un serveur disposant de seize gigaoctets de RAM. Première intervention : ajustement de la configuration MySQL avec un buffer porté à dix gigaoctets. Résultat immédiat, des temps de réponse divisés par trois sur l'ensemble des écrans. Deuxième intervention : analyse du journal des requêtes lentes et création de quatre indexes complémentaires sur des champs personnalisés très utilisés. Résultat, les rapports passent de douze secondes à moins de deux. Troisième intervention : purge de huit ans de logs applicatifs et de pièces jointes orphelines. Résultat, base réduite à cinq gigaoctets et sauvegardes deux fois plus rapides.

Deuxième cas, une PME industrielle gérant son MRP avec Dolibarr et plusieurs modules complémentaires. Les calculs de besoins prenaient plus de quarante minutes en pleine journée et bloquaient l'application. Le diagnostic identifie une combinaison de requêtes mal optimisées, d'absence d'indexes adaptés sur les tables d'éclatement de nomenclatures et d'opcache désactivé. Après refonte des requêtes critiques, ajout de cinq indexes ciblés et activation d'opcache, le calcul global tombe à quatre minutes et peut être lancé sans gêner les utilisateurs.

Troisième cas, un grossiste e-commerce avec un Dolibarr connecté à une boutique en ligne par un connecteur synchronisant en permanence stocks et commandes. Sous charge, l'application devenait inutilisable. Diagnostic : architecture mono-serveur saturée, absence de cache externe, requêtes répétitives sur des données peu variables. Mise en place d'une séparation du serveur web et de la base de données, ajout d'un cache Redis pour les listes de référentiels et optimisation des requêtes du connecteur. Résultat, une plateforme stable même en pleine campagne commerciale, avec des temps de réponse divisés par cinq.

12. Quand faut-il faire appel à un expert ?

Beaucoup d'optimisations sont à la portée d'un administrateur système ou d'un intégrateur Dolibarr expérimenté. Les ajustements de configuration, l'activation d'opcache, la mise en place d'un monitoring de base, le nettoyage des données obsolètes peuvent être conduits en interne avec un peu de méthode et de prudence.

Cependant, certaines situations justifient l'intervention d'un expert. Si vos mesures ne convergent pas vers une cause claire, si les optimisations habituelles ne produisent pas les gains attendus, si votre instance combine plusieurs modules complexes ou dépasse les volumétries courantes, l'expérience accumulée d'un spécialiste fait la différence. Un audit en profondeur identifie des points qu'un œil non entraîné peut manquer : un schéma de données non optimal, une requête PHP générant des centaines de sous-requêtes, un module tiers consommant des ressources disproportionnées, une configuration système incompatible avec la charge réelle.

NEXT GESTION accompagne ses clients à toutes les étapes de cette démarche. Audit de performance documenté, plan d'optimisation chiffré, mise en œuvre des corrections, formation des équipes internes au monitoring et au tuning continu, contrats de maintenance proactive. Notre méthode repose sur la mesure, la transparence et la transmission de compétences afin que vos équipes restent autonomes après notre intervention. Si votre Dolibarr ralentit et que vous voulez en avoir le cœur net, contactez-nous pour un diagnostic préliminaire.

13. FAQ : questions fréquentes sur les performances Dolibarr

Mon Dolibarr est lent uniquement sur certaines pages, faut-il quand même optimiser tout le serveur ? Non. Une lenteur ciblée pointe presque toujours vers un problème spécifique : requête mal écrite, index manquant, module particulier, calcul coûteux. L'analyse du journal des requêtes lentes et l'utilisation d'EXPLAIN suffisent souvent à identifier la cause. Une optimisation globale du serveur viendra dans un second temps si le diagnostic le justifie.

Combien de temps dure un audit de performance complet ? Pour une instance de PME standard, un audit complet incluant configuration MySQL, indexes, requêtes, architecture et code applicatif demande entre deux et cinq jours selon la complexité. Les conclusions sont restituées dans un rapport détaillé accompagné d'un plan d'action priorisé.

Faut-il mettre à jour Dolibarr pour gagner en performances ? Souvent oui. Chaque version majeure apporte son lot d'optimisations sur les requêtes les plus critiques, des indexes supplémentaires et parfois une refonte de modules complets. Migrer d'une version ancienne vers une version récente apporte généralement un gain mesurable, en complément des autres leviers d'optimisation.

Un hébergement mutualisé peut-il faire tourner Dolibarr correctement ? Pour une très petite structure avec quelques utilisateurs et peu de données, oui. Au-delà, les limites des hébergements mutualisés sur la mémoire MySQL, les processus PHP et la latence disque deviennent rédhibitoires. Un VPS dédié, même modeste, offre un bien meilleur rapport qualité-prix dès qu'on franchit le cap de quelques centaines de factures par mois.

Les performances dépendent-elles du nombre d'utilisateurs ou de la taille de la base ? Des deux, mais différemment. La taille de la base affecte la durée des requêtes individuelles et la pression sur le buffer InnoDB. Le nombre d'utilisateurs simultanés affecte la concurrence sur les verrous, la consommation CPU et la mémoire des processus PHP. Une optimisation efficace prend en compte ces deux dimensions.

Faut-il purger régulièrement les anciennes données ? Oui, à condition de respecter les obligations légales de conservation. Documents comptables, factures, déclarations doivent être conservés selon les durées légales applicables. En revanche, les logs techniques, les sessions, les fichiers temporaires et les pièces jointes obsolètes peuvent être archivés ou purgés sans risque, avec un gain de performance notable.

Le passage à PostgreSQL apporterait-il un gain ? PostgreSQL est un excellent moteur de base de données et Dolibarr peut tourner sur PostgreSQL. Le gain pur en performance n'est pas systématique : MySQL/MariaDB bien configuré reste très performant pour le profil de charge de Dolibarr. Le choix relève davantage de la stratégie d'infrastructure et des compétences disponibles que d'un avantage de performance évident.

Mes sauvegardes ralentissent toute l'application, que faire ? Une sauvegarde mal conçue verrouille les tables et bloque les utilisateurs. Privilégiez les outils qui sauvegardent à chaud sans verrouiller, planifiez les sauvegardes complètes en dehors des heures ouvrées, utilisez la réplication pour décharger les sauvegardes vers une réplique. Une stratégie de sauvegarde optimisée préserve à la fois la sécurité et la performance.

Article rédigé par NEXT GESTION, expert Dolibarr et accompagnement des entreprises sur l'optimisation, la sécurisation et l'évolution de leur ERP/CRM. Vous souhaitez auditer les performances de votre instance Dolibarr ? Contactez nos consultants : contact@nextgestion.com.