Comment fonctionne le mode offline dans les applications mobiles

1) Qu'est-ce qu'un mode hors ligne et pourquoi il est nécessaire

Le mode Offline est la capacité de l'application à fonctionner sans réseau (ou avec Internet instable), puis à se synchroniser lorsque la communication apparaît. Il :

réduit les pannes et augmente la rétention ;
accélère le premier écran (les données sont déjà locales) ;
permet d'effectuer des actions critiques (brouillons, affichage du contenu, partie des opérations) « dans le champ ».

2) Couches d'architecture hors ligne (dans n'importe quelle pile)

1. Stockage de données local

Mobile native : SQLite/Room (Android), Core Data/SQLite (iOS), Realm, Key-Value (SharedPreferences/UserDefaults).

Web/PWA : IndexedDB (en haut - Dexie/LocalForage), Cache Storage pour statique.

2. Cache statique (App Shell)

Icônes, polices, CSS/JS, modèles d'écran de base.

3. File d'attente d'opérations

Les requêtes d'écriture (créer/modifier/supprimer) sont mises en file d'attente et envoyées au serveur lorsque le réseau apparaît.

4. Couche de synchronisation

Politiques de merge, versions, déduplication, retraits, bakoff.

5. Signaux d'état du réseau

NetInfo/Reachability/API de navigateur pour basculer UI entre online/offline/limbo.

3) À quoi il ressemble sur iOS/Android

Cache et OBD : la structure de données met en miroir les réponses API de base (normalisez les entités).

Brouillons hors ligne : les formulaires et les actions sont écrits dans une base de données locale avec les drapeaux 'pending/sent/failed'.

Synchronisation : la tâche d'arrière-plan lit périodiquement l'outbox et envoie les lots (batch), marquant le statut.

Sécurité : secrets/jetons - dans Keychain (iOS )/Android Keystore. Les données PII/paiements sont cryptées (par exemple, AES-256 GCM) avec une clé du conteneur sécurisé.

Limites du système d'exploitation : les tâches d'arrière-plan dépendent des modes d'économie d'énergie ; prévoir l'avance des demandes et la reprise après le meurtre du procès.

4) Comment cela fonctionne dans PWA (Web)

Service Worker (SW) - proxy entre le réseau et l'application :

Precache (App Shell) : l'interface est disponible instantanément.
Runtime cache : données/médias sur les stratégies ci-dessous.
Sync de fond/Sync périodique (si disponible) : envoyer une file d'attente, mettre à jour le cache sans la participation de l'utilisateur.
IndexedDB pour les données et Cache Storage pour la statique.
Restrictions : quotas de stockage, contrôle rigoureux des tâches d'arrière-plan (en particulier iOS Safari).

5) Stratégies de mise en cache (quoi et quand appliquer)

Cache First - pour les statiques immuables (icônes, polices, versions JS).

Stale-While-Revalidate (SWR) - pour les listes/répertoires : instantanément à partir du cache, l'arrière-plan pour tirer les données fraîches.

Network First - pour les données personnelles lorsque le réseau existe ; backup - du cache hors ligne.

Cache Only/Network Only sont des cas privés rares (diagnostics, ressources privées).

Combiner : statique - CF/SWR ; Dynamique - SWR/NF ; les enregistrements sont à travers la file d'attente.

6) File de changement et idempotence

Modèle Outbox : chaque action (POST/PUT/PATCH/DELETE) est sérialisée dans l'enregistrement de la file d'attente avec l'ID temporel, le corps, la version et la date limite.

Envoyer des paquets (batch) avec un backoff exponentiel en cas d'erreurs réseau/serveur.

Clés idempotentes dans les titres/endpoints - la réimpression ne créera pas de prises.

Opérations OBD : l'écriture en file d'attente et la mise à jour de l'état local doivent être atomiques.

7) Résolution des conflits (server vs client)

Approches :

Last Write Wins (LWW) est simple, mais risque de perte de modifications.
Versioning/ETag - Le serveur rejette les versions obsolètes → le client fait merge/reconfiguration.
Transformations opérationnelles/CRDT - pour l'édition conjointe d'entités complexes.
Règles par champ - les champs « vérité » sur le serveur, ceux du client (par exemple, étiquettes/drapeaux locaux).

UX:

Affichez le badge « non synchronisé », le bouton « mettre à jour » et le diff en cas de conflit (pour sélectionner la version).

8) Travailler avec les médias et les ressources lourdes

Déduplication et hachage (content-addressable) : Ne chargez pas la même chose.

Playholders/vignettes hors ligne, version complète - après le réseau.

File d'attente de téléchargement avec pause en cas de mauvais réseau/batterie.

Politique TTL pour le cache des médias - ne pas économiser des gigaoctets.

9) Modèles UX pour que hors ligne soit « humain »

RÈGLE SUPÉRIEURE : ne jamais montrer le « vide ». App Shell + skeleton + dernière version validée du contenu.

Statuts clairs : Online/Offline/Synchronisation .../Action requise.

Undo/Retry : annuler la dernière action hors ligne ; Répétition automatique et manuelle.

Brouillons locaux : listes visibles en attente d'envoi.

Erreurs silencieuses : ne vous inquiétez pas agressivement - assez d'indicateurs discrets + journal.

10) Sécurité et vie privée hors ligne

Chiffrer les données sensibles « sur disque » ; les clés sont dans Keystore/Keychain.

Minimiser la collecte/stockage de PII hors ligne ; définissez la rétention et le nettoyage automatique.

Ne jamais mettre en cache les secrets/PAN/CVV complets ; les jetons des fournisseurs de paiement ne sont conformes qu'aux règles PCI.

Protégez SW/Client contre XSS (CSP, SRI), sinon l'attaquant sera en mesure de voler les données hors ligne la prochaine fois en ligne.

11) Limites des plates-formes

iOS : limites strictes des tâches d'arrière-plan dans le navigateur ; Web Push/periodic sync - avec des nuances ; Keychain est fiable pour les secrets.

Android : plus flexible que les services d'arrière-plan (WorkManager), mais les optimisations OEM peuvent « tuer » des tâches - définir comme « importantes ».

PWA : quotas IndexedDB/Cache Storage, nettoyage sans avertissement en cas de manque d'espace.

12) Test hors ligne

Profils réseau (Airplane, 2G/3G, packet loss, RTT élevé).

Kill/restore le processus pendant le bleu.

Tests Chaos : la moitié des butchs tombent 429/503/timeout.

Conflits : modifications parallèles à partir de deux appareils.

Quotas de stockage : remplir le disque, vérifier le comportement du cache.

13) Métriques et observabilité

Time To First Offline View (TTFOV) : vitesse d'apparition d'App Shell.

Hors ligne coverage : proportion d'écrans/opérations disponibles sans réseau.

Santé Outbox : longueur de la file d'attente, temps moyen au bleu, proportion d'erreurs.

Taux de conflit et proportion de merges manuels.

Quota/utilisation du stockage, fréquence de nettoyage du système d'exploitation.

Impact utilisateur : sessions lancées sans réseau → conversion après sink.

14) Plan de mise en œuvre rapide (90 jours)

1. Identifiez le scoop offline : quels écrans sont lus à partir du cache, quelles opérations peuvent être reportées.

2. Sélectionner la base de données et le schéma : tables normalisées, index, versions.

3. Activer App Shell : PWA SW/cache statique/icônes/polices.

4. Assembler Outbox : file d'attente, idempotence, bakoff, batchi.

5. Stratégies de cache : SWR pour les listes, Network First pour les données personnelles.

6. États UX + Journal bleu, retry/undo.

7. Sécurité : cryptage sur disque, CSP/SRI, minimisation des PII.

8. Tests de mauvais réseau, tests de chaos et métriques.

15) Erreurs fréquentes et comment les éviter

« Hors ligne » uniquement pour la statique. → Besoin de brouillons et d'outbox, sinon la valeur est faible.

Il n'y a pas d'idempotence, → les opérations de rétractation. Entrez les clés idempotent.

Conflits cachés. → L'utilisateur perd les modifications. Montrez le diff/solveur.

Sans TTL et nettoyage du cache. → L'application gonfle, le système d'exploitation nettoie de force.

Sink bloque l'IU. → La synchronisation est toujours dans le fond, l'IU est responsive.

Gardez les secrets ouverts. → Utilisez Keychain/Keystore et le cryptage.

16) FAQ

Peut-on faire un « plein » hors ligne pour tout ?

Souvent pas : les paiements, la vérification des licences et les données en direct nécessitent un réseau. Faire un hybride : lecture à partir du cache + enregistrements différés.

Quoi de plus rapide : SWR ou Network First ?

SWR donne une réponse instantanée du cache et une mise à jour silencieuse - le meilleur UX pour les listes. Network First est nécessaire là où la fraîcheur est importante (profil, équilibre).

Comment stocker les grands médias ?

Créez des vignettes et des TTL de courte durée, les originaux sont sur demande, avec un nettoyage LRU.

Dois-je tout chiffrer ?

Crypter les PII/secrets et les enregistrements sensibles. Le reste est sur la politique de risque et les quotas.

Offline va-t-il aggraver le SEO/PWA ?

Non, avec le SW et le SSR corrects, l'inverse améliorera la vitesse et les visites répétées.

Le mode hors ligne n'est pas une tique, mais une architecture système : une base de données locale + cache statique + une file d'attente de changement + un sink fiable et un état UX réfléchi. Ajoutez la sécurité (cryptage, Keychain/Keystore), l'idempotence et les métriques, testez un mauvais réseau - et votre application restera utile même sans Internet, et si elle apparaît, le serveur rattrapera sans heurts sans perdre les données et la confiance de l'utilisateur.