Cache : pourquoi vous ne voyez pas vos modifications.

« J'ai regardé, je ne vois rien de changé. »

Cette phrase, je l'ai entendue des dizaines de fois, et pendant longtemps elle me faisait douter. Je rouvrais le dossier, je vérifiais que j'avais bien mis en ligne, je rechargeais la page de mon côté. Tout était là. Chez moi.

J'ai mis un moment à comprendre que dans la quasi-totalité des cas, le fichier était bien publié. C'est la copie que la personne avait sous les yeux qui datait de la veille.

Un cache, c'est une copie gardée sous la main

Quand vous ouvrez un site, votre navigateur ne se contente pas d'afficher la page. Il télécharge aussi tout ce qu'il y a autour : la feuille de style qui donne les couleurs et les espacements, les scripts, les images, les polices. Ces fichiers sont souvent identiques d'une page à l'autre et d'une visite à l'autre.

Alors le navigateur en garde une copie sur votre disque. À la visite suivante, plutôt que de tout redemander au serveur, il ressort ce qu'il a déjà. C'est plus rapide, ça consomme moins de données, et sur une connexion mobile moyenne la différence se sent immédiatement.

Ce mécanisme n'est pas un défaut, c'est une des raisons pour lesquelles le web reste supportable. L'ennui commence quand la copie gardée n'est plus la bonne et que le navigateur ne le sait pas.

Le test qui prend trente secondes

Avant tout le reste, vérifiez que c'est bien de ça qu'il s'agit.

Sur la page concernée, faites Ctrl + Maj + R sous Windows, Cmd + Maj + R sur Mac. C'est un rechargement forcé, et la documentation de Chrome précise qu'il contourne le cache sans pour autant le vider.

Si vos modifications apparaissent d'un coup, vous avez votre réponse : tout était en ligne depuis le début. Si rien ne bouge, le problème est ailleurs, et là il faut effectivement appeler votre prestataire.

Ce test vaut dans les deux sens. Quand quelqu'un me dit qu'il ne voit rien, je lui demande de le faire avant qu'on aille plus loin. La question se règle en une manipulation, sans que personne ait à se justifier.

Trois endroits où une vieille copie peut dormir

• Votre navigateur. Le cas le plus fréquent, et le seul que le rechargement forcé traite. Chaque visiteur a le sien, ce qui explique que vous voyiez l'ancienne version pendant que votre associé voit la nouvelle.
• Un cache intermédiaire. Beaucoup de sites passent par un service qui garde des copies au plus près des visiteurs pour accélérer le chargement. Cette couche a sa propre mémoire, et elle se purge séparément. Votre prestataire sait le faire, vous pas, et c'est normal.
• Le serveur lui-même. Certains hébergements, et la plupart des CMS, ajoutent encore leur propre cache. Une page peut y rester figée alors que le fichier a bien été remplacé.

Trois couches, trois mémoires, qui ne se vident pas ensemble. Quand une mise en ligne « ne prend pas », c'est presque toujours l'une des trois.

Ce qui devrait rendre tout ça inutile

Le vrai correctif ne consiste pas à demander aux visiteurs de vider leur cache. Personne ne le fera, et vous ne pouvez pas le leur demander.

La bonne méthode est documentée depuis longtemps sous le nom de cache-busting. Le principe tient en une idée : on ne modifie jamais un fichier en place, on en publie un nouveau sous une autre adresse.

Concrètement, la feuille de style ne s'appelle plus style.css mais quelque chose comme style.a91f3c.css, où la suite de caractères dépend du contenu du fichier. Vous changez une couleur, le contenu change, l'empreinte change, le nom change. Le navigateur voit alors une adresse qu'il n'a jamais rencontrée, il n'a donc aucune copie à réutiliser, il la télécharge. Sans que personne ait eu à demander quoi que ce soit à personne.

Ces fichiers-là peuvent du coup être conservés très longtemps, jusqu'à un an dans les recommandations publiées par Google, puisqu'ils ne changeront jamais : c'est leur remplaçant qui portera un autre nom.

Le fichier HTML, lui, reçoit une consigne différente. On lui applique no-cache, qui ne veut pas dire « ne le garde pas » mais « garde-le, et demande-moi à chaque fois s'il a bougé ». La page reste donc toujours à jour, pendant que tout ce qui pèse autour reste rapide.

Un site bien construit n'a pas besoin qu'on explique le cache à ses visiteurs.

Une façon de juger votre prestataire

Si à chaque mise à jour on vous répond « videz votre cache », c'est un contournement, pas une réparation. La question à poser tient en une phrase, et vous pouvez la reprendre telle quelle : est-ce que mes fichiers portent une empreinte dans leur nom ?

Sur les sites que je construis sans CMS, la question ne se pose plus, le nom des fichiers change à chaque mise en production. C'est un des avantages discrets du sur-mesure, beaucoup moins spectaculaire qu'une belle animation, et nettement plus reposant au quotidien.

Je précise quand même une chose, parce que je me suis trompé là-dessus plus d'une fois. Il arrive que le client ait raison et que ce soit bien moi qui n'aie pas publié. Le rechargement forcé sert justement à ne pas accuser le cache à tort.

Vingt minutes, cette semaine

Ouvrez votre site, faites le rechargement forcé, notez ce qui se passe.

Regardez ensuite le nom de vos fichiers. Clic droit sur la page, « afficher le code source », puis cherchez les lignes qui appellent une feuille de style ou un script. Si vous y voyez un .css tout nu, sans suite de chiffres et de lettres ni de ?v= derrière, vous savez déjà que chaque mise à jour vous exposera au problème.

Ce n'est pas dramatique et ça se corrige. Mais autant le savoir avant la prochaine fois où vous direz à quelqu'un « regardez, c'est en ligne », et où cette personne ne verra rien du tout.

Si vous voulez qu'on regarde ça ensemble, demandez un devis. Les questions qui reviennent le plus souvent sont déjà traitées dans la FAQ.

Sources

• HTTP caching, MDN Web Docs, Mozilla. Source primaire, consultée le 19 août 2026.
• Cache-Control header, MDN Web Docs, Mozilla. Source primaire, consultée le 19 août 2026.
• Prevent unnecessary network requests with the HTTP Cache, web.dev, Google. Source primaire, consultée le 19 août 2026.
• Hard reload, blog Chrome for Developers, Google. Source primaire pour le comportement du rechargement forcé, consultée le 19 août 2026.
• Serve static assets with an efficient cache policy, Lighthouse, Chrome for Developers. Source primaire pour la durée de conservation d'un an.

Questions fréquentes

Pourquoi je ne vois pas les modifications de mon site alors qu'il est à jour ?

Votre navigateur conserve une copie des fichiers du site pour ne pas les retélécharger à chaque visite. Tant qu'il considère cette copie valable, il l'affiche au lieu de demander la nouvelle version. Le fichier est bien en ligne, c'est votre copie locale qui date.

Comment forcer un navigateur à recharger la vraie version d'une page ?

Faites Ctrl + Maj + R sous Windows ou Cmd + Maj + R sur Mac. Ce rechargement forcé contourne le cache selon la documentation de Chrome. Si les modifications apparaissent alors, elles étaient en ligne depuis le début.

Comment éviter le problème du cache à chaque mise à jour du site ?

En changeant le nom des fichiers à chaque publication, avec une empreinte du contenu dans le nom, par exemple style.a91f3c.css. Le navigateur découvre une adresse inconnue, n'a aucune copie à réutiliser et télécharge la nouvelle version sans intervention du visiteur.

Sur le même sujet : pourquoi une petite modification n'est pas rapide, et pourquoi je ne livre pas de site WordPress.