đŸ§Ș 3.6 Simulation, tests et exĂ©cution de l'application mobile

Jusqu'ici, vous avez principalement exécuté votre application Ionic dans un navigateur web. C'est rapide et confortable, mais ce n'est pas suffisant pour une vraie application mobile.

Une application mobile doit ĂȘtre testĂ©e :

  • dans diffĂ©rents environnements,
  • avec de vraies contraintes matĂ©rielles,
  • avec de vraies API natives.

Ce chapitre vous apprend oĂč, comment, et quand exĂ©cuter votre application Ionic pour garantir un comportement fiable sur mobile.

🎯 Objectifs d'apprentissage

À la fin de ce chapitre, vous serez capables de :

  • distinguer les diffĂ©rents modes d'exĂ©cution dans une application Ionic ;
  • exĂ©cuter une application sur un navigateur, Ă©mulateur et appareil rĂ©el ;
  • comprendre les diffĂ©rences de comportement entre ces environnements ;
  • utiliser les outils de debug mobile ;
  • tester correctement les APIs natives Capacitor ;
  • identifier et corriger les erreurs mobiles les plus courantes.

⚙ 3.6.1 Modes d'exĂ©cution

Une application Ionic peut ĂȘtre exĂ©cutĂ©e de plusieurs maniĂšres :

  1. Dans le navigateur (mode web)
  2. Dans un émulateur (mobile simulé)
  3. Sur un appareil réel (smartphone)

Note : il existe beaucoup de plateformes d'émulation (Android, iOS, différents modÚles de téléphones). Cependant, pour des raisons de coût et de complexité, nous nous concentrerons ici sur les méthodes d'émulation "natives" aux plateformes Android et iOS.

Chaque mode a un rÎle précis dans le cycle de développement et de test.

⚠ Attention : Web ≠ Mobile

Une erreur fréquente :

Croire qu'une app qui fonctionne dans le navigateur fonctionnera forcément sur mobile.

Ce n'est pas le cas :

  • APIs natives manquantes ou simulĂ©es
  • diffĂ©rences de performance
  • diffĂ©rences de comportements UI / UX

🌐 3.6.2 ExĂ©cuter l'application dans le navigateur

Commande principale :

ionic serve

Elle permet de lancer l'application dans le navigateur avec :

  • rechargement automatique (hot reload) Ă  chaque modification ;
  • accĂšs direct aux DevTools du navigateur ;
  • cycle de dĂ©veloppement trĂšs rapide.

✅ Avantages du mode navigateur

  • idĂ©al pour travailler l’interface utilisateur ;
  • parfait pour tester la navigation et la logique mĂ©tier ;
  • trĂšs rapide Ă  relancer ;
  • aucun besoin d’émulateur ou de tĂ©lĂ©phone.

👉 À utiliser principalement pour : UI, navigation, logique applicative.

⚠ Limites du mode navigateur

  • les APIs natives (camĂ©ra, fichiers, haptics...) ne sont pas rĂ©elles :

    • simulĂ©es
    • ou indisponibles

  • le comportement peut diffĂ©rer fortement d’un vrai tĂ©lĂ©phone ;

  • certaines fonctionnalitĂ©s Capacitor sont simulĂ©es ou absentes.

Conclusion :

Le navigateur est un outil de développement, pas un environnement de test final.

đŸ› ïž DevTools : fonctionnalitĂ©s avancĂ©es

Les DevTools du navigateur permettent de simuler un environnement mobile :

  • Mode appareil : taille d’écran + comportement tactile ;

  • Simulation de la gĂ©olocalisation ;

  • Simulation du rĂ©seau :

    • 4G, 3G, offline


  • Console JavaScript :

    • logs, erreurs, warnings ;

  • Simulation de capteurs (accĂ©lĂ©romĂštre, gyroscope) via outils/extensions.

Pour y accéder :

  • Ouvrir les DevTools (F12 ou clic droit → Inspecter)

  • Menu → More tools → Sensors :

    • gĂ©olocalisation, rĂ©seau, orientation, etc.

đŸ€– 3.6.3 Émulation Android

Un émulateur est un téléphone virtuel exécuté sur votre ordinateur.

Pré-requis

  • Android Studio installĂ©
  • Android SDK configurĂ©
  • CrĂ©ation d’un AVD (Android Virtual Device)
  • Package Android installĂ© dans Capacitor :
npm install @capacitor/android
npx cap add android

Lien Ionic ↔ Android (Capacitor)

Avant de lancer l’app sur Android :

ionic build
ionic cap sync android
ionic cap open android
  • ionic build : gĂ©nĂšre la version web dans www/
  • ionic cap sync android : copie le build dans le projet Android
  • ionic cap open android : ouvre Android Studio

Ensuite, dans Android Studio :

  • choisir un Ă©mulateur ;
  • lancer l’application.

Pourquoi utiliser un Ă©mulateur ?

  • tester diffĂ©rents modĂšles de tĂ©lĂ©phones sans les possĂ©der ;

  • simuler :

    • conditions rĂ©seau
    • localisation
    • rotation, capteurs


  • dĂ©boguer avec les outils Android Studio (Logcat, Profiler, etc.).

C’est une Ă©tape intermĂ©diaire utile entre :

  • le navigateur
  • et les appareils rĂ©els.

🍎 3.6.4 Émulation iOS

💡 L’émulation iOS nĂ©cessite un Mac avec Xcode installĂ©.

Pré-requis

  • Mac + Xcode installĂ©
  • Package iOS dans Capacitor :
npm install @capacitor/ios
npx cap add ios

Lien Ionic ↔ iOS (Capacitor)

Avant de lancer l’app sur iOS :

ionic build
ionic cap sync ios
ionic cap open ios
  • ionic build : gĂ©nĂšre la version web dans www/
  • ionic cap sync ios : copie le build dans le projet iOS
  • ionic cap open ios : ouvre Xcode

Ensuite, dans Xcode :

  • choisir un simulateur iPhone ;
  • lancer l’application.

đŸ“± 3.6.5 ExĂ©cution sur un appareil rĂ©el

Tester sur un vrai smartphone est indispensable avant la publication.

Permet de vérifier :

  • les performances rĂ©elles

  • les vrais capteurs :

    • camĂ©ra
    • vibrations
    • GPS

  • le comportement rĂ©seau :

    • 4G
    • Wi-Fi
    • coupures

Pré-requis Android (appareil réel)

  • activer les options dĂ©veloppeur sur le tĂ©lĂ©phone ;
  • activer le dĂ©bogage USB ;
  • connecter le tĂ©lĂ©phone en USB Ă  l’ordinateur ;
  • lancer depuis Android Studio ou via CLI (selon config).

Android Studio dĂ©tecte l’appareil et permet de :

  • installer l’app ;
  • la lancer ;
  • lire les logs en temps rĂ©el (Logcat).

Pré-requis iOS (appareil réel)

  • Mac avec Xcode ;
  • compte dĂ©veloppeur Apple (gratuit ou payant selon besoins) ;
  • activer les options dĂ©veloppeur sur l’iPhone ;
  • connecter l’iPhone en USB ;
  • ouvrir le projet dans Xcode ;
  • sĂ©lectionner l’iPhone comme cible.

Puis :

  • lancer l’application ;
  • inspecter les logs depuis Xcode.

Pourquoi c’est crucial ?

Certaines erreurs n’apparaissent que :

  • sur un vrai appareil ;
  • avec de vraies contraintes matĂ©rielles ;

Par exemple :

  • performances lentes ;
  • comportements UI diffĂ©rents ;
  • accĂšs camĂ©ra / fichiers / haptics ;
  • bugs rĂ©seau liĂ©s Ă  la 4G / Wi-Fi.

Tester uniquement sur navigateur ou Ă©mulateur n’est jamais suffisant.

🐞 3.6.6 Debug et inspection

Chaque environnement a ses outils de debug.

Navigateur (Chrome, Edge, Firefox)

  • DevTools :

    • console
    • rĂ©seau
    • stockage
    • performance
    • vue mobile

Idéal pour :

  • erreurs JavaScript ;
  • problĂšmes d’UI ;
  • requĂȘtes API (HTTP).

Debug Android

Utiliser Android Studio pour :

  • logs via Logcat ;
  • inspecteur de layout (UI) ;
  • profiler (CPU, mĂ©moire, rĂ©seau) ;
  • gestion des crashs.

Chrome Remote Debugging (Android)

  1. Ouvrir Chrome sur le PC : chrome://inspect/#devices
  2. Lancer l’app sur Ă©mulateur ou appareil Android
  3. Chrome affiche l’app : cliquer sur Inspect

Vous obtenez :

  • console
  • rĂ©seau
  • sources
  • performance


 comme si c’était un onglet du navigateur.

🔍 3.6.7 Tester les APIs natives

Toutes les APIs natives ne se testent pas de la mĂȘme façon.

📾 CamĂ©ra

  • navigateur : simulation ou indisponible ;
  • Ă©mulateur : camĂ©ra virtuelle ;
  • appareil rĂ©el : camĂ©ra physique.

🌐 RĂ©seau

  • tester le mode offline / online ;
  • observer la gestion des erreurs rĂ©seau ;
  • vĂ©rifier le comportement de la synchro (Supabase / API).

Autres APIs natives

📁 Filesystem

  • navigateur : stockage limitĂ© / sandbox diffĂ©rent ;
  • mobile : vrai systĂšme de fichiers sandboxĂ© par l’OS.

📳 Haptics (vibrations)

  • navigateur : aucun effet ;
  • Ă©mulateur : souvent absent ;
  • appareil rĂ©el : feedback haptique rĂ©el.

👉 Conclusion : Les APIs natives doivent toujours ĂȘtre validĂ©es sur un vrai appareil.

⚠ 3.6.8 Erreurs courantes

Erreurs fréquentes :

  • oublier ionic cap sync aprĂšs modification (plugins, config
) ;
  • tester une API native uniquement dans le navigateur ;
  • oublier de dĂ©clarer une permission Android ou clĂ© iOS ;
  • app OK en web, mais qui plante en mobile ;
  • confondre problĂšme Ionic et problĂšme Capacitor.

En cas de doute


Tester sur appareil réel dÚs que possible.

  • Reproduire l’erreur sur mobile ;
  • vĂ©rifier les logs (Logcat, Xcode) ;
  • comparer le comportement avec le navigateur.

🏁 3.6.9 Bonnes pratiques de test mobile

  • tester sur mobile le plus tĂŽt possible ;

  • ne pas attendre la fin du projet ;

  • valider rĂ©guliĂšrement les fonctionnalitĂ©s critiques :

    • auth
    • synchro
    • camĂ©ra
    • stockage

  • considĂ©rer le navigateur comme un outil de dev, pas comme validation finale ;

  • varier les environnements :

    • navigateur
    • Ă©mulateur
    • 1–2 appareils rĂ©els si possible.

đŸ§Ș 3.6.10 ActivitĂ© pratique

Comparer les environnements

🎯 Objectif : observer les diffĂ©rences concrĂštes.

À rĂ©aliser :

  1. Lancer l’application dans le navigateur

  2. Lancer la mĂȘme application dans un Ă©mulateur Android

  3. Si possible : la lancer sur un appareil réel

  4. Tester dans chaque environnement :

    • navigation
    • performances perçues
    • APIs natives (au moins Network / Preferences, voire Camera)

Notez :

  • les comportements diffĂ©rents ;
  • les erreurs spĂ©cifiques ;
  • les limitations de chaque environnement.

🔗 3.6.11 Ressources et documentation