Un utilisateur te signale un bug. Tu vérifies : tu l'as corrigé la semaine dernière, c'est en production, ça marche chez toi et chez tout le monde que tu testes. L'utilisateur, lui, insiste, ça ne marche pas. Tu finis par lâcher la phrase magique : « fais Ctrl+Shift+R. » Et là, le bug disparaît d'un coup.
Son navigateur servait un fichier JavaScript vieux de plusieurs semaines. Pas par erreur : parce qu'un en-tête, que tu avais posé et oublié, lui disait de le garder longtemps sans rien revérifier. Tu avais corrigé le code. Son navigateur n'avait simplement jamais redemandé la nouvelle version.
Avant tout le reste, le navigateur se demande s'il a déjà
Tout ce qu'on a vu jusqu'ici, la résolution DNS, la poignée de main, le cadenas, la requête, ça coûte du temps. Alors avant de s'y lancer, le navigateur pose une question plus radicale : est-ce que je n'ai pas déjà ça sous la main ? C'est la première étape, avant même de traduire le nom en adresse.
S'il a une copie qu'il juge encore fraîche, il l'utilise sans contacter personne. Pas de DNS, pas de connexion, pas de requête. C'est ce qui rend une page déjà visitée quasi instantanée. Cette fraîcheur, c'est toi qui la fixes, via un en-tête, Cache-Control, où tu écris en substance « garde ce fichier pendant tant de temps ». Tant que ce délai n'est pas écoulé, le navigateur ne redemande rien : il te sert sa copie, point.
Quand le délai expire, il ne repart pas forcément de zéro. Il peut faire une vérification à moindre coût : « j'ai cette version, identifiée par cette étiquette (un ETag), est-elle toujours d'actualité ? » Le serveur répond soit « rien n'a changé, garde la tienne », une réponse minuscule et rapide, soit il renvoie la nouvelle. Le cache a donc deux régimes : ne même pas demander, ou demander mais pour pas cher.
Le piège est dans l'en-tête que tu oublies
Tout se joue dans ce délai que tu poses une fois. Mets un Cache-Control long sur un fichier qui ne change jamais, une image, une police : parfait, tes utilisateurs ne le retéléchargent plus. Mets le même délai long sur un fichier qui change, comme le JavaScript de ton application, et tes utilisateurs gardent l'ancienne version aussi longtemps que tu le leur as dit, même après que tu as déployé le correctif. Voilà pourquoi ton bug « corrigé » continue de vivre chez eux : le navigateur obéit à un ordre que tu lui as donné et oublié.
La parade classique tient en une astuce : mettre une empreinte dans le nom du fichier, app.a3f9.js. Change le code, l'empreinte change, donc le nom change, donc c'est une URL que le cache n'a jamais vue : il est obligé d'aller la chercher. Tu ne te bats plus contre le cache, tu le contournes proprement.
Ce que l'IA ne reproduira pas
Le cache est invisible jusqu'au jour où il mord, et il mord toujours de la pire façon : un bug que tu ne reproduis pas. Chez toi tout va bien, la trace d'erreur ne dit rien, parce que le problème n'est pas dans le code. Il est dans un en-tête et dans la mémoire d'un navigateur qui n'est pas le tien. L'IA te génère l'application, pas ta stratégie de cache, et ce « ça marche chez moi pas chez lui » est exactement le genre de fantôme qu'aucune génération ne t'expliquera. Comprendre le cache, c'est ce qui transforme un spectre impossible à reproduire en un correctif d'une ligne.
Ce que je te conseille
Mets en cache sans retenue ce qui ne change jamais, à condition de lui donner un nom qui change quand son contenu change. Sois prudent avec ce qui bouge : délai court, ou revalidation. Et quand un utilisateur te décrit un bug que tu sais mort et enterré, soupçonne le cache avant de douter de toi-même. Le DNS te mentait sur l'adresse du serveur. Le cache, lui, te ment sur la version du fichier, et c'est un mensonge que tu as toi-même autorisé.
Un navigateur optimise la vitesse en pariant que ce qu'il a déjà est encore bon. La plupart du temps, il gagne son pari. Ton travail, c'est de savoir exactement quand tu lui as donné le droit d'avoir tort.
Ce satellite ouvre le dossier Navigateur : c'est la toute première chose que fait un navigateur, avant la résolution DNS. Le vocabulaire : le cache HTTP, le Cache-Control, l'ETag et la revalidation.