Ancien tarif encore affiché : maîtriser le cache de votre site web

Vous modifiez un tarif ou vos horaires. Dans l’administration du site, tout semble correct. Pourtant, un collègue ouvre la page et retrouve l’ancienne information. Avant de republier plusieurs fois, cherchez quelle version lui est réellement envoyée.

Le cache conserve des réponses pour les réutiliser. Cette copie peut se trouver dans le navigateur ou dans un cache partagé, notamment un réseau de diffusion de contenu, appelé CDN. Plusieurs visiteurs peuvent alors recevoir une même réponse enregistrée. C’est le fonctionnement décrit par la norme HTTP sur la mise en cache.

Pour une PME, la bonne question est concrète : après une modification importante, comment vérifier que la version attendue apparaît dans les conditions normales de consultation ? Voici une méthode à préparer avec votre prestataire.

1. Définir ce qui doit changer, et quand

Prenons un exemple fictif : une entreprise corrige le tarif public d’une prestation. Avant toute intervention, elle relève l’adresse exacte de la page, l’ancien montant, le nouveau montant et l’heure de publication souhaitée.

Ajoutez les autres emplacements où cette information apparaît : page d’accueil, fiche détaillée, document téléchargeable, page de demande de devis. Une mise à jour doit avoir un périmètre explicite. Si le tarif a été copié dans plusieurs contenus, commencer par contrôler ces contenus évite d’attribuer trop vite le problème au cache.

Décidez aussi du délai acceptable. Une correction urgente et une nouvelle photo d’équipe n’ont pas la même contrainte. Demandez au prestataire de traduire ce besoin en règle vérifiable, plutôt que de choisir arbitrairement une durée identique pour tout le site.

2. Reproduire l’écart avant de modifier les réglages

Gardez une capture de l’ancien affichage avec l’adresse et l’heure. Vérifiez ensuite que la modification est publiée sur le bon site, dans la bonne langue, et pas seulement enregistrée en brouillon.

Comparez une consultation habituelle et une consultation de diagnostic. Dans Chrome, ouvrez les outils de développement, puis le panneau Network. La case « Disable cache » permet de désactiver le cache du navigateur pendant ce contrôle. Rechargez la page en gardant les outils ouverts, puis relevez le résultat. La documentation Chrome DevTools décrit cette fonction.

Ce test porte sur le navigateur ; il ne constitue pas une purge du CDN. Présentez donc les observations comme des indices : « l’ancien montant apparaît en consultation habituelle, le nouveau dans ce test ». Si les deux affichages restent anciens, poursuivez l’enquête sur la publication et les autres couches de cache.

Avant de conclure, décochez « Disable cache » ou fermez les outils de développement, puis refaites une visite normale. Le but est que les clients voient la bonne information sans manipulation technique.

3. Demander une règle par type de contenu

Votre prestataire peut inspecter l’en-tête HTTP Cache-Control pour comprendre les consignes envoyées aux caches. Quelques termes suffisent pour discuter du besoin :

• « max-age » définit une durée de fraîcheur en secondes ;
• « no-cache », sans argument, autorise le stockage, mais impose une validation réussie avant réutilisation ;
• « no-store » demande de ne pas stocker la réponse ;
• « private », sans argument, interdit le stockage dans les caches partagés ; un cache privé, comme celui du navigateur, peut conserver la réponse si les autres règles le permettent.

Ces distinctions viennent de la norme HTTP, section Cache-Control. Elles concernent les réponses HTTP ; elles ne garantissent pas l’actualisation d’un onglet déjà ouvert. « Private » et « no-store » ne suffisent pas à garantir la confidentialité des données : la norme le précise, et ces consignes de cache ne remplacent pas les contrôles d’accès aux pages personnalisées.

Pour votre cadrage, séparez les pages commerciales à actualiser, les fichiers de présentation et les pages personnalisées. Faites préciser les réglages réellement appliqués par l’hébergement et le CDN, ainsi que leurs exceptions. Évitez de copier une configuration trouvée en ligne sans vérifier son effet sur votre site.

La décision attendue peut tenir en une phrase : « Lorsqu’un tarif change, voici les pages concernées, le mécanisme de mise à jour et le contrôle à effectuer. »

4. Purger au bon endroit

Une purge retire une copie stockée dans le système visé. Demandez donc toujours : quel cache est vidé, pour quelles adresses, et comment le résultat sera-t-il contrôlé ?

Cloudflare propose, par exemple, une purge par URL. Sa documentation précise que certaines clés de cache personnalisées nécessitent un traitement adapté. Elle indique aussi que purger une adresse de redirection ne purge pas le contenu situé à destination. Ces détails montrent l’intérêt de fournir au prestataire les adresses effectivement consultées. Source : Cloudflare, purge par fichier.

La purge du CDN ne retire pas les copies déjà enregistrées dans les navigateurs des visiteurs. Modifier aujourd’hui un en-tête ne suffit pas non plus à rappeler une réponse encore réutilisée sans nouvelle requête. Ce point est expliqué dans la documentation MDN sur les réponses déjà stockées.

Pour une correction sensible, demandez une procédure complète : vérifier la version publiée, traiter les caches concernés, puis contrôler les pages publiques. Gardez une trace du résultat, plutôt qu’un simple message « cache vidé ».

5. Donner une adresse distincte aux nouveaux fichiers

Pour des ressources statiques, comme une feuille de styles ou une image, une stratégie consiste à changer leur adresse lorsque leur contenu change. Le navigateur demande alors une nouvelle ressource. MDN décrit ce mécanisme de versionnement des fichiers.

Vous pouvez appliquer ce principe à une brochure : préparer une nouvelle version identifiable, mettre à jour les liens concernés, puis ouvrir le fichier depuis la page publique. Vérifiez son contenu, pas seulement son nom.

Prévoyez séparément le devenir des anciennes brochures. Un nouveau lien sur le site ne remplace pas les fichiers déjà téléchargés ou envoyés par email. Pour une information commerciale importante, demandez à l’équipe quels documents elle utilise encore avant de considérer la mise à jour terminée.

6. Ajouter une courte recette de publication

Préparez une fiche que la personne chargée des contenus pourra réutiliser :

1. Information modifiée et version attendue.
2. Liste des pages et fichiers concernés.
3. Heure de publication et responsable du contrôle.
4. Action de purge prévue, si nécessaire.
5. Résultat d’une consultation normale sur ordinateur et téléphone.
6. Personne à contacter si l’ancienne version persiste.

Testez cette fiche sur un changement sans enjeu commercial avant de l’utiliser pour un tarif urgent. Demandez aussi quoi faire si la nouvelle publication est incorrecte : quelle version rétablir, qui décide, et quelles vérifications reprendre ?

Un site bien maintenu doit rendre ses mises à jour compréhensibles pour l’équipe qui publie. Pour cadrer ce travail, partez d’une page importante et d’un exemple d’information restée ancienne. Vous pouvez décrire votre besoin à KADRI AI pour préparer les vérifications adaptées à votre site.

Sources consultées le 18 octobre 2026. L’exemple est fictif ; les étapes pratiques constituent une méthode proposée, sans résultat client ni gain chiffré revendiqué.