Appareils réels contre émulateurs : ce que vous n'attrapez que sur du matériel

Les émulateurs, c'est bien. Ils sont rapides, gratuits, scriptables, et ils ont leur place dans votre pipeline — l'essentiel de votre suite devrait y tourner. Ceci n'est pas un plaidoyer pour les remplacer.

C'est un plaidoyer sur le dernier kilomètre : la catégorie de bugs qu'un émulateur, par construction, ne peut pas vous montrer.

Ce qu'est réellement un émulateur

Un émulateur exécute l'OS sur le processeur et la carte graphique de votre machine, adossé au réseau et à la mémoire de votre machine. C'est exactement pour cela qu'il est rapide. Cela signifie aussi que chaque couche où le matériel mobile est différent a été remplacée par quelque chose de commode.

Les bugs qui vivent dans ces couches n'apparaissent donc pas.

Ce qui n'apparaît que sur du matériel

Une vraie carte graphique, et la chaleur. Votre portable a plus de puissance graphique et un meilleur refroidissement qu'un téléphone. Les à-coups au défilement, les images perdues et les animations saccadées qu'un utilisateur constate après dix minutes d'usage ne se reproduisent souvent pas sur une carte graphique de bureau qui ne bride jamais.

De vrais réseaux. Le réseau d'un émulateur, c'est le Wi-Fi de votre bureau. Pas un tunnel ferroviaire, pas une cellule saturée, pas un portail captif qui intercepte votre première requête. La logique de délai d'attente et de nouvelle tentative est précisément le code qui ne s'exerce que dans de mauvaises conditions.

Les surcouches constructeurs. L'Android de référence d'un émulateur n'est pas One UI, ni MIUI, ni une version opérateur avec ses propres demandes d'autorisation et ses règles d'optimisation de batterie. Un traitement en arrière-plan qui survit sur Android de référence se fait tuer sur un vrai téléphone à la gestion d'énergie agressive.

Les autorisations et les dialogues système. Le vrai OS interrompt. Une demande d'autorisation, un avertissement « stockage faible », une bannière de mise à jour, un appel entrant — chacun peut se poser au-dessus de votre parcours au mauvais moment. Les exécutions sur émulateur sont étrangement paisibles.

Les fonctions adossées au matériel. Biométrie, appareil photo réel, NFC, dérive GPS réelle, appairage Bluetooth, livraison des notifications par le vrai service. Autant d'éléments simulés ou absents.

Le vrai toucher. Les doigts sont imprécis et rapides. Une cible confortable au clic de souris, aux coordonnées exactes, peut être réellement difficile à atteindre sur du verre.

Le partage pratique

Une répartition raisonnable des tâches :

À exécuter sur émulateurs	À exécuter sur appareils réels
Tests unitaires et d'intégration	Tests de fumée avant livraison
L'essentiel des régressions fonctionnelles	Performance et comportement au défilement
Retour rapide sur les pull requests	Tout ce qui touche appareil photo, biométrie, notifications, GPS
Balayages larges de versions d'OS	Le bug signalé par un client que vous n'arrivez pas à reproduire

Le mode de défaillance n'est pas « nous avons utilisé des émulateurs ». C'est « tout est passé sur émulateurs, donc nous avons livré ».

Intégrer un appareil réel à la boucle

Si les équipes évitent le matériel, c'est à cause des frictions : acheter des téléphones, les garder chargés, les mettre à jour, les câbler à la CI. C'est cette partie-là qu'il vaut la peine de supprimer, plutôt que les tests eux-mêmes.

Sur RobotActions, un appareil vous est dédié — mis à disposition à la demande, et non prélevé dans un parc partagé : l'état persiste donc entre les exécutions et il n'y a pas de file d'attente. Pointez votre suite Appium, Selenium ou Playwright existante vers la grille et gardez chaque test que vous avez écrit ; rien n'a besoin d'être réécrit pour commencer à exécuter le dernier kilomètre sur du matériel.

Exécutez votre suite sur un appareil réel →