Logiciel terrain offline-first: le protocole de décision pour des opérations fiables

Définir offline-first comme une capacité opérationnelle

Le mode hors ligne ne se résume pas à afficher un écran déjà ouvert. Une équipe terrain doit savoir quelles tâches restent possibles, quelles informations sont suffisamment récentes et quelles actions attendent encore une confirmation du serveur. Cette distinction protège l’utilisateur contre une fausse impression de succès.

L’architecture recommandée par Android pour les applications offline-first place une source locale devant les couches supérieures. Le réseau alimente et réconcilie cette source, mais l’interface ne dépend pas d’un appel distant à chaque lecture. Pour Atlas, ce principe devient une règle de conception: le travail local doit être explicite, durable sur l’appareil et observable jusqu’à son acceptation côté serveur.

Choisir une stratégie par type d’écriture

Toutes les données ne peuvent pas suivre la même règle. Une note ou une photo peut être conservée localement puis envoyée plus tard. Une consommation de stock, une validation de prix ou un encaissement modifie un état partagé et demande davantage de contrôle. Le bon modèle classe les actions avant de choisir la technologie.

Écrire un contrat de synchronisation avant les écrans

Chaque opération locale doit pouvoir être rejouée après une coupure sans produire un second effet. L’application génère un identifiant d’opération stable avant l’envoi. Le serveur conserve cet identifiant avec le résultat déjà produit et renvoie le même résultat si la demande revient. Cette logique complète les propriétés HTTP: le protocole rappelle qu’une opération automatiquement relancée ne doit pas créer plusieurs effets lorsque sa sémantique est idempotente.

Le contrat doit aussi transporter l’identifiant de l’entité, la version lue par l’appareil, l’auteur, l’heure capturée, l’heure reçue et le type d’action. Le statut local suit au minimum quatre états: à envoyer, en cours, accepté et à corriger. Une erreur métier n’est pas traitée comme une panne réseau.

• Identifiant d’opération créé sur l’appareil et conservé après redémarrage.
• Version de départ pour détecter une modification concurrente.
• Réponse serveur stockée avec le numéro de version obtenu.
• Relance avec temporisation progressive pour les erreurs techniques.
• File d’exception distincte pour les rejets métier qui exigent une décision humaine.

Résoudre les conflits selon le sens métier

La règle du dernier enregistrement reçu est facile à coder, mais dangereuse lorsqu’elle efface une preuve, modifie une affectation ou masque un mouvement de stock. La résolution doit dépendre du type de donnée et produire une trace exploitable.

Faire une recette de coupure, pas une démo de bureau

Le test décisif se déroule sur les appareils, les volumes et les parcours réels. Il doit interrompre le réseau au mauvais moment, arrêter l’application pendant une écriture et créer une modification concurrente depuis un second appareil. L’objectif est de prouver ce que voit l’utilisateur et ce que reçoit le système, pas seulement que la file finit par se vider.

• Créer plusieurs opérations en mode avion, fermer l’application, redémarrer puis synchroniser.
• Appuyer plusieurs fois sur la même action et vérifier qu’un seul effet métier est produit.
• Modifier le même dossier sur deux appareils et vérifier la règle de conflit annoncée.
• Retirer un droit utilisateur pendant la coupure et vérifier le rejet contrôlé au retour du réseau.
• Tester un appareil avec une heure incorrecte et ne jamais utiliser son horloge comme ordre absolu.
• Mesurer âge de la file, taux de rejet, nombre de conflits, temps de reprise et opérations bloquées.

Établir une décision Go, Go conditionnel ou No-Go