Concevoir des logiciels pour les réalités de faible connectivité

Ouvrez n'importe quelle application populaire et commencez à l'utiliser sur une connexion lente. Observez ce qui se passe. Des indicateurs de chargement qui ne se résolvent jamais. Des images qui ne se chargent pas. Des actions qui semblent fonctionner jusqu'à ce que vous réalisiez, quelques minutes plus tard, qu'elles n'ont pas abouti. La plupart des logiciels modernes sont conçus pour des conditions qui ne décrivent pas la majeure partie du monde.

Chez Ubora Labs, nous concevons dans le sens inverse dès le départ. Pas comme une fonctionnalité, pas comme une réflexion tardive sur l'accessibilité, mais comme une contrainte fondamentale qui oriente chaque décision que nous prenons. Cet article explique ce que cela signifie concrètement quand on s'assoit pour construire quelque chose.

La contrainte qui change tout

Quand vous concevez pour des données illimitées et une connectivité rapide, vous pouvez vous permettre d'être négligent. Récupérer tout à chaque fois. Ne jamais mettre en cache. Ne jamais mettre en file d'attente. Supposer que le serveur est toujours à une milliseconde.

Quand vous supprimez cette hypothèse, l'architecture entière d'un produit doit changer. Vous ne pouvez plus traiter la connectivité comme acquise. Vous devez la traiter comme une ressource qui pourrait ne pas être disponible et concevoir votre produit pour rester utile même en son absence.

La question n'est pas "que fait cette fonctionnalité quand la connexion est bonne ?" C'est "que fait cette fonctionnalité quand la connexion est coupée ?"

Cette question, posée systématiquement pour chaque fonctionnalité, produit un type de logiciel fondamentalement différent.

Ce que signifie vraiment l'offline-first

"Offline-first" est parfois utilisé de manière vague pour signifier "fonctionne un peu hors ligne." Ce n'est pas ce que nous voulons dire. Offline-first signifie que l'état par défaut de l'application est de fonctionner pleinement sans connexion, et la connectivité est traitée comme une amélioration quand elle est disponible, pas comme une exigence.

En pratique, pour un produit comme Ubora Écoles, cela signifie :

• 01 Stockage de données local en priorité. Les dossiers des élèves, les notes, les présences et les emplois du temps sont stockés sur l'appareil. L'application lit depuis le stockage local en premier, pas depuis le serveur. Un enseignant peut enregistrer les présences dans une salle de classe sans signal. La synchronisation se fait au retour de la connexion.
• 02 Résolution des conflits par conception. Quand un appareil se synchronise après avoir été hors ligne, le serveur peut avoir des données plus récentes. L'application a besoin d'une politique claire sur ce qui prévaut. Nous rendons ces règles explicites plutôt que de laisser la situation produire une corruption silencieuse des données.
• 03 Actions en file d'attente, pas actions échouées. Si un parent envoie un message à un enseignant hors ligne, ce message est mis en file d'attente localement et envoyé au retour de la connexion. L'expérience utilisateur affiche "envoyé", pas "échoué". Rien n'est perdu.
• 04 Amélioration progressive pour le contenu lourd en données. Les images, rapports et documents sont chargés à la demande, pas automatiquement. Les utilisateurs choisissent ce qu'ils téléchargent. Ce n'est pas une limitation, c'est du respect pour leur budget données.

Data-aware n'est pas la même chose que minimaliste

La conception pour faible données est parfois confondue avec des applications qui ont l'air minimal ou dépouillé. Ce n'est pas l'objectif. L'objectif est l'intentionnalité concernant quelles données sont transférées et quand.

Une application data-aware suit la quantité de données que chaque opération consomme. Elle offre aux utilisateurs des choix sur quand synchroniser, quand télécharger des médias et ce qu'il faut mettre en cache pour une utilisation hors ligne. Elle distingue ce qui doit être à jour et ce qui peut avoir quelques heures de retard sans conséquence.

Concevoir pour l'appareil réel, pas l'idéal

L'autre côté de cette contrainte concerne le matériel. L'appareil médian qui fait tourner nos produits n'est pas un smartphone haut de gamme acheté l'année dernière. C'est un Android milieu de gamme avec une RAM limitée, un stockage limité et une batterie qui a été trop souvent rechargée.

Cela change la façon dont vous écrivez du code. Les frameworks JavaScript lourds qui fonctionnent bien sur un appareil haut de gamme deviennent lents et énergivores sur un téléphone d'entrée de gamme vieux de trois ans. Les animations qui semblent soignées sur du matériel rapide paraissent saccadées et consommatrices de batterie sur des appareils réels.

Nous testons sur les appareils que nos utilisateurs ont réellement. Pas seulement dans des simulateurs. De vrais appareils, de vraies conditions, de vraies vitesses réseau. L'écart entre "fonctionne dans le simulateur" et "fonctionne sur le terrain" est suffisamment grand pour tuer un produit si vous ne le comblez pas tôt.

Pourquoi cela importe au-delà de l'Afrique

Les logiciels conçus pour la pénurie de données sont, à bien des égards, de meilleurs logiciels. Ils sont plus rapides. Ils sont plus résilients. Ils fonctionnent dans les sous-sols et dans les trains et dans les zones à mauvaise couverture partout, pas seulement là où les données sont chères.

Les principes que nous appliquons en construisant pour l'Afrique produisent des applications plus réfléchies sur les ressources, plus respectueuses de l'autonomie des utilisateurs, et plus robustes face à des conditions imprévisibles. Ce n'est pas un lot de consolation pour construire sous contraintes. C'est le résultat de prendre ces contraintes au sérieux comme données de conception.

La contrainte n'est pas la limitation. C'est le cahier des charges.