Architecture Dolibarr : cache en 2026

(Article technique – version française)

1. Introduction

Dolibarr est un ERP/CRM open‑source qui a su gagner une popularité durable grâce à sa simplicité d’utilisation et à son architecture modulaire. En 2023‑2024, les performances de Dolibarr sont largement dépendantes du cache mis en place par les développeurs et les intégrateurs (opcache, APCu, Redis, etc.). En 2026, l’évolution des environnements de déploiement (cloud natif, conteneurs, edge computing) et l’émergence de nouvelles extensions PHP obligent à repenser l’architecture du cache.

Cet article vous propose un tour d’horizon complet :

  • les principes de base du cache dans Dolibarr,

  • les solutions actuelles (2024),

  • les évolutions prévues d’ici 2026,

  • les recommandations pour préparer votre infrastructure à ces changements.

2. Vue d’ensemble de l’architecture de Dolibarr

Niveau Description Interaction avec le cache
Front‑office (HTML/JS) Génération des pages via Smarty templates. Les rendus sont souvent pré‑rendus et stockés dans le cache (Smarty cache, HTTP cache).
Engine PHP Fichiers *.inc.php qui peuplent les modèles ($object->get(), $object->fetch()). Object cache (memcached/Redis) pour les requêtes DB répétées ; *apc/u** pour le bytecode et les données structurées.
Base de données MySQL / MariaDB / PostgreSQL. Le cache de requêtes SQL (query cache, result cache) permet de servir les mêmes SELECT sans les refaire.
API/Services externes Webhooks, paiements, messageries. Le cache de réponses HTTP (cURL) évite des appels redondants.
Configuration et fichiers conf.php, fichiers de languages, certificats. Un simple filemtime() déclenche le bypass du cache lorsqu’un fichier change.

Schéma simplifié 

[Client HTTP] → [NGINX] → [FPM] → (Cache HTTP/Smarty) → [PHP] → 

   → [$ object->fetch() ] → (Cache DB/Redis) → DB → 

   → (apc/u** cache) → 

   → [Réponse]

3. Les mécanismes de cache « actuels » (2023‑2024)

Mécanisme Portée Implémentation dans Dolibarr Configuration clé
Smarty cache Page entière (HTML) smarty::getCacheInfo(); $smarty->caching = $caching && $GLOBALS['setup']->cache_ld cache_lifetime (3600 s par défaut)
OPcache Bytecode + variables PHP Activez opcache.enable=1 ; opcache.memory_consumption ; opcache.max_accelerated_files Le cache est partagé entre tous les scripts.
APCu Cache d’objets PHP (ex. $object->fetch()) Utilisé par défaut pour les « state » de certains objets. apc.enable_cli=1 pour les CLI scripts.
Redis / Memcached Cache de résultats SQL ou de données structurées Via le module dolibarr-redis-cache ou plugin externe. host, port, db, password.
HTTP cache (Edge) Proxies / CDN Cache-Control: public, max-age=300 ou Vary header. Configuration NGINX proxy_cache_key "$scheme$request_method$host$request_uri"

Points forts actuels

  • Granularité : le cache peut être limité au niveau d’un objet ($object->get()), d’une requête ou d’une page complète.

  • Détection de changement : le framework compare md5($file) avec la valeur stockée dans la table llx... pour réinitialiser le cache lorsqu’un fichier est modifié.

  • Compatibilité : aucune dépendance externe obligatoire, ce qui facilite le déploiement.

Limites reconnues

  • Le cache HTTP repose encore sur la désactivation du cache du navigateur ou sur des contrôles de version manuels (URL avec timestamp).

  • Pas de pré‑chauffage automatisé des caches critiques (ex. catalogue produit).

  • Manque d’intégration native de Cache‑Aside (pattern) ou de Cache‑Linearization pour les méta‑données complexes.

  • L’OPcache ne profite pas d’une purge fine‑grained (seulement de l’ensemble du processus).

4. Projection 2026 : Quels changements architecturaux ?

4.1. Le Cache‑Aside 2.0 intégré nativement

  • Concept : le service « cache‑aside » sera fourni comme service centralisé (ex. CacheInterface) accessible depuis n’importe quel composant (object, repository, worker).

  • Implémentation : un PSR‑6‑like mais plus léger (DolibarrCacheInterface) offrant get($key), set($key,$value, $ttl), fetch($key, $callable) où le $callable est le code qui récupère les données depuis la DB si le cache est manquant.

  • Avantages :

    • Suppression totale du cache warming manuel.

    • Gestion automatique de la baisse de TTL liée à la charge du serveur (dynamic TTL).

4.2. Cache distribué natif en NATS‑Streaming / Kafka

  • En 2026, les environnements Kubernetes sont majoritairement event‑driven.

  • Dolibarr pourra s’abonner à un topic qui logge les événements « ObjectUpdated », et publier des instructions de ré‑initialisation de cache vers d’autres pods.

  • Le pattern « Cache‑Invalidation‑Bus » deviendra standard (ex. dolibarr-cache-eventbus).

4.3. Edge‑Ready / CDN‑First

  • Les CDN à la Cloudflare Workers ou à l’edge de Vercel permettent d’intercepter les requêtes PHP via les fonctionnalités response‑cache des Edge Functions.

  • Dolibarr 2026 intégrera un Header‑Based Cache‑Control configurable : Cache-Control: public, max-age=7200, stale-while-revalidate=300.

  • Le service dolibarr-cdn-middleware sérialise les réponses HTML dans des formats JSON/Protobuf, rendant le cache HTTP beaucoup plus efficace.

4.4. Lazy‑Loading & Asynchronous Rendering

  • Les pages de liste sont de plus en plus rendues de façon progressive (React/Preact ou Vue) côté client.

  • Dolibarr 2026 exposera API‑JSON qui renvoient les données déjà pré‑cachées (par le Cache‑Aside). Les vues côté serveur ne font que préparer le JSON; le rendu final est delegué à l’UI.

  • Le serveur ne fait plus de Smarty complet ; il se contente de injecter les modèles déjà en cache sous forme de fragments.

4.5. Gestion du TTL adaptative

  • Grâce à un metastore partagé (ex. Redis Streams), chaque cache entry pourra avoir un TTL dynamique en fonction de la fréquence d’accès et du hotness du contenu.

  • Le plugin CacheTtlAdaptor utilise le machine‑learning léger (via php-ml) pour prédire la durée de vie optimal.

5. Scénario d’utilisation 2026 : Implémentation concrète

5.1. Installation recommandée

Élément Version recommandée (2026) Raison
PHP 8.3+ (opcache + apcu + redis) Opcache 3.2 introduit le opcache.validate_timestamps=1n avec purge granulaire.
NGINX 1.27+ (cache + http2) Support natif du Cache‑Aside Header et du edge cache partagé.
Redis 7.2 (client PHP phpredis 6.0) Supporte les Lua scripts de purge atomique.
Docker dolibarr:2026 (multi‑stage) Contenu minimalisé, multi‑arch.
Kubernetes Helm chart dolibarr-cache-2026 Gestion auto‑scaling du cache Redis & du worker de purge.

5.2. Configuration du Cache‑Aside

// src/Dolibarr/Cache/CacheAside.php

namespace Dolibarr\Cache;
class CacheAside implements CacheInterface

{

    private CacheInterface $backend; // Redis ou APCu

    private int $defaultTtl = 3600;
public function __construct(CacheInterface $backend, int $defaultTtl = 3600)

    {

        $this->backend = $backend;

        $this->defaultTtl = $defaultTtl;

    }
public function get(string $key)

    {

        return $this->backend->get($key);

    }
public function set(string $key, $value, int $ttl = -1)

    {

        $ttl = ($ttl > 0) ? $ttl : $this->defaultTtl;

        $this->backend->set($key, $value, $ttl);

    }
/**

     * Cache-Aside pattern

     */

    public function fetch(string $key, callable $loader, int $ttl = -1)

    {

        $value = $this->get($key);

        if ($value === null) {

            $value = $loader();               // <- récupère depuis DB

            $this->set($key, $value, $ttl);

        }

        return $value;

    }

}

Utilisation dans le repository d’un objet : 

public function getByNumber(int $num) : DoliObject

{

    $key = "object_$num";

    return $cache->fetch($key, fn() => $this->loadFromDb($num));

}

5.3. Purge atomique via Lua script

-- purge_key.lua

local key = KEYS[1]

redis.call('EXPIRE', key, 0)   -- supprime immédiatement

return 1

Concernant le module dolibarr-redis-cache : le plugin utilise ce script via redis->evalsha().

5.4. Exemple de configuration NGINX pour le Cache‑Aside Header

location / {

    proxy_pass http://php-fpm;

    proxy_set_header Host $host;

    # Ajoute les en-têtes de cache générés par le script PHP

    add_header Cache-Control "public, max-age=7200, stale-while-revalidate=120";

    # Soporte de Cache‑Aside via le header 'X-Cache-Aside'

    if ($sent_http_x_cache_aside = "hit") {

        add_header X-Cache-Aside "true" always;

    }

}

6. Bonnes pratiques à adopter dès aujourd’hui

Action Pourquoi Exemple concret
Activer opcache.validate_timestamps=0 en prod Réduit le coût de la validation du bytecode. Dans php.ini : opcache.validate_timestamps=0
Utiliser APCu pour les petites métriques APCu est plus rapide que Redis pour < 1 KB. $apc->add('module_status_12', $status, 600);
Pré‑charger le cache des listes statiques Évite le « cold‑start » après un déploiement. Cron : curl -s http://my.dolibarr.local/llx/menu/mainmenu.php?mainmenu_token=12345 > /dev/null
Configurer Cache-Control sur les API JSON Les clients mobiles peuvent mettre en cache côté browser. header('Cache-Control: public, max-age=300');
Mettre en place un Cache‑Bus Synchronise la purge entre plusieurs instances. Publier sur Redis Stream cache-updates chaque fois que llx.object est mis à jour.
Surveiller le hit‑ratio Détecter les caches sous‑utilisés ou sur‑utilisés. Prometheus metric dolibarr_cache_hit_ratio.
Versionner les clés (ex. object_42_v202411) Permet d’appliquer de la stale‑while‑revalidate sans perdre de données. $key = "product_{$product->id}_{$product->version}";

7. Scénario de migration vers 2026

Étape Durée Action clé Résultat attendu
1 – Audit 2 semaines Mesurer hit‑ratio, identifier les goulots d’étranglement (SQL repeat, page rendering). Rapport de performance ; liste des objets « hot ».
2 – Test de Cache‑Aside 1 mois Implémenter le --‑CacheAside en environnement de test. 15‑30 % de réduction du temps de réponse sur les listes de produits.
3 – Migration du Cache Engine 2 mois Passer de Redis à Redis + Lua Purge + OPcache 3.2. Élimination des « stale cache » liés à la propagation.
4 – CDN + Edge‑Cache 1 mois Ajouter le middleware dolibarr-cdn-middleware. Diminution du load‑balancer de 40 %.
5 – Automatisation du Warm‑up 2 semaines Script cron qui lance les API “popular‑items”. Cache rempli avant les pics de trafic (Black Friday).
6 – Go‑Live 2026 – Déployer sur Kubernetes avec autoscaling du cache Redis. Architecture prête pour des charge > 10 k RPS avec < 150 ms latence moyenne.

8. Conclusion

L’architecture du cache dans Dolibarr est déjà riche et modulable, mais le parcours 2026 introduit trois leviers majeurs :

  1. Cache‑Aside natif (pattern centralisé, TTL adaptatif) ;

  2. Cache distribué orienté events (Redis Streams/Nats‑Streaming) ;

  3. Edge‑Ready / CDN‑First avec gestion fine du Cache‑Control côté serveur.

En combinant ces évolutions avec les bonnes pratiques ci‑dessus, les organisations pourront :

  • Réduire de 30 % à 50 % le temps de réponse des pages critiques,

  • Diminuer la consommation de ressources serveur (CPU, RAM) de 20‑30 %,

  • Garantir une meilleure résilience face aux pics de trafic grâce à la purge atomique et au pré‑chauffage automatisé.

En résumé, préparer Dolibarr à 2026 consiste à externaliser le cache comme un service, à rendre les invalidations event‑driven, et à exploiter les capacités modernes du stack PHP/NGINX. Une implémentation progressive, testée en environnement isolé, vous donnera la certitude que votre ERP restera performant et évolutif pendant les prochaines années.

À retenir : le futur du cache dans Dolibarr, c’est la convergence service‑oriented cache + event‑driven invalidation + edge‑first delivery. En adoptant dès maintenant les patterns décrits, vous serez paré pour 2026 et au‑delà.

Merci pour votre lecture ! Vous avez des questions sur une implémentation précise ? N’hésitez pas à les poser en commentaire ou à me contacter directement.

Publications similaires