Le cache te ment plus longtemps que le DNS
Vingt minutes à croire qu'un correctif n'avait pas été déployé, alors qu'il était en ligne depuis le début. Le serveur répondait 200. Le navigateur affichait l'ancienne version.
Les trois mensonges d'un 200
Un code 200 veut dire « j'ai quelque chose à te montrer ». Il ne dit pas d'où vient ce quelque chose. Trois sources peuvent répondre à la place de votre serveur : le cache du navigateur, le CDN, et — cas plus vicieux — une page de stationnement sur un domaine mal configuré.
Ce jour-là, les trois étaient sur le chemin. Le fichier modifié était bien sur le disque, le serveur local le servait correctement, et l'utilisateur voyait encore l'ancien.
Ce qui m'a fait perdre du temps
Le test « qui marche » : demander le fichier avec un paramètre aléatoire pour casser le cache. La requête repart vers l'origine et revient avec la bonne version. Conclusion hâtive : « c'est déployé ». En réalité, on a testé une URL que personne ne visite.
La vérification honnête regarde les en-têtes de l'URL réelle :
cf-cache-status: HIT — servi par le cache, pas par l'origine.
age: 1685 — cette copie a vingt-huit minutes.
cache-control: max-age=14400 — quatre heures pendant lesquelles ça ne changera pas.
Trois lignes, et le diagnostic tombe sans discussion. Le correctif existait ; il n'était simplement pas encore visible.
La bonne réaction
Purger le cache de la zone — pour un site statique, tout purger coûte moins cher que réfléchir
à une sélection d'URL. Puis vérifier immédiatement que cf-cache-status repasse en
MISS et que age retombe à zéro.
Pour les correctifs urgents sur des fichiers statiques, une deuxième ceinture : versionner le
nom du fichier (style.css?v=3). Une nouvelle URL n'a pas d'historique, donc pas de
cache à contredire.
Le cousin : le domaine qui répond 200 en étant parqué
Même famille de piège, autre étage. Un domaine dont les serveurs de noms pointent encore vers un registrar répond 200 avec une page de stationnement. Techniquement vivant, éditorialement mort. Si on teste « est-ce que le site répond ? », la réponse est oui — et elle est fausse.
Le contrôle utile n'est pas le code HTTP, c'est le contenu : le titre de la page, la présence du vrai site, la correspondance entre ce qu'on attend et ce qui arrive. Un statut n'est pas une preuve.
Règle retenue
Après chaque déploiement, vérifier trois choses : le fichier sur l'origine, les en-têtes de l'URL publique, et le rendu réel dans un navigateur. Trois couches, trois réponses possibles. Quand une seule est contrôlée, les deux autres mentent en silence.
- cloudflare
- tunnel
- cache-control
- dns