Concevez un mode hors ligne pour vos équipes terrain : données disponibles, opérations en attente, conflits de synchronisation et vérifications sur mobile.
Un technicien termine une intervention dans un endroit où la connexion fonctionne mal. Il doit conserver ses observations et savoir si elles ont atteint le serveur. Un écran qui accepte la saisie puis la perd au rechargement ne répond pas à ce besoin.
Le mode hors ligne demande des choix métier sur les informations conservées dans l’appareil et sur les opérations autorisées sans serveur. Ces choix doivent être fixés avant de sélectionner une technologie. Le fonctionnement attendu diffère selon qu’on consulte un catalogue ou qu’on modifie un stock partagé.
Délimiter ce qui doit fonctionner sans réseau
Listez les tâches que l’équipe réalise pendant une interruption. Certaines nécessitent seulement une copie de données connues. D’autres créent de nouvelles informations qui pourront être transmises plus tard. D’autres encore exigent un état partagé à jour et devront attendre la connexion.
Dans un scénario fictif, un technicien peut consulter son ordre de mission et enregistrer un compte rendu sans réseau. La confirmation définitive d’une nouvelle réservation reste en attente, car elle dépend de la disponibilité connue du serveur. L’interface doit expliquer cette différence.
Précisez aussi la durée d’autonomie attendue et les appareils concernés. Une interruption de quelques minutes au bureau et une journée complète de déplacement ne demandent pas la même préparation des données ni la même gestion de batterie.
Afficher l’état réel des données
L’utilisateur doit distinguer un brouillon local, une opération en attente et une donnée confirmée par le serveur. Utilisez des libellés compréhensibles, avec la date de dernière synchronisation utile. Un simple pictogramme réseau ne permet pas de savoir si un dossier précis est à jour.
Si une opération attend une pièce jointe encore en cours d’envoi, indiquez cette situation. Le compte rendu et la photo peuvent avoir des états différents. Définissez à quel moment le dossier est considéré comme complet pour le métier.
Évitez de présenter une donnée ancienne comme une information actuelle. Un stock conservé sur l’appareil peut aider à préparer une demande, mais sa consultation ne garantit pas la disponibilité au moment où une commande sera acceptée.
Enregistrer les opérations dans une file durable
Une opération préparée hors ligne doit survivre aux interruptions prévues dans le périmètre : fermeture de l’application, redémarrage ou perte temporaire de session. Testez cette conservation avec les appareils réellement ciblés et expliquez ses limites.
Attribuez une identité stable à chaque opération afin que sa relance ne crée pas de doublon. Conservez son état et le résultat reçu. La logique rejoint celle des intégrations qui doivent éviter les doublons, avec une file située en partie sur l’appareil de l’utilisateur.
La documentation MDN de Background Synchronization décrit une API permettant de différer des tâches dans un service worker jusqu’au retour d’une connexion. Sa disponibilité dépend des navigateurs. Vérifiez la compatibilité ciblée et prévoyez un mécanisme explicite de synchronisation si l’application ne peut pas compter sur ce fonctionnement.
Définir une règle pour les modifications concurrentes
Un conflit apparaît quand deux personnes changent le même dossier à partir de versions différentes. Écraser systématiquement l’ancienne valeur peut convenir à certains champs, mais peut aussi effacer une décision importante. Choisissez une règle selon la donnée.
| Situation fictive | Traitement possible à valider |
|---|---|
| Ajout de deux commentaires indépendants | Conserver les deux avec leur auteur |
| Modification du même rendez-vous | Demander une résolution explicite |
| Dossier clôturé pendant une saisie hors ligne | Refuser la modification ou ouvrir une procédure de révision |
| Photo transmise deux fois | Reconnaître la répétition sans créer deux pièces |
Ces exemples ne constituent pas une règle universelle. Le métier décide quelles informations peuvent être fusionnées et lesquelles exigent un arbitrage. Conservez assez de contexte pour expliquer le conflit sans obliger l’utilisateur à reconstituer son travail de mémoire.
Limiter les données présentes sur l’appareil
Préparez les seuls dossiers nécessaires au travail prévu, avec les droits correspondants. Une copie locale peut rester accessible pendant une période sans réseau alors que les droits ont changé sur le serveur. Définissez cette durée et le comportement lors de la prochaine reconnexion.
Examinez le cas des appareils partagés, perdus ou remplacés. La déconnexion doit avoir un effet défini sur les données locales et sur les opérations non envoyées. Effacer automatiquement une file encore utile peut perdre du travail ; la conserver sans contrôle peut exposer des informations.
Précisez les responsabilités de gestion des appareils et les protections adaptées à leur usage. Le mode hors ligne ajoute une copie de données à prendre en compte dans l’exploitation du logiciel.
Tester des interruptions au milieu des opérations
Pendant la recette utilisateur, coupez la connexion après la saisie, pendant un transfert et après l’enregistrement côté serveur mais avant la réception de sa réponse. Vérifiez le résultat final et l’état affiché à l’utilisateur.
Ajoutez le manque d’espace disponible, une pièce jointe volumineuse et une session expirée. Redémarrez l’application avec des opérations en attente. Le test doit confirmer que les données sont conservées selon les garanties promises et que les erreurs restent visibles.
Préparez enfin une procédure de support pour les files bloquées. Elle doit permettre d’identifier une opération sans demander à l’utilisateur de la ressaisir immédiatement. La reprise manuelle doit préserver son identité et vérifier si le serveur l’a déjà traitée.