Pourquoi une ancienne version du site reste visible après une mise à jour
La correction est bien en production. Le serveur renvoie le nouveau fichier, l’équipe le voit sur ses ordinateurs, mais un utilisateur continue d’obtenir l’ancienne page. Il actualise. Rien ne change.
Lors d’un contrôle du site BizBet Afrique, comme de n’importe quel autre domaine, vider le cache du serveur ne prouve pas que chaque visiteur recevra aussitôt la dernière version. Une copie peut encore se trouver dans le navigateur, sur un nœud CDN ou dans le stockage géré par un service worker. Il faut d’abord savoir laquelle répond.
Une requête peut rencontrer plusieurs caches
Le mot « cache » donne l’impression d’un seul dossier temporaire. Sur un site actuel, plusieurs couches peuvent intervenir.
Le navigateur conserve des fichiers sur l’appareil. Le CDN les rapproche géographiquement du visiteur. Un reverse proxy peut ajouter une copie près du serveur d’origine. Enfin, une application web progressive peut intercepter la requête grâce à son service worker.
| Couche | Où se trouve la copie ? | Qui la contrôle principalement ? |
|---|---|---|
| Cache du navigateur | Appareil du visiteur | En-têtes HTTP et navigateur |
| Cache CDN | Nœud situé entre le visiteur et l’origine | Règles CDN |
| Reverse proxy | Infrastructure du site | Configuration du serveur |
| Cache du service worker | Stockage local de l’application web | Code JavaScript |
| Cache applicatif | Mémoire ou base côté serveur | Code de l’application |
Une actualisation ordinaire ne contourne pas forcément toutes ces couches. Elle peut demander au navigateur de vérifier son contenu tout en laissant le CDN ou le service worker répondre avec une autre copie.
no-cache ne veut pas dire « ne rien stocker »
Les noms des directives HTTP prêtent à confusion. Cache-Control: no-store demande de ne pas enregistrer la réponse. no-cache, malgré son nom, autorise le stockage mais impose une revalidation avant réutilisation. Le navigateur peut donc conserver le fichier, puis demander au serveur s’il a changé.
Deux en-têtes facilitent cette vérification : ETag, qui identifie une version précise du contenu, et Last-Modified, qui indique une date de modification. Le client envoie ensuite If-None-Match ou If-Modified-Since. Si la copie reste valable, le serveur répond 304 Not Modified sans renvoyer tout le fichier.
Ce mécanisme économise du transfert. Il peut aussi révéler une mauvaise configuration lorsque le serveur affirme par erreur qu’un fichier modifié est resté identique.
Le service worker peut servir sa propre version
Le cas le plus déroutant apparaît souvent dans une PWA. Un service worker peut intercepter les requêtes avant qu’elles ne suivent le trajet habituel. Il choisit alors entre le réseau et la Cache Storage API. La stratégie cache first privilégie la copie locale, network first tente le serveur puis revient au cache en cas d’échec, et stale while revalidate affiche immédiatement la copie connue et télécharge la suivante en arrière-plan.
Cette dernière stratégie donne une page rapide, mais l’utilisateur peut voir l’ancien contenu lors de la première ouverture. La version récente n’apparaît qu’à la suivante.
Une autre subtilité vient du cycle de vie. Le nouveau service worker peut être téléchargé sans prendre immédiatement le contrôle. Tant que les anciens onglets restent ouverts, l’ancienne version peut continuer à fonctionner.
Lors d’un déploiement, il faut donc prévoir :
- un nom de cache différent pour la nouvelle version ;
- la suppression des anciens caches après activation ;
- un message proposant d’actualiser la page ;
- une stratégie distincte pour le HTML et les fichiers statiques ;
- un test avec un onglet déjà ouvert avant la mise à jour.
La Cache Storage API ne remplace pas automatiquement un fichier simplement parce que celui-ci a changé sur le serveur. Le code doit organiser cette mise à jour.
Tester l’URL exacte, pas seulement l’accueil
Une page d’accueil récente ne prouve pas que toutes les routes le sont. Les règles de cache peuvent dépendre du chemin, de la langue, du type d’appareil ou de paramètres de requête. Une page dynamique peut contourner le CDN alors qu’une autre reste stockée plusieurs heures.
Pour tester une adresse précise comme https://africa-bizbet.com/fr/live/football, il faut examiner la requête correspondante dans les outils réseau, avec son URL complète, ses redirections et ses en-têtes.
Quelques indices sont particulièrement utiles :
Age, qui indique depuis combien de temps une réponse se trouve dans un cache partagé ;Cache-Control, qui décrit la durée et les conditions de réutilisation ;ETagetLast-Modified, utilisés pour la revalidation ;- un en-tête propre au CDN signalant
HIT,MISS,BYPASSou une mise à jour ; - la présence d’un service worker dans le panneau Application.
Tester en navigation privée aide, mais ne remplace pas l’analyse. Ce mode possède lui aussi un cache temporaire, simplement séparé du profil principal.
Une procédure courte pour localiser la copie
Commencez au plus près de l’origine, puis avancez vers le visiteur.
- Demandez directement le fichier au serveur d’origine.
- Comparez sa taille, son ETag ou son contenu avec la version attendue.
- Recommencez par le domaine public afin d’inclure le CDN.
- Ouvrez les outils réseau et désactivez temporairement le cache du navigateur.
- Vérifiez si un service worker contrôle la page.
- Supprimez seulement la couche identifiée, puis refaites exactement la même requête.
Le bouton « tout purger » donne parfois l’impression d’avoir réglé le problème. Il efface surtout les indices.
Une ancienne page n’est pas nécessairement restée sur le serveur. Elle peut avoir été livrée par une couche placée bien avant lui. Trouver cette couche prend quelques minutes de plus ; cela évite de redémarrer, supprimer et redéployer au hasard.
Vous pourriez aussi aimer
