Uploader un .aab sur Google Play sans Android Studio en 2026

Read in English →

Android Studio est la voie évidente pour builder et uploader un .aab — ce n'est pas la seule. Si votre workflow vit dans un terminal, une pipeline CI ou un framework cross-platform, ouvrir un IDE complet juste pour pousser un binaire de release est une friction dont vous pouvez vous passer. Si vous shippez aussi sur iOS, la même logique s'applique côté Xcode — voir comment uploader un .ipa sur App Store Connect sans Xcode.

Pourquoi se passer d'Android Studio pour l'upload ?

Android Studio est d'abord un outil de build ; la capacité d'upload est un confort pour les développeurs déjà dedans. Le format .aab n'a aucune dépendance à l'IDE — Google Play l'accepte via sa console web, son API Developer, et tout outil qui enveloppe cette API.

Méthode 1 : Play Console (upload navigateur)

Allez sur play.google.com/console, sélectionnez l'app, Release > Production (ou internal/alpha/beta), Créer une nouvelle release, uploadez le .aab sous App bundles, remplissez les notes de version, enregistrez / déployez. Fonctionne pour n'importe quel .aab, quelle que soit la méthode de build. Manuel — correct pour des releases occasionnelles, fastidieux à l'échelle.

Méthode 2 : Bundletool (ligne de commande)

Google publie bundletool en JAR autonome — il inspecte, valide et teste un .aab en local, mais n'uploade rien directement.

java -jar bundletool.jar validate --bundle=app-release.aab

Pour un vrai upload depuis le CLI, il faut passer par l'API Developer ou un outil qui l'enveloppe.

Méthode 3 : Google Play Developer API (appel API direct)

Il faut un compte de service Google avec le rôle Release Manager, sa clé JSON, et un jeton d'accès OAuth 2.0. Trois appels : créer un edit (POST .../edits), uploader le bundle (POST .../edits/{editId}/bundles), assigner à un track et commit (PUT track, POST commit). Entièrement automatisable, mais vous écrivez vous-même l'intégration ; google-api-python-client ou google-api-nodejs-client comme point de départ.

Méthode 4 : Fastlane supply

fastlane supply --aab app-release.aab --track production

Enveloppe l'API Developer, gère le cycle edit/upload/commit. Gratuit, open-source, standard depuis des années. Le compromis : ça demande Ruby, un Gemfile, et une certaine familiarité avec la config Fastlane.

Méthode 5 : Expo EAS Submit

eas submit --platform android

La clé JSON du compte de service se configure dans eas.json, EAS gère les appels API. C'est l'option la plus fluide pour un projet Expo — build et submit dans la même toolchain.

Méthode 6 : un dashboard unifié (OneStore)

Les cinq méthodes précédentes résolvent l'upload en isolation, pas le travail autour (métadonnées de fiche avant release, suivi de ce qui est en ligne vs en brouillon, gestion d'iOS en parallèle d'Android). OneStore relie l'upload du .aab au reste du workflow de release : authentification unique avec la clé JSON du compte de service, uploads via l'API Developer, contrôle du rollout progressif directement depuis le dashboard. Si vous shippez aussi iOS, le .ipa part dans la même session. Pour le détail de comment OneStore livre les binaires (.ipa comme .aab), voir comment OneStore envoie vos binaires.

Choisir la bonne méthode

Une note sur les permissions du compte de service

Quelle que soit la méthode, la clé JSON du compte de service a besoin des bonnes permissions Play Console — le rôle Release Manager couvre l'upload de bundles et la gestion des tracks ; Admin fonctionne aussi mais accorde plus que nécessaire, préférez le scope minimal. Ne committez jamais ce JSON dans un dépôt de code.

FAQ

Faut-il installer Android Studio pour builder un .aab ?

Non — ./gradlew bundleRelease, Expo EAS Build ou flutter build appbundle fonctionnent tous sans lui.

Peut-on uploader directement en internal testing plutôt qu'en production ?

Oui — l'upload navigateur et l'API Developer permettent tous deux de cibler n'importe quel track ; Fastlane avec --track internal ; EAS configure le track dans eas.json.

Quelle différence entre .aab et .apk pour l'upload ?

Google Play exige le .aab pour les nouvelles apps depuis août 2021 ; les apps existantes peuvent encore mettre à jour via .apk, mais toute nouvelle app doit passer par .aab (ou par Play Asset Delivery).

Comment générer une clé JSON de compte de service ?

Dans Google Cloud Console, créez un compte de service sous votre projet, générez une clé JSON, puis accordez-lui l'accès dans Play Console sous Utilisateurs et permissions avec le rôle Release Manager au niveau de l'app.

Est-ce sûr de confier ma clé JSON de compte de service à un outil tiers ?

Ça dépend de comment l'outil la stocke. Chez OneStore, la clé JSON va dans un vault chiffré au repos avec AES-256-GCM (chiffrement authentifié) au niveau applicatif ; un accord de traitement des données basé sur les clauses contractuelles types de l'UE est disponible sur demande sur onestore.so/dpa. Ce n'est pas une promesse d'hébergement en Europe ni une conformité RGPD générique — vérifiez toujours la politique de sécurité réelle de l'outil avant de lui donner un accès Release Manager.

Peut-on automatiser l'upload de .aab en CI/CD sans Fastlane ?

Oui — l'API Developer accepte des appels HTTP directs, s'intègre dans GitHub Actions, Bitrise ou CircleCI via les client libraries officielles ; il faut une clé JSON de compte de service valide et le bon scope OAuth.

Que se passe-t-il si j'uploade avec le mauvais version code ?

Google Play rejette l'upload si le version code existe déjà ou est inférieur à la release courante — incrémentez versionCode dans build.gradle avant de rebuilder.

Envie de vérifier votre fiche avant la prochaine release ? Audit de fiche de store le fait gratuitement en quelques secondes. OneStore gère le reste : upload, rollout progressif, et les deux stores depuis un seul dashboard.