Build et publication d’une app React Native avec EAS

📍 Article principal du parcours : React Native et Expo : créer une application mobile en 2026
Cette leçon clôt la série React Native. Pour la vue d’ensemble, consultez le guide principal.

De l’aperçu au vrai binaire

Jusqu’ici, StockPoche tournait dans Expo Go — pratique pour développer, mais ce n’est pas une vraie application installable. Pour la mettre entre les mains d’un commerçant, il faut produire un binaire : un fichier .apk ou .aab pour Android, un .ipa pour iOS, signé et prêt pour les stores. Le problème classique : compiler iOS exige un Mac et Xcode, compiler Android exige le SDK Android et Java. EAS Build résout cela en compilant dans le cloud, depuis n’importe quel ordinateur — même sous Windows, sans rien installer de natif.

Dans cette dernière leçon, vous configurez EAS, produisez un build de test puis un build de production, le soumettez aux stores, et apprenez à corriger un bug en quelques minutes grâce aux mises à jour à distance (OTA) — sans repasser par la validation des stores. C’est l’étape qui transforme un projet en produit livré.

🎯 Ce que vous allez apprendre

• Installer et configurer EAS pour votre projet.
• Comprendre les profils de build (development, preview, production) dans eas.json.
• Produire un build cloud Android et iOS sans machine native.
• Soumettre l’app aux stores avec eas submit.
• Publier un correctif instantané avec les mises à jour OTA (eas update).

🛠️ Ce que vous allez construire

La chaîne de livraison de StockPoche : un build de prévisualisation à partager avec un testeur par simple lien, un build de production signé pour les stores, et un canal de mises à jour à distance pour pousser un correctif sans réinstallation.

Prérequis

• L’application StockPoche fonctionnelle (toutes les leçons précédentes).
• Un compte Expo gratuit (créé sur expo.dev).
• Pour publier réellement : un compte Google Play Console et/ou Apple Developer (payants, côté éditeur).
• ⏱️ Temps estimé : ~45 minutes (hors temps de compilation cloud).

Étape 1 — Installer EAS et se connecter

EAS s’pilote avec sa propre interface en ligne de commande, eas-cli. On l’installe globalement, puis on se connecte à son compte Expo — c’est ce compte qui hébergera les builds et les mises à jour.

# Installer l'outil en ligne de commande EAS
npm install -g eas-cli

# Se connecter à son compte Expo
eas login

# Vérifier la connexion
eas whoami

Après eas login, saisissez les identifiants de votre compte Expo ; eas whoami confirme en affichant votre nom d’utilisateur. Si vous n’avez pas de compte, créez-le d’abord sur expo.dev — c’est gratuit pour un usage de développement. Tout le reste de la leçon se fait depuis le dossier du projet StockPoche.

✅ Point d’étape — eas whoami affiche votre identifiant Expo. Si la commande eas est introuvable, c’est que l’installation globale n’est pas dans le PATH : rouvrez le terminal.

Étape 2 — Configurer le projet pour EAS

Une seule commande prépare le projet : elle crée le fichier eas.json (la configuration des builds) et relie le projet à votre compte Expo. C’est l’équivalent d’un git init pour la chaîne de build.

eas build:configure

La commande détecte les plateformes, génère un identifiant de projet et écrit eas.json à la racine. Ce fichier est le cœur de la configuration : il décrit comment compiler selon le contexte. Examinons sa structure et ses trois profils standard.

{
  "cli": { "version": ">= 16.0.0" },
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal"
    },
    "preview": {
      "distribution": "internal",
      "android": { "buildType": "apk" }
    },
    "production": {
      "autoIncrement": true
    }
  },
  "submit": { "production": {} }
}

Chaque profil sert un usage précis. development produit un build de développement (avec le client de débogage) pour tester les modules natifs hors Expo Go. preview génère un binaire installable directement, idéal pour faire essayer l’app à un testeur sans passer par les stores ; le buildType: apk facilite l’installation sur Android. production produit le binaire optimisé et signé pour les stores, avec autoIncrement qui incrémente le numéro de build automatiquement.

✅ Point d’étape — Le fichier eas.json existe à la racine avec les trois profils. Si la commande demande de vous reconnecter, relancez eas login.

Étape 3 — Produire un build de prévisualisation

Commençons par le profil le plus utile au quotidien : preview. Il produit un APK Android installable que vous pouvez envoyer à un testeur par un simple lien. Le build se fait dans le cloud d’Expo : votre ordinateur n’a qu’à lancer la commande et attendre.

eas build --platform android --profile preview

EAS téléverse votre projet, le compile sur ses serveurs, et affiche une URL de suivi. À la fin (quelques minutes), vous obtenez un lien de téléchargement de l’APK. Envoyez ce lien à un testeur : il installe l’app sur son téléphone Android sans passer par le Play Store. C’est la façon la plus rapide de faire valider StockPoche par un commerçant avant la publication officielle.

✅ Point d’étape — La commande affiche « Build finished » et un lien vers l’APK. Téléchargez-le sur un téléphone Android et installez-le : StockPoche s’ouvre comme une vraie app. Si le build échoue, lisez les journaux sur la page de build — l’erreur y est détaillée.

Étape 4 — Produire le build de production

Pour les stores, on utilise le profil production. Sur Android, il génère un .aab (Android App Bundle, format exigé par le Play Store) ; sur iOS, un .ipa. La signature des binaires — étape habituellement pénible — est gérée par EAS, qui crée et conserve les certificats pour vous.

# Build de production pour les deux plateformes
eas build --platform all --profile production

Lors du premier build iOS, EAS vous guide pour générer les certificats et profils de provisionnement à partir de votre compte Apple Developer — automatiquement, sans manipuler Xcode. Pour Android, il crée la clé de signature et la garde en lieu sûr. À la fin, vous disposez des deux binaires prêts à être soumis. C’est ici que la compilation cloud prend tout son sens : vous venez de produire une app iOS depuis un PC Windows.

✅ Point d’étape — Vous obtenez un .aab et un .ipa sur le tableau de bord Expo. Conservez précieusement l’accès au compte : c’est lui qui détient les clés de signature, nécessaires à chaque mise à jour future.

Étape 5 — Soumettre l’app aux stores

Une fois le build de production prêt, eas submit l’envoie directement sur le Play Store ou l’App Store, sans téléverser le fichier à la main. C’est l’étape qui relie votre build cloud aux consoles des stores.

# Soumettre le dernier build au Play Store
eas submit --platform android --profile production

# Soumettre à l'App Store
eas submit --platform ios --profile production

EAS récupère le dernier build de production et le transmet à la console correspondante. Il vous demande les informations nécessaires la première fois (clé d’API Google Play, identifiants Apple). Après soumission, la suite se passe dans les consoles : fiche du store, captures d’écran, description, puis examen par la plateforme. La validation prend de quelques heures à quelques jours selon le store et la période.

✅ Point d’étape — Le build apparaît dans la console du store, en attente d’examen. Si la soumission échoue, c’est presque toujours une information manquante côté console (fiche incomplète, accord non signé) — la console l’indique.

Étape 6 — Corriger sans repasser par les stores : les mises à jour OTA

Voici la fonctionnalité qui change la vie. Quand vous corrigez un bug dans du code JavaScript ou un style, vous n’êtes pas obligé de reconstruire et de resoumettre l’app : EAS Update pousse la correction directement aux appareils, qui la récupèrent au prochain démarrage. C’est légal et prévu : seules les modifications natives exigent un nouveau build.

# Installer la bibliothèque de mise à jour
npx expo install expo-updates

# Publier une mise à jour sur le canal de production
eas update --branch production --message "Corrige le filtre de recherche"

La commande empaquette votre code JavaScript modifié et le publie sur le canal production. Les appareils déjà équipés de StockPoche téléchargent la mise à jour en arrière-plan et l’appliquent au lancement suivant. Un correctif urgent — par exemple le filtre de recherche qui plante — atteint ainsi vos utilisateurs en minutes au lieu de jours. Attention : tout ce qui touche au code natif (nouvelle permission, nouveau module natif) impose, lui, un vrai rebuild et une resoumission.

✅ Point d’étape — La commande confirme « Published! » avec un identifiant de mise à jour. Sur un appareil équipé du build de production, fermez puis rouvrez l’app : la correction est appliquée. Si rien ne change, vérifiez que le build et la mise à jour ciblent le même canal.

🐞 Pièges fréquents

🌍 Réalités du terrain

La compilation cloud d’EAS est un atout décisif quand on n’a pas de Mac : produire une app iOS depuis un PC Windows ou une machine Linux modeste devient possible, sans investir dans du matériel Apple. Le quota gratuit d’EAS suffit pour des builds occasionnels ; au-delà, les files d’attente peuvent s’allonger aux heures de pointe — anticipez un build de production la veille d’une échéance plutôt que le jour même.

Pour distribuer une app à un client sans passer par les stores — fréquent pour un outil interne d’entreprise — le profil preview et son APK partagé par lien sont souvent la solution la plus pragmatique : pas de frais de compte développeur, pas de délai d’examen. Et les mises à jour OTA prolongent cet avantage : vous corrigez et améliorez l’outil en continu sans réinstallation côté utilisateur, ce qui compte quand chaque téléchargement consomme de la donnée. Pour automatiser ces builds à chaque modification du code, branchez EAS sur une chaîne d’intégration continue, comme décrit dans le guide CI/CD mobile.

✅ Récapitulatif

StockPoche est désormais livrable. Vous avez configuré EAS et son fichier eas.json, compris les trois profils de build, produit un APK de prévisualisation partageable et des binaires de production signés — le tout dans le cloud, sans machine native. Vous savez soumettre aux stores avec eas submit et, surtout, pousser un correctif JavaScript en minutes via les mises à jour OTA. Le parcours React Native est complet : de l’installation à la livraison.

🧾 Aide-mémoire

💪 À vous de jouer

Produisez un build de prévisualisation, installez-le sur un téléphone, puis publiez une mise à jour OTA qui change un texte de l’app et vérifiez qu’elle s’applique sans réinstallation.

eas update --branch preview --message "Nouveau libellé d'accueil"

Tutoriels frères

• Accès natif : caméra et stockage — les modules natifs qui imposent un build de développement.
• Démarrer un projet React Native avec Expo — le point de départ du parcours.

Pour aller plus loin

• 🔝 Retour au guide principal : React Native et Expo : créer une application mobile
• Documentation officielle : EAS Build
• Automatiser les builds : CI/CD pour applications mobiles

FAQ

Q : Puis-je vraiment compiler une app iOS sans Mac ?
R : Oui. EAS Build compile iOS sur ses propres serveurs macOS. Vous lancez eas build --platform ios depuis Windows ou Linux et récupérez le .ipa. Un compte Apple Developer reste requis pour publier sur l’App Store.

Q : EAS est-il gratuit ?
R : Il y a un quota gratuit de builds, suffisant pour apprendre et pour des projets occasionnels. Au-delà, des offres payantes augmentent la priorité et le nombre de builds. Les mises à jour OTA ont aussi un palier gratuit.

Q : Quelle différence entre eas build et eas update ?
R : eas build produit un nouveau binaire (nécessaire pour le natif et la première publication). eas update ne pousse que du JavaScript/des ressources sur un build existant — instantané, mais limité aux changements non natifs.

Q : Dois-je resoumettre l’app à chaque correctif ?
R : Non, pas pour un correctif de code JavaScript : eas update suffit. La resoumission n’est nécessaire que pour un changement natif (nouvelle permission, nouveau module natif, montée de version du SDK).