Expo Go est une application gratuite, disponible sur l'App Store et Google Play, qui exécute votre projet Expo sur un vrai téléphone sans rien compiler. Vous lancez le projet sur votre ordinateur, vous scannez un QR code, et l'écran que vous étiez en train de modifier apparaît sur votre iPhone ou votre appareil Android quelques secondes plus tard. Vous enregistrez un fichier, le téléphone se met à jour. Pour une première version d'app, c'est le chemin le plus court entre le code et un vrai écran tactile.
C'est aussi l'outil que les débutants comprennent le moins bien. Expo Go n'est pas votre application, et ce n'est jamais le binaire que vous publierez : c'est un conteneur qui embarque déjà la partie native du SDK Expo et ne charge que votre JavaScript. Ce seul fait explique ce qu'il peut tester, ce qu'il ne peut pas, les erreurs de version que vous rencontrerez, et pourquoi Expo a ajouté une règle de connexion au compte en 2026. Ce guide couvre tout cela, avec le parcours pour les deux plateformes.
Si Expo lui-même est nouveau pour vous, commencez par notre présentation Expo, c'est quoi ; cet article suppose que vous avez un projet et que vous voulez le voir sur un téléphone.
Ce que fait vraiment Expo Go
Une app Expo a deux moitiés. La moitié native est du code compilé : le runtime React Native, les modules du SDK Expo pour la caméra, la géolocalisation, les notifications ou les fichiers, et toute bibliothèque native que vous ajoutez. La moitié JavaScript, ce sont vos écrans et votre logique, empaquetés par le serveur de développement Metro. Compiler la moitié native prend des minutes sur un Mac ou un service de build cloud ; empaqueter la moitié JavaScript prend des secondes.
Expo Go livre la moitié native déjà compilée, une fois pour tout le monde : un ensemble fixe de modules du SDK Expo réunis dans une seule application qu'Expo publie sur les stores. Quand vous scannez le QR code, Expo Go demande un manifeste à Metro, télécharge votre bundle JavaScript par le réseau local et l'exécute dans sa propre coquille native. Rien n'est compilé de votre côté. C'est ce qui le rend si rapide, et c'est pour cela qu'il ne fonctionne que si votre projet utilise la même version de SDK que le build d'Expo Go installé sur le téléphone.
Tester sur iPhone et Android, étape par étape
Le parcours est le même sur les deux plateformes, avec une différence en 2026 : sur iPhone, Expo Go vérifie désormais que vous êtes connecté avec le même compte Expo que la ligne de commande qui a lancé le projet.
1. Installer Expo Go et se connecter
Sur iPhone, installez Expo Go depuis l'App Store. La version pour le SDK 57 est revenue sur le store en septembre 2026 après plusieurs mois dans la file de validation d'Apple, pendant lesquels il fallait l'installer comme build TestFlight personnel. Sur Android, installez-la depuis Google Play, ou depuis expo.dev/go s'il vous faut une version de SDK plus ancienne, que le store ne propose plus.
Créez ensuite un compte Expo gratuit sur expo.dev si vous n'en avez pas, et connectez-vous deux fois : dans Expo Go sur le téléphone, et dans la CLI Expo sur votre ordinateur avec la commande expo login. Depuis le 3 septembre 2026, Expo exige le même compte des deux côtés pour ouvrir un projet en SDK 57 dans Expo Go sur un iPhone physique. Les simulateurs sont exemptés, les development builds aussi, et Android recevra la même règle plus tard. Si les comptes diffèrent, le projet refuse simplement de s'ouvrir.
2. Lancer le projet et scanner le QR code
Dans le dossier du projet, lancez npx expo start. Metro démarre, affiche un QR code dans le terminal et une adresse de la forme exp://192.168.x.x:8081. Sur iPhone, ouvrez l'application Appareil photo, visez le QR code et touchez la bannière : elle ouvre directement Expo Go. Sur Android, ouvrez Expo Go et utilisez son bouton « Scan QR code ». Si le téléphone et l'ordinateur se voient, le bundle se télécharge et votre premier écran apparaît.
À partir de là, chaque enregistrement déclenche le Fast Refresh : le composant modifié se recharge sur place, en conservant l'état de l'app quand c'est possible. Secouez le téléphone pour ouvrir le menu développeur, qui permet de recharger manuellement, d'ouvrir l'inspecteur d'éléments ou d'activer le moniteur de performance.
3. Même réseau, tunnel, et les erreurs habituelles
Le téléphone charge le bundle depuis votre ordinateur, donc les deux doivent être sur le même réseau Wi-Fi, et ce réseau doit autoriser les appareils à se parler. Les réseaux d'entreprise et d'hôtel le bloquent souvent. La solution est un tunnel : npx expo start --tunnel fait passer la connexion par une URL ngrok qui fonctionne depuis n'importe quel réseau, au prix d'un premier chargement plus lent. La plupart des autres problèmes tiennent en quelques messages :
| Ce que vous voyez | Ce que ça veut dire | Quoi faire |
|---|---|---|
| Project is incompatible with this version of Expo Go | Le SDK de votre projet et l'Expo Go installé ne correspondent pas | Mettez le projet à jour avec npx expo install expo@latest, ou installez le build d'Expo Go de votre SDK depuis expo.dev/go |
| Le projet ne s'ouvre pas, ou demande de se connecter | iPhone seulement : la CLI et Expo Go ne sont pas connectés au même compte | Lancez npx expo whoami, connectez-vous avec expo login, et vérifiez le nom du compte dans l'onglet profil d'Expo Go |
| Something went wrong : could not connect to the server | Le téléphone n'atteint pas votre ordinateur par le réseau | Même Wi-Fi pour les deux, port 8081 autorisé dans le pare-feu, ou relance avec --tunnel |
| Native module cannot be null, ou écran rouge au lancement | Le projet utilise du code natif qui ne fait pas partie du SDK Expo | Expo Go ne peut pas l'exécuter : passez à un development build pour ce projet |
| L'app s'ouvre mais une fonctionnalité ne fait rien | Une capacité qu'Expo Go ne prend pas en charge, comme les notifications push distantes | Testez cette fonctionnalité dans un development build ou dans TestFlight |
Ce qu'Expo Go ne peut pas tester, et quoi utiliser à la place
Parce que la moitié native est figée, Expo Go s'arrête exactement là où votre projet a besoin de code natif absent du SDK Expo : une bibliothèque native tierce, un config plugin qui modifie le projet iOS ou Android, un module Swift ou Kotlin maison. Il ne peut pas non plus vous montrer ce qui n'existe que dans votre propre binaire : votre icône et votre écran de démarrage, votre bundle identifier, vos deep links, vos achats intégrés. Depuis le SDK 53, Expo a aussi retiré les notifications push distantes d'Expo Go et renvoie vers les development builds pour les tester.
Le remplaçant est un development build : votre propre application, compilée une fois avec les outils de développement à l'intérieur, que vous installez sur le téléphone et que vous rechargez ensuite en direct exactement comme avec Expo Go. Il contient vos modules natifs, votre icône et vos identifiants, et il n'a pas besoin d'un compte Expo pour ouvrir un projet. La vérification finale avant soumission est encore un autre outil : TestFlight sur iOS et le canal de test interne sur Google Play installent le vrai binaire de production.
| Vous voulez vérifier | Expo Go | Development build | TestFlight / test interne Play |
|---|---|---|---|
| Écrans, navigation, mise en page sur un vrai écran | Oui | Oui | Oui |
| Caméra, géolocalisation, capteurs, sélecteur d'images (modules expo-*) | Oui | Oui | Oui |
| Bibliothèque native tierce ou module natif maison | Non | Oui | Oui |
| Notifications push distantes | Non | Oui | Oui |
| Icône, écran de démarrage, deep links, achats intégrés | Non | Oui | Oui |
| Le binaire exact que les utilisateurs installeront | Non | Non | Oui |
| Coût de mise en place | Aucun | Un build (EAS ou local), puis rechargement en direct | Un build de production et un compte store |
Expo Go dans Cadrant
Les projets mobiles natifs sur Cadrant sont des apps Expo et React Native, donc les mêmes règles s'appliquent. L'éditeur prévisualise l'app dans un cadre de téléphone, et un QR code ouvre le projet en direct dans Expo Go sur votre propre appareil. À cause de la règle de connexion 2026, le QR code apparaît une fois votre compte Expo connecté : créez un compte gratuit sur expo.dev, générez un jeton d'accès personnel, collez-le dans Réglages, Intégrations, Expo, puis connectez-vous à Expo Go sur le téléphone avec ce même compte. Cadrant lance le serveur de développement avec votre jeton, et la vérification du compte passe.
La plupart des API expo-* y tournent directement, ce qui couvre les tests du quotidien : caméra, géolocalisation, capteurs, sélecteur d'images, notifications locales. Pour du code natif hors SDK, et pour la vérification finale, publiez un vrai build : le binaire iOS est compilé sur votre compte Expo et déposé sur votre App Store Connect, où TestFlight l'installe sur vos appareils ; sur Android, le build arrive dans le canal de test interne de votre Play Console. La documentation des applications mobiles natives détaille les deux parcours.
En résumé
- Expo Go est un conteneur précompilé du SDK Expo : il charge votre JavaScript, jamais votre code natif, et il doit correspondre à la version de SDK de votre projet.
- Sur iPhone depuis septembre 2026, connectez-vous avec le même compte Expo dans la CLI et dans Expo Go, sinon le projet ne s'ouvre pas ; simulateurs et development builds sont exemptés.
- Même Wi-Fi ou tunnel, puis scan : l'Appareil photo sur iPhone, le scanner intégré sur Android.
- Modules natifs maison, notifications push distantes, icônes, deep links et achats demandent un development build ; le binaire exact demande TestFlight ou le canal interne de Play.
Utilisez Expo Go pour ce qu'il fait le mieux, voir un écran sur un vrai téléphone trente secondes après l'avoir écrit, et passez au development build le jour où votre projet a besoin de quelque chose que le conteneur n'a pas. Le changement est un build unique, pas une réécriture.