Qu'est-ce que la synchronisation des données offline-first ?

La synchronisation offline-first est une architecture où l’app lit et écrit d’abord en stockage local, puis se réconcilie avec le serveur une fois en ligne. Le réseau cesse d’être une dépendance pour devenir un processus d’arrière-plan : chaque écran s’affiche à partir de l’appareil, chaque tap s’enregistre sur l’appareil, et une couche de synchronisation solde les comptes avec le backend dès que la connectivité le permet. Le plus dur n’a jamais été de stocker des données en local ; c’est ce qui se passe quand deux copies de la vérité ne sont pas d’accord.

Points clés

Épingler, lire, mettre en file : la boucle hors ligne en code

La version SDK mobile du pattern — épinglez ce dont les écrans ont besoin, mettez en file d’attente ce que les utilisateurs modifient :

// JavaScript — Back4app JS SDK with the Local Datastore enabled
Parse.enableLocalDatastore();

// Read: serve the screen from the local store — instant, works offline
const query = new Parse.Query('Task');
query.fromLocalDatastore();
render(await query.find());

// Write: durable locally now, queued for the server automatically
const task = new Parse.Object('Task');
task.set('title', 'Inspect site 14');
task.set('done', false);
await task.pin();          // survives restarts, feeds local reads
task.saveEventually();     // replays when the network returns

// Flutter / Dart — Back4app Flutter SDK with local storage enabled
// Parse().initialize(..., coreStore: await CoreStoreSembastImp.getInstance())

// Read: serve the screen from pinned data — instant, works offline
final pinned = await ParseObject('Task').fromPin('openTasks');
render(pinned);

// Write: durable locally now, synced when the network allows
final task = ParseObject('Task')
  ..set('title', 'Inspect site 14')
  ..set('done', false);
await task.pin();                 // survives restarts, feeds local reads

final response = await task.save();
if (!response.success) retryLater(task);   // replay from the outbox

// iOS / Swift — Back4app iOS SDK with the Local Datastore enabled
// (in the app delegate) Parse.enableLocalDatastore()

// Read: serve the screen from the local store — instant, works offline
let query = PFQuery(className: "Task")
query.fromLocalDatastore()
query.findObjectsInBackground { tasks, _ in
  render(tasks)
}

// Write: durable locally now, queued for the server automatically
let task = PFObject(className: "Task")
task["title"] = "Inspect site 14"
task["done"] = false
task.pinInBackground()     // survives restarts, feeds local reads
task.saveEventually()      // replays when the network returns

// Android / Kotlin — Back4app Android SDK with the Local Datastore enabled
// (before Parse.initialize) Parse.enableLocalDatastore(context)

// Read: serve the screen from the local store — instant, works offline
val query = ParseQuery.getQuery<ParseObject>("Task")
query.fromLocalDatastore()
query.findInBackground { tasks, _ ->
    render(tasks)
}

// Write: durable locally now, queued for the server automatically
val task = ParseObject("Task")
task.put("title", "Inspect site 14")
task.put("done", false)
task.pinInBackground()     // survives restarts, feeds local reads
task.saveEventually()      // replays when the network returns

Deux appels portent toute l’architecture. Pin rend les objets durables et interrogeables sur l’appareil — la même interface de requête que le serveur, pointée vers le stockage local (Local Datastore dans les SDK ci-dessus). Save-eventually accepte l’écriture tout de suite et prend en charge sa livraison plus tard. Tout le reste de cet article décrit ce qui se passe entre ces deux appels.

Tampon ou source de vérité ? La décision sous la décision

Toute conception offline-first choisit discrètement l’une de deux postures pour le stockage local, et l’essentiel des difficultés de synchronisation vient de ce que ce choix n’a pas été fait délibérément.

Le stockage local comme tampon. Le serveur reste l’autorité ; l’appareil détient une copie de travail plus une outbox d’intentions. Les conflits se résolvent en faveur du serveur ou par une politique simple, et un appareil peut toujours être réparé en récupérant à nouveau les données. C’est le bon choix par défaut pour les apps métier — checklists de CRM, inspections sur le terrain, saisie de commandes — parce que le raisonnement reste simple : la vérité vit à un seul endroit, les appareils sont simplement en retard sur elle.

Le stockage local comme réplique. La vérité est négociée entre pairs et le serveur n’est qu’une réplique parmi d’autres — la posture des éditeurs collaboratifs et des apps de notes qui promettent de tout fusionner. Vous y gagnez en résilience et en confiance des utilisateurs, au prix d’une véritable mécanique de systèmes distribués : des version vectors pour détecter la concurrence, des fonctions de fusion par type de données, et la cohérence à terme comme garantie la plus forte que vous puissiez afficher honnêtement.

La posture se choisit par jeu de données, pas par app : une même app d’intervention terrain peut traiter les ordres de travail du technicien comme une réplique (ils doivent rester modifiables toute la journée en sous-sol) et le catalogue de pièces comme un tampon read-through.

La boucle de synchronisation, de bout en bout

La boucle a une moitié sortante et une moitié entrante, qui se rejoignent au niveau de la résolution de conflits.

Sortante : écritures en file d’attente et rejeu. Les écritures hors ligne sont validées en local et ajoutées à une outbox durable — l’interface reflète l’intention immédiatement, avec un libellé « en attente » honnête là où cela compte. À la reconnexion, la file est rejouée dans l’ordre. Toute l’ingénierie réside dans les modes de défaillance : les erreurs transitoires sont réessayées avec backoff ; les refus de permission et de validation doivent remonter jusqu’à l’utilisateur, pas être réessayés indéfiniment ; et les opérations doivent être idempotentes, car un accusé de réception perdu signifie que la même opération peut arriver deux fois. Rejouer deux fois « passer le statut à terminé » est inoffensif ; rejouer deux fois « incrémenter le stock de 3 » est un bug.

Entrante : récupération des deltas. Tout re-télécharger à la reconnexion gaspille bande passante et batterie ; une synchronisation de production récupère les changements depuis un point de reprise — un repère updated-at dans les conceptions simples, un numéro de séquence serveur ou un change feed dans les plus robustes. Les mêmes événements qui alimentent les live queries quand l’app est en ligne servent aussi de flux de deltas entrants, et c’est pourquoi la synchronisation hors ligne et la synchronisation en temps réel forment un continuum, pas deux features.

Last-write-wins vs. fusion vs. CRDT

Deux remarques honnêtes sur ce tableau. D’abord, les timestamps sont plus fragiles qu’ils n’en ont l’air — les horloges des appareils dérivent, si bien qu’un last-write-wins sérieux utilise l’heure de réception côté serveur ou des versions logiques (version vectors quand les modifications concurrentes doivent être détectées plutôt que devinées). Ensuite, le juste milieu pratique pour les apps mobiles, c’est le CRDT-lite : les bibliothèques CRDT complètes sont une lourde mécanique, mais emprunter l’idée par champ ne coûte presque rien — modélisez une quantité comme des opérations d’incrément plutôt qu’un total stocké, des tags comme des ensembles add/remove plutôt qu’un tableau, et ces champs cessent tout simplement d’entrer en conflit. La stratégie se choisit par champ ; les apps qui adoptent une politique globale unique se sont presque toujours trompées pour l’un de leurs champs.

Cas d’usage courants

• Opérations terrain — inspections, livraisons, interventions sur les réseaux : le chantier est précisément l’endroit où la couverture disparaît, donc la saisie doit être locale et la synchronisation opportuniste.
• Prise de notes et productivité personnelle — un seul utilisateur, plusieurs appareils : les conflits sont rares et le plus souvent auto-infligés, ce qui rend les politiques de fusion maîtrisables.
• Apps de point de vente et de borne — la file de clients doit continuer d’avancer pendant le redémarrage du routeur ; les transactions sont rejouées quand la liaison revient.
• Apps de voyage — itinéraires, cartes et billets consultés exactement là où la connectivité est la pire : avions, trains, itinérance.
• Produits pour marchés émergents et faible bande passante — des connexions intermittentes et facturées au volume font de la synchronisation différentielle en arrière-plan la seule conception respectueuse, quelle que soit la combinaison de plateformes.

Devriez-vous construire en offline-first ? Matrice de décision

La voie intermédiaire est légitime et courante : mettez les lectures en cache pour des écrans instantanés, autorisez les écritures hors ligne uniquement pour les quelques jeux de données qui en ont vraiment besoin, et gardez le reste en online-first derrière des indicateurs de connectivité honnêtes.

Limites et trade-offs

• La résolution de conflits est une décision produit déguisée en question d’ingénierie. « Quelle modification survit ? » n’a pas de réponse techniquement correcte — quelqu’un doit porter la politique champ par champ, et « garder la plus récente en silence » est un choix qui fait une victime.
• L’outbox est une file de passifs. Des écritures en attente périmées, venues d’un appareil qui réapparaît au bout de deux semaines, peuvent être rejouées dans un monde qui a changé ; politiques d’expiration et validation au rejeu sont obligatoires, pas paranoïaques.
• Les bugs de synchronisation sont la pire catégorie de bugs qui soit. Ils ne se reproduisent que sous des entrelacements précis de modifications et de connectivité — investissez dans des tests de rejeu déterministes et dans un affichage visible de l’état de synchronisation, ou déboguez à l’anecdote pour toujours.
• La vérité locale vieillit. Les écrans doivent être honnêtes sur l’obsolescence là où elle compte (prix, disponibilité) — « il y a 2 heures » est une feature, pas une excuse.
• Stockage et identité ajoutent de la friction. Les stockages sur l’appareil ont besoin de migrations comme n’importe quelle base de données, et les enregistrements créés hors ligne ont besoin d’identifiants générés côté client qui survivent au voyage jusqu’au serveur sans se dupliquer.

Synchronisation offline-first sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Ses SDK mobiles livrent la posture tampon clé en main : le Local Datastore épingle les résultats de n’importe quelle requête pour les lectures hors ligne via la même API de requête, saveEventually dote chaque écriture d’une outbox durable avec rejeu ordonné, et les triggers beforeSave de Cloud Code sont l’emplacement naturel de la politique de conflits côté serveur — contrôles de version, règles de fusion, validation au rejeu — appliquée sur chaque chemin d’écriture. Ajoutez le flux Live Query pour les deltas entrants tant que l’app est en ligne, et la boucle de synchronisation du diagramme ci-dessus devient une affaire de configuration et de politique, pas un sous-système à construire.