Ingénierie

L'offline first est une décision produit, pas une couche de cache

Chaque équipe demande le mode hors ligne après le premier retour du terrain. La difficulté n'a jamais été le cache — c'est de décider ce que l'application a le droit de promettre.

Écrit par Denis Rudenko, Software Engineer · 2026-09-12 · 2 min de lecture

Chaque équipe terrain demande le mode hors ligne après sa première semaine sans réseau. La demande ressemble à un problème de cache. Ce n'en est jamais un.

Quatre questions avant d'écrire du code

Quand deux appareils modifient le même enregistrement hors ligne, lequel l'emporte ?
Que peut promettre l'application à un utilisateur qui est hors ligne en ce moment ?
Combien de temps des données périmées peuvent-elles rester à l'écran avant de devenir un mensonge ?
Qu'advient-il d'une action en file d'attente que le serveur rejette plus tard ?

Les équipes qui répondent d'abord à ces quatre questions livrent le mode hors ligne en quelques semaines. Celles qui commencent par une bibliothèque de cache passent des mois à découvrir ces questions, un bug à la fois.

La résolution des conflits est une règle produit

Last write wins est une décision, pas un comportement par défaut. Dans une application logistique, la confirmation de livraison d'un chauffeur ne doit jamais être écrasée par une modification obsolète d'un dispatcher : l'enregistrement porte donc son origine, et la règle de fusion la lit.

fun merge(local: Delivery, remote: Delivery): Delivery = when {
    local.confirmedByDriver && !remote.confirmedByDriver -> local
    remote.updatedAt > local.updatedAt -> remote
    else -> local
}

Montrer l'état, ne pas le cacher

Les applications qui inspirent confiance hors ligne sont celles qui disent ce qu'elles savent :

Synchronisé — correspond au serveur à un horodatage visible par l'utilisateur.
En attente — mis en file localement, sera envoyé dès le retour du réseau.
Rejeté — le serveur l'a refusé, et voici ce qu'il faut faire.

Dès qu'une application prétend que tout va bien hors ligne, l'utilisateur cesse de la croire lorsqu'elle affirme que tout va bien en ligne.

Ce que ça coûte

Approche	Temps de développement	Charge de support
Cache ajouté à une application réseau	2 semaines	Élevée, pour toujours
Local first avec synchronisation	6 semaines	Faible

C'est la deuxième colonne qui tranche. Un cache greffé sur une application pensée d'abord pour le réseau génère des tickets de support pendant toute la vie du produit.

architecture
mobile
kotlin