Vos techniciens interviennent dans des sous-sols, vos livreurs traversent des zones blanches, vos inspecteurs relèvent des données au fond d'un entrepôt métallique. Dans ces contextes, une application mobile qui exige une connexion permanente n'est pas une application lente : c'est une application inutilisable. L'architecture offline-first renverse le raisonnement habituel en faisant du téléphone la source de vérité, le réseau n'intervenant plus que pour synchroniser en arrière-plan.

Le vrai problème n'est pas l'absence de réseau, c'est le réseau intermittent

Une coupure franche se gère assez bien : l'application sait qu'elle est hors ligne et adapte son comportement. Le cas destructeur, c'est la connexion dégradée. La requête part, le serveur la reçoit, mais la réponse n'arrive jamais. L'utilisateur ignore si son intervention a été enregistrée, donc il recommence. Vous récupérez deux fiches identiques, ou pire, aucune.

Les conséquences se voient rarement dans les indicateurs techniques, mais toujours dans le quotidien : retour au carnet papier, ressaisie le soir au bureau, données incomplètes, refus d'utiliser l'outil. Une application de terrain abandonnée par ses utilisateurs coûte bien plus cher que la conception hors ligne qu'on a voulu éviter au départ.

Offline-first : le téléphone devient la source de vérité

Le principe tient en une phrase : toute lecture et toute écriture de l'application passent d'abord par une base de données locale, embarquée sur l'appareil. L'interface n'attend jamais le réseau. Quand la connexion revient, un moteur de synchronisation pousse les modifications locales vers le serveur et récupère celles des autres utilisateurs.

Cette approche n'a rien à voir avec un simple cache. Un cache stocke une copie de lecture : si le serveur est injoignable, l'utilisateur peut consulter, mais pas produire. En offline-first, l'utilisateur crée, modifie et supprime hors ligne, et ces actions sont valides. C'est un choix d'architecture, pas une option activée en fin de projet.

Les trois briques d'un moteur de synchronisation

C'est là que se concentre la complexité réelle. Un moteur de synchronisation sérieux repose sur trois composants :

  • Une file d'attente sortante qui conserve les modifications produites hors ligne, dans l'ordre, et les rejoue quand le réseau revient. Elle doit survivre à la fermeture de l'application et au redémarrage du téléphone.
  • Un processeur entrant qui applique les changements venus du serveur à la base locale, idéalement de façon incrémentale, en ne redescendant que ce qui a changé depuis la dernière synchronisation réussie.
  • Un résolveur de conflits, qui tranche lorsque le même enregistrement a été modifié à deux endroits pendant la déconnexion.

Deux règles techniques évitent la majorité des incidents. D'abord, les identifiants sont générés par le client (UUID) et non par la base serveur : sans cela, impossible de créer une fiche hors ligne et de lui rattacher des photos ou des lignes de détail. Ensuite, chaque opération envoyée doit être idempotente : si le réseau coupe avant la réponse et que le client rejoue l'opération, le serveur doit reconnaître qu'il l'a déjà traitée plutôt que de créer un doublon.

Quatre stratégies de résolution de conflits

Choisir la stratégie de synchronisation est la décision structurante du projet. Il n'y a pas de réponse universelle, seulement une réponse adaptée à votre métier.

  1. Le dernier qui écrit gagne. Simple à mettre en oeuvre, acceptable quand les collisions sont rares et les données peu critiques. Inacceptable dès qu'une donnée perdue signifie une intervention non facturée.
  2. La propriété par enregistrement. Chaque fiche appartient à un intervenant pendant sa tournée. Les conflits deviennent structurellement impossibles. C'est la solution la plus économique et elle couvre une grande partie des besoins terrain.
  3. La fusion champ par champ. Deux modifications sur des champs différents du même enregistrement sont conservées toutes les deux. Seul un vrai désaccord sur un même champ remonte en arbitrage.
  4. Le journal d'évènements ou les CRDT. On synchronise des actions plutôt que des états, ou l'on utilise des structures conçues pour fusionner sans conflit, comme Automerge ou Yjs. Puissant pour l'édition collaborative, mais plus exigeant à exploiter.

Quel socle technique en 2026

Côté stockage local, SQLite reste la référence, directement ou via les couches natives (Room sur Android, Core Data sur iOS) et les bibliothèques multiplateformes. Côté synchronisation, l'écosystème s'est structuré autour de solutions comme PowerSync, ElectricSQL, RxDB ou Ditto, qui évitent de réécrire un moteur maison.

Un épisode récent mérite d'être gardé en tête au moment du choix. En septembre 2024, MongoDB a annoncé la dépréciation d'Atlas Device Sync et des Atlas Device SDKs, avec un arrêt du service de synchronisation au 30 septembre 2025. Des équipes qui avaient bâti leur application mobile sur cette brique ont dû migrer dans un délai contraint. La leçon n'est pas d'éviter les briques externes, mais de vérifier avant de s'engager que le format de données local et le protocole de synchronisation restent réversibles, et de garder un chemin de sortie documenté.

Le débat natif contre multiplateforme reste secondaire par rapport à cette question. Une application Flutter ou React Native bien conçue fonctionne parfaitement hors ligne. En revanche, si le stockage local doit contenir des milliers d'enregistrements et des photos sur plusieurs jours, une application installée offre des garanties de persistance qu'une application web progressive, soumise aux quotas du navigateur, ne peut pas donner.

Les pièges qui se paient plus tard

  • Les pièces jointes. Photos et signatures pèsent lourd. Il faut les compresser à la prise de vue, les stocker séparément des données métier et les téléverser dans une file dédiée, reprenable après interruption.
  • Les migrations de schéma. Un appareil resté trois semaines hors ligne revient avec une ancienne base locale et des données non envoyées. Le plan de migration s'écrit dès la première version.
  • L'authentification. Un jeton expiré hors ligne ne doit pas bloquer la saisie ni, surtout, effacer les données en attente d'envoi.
  • La sécurité. Des données métier résident sur des téléphones qui se perdent. Chiffrement de la base locale, effacement à distance et rétention limitée deviennent obligatoires, surtout si des données personnelles sont concernées.
  • Les tests. Un scénario en mode avion ne suffit pas. Il faut simuler la latence forte, la perte en cours de requête et la reconnexion partielle, sinon les bogues seront découverts par vos équipes sur le terrain.

Notre façon de cadrer ces projets

Nous procédons en trois temps. D'abord, délimiter le périmètre hors ligne : rarement toute l'application. Saisir un rapport d'intervention est indispensable, consulter tout le catalogue produits ne l'est pas. Moins vous embarquez de données, plus la synchronisation est rapide et fiable.

Ensuite, prototyper le pire scénario plutôt que le parcours nominal : deux intervenants, la même fiche, trois jours sans réseau. Un prototype rapide sur ce seul cas révèle en quelques jours ce qu'une spécification de trente pages laisse dans l'ombre. Enfin, industrialiser : journalisation des synchronisations, écran d'état montrant à l'utilisateur ce qui reste en attente, et supervision côté serveur des appareils qui ne se sont pas synchronisés depuis trop longtemps.

Questions fréquentes

Faut-il obligatoirement une application native pour fonctionner hors ligne ?

Non. Une application multiplateforme ou une application web progressive peut fonctionner hors ligne. La différence porte sur les garanties de persistance : le navigateur peut libérer l'espace de stockage, ce qui reste risqué pour des données de terrain non synchronisées. Pour un usage intensif avec photos, une application installée est plus sûre.

Comment éviter les doublons quand deux personnes modifient la même fiche ?

La méthode la plus efficace consiste à éviter le conflit plutôt qu'à le résoudre, en attribuant chaque fiche à un intervenant pendant sa tournée. Quand ce n'est pas possible, la fusion champ par champ couvre la plupart des cas et ne fait remonter en arbitrage que les vrais désaccords.

Combien de données peut-on conserver sur le téléphone ?

Techniquement beaucoup, puisque la limite est celle du stockage de l'appareil pour une application installée. La bonne question est plutôt métier : n'embarquez que les données nécessaires à la journée ou à la tournée, avec une purge automatique. Cela réduit le risque de fuite en cas de perte du téléphone et accélère la synchronisation.

Peut-on ajouter le mode hors ligne à une application mobile existante ?

C'est possible, mais rarement anodin, car cela touche la couche de données et la gestion des identifiants. L'approche réaliste consiste à traiter d'abord un parcours prioritaire, comme la saisie d'un rapport d'intervention, puis à étendre progressivement le périmètre.

Parlons de votre application de terrain

Vos équipes perdent du temps en ressaisie ou en allers-retours papier ? Nous concevons des applications métier mobiles pensées pour les conditions réelles du terrain, du cadrage au déploiement. Parlons de votre projet.