Cache applicatif Laravel : Redis, tags et invalidation sans surprise

Le cache est l'optimisation la plus rentable d'une application Laravel, et aussi l'une des plus dangereuses : un cache mal invalidé affiche des données fausses, et personne ne comprend pourquoi. La règle d'or est célèbre : il n'y a que deux difficultés en informatique, nommer les choses et invalider le cache. Voici comment aborder le sujet sans surprise.

1. Commencer par le cache du framework

Avant de mettre en cache vos données, activez les optimisations de Laravel en production :

php artisan optimize

Cette commande met en cache la configuration, les routes, les vues et les événements. Elle fait partie de toute procédure de déploiement sérieuse : nous l'intégrons à la procédure décrite dans notre guide de déploiement sur un VPS avec GitHub Actions. N'oubliez pas de relancer php artisan optimize:clear en développement après un changement de configuration.

2. Choisir le bon pilote

• file / database : acceptables en développement ou pour un petit site ;
• Redis : le choix courant en production (rapide, supporte les tags et les verrous, partagé entre serveurs) ;
• Memcached : alternative simple et rapide ;
• array : réservé aux tests.

Définissez le pilote via CACHE_STORE dans le fichier .env, et dédiez si possible une base Redis distincte au cache, pour pouvoir la vider sans toucher aux files d'attente ni aux sessions.

3. Le motif de base : Cache::remember

$stats = Cache::remember('dashboard.stats', now()->addMinutes(10), function () {
    return Order::query()
        ->selectRaw('count(*) as total, sum(amount) as revenue')
        ->first();
});

Si la clé existe, la valeur est renvoyée ; sinon, la closure est exécutée et le résultat stocké. C'est la meilleure option pour les requêtes lourdes qui supportent un léger retard : statistiques, listes de référence, menus. Pensez à des clés explicites et structurées (products.featured.fr) qui incluent tout paramètre qui change le résultat (langue, utilisateur, filtre).

Les versions récentes de Laravel proposent aussi Cache::flexible(), une stratégie « stale-while-revalidate » : elle sert une valeur légèrement périmée pendant qu'elle se recalcule en arrière-plan. Vérifiez sa disponibilité et sa signature dans la documentation de votre version.

4. Invalider : les trois stratégies

L'expiration par durée (TTL). La plus simple : acceptez que la donnée ait jusqu'à 10 minutes de retard. Idéale pour tout ce qui n'est pas critique.

L'invalidation par événement. Lorsque le modèle change, vous supprimez la clé concernée, par exemple dans un observer :

class ProductObserver
{
    public function saved(Product $product): void
    {
        Cache::forget('products.featured');
    }

    public function deleted(Product $product): void
    {
        Cache::forget('products.featured');
    }
}

Les tags. Avec Redis ou Memcached, vous regroupez des entrées sous une étiquette et les videz ensemble :

Cache::tags(['products'])->remember('products.list.page1', 600, fn () => Product::paginate(20));

// à la modification d'un produit
Cache::tags(['products'])->flush();

Attention : les tags ne fonctionnent pas avec les pilotes file et database, et un flush sur un tag est large. Ciblez avec précision.

5. Éviter la ruée sur le cache (cache stampede)

Quand une clé très sollicitée expire, des dizaines de requêtes peuvent recalculer la même donnée en même temps et saturer la base. Les verrous atomiques de Laravel y remédient :

$value = Cache::lock('lock:dashboard.stats', 10)->block(5, function () {
    return Cache::remember('dashboard.stats', 600, fn () => computeStats());
});

Un seul processus recalcule, les autres attendent le résultat. Combinez-les avec un TTL aléatoire (600 + random_int(0, 60)) pour éviter que plusieurs clés n'expirent simultanément.

6. Mettre en cache les bonnes choses

• À mettre en cache : résultats de requêtes lourdes, appels à des API externes, données de configuration lues souvent, fragments de page coûteux.
• À éviter : données propres à un utilisateur sans clé dédiée (risque de fuite entre comptes), données qui changent à chaque requête, résultats qui dépendent de droits d'accès.

Mesurez avant de mettre en cache : si une requête est lente, commencez par l'index ou le chargement anticipé (voir notre guide sur les requêtes lentes). Le cache masque un problème, il ne le règle pas. Les évolutions récentes du langage aident aussi : voyez les nouveautés de PHP 8.5.

7. Tester et surveiller

• Utilisez le pilote array dans vos tests pour vérifier que l'invalidation fonctionne.
• Surveillez le taux de réussite (hit ratio) de Redis avec INFO stats ou un outil de supervision.
• Prévoyez une commande d'urgence pour vider un tag précis plutôt que tout le cache.

Conclusion

Une bonne stratégie de cache commence petit : activez optimize, passez sur Redis, mettez en cache deux ou trois requêtes lourdes avec un TTL court, puis invalidez par événement uniquement là où la fraîcheur compte. Vous obtiendrez l'essentiel du gain sans transformer votre application en puzzle de clés.