Par [Nom du formateur/consultant] – 2 novembre 2025
1. Contexte et problématique
Le secteur du BTP (Bâtiment, Travaux Publics) requiert des outils de gestion très spécifiques : suivi des devis, factures, chantier, sous‑traitants, stocks de matériaux, planning d’intervention, facturation au mètre carré, conformité légale…
Dolibarr, solution ERP‑CRM open‑source, est souvent adoptée par les PME du BTP pour son côté « modulaire » et sa facilité de paramétrage. Cependant, dans des environnements où les volumes deDocuments (devis, factures, notes de commande, rapports d’intervention) dépassent régulièrement 10 000 – 30 000 enregistrements par mois, deux phénomènes apparaissent :
| Symptomes typiques | Conséquences business |
|---|---|
| Temps de réponse > 5 s sur les listes de devis | Décision lente, perte de revenus |
| Erreurs de synchronisation entre stocks et facturation | Surcoûts, litiges clients |
| Utilisation abusive du serveur (CPU > 85 %, I/O > 70 %) | Instabilité, besoin de scaling coûteux |
Le besoin de diagnostiquer ces dysfonctionnements avant d’effectuer des actions d’optimisation devient donc une première étape cruciale.
2. Présentation de Dolibarr dans le BTP
| Module | Fonction BTP | Exemple d’usage |
|---|---|---|
| Facture | Génération PDF à partir des devis | Fatture client après réception des travaux |
| Stocks | Gestion des matériaux (ciment, béton, ferraille) | Vérification du stock restant avant lancement d’un chantier |
| Contracts | Suivi des sous‑traitants et délais | Contrat de sous‑traitance avec échéancier |
| Interventions | Planning des équipes sur site | Affectation de techniciens sur 3 chantiers simultanés |
| CRM | Suivi des prospects et devis | Conversion de devis en contrat |
Chaque module repose sur la même base de données MySQL/MariaDB et partage des tables de liaison (ex. asso_user_plugin, llx_pdfmodel).
— ## 3. Objectifs de la démarche de performance
- Quantifier les temps de réponse des écrans clés (liste des devis, génération de facture, mise à jour de stock).
- Identifier les goulots d’étranglement (SQL, PHP, I/O, cache).
- Déployer des correctifs ciblés tout en conservant la conformité légale du BTP (ex. archivage des factures 10 ans).
- Mesurer l’impact post‑optimisation via des KPI (latence, coût serveur, satisfaction utilisateur).
4. Équipement diagnostique utilisé
| Outil | Rôle | Métriques clés |
|---|---|---|
| APM – Grafana + Prometheus | Surveillance temps réel du serveur PHP‑FPM | request_duration_seconds, php_fpm_active_processes |
| MySQLTuner / PerfSchema | Analyse requêtes SQL lentes | slow_queries, handler_read_next |
| XDebug Profiler (ou Tideways) | Profilage PHP ligne par ligne | cpu_time, memory_usage |
| iostat / vmstat | Overlay I/O et mémoire du système | await, %util |
| Apache ab / Siege | Tests de charge HTTP | Requests per second, Transfer rate |
| SQL EXPLAIN ANALYZE | Compréhension du plan d’exécution | type, possible_keys, rows |
Ces outils ont permis de capturer des traces avant, pendant et après les interventions d’optimisation.
— ## 5. Étapes de diagnostic détaillées
5.1. Capture des temps de réponse de base
- Scénario : 50 utilisateurs simultanés effectuant une recherche de devis (critère : chantier).
- Résultat : Temps moyen 7,2 s ; 95 ème percentile = 12 s.
5.2. Analyse des requêtes MySQL
- Requête lente identifiée (
llx_assignmentsqlsur la tablellx_c_contract) : 2 s d’exécution,EXPLAINmontrant un scan d’index sur 180 000 lignes. - Action : Création d’un index composite
(fk_soc_id, date_start)→ temps réduit à 0,12 s.
5.3. Profilage PHP
- Hotspot :
function getStockLevel()appelé 12 000 fois dans la génération d’un devis. - Analyse Tideways : 68 % du CPU passé dans la boucle
foreachsur le tableau$_SESSION['basket']. - Solution : Passage d’un tableau associatif à un Mapping via
splObjectStorageet mise en cache (OpCache).
5.4. I/O et cache disque – iostat : await de 14 ms sur /var/lib/mysql pendant les pics de charge (10 % de util).
- Observation : Le fichier de log
error.logcroît de 5 Mo par heure → besoin de rotation et de purge. - Optimisation : Passage du stockage des logs vers tmpfs + rotation daily avec
logrotate.
5.5. Configuration du serveur PHP‑FPM
- Paramètres :
pm.max_children = 15,pm.start_servers = 5. - Test de charge : Augmentation à
pm.max_children = 30a permis d’atteindre 150 req/s sans dépassement de RAM (2 GB).
6. Étude de cas détaillée
6.1. Présentation du client
| Caractéristique | Valeur |
|---|---|
| Société | BTP &Co, PME de 35 personnes |
| Volume facturations | 12 000 factures / an |
| Déploiement | 2 serveurs (Web & DB) – VM 4 vCPU / 8 GB RAM chacun |
| Environnement | Debian 12, Apache 2.4, PHP 8.2, MariaDB 10.6 |
6.2. Besoin fonctionnel critique – Génération instantanée de factures PDF pour les chantiers à terme. – Requête de stocks en temps réel pour éviter les ruptures sur les chantiers en cours.
6.3. Diagnostic (avant correction)
| KPI | Avant | Après (cible) |
|---|---|---|
| Temps moyen génération facture PDF | 6,8 s | ≤ 1,2 s |
| Latence de recherche devis | 7,2 s | ≤ 1,5 s |
| Utilisation CPU serveur Web (peak) | 92 % | ≤ 55 % |
| Erreurs “500 Internal Server Error” mensuelles | 8 | 0 |
6.4. Actions correctives réalisées
| Action | Méthode | Résultat |
|---|---|---|
Ajout d’index sur llx_contract (fk_soc_id, date_start) |
CREATE INDEX idx_contract_date ON llx_contract (fk_soc_id, date_start); |
Temps requête ↓ 90 % |
Refactorisation de getStockLevel() avec cache OpCache + array_merge |
Utilisation de array_column() |
CPU ↓ 45 % |
| Injection de Prepared Statements dans les modules de facturation | mysqli_prepare() |
Sécurité + performance |
| Passage du moteur de PDF à TCPDF avec optimisation « Enableohno » | Désactivation du complétion automatique des glyphes | Temps PDF ↓ 35 % |
| Re‑tuning de PHP‑FPM (max_children = 30, request_terminate_timeout = 30s) | /etc/php/8.2/fpm/pool.d/www.conf |
RPS ↑ 2,5× |
Rotation et compression des logs via logrotate + gzip |
/etc/logrotate.d/dolibarr |
I/O disque ↓ 70 % |
6.5. Résultats post‑optimisation
| KPI | Valeur après |
|---|---|
| Temps moyen génération facture PDF | 1,1 s |
| Latence de recherche devis | 1,3 s |
| Utilisation CPU (peak) | 48 % |
| Erreurs 500 | 0 (sur 30 jours) |
| Coût serveur (VM) | Identique (pas de scaling) |
7. Bonnes pratiques à retenir pour le BTP | Domaine | Recommandation |
|———|—————-|
| Modélisation DB | Créer index composés sur les colonnes de jointure fréquentes (fk_*, date_*). |
| Code PHP | Limiter les boucles imbriquées sur de gros tableaux ; privilégier les fonctions natives (array_column, array_map). |
| Mise en cache | Activer OpCache et APCu pour les fonctions de stock; envisager un Redis comme cache de session lorsqu’un nombre d’utilisateurs > 200. |
| Génération PDF | Utiliser des bibliothèques légères (TCPDF, Dompdf) avec désactivation des fonctionnalités inutilisées; placer les PDFs générés dans un répertoire dédié avec compression gzip. |
| Gestion des logs | Rotations quotidiennes + compression ; rediriger les logs vers tmpfs ou elastic si le volume dépasse 200 Mo/jour. |
| Scalabilité | Configurer pm.max_children en fonction du nombre de cœurs et de la RAM disponible; prévoir un load‑balancer (HAProxy) dès 100 concurrent users. |
| Monitoring continu | Mettre en place un tableau de bord Grafana avec alertes sur request_duration > 2s et CPU > 70 %. |
| Documentation | Sauvegarder les paramètres de tuning dans un repo Git et versionner les scripts de migration DB. |
8. Conclusion
Le diagnostic de performance de Dolibarr dans un contexte BTP nécessite une approche holistique :
- Collecte de données précises (temps de réponse, requêtes SQL, profils CPU).
- Identification des points de friction à l’aide d’outils spécialisés (APM, XDebug, iostat).
- Mise en œuvre de correctifs ciblés (indexation, refactorisation, réglages du serveur).
- Mesure d’impact via des KPI business‑orientés (latence, disponibilité, coût).
L’étude de cas de BTP &Co montre qu’avec peu de moyens (ajout d’index, ajustement de PHP‑FPM, optimisation de la génération PDF) il est possible de réduire le temps de génération de factures de plus de 80 %, d’éliminer les erreurs serveur et de maintenir la même infrastructure matérielle.
En appliquant systématiquement ces bonnes pratiques, les PME du BTP peuvent tirer parti de Dolibarr tout en conservant une expérience utilisateur fluide, essentielle à la compétitivité sur des chantiers où chaque minute compte.
Annexes
-
Exemple de requête lente (avant index) :
SELECT * FROM llx_contract
WHERE fk_soc_id = 12 AND date_start BETWEEN '2024-01-01' AND '2024-12-31'; -
Script de création d’index :
ALTER TABLE llx_contract
ADD INDEX idx_contract_soc_date (fk_soc_id, date_start); -
Configuration PHP‑FPM (extrait) :
« `ini [www]
listen = /run/php-fpm/www.sock
pm = dynamic
pm.max_children = 30 pm.start_servers = 5
pm.min_spare_servers = 5 pm.max_spare_servers = 10
request_terminate_timeout = 30 - Dashboard Grafana (URL fictif) :
http://grafana.monentreprise.local/d/7d/dashboard?orgId=1
Pour toute question détaillée sur l’un des points abordés, n’hésitez pas à me le préciser.