Empêcher le navigateur de mélanger un index.html neuf et un app.js en cache

Symptôme observé en production : après mise à jour, l'application restait
vide et aucune requête /api/ n'était émise. Le navigateur avait rechargé
index.html et les feuilles de style (nouveaux noms de fichiers) mais
servait app.js depuis son cache — la version précédente, qui référence
des identifiants disparus du nouveau balisage. Le script levait
« Cannot read properties of null » à l'évaluation et s'arrêtait avant
d'enregistrer ses gestionnaires et d'appeler boot().

index.html, app.js et les CSS gardant le même nom d'une version à
l'autre, ils sont désormais servis avec Cache-Control: no-cache : le
navigateur peut toujours les mettre en cache mais doit les revalider, ce
qui coûte un 304 quand rien n'a changé. Les polices, stables et
volumineuses, gardent un cache long.

Vérifié en simulant un redéploiement dans un navigateur au cache chaud :
app.js est revalidé et la nouvelle version prise en compte. Suite E2E
toujours à 62/62.

frontend/nginx.conf

@@ -26,7 +26,24 @@ server {
     proxy_set_header X-Forwarded-Proto $scheme;
   }
 
+  # index.html, app.js and the stylesheets keep the same filenames across
+  # releases, so without this a browser happily pairs a freshly fetched
+  # index.html with a cached app.js from a previous deploy. That mismatch
+  # throws on the first missing element id and kills the whole script — which
+  # looks exactly like a server-side failure. "no-cache" still allows caching,
+  # it only forces a revalidation, so unchanged files cost one 304.
+  location ~* \.(?:html|js|css)$ {
+    add_header Cache-Control "no-cache";
+    try_files $uri $uri/ /index.html;
+  }
+
+  # Fonts are content-stable and large; let them sit in the browser cache.
+  location ~* \.(?:woff2|woff|ttf)$ {
+    add_header Cache-Control "public, max-age=2592000";
+  }
+
   location / {
+    add_header Cache-Control "no-cache";
     try_files $uri $uri/ /index.html;
   }
 }