Concevoir une application mobile pour une connexion instable

Quand on développe pour le marché camerounais, la connexion instable n’est pas un cas limite. C’est le cas moyen. La question n’est pas « comment gérer l’offline » — c’est « comment concevoir une expérience qui reste utile quand le réseau n’est pas fiable ».

Ce que « connexion instable » veut vraiment dire

Trois patterns différents, à traiter différemment :

1. Pas de réseau du tout — l’utilisateur est dans un endroit sans couverture. Il le sait. Il attend une expérience honnête.
2. Réseau lent — 2G ou EDGE. Ping à 800 ms, débit sous 20 KB/s. L’utilisateur ne sait pas nécessairement que c’est lent, il pense que l’app est cassée.
3. Réseau qui saute — connexion 4G qui perd la porteuse pendant 20 secondes, puis revient. Le pire cas pour une architecture qui suppose une session HTTP stable.

Les décisions produit qui ont compté

Assumer que le premier écran s’ouvre offline. L’écran d’accueil de VALIDE affiche les ressources déjà consultées avant tout appel réseau. On charge d’abord ce qui est en cache local, puis on rafraîchit en tâche de fond. Résultat : temps perçu d’ouverture divisé par trois sur réseau lent.

Rendre le statut réseau visible sans être anxiogène. Un petit indicateur discret en haut à droite, jamais un bandeau rouge « pas d’internet ». Le message : « on continue avec ce que tu as, on retentera plus tard ». L’utilisateur n’a pas à agir.

Prioriser les écritures optimistes. Poster une réponse dans un forum ou noter une ressource : l’action est enregistrée localement immédiatement, avec un état visuel « en attente de sync ». Quand le réseau revient, la sync se fait en arrière-plan. Si ça échoue, on notifie discrètement — sans perdre le contenu.

Les choix techniques qui ont soutenu ces décisions

• Cache Firestore natif — bien plus fiable qu’un cache maison ;
• File d’écritures avec WriteBatch — atomicité même en cas de coupure au milieu d’une transaction ;
• Taille des ressources limitée — un PDF de cours de 15 MB, c’est 3 minutes de téléchargement en 2G. On a segmenté en pages ;
• Détection de connectivité intelligente — connectivity_plus seul ne suffit pas ; on double-vérifie avec un ping léger sur un endpoint de santé.

Ce que je ne referais plus

• essayer de « simuler » un chargement instantané en pré-chargeant tout — ça consomme les données de l’utilisateur, qu’il paie ;
• afficher un skeleton screen pendant plus de 800 ms — au-delà, l’utilisateur pense que c’est cassé ;
• utiliser une bibliothèque tierce de gestion offline sans comprendre sa stratégie de conflit — les conflits arrivent, et les résoudre à l’aveugle coûte plus cher que de les prévoir.

Une application qui fonctionne offline n’est pas une application avec un « mode dégradé ». C’est une application dont l’expérience nominale n’est pas de dépendre du réseau à chaque geste.