L'émulateur ne reproduit pas ce qui casse
Une application validée en émulateur échoue sur un appareil réel pour des raisons qu'aucun émulateur ne simule : le réseau, la mémoire, le système du constructeur.
L’émulateur affiche l’écran correctement, les parcours passent, la livraison est validée. Les premiers retours d’utilisateurs décrivent des comportements qu’aucun développeur ne reproduit.
L’émulateur teste le code. Il ne teste pas les conditions.
Ce qu’il ne reproduit pas
Le réseau réel. L’émulateur tourne sur la connexion du poste de développement. Il ne reproduit ni la latence mobile, ni les coupures d’ascenseur, ni le passage du Wi-Fi aux données cellulaires en cours de requête. Ce dernier cas révèle la majorité des bugs de synchronisation.
La pression mémoire. Sur un appareil chargé, le système suspend puis tue les applications en arrière-plan. Une application qui ne sait pas restaurer son état revient à l’écran d’accueil et perd la saisie en cours. En émulateur, elle n’est jamais tuée.
Les surcouches constructeur. Gestion agressive de la batterie, restrictions d’arrière-plan propres à certaines marques, permissions supplémentaires. Une tâche de fond parfaitement fonctionnelle en émulateur peut ne jamais s’exécuter sur certains appareils.
Les réglages système. Une taille de police système augmentée, un thème sombre, un mode d’économie de données, une langue régionale. Chacun modifie l’affichage ou le comportement.
Un parc minimal
Trois appareils couvrent l’essentiel :
- un modèle d’entrée de gamme de trois ou quatre ans, sur la plateforme majoritaire de vos utilisateurs — c’est celui qui révèle les problèmes ;
- un modèle récent de l’autre plateforme ;
- une tablette, si le produit la cible.
Le premier est le plus important et le plus souvent absent des équipes, qui travaillent sur du matériel récent.
Les tests à faire sur ces appareils
Couper le réseau au milieu d’un envoi. Basculer du Wi-Fi aux données pendant une synchronisation. Mettre l’application en arrière-plan cinq minutes, puis revenir. Refuser une permission, puis l’accorder plus tard depuis les réglages.
Augmenter la taille de police système au maximum et vérifier qu’aucun texte n’est tronqué ni aucun bouton inatteignable. Ce test-là révèle beaucoup, en trente secondes.
Ce que les journaux ne diront pas
Un plantage en production remonte avec une trace. Une lenteur, une animation saccadée, un formulaire pénible au pouce ne remontent jamais.
Une demi-heure d’usage réel, debout, en marchant, sur un réseau moyen, apprend davantage que la lecture des rapports d’incident.