Perte de connexion mobile : les 3 stratégies possibles

Ouvrez WhatsApp dans un tunnel de métro et envoyez un message. Une petite horloge grise apparaît à côté du texte. Le message reste dans l’interface. La file d’attente prend le relais. À la sortie du tunnel, l’horloge devient un simple ✓, puis ✓✓ quand le destinataire reçoit.

Sur plus de 3 milliards d’utilisateurs mensuels en 2025 (Backlinko — WhatsApp Users 2026, source Meta Q1 2025), ce détail est probablement la décision produit mobile la plus vue au monde. Il condense une réponse — parmi trois possibles — à la question que toute équipe mobile finit par se poser : que doit faire l’application quand le réseau tombe pendant que l’utilisateur enregistre une action ?

Il existe trois stratégies. Chacune modifie l’expérience utilisateur, la complexité technique et la nature du contrat de confiance passé avec l’utilisateur. Le marqueur de séniorité mobile n’est pas de savoir implémenter les trois — c’est de savoir arbitrer entre les trois, action par action.

Pourquoi le mobile impose ce choix

Un backend intra-datacenter subit des partitions réseau rares. Une application mobile connectée à ce même backend est toujours dans un régime de partition potentielle : tunnel, ascenseur, changement de cellule, saturation, roaming. La perte de réseau n’est pas un edge case en mobile — c’est un état régulier.

Le théorème CAP, posé par Eric Brewer en keynote à PODC 2000 puis formalisé par Seth Gilbert et Nancy Lynch au MIT en 2002 (Gilbert & Lynch, ACM SIGACT News 2002), stipule qu’un système distribué ne peut pas simultanément garantir la Consistency, l’Availability et la Partition tolerance. En pratique, P n’est pas négociable ; le vrai choix est donc entre C ou A pendant une partition.

Traduit côté mobile :

• Choisir C → si le réseau tombe, refuser l’action ou attendre. C’est la stratégie 01 (Bloquer).
• Choisir A → si le réseau tombe, accepter l’action localement, réconcilier plus tard. C’est la base des stratégies 02 et 03.

Le CAP ne dit pas qu’il faut choisir C ou A une fois pour toutes pour l’app entière. Il dit qu’à chaque opération en régime de partition, un choix est fait — implicitement ou explicitement. Le rôle du développeur senior mobile est de rendre ce choix explicite et documenté.

Stratégie 01 — Bloquer

L’application refuse d’accepter l’action tant que la confirmation serveur n’est pas reçue. L’UI reste en état pré-action, avec un spinner, jusqu’à retour du serveur ou timeout.

Le premier onboarding de Notion refusait les modifications hors ligne — c’était une critique récurrente pendant des années, jusqu’à la sortie de l’offline natif en août 2025 (version 2.53) (XDA Developers, août 2025). Cette absence a été un frein commercial documenté contre Apple Notes et Obsidian. Notion n’utilisait pas la stratégie 01 par principe — l’équipe reconnaissait la limite, mais la considérait comme moins prioritaire que d’autres chantiers.

Le message est clair : bloquer par défaut n’est pas un choix neutre. Sur toute action non-critique, c’est une dette qui se paie en churn.

Stratégie 02 — File locale + synchronisation (pattern outbox)

L’application enregistre l’action immédiatement dans une base locale (SQLite, Isar, Drift, Hive, Realm) dans la même transaction qu’une entrée dans une table outbox. L’UI reflète l’état local. Un worker asynchrone consomme l’outbox et synchronise avec le serveur, avec retry et back-off exponentiel.

Le pattern transactional outbox a été formalisé par Chris Richardson pour l’architecture micro-services (microservices.io — Transactional Outbox (Chris Richardson)) pour résoudre le dual-write problem : garantir qu’un événement publié dans un broker reste cohérent avec l’état écrit en base. Le problème mobile est structurellement identique — garantir qu’un appel API différé est cohérent avec l’état local que l’utilisateur voit à l’écran.

Cas d’école : WhatsApp

WhatsApp est probablement l’implémentation la plus visible au monde de cette stratégie. Lorsque le réseau tombe :

1. Le message est écrit immédiatement dans SQLite local avec un client_id UUID
2. L’icône horloge grise indique « en attente d’envoi au serveur »
3. Un worker retente périodiquement — à retour du réseau, l’envoi passe

Le passage aux icônes suivantes (✓ = serveur reçu, ✓✓ = livré au destinataire, ✓✓ bleus = lu) donne les 4 états UX obligatoires en une seule cellule visuelle (LINK Mobility — What do WhatsApp check marks mean?). C’est ce système d’icônes qui a probablement contribué au succès de WhatsApp sur les marchés à connectivité irrégulière — l’Inde, le Brésil et l’Indonésie sont les trois premiers marchés WhatsApp par nombre d’utilisateurs.

Cas d’école : Google Docs

Depuis la Chrome App HTML5 introduite en août 2011 (TechCrunch, 31 août 2011), Google Docs applique une variante mobile de la stratégie 02 : les modifications sont écrites localement (IndexedDB sur web, structures locales sur mobile), un worker synchronise dès le retour du réseau. Sur les collaborations multi-utilisateur, le merge utilise une variante d’algorithme de réconciliation (Operational Transformation historiquement, algorithmes proches de CRDT aujourd’hui — voir Shapiro et al., SSS 2011 (Shapiro et al., SSS 2011 (LIP6))).

Stratégie 03 — Optimistic UI

L’application reflète immédiatement le résultat présumé de l’action dans l’UI — comme si le serveur avait répondu OK — puis lance l’appel réel en arrière-plan. En cas de succès, aucun changement visible. En cas d’échec, rollback silencieux ou explicite de l’UI.

Séquence de l’optimistic UI (le like) :

Le like Instagram est le cas d’école le plus cité en pédagogie UX (DEV Community — Optimistic UI Updates Explained) : le tap sur le cœur déclenche l’animation avant l’appel API. Cette stratégie ramène le feedback perçu sous 100 ms — le seuil de perception d’immédiateté établi par Robert Miller en 1968 et repris par Jakob Nielsen dans Usability Engineering (1993) (Nielsen Norman Group — Response Times: The 3 Important Limits) — indépendamment de l’état du réseau.

Différence avec la stratégie 02 : la donnée n’est pas nécessairement persistée localement. En cas d’échec, elle disparaît sans laisser de trace — c’est le risque assumé. Les deux stratégies peuvent se combiner : optimistic UI pour le rendu immédiat + outbox pour la persistance et le retry. C’est exactement ce que fait Instagram sur les commentaires, WhatsApp sur les messages, et Slack sur les réactions.

La grille de décision

Le choix de stratégie n’est pas une doctrine — c’est une matrice 2×2 à relire à chaque nouvelle action produit :

Une même app doit typiquement occuper les 4 quadrants. Prenez une app bancaire :

• Like d’une notification push marketing → Optimistic
• Modification du libellé d’un compte → File locale
• Envoi d’un message au conseiller → File locale
• Virement SEPA → Bloquer

Confondre les plans (« on fait du offline partout » ou « on fait tout en optimistic ») produit des dettes techniques qui deviennent structurelles.

Les 4 états UX obligatoires

Toute stratégie qui n’est pas « Bloquer » impose de communiquer explicitement à l’utilisateur l’état de sa donnée. Quatre états sont nécessaires et suffisants, avec des transitions bien définies :

Cinq anti-patterns à surveiller

Ce qu’il reste à faire cette semaine

Prendre les cinq dernières fonctionnalités livrées par l’équipe. Pour chacune, écrire à l’oral en une phrase la stratégie utilisée : « bloquer », « file locale », « optimistic ». Puis vérifier deux choses :

1. Le choix est-il explicite ? Documenté quelque part, ou implicite dans le code sans que personne ne puisse le nommer ?
2. Correspond-il à la case attendue de la matrice ? Un virement en optimistic est un incident qui attend d’arriver. Un like en bloquant, c’est trois utilisateurs qui désinstallent chaque semaine.

Si personne ne sait, c’est probablement bloquer par défaut — et ça se voit dans la NPS.

Sources principales

• Gilbert, S. & Lynch, N. — « Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services », ACM SIGACT News, 2002.
• Richardson, C. — « Pattern: Transactional outbox », microservices.io.
• Shapiro, M., Preguiça, N., Baquero, C., Zawirski, M. — « Conflict-free Replicated Data Types », SSS 2011, LNCS 6976.
• Backlinko — « WhatsApp User Statistics 2026 » (Meta Q1 2025 earnings — 3 Md MAU).
• XDA Developers — « Notion’s offline mode is finally here », août 2025.
• Nielsen, J. — Usability Engineering, Academic Press, 1993 (seuils 100 ms / 1 s / 10 s, chapitre 5).