Purger un cache vide : savoir qui garde la copie avant de nettoyer

« Nettoie le cache pour que la photo s'affiche. » La demande est raisonnable, l'action évidente. Sauf qu'il n'y avait rien à purger : la copie de vingt-quatre heures était dans le navigateur, et aucune commande serveur ne peut l'effacer.

1. La demande

Une photo de profil ne s'affiche pas à jour. L'utilisateur voit l'ancienne image, ou une image vide. Il demande — légitimement — qu'on vide le cache.

Dans la plupart des équipes, cette phrase déclenche un geste : on ouvre la console du fournisseur de diffusion, on cherche le bouton de purge, on clique, on annonce que c'est fait. Le geste est rapide, rassurant, et souvent sans effet.

Cette fois, nous avons commencé par mesurer.

2. Ce que disaient les en-têtes

Un curl sur l'adresse de l'image, avec les en-têtes complets, donne trois informations décisives :

• cf-cache-status : absent. Le réseau de diffusion n'a pas servi cette requête depuis une copie locale. Si la copie existait, l'en-tête serait là, avec un âge. Il n'y a rien.
• age : absent. Confirmation : aucune copie n'a été conservée côté diffusion.
• cache-control: public, max-age=86400 et aucun ETag.

Autrement dit : le réseau de diffusion transmettait l'image sans la garder, en demandant à l'appelant de la garder vingt-quatre heures. La copie de vingt-quatre heures vivait donc dans le navigateur de l'utilisateur, sur son poste.

Purger le réseau de diffusion revenait à nettoyer un placard vide. Et rien, côté serveur, ne peut effacer une copie déjà stockée dans un navigateur sur un autre continent.

3. Le malentendu de la purge

« Purger le cache » est une expression qui masque un problème de topologie. Un cache n'est pas un objet : c'est un rôle, tenu par plusieurs acteurs à la fois.

Entre la source et l'œil de l'utilisateur, il y a au moins :

• le serveur d'origine, qui peut mettre en cache en mémoire ou sur disque ;
• le proxy inverse de l'hébergeur ;
• le réseau de diffusion, avec ses points de présence régionaux ;
• le navigateur, avec son cache HTTP, doublé d'un cache mémoire pour la session en cours ;
• parfois un proxy d'entreprise ou un opérateur mobile.

Chacun a ses règles, ses durées, ses clés. Purger chez l'un ne dit rien des autres. Tant qu'on ne sait pas qui garde la copie, la purge est un rituel : une suite de gestes sans rapport avec la cause.

4. Le correctif : revalidation plutôt que purge

La bonne réponse n'était pas de purger plus fort, mais de rendre la copie périssable et vérifiable.

Deux changements ont été déployés :

• durée courte et revalidation obligatoire : max-age=300, must-revalidate au lieu de vingt-quatre heures ;
• empreinte forte : un ETag calculé sur le contenu de l'image, stable tant que le fichier ne change pas.

L'effet est immédiat et mesurable : au bout de cinq minutes, le navigateur redemande l'image avec l'empreinte connue (If-None-Match). Si le fichier n'a pas changé, le serveur répond 304, zéro octet. Si le fichier a changé, il renvoie l'image et la nouvelle empreinte.

C'est le meilleur des deux mondes : pas de bande passante gaspillée quand rien ne change, pas de copie périmée quand quelque chose change.

5. La preuve, et ce qu'elle a coûté

Le déploiement n'a pas été direct. L'outil en ligne de commande du fournisseur a refusé l'opération avec un code d'erreur d'autorisation, alors que le même jeton fonctionnait par appel direct à l'interface de programmation — un défaut d'outillage, pas un problème de droits. L'opération a donc été faite par l'interface de programmation, avec la version précédente sauvegardée pour permettre un retour arrière.

Preuves après déploiement :

• en-têtes servis : cache-control: public, max-age=300, must-revalidate, etag présent ;
• requête conditionnelle : 304, zéro octet ;
• empreinte du corps servi identique, octet pour octet, à la source dans le dépôt ;
• contrôle anti-dérive : quarante-deux clés comparées, aucune divergence.

Un point d'honnêteté : pour la session en cours de l'utilisateur, un rechargement forcé restait nécessaire une fois. L'ancienne consigne « garde vingt-quatre heures » était déjà en mémoire ; aucune correction serveur ne rattrape une instruction déjà reçue.

6. Les leçons

Première : « purger » n'est pas un geste, c'est un diagnostic. La bonne question est « qui détient la copie, et depuis quand ? ». Les en-têtes répondent à cette question ; le bouton de purge, non.

Deuxième : un cache sans empreinte est un cache aveugle. Sans ETag, le seul moyen de savoir si une copie est encore valable est de retélécharger ou d'attendre l'expiration. L'empreinte transforme une attente en vérification.

Troisième : une durée longue est une dette différée. max-age=86400 est parfait pour une image qui ne changera jamais, désastreux pour une image qui peut changer. La durée doit être choisie par ressource, pas par confort.

Quatrième : distinguer le cache du réseau et le cache du poste. Le premier se configure, le second s'obtient par la conception. On ne « purge » pas un navigateur : on lui donne les moyens de vérifier.

7. Ce que ça change

Depuis, chaque ressource servie par nos interfaces porte une politique explicite : durée, revalidation, empreinte. Et nous avons ajouté une habitude simple : avant d'annoncer une purge, afficher les en-têtes.

Cela évite deux choses également coûteuses : annoncer une action qui n'a rien changé, et faire porter à l'utilisateur la responsabilité d'un nettoyage que la conception aurait dû rendre inutile.

À retenir. Un cache est un rôle tenu par plusieurs acteurs. Avant de purger, lisez les en-têtes : s'il n'y a pas d'âge ni d'état de cache, la copie est ailleurs — souvent dans le navigateur, hors de portée. Préférez une durée courte et une empreinte forte à une purge sans effet.