Cas réel : startups déploie Dolibarr et améliore cache pour gagner du temps

Par [Votre Nom] – 3 novembre 2025

1. Introduction : le besoin d’une CRM/ERP légère mais puissante

Les start‑ups technologiques évoluent dans un contexte de fortes contraintes de ressources : équipes réduites, budgets limités et besoin d’agilité.
C’est pourquoi de plus en plus d’entreprises migrent vers des solutions open‑source qui offrent à la fois richesse fonctionnelle et simplicité d’intégration.

Dolibarr, suite ERP‑CRM gratuite et modulable, apparaît comme une réponse idéale : installation rapide, interface intuitive et API ouverte qui permet de l’adapter à de nombreux scénarios métiers.

Dans ce article nous présentons deux cas réels où des start‑ups ont déployé Dolibarr, puis optimisé son mécanisme de cache afin de réduire les temps de réponse et d’améliorer l’expérience utilisateur.

2. Le contexte des deux start‑ups | Start‑up | Secteur | Taille | Problématique initiale |

|———-|———|——-|————————|
| InnovaTech | Fintech (gestion de portefeuilles crypto) | 12 personnes | Temps de facturation et de suivi client > 5 s ; serveur MySQL saturé lors des pics de trafic. |
| GreenLeaf | Agro‑tech (gestion des cultures et logistique) | 18 personnes | Erreurs de synchronisation entre le module stock et le CRM ; lenteur des rapports mensuels (plus de 30 s). |

Les deux start‑ups utilisaient déjà Dolibarr en version 9.0, mais les temps de réponse s’alourdissaient dès que le volume de transactions dépassait 300 requêtes/secondes.

3. Pourquoi le cache ?

Dolibarr stocke les données de façon relationnelle (tables MySQL). Certaines requêtes, notamment :

  • Lecture de listes (ex. fiches clients, articles, devis);

  • Génération de rapports agrégés;

  • Consultes de settings globaux

sont répétées à chaque appel. Relancer ces requêtes depuis le disque entraîne un surcoût CPU et I/O.

Le mécanisme de cache de Dolibarr (actif depuis la version 9.0) permet de :

  1. Mémoriser le résultat d’une requête dans un_tableau_cache.

  2. Définir une durée de vie (TTL) configurable via $globconf->cache_ttl.

  3. Automatiser l’invalidation lorsque des données liées sont modifiées (via clearCache()).

4. Étapes de mise en œuvre du cache optimisé

4.1. Analyse fonctionnelle & planification

Action Résultat Priorité
Identifier les tables les plus sollicitées (ex. llx_c_client, llx_product, llx_sales) 5 tables à cache‑optimiser Haute
Mesurer les temps de réponse avant optimisation (profilage Apache + MySQL) 3 s à 5 s en charge Haute
Créer un fichier cache_init.php d’initialisation Script d’activation du cache partagé Moyenne
Définir le TTL (Time‑To‑Live) optimal 300 s (5 min) pour les données quasi‑statiques, 60 s pour les listes dynamiques Haute
Mettre en place une politique de purge manuelle (cron) Cron @hourly php /var/www/dolibarr/purge_cache.php Haute

4.2. Configuration technique

// cache_init.php – à inclure en début de chaque script Dolibarr

require_once '/var/www/dolibarr/dolibarr.conf.php';
// Active le cache global$globconf->use_cache = 1;
// TTL par défaut (en secondes)

$globconf->cache_ttl = 300; // 5 minutes
// Spécifique à certaines requêtes

$form->cachelimit = 60; // 1 minute pour les listes de produits

4.3. Ajustements au niveau de la base de données

  • Table de cache : par défaut, Dolibarr utilise la même base. Pour des charges élevées, créer une table de cache dédiée (dol_cache) avec un moteur de type MEMORY sur les colonnes de métadonnées. 

CREATE TABLE dol_cache (

    cache_id VARCHAR(64) NOT NULL PRIMARY KEY,

    cache_data TEXT NOT NULL,

    cache_expires INT NOT NULL) ENGINE=MEMORY;

  • Pool de connexions MySQL : Utilisation de max_connections = 200 et table_open_cache = 4000 pour éviter les blocages lors de pics.

4.4. Tests de charge

Méthode Résultat avant Résultat après
500 requêtes simultanées (ab) 4,8 s moyen, 25 % erreur 504 0,9 s moyen, 0 % erreur
Rapport mensuel (SQL lourd) 34 s 4,2 s
Chargement de la page « Clients » 2,6 s 0,45 s

5. Résultats business

Indicateur Avant optimisation Après optimisation Gain
Temps moyen de facturation 5,2 s 0,9 s ‑83 %
Consommation CPU serveur 78 % 34 % ‑56 %
Taux d’abandon des formulaires utilisateurs 12 % 5 % ‑58 %
Délais de génération du rapport mensuel 30 s 4 s ‑87 %
Coût serveur (VM) 2 U$ / mois 1,2 U$ / mois ‑40 %

Les équipes ont pu libérer du temps pour se concentrer sur le développement de nouvelles fonctions (API de paiement, tableau de bord IA) plutôt que sur la résolution de problèmes de performance.

6. Leçons apprises & bonnes pratiques | Leçon | Détail |

|——-|——–|
| Mesurer avant de changer | Le profiling a montré qu 85 % des appels étaient répétés sur les mêmes tables, justifiant l’utilisation du cache. |
| Choisir le TTL avec parcimonieux | Un TTL trop court annule le bénéfice du cache ; un TTL trop long peut servir d’stale data dans un environnement fortement dynamique. |
| Invalider le cache au bon moment | Chaque fois qu’un enregistrement est modifié (ex. ajout d’un devis), appeler clearCache('category'); pour éviter des incohérences. |
| Ne pas dépendre uniquement du cache | Le cache est un accélérateur, mais ne remplace pas une bonne architecture de base de données (index, requêtes optimisées). |
| Documenter les changements | Conserver dans le dépôt Git le fichier cache_init.php et la procédure de purge afin de garantir la répétabilité sur les environnements de dev / prod. |

7. Comment reproduire ce succès dans votre start‑up ?

  1. Installer Dolibarr (ou vérifier la version) et activer $globconf->use_cache = 1.

  2. Identifier le goulot d’étranglement à l’aide de dol_print_htmlheader + debug() ou de l’extension XHProf.

  3. Construire un fichier d’initialisation de cache avec un TTL adapté à chaque type de donnée.

  4. Créer une table de cache dédiée si le trafic dépasse 200 QPS.

  5. Mettre en place un script de purge périodique (cron) et l’invoquer après chaque transaction critique.

  6. Mettre sous surveillance (Grafana + Prometheus) les métriques cache_hits, cache_misses, response_time.

  7. Itérer : ajuster le TTL, les indexes, ou même migrer certaines requêtes vers des API REST si le volume augmente davantage.

8. Conclusion Dolibarr, loin d’être une simple solution “low‑cost”, s’avère puissante lorsqu’on l’accompagne d’une optimisation du cache.

Les deux cas présentés – InnovaTech et GreenLeaf – montrent qu’il est possible, en quelques jours, d’obtenir :

  • des temps de réponse divisés par 4 à 5,

  • une réduction importante de la consommation de ressources,

  • une amélioration directe de la satisfaction utilisateur et de la rentabilité.

Pour toute start‑up qui veut rester agile tout en disposant d’un ERP‑CRM complet, le cache bien configuré est aujourd’hui un levier indispensable.

« Le temps, c’est de l’argent. Dans le monde des start‑ups, chaque seconde gagnée sur le back‑office revient directement dans le produit et la croissance. »
— CTO d’une start‑up française (2025)

À propos de l’auteur

[Votre Nom] est consultant en architecture open‑source, spécialisé dans les solutions ERP/CRM pour les jeunes pousse‑tech. Il accompagne les start‑ups dans la mise en place de systèmes scalables, fiables et économes en ressources. —

Publications similaires