Développement mobile en Afrique de l'Ouest : concevoir pour le réseau réel

Une application mobile conçue dans un bureau climatisé, en Wi-Fi, sur un téléphone haut de gamme, fonctionne toujours. Le problème apparaît quand un agent de terrain l'ouvre à Kolda, en 3G instable, sur un appareil d'entrée de gamme dont la mémoire est déjà saturée, avec 8 % de batterie.

Ces conditions ne sont pas des cas limites : ce sont les conditions normales d'usage.

Concevoir pour la coupure, pas pour la connexion

La première décision d'architecture est celle-ci : l'application doit-elle fonctionner sans réseau ? Pour toute application de collecte, d'inspection ou de suivi sur le terrain, la réponse est oui, et cela change tout.

• Les données saisies sont d'abord écrites localement, puis synchronisées quand le réseau revient. Jamais l'inverse.
• La synchronisation doit être reprenable. Une transmission coupée à 70 % reprend là où elle s'est arrêtée au lieu de tout recommencer.
• Les conflits doivent être prévus. Deux agents modifient la même fiche hors ligne : qui gagne, et comment l'utilisateur en est-il informé ?
• L'utilisateur doit voir l'état. Ce qui est enregistré, ce qui attend d'être envoyé, ce qui a échoué. Une icône de synchronisation honnête évite les doubles saisies.

Le poids compte

Sur un forfait payé au mégaoctet, chaque image non compressée est un coût pour l'utilisateur. Nous visons une application légère au téléchargement, des échanges réseau réduits au strict nécessaire, des images redimensionnées avant envoi et des formats de données compacts. Un tableau de bord qui rapatrie dix mille lignes pour en afficher vingt est un défaut de conception, pas un détail d'optimisation.

Tester sur ce que les gens utilisent

Le parc réel est dominé par Android, souvent des versions anciennes, sur des appareils modestes. Trois pratiques changent la qualité perçue :

• tester sur un appareil d'entrée de gamme réel, pas seulement sur un émulateur ;
• simuler un réseau dégradé pendant la recette, pas seulement une coupure franche ;
• vérifier le comportement quand le système tue l'application en arrière-plan pour récupérer de la mémoire.

Application native, web ou hybride ?

La question mérite mieux qu'une réponse de principe.

• Le web progressif convient quand l'usage est occasionnel, que l'installation est un frein et que les besoins matériels sont limités. Il évite la contrainte des magasins d'applications, ce qui compte pour une administration qui doit corriger vite.
• Le natif ou l'hybride compilé s'impose dès qu'il faut un usage hors ligne intensif, l'accès au GPS en arrière-plan, l'appareil photo de manière soutenue, ou une réactivité à toute épreuve.

Le critère décisif n'est pas technique, il est organisationnel : qui maintiendra l'application, avec quelles compétences, sur quel budget annuel.

Ne pas oublier ceux qui n'ont pas de smartphone

Pour certains dispositifs publics, une part des bénéficiaires n'a pas d'accès internet. Un canal de repli — SMS, USSD, ou un agent équipé qui saisit pour eux — n'est pas une régression : c'est la condition pour que le service atteigne réellement sa cible. Cela se conçoit dès le départ, car cela impose une structure de données compatible avec des échanges très pauvres.

La batterie et la chaleur

Une application qui interroge le GPS en continu vide un téléphone en deux heures. Sur une tournée d'une journée, sans prise de courant, c'est rédhibitoire. Les relevés de position s'espacent, les synchronisations se regroupent, les traitements lourds attendent la recharge.

En résumé

La qualité d'une application mobile de terrain ne se mesure pas à la richesse de son interface, mais à son comportement dans les mauvaises conditions. C'est là que se joue l'adoption : un agent qui a perdu une fois deux heures de saisie n'ouvrira plus l'application avec confiance.