Temps de lecture estimé : 3 min · Publié le 1 octobre 2026
Définir un périmètre utile
Classez les tâches : lire une information stable, préparer un brouillon, consulter une disponibilité ou payer. Les deux dernières dépendent de données et confirmations que l’on ne peut pas supposer actuelles sans réseau. Prévoyez une explication utile lorsque l’action reste indisponible.
Un site simple peut rester utile avec des pages légères et des liens fiables sans ajouter une application hors ligne. Évaluez d’abord les interruptions réellement rencontrées et les contenus indispensables. Un mécanisme supplémentaire doit avoir un responsable et des tests, pas seulement un nom technique.
Décrire les états sans ambiguïté
Séparez brouillon local, attente d’envoi, réception serveur et traitement terminé. Écrivez le message affiché dans chaque état et le moyen de reprendre. Une icône de réseau ou un bouton désactivé ne suffit pas à expliquer ce qui est arrivé à la demande.
La documentation MDN décrit les service workers et les mécanismes d’opération hors ligne ou en arrière-plan. Leur disponibilité et leur cycle de vie doivent être évalués sur les navigateurs du projet. Un navigateur peut interrompre certains travaux ; le parcours doit rester compréhensible sans dépendre d’une exécution permanente.
Tester une interruption au moment défavorable
Sur un environnement d’essai, coupez le réseau avant l’envoi, pendant le transfert et après la réception serveur. Rétablissez-le puis relancez la page. Contrôlez ce qui est conservé, perdu, répété ou présenté comme terminé. Le cas difficile est souvent l’incertitude sur une demande déjà reçue.
Rejouez avec une nouvelle session et un autre appareil si le service promet une continuité entre appareils. Faites tester les messages par une personne qui ne connaît pas l’architecture. Elle doit comprendre si une action reste à faire et comment éviter une deuxième commande.
Vérifier fraîcheur et confidentialité
Pour une donnée conservée, indiquez la date et l’usage possible. Une ancienne disponibilité peut aider à se repérer sans autoriser une réservation. Définissez quelles données restent sur l’appareil après déconnexion et qui examine les risques liés à un appareil partagé.
Après une nouvelle version, vérifiez le remplacement des ressources et la compatibilité des données locales. Gardez une manière de récupérer un brouillon autorisé ou de rétablir un fonctionnement simple. Le livrable doit inclure les états, tests d’interruption, règles de conservation et limites du mode dégradé.
Documentation primaire : MDN — Offline and background operation.