Hors ligne, retardé, repris : parcours mobiles

Imaginons une personne qui commence une action avec une connexion stable, la poursuit alors que la réponse tarde et revient après la fermeture de l’application. L’interface doit prendre en compte l’ensemble du parcours, et pas seulement le moment où la requête aboutit. Le fonctionnement hors ligne, c’est-à-dire l’absence de chemin réseau utilisable, constitue une condition au sein de ce problème plus large de continuité.

La latence est le délai entre une action et sa réponse. Une session interrompue est un parcours produit mis en pause avant que l’application ait entièrement résolu l’intention de la personne. Considérer ces deux éléments comme des données de conception conduit à des questions plus claires : qu’est-ce qui peut continuer localement, qu’est-ce qui nécessite une confirmation et que faut-il afficher lorsque la certitude n’est pas possible ?

Cartographiez le parcours avant de choisir une solution de repli

Commencez par l’action prévue et retracez tous les états qu’elle peut rencontrer. Un document peut être intact, modifié localement, en attente de téléversement, confirmé à distance ou bloqué par un conflit. Nommer ces états évite qu’un écran de chargement vague recouvre plusieurs situations nécessitant des explications ou des contrôles différents.

La carte doit inclure les sorties et les retours. Demandez-vous ce qui subsiste si l’application se ferme, si la connexion change ou si une réponse arrive après la disparition de l’écran visible. Plutôt que de compiler des cas limites, décrivez le parcours produit dans chaque condition de mise en œuvre que l’équipe doit prendre en charge et vérifier.

• Identifiez l’intention de la personne séparément de la requête réseau utilisée pour la concrétiser.
• Indiquez les étapes qui peuvent être effectuées localement et celles qui nécessitent une confirmation à distance.
• Consignez ce que l’interface affiche tant que le résultat reste incertain.
• Définissez où reprend une session lors du retour et quel contexte elle restaure.

Donnez un sens clair à chaque état visible

L’état correspond aux informations qu’une application conserve sur la situation actuelle. Certains états appartiennent uniquement à l’interface, comme un panneau ouvert. D’autres représentent une progression significative, comme un brouillon modifié. Les équipes produit doivent déterminer quelles informations doivent survivre à une interruption et les placer dans un stockage durable, c’est-à-dire un stockage conçu pour rester disponible après la fin de la session en cours.

Les libellés visibles doivent distinguer la progression de la confirmation. Enregistré sur cet appareil, en attente d’envoi et confirmation impossible décrivent des situations différentes. La formulation exacte dépend du produit, mais chaque message doit indiquer ce qui s’est passé, si la personne doit agir et si son travail reste disponible.

1. Nommez l’état significatif dans le langage du produit plutôt que dans celui de la mise en œuvre.
2. Déterminez quelles preuves permettent à l’application d’afficher cet état avec assurance.
3. Proposez une action suivante uniquement lorsqu’une intervention peut changer le résultat.
4. Conservez assez de contexte pour que le message reste compréhensible après un retour.

Distinguez la progression locale de la vérité partagée

Une source de vérité est le registre contrôlé qu’un produit considère comme faisant autorité lorsque des copies divergent. Une application peut conserver le travail local en attendant de le comparer à ce registre. L’interface ne doit pas laisser entendre qu’une confirmation à distance a eu lieu simplement parce que le stockage local a réussi, mais elle ne doit pas non plus présenter une progression locale utile comme si elle avait été perdue.

Une mise à jour optimiste présente le résultat prévu avant l’arrivée de la confirmation à distance. Ce choix peut remplacer une attente visible par un état provisoire, mais l’équipe doit alors définir ce qui se passe après un rejet, un retard ou une correction. Envisagez cette solution lorsque l’état provisoire est compréhensible et réversible. Pour les actions ayant des conséquences ou irréversibles, une confirmation explicite peut fournir une limite plus claire.

• Affichez un état provisoire lorsqu’une correction ultérieure pourrait autrement sembler surprenante.
• Gardez les modifications locales disponibles tant que la confirmation à distance n’est pas résolue.
• Expliquez les conflits au moyen du contenu concerné plutôt que par une erreur de synchronisation générique.
• Évitez tout remplacement silencieux lorsque le produit peut devoir préserver des modifications concurrentes.

Traitez le travail en attente comme une file gérée

Une file est un ensemble ordonné d’opérations en attente de traitement. Si une action doit continuer après le rétablissement de la connectivité, représentez-la comme une opération durable plutôt que comme une animation liée à un seul écran. L’équipe doit vérifier les conditions de mise en œuvre relatives au stockage, au travail effectué hors de l’écran visible et aux tentatives répétées avant de décider du degré d’autonomie de cette file.

Chaque opération nécessite une identité, un état actuel et une politique de nouvelle tentative, qui définit quand une autre tentative est appropriée. Lorsque le produit et le système distant le permettent, rendez le traitement idempotent, ce qui signifie que la répétition de la même opération ne crée pas d’effet supplémentaire. Si l’équipe ne peut pas établir cette condition, le produit doit s’arrêter avant une répétition ambiguë et permettre d’examiner l’action non résolue.

1. Stockez l’opération prévue avec le contexte minimal nécessaire pour la reprendre en toute sécurité.
2. Indiquez si le traitement n’a pas commencé, reste incertain, a réussi ou nécessite une intervention.
3. Ne réessayez que lorsque l’opération et le système distant permettent une répétition sûre.
4. Supprimez le travail terminé sans effacer le contexte nécessaire pour expliquer le résultat visible.

Testez les limites d’interruption, pas seulement les écrans

Les tests d’interruption doivent suivre les actions à travers les limites : avant l’envoi, pendant une réponse retardée, après le stockage local et avant la confirmation à distance. Un test ciblé modifie une condition à la fois, puis vérifie à la fois l’interface immédiate et l’état présenté après la réouverture. L’équipe peut ainsi repérer directement les règles de récupération qui manquent de clarté.

Fermez l’application à chaque étape significative d’une action en plusieurs temps, puis rétablissez la connectivité avant et après la création du travail en attente. Introduisez une modification conflictuelle hypothétique et examinez le parcours de résolution. Revenez par un point d’entrée différent et vérifiez que l’état reste compréhensible sans dépendre de l’écran d’origine.

Examinez le résultat du point de vue du produit aussi bien que du point de vue technique. Pour chaque test, déterminez si l’achèvement technique concorde avec le message visible. Les critères d’acceptation, c’est-à-dire les conditions utilisées pour évaluer le parcours, doivent couvrir le travail conservé, l’état visible, la répétition sûre et l’alignement ultérieur sur le registre faisant autorité.

Rédigez un contrat de continuité pour chaque action clé

Transformez le cadre en contrat de continuité : une brève description interne de ce que l’application conserve, communique et tente lorsqu’une action est interrompue. Pour chaque parcours clé, consignez l’état local, le registre faisant autorité, les conditions de confirmation, la règle de nouvelle tentative et l’option de récupération proposée à la personne.

La décision pratique ne consiste pas simplement à déterminer si une application est en ligne ou hors ligne. Elle consiste à définir comment le produit représente l’incertitude entre l’intention et la confirmation. Cartographiez les états, distinguez la progression locale de la vérité partagée, gérez explicitement le travail en attente et testez chaque limite d’interruption. Ensemble, ces décisions constituent un plan utilisable pour les parcours dans lesquels la continuité ne peut pas être tenue pour acquise.