Configurer le cache HTTP sans exposer de données privées

Temps de lecture estimé : 3 min · Publié le 1 octobre 2026

Classer les réponses avant de fixer une durée

Faites l’inventaire des pages publiques, fichiers statiques, réponses d’API, comptes et confirmations. Pour chacune, notez si le contenu varie selon la personne, la langue ou un paramètre. Identifiez les caches traversés : navigateur, serveur intermédiaire et CDN. Une page de compte ne doit pas hériter par commodité de la politique d’une photographie publique.

Distinguez la durée de fraîcheur du droit de conserver une réponse. MDN rappelle que no-cache demande une revalidation, alors que no-store demande de ne pas stocker. private restreint le stockage aux caches privés. La présence d’un cookie ne suffit pas à rendre automatiquement une réponse privée.

Prévoir comment une modification devient visible

Rédigez une règle de mise à jour par famille. Pour un fichier versionné, vérifiez que la nouvelle page appelle bien la nouvelle URL. Pour une page publique à adresse stable, décrivez la revalidation ou la purge prévue. Fixer une longue durée sans procédure de remplacement déplace simplement le problème vers le prochain changement.

Prenez un exemple concret : une correction de prix, un horaire ou un document remplacé. Notez le moment où la source est modifiée, puis observez la réponse depuis une session ayant déjà visité la page. Une vérification depuis un navigateur vierge ne couvre pas le visiteur qui conserve une ancienne réponse.

Tester plusieurs identités et états

Sur un environnement de test, comparez une visite anonyme, deux comptes distincts, une déconnexion et une navigation de retour. Examinez le contenu réellement affiché et les en-têtes reçus, pas seulement la configuration annoncée par l’hébergeur. N’utilisez aucun document personnel réel dans les jeux d’essai.

Ajoutez les variantes utiles : langue, appareil, paramètres de filtre et erreur serveur. Conservez pour chaque essai l’URL, l’état de session, la réponse attendue et le résultat. Si une personnalisation passe par un cache partagé, faites examiner la clé et les exclusions par la personne responsable de l’infrastructure.

Conserver une procédure de reprise

Documentez qui peut purger le cache, comment vérifier l’effet et comment rétablir une configuration précédente. Une purge générale peut réduire temporairement le bénéfice du cache ; préparez un contrôle des pages essentielles après l’opération.

Révisez cette politique lorsqu’un espace client, une boutique, une langue ou un nouveau CDN apparaît. Le livrable utile est une matrice réponse–politique–test–responsable. Une note de performance isolée ne démontre ni la fraîcheur des informations ni l’absence de fuite entre utilisateurs.

Documentation primaire : MDN — HTTP caching.

Documents de référence

MDN — HTTP caching

Matrice de recette à adapter au projet

Ces contrôles proposés utilisent des cas fictifs. Décidez du comportement attendu avec l’équipe, notez le résultat et attribuez les écarts non résolus avant publication.

Cas de test, résultats attendus et preuves utiles
Cas	Résultat attendu	Preuve à conserver
Page publique inchangée	La politique annoncée et la réponse conditionnelle restent cohérentes.	En-têtes, validateur et statut des deux requêtes.
Contenu public modifié	La version corrigée arrive dans les conditions de fraîcheur prévues.	Ancienne et nouvelle version, heure et en-têtes reçus.
Deux comptes de test	Aucune réponse personnalisée du premier compte ne sert au second.	Requêtes isolées et contenu reçu pour chaque compte.
Déconnexion puis retour arrière	Le comportement des écrans sensibles correspond au besoin de confidentialité défini.	Séquence complète dans le navigateur et limites documentées.

Questions fréquentes

no-cache et no-store sont-ils équivalents ?

Non. Le premier impose une revalidation avant réutilisation ; le second demande de ne pas conserver la réponse. Le choix doit suivre le contenu et les caches réellement traversés, puis être vérifié sur les parcours concernés.

Faut-il appliquer la même durée à tout le site ?

Une durée unique ignore les différences entre fichier public versionné, page éditoriale, prix et réponse personnalisée. Classez les réponses, définissez leur mise à jour et vérifiez les états de connexion avant de choisir les durées.