Concevoir une application qui continue de fonctionner sans Internet

Définir ce qui doit fonctionner hors ligne

Le mot offline recouvre plusieurs niveaux : consulter des données déjà chargées, créer une opération, modifier un dossier ou déclencher une action matérielle. La première décision consiste à classer les fonctions selon leur besoin de continuité et le risque d’une décision prise sans serveur. Une consultation peut souvent être locale ; un paiement irréversible demande davantage de garde-fous.

Pour chaque action, on rédige un contrat hors ligne : données nécessaires, durée de validité, preuve produite et message affiché. Cette discipline empêche de promettre un fonctionnement complet lorsque seule une partie du parcours est réellement disponible.

Le journal local avant la synchronisation

Au lieu de modifier silencieusement une copie, l’application enregistre une opération dans un journal : identifiant unique, auteur, appareil, date, type d’action, charge utile et version du schéma. Elle passe par des états visibles comme en attente, en cours d’envoi, confirmée ou à résoudre. Une transaction locale garantit que la donnée métier et l’entrée de journal évoluent ensemble.

Les identifiants sont générés côté appareil pour éviter les doublons à la reconnexion. L’envoi doit être idempotent : répéter la même requête ne crée pas une seconde opération. Le serveur conserve l’identifiant d’origine et retourne un accusé exploitable par le client.

• Écrire localement avant d’annoncer le succès.
• Attribuer un identifiant stable à chaque opération.
• Conserver les erreurs et tentatives sans perdre la donnée.

Synchroniser sans créer de tempête

Une reconnexion après plusieurs heures peut déclencher des centaines d’opérations. Le moteur utilise des lots, une temporisation progressive et une reprise après interruption. Il vérifie la disponibilité réelle du service plutôt que la simple présence d’un réseau.

Les opérations dépendantes exigent un ordre : on ne synchronise pas un paiement avant le contrat auquel il appartient. Un graphe simple de dépendances ou des priorités évitent les erreurs. La synchronisation descendante respecte aussi les versions afin de ne pas écraser une modification locale plus récente.

Traiter les conflits comme une décision produit

La stratégie dernier arrivé, dernier gagnant est facile mais peut supprimer une information légitime. Certains champs peuvent être fusionnés, certains événements seulement ajoutés, et certaines décisions soumises à un humain. Deux commentaires peuvent coexister ; deux attributions exclusives ne le peuvent pas.

L’interface explique qu’une action est en attente ou qu’un conflit demande une résolution. Masquer cet état crée une confiance artificielle. Les principes local-first montrent que contrôle local et collaboration peuvent coexister, mais exigent un modèle conçu pour la convergence.

Sécuriser puis mesurer la continuité

Un appareil peut être perdu, compromis ou mal configuré. Les données locales sensibles sont chiffrées, les secrets stockés dans le coffre de la plateforme et les droits limités. Le serveur distingue la date déclarée par l’appareil de la date de réception et traite les anomalies comme des signaux à examiner.

Un test en mode avion ne suffit pas. Il faut simuler réseau instable, arrêt brutal, stockage plein et modifications concurrentes. Les indicateurs utiles sont le taux d’opérations confirmées, le délai de synchronisation, les conflits et les interventions manuelles. L’offline-first réussit lorsque l’utilisateur sait ce qui est enregistré et ce qui reste à confirmer.

Concevoir l’interface autour des états réels

Une icône de réseau ne suffit pas à expliquer la fiabilité d’une opération. L’interface distingue enregistré sur cet appareil, en attente d’envoi, accepté par le serveur et refusé. Elle affiche l’heure de la dernière synchronisation, permet de relancer une erreur et évite les messages de succès définitif avant l’accusé du serveur.

Ces états doivent rester compréhensibles sans vocabulaire technique. Pour une série d’opérations, un centre de synchronisation peut regrouper les éléments bloqués et indiquer l’action attendue. L’utilisateur garde ainsi le contrôle, même si la reconnexion intervient plusieurs jours plus tard ou depuis un autre réseau.

Préparer un plan de test reproductible

Le test commence par une matrice : fonction, état du réseau, état du stockage, version de l’application et concurrence éventuelle. On rejoue le même scénario avec une coupure avant l’écriture locale, pendant l’envoi et après la réception côté serveur. Chaque point doit conduire à un état déterministe après redémarrage.

Les migrations de schéma méritent une attention particulière, car un appareil peut revenir en ligne après plusieurs versions. Le client doit savoir migrer son journal ou expliquer pourquoi une mise à jour est obligatoire, sans perdre les opérations déjà enregistrées.

• Couper le processus à chaque étape critique.
• Répéter les mêmes opérations pour vérifier l’idempotence.
• Tester les conflits avec deux appareils.
• Mesurer le temps de récupération après reconnexion.