Tester une app sur un téléphone modeste et un réseau lent

Sur le téléphone du développeur, l’application s’ouvre en une seconde. Sur celui de sa cliente, un Android d’entrée de gamme dont la mémoire déborde de photos et de vidéos WhatsApp, elle affiche encore un écran blanc quand le taxi arrive à destination. Même code, même version : deux expériences opposées.

Cet écart ne vient pas d’un bug classique. Il vient de conditions que l’équipe n’a jamais reproduites : peu de mémoire vive, un processeur modeste, un réseau qui passe de la 4G à la 2G au coin de la rue, et des données achetées en petits forfaits qu’on surveille de près.

Cet article vous apprend à recréer ces conditions depuis votre bureau avec des outils officiels et gratuits, à savoir quoi mesurer et quels seuils viser, puis à rapporter une lenteur de façon à ce que l’équipe puisse vraiment la corriger.

Pourquoi tester sur un téléphone modeste et un réseau lent

Les équipes développent souvent sur des téléphones récents, connectés à un bon Wi-Fi. Leurs utilisateurs vivent ailleurs. Google en tient compte lui-même : il existe une version allégée de son système, Android (Go edition) (nouvel onglet), conçue pour les smartphones d’entrée de gamme, et un guide entier, Build for Billions, consacré aux réseaux lents, aux appareils peu puissants, au coût des données et à l’autonomie.

Trois réalités changent tout pour un testeur :

• Le téléphone : peu de mémoire vive, un stockage presque plein, un processeur qui chauffe vite. Le système ferme les apps en arrière-plan sans prévenir.
• Le réseau : la couverture varie d’un quartier à l’autre, d’un étage à l’autre. Le signal tombe dans un ascenseur, un parking souterrain, un car entre Douala et Yaoundé.
• Le prix des données : quand on achète un petit forfait pour la semaine, une mise à jour lourde ou une vidéo qui se lance toute seule coûte de l’argent réel.

C’est l’application directe d’un des 7 principes du test logiciel : le test dépend du contexte. Une app de mobile money, de livraison ou de téléconsultation testée uniquement en Wi-Fi n’a pas été testée pour ses vrais utilisateurs.

Que mesurer : les sept indicateurs qui comptent

La performance ne se résume pas à « c’est lent ». Le tableau ci-dessous liste ce qu’un testeur peut observer sans outil de développeur, avec la question à se poser pour chaque indicateur.

Pour le démarrage, distinguez trois situations, car leurs durées n’ont rien à voir.

Pour provoquer un démarrage à froid fiable, forcez l’arrêt de l’app dans les réglages du téléphone, ou redémarrez-le, puis lancez l’app.

Quels seuils viser sans inventer de chiffres

Un seuil de performance doit venir d’une source sérieuse ou d’une décision de l’équipe, jamais d’une impression. Deux références publiques font autorité.

Pour le web : les Core Web Vitals. Google les publie sur web.dev. Une page offre une bonne expérience si ces trois mesures restent dans le vert pour au moins 75 % des visites :

• LCP (Largest Contentful Paint), le temps d’affichage du plus grand élément visible : 2,5 secondes au plus ;
• INP (Interaction to Next Paint), le délai de réaction aux appuis et aux clics : 200 millisecondes au plus ;
• CLS (Cumulative Layout Shift), la stabilité visuelle, c’est-à-dire les sauts de mise en page qui font toucher le mauvais bouton : 0,1 au plus.

Pour Android : Android vitals. Dans la Play Console, Google considère un démarrage comme excessif à partir de 5 secondes à froid, 2 secondes à tiède et 1,5 seconde à chaud. La mesure retenue est le temps d’affichage de la première image de l’interface.

Pour l’iPhone, pour les données consommées ou pour la batterie, il n’existe pas de seuil public aussi simple. Fixez donc un budget avec l’équipe avant de tester, par exemple « l’inscription complète consomme moins de X Mo » ou « l’écran d’accueil est utilisable en moins de Y secondes en 3G ». Le testeur vérifie ensuite que ce budget tient, version après version.

Comment simuler un réseau lent avec les outils officiels

Inutile de partir au village pour tester en 2G. Les trois grandes plateformes fournissent des outils de simulation gratuits.

Sur le web : les outils de développement de Chrome

1. Ouvrez la page, puis les outils de développement (touche F12, ou clic droit puis « Inspecter »).
2. Dans l’onglet Network (Réseau), ouvrez le menu de limitation du débit (throttling). Il propose des préréglages comme Fast 4G, Slow 4G et 3G, ainsi que le mode Offline (hors ligne).
3. Pour un profil sur mesure, choisissez Custom, puis Add…, et réglez le débit et la latence.
4. Cochez Disable cache pour simuler la toute première visite.
5. Dans l’onglet Performance, les paramètres de capture permettent aussi de ralentir le processeur, pour imiter un téléphone peu puissant.

La simulation ne s’applique qu’à l’onglet ouvert. Pensez à la retirer quand vous avez fini.

Sur Android : l’émulateur d’Android Studio

Dans l’émulateur, ouvrez les commandes étendues (Extended controls, le bouton « … »), puis la rubrique Cellular. Vous y choisissez le type de réseau (GSM, GPRS, EDGE, UMTS, LTE, 5G…), la force du signal, de None à Great, et l’état des données, par exemple l’itinérance. La rubrique Battery simule une batterie presque vide ou un chargeur débranché.

Sur un vrai téléphone Android, activez les options pour les développeurs en touchant sept fois le numéro de build. L’option Ne pas conserver les activités détruit chaque écran dès que vous le quittez : un excellent moyen de vérifier que l’app retrouve vos saisies, comme sur un téléphone à court de mémoire.

Sur iPhone : Network Link Conditioner

Sur un iPhone utilisé pour le développement, le menu Développeur des Réglages contient le Network Link Conditioner. Activez-le, choisissez un profil (3G, Edge, perte totale du réseau…), puis revenez dans l’app. Sur Mac, le même outil s’installe avec le paquet Additional Tools for Xcode. Xcode propose aussi des conditions d’appareil (device conditions), dans la fenêtre des appareils, pour simuler un réseau dégradé ou un téléphone qui chauffe.

Les simulateurs ont une limite : ils produisent un réseau lent, mais régulier. La vraie vie est faite de coupures, de pertes brèves et de bascules entre Wi-Fi et données mobiles. Complétez toujours par un test sur le terrain, avec le téléphone le moins cher de votre liste et une carte SIM ordinaire.

Huit scénarios concrets à dérouler

Ces scénarios révèlent les problèmes les plus fréquents. Pour chacun, notez ce que l’app fait et ce qu’elle devrait faire.

1. L’inscription en 3G avec un code SMS en retard. Le code arrive au bout de deux minutes. L’app laisse-t-elle le temps de le saisir et permet-elle d’en redemander un, sans bloquer l’utilisateur ?
2. Le paiement coupé au pire moment. Lancez un paiement mobile money, puis passez en mode avion juste après avoir touché « Confirmer ». Au retour du réseau, l’app doit afficher un statut clair (réussi, échoué ou en attente) et ne jamais débiter deux fois.
3. La bascule du Wi-Fi vers les données mobiles. Lancez l’envoi d’une photo, puis quittez la zone Wi-Fi. L’envoi reprend-il, ou faut-il tout recommencer ?
4. L’interruption. En plein formulaire de commande, recevez un appel ou ouvrez l’appareil photo pour joindre un justificatif. Au retour, vos saisies sont-elles encore là ?
5. Le stockage presque plein. Ne laissez que quelques centaines de mégaoctets libres. L’app s’installe-t-elle, se met-elle à jour, prévient-elle clairement quand la place manque ?
6. L’économie de données. Activez l’économiseur de données d’Android ou le mode données réduites de l’iPhone. Les vidéos se lancent-elles encore toutes seules ? Les synchronisations lourdes attendent-elles le Wi-Fi ?
7. Le catalogue de 200 produits en 3G. Faites défiler une longue liste illustrée. Des espaces réservés s’affichent-ils pendant le chargement ? Les images sont-elles adaptées à la taille de l’écran ?
8. L’ouverture hors ligne. Ouvrez l’app sans aucun réseau, puis après trois jours sans connexion. Voit-on les dernières données connues avec un message honnête, ou un écran blanc ?

Ces scénarios se marient très bien avec le test exploratoire : partez d’un scénario, puis suivez votre curiosité dès qu’un comportement vous paraît étrange.

Comment rapporter un problème de lenteur

« L’app est lente » ne permet à personne d’agir. Un bon rapport de performance donne le contexte complet, une mesure répétée et une preuve. Inspirez-vous du modèle ci-dessous, puis du guide du rapport de bug efficace.

Titre : écran « Mes commandes » affiché en 9 s en 3G (démarrage à froid)
Appareil : modèle, mémoire vive, version du système, stockage libre
Réseau : 3G réelle (signal faible) ou profil simulé (nom de l'outil et du profil)
Version de l'app : 2.4.1 (build 87)
Étapes : 1. Forcer l'arrêt de l'app  2. Ouvrir l'app  3. Toucher « Mes commandes »
Mesures : 8,7 s / 9,4 s / 9,1 s (médiane 9,1 s), chronométrées sur vidéo
Attendu : écran utilisable en moins de 3 s (budget fixé par l'équipe)
Pièce jointe : vidéo de l'écran avec un chronomètre visible

Une vidéo vaut mieux qu’une longue description : filmez l’écran à côté d’un chronomètre, ou utilisez l’enregistreur d’écran intégré au téléphone. Comparez si possible avec la version précédente. « Quatre secondes de plus que la 2.3 » est un argument que personne ne conteste.

Par où commencer dès aujourd’hui

Une première campagne tient en une heure. Suivez cette liste :

Si vous n’avez pas de téléphones variés sous la main, c’est précisément l’intérêt d’un panel de testeurs réels : en faisant tester votre app sur GeekTest, vous la confiez à des personnes qui utilisent leurs propres téléphones, sur leurs propres réseaux. Pour élargir ensuite à d’autres modèles et tailles d’écran, lisez le guide du test de compatibilité.

Pour aller plus loin

• Core Web Vitals, sur web.dev (nouvel onglet) : la définition des trois indicateurs du web, leurs seuils et la règle des 75 % de visites.
• Temps de démarrage de l’application dans Android vitals (nouvel onglet) : les seuils de démarrage excessif à froid, tiède et à chaud utilisés par la Play Console.
• Référence du panneau Network de Chrome DevTools (nouvel onglet) : limiter le débit, créer un profil sur mesure, passer hors ligne.
• Commandes étendues de l’émulateur Android (nouvel onglet) : type de réseau cellulaire, force du signal, batterie.
• Designing for Adverse Network and Temperature Conditions, WWDC 2019 (nouvel onglet) (en anglais) : la session d’Apple sur Network Link Conditioner et les conditions d’appareil dans Xcode.
• Build for Billions, Android Developers (nouvel onglet) : les recommandations de Google pour les réseaux lents, les appareils modestes, le coût des données et la batterie.