React Native avec Expo et EAS — premier projet de bout en bout

Ce tutoriel monte un projet React Native avec Expo SDK 55 (qui embarque React Native 0.83) de zéro, l’exécute sur un téléphone via Expo Go, le configure pour les modules natifs avec prebuild, déclenche un premier build cloud sur EAS Build, et distribue le binaire à des testeurs internes via un simple lien. Chaque commande est testée pas-à-pas avec sa sortie attendue, et chaque concept central — Expo SDK, Expo Router, EAS, prebuild — est expliqué au moment où il devient utile, pas avant. À la fin, vous avez une app React Native déployée chez vos testeurs sans avoir touché à Xcode ni à Android Studio.

📍 Guide principal de la série : Développement mobile 2026 : Flutter 3, React Native, Expo, stores

Pour le panorama complet, lire d’abord ce guide.

Prérequis

L’expérience Expo est conçue pour minimiser les prérequis locaux. Vous n’avez besoin ni de Xcode, ni d’Android Studio pour parcourir ce tutoriel jusqu’à la distribution interne — c’est l’intérêt principal de cette stack en 2026.

• Système : Windows 10 / 11, macOS 13+ ou Linux récent (Ubuntu 22.04+)
• Node.js 20 LTS ou 22 LTS, installé depuis nodejs.org ou via nvm / fnm
• Un téléphone Android ou iOS pour exécuter Expo Go (l’app de prévisualisation officielle)
• Un compte Expo gratuit (créé en deux minutes sur expo.dev)
• Espace disque : 2 Go libres pour le projet et ses dépendances Node
• Pour les builds EAS : connexion stable, le build se passe dans le cloud mais le code source est uploadé

Niveau attendu : développeur qui connaît React, JavaScript ES modernes, et l’utilisation d’un terminal. Aucune expérience préalable en mobile n’est nécessaire. Temps total : trente à quarante-cinq minutes pour atteindre le premier build distribué.

Étape 1 — Créer le projet avec create-expo-app

Expo CLI a unifié l’expérience de création en une seule commande qui génère un projet TypeScript prêt à l’emploi, avec navigation, gestion des assets, configuration de build et scripts npm pré-câblés. Comparez avec npx react-native init classique qui produit un projet beaucoup plus minimal et beaucoup plus exposé aux subtilités natives.

npx create-expo-app@latest my-first-rn-app
cd my-first-rn-app

La commande télécharge la dernière version d’Expo CLI, l’exécute en mode npx sans rien installer globalement, et crée un dossier my-first-rn-app/. La sortie liste les fichiers générés : app/ avec les écrans, assets/ pour les images, app.json pour la configuration Expo, package.json pour les dépendances Node, tsconfig.json pour TypeScript. Comptez deux à trois minutes le temps que npm install télécharge les 800+ dépendances de l’écosystème Expo / React Native.

Une fois la création terminée, vous avez sous les yeux un projet fonctionnel avec deux écrans pré-câblés via Expo Router. Le routeur de fichiers transforme chaque fichier dans app/ en une route navigable — c’est un calque inspiré de Next.js, qui remplace l’ancien React Navigation explicite par un modèle déclaratif beaucoup plus simple à maintenir.

Étape 2 — Installer Expo Go sur votre téléphone

Expo Go est l’app officielle qui sert de coquille pour exécuter votre code sans build natif. Vous publiez votre code sur un serveur de développement local, Expo Go le télécharge à la volée et l’exécute. C’est ce qui permet de voir votre app tourner sur un téléphone réel en moins d’une minute après avoir tapé create-expo-app.

Sur Android, ouvrez le Play Store et installez « Expo Go » (publié par Expo). Sur iPhone, ouvrez l’App Store et faites de même — l’app est gratuite. Une fois installée, ne lancez pas encore — vous l’ouvrirez à l’étape suivante en scannant un QR code.

Notez qu’Expo Go a une limitation importante : il ne contient que les modules natifs du SDK Expo officiel. Si votre app ajoute un module natif tiers (un SDK de paiement par exemple), Expo Go ne saura pas le faire tourner et vous devrez basculer en development build custom — le sujet est traité plus loin avec EAS.

Étape 3 — Démarrer le serveur de développement

Le serveur de développement est ce qui transforme votre code TypeScript en JavaScript exécutable, le sert à Expo Go via WiFi, et orchestre le hot reload. Une seule commande lance toute cette machinerie.

npx expo start

La sortie affiche un QR code dans le terminal et démarre un serveur sur http://localhost:8081. Sur Android, ouvrez Expo Go, tapez « Scan QR code » et pointez l’appareil photo sur le terminal. Sur iPhone, ouvrez l’app Camera native — pas Expo Go — pointez sur le QR code, et Apple propose un lien qui ouvre Expo Go. L’app charge le bundle JavaScript depuis votre ordinateur et l’exécute. En dix secondes, votre app tourne sur votre téléphone.

Si rien ne se passe, deux causes possibles. Premièrement, votre téléphone et votre ordinateur ne sont pas sur le même réseau WiFi — c’est le cas le plus fréquent. Vérifiez que les deux sont connectés au même routeur. Deuxièmement, votre pare-feu bloque le port 8081 : sur Windows, autorisez Node dans le pare-feu Windows Defender ; sur macOS, accordez les permissions réseau à votre terminal. Si le QR code refuse toujours, lancez npx expo start --tunnel qui passe par les serveurs Expo via un proxy ngrok et contourne tout problème réseau, au prix d’une latence accrue.

Étape 4 — Modifier l’écran d’accueil avec Fast Refresh

Le Fast Refresh est l’équivalent React Native du hot reload Flutter. À chaque sauvegarde, votre code est recompilé et appliqué à l’app sans redémarrage complet. L’état des composants est préservé, ce qui change radicalement la productivité quotidienne par rapport à un cycle build/run/test.

Ouvrez app/index.tsx dans VS Code. Vous voyez un composant React standard, avec un <Text> qui affiche « Welcome to Expo ». Remplacez ce texte par « Mon premier projet React Native », sauvegardez, et regardez votre téléphone. En moins d’une seconde, le texte se met à jour. Pas de redémarrage, pas de chargement, juste le nouveau texte.

import { Text, View } from 'react-native';

export default function Index() {
  return (
    <View style={{ flex: 1, alignItems: 'center', justifyContent: 'center' }}>
      <Text>Mon premier projet React Native</Text>
    </View>
  );
}

Le composant <View> est l’équivalent du <div> en React web — un conteneur. Le composant <Text> est obligatoire pour tout texte, contrairement à React web où le texte se balade librement. Cette règle simple est ce qui surprend le plus les développeurs venant du web ; mémorisez-la et vous éviterez 90 % des messages d’erreur « Text strings must be rendered within a Text component ».

Étape 5 — Ajouter un module natif via le SDK Expo

Le SDK Expo fournit une cinquantaine de modules natifs prêts à l’emploi : caméra, géolocalisation, notifications, capteurs, contacts, accéléromètre. Ajouter un module est aussi simple que d’installer un package npm. Pour cet exemple, ajoutons l’accès à la caméra du téléphone.

npx expo install expo-camera

La commande utilise expo install et non npm install : Expo CLI sélectionne automatiquement la version du package compatible avec votre version de SDK. C’est un détail crucial — installer une version trop récente d’expo-camera peut casser le build, et Expo CLI évite ce piège en lisant la matrice de compatibilité officielle.

Une fois installé, le module est immédiatement utilisable depuis votre code. Importez-le, demandez la permission caméra, et affichez l’aperçu vidéo. La documentation officielle d’Expo donne le code complet ; copiez-le dans app/index.tsx, sauvegardez, et le Fast Refresh applique le changement. La première fois que l’app demande la permission caméra, votre téléphone affiche une popup système — c’est exactement le même comportement qu’une app native.

Étape 6 — Comprendre Expo Router et naviguer entre écrans

Expo Router transforme la structure de fichiers en arbre de navigation. Un fichier app/profile.tsx devient automatiquement la route /profile. Un dossier app/(tabs)/ avec un fichier _layout.tsx devient une navigation par onglets. Cette approche déclarative supprime l’essentiel du code boilerplate de l’ancien React Navigation explicite.

Créez un nouveau fichier app/about.tsx avec un composant minimal qui affiche « À propos ». Sauvegardez. Maintenant, dans app/index.tsx, ajoutez un lien vers cette nouvelle route avec le composant <Link> de expo-router.

import { Link } from 'expo-router';

// Dans votre composant
<Link href="/about">Aller à À propos</Link>

Tapotez sur le lien dans Expo Go : l’app navigue vers la nouvelle route, avec une animation de transition iOS native sur iPhone et une animation Material sur Android. Vous n’avez ni configuré de stack navigator, ni déclaré de routes, ni géré de paramètres — Expo Router a tout fait à partir de la structure de fichiers.

Étape 7 — Préparer le build cloud avec eas init

Expo Go est génial pour le développement, mais il a deux limites : il ne supporte que les modules du SDK Expo officiel, et il ne produit pas de binaire qu’on peut publier sur les stores. Pour aller plus loin, on bascule sur EAS Build — le service de compilation cloud d’Expo qui produit des APK Android et des IPA iOS signés et prêts pour la distribution.

Commencez par installer EAS CLI globalement et vous connecter à votre compte Expo.

npm install -g eas-cli
eas login

La commande eas login demande votre email et votre mot de passe Expo, créés à l’étape 0. Une fois connecté, initialisez EAS dans votre projet.

eas init

EAS crée un fichier eas.json à la racine de votre projet, avec trois profils de build par défaut : development (pour les builds de développement avec rechargement à chaud), preview (pour les bêtas internes distribuées par lien), et production (pour la soumission aux stores). Ouvrez eas.json et inspectez le contenu : c’est le fichier de configuration que vous éditerez à mesure que votre pipeline mûrit.

Étape 8 — Lancer le premier build EAS

Avec EAS initialisé, déclencher un build cloud se résume à une commande. Choisissez le profil preview qui produit un APK installable directement, sans passer par le store.

eas build --platform android --profile preview

EAS pose deux ou trois questions à la première exécution : un identifiant d’application Android (com.votreentreprise.myfirstrnapp), la création automatique du keystore Android par Expo, et la confirmation. Acceptez la création automatique : EAS génère et stocke votre keystore en sécurité. Vous pouvez le récupérer plus tard pour archive avec eas credentials.

Le build démarre. EAS upload votre code source vers ses serveurs, lance une VM avec l’environnement Android complet, exécute Gradle en mode release, signe l’APK avec votre keystore, et publie le résultat. Comptez dix à vingt minutes pour le premier build, sept à dix pour les suivants grâce au cache.

Pendant ce temps, EAS affiche dans votre terminal un lien vers la page web de suivi du build. Ouvrez-le dans votre navigateur : vous voyez la progression en temps réel, les logs Gradle, et finalement le bouton « Install » qui apparaît à la fin. Sur la page, un QR code permet à n’importe quel testeur d’installer l’APK directement sur son téléphone Android sans passer par Google Play.

Étape 9 — Distribuer aux testeurs internes

Le build preview est un APK de production complet, signé, fonctionnel hors connexion au serveur de développement. Vous pouvez le distribuer comme bon vous semble : par lien direct, par email, par Slack, par TestFairy, par Firebase App Distribution. Le canal le plus simple en 2026 reste le QR code généré par EAS lui-même.

Récupérez l’URL d’installation depuis la page de build EAS. Partagez-la à vos testeurs. Sur leur téléphone Android, ils ouvrent le lien dans Chrome, autorisent Chrome à installer des apps inconnues — c’est la procédure standard d’installation hors-store —, et l’APK s’installe en moins d’une minute. Au premier lancement, l’app demande les permissions configurées (caméra dans notre exemple), puis fonctionne normalement.

Pour iOS, la procédure est différente. Apple n’autorise pas l’installation libre d’IPA en dehors de TestFlight ou de l’App Store. Le profil preview sur iOS produit un IPA ad hoc qui ne fonctionne que sur les téléphones dont l’UDID est enregistré dans votre compte Apple Developer. Pour distribuer largement à des testeurs externes, il faut passer par TestFlight via EAS Submit ou fastlane — ces sujets sont traités dans le tutoriel sur le déploiement aux stores.

Étape 10 — Préparer le build de production

Le build preview est un brouillon de distribution. Pour publier sur Google Play, il faut un AAB (Android App Bundle) au lieu d’un APK, et un nombre cohérent de versionCode. Editez votre app.json pour ajouter la version, puis modifiez eas.json pour que le profil production produise un AAB.

{
  "build": {
    "production": {
      "android": {
        "buildType": "app-bundle"
      }
    }
  }
}

Avec ce fichier en place, lancez le build production. Cette fois la commande cible le profil correspondant.

eas build --platform android --profile production

Le résultat est un AAB stocké chez EAS, téléchargeable depuis la page de build. Ce fichier est exactement celui que vous uploaderez sur la Google Play Console pour la première soumission. Le tutoriel suivant explique la procédure complète de soumission, depuis la création de l’app sur la Play Console jusqu’à l’automatisation avec fastlane.

Erreurs fréquentes

Tutoriels associés

• Flutter 3 — créer une app cross-platform et générer l’APK release
• CI/CD pour applications mobile — GitHub Actions et Codemagic
• Déployer une app sur Play Store et App Store avec fastlane

Pour aller plus loin

• 🔝 Retour au guide principal : Développement mobile 2026 : Flutter 3, React Native, Expo, stores
• Documentation Expo — créer un projet
• Expo — configurer un premier build EAS
• Expo Router — introduction
• React Native — environnement de développement

FAQ

Q : Quelle différence entre Expo Go et un development build ?

R : Expo Go est une app pré-construite par Expo qui contient les modules du SDK Expo officiel. Vous y chargez votre code JS sans builder. Un development build est une version personnalisée de votre app, buildée par EAS, qui inclut votre code natif et vos modules tiers. Tant que vous n’utilisez que des modules SDK Expo, Expo Go suffit. Dès que vous ajoutez un module natif tiers, le development build devient nécessaire.

Q : Faut-il abandonner Expo dès qu’on a besoin de code natif personnalisé ?

R : Non. La commande npx expo prebuild génère les dossiers ios/ et android/ à partir de votre app.json, dossiers que vous pouvez ensuite éditer librement. Vous gardez l’écosystème Expo (CLI, SDK, EAS) tout en ajoutant du code natif. C’est ce qu’on appelait le mode « ejected » jusqu’en 2022 ; aujourd’hui c’est juste le mode bare, et il cohabite avec le mode managed sans rupture.

Q : Quel est le coût mensuel pour un développeur solo qui publie une app par mois ?

R : Zéro. Le plan gratuit d’EAS donne 15 builds Android et 15 builds iOS par mois, ce qui couvre largement un cycle de release mensuel avec une dizaine de builds de bêta intermédiaires. Le seul coût obligatoire est le compte développeur Apple à 99 $/an pour publier sur l’App Store, et 25 $ une fois pour ouvrir un compte Google Play.

Q : EAS Update remplace-t-il une mise à jour via le store ?

R : Pour les changements en JavaScript pur, oui — EAS Update pousse le nouveau bundle JS aux téléphones sans repasser par le store, en quelques secondes. Pour les changements de code natif (nouveau module, modification d’Info.plist ou d’AndroidManifest.xml), non — il faut un nouveau build et une nouvelle soumission. Apple impose aussi des limites : les mises à jour OTA ne doivent pas changer « fondamentalement » la fonctionnalité de l’app sous peine de violation des guidelines.

Q : Mon projet React Native existant est-il migrable vers Expo ?

R : Oui, et c’est l’un des chantiers fréquents de 2026. La commande npx install-expo-modules ajoute Expo SDK à un projet React Native vanille. Vous gardez votre code natif, vous gagnez l’accès au SDK Expo et à EAS Build. La migration prend généralement entre une demi-journée et deux jours selon la taille du projet et le nombre de modules natifs déjà installés.