Dolibarr et migration : erreurs fréquentes et solutions orienté performance

Une analyse détaillée pour accompagner les responsables IT, consultants et chefs de projet dans leurs transitions sans accroc.

1. Introduction

Dolibarr est un ERP/LPG (Gestion de Entreprise) open‑source qui, grâce à sa modularité, séduit de nombreuses PME et projets communautaires. Lorsqu’il s’agit de faire évoluer l’environnement—mise à jour de version, migration d’une base de données, passage du serveur local au cloud, ou même migration depuis un autre ERP—la performance devient un paramètre décisif.

Cet article passe en revue :

  • Les scénarios de migration les plus fréquents.

  • Les erreurs les plus récurrentes qui impactent la vitesse et la stabilité.

  • Des solutions concrètes, orientées performance, pour éviter les ralentissements et garder Dolibarr fluide.

Objectif : Vous fournir un guide opérationnel que vous pourrez appliquer immédiatement, même si vous avez peu d’expérience en administration de bases de données.

2. Scénarios classiques de migration

Scénario Pourquoi le réaliser ? Principaux défis de performance
Mise à jour de version (ex. 13.x → 20.x) Nouvelles fonctionnalités, corrections de bugs, support PHP 8.x Compatibilité des modules, migration de schémas SQL, changement de configuration PHP.
Migration de base de données (MySQL → MariaDB / PostgreSQL) Optimisation du SGBD, conformité légale (licence), amélioration de la réplication. Mapping des types de données, index manquants, conversion de caractères (utf8 ↔ utf8mb4).
Passage d’un serveur dédié à du cloud (AWS, Azure, OVH, etc.) scalabilité, réduction CAPEX, meilleure disponibilité. Latence réseau, mauvaise configuration du réseau (NACL, SG), sous‑dimensionnement des instances.
Migration d’un ERP tiers → Dolibarr centraliser la comptabilité, les contacts, les stocks. Mapping des objets (clients/fournisseurs → contacts), migration des pièces jointes, gestion des droits d’accès.
Déploiement multi‑site avec réplication Offrir une même instance à plusieurs succursales. Conflits de données, réplication asynchrone mal paramétrée, conflits de version de modules.

Note : Chaque scenario requiert une préparation différente mais partage des points communs (sauvegarde, tests, monitoring, optimisation des ressources).

3. Erreurs fréquentes qui nuisent à la performance

3.1. Oublier les index sur les colonnes fréquemment interrogées

  • Cas typique : Table factures sans index sur date_created ou status.

  • Impact : Sélections de factures sur plusieurs dizaines de milliers de lignes se traduisent par des SELECT ... WHERE qui font plusieurs scans de table (O(N)).

  • Symptôme : Temps de réponse qui augmente de quelques dizaines de millisecondes à plusieurs secondes dès le démarrage du premier chargement.

3.2. Utilisation de PHP 7.x/8.x sans adapter les paramètres opcache

  • Cas typique : Passage à PHP 8.1 sur un serveur qui utilise encore le cache de bytecode désactivé.

  • Impact : Le chargement des scripts PHP devient 3‑5 fois plus lent.

  • Symptôme : Temps de réponse du formulaire d’édition d’un client qui passe de 0,2 s à > 1 s.

3.3. Ne pas optimiser les requêtes (SELECT * , pas de LIMIT)

  • Cas typique : Export des contacts pour un rapport sans limiter les colonnes.

  • Impact : Charge réseau inutile, consommation mémoire du serveur web.

  • Symptôme : Pics CPU sur le serveur Apache pendant l’export.

3.4. Migration de base de données sans re‑indexation post‑migration

  • Cas typique : Passage d’un dump MySQL à un serveur MariaDB avec innodb_buffer_pool_size inchangé.

  • Impact : Le taux d’insertion/lecture chute de 50 % à 30 % parce que le buffer pool ne reflète pas la taille réelle des données.

  • Symptôme : Temps d’insertion de factures qui augmente de 200 ms à 600 ms.

3.5. Configurations file system inadaptées (permissions, SELinux, AppArmor)

  • Cas typique : Chmod 777 sur les répertoires www sans stratégie de confinement.

  • Impact : Le processus PHP se voit refuser l’accès aux répertoires de cache, forçant des retries coûteuses.

  • Symptôme : Erreurs 500 qui se traduisent par des temps de rechargement intermittents.

3.6. Utilisation d’un stockage de fichiers inapproprié (local au lieu de NFS/GlusterFS)

  • Cas typique : Gestion des pièces jointes stockées sur le disque du serveur web.

  • Impact : Réplication multi‑site entraîne des conflits et des latences d’écriture.

  • Symptôme : Temps de sauvegarde de documents qui passe de 2 s à > 10 s.

3.7. Absence de monitoring et de alertes

  • Cas typique : Aucun tableau de bord sur la latence des requêtes SQL.

  • Impact : Un problème de mauvaise indexation reste passé inaperçu jusqu’à ce que les utilisateurs signalent des retards.

  • Symptôme : Dépérioration progressive de la performance sans cause évidente.

4. Solutions orientées performance (check‑list pratique)

4.1. Optimisation des Index

  1. Identifier les requêtes lentes : Activez le slow_query_log de MySQL/MariaDB ou utilisez pg_stat_statements en PostgreSQL.

  2. Ajoutez les index ciblés : 
    CREATE INDEX idx_factures_date ON llx_facture (date_created);
    
CREATE INDEX idx_factures_status ON llx_facture (status);

  3. Analysez régulièrement : ANALYZE TABLE ou VACUUM ANALYZE.

  4. Utilisez les covering indexes** lorsqu’une requête ne récupère que des colonnes déjà indexées.

4.2. Paramétrage du serveur Web (Apache/Nginx)

Directive Valeur conseillée utilité
KeepAlive On 100 (ou selon le trafic) Réduit le nombre de handshakes TCP.
worker_processes auto (ou $(nproc)) Utilise tous les cœurs CPU.
Timeout 300 (pour les longues importations) Empêche les coupures prématurées.
php-fpm pm.max_children 2 * cores + 1 Adequate capacité de traitement PHP.
php-fpm request_terminate_timeout 300s Durée maximale d’un script long.

4.3. Configuration PHP (OPcache + APCu)

; OPcache

opcache.enable=1

opcache.memory_consumption=256

opcache.max_accelerated_files=20000

opcache.revalidate_freq=0   ; en dev, on veut re‑chargement immédiat

opcache.validate_timestamps=1 ; obligatoire en prod
; APCu pour le cache de drivers

apc.enabled=1

apc.shm_segments=1

apc.shm_size=64M

apc.ttl=7200

  • Pourquoi : OPcache réduit le temps de compilation de chaque script de ~30 ms à < 5 ms, doublant le débit des requêtes simultanées.

4.4. Optimisation de la Base de Données

Action Réglage recommandé Impact
innodb_buffer_pool_size 60‑80 % de la RAM si serveur dédié DB Plus de pages en mémoire → moindres I/O disque.
max_connections Calculé en fonction du pic : 2 * nb_clients Évite les files d’attente.
query_cache_type=0 (MySQL 5.7) Évite la fragmentation et le coût d’actualisation.
prepared_stmt_precompute = 1 Réduit le temps de parsing des requêtes préparées.
tmp_table_size / max_heap_table_size 64 M ou plus selon les tailles de temp tables. Diminue le recours à disk‑based temp tables.

4.5. Migration de fichiers attaché

  • Option 1 : Utiliser un Stockage externe (S3 compatible, NFS, MinIO).

    • Configurez Dolibarr → Fichier → Document Path → « URL extern ».

    • Avantages : Scalabilité, transfert CDN, sauvegarde indépendante.

  • Option 2 : Réplication de répertoires via rsync + inotify pour les environnements on‑prem.

    • Limitez la taille maximale des pièces jointes (document_max_size = 10M).

  • Performance : En servir les fichiers via HTTP/2 avec compression gzip (déjà supportée par la plupart des serveurs Nginx) et expires 1y.

4.6. Gestion des sessions & Cache

Technique Mise en place Bénéfice
Database Session Handler session.save_handler = user avec table dolibarr_sessions. Évite le file lock de session.save_path lorsqu’on a plusieurs serveurs web.
Redis/Memcached pour le cache de sessions session.save_handler = redis (extension php‑redis). Latence de < 1 ms, capacité de plusieurs millions de sessions.
Cache d’objets (PECL memcached) Utiliser dolibarr intégré dolibarr_cardboard pour mettre en cache les listes de contacts. Réduction du nombre de requêtes SQL de 30‑70 %.

4.7. Stratégie de Testing de charge

  1. Créer un scénario réaliste avec JMeter ou Locust : 500 utilisateurs simultanés, 30 % de requêtes d’édition factures, 20 % d’import de contacts.

  2. Mesurer le temps de réponse moyen (RT) et le débit (RPS) avant et après optimisation.

  3. Analyser les « slow transactions » : identifier les requêtes au-dessus du 95ᵉ percentile.

  4. Appliquer un plan d’optimisation (index, paramètres PHP, réplication).

  5. Re‑tester jusqu’à ce que le SLA (ex. < 200 ms pour 95 % des requêtes) soit atteint.

5. Guide de migration version‑à‑version (exemple : 13 → 20)

Étape Action Check‑list performance
0. Backup mysqldump --single-transaction --quick + copie du répertoire document_root. Vérifier l’intégrité du dump (checksum).
1. Pré‑install Déployer la version cible sur un serveur de test avec PHP 8.2 et MariaDB 10.6. Activer OPcache, définir max_execution_time = 300.
2. Mapper les tables Utiliser le script upgrade.php fourni. Exécuter le script avec --dry-run puis mesurer le temps d’exécution (≈ 5 s pour ~50 k lignes).
3. Indexation post‑upgrade ANALYZE TABLE llx_* et création d’index custom. Re‑générer le cache de statistiques (SELECT /*+ ANALYZE */ …).
4. Test de charge Simuler 1000 requêtes simultanées d’édition client. Le temps moyen doit rester ≤ 150 ms ; sinon, ajuster innodb_log_buffer_size.
5. Mise en production Planifier le basculement pendant une fenêtre de faible trafic. Monitoring en temps réel (Grafana + Prometheus).

6. Bonnes pratiques transversales

  1. Documenter chaque migration : script de restauration, checksum des tables, version de PHP/SQL.

  2. Séparer les environnements : dev, staging, prod. Chaque migration part doit être testée dans staging avant prod.

  3. Automatiser les changements de configuration : Utilisez Ansible ou Terraform pour définir les paramètres php.ini et my.cnf.

  4. *Limiter les appels « SELECT »** : Exportez uniquement les champs nécessaires via le moteur de recherche de Dolibarr ($db->fetchObject).

  5. Pré‑charger les caches (dolibarr_cache_rebuild) après chaque import important pour éviter des délais de récurrence.

  6. Surveiller le taux d’erreurs 504 (gateway timeout) : Si les temps dépassent le proxy_read_timeout, prolongez-le ou allégez les requêtes.

  7. Utiliser le mode "maintenance"** pendant les gros imports : Bloquer les nouveaux accès via $_SERVER['REQUEST_METHOD'] !== 'GET'.

7. Conclusion

Migrer Dolibarr ne doit pas être perçu comme une simple opération de transfert de fichiers. La performance est le fil conducteur qui relie chaque étape :

  • Vous devez anticiper les index et les requêtes qui seront les plus fréquentées.

  • Vous devez adapter la stack technologique (PHP, OPcache, serveur web, SGBD).

  • Vous devez choisir le mode de stockage (local vs externe) et le format de sauvegarde (dump, rsync).

  • Et surtout, vous devez mesurer avant, pendant et après la migration avec des outils de monitoring pour valider que les gains attendus sont bien réels.

En suivant la checklist présentée ci‑dessus – des erreurs fréquentes aux solutions orientées performance – vous pouvez réalisé vos migrations Dolibarr sans perte de vitesse, avec une stabilité garantie et scalable pour les prochains besoins.

Prochaine étape : Implémentez immédiatement le script d’analyse des requêtes lentes sur votre serveur de production, ajustez les paramètres de cache OPcache et planifiez un test de charge avant la prochaine mise à jour majeure. Vous constaterez rapidement que les gains de latitude sont réels et que la perception de Dolibarr comme “lent” disparaît dès que les bonnes pratiques sont appliquées.

Bonne migration ! 🚀

Publications similaires