Le mobile n'est pas le web : fragmentation et contraintes
Le gain du jour : identifier les cinq sources de variabilité propres au mobile qui n’existent pas (ou peu) sur le web, et comprendre pourquoi elles obligent à repenser la stratégie de test.
Pourquoi le mobile est un terrain différent
Sur le web desktop, un testeur QA compose avec quelques navigateurs et des écrans qui varient peu. Sur mobile, cinq facteurs se combinent et démultiplient le nombre de contextes à couvrir.
1. La fragmentation des OS
Android et iOS coexistent, chacun avec ses propres versions supportées simultanément en production — une app peut devoir fonctionner sur des versions d’Android sorties à plusieurs années d’écart. Android ajoute une couche supplémentaire : les surcouches constructeur (Samsung One UI, Xiaomi MIUI…) modifient parfois le comportement du système au point de faire apparaître des bugs qui n’existent que sur un seul fabricant.
2. La fragmentation matérielle
Tailles d’écran, densités de pixels, présence ou non d’encoche (notch), de capteur d’empreinte, de NFC — Android en particulier couvre un très large éventail d’appareils, du bas de gamme au haut de gamme, avec des performances processeur très différentes.
3. Le réseau, variable et non fiable
Contrairement à un poste de bureau généralement câblé, un mobile passe du WiFi à la 4G/5G, perd la connexion en ascenseur ou en zone blanche, et peut la retrouver en plein milieu d’une requête. Une app doit gérer la coupure, la reprise, et parfois un mode hors-ligne complet — un scénario de test à part entière, rarement pertinent sur le web.
4. Le cycle de vie applicatif
Une app mobile est mise en arrière-plan, tuée par le système pour libérer de la mémoire, relancée par une notification, interrompue par un appel téléphonique. Ces transitions d’état (foreground → background → killed → resumed) sont une classe entière de bugs qui n’a pas d’équivalent web : une app qui perd les données d’un formulaire en cours après un appel entrant est un défaut mobile classique.
5. Les capteurs et permissions
GPS, caméra, contacts, notifications push, biométrie : chaque capteur ou permission ajoute un axe de test — l’app doit se comporter correctement quand une permission est refusée, révoquée en cours d’usage (depuis les réglages système), ou quand le capteur est physiquement indisponible (GPS coupé, caméra utilisée par une autre app).
Un scénario que beaucoup d’équipes oublient de tester : l’utilisateur autorise l’accès à la caméra, utilise la fonctionnalité, puis révoque la permission depuis les réglages système sans fermer l’app. Au retour dans l’app, l’appel à la caméra doit échouer proprement — pas planter. C’est un cas typique de test « cycle de vie + permission » qu’un scénario web n’a simplement pas.
Conséquence pratique : on ne peut pas tout couvrir, il faut une matrice
Face à ces cinq axes combinés, la réponse n’est pas de tester chaque combinaison (impossible, principe 2 vu en leçon 2) mais de construire une matrice de compatibilité priorisée : les appareils et OS réellement utilisés par la base utilisateurs (souvent visibles dans les statistiques d’usage du Play Store / App Store Connect), plus quelques cas limites représentatifs (un très vieil appareil, un très récent, un bas de gamme).
Vérifie ta compréhension
Une app plante quand l'utilisateur reçoit un appel téléphonique pendant qu'il remplit un formulaire. À quelle catégorie de bug mobile cela correspond-il ?
Pourquoi construit-on une matrice de compatibilité priorisée plutôt que de tester tous les appareils existants ?
À toi de jouer
Sur une app mobile que tu utilises, coupe le réseau en pleine utilisation (mode avion) et observe : l’app affiche-t-elle un message clair, ou plante-t-elle silencieusement ?
Révoque une permission (caméra, localisation) depuis les réglages système sans fermer l’app concernée, puis reviens dedans : que se passe-t-il ?
🗂 Fiche de référence associée : Glossaire QA mobile — antisèche.