PWA · installation et cache

PWA, installation et hors ligne : capacités réelles, limites et vérifications

Comprendre ce que prouvent un manifeste et un service worker, expliquer l’installation par plateforme et concevoir un cache utile sans promettre un Store.

Site, PWA installable et application distribuée

Un site Web fonctionne dans un navigateur. Une Progressive Web App ajoute des métadonnées et des capacités susceptibles d’améliorer installation, lancement et usage hors ligne. Une application distribuée par un Store suit encore un autre canal. Ces états ne sont pas interchangeables et peuvent varier selon navigateur et système.

La présence d’un fichier manifest ne suffit pas à déclarer « Installez l’app ». Le site doit vérifier la liaison du manifeste, ses icônes, son start_url, son scope, le contexte sécurisé et l’expérience réellement offerte. Sans page d’installation qualifiée, le CTA honnête reste « Ouvrir l’application ».

Rôle du manifeste

Le manifeste décrit notamment nom, icônes, URL de démarrage, portée et mode d’affichage. Le scope borne les navigations considérées comme faisant partie de l’application. Une URL hors portée revient au comportement ordinaire du navigateur et ne doit pas être présentée comme écran interne.

Les icônes doivent exister dans les dimensions annoncées et rester lisibles. Un manifeste peut être valide sans que tous les navigateurs proposent la même installation ; l’interface explique donc la plateforme au lieu de prétendre détecter universellement l’état d’installation.

Expliquer l’installation selon le navigateur

Sur ordinateur, l’action peut apparaître dans la barre d’adresse, dans un menu ou ne pas être proposée. Sur mobile, certains navigateurs parlent d’installation, d’autres d’ajout à l’écran d’accueil. Une aide fiable nomme le système et le navigateur réellement vérifiés, décrit le chemin en quelques étapes et indique comment retirer l’application sans effacer par surprise les données que le produit conserve ailleurs.

Le site ne déduit pas l’installation d’une largeur d’écran ni d’un user-agent. Il propose d’abord l’ouverture Web, puis une aide facultative. Si les conditions d’installabilité ne sont pas remplies, le bouton disparaît au profit d’une phrase honnête ; aucune redirection vers un Store inexistant n’est utilisée comme repli.

Service worker et hors ligne

Le service worker intercepte certaines requêtes et peut utiliser Cache Storage. Il ne rend pas automatiquement toutes les données accessibles hors ligne. Le développeur choisit les ressources précachées, les réponses mises à jour et les écrans de repli. Les comptes, paiements et réponses personnalisées ne vont pas dans un cache partagé.

Une stratégie utile précache le shell et quelques ressources essentielles, met à jour les données publiques selon leur fraîcheur et affiche clairement ce qui n’est pas disponible. Le cache porte un numéro de version et une politique de nettoyage bornée.

Stratégies de cache

Les actifs adressés par hash peuvent être servis longtemps comme immuables. Le HTML éditorial utilise une revalidation ou un TTL raisonnable. Un manifeste courant a une durée courte. Les données vivantes conservent une politique métier : un prix, un horaire ou une disponibilité périmés ne deviennent pas vrais parce qu’ils sont dans un cache.

ETag et If-None-Match évitent de retélécharger un contenu inchangé. Une mise à jour atomique évite de mélanger un shell ancien et un manifeste nouveau. Le rollback réactive un ensemble cohérent.

RessourceStratégie possibleRisque à contrôler
Asset hashéCache long immutableRéférence mise à jour au build
HTML éditorialTTL + revalidationCorrection visible à temps
Manifeste courantTTL courtActivation atomique
Donnée publique datéeTTL métier + provenancePérimètre et expiration
Session ou compteno-store ou cache privéAucune fuite inter-utilisateur

Mises à jour et migration

Une nouvelle version de service worker s’installe avant activation. Forcer immédiatement le contrôle peut interrompre un parcours ; attendre indéfiniment laisse une version vulnérable. La stratégie dépend du risque et informe l’utilisateur lorsque le changement est important.

Les migrations de stockage sont versionnées et testées avec des données fictives. Le nettoyage retire les anciennes caches selon quota sans supprimer des données utilisateur hors contrat.

Tester sans surpromettre

Le test vérifie première visite, rechargement, navigation hors ligne, mise à jour, retour en ligne et quota. Il couvre au moins les navigateurs réellement annoncés. Une réponse 200 du service worker ne prouve pas que le contenu nécessaire est en cache.

Le bouton d’installation n’apparaît que si le parcours est qualifié. Si le navigateur ne propose pas l’événement attendu, la page fournit des instructions adaptées ou conserve seulement l’ouverture Web.

Accessibilité et installation

La proposition d’installation ne surgit pas avant que le lecteur comprenne le service. Elle peut être ignorée et reste accessible au clavier. Les instructions ne reposent pas uniquement sur l’icône d’un navigateur susceptible de changer.

L’écran hors ligne annonce l’état et les actions disponibles. Il ne ressemble pas à une erreur vide et ne prétend pas synchroniser ce qui reste local.

Checklist PWA

Avant d’afficher un CTA d’installation, contrôlez le parcours réel.

  • Manifeste relié, valide et servi avec un type adapté.
  • start_url et scope correspondent aux routes publiques.
  • Icônes réelles disponibles.
  • Service worker enregistré sur la portée attendue.
  • Shell hors ligne et erreurs compréhensibles.
  • Caches versionnés, bornés et nettoyés.
  • Aucune session ou donnée privée dans un cache partagé.
  • Mise à jour et rollback testés.
  • Instructions par plateforme réellement supportée.
  • Aucun Store annoncé sans publication.

Sources

Éditeur : DOHM — Digital Operations Hub & Modules · informations revues le . Signaler une correction.