Offline-First dans le développement mobile — qu’est-ce que c’est, principes et stratégie de travail
Offline-First est une stratégie de développement d’applications mobiles et web où l’application accède d’abord au stockage local des données, puis se synchronise avec le serveur en arrière-plan. L’utilisateur voit l’interface instantanément, même sans connexion Internet, et les données sont automatiquement synchronisées lors de l’apparition de la connexion. Selon Google Developers, 2025, l’approche Offline-First augmente l’engagement des utilisateurs de 20 à 40 % grâce à un fonctionnement stable dans des conditions de réseau instable.
Points clés
- Offline-First — une stratégie où les données locales ont la priorité sur les requêtes réseau.
- Stockage local — le cache sur l’appareil (Room, SQLite, DataStore) fournit un accès instantané aux données.
- Synchronisation en arrière-plan — les modifications sont envoyées au serveur lors du rétablissement de la connexion réseau.
- Gestion des conflits — approches Last-Write-Wins ou CRDT pour concilier les données locales et celles du serveur.
- Service Worker — un composant clé d’Offline-First dans les applications web et les Progressive Web Apps.
Qu’est-ce qu’Offline-First ?
Offline-First est une approche architecturale de développement d’applications où le stockage et le traitement locaux des données sont primaires, et les requêtes réseau sont secondaires. Contrairement à l’approche traditionnelle Online-Only où l’application envoie une requête au serveur et attend une réponse, une application Offline-First lit d’abord les données du cache ou de la base de données locale, les affiche instantanément à l’utilisateur, et seulement ensuite se synchronise avec le serveur en arrière-plan. Cela change complètement l’expérience utilisateur : les écrans se chargent en millisecondes, quelle que soit la vitesse d’Internet.
Le concept Offline-First gagne en popularité avec la croissance du trafic mobile et la propagation des applications dans les régions à Internet instable. Selon Google I/O 2025, plus de 60 % des utilisateurs d’applications mobiles rencontrent des problèmes de connexion réseau au moins une fois par jour. Offline-First résout ce problème en rendant l’application entièrement fonctionnelle sans accès à Internet. L’utilisateur peut créer, modifier et supprimer des données — toutes les modifications sont enregistrées localement et synchronisées lors du rétablissement de la connexion.
Offline-First doit être distingué du simple mise en cache. Avec la mise en cache, les données sont d’abord chargées depuis le serveur puis enregistrées localement comme copie. Avec Offline-First, le stockage local est la source de vérité. L’utilisateur interagit avec les données locales, et le serveur est un réplica. Si le réseau est indisponible, l’application continue de fonctionner pleinement. Si le réseau est disponible, les modifications sont synchronisées en arrière-plan. Cette approche nécessite une architecture plus complexe mais offre une expérience utilisateur qualitativement différente.
Offline-First vs Online-Only vs Offline-Only
Il existe trois approches pour travailler avec les données dans les applications. Online-Only — l’application ne fonctionne pas sans Internet, toutes les données sont stockées sur le serveur. Offline-Only — l’application fonctionne entièrement localement, sans synchronisation avec le serveur. Offline-First — un hybride : les données locales comme source de vérité, le serveur comme réplica pour la sauvegarde et le partage. Chaque approche a son domaine d’application : Online-Only convient aux opérations bancaires, Offline-Only aux calculatrices, Offline-First aux réseaux sociaux, notes, tâches et messageries.
Principes de la stratégie Offline-First
L’architecture Offline-First repose sur quatre principes clés. Source de vérité locale — toutes les données sont d’abord enregistrées dans la base de données locale, et seulement ensuite envoyées au serveur. L’utilisateur voit toujours des données à jour depuis le stockage local, garantissant une réponse instantanée de l’interface. L’application n’attend jamais la réponse du serveur pour afficher les données — c’est une différence fondamentale avec les clients REST traditionnels avec indicateurs de chargement.
Synchronisation en arrière-plan — après avoir enregistré les données localement, l’application met en file d’attente une tâche de synchronisation. Si le réseau est disponible, les modifications sont envoyées immédiatement au serveur. Si le réseau est indisponible, la tâche est conservée dans une file d’attente et exécutée lors du rétablissement de la connexion. Android WorkManager et iOS BGProcessingTask sont des outils standards pour implémenter ce principe. Résolution des conflits — des conflits peuvent survenir lors de la synchronisation si les mêmes données ont été modifiées sur différents appareils. Les stratégies de résolution incluent Last-Write-Wins, le contrôle de concurrence multi-version ou CRDT.
Interface adaptative — l’application doit informer l’utilisateur de l’état de synchronisation mais ne doit pas bloquer le travail en mode hors ligne. Une icône d’état de connexion, un indicateur de modifications non synchronisées et des notifications de synchronisation terminée sont des éléments UX obligatoires pour les applications Offline-First. Service Worker dans les applications web et Network Manager dans les applications mobiles surveillent l’état du réseau et gèrent l’envoi des données.
Cache-First vs API-First vs Offline-First
Cache-First — l’application vérifie d’abord le cache, mais s’il n’y a pas de données, elle envoie une requête au serveur. C’est une version simplifiée d’Offline-First sans file de synchronisation ni résolution de conflits. API-First — l’application demande toujours les données au serveur, le cache n’est utilisé qu’en secours en l’absence de réseau. Offline-First est l’approche la plus complexe mais aussi la plus fiable, offrant une fonctionnalité complète sans réseau et une cohérence des données pendant la synchronisation.
Outils pour implémenter Offline-First
Les plateformes modernes offrent un ensemble d’outils pour construire des applications Offline-First. Sur Android, l’outil principal de stockage local est Room — une bibliothèque au-dessus de SQLite qui fournit une API type-safe pour travailler avec la base de données. Room permet de stocker des objets complexes, de définir des relations entre les tables et d’exécuter des requêtes réactives via Flow et LiveData. WorkManager avec des contraintes NetworkType.CONNECTED est utilisé pour la synchronisation.
Sur iOS, Core Data ou SwiftData (un nouveau framework d’Apple) sont utilisés pour le stockage local. Pour la synchronisation — CloudKit ou une implémentation personnalisée via URLSession avec des tâches en arrière-plan. Firebase offre une solution Offline-First prête à l’emploi pour les deux plateformes : Firebase Realtime Database et Firestore enregistrent automatiquement les données localement et les synchronisent lors de l’apparition d’une connexion. Le développeur n’a pas besoin d’écrire de code de synchronisation et de résolution de conflits — Firebase le fait par défaut avec une politique Last-Write-Wins.
Pour les applications web, l’outil clé est Service Worker, qui intercepte les requêtes HTTP et peut renvoyer des réponses depuis le cache (Cache API). Workbox de Google simplifie l’implémentation de Service Worker avec des stratégies de mise en cache prêtes : Cache First, Network First, Stale-While-Revalidate. IndexedDB est utilisé pour stocker des données structurées dans le navigateur. Les bibliothèques comme RxDB et PouchDB fournissent une base de données Offline-First complète avec réplication sur le serveur via CouchDB.
| Plateforme | Stockage local | Synchronisation |
|---|---|---|
| Android | Room, SQLite, DataStore | WorkManager + SyncAdapter |
| iOS | Core Data, SwiftData, SQLite | CloudKit, URLSession Background |
| Web (PWA) | IndexedDB, Cache API, localStorage | Service Worker + Background Sync API |
| Multiplateforme | Firestore, Realm, Couchbase Lite | Firebase Sync, CouchDB Replication |
Choix des outils selon le projet
Pour les applications simples avec une synchronisation peu fréquente, Room + WorkManager convient. Pour les systèmes complexes avec de nombreux utilisateurs et des exigences élevées de cohérence — Firestore avec son support Offline-First intégré. Pour les applications web hybrides — IndexedDB + Workbox. Le choix des outils dépend de la complexité des données, des exigences de cohérence, du volume de synchronisation et de l’équipe de développement.
Synchronisation des données et gestion des conflits
La synchronisation est la partie la plus complexe de l’architecture Offline-First. Lorsqu’un utilisateur modifie des données en mode hors ligne et qu’un autre appareil apporte des modifications aux mêmes données en ligne, un conflit surgit lors du rétablissement de la connexion. Last-Write-Wins (LWW) est la stratégie la plus simple : la dernière écriture gagne. Elle est utilisée par défaut dans Firebase et convient à la plupart des applications où la perte d’une version de données n’est pas critique. Cependant, LWW peut entraîner une perte de données si l’utilisateur a été hors ligne pendant longtemps.
Contrôle de concurrence multi-version (MVCC) est une approche plus complexe où les deux versions des données sont stockées et l’utilisateur est invité à choisir la bonne. Cette approche est utilisée dans les systèmes d’édition collaborative (Google Docs, Notion). Pour implémenter MVCC, il faut synchroniser les horloges des appareils (NTP) ou utiliser des horloges vectorielles pour déterminer les relations de cause à effet. CRDT (Types de Données Répliquées sans Conflit) est une approche mathématique qui garantit l’absence de conflits grâce à des structures de données spéciales qui peuvent être fusionnées sans perte d’information. CRDT est utilisé dans Figma et SoundCloud.
Pour les applications mobiles, il est recommandé de commencer par LWW et d’ajouter des stratégies plus complexes selon les besoins. L’algorithme de synchronisation fonctionne généralement comme suit : l’application stocke l’horodatage de la dernière synchronisation pour chaque enregistrement. Lors du rétablissement de la connexion, un tableau de modifications avec horodatages est envoyé. Le serveur renvoie un tableau des modifications survenues sur le serveur après l’horodatage spécifié. Pour chaque champ conflictuel, la stratégie choisie est appliquée. Après la fin de la synchronisation, l’horodatage est mis à jour.
File d’attente des opérations
Dans l’architecture Offline-First, toutes les opérations d’écriture (CREATE, UPDATE, DELETE) entrent d’abord dans une file d’attente des opérations. Une opération contient le type, l’identifiant de l’enregistrement, les données et l’horodatage. Si le réseau est disponible, l’opération est exécutée immédiatement. Si indisponible — elle est conservée dans la file locale. Lorsque le réseau est rétabli, WorkManager ou BackgroundTask traite la file dans l’ordre FIFO. Les opérations réussies sont supprimées de la file, les échouées sont réessayées avec un backoff exponentiel. Cela garantit qu’aucune modification de l’utilisateur n’est perdue.
Offline-First dans les applications Android
Sur la plateforme Android, l’implémentation Offline-First est construite autour de trois composants clés : Room pour le stockage local, WorkManager pour la synchronisation en arrière-plan et ConnectivityManager pour la surveillance de l’état du réseau. Room fournit un accès réactif aux données via Flow : l’interface utilisateur s’abonne aux modifications dans la base de données et se met à jour automatiquement à tout changement. WorkManager planifie une tâche de synchronisation avec la contrainte NetworkType.CONNECTED pour que la tâche ne s’exécute qu’en présence d’Internet.
Un scénario typique d’Offline-First sur Android : un utilisateur crée un enregistrement dans l’application. Les données sont enregistrées dans Room via un référentiel. Le référentiel renvoie un Flow avec des données mises à jour et l’interface utilisateur affiche instantanément le nouvel enregistrement. En parallèle, le référentiel met en file d’attente une tâche de synchronisation dans WorkManager. Si le réseau est disponible, WorkManager envoie une requête POST au serveur. Si le serveur renvoie une erreur ou si le réseau est indisponible, la tâche est réessayée plus tard. L’utilisateur voit un indicateur de synchronisation (icône de nuage avec flèche) à côté des nouveaux enregistrements.
Pour la réactivité, le modèle Référentiel + Flow est utilisé. Le référentiel cache les détails de synchronisation au ViewModel : le ViewModel s’abonne à un Flow depuis Room et met à jour l’interface utilisateur. Le Référentiel appelle l’API et enregistre le résultat dans Room. L’interface utilisateur ne sait pas si les données ont été obtenues de la base de données locale ou du serveur — elle réagit simplement aux changements dans le Flow. Cela permet de changer la stratégie de synchronisation sans modifier le code de l’interface utilisateur. Room notifie automatiquement le Flow des changements grâce aux annotations LiveData/Flow.
kotlin
class NotesRepository(
private val localDb: NoteDao,
private val api: NotesApi,
private val syncManager: SyncManager
) {
val notes: Flow<List<Note>> = localDb.getAllNotes()
suspend fun createNote(text: String) {
val note = Note(text = text, synced = false)
localDb.insert(note)
syncManager.enqueueSync()
}
}Offline-First avec Jetpack Compose
Dans Jetpack Compose, Offline-First est implémenté via StateFlow du ViewModel vers les fonctions Composable. Le ViewModel reçoit un Flow du référentiel, le transforme en StateFlow via stateIn() et le transmet à Compose. Lorsque Room modifie les données, le Flow émet une nouvelle valeur, le StateFlow se met à jour et Compose ne réaffiche que les éléments modifiés. Cela fournit une interface utilisateur réactive avec un minimum d’effort et sans mise à jour manuelle des listes après la synchronisation.
Erreurs courantes avec Offline-First
L’erreur la plus courante est d’utiliser la mise en cache au lieu d’une architecture Offline-First complète. Les développeurs ajoutent Room ou Core Data mais continuent d’appeler d’abord l’API et d’enregistrer le résultat dans la base de données comme copie. En l’absence de réseau, l’application affiche un espace réservé ou un écran vide parce que les données n’ont jamais été chargées. La bonne approche est de toujours lire les données depuis la base de données locale et d’utiliser les réponses de l’API uniquement pour mettre à jour cette base de données. Si la base de données est vide au premier lancement, l’application doit charger les données depuis le serveur, les enregistrer localement, puis les afficher.
La deuxième erreur est d’ignorer les conflits de synchronisation. Les développeurs se fient souvent au Last-Write-Wins par défaut sans considérer les scénarios où l’utilisateur pourrait perdre des données importantes. Si l’application permet de modifier les mêmes enregistrements depuis plusieurs appareils, il est nécessaire d’implémenter au moins une résolution de base des conflits avec notification à l’utilisateur. Firebase Firestore résout ce problème automatiquement, mais une implémentation personnalisée nécessite une conception minutieuse.
Le troisième problème est de ne pas tenir compte de l’état du réseau. L’application doit gérer correctement les transitions d’online à offline et inversement. Si un utilisateur soumet un formulaire et que la connexion est perdue, les données doivent être conservées dans la file d’attente des opérations, et non perdues. ConnectivityManager sur Android et NWPathMonitor sur iOS permettent de surveiller les changements de réseau en temps réel. L’application doit afficher une interface claire : si les données ne sont pas synchronisées — une icône « en attente de synchronisation », s’il n’y a pas de réseau — une icône « hors ligne ». Cela gère les attentes de l’utilisateur et réduit le nombre de fausses demandes d’assistance.
Problèmes de mémoire et de performance
L’architecture Offline-First peut entraîner des problèmes de mémoire si la base de données locale croît sans contrôle. Toutes les données chargées depuis le serveur sont enregistrées localement, et si une politique de nettoyage n’est pas configurée, la taille de la base de données peut atteindre des centaines de mégaoctets. Il est recommandé de définir un TTL (durée de vie) pour les données en cache, de supprimer les anciens enregistrements lors de la synchronisation et d’utiliser la pagination pour charger de grandes listes. Room fournit les fonctions d’agrégation COUNT et DELETE pour gérer la taille de la base de données.
Foire aux questions
Quelle est la différence entre Offline-First et Cache-First ?
Offline-First — les données locales sont la source de vérité, l’application fonctionne entièrement sans réseau. Cache-First — le cache est utilisé pour la vitesse, mais la source de vérité est le serveur. Dans Offline-First, l’utilisateur peut créer et modifier des données sans réseau ; dans Cache-First, il ne peut que visualiser les données précédemment chargées. Offline-First nécessite une synchronisation complexe, Cache-First non.
Comment gérer les conflits de synchronisation dans Offline-First ?
La stratégie de base est Last-Write-Wins (la dernière écriture gagne). Pour des scénarios plus complexes — MVCC avec une interface de sélection de version pour l’utilisateur ou CRDT (Types de Données Répliquées sans Conflit), qui garantissent mathématiquement l’absence de conflits. Le choix de la stratégie dépend de la criticité des données et de la complexité de l’implémentation.
Quelles données ne doivent pas être stockées uniquement localement ?
Les données critiques qui ne doivent pas être perdues lors de la suppression de l’application ou d’une panne de l’appareil nécessitent un stockage sur serveur. Les jetons d’autorisation, les données de paiement, l’historique des commandes doivent être dupliqués sur le serveur. Offline-First ne signifie pas « local uniquement » — il signifie « local comme stockage principal avec réplica serveur ».
Comment tester une application Offline-First ?
Utilisez un Network Call Manager pour simuler la perte de réseau, la limitation de bande passante et le mode avion dans l’émulateur. Testez les scénarios : création de données sans réseau, synchronisation lors du rétablissement, conflits lors de l’édition parallèle. Android fournit NetworkBehavior dans Robolectric, iOS dispose d’OHHTTPStubs pour simuler les erreurs réseau. Les tests d’intégration doivent vérifier la file d’attente des opérations et la résolution des conflits.
Quand ne pas utiliser Offline-First ?
Offline-First est excessif pour les applications où les données doivent toujours être à jour — par exemple, les cotations boursières, les cartes en ligne ou les systèmes de surveillance. Si l’utilisateur n’utilise jamais l’application sans Internet et que la cohérence des données est critique, il est plus simple et plus fiable d’utiliser une architecture Online-Only avec des indicateurs de chargement.
Résumé
- Offline-First — une stratégie de développement où le stockage local est la source de vérité et le serveur est un réplica pour la synchronisation.
- Source de vérité locale — les données sont d’abord enregistrées sur l’appareil (Room, Core Data, IndexedDB), puis synchronisées avec le serveur.
- Synchronisation en arrière-plan — WorkManager (Android), BackgroundTask (iOS), Service Worker (Web) envoient les modifications lorsque le réseau est disponible.
- Résolution des conflits — Last-Write-Wins, MVCC ou CRDT pour concilier les modifications effectuées sur différents appareils en mode hors ligne.
- File d’attente des opérations — garantit qu’aucune modification de l’utilisateur n’est perdue : les opérations sont enregistrées localement et exécutées lors du rétablissement de la connexion.
- Interface utilisateur réactive — via Flow (Android) ou Combine (iOS), l’interface s’abonne à la base de données locale et se met à jour automatiquement à tout changement.
- Erreurs courantes — confusion avec le cache, ignorance des conflits, non-prise en compte de l’état du réseau et croissance incontrôlée de la base de données locale.
Nous développerons une application mobile clé en main
IT Sectr crée des applications iOS et Android pour les startups et les entreprises depuis 2017. Nous vous conseillerons et vous proposerons la meilleure solution.
Lisez aussi