La parole est aux speakers : Andoni Larzabal

Jusqu’au mois de mai 2026, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !

La conférence

La gestion du cache en général est un sujet complexe : sans (trop) spoil ton talk, quelles seraient les principales erreurs à éviter ?

Effectivement, le cache est toujours un sujet touchy dans notre domaine, car on ne peut pas « juste » mettre du cache. Mettre en place du cache implique tout un tas de paramètres à prendre en compte, à commencer par l’un des plus compliqués en informatique : l’invalidation du cache.
Quand est-ce que mes éléments ne sont plus bons ? Est-ce que je définis cela en temps, ou est-ce que je viens invalider spécifiquement certains éléments suite à certaines actions ? Peut-être un peu des deux ?

Pour moi, l’une des premières erreurs pourrait être de tout simplement mettre du cache en place alors que ce n’est pas nécessaire : parfois, on peut être tenté d’en utiliser pour régler un problème de performance, mais au bout du compte, on ne fait que rajouter de la complexité là où on aurait plutôt besoin d’une optimisation. Au final, on aura passé plus de temps à gérer les problèmes de cache que si on avait travaillé sur l’optimisation.
Ce cas est souvent valable pour le cache HTTP, avec Varnish par exemple. Au lieu d’optimiser les performances de l’API ou du site web, on installe un Varnish. On finit par oublier qu’il est là, et le jour où le site affiche des données erronées, on vérifie la base de données sans comprendre pourquoi les données affichées sont différentes de celles en DB (c’est arrivé plus d’une fois à mes collègues et à moi, et je pense que les lecteurs et lectrices se reconnaîtront aussi).

La deuxième erreur serait évidemment de sous-dimensionner ses clés de cache : quand on commence, on se dit qu’on va faire simple, y compris sur le nommage. Mais quand le cache commence à grossir, pour pouvoir bien le gérer, il faut avoir nommé ses éléments rigoureusement au préalable.
Dans le cas contraire, on peut se retrouver coincé entre supprimer une trop grosse partie du cache — ce qui coûtera beaucoup de temps à reconstruire — ou laisser des données erronées en place jusqu’à ce qu’elles soient invalidées par les règles existantes.

Quelles étaient tes attentes du composant cache de Symfony ? Et est-ce qu’elles ont été remplies ?

Je m’attendais à ce que l’utilisation du composant Cache me permette de gérer facilement mon cache Redis, en m’évitant d’interagir directement avec lui et en me facilitant la vie.
Le fait est qu’il a répondu en partie à mes besoins, mais pas totalement. J’en parle dans mon talk, mais le composant Cache ne peut en fait pas être compatible avec tous les systèmes sur certains besoins spécifiques.
Il y a donc un compromis à trouver : utiliser le composant Cache pour certaines choses, tandis que le reste doit être géré « à l’ancienne » en passant par la classe Redis native de PHP, par exemple.

À quoi ressemblerai un monde sans cache ?

La réponse utopique serait : à un monde où tout est optimisé et rapide. Mais cela signifierait que tout devrait être optimisé à outrance, et probablement que beaucoup d’outils et d’applications existants n’auraient jamais vu le jour sans cela.
Le monde serait donc rempli d’applications et de logiciels horriblement lents !
Il y a du cache partout, qu’on oublie parfois : Symfony build un cache, Doctrine gère un cache, les navigateurs gèrent un cache… On peut même parler des CDN qui sont une sorte de cache très utile.
Sans cela, on aurait un peu plus de latence pour regarder un épisode de Better Call Saul ou The Office !

Une conférence présentée par

Andoni LARZABAL

Andoni est développeur Back End & parfois Devops chez Sensiolabs. Dans le bain du dev depuis déjà plus de 10 ans, il a déjà eu l'occasion de partager lors de plusieurs meetups locaux. Il souhaite continuer à partager plus largement ses différentes expériences pour aider la communauté.

Autres interviews