Résumé

  • AppCache promettait qu’une application web resterait utilisable sans réseau. Une page désignait un manifeste, et le navigateur conservait les ressources énumérées. Pour remplacer un script ou une image déjà conservés, il fallait modifier le manifeste lui-même.
  • Si le manifeste ou une ressource requise ne se téléchargeait pas, toute la mise à jour échouait et l’ancienne version restait en service. À partir de 2020, Chrome a commencé à retirer AppCache et a orienté les développeurs vers les service workers. Le petit fichier de liste commandait en pratique la sortie d’une nouvelle version.

Le correctif est arrivé ; l’application est restée vieille

Un développeur remet en état son fichier JavaScript sur le serveur. Le navigateur continue pourtant d’ouvrir l’ancienne application. Le maillon manquant se trouve dans le manifeste AppCache : si cette liste ne change pas, la simple modification du script ne déclenche pas sa nouvelle mise en cache. Le guide technique publié par Google le disait sans détour. Il fallait changer le manifeste pour signaler au navigateur qu’un nouvel ensemble de fichiers devait être préparé.

C’était le prix singulier de la disponibilité hors connexion. Le navigateur gardait une application utilisable quand le réseau disparaissait, mais le fichier de liste devenait aussi le bouton de publication. Une ligne de commentaire portant une nouvelle version pouvait suffire à actionner ce bouton. Le code réparé sur le serveur attendait de l’autre côté de la porte.

Une liste pour garder le Web ouvert sans réseau

La note du W3C de mai 2008 partait d’un besoin réel : consulter une application web après avoir quitté la couverture réseau. Le cache HTTP ordinaire ne garantissait pas que tous les éléments utiles seraient présents. L’élément html pouvait donc porter un attribut manifest pointant vers un fichier text/cache-manifest. Celui-ci indiquait quels documents et ressources garder localement. Une section NETWORK: signalait les requêtes qui devaient continuer à passer par le réseau.

La promesse tenait dans cette liste explicite. Le navigateur n’avait plus à deviner quelles pièces d’une application méritaient de survivre hors ligne. En échange, la mise à jour devenait une opération collective. Le guide AppCache de Google précisait qu’un échec du téléchargement du manifeste ou d’un seul fichier déclaré faisait échouer toute l’actualisation. Le navigateur continuait alors à utiliser l’ancien cache complet. Même après l’arrivée d’un nouvel ensemble, une page déjà chargée n’utilisait pas aussitôt les nouveaux fichiers : elle devait être rechargée.

Cette prudence empêchait de monter une application à moitié remplacée. Elle pouvait aussi prolonger un bug alors que le serveur avait déjà son correctif. Modifier main.js sans toucher au manifeste ne suffisait pas. Modifier le manifeste mais oublier un fichier requis ne suffisait pas davantage. La question importante cessait d’être « le serveur contient-il la correction ? » ; elle devenait « le navigateur du lecteur a-t-il installé puis affiché un lot complet ? ».

Le manifeste trop calme et le manifeste trop pressé

La liste pouvait bloquer la sortie dans les deux sens. Si elle ne bougeait jamais, les anciennes ressources restaient en place. Si elle changeait constamment, par exemple avec une heure recalculée à chaque demande, le navigateur pouvait la relire pendant le téléchargement et constater que le paquet avait encore changé. Le guide de Google expliquait qu’il pouvait alors refuser un assemblage de fichiers provenant de deux versions et réessayer plus tard.

Les rubriques CACHE, NETWORK et FALLBACK ajoutaient une vraie politique applicative. Certains fichiers étaient conservés, certaines requêtes devaient atteindre le réseau, certains chemins recevaient une page de secours. Une faute dans un fichier requis pouvait empêcher tout le nouveau paquet d’entrer. La petite liste n’était donc pas un inventaire passif : elle fixait la frontière entre continuité et fraîcheur.

L’ancienne version gagnait lorsque la nouvelle n’était pas complète. Ce choix pouvait éviter de casser une application hors ligne. Il imposait aussi une discipline de publication que l’on pouvait manquer facilement en ne regardant que les fichiers déposés sur le serveur.

Chrome a fixé une date de sortie

Le plan de retrait publié par Chrome en 2020 prévoyait une sortie par étapes. Chrome 85 désactivait AppCache par défaut, avec une période supplémentaire accordée aux sites inscrits à un essai d’origine. Les service workers étaient proposés pour organiser l’expérience hors ligne autrement. Une règle de migration était décisive : dans Chrome, dès qu’un service worker contrôlait la page, AppCache n’y fonctionnait plus. Ajouter la moitié d’un nouveau cache et demander à l’ancien de compléter l’autre moitié ne formait pas une stratégie.

Le retrait obligeait les équipes à redéfinir la récupération des requêtes, la conservation des fichiers et l’adoption d’une nouvelle version dans un onglet déjà ouvert. Google précisait que son outil de transition reproduisait certains comportements d’AppCache, pas l’interface window.applicationCache et ses événements. Le calendrier de Chrome était celui d’un navigateur et d’une migration, pas un interrupteur mondial unique.

L’histoire d’AppCache tient dans cette contradiction pratique. La liste promettait de garder l’application accessible quand la connexion tombait. La même liste pouvait laisser un correctif en attente si elle n’était pas modifiée, ou si un fichier du paquet manquait. La page restait disponible hors ligne ; la réparation demeurait en ligne jusqu’à ce que le navigateur accepte le nouveau lot.