Concevoir une application capable de fonctionner hors connexion ne consiste pas simplement à enregistrer une copie de ses écrans. Cette décision a des conséquences sur les tâches que l’utilisateur peut accomplir, l’actualité des données, la sécurité de l’appareil et la manière de résoudre les modifications lorsque le réseau revient. Une fonction disponible hors connexion peut être utile, mais aussi induire en erreur si elle affiche des informations obsolètes ou confirme une opération qui n’a pas encore atteint le serveur.
La question pratique n’est pas de savoir si toute l’application doit fonctionner hors connexion. Il s’agit de déterminer quelles tâches doivent pouvoir se poursuivre, dans quelles conditions et avec quelles conséquences si la synchronisation est retardée ou échoue. Le cadre ci-dessous permet de transformer cette question en décisions de produit et d’architecture avant de choisir une mise en œuvre.
Commencez par définir ce que signifie fonctionner hors connexion
Trois objectifs distincts sont souvent confondus. Une expérience hors connexion permet d’accomplir certaines tâches sans réseau et conserve les modifications pour les transmettre ultérieurement. La tolérance aux interruptions vise à éviter qu’une brève coupure n’interrompe le flux de travail, par exemple en conservant un brouillon pendant la reconnexion. Un mode dégradé maintient certaines fonctions, mais désactive celles qui dépendent de données ou de services indisponibles.
Ces approches ne s’excluent pas mutuellement. Une application peut permettre de consulter des dossiers récents sans réseau, d’enregistrer des notes localement et exiger une connexion pour approuver une transaction. Cette combinaison est généralement plus sûre que de promettre un fonctionnement complet. Formulez le périmètre sous forme de règles visibles : « les brouillons peuvent être créés hors connexion » est plus précis que « l’application fonctionne hors connexion ».
Avant de concevoir la solution, étudiez le contexte : couverture habituelle, durée possible des coupures, appareils partagés ou personnels et conséquences d’une interruption du travail. Une équipe de terrain qui consigne des inspections n’a pas les mêmes besoins qu’un tableau d’administration qui modifie des autorisations. Si vous ne disposez pas de données sur les conditions réelles, interrogez les utilisateurs et mesurez les problèmes de réseau existants. Ne concevez pas votre solution à partir d’une durée de déconnexion supposée.
Hiérarchisez les tâches selon leur criticité et leur réversibilité
Dressez l’inventaire des tâches, et pas seulement celui des écrans. Pour chacune, demandez-vous : est-elle indispensable à l’accomplissement du travail ? Peut-elle attendre ? Quel préjudice pourrait causer son exécution à partir d’informations obsolètes ? Est-il facile de l’annuler ou de la corriger ? Cette évaluation évite de décider d’activer une fonction uniquement parce que c’est techniquement facile.
- Continuer hors connexion : tâches nécessaires, à faible risque, dont les données peuvent être conservées sans ambiguïté, comme remplir un formulaire ou consigner une observation.
- Autoriser avec des limites : actions pouvant rester en attente, mais qui nécessitent un contexte, des avertissements ou une validation ultérieure. Par exemple, modifier un dossier téléchargé en affichant clairement la date de sa dernière mise à jour.
- Exiger une connexion : opérations irréversibles ou sensibles, ou nécessitant une autorisation ou la disponibilité immédiate du serveur, comme confirmer une opération financière ou modifier des droits d’accès.
Décidez également de ce qui doit se passer si le réseau est interrompu au milieu d’une tâche. Si l’utilisateur risque de perdre son travail, enregistrez fréquemment les brouillons et permettez leur récupération. Si une action ne peut pas être enregistrée de manière sûre hors connexion, indiquez-le avant que l’utilisateur ne l’effectue, et non après une erreur inattendue.
Choisissez les données locales selon leur fraîcheur et leur exposition
Le mode hors connexion suppose que certaines données soient disponibles sur l’appareil. Pour chaque ensemble de données, définissez ce qui est téléchargé, à quel moment, pendant combien de temps et par qui ces données peuvent être consultées. Ne conservez que ce qui est nécessaire aux tâches autorisées : une copie étendue facilite certaines consultations, mais augmente les risques d’exposition en cas de perte de l’appareil ou de session laissée ouverte.
Établissez une politique de fraîcheur compréhensible. Une donnée mise à jour il y a quelques minutes peut rester acceptable, contrairement à une donnée qui n’a pas été validée depuis plusieurs jours. Affichez la date de dernière mise à jour et distinguez clairement les informations stockées localement de celles qui ont été confirmées par le serveur. Si le retard de mise à jour risque de rendre une décision dangereuse, ne présentez pas la donnée comme actuelle : limitez l’action ou demandez une connexion.
Définissez aussi ce qui se passe à la déconnexion, lors d’un changement d’utilisateur ou en cas de perte d’accès. Les brouillons sont-ils conservés ? Les données téléchargées sont-elles supprimées ? Une autre personne peut-elle les consulter sur un appareil partagé ? La réponse dépend de la sensibilité des données et des besoins opérationnels. Examinez les contrôles de stockage et d’accès avec les responsables de la sécurité. Ne supposez pas que le stockage local est privé par défaut.
Concevez la synchronisation et la gestion des conflits avant la mise en œuvre
Une action enregistrée sans réseau n’est pas une action terminée. L’application doit la conserver comme étant en attente, tenter de l’envoyer lorsque la connexion revient et en communiquer l’état. Pour chaque opération, définissez ce qui se passe si l’utilisateur ferme l’application, redémarre l’appareil, perd sa session ou reste hors connexion pendant une période prolongée.
Une file d’attente de synchronisation doit prévoir les nouvelles tentatives comme une partie normale de la conception. Tenez compte des interruptions, des réponses en échec et des envois répétés : si le renvoi d’une opération risque de la dupliquer, définissez comment le serveur reconnaîtra qu’il s’agit de la même action. N’indiquez pas « terminé » avant d’avoir reçu une confirmation. Des états comme « enregistré sur cet appareil », « en attente de synchronisation » et « synchronisé » contribuent à maintenir des attentes réalistes.
Des conflits surviennent lorsque la même donnée est modifiée sur l’appareil et sur le serveur avant la synchronisation. Il n’existe pas de règle universelle qui les résolve correctement dans tous les cas. Vous pouvez conserver une version, fusionner des champs indépendants ou demander à une personne d’examiner les différences. Le choix dépend du sens de la donnée :
- Pour une note ajoutée, il peut être pertinent de conserver les deux versions ou d’ajouter les entrées à la suite.
- Pour des champs modifiés séparément, une fusion champ par champ peut éviter des écrasements inutiles.
- Pour un inventaire, des attributions ou des états qui ont des conséquences pour d’autres personnes, il est préférable de valider l’opération par rapport à l’état actuel et d’expliquer pourquoi elle pourrait être refusée.
Documentez la version qui prévaut et ce que l’utilisateur voit en cas de conflit. Une politique automatique du « dernier enregistrement prioritaire » est simple, mais elle peut supprimer du travail sans que personne ne s’en aperçoive. Ne l’utilisez que si la perte d’une modification est acceptable et clairement visible.
Faites en sorte que l’état de la connexion soit exploitable
Un indicateur de réseau ne suffit pas. L’utilisateur doit savoir si l’application est connectée, si ses modifications ont été enregistrées localement, combien restent en attente et quoi faire lorsqu’une synchronisation nécessite son attention. Utilisez des messages concrets et cohérents sur l’écran où le travail est effectué. N’assimilez pas « hors connexion » à « non enregistré » : le résultat dépend de la tâche et doit être communiqué.
Proposez un moyen de rétablir la situation. Si un envoi échoue, indiquez s’il sera automatiquement retenté ou si une intervention est nécessaire. Si le serveur refuse une modification, identifiez le dossier concerné et présentez des options sûres pour la corriger. Ne supprimez pas une modification en attente uniquement pour faire disparaître une alerte et ne bloquez pas l’utilisateur avec des messages techniques qui ne proposent aucune action utile.
Testez les coupures réelles et définissez les critères de lancement
Les tests ne doivent pas se limiter à l’activation du mode avion. Incluez un signal intermittent, une déconnexion pendant l’envoi, une fermeture forcée, un redémarrage, un manque d’espace, une session expirée, une reconnexion lente et des modifications simultanées depuis plusieurs appareils. Vérifiez que le travail enregistré est conservé, que les doublons n’apparaissent pas et que les conflits sont résolus conformément à la règle définie.
Avant le lancement, établissez des critères vérifiables : quelles tâches fonctionnent sans réseau, quelles données peuvent devenir obsolètes, quel volume de travail en attente est acceptable, comment les erreurs de synchronisation sont détectées et qui traite les cas nécessitant un examen. Après le lancement, surveillez avec prudence les échecs de synchronisation et les abandons de tâches, sans collecter plus d’informations locales que nécessaire.
La meilleure stratégie hors connexion ne consiste pas à maximiser le nombre de fonctions disponibles : elle permet de poursuivre les tâches importantes avec des limites explicites, protège les données et offre un moyen fiable de récupérer chaque modification. Si une tâche ne peut pas être exécutée à partir d’informations obsolètes ni confirmée avant le rétablissement de la connexion, un mode dégradé bien expliqué peut constituer un meilleur produit qu’une expérience hors connexion apparemment complète.