Développement mobile : concevoir pour les vrais téléphones et les vrais réseaux

Il y a un piège dans le développement mobile : on conçoit sur un téléphone haut de gamme, dernier modèle, connecté en fibre, et on oublie que l'utilisateur, lui, tient souvent un appareil d'entrée de gamme sur un réseau capricieux. Entre les deux, le fossé est immense. Une application qui tourne parfaitement au bureau peut devenir inutilisable sur le terrain : lente, gourmande, instable.

Concevoir pour le terrain africain, c'est d'abord accepter cette réalité et concevoir pour le téléphone que l'utilisateur a vraiment, pas pour celui du développeur. C'est cette exigence qui nous a conduits à développer en natif, sur iOS comme sur Android, les applications de notre loto digital. Voici pourquoi, et ce que cela change concrètement.

Le téléphone du développeur n'est pas celui de l'utilisateur

Sur la plupart de nos marchés, le parc est dominé par des smartphones d'entrée de gamme : peu de mémoire, processeur modeste, stockage limité, écran réduit. Ce ne sont pas des cas marginaux à gérer en plus du cas nominal, c'est le cas nominal. La majorité des utilisateurs sont là, et une application qui les ignore se prive de la majorité de son public.

Cette inversion de perspective change tout. Au lieu de viser le haut de gamme et de dégrader pour le reste, on conçoit d'abord pour le bas de gamme et on profite du surplus quand il existe. L'appareil le plus modeste devient la cible de référence, celle sur laquelle l'expérience doit déjà être fluide. Tout ce qui passe sur ce téléphone-là passera, à plus forte raison, sur les autres.

Pourquoi le natif, et pas le multi-plateforme

Le choix du natif n'est pas un réflexe de puriste. Sur des appareils contraints, la performance n'est pas un luxe, c'est la condition de l'usage. Le code natif tire le meilleur parti de chaque plateforme, consomme moins de mémoire et d'énergie, démarre plus vite, et reste réactif là où une couche d'abstraction supplémentaire ajoute du poids et des aléas. Sur un téléphone d'entrée de gamme, cette différence se voit immédiatement.

Le natif donne aussi un accès direct et fiable aux capacités du système, et un meilleur contrôle du comportement de l'application dans les situations limites : mémoire saturée, réseau coupé, batterie faible. Pour une application qui touche à de l'argent et à des prises de jeu, cette robustesse dans les cas dégradés prime sur l'économie d'un code partagé. On préfère deux bases natives bien tenues à une base unique qui plie sur le terrain.

Chaque mégaoctet compte

Sur un marché où la data se paie cher et où le stockage est compté, la taille de l'application est une contrainte de premier ordre. Une application trop lourde se télécharge mal, se met à jour rarement, et finit désinstallée pour libérer de la place. Chaque mégaoctet économisé, sur le binaire comme sur les données échangées, est un utilisateur de plus qui garde l'application et la met à jour.

Cette sobriété se travaille partout : limiter le poids des images, ne charger que le nécessaire, mettre en cache intelligemment pour éviter de retélécharger, compresser les échanges avec le serveur. Ce qui passe pour un détail d'optimisation dans un contexte aisé devient ici un facteur d'adoption. L'application la plus légère n'est pas la plus pauvre, c'est souvent la plus utilisée.

La batterie est l'autre ressource qu'on oublie depuis un bureau alimenté en permanence. Sur le terrain, recharger n'est pas toujours simple, et une application qui vide la batterie est une application qu'on évite d'ouvrir. Économiser l'énergie, c'est limiter les réveils inutiles, les traitements en arrière-plan et les échanges réseau superflus. Une application sobre en énergie est une application qu'on garde à portée de main, prête à servir.

Le réseau comme première contrainte

L'autre réalité, c'est le réseau. Intermittent, lent, parfois absent, il ne ressemble en rien à la connexion stable sur laquelle on développe. Une application qui suppose que le réseau répond toujours, et vite, échoue dès la première coupure. Il faut donc concevoir pour le réseau réel : tolérer la latence, gérer proprement les pertes, et ne jamais bloquer l'utilisateur sur une requête qui traîne.

Concrètement, cela veut dire des opérations qui survivent à une coupure, des retentatives sûres, et une application qui reste utilisable même dégradée. Les mêmes disciplines que côté serveur, l'idempotence pour qu'une action rejouée ne compte qu'une fois, se prolongent jusque dans l'application. Le mobile n'est pas un simple écran, c'est le premier maillon d'une chaîne transactionnelle qui doit tenir de bout en bout.

La fragmentation, une réalité à embrasser

Le monde Android, en particulier, est un patchwork : des dizaines de fabricants, des versions du système très étalées, des tailles et densités d'écran innombrables, des surcouches qui modifient le comportement attendu. Prétendre tout uniformiser est illusoire. La bonne approche est d'embrasser cette diversité plutôt que de la combattre, en s'appuyant sur ce qui est stable et en testant ce qui ne l'est pas.

Cela impose une discipline de compatibilité : viser une base de versions large, se méfier des fonctionnalités trop récentes que la majorité du parc n'a pas, et dégrader proprement quand une capacité manque. Sur iOS, le parc est plus homogène, mais le principe reste le même : on conçoit pour la diversité réelle des appareils en service, pas pour le dernier modèle de la démo.

Tester sur le vrai parc, pas sur l'émulateur

Tout cela ne se valide pas en salle. Un émulateur sur une machine puissante ne dit rien de l'expérience sur un téléphone d'entrée de gamme un jour de réseau saturé. La seule vérité est le test sur de vrais appareils, représentatifs du parc des utilisateurs, dans des conditions réseau réalistes. C'est là que se révèlent les lenteurs, les fuites de mémoire et les plantages que la machine de développement masquait.

C'est cette confrontation au réel qui distingue une application qui marche d'une application qui marche pour tout le monde. Développer en natif, pour les vrais téléphones et les vrais réseaux, puis tester sur ce terrain plutôt que sur un idéal, c'est la seule façon de servir une base d'utilisateurs telle qu'elle est. Et sur une plateforme transactionnelle, l'application n'est pas la vitrine, c'est la porte d'entrée : elle doit tenir.