Chapitre 12.2 — EAS Build en production

Où on en est : identité figée. Premier binaire de PRODUCTION — par le cloud d’abord (le chemin qui gère la signature pour vous), le local au chapitre suivant.

⏱️ TL;DR — Le profil preview d’eas.json produit l’APK de prod sideloadable (JS embarqué, mode release) — LE format de la voie perso. Le profil production produit l’AAB pour le Play Store (P13). EAS gère le keystore de signature (généré, stocké, sauvegardable — eas credentials). Quotas du plan gratuit et files d’attente : les chiffres honnêtes pour planifier.

🎯 Objectifs

Comprendre APK vs AAB une bonne fois (et pourquoi la voie perso = APK).
Lancer le build preview et récupérer un binaire installable.
Comprendre la signature Android et ce qu’EAS fait du keystore.
Connaître les limites du plan gratuit pour décider local vs cloud en connaissance.

APK vs AAB — le seul tableau à retenir

	APK	AAB (Android App Bundle)
Nature	Le binaire installable	Un « colis » pour le Play Store
S’installe directement	✅ (sideload, adb)	❌ (le Store en dérive des APK optimisés par appareil)
Poids téléchargé	Tout inclus (toutes densités/ABIs)	Optimisé par le Store (~-30 %)
Voie perso (P12)	✅ le format	inutile
Play Store (P13)	refusé depuis 2021	✅ obligatoire

Un AAB ne s’installe PAS sur un téléphone — c’est l’erreur classique du premier build de store. Voie perso = APK, toujours.

Le profil preview : l’APK de prod

Relecture d’eas.json (ch. 11.2) avec les yeux d’aujourd’hui :


"preview": {
  "distribution": "internal",           // hors store → APK installable
  "env": { "APP_VARIANT": "production" },   // identité PROD (com.alex.drill, « Drill »)
  "android": { "buildType": "apk" }
}

« Preview » est le nom EAS historique — pour nous c’est le profil app perso : mode release (JS minifié embarqué, pas de menu dev, perfs réelles), identité de prod, format APK.


eas build --profile preview --platform android

Même déroulé qu’au ch. 11.2 (upload → file → build → lien/QR), mais le résultat est autonome : installez-le, coupez Metro, coupez le WiFi — Drill vit sa vie. C’est officiellement la première « vraie » version de votre app.

La signature — ce qui se passe sous le capot

Android n’installe que des binaires signés ; les mises à jour ne s’installent que si la signature est identique à celle en place. La clé (le keystore) est donc un objet précieux : perdue = impossible de mettre à jour l’app installée (réinstallation sèche, données perdues — et catastrophe si l’app était sur le Store).

Ce que fait EAS : à votre premier build, il génère un keystore et le garde sur ses serveurs — tous vos builds cloud signent pareil, zéro geste. Les commandes à connaître :


eas credentials      # inspecter / télécharger / importer le keystore

Le geste de prudence (5 min, une fois) : eas credentials → Download → ranger le .jks + ses mots de passe dans votre gestionnaire de mots de passe. EAS est fiable, mais un keystore n’existe jamais en un seul exemplaire — et le ch. 12.3 (build local) voudra signer avec LE MÊME (sinon les mises à jour locales/cloud se refuseront mutuellement).

Les quotas du plan gratuit — les chiffres honnêtes

L’offre gratuite EAS (2026) : ~30 builds/mois (dont ~15 crédits iOS-équivalents selon la grille du moment), file d’attente standard (10-30 min d’attente aux heures de pointe US), builds Android ~10-15 min d’exécution. Largement assez pour notre cadence « le conteneur change rarement » — insuffisant si vous itérez du natif à la journée (→ local, chapitre suivant).

À savoir aussi : eas build:list (historique + liens de téléchargement), les builds expirent du CDN après ~30 jours (retéléchargez ce qui compte), et le dashboard expo.dev montre logs complets de chaque build — LE réflexe quand un build cloud échoue.

⚠️ Piège — Le build preview embarque le JS du moment du build : vos données de dev (repo de questions de TEST si APP_VARIANT jouait sur extra, ch. 11.3) peuvent s’y glisser. Avant chaque build de prod : vérifier les env du profil dans eas.json — c’est LE bug de config qui atteint la prod. Et rappel : mode release = plus de RedBox — les erreurs JS crashent ou passent silencieuses (Sentry en P14 comblera ce trou noir).

💡 Pour un dev Next.js — Le keystore n’a aucun équivalent web — c’est la matérialisation de « qui a le droit de mettre à jour ce qui est installé chez les gens ». Prenez-le au sérieux comme un secret de prod : sauvegardé, jamais commité, jamais partagé en clair. Le reste du chapitre, vous l’avez reconnu : preview/production = vos environnements Vercel.

✏️ Exercices

1. Lancez le build preview, installez l’APK, et déroulez le test d’autonomie complet : Metro coupé, WiFi coupé, kill, relance, une partie complète (le cache offline du ch. 7.4 passe-t-il en release ?).

✅ Solution

Tout doit fonctionner : le JS est embarqué, le cache Query persisté fait l’offline, SQLite est local. Si l’app release diffère du dev (ça arrive : timing d’hydratation, code strippé), c’est maintenant qu’on le découvre — pas après le Store. Ce test d’autonomie devient un rituel pré-release (il rejoint la checklist du ch. 7.4).

2. Faites le geste de prudence : téléchargez le keystore via eas credentials, notez l’empreinte SHA-1 affichée, et rangez le tout. Pourquoi le SHA-1 est-il bon à garder ?

✅ Solution

eas credentials → Android → Download credentials → .jks + passwords dans le gestionnaire. Le SHA-1 identifie la signature : utile pour vérifier qu’un APK est signé par LA bonne clé (keytool -printcert -jarfile app.apk), et exigé par certains services (Google Sign-In, Firebase). Une empreinte notée = des heures de débogage épargnées.

3. Comparez les poids : l’APK preview vs le dossier de votre projet. Où sont passés les node_modules, et pourquoi l’APK reste-t-il « gros » (~30-50 Mo) ?

✅ Solution

Metro a bundlé UNIQUEMENT le code atteint (tree-shaking par la racine) : les node_modules n’existent plus en tant que tels — un seul bundle Hermes. Le poids restant : les runtimes natifs (RN, Reanimated, SQLite… par architecture ABI), les assets, et les ressources Android. L’AAB du Store réduira le téléchargement (~-30 %) en ne livrant que l’ABI/densité de l’appareil — c’est SA raison d’être.

🧠 Quiz

1. Pourquoi un AAB ne s’installe-t-il pas sur un téléphone ?

Réponse

C’est un colis pour le Play Store, pas un binaire : le Store en dérive des APK optimisés par appareil. Voie perso = APK (profil preview), Store = AAB (profil production).

2. Qu’est-ce qui distingue le build preview du dev build ?

Réponse

Mode release : JS minifié embarqué (autonome, sans Metro), pas de dev-client ni RedBox, perfs réelles, identité de prod. Le dev build est un conteneur d’outillage ; preview est l’app.

3. Que garantit la signature pour les mises à jour ?

Réponse

Android ne met à jour une app que si la nouvelle version est signée par la même clé — le keystore est donc l’objet qui matérialise le droit de mise à jour. Perdu = plus de mises à jour possibles.

4. Où vit le keystore avec EAS, et quel est le geste de prudence ?

Réponse

Généré et stocké par EAS (tous les builds cloud signent pareil). Prudence : eas credentials → télécharger le .jks + mots de passe → gestionnaire de mots de passe.

5. Citez deux limites du plan EAS gratuit à connaître.

Réponse

~30 builds/mois et la file standard (attente aux heures de pointe) ; artefacts expirés après ~30 jours. D’où la doctrine : local par défaut, cloud pour les occasions.

👉 Chapitre suivant : 12.3 — Le build local gradle — le même APK release, sur ta machine, illimité — keystore compris.