Actualiser le CSS et le JavaScript mis en cache par le navigateur

Si un déploiement modifie le CSS ou le JavaScript mais conserve la même URL, certains navigateurs peuvent réutiliser une copie encore valide. Les nouveaux en-têtes n'arrivent que lorsque le navigateur redemande cette URL : le serveur ne peut pas vider à distance une réponse que le client considère encore comme fraîche.

Vérifiez d'abord dans l'onglet Réseau / Network des outils du navigateur quelle URL est chargée, son statut, Cache-Control, Age, ETag, et si la réponse vient du navigateur, d'un service worker ou d'un CDN. Vous distinguerez ainsi le cache HTTP des autres couches.

Changer l'URL de la ressource

La solution fiable consiste à publier chaque version sous une nouvelle URL. De préférence, utilisez des noms contenant un hash du contenu :

<link rel="stylesheet" href="https://static.example.com/css/app.abc123.css">
<script src="https://static.example.com/js/app.abc123.js"></script>

Vous pouvez aussi ajouter une version à l'URL, par exemple /css/app.css?v=20260825, si votre application et les caches intermédiaires respectent les paramètres de requête.

Servez le HTML non versionné avec Cache-Control: no-cache pour qu'il soit revalidé et pointe vers les nouvelles ressources. no-cache autorise le stockage, mais exige une validation avant réutilisation. Conservez ETag ou Last-Modified : ils permettent de répondre 304 Not Modified sans retélécharger une ressource identique.

Les ressources avec hash peuvent avoir une longue durée d'expiration, car leur URL change avec le contenu. S'il existe un CDN ou un service worker, mettez aussi à jour son manifeste ou lancez la purge propre à cette couche. Ne gardez pas pendant des semaines des règles globales no-store, ne supprimez pas les validateurs et n'utilisez pas Pragma comme substitut général de Cache-Control.

Consultez le guide sur le cache HTTP et les URL versionnées et la référence de Cache-Control.

Éviter qu'un déploiement casse les sessions ouvertes

Publiez d'abord les nouveaux fichiers, puis le HTML qui les référence. Conservez pendant une période de transition les ressources de la version précédente : un onglet ouvert peut continuer à les demander. Les supprimer immédiatement peut provoquer des 404 alors que les nouvelles visites fonctionnent.

Si l'application utilise un service worker, testez une mise à jour avec un ancien onglet ouvert et un nouveau. Le HTML dynamique ou privé peut nécessiter une politique différente du HTML public ; n'appliquez pas un en-tête global sans examiner les sessions et les données sensibles.

Vérifiez l'URL finale, le contenu reçu et la version après le déploiement. Une réponse 304 peut être correcte lorsque la ressource n'a pas changé ; elle n'est pas à elle seule le signe d'un cache défaillant.