Identifier quelle version est servie
Une ancienne version visible après publication peut venir du navigateur, d’un cache partagé ou de la source publiée. Avant de purger quoi que ce soit, relevez l’URL exacte, le contenu attendu et une marque de version que vous pouvez vérifier.
La documentation de Cache-Control, consultée le 6 octobre 2026, distingue stockage et revalidation, ainsi que caches privés et partagés. Ces mécanismes ne se diagnostiquent pas avec une capture seule.
Relever le problème avant d’intervenir
Décrivez une différence visible : une phrase ancienne, un lien absent ou une image remplacée. Notez l’heure du déploiement et l’adresse consultée, avec son éventuelle requête. Vérifiez que la production reçoit bien le fichier attendu avant d’accuser le cache.
Dans les outils réseau du navigateur, relevez la réponse du document HTML et celles des ressources concernées. Conservez le statut, les en-têtes de cache et, lorsqu’elle existe, une information de version. N’en déduisez pas une durée universelle : la configuration du service et les directives reçues comptent.
Cette recherche est distincte du diagnostic de LCP. Une page rapide peut être ancienne ; une page à jour peut rester lente. Pour comparer des mesures, gardez les conditions du contrôle laboratoire et terrain.
Exemple fictif : texte ancien, image récente
Un site imaginaire publie une nouvelle fiche avec un titre modifié et une image portant un nouveau nom. L’image apparaît correctement, mais le titre reste ancien. Une hypothèse est que le document HTML et l’image ne suivent pas la même politique de cache.
Commencez par examiner le fichier HTML déployé. S’il contient déjà le titre ancien, le problème précède la distribution. S’il contient le nouveau titre, comparez la réponse publique dans une autre session et le comportement après revalidation.
L’exemple est une démarche proposée, pas un incident observé. Aucune durée de cache, performance ou réussite de purge n’est attribuée à un hébergeur.
Préparer une décision limitée
| Observation | Hypothèse à vérifier | Action prudente |
|---|---|---|
| Source déployée ancienne | Mauvais artefact publié | Vérifier la version de publication |
| Source récente, réponse ancienne | Distribution conserve une version | Examiner la politique du service |
| Une session seulement diffère | Cache local ou état de session | Comparer avec une session distincte |
| Asset changé sous même nom | Ressource réutilisée | Préparer un nom lié à la version |
Une purge générale n’explique pas la cause et peut rendre un nouvel essai moins comparable. Si une invalidation ciblée est appropriée, documentez ce qui a été invalidé, à quel moment et avec quel résultat public.
Gardez un retour arrière : fichier précédent, version actuelle et consignes d’exploitation. La nouvelle politique doit être relue avec la personne qui gère le déploiement ; elle ne se copie pas indistinctement du HTML vers les assets.
Questions fréquentes
Recharger plusieurs fois prouve-t-il que le cache est vidé ?
Non. Relevez les réponses et comparez le contenu attendu. Des rechargements successifs peuvent produire le même résultat sans identifier le système qui conserve la version.
Une adresse avec une requête règle-t-elle définitivement le problème ?
Elle peut servir à un essai, mais son comportement dépend de la configuration. Elle ne remplace pas une politique de versions et de cache cohérente.
Faut-il supprimer le cache pour toutes les ressources ?
Évitez une décision globale sans diagnostic. Le document et les ressources versionnées n’ont pas nécessairement les mêmes besoins ; examinez chacun dans son rôle.
Sources
Documentation consultée lors de la relecture du 6 octobre 2026.