Concevoir des applications mobiles face aux ruptures de continuité

Un produit mobile doit être conçu pour une connectivité changeante, des réponses différées et des sessions qui se terminent sans préavis. Il ne s’agit pas simplement de cas limites techniques. Ces conditions déterminent si une action est compréhensible, si le travail inachevé est conservé et si l’interface peut expliquer ce qui va se passer ensuite.

La question de conception utile ne consiste pas simplement à savoir si une application fonctionne hors ligne. Il faut déterminer quelles parties restent disponibles, quel état l’appareil peut conserver et comment les actions locales sont conciliées lorsque la communication reprend. Répondre tôt à ces questions produit un modèle de produit plus clair pour la conception, l’ingénierie et les tests.

Concevoir pour la continuité, pas pour une connexion parfaite

Une requête qui dépend de la connexion peut échouer avant de commencer, pendant son traitement ou après son acceptation par le système distant. L’interface peut ignorer lequel de ces cas s’est produit. Les équipes produit ont donc besoin d’une politique explicite pour gérer l’incertitude, plutôt que d’un message d’erreur générique qui traite toutes les interruptions de la même façon.

La continuité consiste à préserver le sens de la tâche dans ces différentes conditions. Une vue de lecture peut continuer à fonctionner avec du contenu stocké, tandis qu’un parcours d’envoi peut conserver un brouillon terminé sans prétendre qu’il a été transmis. Le comportement approprié dépend des conséquences du retard, de la duplication et des informations obsolètes.

Cartographier l’état avant de concevoir les écrans

L’état correspond aux informations nécessaires pour représenter le produit à un moment donné. L’état local est conservé sur l’appareil, tandis que l’état distant est maintenu ailleurs par un service contrôlé. Leur cartographie révèle quelles informations peuvent être affichées immédiatement, lesquelles doivent être vérifiées et lesquelles peuvent devenir incohérentes.

• Identifiez les informations qui peuvent rester utiles lorsqu’elles ne sont plus à jour.
• Repérez les actions qui ne doivent pas être répétées sans vérifier leur résultat distant.
• Séparez les saisies inachevées des enregistrements confirmés et des détails temporaires de l’interface.
• Définissez ce qui doit subsister après la fermeture d’une session, un redémarrage ou l’échec d’une requête.

Une cartographie des états doit décrire les transitions aussi bien que les écrans. Pour chaque action importante, demandez-vous ce que l’interface affiche avant la requête, pendant l’attente, après la confirmation et après un échec ambigu. Cette séquence rend visibles les états de récupération manquants avant qu’ils ne deviennent des décisions d’implémentation dispersées.

Rendre les actions différées lisibles

La latence est le temps qui s’écoule entre le déclenchement d’une action et la réception d’une réponse utilisable. Pendant cet intervalle, l’interface doit indiquer si la saisie a été acceptée localement, si la confirmation distante est en attente et si une autre action créerait un doublon. Un indicateur de chargement répond rarement, à lui seul, à ces questions concernant le produit.

1. Accusez immédiatement réception de l’action sans laisser entendre qu’elle est terminée à distance.
2. Conservez la saisie pertinente tant que le résultat reste incertain.
3. Affichez un état d’attente stable lorsque l’attente risque de se prolonger au-delà de l’écran actuel.
4. Proposez une nouvelle tentative uniquement lorsque la répétition de l’opération est définie comme sûre.
5. Remplacez l’état temporaire par un résultat confirmé ou récupérable.

Une politique de nouvelle tentative nécessite également un soutien technique. L’idempotence est une propriété qui permet de soumettre à nouveau la même opération sans appliquer son effet prévu plus d’une fois. Lorsque le système contrôlé peut prendre en charge cette propriété, un identifiant de requête idempotent peut réduire l’ambiguïté. Dans le cas contraire, l’interface peut devoir effectuer une vérification avant une nouvelle tentative.

Concilier les réalités locale et distante

La synchronisation est le processus qui amène les états local et distant à une forme convenue. Elle ne se résume pas à une seule action d’actualisation. Un produit doit décider quel côté fait autorité pour chaque champ, comment les changements en attente sont représentés et ce qui se passe lorsque les deux côtés ont changé pendant l’interruption.

La résolution des conflits est la politique utilisée lorsque des changements concurrents ne peuvent pas être fusionnés automatiquement. Une préférence sans effet préjudiciable peut adopter la dernière valeur acceptée, tandis qu’un contenu modifié peut nécessiter de conserver les deux copies ou de demander un choix. La politique doit suivre le sens des données plutôt que d’appliquer partout une règle unique.

Préserver délibérément le travail interrompu

Une session interrompue peut laisser des saisies précieuses en mémoire, dans le stockage persistant de l’appareil ou nulle part. La persistance consiste à stocker des informations afin qu’elles restent disponibles après la fin du processus en cours. Les équipes doivent décider ce qui mérite d’être conservé, combien de temps ces informations restent pertinentes et dans quels cas leur restauration pourrait induire en erreur.

• Enregistrez les brouillons à des étapes significatives, et pas seulement lors de l’envoi final.
• Distinguez les saisies restaurées des informations déjà acceptées à distance.
• Évitez de conserver des éléments sensibles, sauf si leurs conditions de stockage sont appropriées.
• Supprimez le travail en attente devenu obsolète après une confirmation claire ou un abandon délibéré.

La restauration doit inclure le contexte, et pas seulement les valeurs brutes. Si une application rouvre un formulaire, elle peut aussi devoir expliquer si les pièces jointes restent disponibles, si les informations dépendantes doivent être vérifiées et si un envoi précédent est toujours en attente. Ces conditions doivent être vérifiées pour la plateforme et la conception de stockage réelles.

Tester les parcours dans des conditions changeantes

Un écran peut sembler correct alors que le parcours dans son ensemble perd des données ou répète une action. Les tests doivent donc faire varier la connectivité et les limites de session pendant une tâche. L’objectif est d’examiner les transitions d’état du produit, y compris les moments où l’interface et le système distant disposent temporairement d’informations différentes.

1. Commencez une action en étant connecté, puis interrompez la communication avant la confirmation.
2. Fermez la session alors qu’un travail est en attente, puis rouvrez-la.
3. Répétez une action après une réponse ambiguë et examinez le résultat.
4. Modifiez les mêmes informations localement et à distance avant la synchronisation.
5. Rétablissez la connectivité lorsque le travail mis en file d’attente n’est plus valide.

Ces scénarios sont particulièrement utiles lorsque les résultats attendus sont consignés avant l’implémentation. Pour chacun, précisez ce qui est stocké, ce que l’interface peut affirmer, ce qui peut faire l’objet d’une nouvelle tentative et comment le produit retrouve un état stable. L’exécution en arrière-plan et le comportement du stockage propres à chaque plateforme doivent rester des éléments à vérifier, et non des hypothèses.

Choisir la politique d’échec avant les finitions

Un cadre pratique commence par quatre décisions : quelles tâches restent utiles sans connexion, quelles actions nécessitent une confirmation distante, quel travail local doit survivre à une interruption et comment les états conflictuels sont conciliés. Ces décisions établissent les limites dans lesquelles les détails de l’interface peuvent être conçus honnêtement.

L’examen final doit suivre des parcours complets plutôt que des écrans de réussite isolés. Retracez chaque action importante à travers l’attente, la déconnexion, la fermeture, la restauration, la nouvelle tentative et le conflit. Si chaque transition a un responsable, un état visible et un chemin de récupération, l’usage hors ligne et la latence deviennent des conditions définies du produit plutôt que des exceptions non spécifiées.