Supposons qu’une bibliothèque modifie ses horaires du jour sur son site, mais que certains visiteurs voient encore les anciens. Il faut d’abord distinguer plusieurs causes : l’original sur le serveur n’a-t-il pas été modifié, le navigateur réutilise-t-il une réponse conservée, ou un serveur intermédiaire fournit-il une ancienne version ? Actualiser plusieurs fois l’écran ne suffit pas à déterminer quelle étape est responsable.
Un cache HTTP conserve les réponses reçues et les réutilise lorsque les conditions le permettent. Cet article relie les instructions de stockage et de revalidation de Cache-Control à ETag et aux réponses 304, à partir d’un exemple fictif d’horaires publics. Les échanges ci-dessous sont des illustrations abrégées, pas des mesures réalisées dans une vraie bibliothèque ou sur un serveur particulier. L’objectif est d’expliquer quelles réponses doivent pouvoir être réutilisées et quand, plutôt que de prescrire la suppression de tous les caches.
1. Distinguer le stockage, la vérification et le partage
Pour lire une politique de cache, notez séparément trois questions : peut-on conserver la réponse, peut-on utiliser immédiatement la copie lors de la prochaine requête, et peut-on la partager entre plusieurs utilisateurs ? L’autorisation de stocker ne signifie pas une réutilisation sans condition ; vérifier l’actualité ne donne pas non plus le droit de partager. La norme de cache HTTP RFC 9111 définit ces conditions au moyen de directives distinctes. Les explications suivantes portent sur les directives de réponse sans argument supplémentaire indiquant des noms de champs.
| Question à trancher | Directive de réponse concernée | Sens à distinguer |
|---|---|---|
| Faut-il interdire le stockage ? | no-store | Interdit la conservation en vue d’une réutilisation ultérieure |
| Faut-il vérifier avant de réutiliser ? | no-cache | Le stockage est possible, mais une validation réussie est nécessaire avant réutilisation |
| Plusieurs utilisateurs peuvent-ils partager la réponse ? | private | Exclut le stockage dans un cache partagé sans interdire celui d’un cache privé |
Si un horaire public est fréquemment modifié à la même adresse, on peut par exemple envisager d’exiger une vérification avant usage même lorsqu’une copie existe. Un écran personnalisé diffère déjà de cet horaire par ses conditions de partage. La directive private concerne les caches partagés ; elle ne remplace ni la connexion ni le contrôle des autorisations. Regrouper des réglages d’objectifs différents dans une seule phrase risque de mal définir le public d’une information en cherchant à améliorer la vitesse.
Dans le tableau des politiques, indiquez aussi les raisons, pas seulement les directives. Précisez si l’horaire est une information publique dont il faut vérifier les changements, si le logo est un fichier au contenu fixe, ou si une même adresse contient des informations personnelles. Ce tableau sert à classer les réponses réelles ; ce n’est pas une configuration prête à appliquer partout. Distinguez également le stockage visé, par exemple le navigateur ou le CDN.
2. Ne pas choisir no-cache et no-store d’après leur seul nom
Le nom no-cache peut faire penser à une interdiction de stockage. Dans une réponse, il demande pourtant de valider la copie avant de la réutiliser. Si le serveur confirme qu’elle n’a pas changé, son corps conservé peut éventuellement resservir. À l’inverse, no-store demande de ne pas conserver cette réponse. Ce qui peut être gardé et ce qui doit être vérifié à la requête suivante diffèrent : il ne faut donc pas attendre un comportement identique.
Dans un cache, fresh désigne un état où la politique autorise la réutilisation sans validation supplémentaire. Cela ne garantit pas que l’exploitant n’a pas changé l’original entre-temps. Si max-age fixe une période de réutilisation, une réponse déjà conservée peut continuer à être choisie même lorsque l’original est modifié pendant cette période. Déterminez d’abord le retard de mise à jour acceptable, puis reliez cette exigence aux directives. Ne copiez pas une longue durée arbitraire comme solution universelle de performance.
Le guide du cache HTTP de MDN explique qu’ajouter no-store à une nouvelle réponse ne supprime pas les anciennes réponses déjà stockées pour la même URL. Si l’ancienne copie reste utilisable et qu’aucune nouvelle réponse n’est demandée, le nouvel en-tête peut lui aussi ne jamais parvenir. Ne considérez no-store ni comme une purge générale ni comme une condition suffisante de confidentialité. Vérifiez aussi la durée de vie des réponses existantes et les procédures de renouvellement des caches que vous contrôlez.
3. Suivre une nouvelle visite avec ETag et 304
Imaginons que l’adresse fictive /hours.json annonce initialement une fermeture à 18 h. Voici un échange explicatif au format HTTP/1.1 limité aux éléments utiles ; les autres en-têtes nécessaires à une réponse réelle sont omis. Dans cet exemple, hours-v1 est un identifiant de représentation choisi par le serveur, pas une formule de calcul des horaires ni l’empreinte réelle d’un fichier.
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache
ETag: "hours-v1"
{"closes":"18:00"}Si le navigateur a conservé cette réponse, il peut ensuite envoyer la valeur ETag dans If-None-Match lors d’une requête conditionnelle. Si la condition correspond à la représentation actuelle sélectionnée par le serveur et que celle-ci est jugée inchangée, la réponse est 304 Not Modified. Le bloc suivant est une trace abrégée présentant successivement une requête puis sa réponse. Il ne montre pas l’envoi d’un nouveau JSON d’horaires après le 304.
GET /hours.json HTTP/1.1
Host: library.example
If-None-Match: "hours-v1"
HTTP/1.1 304 Not Modified
Cache-Control: no-cache
ETag: "hours-v1"Comme le décrit l’explication d’ETag par MDN, le client utilise alors le corps conservé. Le 304 ne contient pas de nouveau corps, mais la requête et sa validation impliquent bien des communications. Si l’exploitant passe la fermeture à 19 h et que la représentation du serveur change également, on peut attendre une réponse 200 avec un nouveau corps et un nouvel identifiant face à l’ancienne condition. Utiliser no-cache ne signifie ni obtenir systématiquement 304 ni supprimer les consultations de base de données.
Vérifiez la correspondance entre contenu et identifiant plutôt qu’un seul code d’état. Si le contenu change mais que le serveur garde l’ancien ETag, la validation peut produire un résultat erroné. Inversement, si l’identifiant change sans cesse pour un contenu identique, les retransmissions du corps peuvent se multiplier. Examinez côté serveur la relation entre sa génération et la représentation choisie. La présence d’un ETag ne prouve pas à elle seule que l’implémentation est correcte.
4. Séparer documents changeants et ressources renommées
Un document dont le contenu change à la même URL, comme l’horaire, peut demander une stratégie différente de celle d’un logo ou d’un script auquel on attribue un nouveau nom à chaque modification. Si le logo passe de logo.a1.png à logo.b2.png, le nouveau document doit pointer vers la nouvelle adresse. Ajouter un identifiant au nom puis écraser le contenu de l’ancien fichier rompt l’engagement de gérer ensemble contenu et adresse.
Mettre un nouveau fichier en ligne ne suffit pas à ce que les visiteurs demandent sa nouvelle adresse. Si le HTML reçu indique toujours l’ancien logo, l’ancienne ressource peut être réutilisée. Regardez donc la mise à jour du document qui référence la ressource autant que la politique de cache de celle-ci. Au lieu d’imposer la même durée de conservation aux documents et aux ressources, il faut pouvoir expliquer le retard acceptable pour chacun.
Durant un déploiement, anciens et nouveaux documents peuvent coexister temporairement. Publier le nouveau document avant que ses ressources soient prêtes, ou supprimer trop tôt les anciennes, crée des défaillances distinctes. Dans cet exemple fictif, vérifiez à la fois l’existence des fichiers visés par le nouveau document et l’accessibilité de ceux que les documents existants référencent. Renommer les fichiers est un outil de conception du cache, pas une solution automatique à tous les problèmes d’ordre de déploiement ou de retour arrière.
5. Tester une hypothèse à la fois dans Network
Pour une vérification directe, établissez d’abord une trace de référence avec le cache autorisé. Examinez ensemble l’URL exacte et ses paramètres de requête, la version de l’horaire affichée, l’état de réponse, If-None-Match dans la requête, puis Cache-Control et ETag dans la réponse. Même lorsque les noms se ressemblent, requête et réponse expriment les conditions de parties différentes : notez quel côté vous avez lu. La documentation Network de Chrome DevTools explique comment distinguer ces éléments dans Headers.
| Situation d’essai fictive | Traces à examiner ensemble | Conclusion prématurée à éviter |
|---|---|---|
| Redemander le même horaire | Requête conditionnelle, état, horaires affichés | Un 304 signifie qu’il n’y a eu aucune communication |
| Demander après modification de l’original | Nouveau corps, ETag, URL réellement demandée | L’indication d’enregistrement réussi prouve que tous les utilisateurs ont la mise à jour |
| Demander avec le cache du navigateur désactivé | Différence entre premier téléchargement et revisite ordinaire | Ce résultat représente la vitesse habituelle des revisites |
| Revenir avec le bouton Précédent | Présence d’une nouvelle requête et écran restauré | Un écran visible implique nécessairement une nouvelle validation HTTP |
Testez ensuite la désactivation du cache du navigateur comme une condition distincte. Le réglage Disable cache de Chrome s’applique pendant que DevTools est ouvert : consignez donc l’ouverture des outils et la valeur du réglage. C’est utile pour examiner un premier téléchargement, mais différent d’un essai de réutilisation lors d’une revisite normale. Sans cette information, des téléchargements toujours neufs risquent de faire croire que le cache ne fonctionne pas. Gardez les conditions de l’expérience pour pouvoir revenir à une comparaison avec le cache autorisé.
Pour cerner la cause, évitez de modifier et de demander beaucoup de choses à la fois. Vérifiez d’abord une revisite sans changement de contenu, puis modifiez un seul horaire et observez la réponse. Changer simultanément URL du document, configuration serveur et noms de fichiers empêche de distinguer l’effet de chaque modification. Si le 200 ou le 304 attendu n’apparaît pas, relisez les échanges réels avant d’ajouter d’autres réglages.
6. Vérifier les autres stockages et les critères de réussite
Désactiver le cache HTTP du navigateur ne fait pas disparaître un CDN devant le serveur ni les autres circuits de stockage de l’application. Examinez séparément si un service worker traite la requête, quelle réponse choisit un serveur intermédiaire et si l’application continue d’afficher des données déjà reçues. Une même URL ne signifie pas que toutes les couches utilisent la même copie.
Le retour en arrière doit lui aussi être distingué d’une nouvelle requête HTTP. Lorsque le navigateur restaure l’écran d’une session précédente, la revalidation attendue peut ne pas apparaître même avec no-cache. Y voir immédiatement la preuve que le serveur ignore l’en-tête conduit à mal identifier la cause. Notez séparément si une requête a réellement eu lieu lors d’une nouvelle navigation, d’une actualisation et d’un retour en arrière, afin de ne pas fusionner des phénomènes différents.
Le critère de réussite de l’horaire ne se réduit pas au taux de succès du cache. Vérifiez l’usage correct de la copie quand rien n’a changé, l’apparition de la nouvelle information dans le délai autorisé après modification et le bon public de partage. Conserver l’heure de modification et d’observation, les conditions et le corps réel facilite la reproduction par une autre personne. De meilleurs chiffres de vitesse ne satisfont pas le besoin initial si des horaires faux restent affichés trop longtemps.
En production, examinez les politiques par type de réponse avec les procédures de mise à jour et de retour arrière. Ne copiez pas les instructions d’un document public sur une réponse personnelle et n’assimilez pas une validation réussie à un contrôle d’autorisation terminé. Les en-têtes transmettent des règles de stockage et de réutilisation. Pouvoir expliquer ce qui a été conservé et quelles vérifications ont conduit à l’écran actuel permet de mieux diagnostiquer un affichage périmé.