Un cache conserve temporairement une copie de données ou de résultats afin d’éviter de refaire un travail coûteux. Il peut accélérer une application et réduire la pression exercée sur une base de données ou un service externe. Mais ce n’est pas une amélioration automatique : il faut définir des règles de mise à jour, gérer les risques d’incohérence et assurer le fonctionnement d’une dépendance supplémentaire.
La bonne question n’est pas « Peut-on ajouter un cache ? », mais quelle opération précise voulons-nous améliorer, et quel coût sommes-nous prêts à accepter en échange ? Ce guide vous aide à y répondre, du diagnostic initial à la validation, jusqu’au retrait éventuel du cache.
Les problèmes qu’un cache résout — et ceux qu’il ne corrige pas
Un cache est pertinent lorsqu’une même information ou un même résultat calculé est demandé de façon répétée, et que le produire à nouveau a un coût significatif. Ce coût peut être le temps d’une requête, la consommation de ressources, un appel à un autre service ou la latence ressentie par l’utilisateur.
En revanche, stocker des réponses ne corrige pas à lui seul une requête mal conçue, un algorithme inefficace, une interface qui envoie trop de demandes ou une dépendance systématiquement lente. Le cache peut masquer ces défauts quelque temps et rendre le diagnostic plus difficile. Si chaque demande est différente ou si les données changent en permanence, les réutilisations seront peut-être trop rares pour justifier cette couche supplémentaire.
Avant de concevoir un cache, formulez un objectif vérifiable : réduire la latence d’une lecture fréquente, par exemple, ou limiter les appels répétés à une dépendance. Précisez également quelle mesure doit s’améliorer, dans quel parcours et pour quels utilisateurs.
Les signes qui peuvent justifier un cache
L’hypothèse devient plus solide si les mesures révèlent plusieurs des signes suivants :
- Des lectures répétées : des requêtes différentes ont besoin des mêmes données ou du même résultat sur une période donnée.
- Un coût élevé à la source : interroger la base de données, calculer une réponse ou appeler un service prend assez de temps pour affecter le parcours.
- Une dépendance sous pression : le volume de demandes risque de dépasser sa capacité, ses limites ou la stabilité du système.
- Une réutilisation prévisible : vous pouvez définir une clé stable qui distingue les résultats, par exemple selon la langue, les droits ou les filtres concernés.
Une latence élevée, à elle seule, ne suffit pas. Repérez où le temps est consommé et vérifiez si la plupart des demandes pourraient réutiliser un résultat. Mesurez les temps de réponse par opération, le volume, les erreurs et la fréquence de répétition. Si l’application sert des contenus à différents utilisateurs, vérifiez aussi que la clé distingue correctement leurs droits et leur contexte.
Quand optimiser avant d’ajouter une couche
Commencez par la source si le problème vient de là. Examinez les requêtes lentes, la pertinence des index, les données inutiles, les appels redondants et le travail qui pourrait n’être effectué qu’une seule fois. Pour une opération coûteuse, comparez le coût de sa correction à celui de la maintenance d’un cache. L’optimisation est souvent préférable lorsqu’elle améliore tous les cas, y compris ceux où une réponse ne peut pas être réutilisée.
Il est également utile de chercher si la lenteur n’apparaît que sous forte concurrence, dans un service externe ou à une étape précise du parcours. Un cache peut aider dans certaines de ces situations, mais pas nécessairement dans toutes. Si le résultat dépend d’informations qui changent à chaque demande, une copie stockée risque d’être inutile ou trompeuse.
Commencez par l’intervention la plus limitée qui puisse confirmer la cause. Si l’ajustement d’une requête résout le problème, inutile d’assumer le coût d’une couche supplémentaire. Si des répétitions mesurables persistent et que les données tolèrent un certain délai, il devient pertinent d’évaluer un cache.
Quelles données stocker et où les placer
Privilégiez les données souvent consultées, coûteuses à obtenir et peu fréquemment modifiées, ou dont le délai de mise à jour est explicitement accepté. À l’inverse, évitez de stocker sans raison claire des données personnelles ou sensibles, des informations exigeant une cohérence immédiate et des résultats peu réutilisés. Définissez le contenu de chaque entrée, sa taille maximale, son mode d’identification et les personnes ou systèmes autorisés à y accéder.
Le choix de l’emplacement dépend du parcours :
- Côté client : le cache peut éviter des demandes répétées dans le navigateur et améliorer la réactivité perçue. Le serveur reste responsable de l’autorisation d’accès ; les données du client ne doivent pas faire autorité pour les droits ou la vérité des données.
- Côté serveur : cette option est utile lorsque plusieurs utilisateurs ou requêtes peuvent réutiliser le même résultat. La clé doit inclure toutes les variables qui modifient la réponse, notamment l’identité, les droits et, le cas échéant, la configuration.
- Dans l’infrastructure : un cache de réponses ou de contenus peut traiter des demandes répétées avant qu’elles n’atteignent l’application. Il faut définir sa portée et ses règles de stockage pour ne pas exposer de réponses privées.
Ne choisissez pas un emplacement par habitude. Suivez le chemin des données et déterminez où la réutilisation est possible sans mélanger les contextes ni enfreindre les exigences de confidentialité.
Expiration, invalidation et fraîcheur des données
L’expiration définit la durée pendant laquelle une entrée peut être réutilisée avant d’être considérée comme périmée. Cette méthode est simple, mais les informations peuvent devenir obsolètes pendant cet intervalle. L’invalidation explicite supprime ou actualise les entrées lorsque la donnée source change. Elle exige toutefois de relier de manière fiable les écritures aux clés concernées : aucune stratégie ne convient à tous les cas.
Pour chaque donnée, définissez une tolérance maximale à l’obsolescence. Une fiche d’information peut éventuellement afficher quelques minutes de retard si cette limite est acceptée. Pour un stock, un solde, des droits ou un état qui conditionne une action, déterminez si la source doit être consultée avant confirmation. Ne partez pas du principe qu’un cache garantit la cohérence entre plusieurs répliques ou processus.
Documentez l’événement qui invalide une entrée, la conduite à tenir si la mise à jour échoue et les moyens d’éviter que de nombreuses demandes simultanées ne recalculent le même résultat. Si l’activité exige une mise à jour immédiate, il peut être préférable de ne pas mettre cette donnée en cache pour le parcours critique, ou de n’utiliser le cache qu’en soutien, sans en faire la source de référence.
Pannes et dégradation maîtrisée
Un cache peut devenir indisponible, perdre des entrées ou renvoyer des données périmées. Décidez à l’avance du comportement de l’application dans chaque cas : consulter la source, renvoyer une réponse limitée ou afficher une erreur. Le choix dépend de l’importance de la donnée et de la capacité de la dépendance. Si toutes les demandes se reportent simultanément sur la source après une panne, la reprise peut provoquer une surcharge supplémentaire.
Définissez des limites de mémoire et le traitement des entrées invalides. Pour les opérations sensibles, vérifiez les autorisations au moment approprié et empêchez qu’une clé partagée expose les données d’un autre compte. Les pannes de cache doivent être observées et testées, et non considérées comme des exceptions improbables.
Comment vérifier qu’un cache est utile
Établissez une référence avant le changement, puis comparez le même parcours après sa mise en place. Observez la latence, les erreurs, la charge sur la source et le comportement sous une demande représentative. Ajoutez des mesures des réussites et des échecs du cache, sans confondre un taux élevé de réutilisation avec une amélioration pour l’utilisateur : le résultat final doit progresser sans dégrader la fraîcheur ni la fiabilité.
Examinez aussi les cas d’expiration, d’invalidation et de panne. Si le bénéfice n’apparaît que dans des conditions rares, ou si le coût d’exploitation dépasse l’impact mesuré, réévaluez votre choix. Conservez la possibilité de retirer le cache et de comparer les résultats, surtout si les habitudes d’utilisation évoluent.
Liste de contrôle avant la mise en œuvre
- Une opération précise et une référence mesurable ont-elles été définies ?
- Les lectures sont-elles répétées, et l’obtention ou le calcul du résultat est-il coûteux ?
- Les optimisations plus simples à la source ont-elles été écartées ?
- La clé est-elle définie, y compris pour les droits et le contexte ?
- Le délai de mise à jour acceptable est-il convenu ?
- Un plan d’expiration, d’invalidation et de gestion des pannes existe-t-il ?
- Les résultats pour les utilisateurs, la charge et les erreurs seront-ils mesurés, en plus des réussites du cache ?
Utilisez un cache lorsque les mesures confirment une possibilité de réutilisation et que vous pouvez maîtriser les risques associés. Si vous ne pouvez pas expliquer ce qui est stocké, pendant combien de temps et ce qui se passe lorsque les données deviennent obsolètes, une décision de conception essentielle reste à prendre.