💾 2.4 Persistance et scénarios offline

Module 335 – Réaliser une application pour mobile

🎯 Objectif d'apprentissage

À la fin de ce chapitre, vous serez capables de :

• Comprendre les différentes formes de persistance locale sur mobile
• Distinguer bases de données locales, stockage clé–valeur et stockage de fichiers
• Expliquer le fonctionnement des scénarios offline et du cache local
• Gérer les erreurs réseau, la synchronisation et la résilience d'une application

🤔 2.4.1 Introduction : pourquoi la persistance ?

Une application mobile n’est pas toujours connectée à Internet :

• tunnels
• bâtiments
• zones rurales
• métro
• mode avion

Pourtant, les utilisateurs s’attendent à ce qu’elle continue de fonctionner, même hors ligne.

2.4.1 Persistance : définition

La persistance = capacité d’une application à stocker des données localement sur l’appareil, afin qu’elles restent disponibles :

• même sans réseau
• même après fermeture de l’app

Exemples de données persistées :

• Préférences utilisateur (langue, thème sombre)
• Session de connexion
• Notes, listes, messages, documents
• Cache de données venant d’une API (ex. dernier rapport météo)

2.4.1 Trois briques principales

La gestion du mode offline repose sur 3 briques :

1. Stockage léger (clé–valeur)
2. Base de données locale (SQLite, Realm, CoreData, etc.)
3. Synchronisation entre local et serveur quand la connexion revient

2.4.1 Exemple – Application de notes

Une application de notes doit permettre :

• d’ajouter / modifier / supprimer des notes même hors ligne
• puis de synchroniser ces notes avec le cloud
• dès que la connexion revient

🎯 Objectif du chapitre :
Comprendre les solutions de stockage et comment assurer le offline sans frustrer l’utilisateur.

🔐 2.4.2 Stockage clé–valeur – Principe

Le stockage clé–valeur = forme de persistance la plus simple.

On enregistre de petites infos sous forme :

clé → valeur

Comme un dictionnaire.

2.4.2 Stockage clé–valeur – À quoi ça sert ?

• Préférences utilisateur

  • thème sombre / clair
  • langue
  • notifications activées

• Petits états internes

  • dernière page visitée
  • tutoriel déjà vu

• Tokens d’authentification

  • JWT
  • OAuth

• Paramètres de configuration

⚠️ Pas adapté aux données volumineuses (listes, historiques, gros objets…).

2.4.2 Outils selon la plateforme

2.4.2 Exemple – Capacitor Preferences

import { Preferences } from '@capacitor/preferences';

await Preferences.set({
  key: 'theme',   
  value: 'dark', 
});

Ici, on mémorise le thème choisi par l’utilisateur.

2.4.2 Bonnes pratiques – Clé–valeur

• Ne jamais stocker d’infos sensibles en clair (mots de passe, données perso détaillées…)
• Limiter à quelques kilo-octets
• Réserver ce stockage à des paramètres ou états simples

📂 2.4.3 Bases de données locales – Principe

Pour des données plus volumineuses ou structurées, on utilise une base de données locale.

Elle permet :

• recherches (requêtes)
• tris
• relations entre données
• mises à jour complexes

2.4.3 Pourquoi une base locale ?

Utile pour :

• conserver une liste de données :
  • notes, produits, messages, utilisateurs, etc.
• permettre à l’app de fonctionner 100 % offline
• créer un cache local d’API :
  • charger les données une fois,
  • les relire même sans réseau

2.4.3 Solutions principales

2.4.3 Exemples d’usage – BDD locale

• App de recettes qui garde toutes les recettes consultées
• App de notes avec centaines d’entrées locales
• App de films qui garde les favoris hors ligne

2.4.3 Schéma logique – BDD locale

[ UI ] ⇄ [ ViewModel / Service ] ⇄ [ SQLite / CoreData ]

🎯 Idée : la vue ne parle jamais directement à la base.
Elle passe par une couche intermédiaire (service / ViewModel).

📇 2.4.4 Stockage de fichiers – Quand et pourquoi ?

Certaines apps doivent stocker des fichiers :

• photos
• PDF
• documents scannés
• enregistrements audio
• fichiers téléchargés

Ici, ce ne sont plus des “lignes de BDD”, mais des fichiers sur le stockage.

2.4.4 Types de fichiers courants

• Photos prises par l’utilisateur
• Documents scannés (factures, reçus)
• Fichiers PDF
• Notes vocales, enregistrements audio
• Fichiers téléchargés depuis Internet

2.4.4 APIs selon la plateforme

Exemple : une app de scan stocke les documents localement avant upload.

2.4.4 Points d’attention – Fichiers

• Gérer les permissions d’accès aux fichiers / médias
• Faire attention à la taille (photos HD = gros fichiers)
• Nettoyer régulièrement les fichiers inutilisés
  → éviter de saturer le stockage

🔌 2.4.5 Cache local et usage offline – Principe

Le cache local permet d’afficher du contenu même si :

• le réseau est lent, ou
• complètement indisponible

C’est essentiel pour :

• éviter les écrans vides
• donner une impression de rapidité

2.4.5 Pourquoi utiliser un cache ?

• Réduire les appels réseau
• Accélérer l’affichage (données déjà présentes)
• Permettre un usage offline partiel
• Améliorer la perception de performance

Exemple : Twitter, Instagram ou YouTube affichent le dernier contenu chargé hors ligne.

2.4.5 Types de cache

• Cache mémoire (RAM)

  • très rapide
  • disparaît quand l’app est fermée

• Cache disque

  • plus lent
  • persiste entre les sessions
  • idéal pour données d’API, images, listes

2.4.5 Stratégies de lecture des données

2.4.5 Bonnes pratiques – Cache

🧑‍💻 Conseil développeur :
Toujours enregistrer un timestamp avec les données du cache.

Comme en restauration :

• On étiquette chaque élément du “frigo” (cache)
• On sait quand il a été mis, et si c’est encore “frais”

🔄️ 2.4.6 Synchronisation online/offline – Principe

La synchronisation = garder la cohérence entre :

• les données locales
• les données serveur

… même si l’utilisateur travaille offline.

2.4.6 Synchronisation – Défis principaux

• Conflits entre données locales et distantes
• Envoi des actions accumulées hors ligne
• Fiabilité en cas :
  • de batterie vide
  • de crash
  • de fermeture brutale de l’app

2.4.6 Stratégie – File d’attente locale (queue)

Principe :

• Chaque action utilisateur est enregistrée dans une queue :

  • “Ajouter une note”
  • “Modifier le profil”
  • “Supprimer un élément”

• À la reconnexion :

  • on rejoue la queue dans l’ordre
  • vers le serveur

2.4.6 Stratégie – Marqueurs de version

Chaque enregistrement a un champ du type :

• updatedAt
• ou un numéro de version

En cas de conflit :

• la version la plus récente gagne
• ou selon une règle métier décidée

2.4.6 Stratégie – Résolution des conflits

Stratégies possibles :

• Last Writer Wins
  → la dernière modification l’emporte

• Serveur prioritaire
  → le serveur est l’autorité finale

• Local prioritaire (offline-first)
  → on fait confiance à ce que l’utilisateur a saisi

Exemple : app de notes → souvent la version locale la plus récente prime.

❌ 2.4.7 Gestion des erreurs réseau – Réalité du terrain

Le réseau mobile est :

• variable
• parfois lent
• parfois coupé

Une bonne app anticipe :

• les coupures
• les ralentissements
• les erreurs HTTP

2.4.7 Détection du statut réseau

Outils fréquents :

• Android : ConnectivityManager
• iOS : NWPathMonitor
• Ionic / Capacitor : plugin Network
• Flutter : package connectivity_plus

Permet d’afficher des messages :

• “Vous êtes hors ligne”
• “Connexion lente, veuillez patienter”
• “Connexion instable – affichage du cache”

2.4.7 Stratégies de résilience

• Retry exponentiel : 1s → 2s → 4s → 8s…
• Fallback local : cache, BDD locale
• Désactivation de certaines actions hors ligne
• Sauvegarde des actions dans une queue locale

Exemple :
Une app de livraison peut empêcher l’envoi d’une commande hors ligne,
mais continuer d’afficher les menus via le cache.

🧩 2.4.8 Activité pratique – Où stocker quoi ?

(clé–valeur / base de données / fichiers / pas de persistance)

🎓 Objectif

Comprendre où et comment stocker chaque type de donnée dans une app mobile.

2.4.8 🌇 Contexte – App CityQuest

Vous travaillez sur CityQuest, une app de chasse au trésor en ville.

Fonctionnalités :

• Quêtes géolocalisées (énigmes, points d’intérêt, QR codes à scanner)
• Chaque quête rapporte des points
• Une quête peut être validée avec une photo
• L’utilisateur peut voir :
  • ses quêtes en cours
  • ses quêtes terminées
• L’app doit fonctionner raisonnablement même avec un réseau faible (cache local)

2.4.8 Ce qu’on modélise / ne modélise pas

On se concentre sur les données stockées sur le téléphone :

• pas de schéma complet de BDD serveur
• pas de détails sur le profil utilisateur côté back

🎯 Objectif : apprendre à choisir le bon type de stockage local.

2.4.8 Consignes de l’exercice

Pour chaque donnée ci-dessous, indiquez dans quel type de stockage vous la placeriez :

• Clé–valeur
• Base de données locale
• Fichiers
• Pas besoin de persistance (si justifié)

✍️ Justifiez chaque choix en 1 phrase.

2.4.8 Données à analyser (1/2)

1. Token d’authentification (JWT, OAuth)
2. Paramètre du thème (sombre / clair)
3. Choix de l’utilisateur pour télécharger les images :
   • uniquement en Wi-Fi
   • ou Wi-Fi + 5G
4. Dernière position GPS connue (pour centrer la carte au prochain lancement)
5. Liste des quêtes disponibles dans la ville
   • titre, description, coordonnées GPS, difficulté, points

2.4.8 Données à analyser (2/2)

1. État d’une quête pour l’utilisateur
   (non commencée, en cours, terminée)

2. Historique des quêtes terminées
   (dizaines ou centaines d’entrées)

3. Cache des quêtes à proximité récupérées depuis l’API
   (afficher même si le réseau est lent)

4. Photo de validation d’une quête prise par l’utilisateur

5. Fichiers de logs d’erreur pour envoi ultérieur au support
   (stack traces, messages techniques)

2.4.8 Format de réponse suggéré

💬 L’objectif est moins d’avoir “la bonne réponse” que de savoir argumenter.

🔗 2.4.9 Références

• Android Room
  https://developer.android.com/training/data-storage/room

• iOS CoreData
  https://developer.apple.com/documentation/coredata

• Capacitor – Storage & SQLite
  https://capacitorjs.com/docs

• Flutter – sqflite
  https://pub.dev/packages/sqflite

• W3C – IndexedDB API
  https://developer.mozilla.org/docs/Web/API/IndexedDB_API