Pourquoi mon site affiche-t-il encore l'ancienne version ?

Votre site va bien. C'est la copie devant lui qui est vieille.

Publier écrit une nouvelle version de la page sur votre origine, c'est-à-dire le serveur ou le bucket de stockage dans lequel votre hébergeur lit réellement. Rien dans cette étape ne garantit que vos visiteurs parlent à votre origine. Entre les deux se trouvent votre navigateur, le plus souvent un réseau de diffusion de contenu, parfois un service worker installé par votre framework, et de temps en temps un proxy sur le réseau du visiteur lui-même. Chacun conserve une copie et une règle sur la durée pendant laquelle il lui fait confiance, et chacun répondra à une requête sans demander l'avis de personne.

La signature de ce problème est l'incohérence. Vous voyez la nouvelle page, votre client non. Deux personnes reçoivent des versions différentes de la même adresse. Une heure plus tard, c'est réglé sans le moindre déploiement. Ce motif vaut la peine d'être appris, car une mise en production réellement cassée est cassée pour tout le monde en même temps : si certains n'ont aucun souci, arrêtez de lire le journal de build et cherchez plutôt qui répond à la requête. La règle qui se cache sous la première est celle qui surprend : beaucoup de caches ne se contentent pas de garder une copie jusqu'à son expiration, ils continuent de servir la copie expirée pendant qu'ils en cherchent une fraîche en arrière-plan. Expirée ne veut pas dire hors service, et c'est ainsi qu'une page survit largement à sa propre durée de vie.

Identifiez la couche avant de réparer quoi que ce soit

Chaque étape ci-dessous élimine un cache, dans l'ordre qui vous coûte le moins. Descendez la liste et arrêtez-vous à la première qui affiche la nouvelle page : c'est votre réponse, et la solution est une purge à cette couche, pas un déploiement de plus.

1. Ouvrez-la dans une fenêtre privée. Si la nouvelle version y apparaît, la copie ancienne n'existait que dans votre propre navigateur et aucun visiteur n'a été touché. Un rechargement forcé dans votre fenêtre habituelle et c'est fini. C'est l'issue la plus fréquente et l'étape la plus souvent sautée, ce qui explique que la panique dure en général plus longtemps que le bug.
2. Ajoutez un paramètre d'URL sans signification. Chargez la même adresse avec quelque chose comme ?x=1 à la fin. La plupart des caches partagés traitent cela comme une autre URL et vont la chercher à l'origine : une page fraîche ici signifie donc que votre origine est correcte et que quelque chose entre vous et elle continue de servir l'ancienne copie sous l'adresse propre.
3. Ouvrez-la depuis un autre réseau. Un téléphone en données mobiles plutôt que le Wi-Fi du bureau. Un réseau de diffusion de contenu garde des copies distinctes dans des emplacements distincts : cette étape sépare donc une périphérie périmée de quelque chose que tous les visiteurs reçoivent. Et c'est la seule version du test qui reflète ce qu'un inconnu voit vraiment.
4. Interrogez l'origine directement. Récupérez la page depuis le tableau de bord de votre hébergeur, un aperçu côté serveur, ou une requête adressée à l'origine et non à l'adresse publique. Si l'origine est juste et l'URL publique fausse, le problème vit entièrement dans la diffusion, et rien dans votre code ni dans votre build ne le déplacera.

Une fois la couche connue, purgez ou invalidez à cet endroit, puis répétez la troisième étape depuis un réseau que vous ne contrôlez pas. Confirmer un correctif depuis sa propre machine est la manière dont on finit certain qu'une purge a fonctionné alors qu'elle n'a rien fait.

La version de tout cela qui nous a coûté une heure

Nous hébergeons des pages pour nos propres clients : c'est donc notre problème et pas seulement celui de nos lecteurs. Le 11 septembre 2026, nous avons trouvé une page que nous avions retirée et qui continuait d'être servie à quiconque l'ouvrait, cinquante-deux minutes après le retrait. Tout ce que nous pouvions voir de notre côté était correct : le fichier avait disparu du stockage et nos propres enregistrements indiquaient la page comme dépubliée. Le réseau de diffusion de contenu placé devant était configuré pour continuer à répondre avec sa dernière bonne copie pendant une journée entière tant qu'il revalidait en arrière-plan. Supprimé décrivait donc notre stockage et ne disait rien de ce que recevait un visiteur. Nous avons corrigé à deux endroits volontairement : dans la configuration du réseau, pour qu'il ne serve plus du tout de copies expirées, et dans les instructions de cache de la page elle-même, afin que cette limite ne dépende plus d'un réglage qu'un backend reconstruit remettrait silencieusement à sa valeur par défaut.

La règle que nous en avons tirée est la partie transposable : publié, mis à jour et supprimé sont des affirmations sur votre origine. Ce que reçoit un visiteur est un fait distinct, et la seule façon honnête de le connaître est de récupérer la page comme le ferait un inconnu. La même couche a aussi changé ce que nous pouvions mesurer. Les vues des pages que nous hébergeons sont enregistrées comme un plancher et non comme un total, parce qu'une requête servie en périphérie n'atteint jamais l'origine qui compte. Et tant que la diffusion de copies expirées était active, les requêtes de rafraîchissement de cache de notre propre réseau constituaient l'essentiel de ce compteur, jusqu'à ce que nous les excluions nommément. Un cache ne change pas seulement ce que les gens voient. Il change ce que vous pouvez prouver de ce qu'ils ont vu.

Cela a aussi changé la façon dont nous écrivons les deux opérations. Publier envoie d'abord le fichier et enregistre ensuite, parce que l'ordre inverse enregistre une page en ligne alors que rien n'est servi. Dépublier supprime d'abord le fichier et marque l'enregistrement ensuite, parce que l'ordre inverse enregistre une page comme retirée alors qu'elle est encore debout. Quand la seconde moitié échoue, l'état que nous rapportons est faux dans le sens où il est prudent de se tromper. Se demander d'abord quel échec on préférerait constitue l'essentiel de ce que signifie tenir un site web avec soin, et c'est la même discipline que nous intégrons à AgentCeres, l'AI Growth Officer sur agentceres.com : une équipe de rôles spécialisés rédige les pages, les publications et la prise de contact, et tout ce qui sort attend par défaut l'approbation d'une personne. Si vous venez de publier un site pour la première fois, les vérifications de dois-je utiliser l'IA pour créer mon site ? sont l'autre moitié de cette page.