Comment publier une application Android sur le Play Store en 2026 ?

Je suis en train de publier Macrodiet, mon app de nutrition macrobiotique, sur le Play Store. iOS approuvé le 4 mai. Android : compte créé, build (5) uploadé en test interne, abonnements configurés, fiche store complète. Mais pas encore en prod parce que je dois passer la fameuse phase de bêta fermée de 14 jours avec 12 testeurs minimum.

Ce guide rassemble tout ce que j'ai appris en faisant la publication des deux côtés — avec le vrai planning réaliste que personne ne te dit avant de t'engager.

Les 7 grandes étapes pour publier sur Google Play

Total réaliste pour une première publication : 4 à 6 semaines, dont 14 jours incompressibles si vous avez un compte Personal créé après novembre 2023.

Les pré-requis avant de commencer

Le compte Google Play Console (25 USD une fois)

Bonne nouvelle vs Apple : paiement unique de 25 USD, pas d'abonnement annuel. Le compte est valide à vie. L'inscription se fait sur play.google.com/console/signup.

⚠️ Piège : si vous n'utilisez pas le compte pendant ~12 mois, Google le ferme automatiquement et les frais sont perdus. Pour Macrodiet, j'ai dû récupérer un ancien compte créé en octobre 2025 qui était sur le point d'être fermé pour inactivité — j'ai eu de la chance.

Personal vs Organization : lequel choisir ?

Au moment de l'inscription, Google vous demande de choisir entre Personal (Particulier) et Organization (Entreprise). Le choix a des conséquences importantes :

Mon conseil :

• Si vous avez une entreprise déjà déclarée + un D-U-N-S déjà obtenu → Organization
• Si vous êtes auto-entrepreneur, freelance ou particulier → Personal (plus rapide à activer, mais 14j de bêta fermée à anticiper)
• Si vous anticipez le D-U-N-S très tôt dans votre planning produit → vous pouvez le demander pendant que vous codez l'app

Pour Macrodiet, j'ai choisi Personal parce que la vitesse d'activation primait sur l'éviction des 14 jours de bêta.

Android Studio (pas besoin de Mac)

Contrairement à iOS, vous pouvez publier une app Android depuis Windows, Linux ou Mac. Outils requis :

• Android Studio (gratuit, multi-OS, ~3 Go) : IDE, simulateurs, build tools
• Java JDK (souvent inclus dans Android Studio) : nécessaire pour keytool
• Flutter ou React Native ou Kotlin natif : selon votre stack

Si votre app est multi-plateforme Flutter, vous travaillez sur le même projet que iOS — pas de duplication de code. C'est l'avantage massif d'un framework cross-platform.

Le package name et l'identité de l'app

Le package name Android est l'équivalent du bundle ID iOS (ex : app.macrodiet.macrodiet). Convention reverse-DNS, immuable une fois publié.

Si vous publiez la même app sur iOS et Android, utilisez le même identifiant des deux côtés : ça simplifie analytics, deep links, et branding.

Configuration dans Play Console

Google Play Console est le tableau de bord équivalent à App Store Connect.

Créer la fiche de l'app

Toutes les apps → Créer une application. Vous renseignez :

• Nom de l'application : visible sur le store, max 30 caractères
• Langue par défaut : choisissez bien, ça oriente les autres champs
• Type d'application : App ou Jeu
• Gratuite ou Payante : pour les apps avec IAP, choisissez Gratuite (le store dit « Free », l'IAP gère le paiement)

Préparer les métadonnées

Trois champs visibles par l'utilisateur :

• Brève description (max 80 chars) : sous le nom dans la fiche, indexée pour la recherche
• Description complète (max 4000 chars) : la fiche complète, visible quand on tape « Plus d'infos »
• Tags (5 max) : choisis dans une liste prédéfinie selon votre catégorie

⚠️ Évitez les claims marketing agressifs dans la description :

• ❌ « Perdez 5 kg en une semaine ! » → flag automatique sur les apps santé
• ❌ « L'application n°1 mondiale » → claim non vérifiable
• ✅ « 110 aliments analysés, équilibre Yin/Yang, assistant IA » → factuel

Capturer les screenshots aux bons formats

Google Play impose des dimensions strictes :

• Icône : 512×512 px PNG (sans transparence)
• Image de présentation (Feature Graphic) : 1024×500 px JPG/PNG, sans screenshot ni mockup de téléphone (Google interdit explicitement)
• Screenshots téléphone : 2 à 8 captures, ratio entre 9:16 et 16:9, chaque côté entre 320 et 3840 px

Si vos screenshots iOS sont en 1320×2868 (iPhone 16 Pro Max), le ratio est ~9:19.5 — trop allongé pour Google. Deux options :

1. Padding latéral : ajouter du blanc/cream sur les côtés pour atteindre 1614×2868 (9:16 exact)
2. Crop centré : couper en hauteur vers 1320×2347

J'ai choisi l'option 1 pour Macrodiet : ça préserve toute l'UI iOS, on ajoute juste du padding crème esthétique. Script Python en 10 lignes avec PIL.

Data Safety — la déclaration de collecte de données

C'est l'équivalent du Privacy Nutrition Label d'Apple, mais plus détaillé. Google vous demande de déclarer catégorie par catégorie :

• Quels types de données vous collectez (email, nom, photos, conversations IA, etc.)
• Pour chaque type : objectif, partage tiers, optionnel ou requis
• Sécurité : chiffrement en transit, possibilité de suppression de compte

⚠️ Mentir ici = violation directe de la politique Play. Si vous déclarez « Aucune donnée collectée » alors que votre app utilise Supabase + Firebase, votre app peut être retirée même après publication quand Google détecte la divergence.

<uses-permission
    android:name="com.google.android.gms.permission.AD_ID"
    tools:node="remove" />

Classification du contenu

Google génère automatiquement les ratings (PEGI, ESRB, ClassInd) à partir d'un questionnaire. Pour une app type Macrodiet (nutrition, IAP, login), vous obtenez généralement PEGI 3 / ESRB Everyone — sauf au Brésil (ClassInd 14+ à cause des « achats in-app », anomalie locale sans impact en Europe).

Tranches d'âge cibles

Pour une app wellness/nutrition adulte, cochez uniquement 16-17 et 18+. En cochant 13-15 ou moins, vous tombez sous Google Families Policy (interdiction de pub tierce non certifiée, parental consent obligatoire dans certains pays UE) — overhead réglementaire qu'on évite tant qu'on n'a pas une vraie cible enfant.

Le build, la signature, et le keystore

Générer un keystore avec keytool

Le keystore est le fichier de signature de votre app. C'est l'élément le plus critique de toute votre publication Android : si vous le perdez, vous ne pourrez plus jamais updater votre app sous le même package name.

Commande de génération (depuis le JDK Android Studio) :

keytool -genkey -v \
  -keystore ~/keys/votre-app.jks \
  -storetype PKCS12 \
  -keyalg RSA -keysize 2048 \
  -validity 10000 \
  -alias votre-app

keytool vous demande un mot de passe (storePassword + keyPassword) et des infos de certificat. Stockez tout ça dans 1Password ou Bitwarden immédiatement.

Configurer le signing dans build.gradle

Créez un fichier android/key.properties (à NE PAS commit dans Git, vérifiez votre .gitignore) :

storePassword=VOTRE_MOT_DE_PASSE
keyPassword=VOTRE_MOT_DE_PASSE
keyAlias=votre-app
storeFile=/Users/vous/keys/votre-app.jks

Puis dans android/app/build.gradle.kts, chargez ce fichier et configurez le signing config pour la build release. Flutter a une doc détaillée pour ce point.

Builder le .aab signé

flutter build appbundle --release

Vous obtenez un .aab (Android App Bundle) dans build/app/outputs/bundle/release/. Pour Macrodiet : 52,1 Mo.

Pourquoi .aab et pas .apk ? Google a abandonné les .apk en 2021. Le .aab est un format intermédiaire : Google génère ensuite des APK optimisés par device (ABI, density, langue) — l'utilisateur télécharge typiquement seulement 15-20 Mo au lieu des 52 Mo du bundle. C'est le dynamic delivery.

Sauvegarder le keystore (CRITICAL)

Triple sauvegarde :

1. Local : votre Mac/PC, dans un dossier hors du repo Git
2. Cloud chiffré : 1Password / Bitwarden / iCloud Drive personnel
3. Backup physique : clé USB ou Time Machine

Si tu perds les trois, tu perds Macrodiet sur Android pour toujours sous ce package name. Aucun support Google ne peut le récupérer.

Le piège des nouveaux comptes : 14 jours de bêta fermée

Pourquoi cette règle existe

Depuis novembre 2023, Google impose à tous les nouveaux comptes Personal une phase de validation avant publication en production :

• 12 testeurs minimum, opted-in à un test fermé
• 14 jours consécutifs minimum de durée de test
• Activité de test trackée par compte Google (pas par device)

Le but : limiter les apps fraudeuses ou malveillantes publiées par des comptes neufs sans historique.

Comment recruter 12 testeurs

Les vrais testeurs uniques sont obligatoires — Google détecte les comptes fakes (même IP, fingerprint matériel commun, comptes récents sans historique). Trois approches qui fonctionnent :

1. Réseau perso : famille + amis + collègues qui ont un Android. Message WhatsApp générique : « j'ai besoin de 12 personnes pour tester mon app sur Android, 14 jours. Échange : 1 mois Premium gratuit ». Ça part vite.
2. Reddit : r/AndroidBetaTester, r/AppBetaTesters, r/AlphaAndBetaUsers — vous postez une fois, vous recevez 30+ candidats en 24h, gratuit.
3. Upwork : 5-10 USD par testeur, total ~60-100 USD pour les 12. Vous postez « Android beta tester for 14 days, opt-in + install required », vous avez 50 candidatures en 4h.

Comment lancer le test fermé

Path : Play Console → Tester → Tests fermés → Créer une release.

1. Uploader votre .aab (le build doit déjà avoir passé un test interne avec succès)
2. Configurer la liste des pays disponibles (sélectionnez large pour le test, vous restreindrez en prod)
3. Créer une liste d'adresses email des 12 testeurs (onglet Testeurs)
4. Activer le track → le compteur de 14 jours démarre

Pendant ces 14 jours, vous pouvez continuer à pousser des updates sur le track de test. Le compteur ne redémarre pas tant que vous restez sur le même bundle ID.

Configurer les abonnements (IAP)

Le piège chicken-and-egg

Vous ne pouvez pas créer les produits IAP avant d'avoir uploadé un .aab. La section « Abonnements » du Play Console reste verrouillée tant qu'aucune build n'est passée par n'importe quel track (interne, fermé, ou prod).

Donc l'ordre est :

1. Builder un premier .aab même incomplet
2. Upload en test interne (le track le moins contraignant)
3. Maintenant vous pouvez créer les abonnements
4. Re-builder une .aab (1.0.0+5) avec les vrais IDs IAP référencés
5. Promouvoir vers test fermé

Créer les produits avec les bons IDs

Path : Monétiser avec Play → Produits → Abonnements.

⚠️ Les Product IDs doivent être identiques côté iOS et Android si vous utilisez du code Flutter cross-platform — sinon queryProductDetails échoue sur l'une des deux plateformes.

Pour Macrodiet :

• premium_mensuel — 5 € / mois
• premium_annuel — 60 € / an

Chaque abonnement a un plan de base (auto-renouvelable, période de facturation, prix) et optionnellement des offres (essai gratuit, prix réduit première période, etc.).

Tester avec license testing

Avant la prod, dans Paramètres → Paramètres de licence : ajoutez votre Gmail comme testeur de licence. Ça vous permet de tester les achats en mode sandbox sans débit réel — équivalent du bac à sable iOS.

Délai de propagation : les nouveaux IAP mettent 2 à 24 heures pour être queryables côté app. Si vous lancez l'app juste après création et que queryProductDetails retourne vide, ne paniquez pas — attendez le lendemain.

La review Google Play : à quoi s'attendre

Délais réels (mai 2026)

• Apps neuves : 1 à 7 jours (médiane ~3 jours, plus rapide qu'Apple)
• Updates : 1-3 jours
• Pas de système d'expedited review équivalent à Apple

Google review beaucoup automatiquement (analyse statique du .aab) et fait du sampling humain. Moins strict qu'Apple sur la forme, plus strict sur certains points (politique Play Families, données sensibles).

Compte reviewer

Google ne pose pas systématiquement de questions au reviewer comme Apple. Mais si votre app exige un login, fournissez les credentials dans la section « Accès aux applications » lors de la création de la fiche.

Pour Macrodiet, j'ai utilisé le même compte reviewer que pour Apple : un compte Premium activé en base avec subscription_tier = 'yearly' côté Supabase, pour que le reviewer voie toutes les fonctionnalités sans devoir simuler un IAP.

Les motifs de rejet courants

Google rejette moins que Apple en première soumission. Les rejets que je vois revenir :

1. Data Safety incohérent : déclaration « Aucune donnée collectée » alors que l'app utilise Firebase, Supabase, Sentry, etc. Détection automatique.
2. Permissions excessives : demande de permissions non utilisées (location, contacts) sans justification — flagué par l'analyse statique.
3. Politique Play Families : si vous cochez « moins de 13 ans » sans implémenter les protections requises.
4. Apps santé sans disclaimer : équivalent de la guideline 1.4.1 d'Apple, mais Google est moins strict.
5. Liens trompeurs : liens vers d'autres stores ou systèmes de paiement qui contournent Google Play Billing.

Les pièges Android-spécifiques (de l'expérience Macrodiet)

POST_NOTIFICATIONS requis sur Android 13+

Depuis Android 13 (API 33), les notifications push exigent une permission runtime. Sans déclaration explicite dans le manifest, FCM ne peut pas demander la permission à l'utilisateur.

Ajout dans AndroidManifest.xml :

<uses-permission android:name="android.permission.POST_NOTIFICATIONS" />

Subscription management URL platform-aware

Si votre app a un bouton « Gérer mon abonnement » et qu'il pointe vers https://apps.apple.com/account/subscriptions (URL Apple), ça crashe ou ouvre Apple Account sur Android. Faites un check Platform.isIOS et redirigez vers https://play.google.com/store/account/subscriptions sur Android.

Sign in with Apple à masquer sur Android

Apple impose Sign in with Apple sur iOS dès qu'un autre login tiers est présent. Mais sur Android, c'est de la friction inutile : la majorité des utilisateurs Android n'ont pas d'Apple ID et seront perdus. Wrapez le bouton Apple dans un if (Platform.isIOS) Flutter et laissez seulement Google Sign-In + email/password sur Android.

Le label de la bottom nav peut être tronqué

Sur certains écrans Android, les labels longs (« Combinaisons » dans Macrodiet) peuvent être tronqués. Si vous testez sur émulateur, vérifiez en orientation portrait + landscape avant de soumettre.

Combien ça coûte au total ?

Mes 5 conseils issus de l'expérience Macrodiet

1. Anticipez les 14 jours de bêta fermée dès le début. Recrutez vos 12 testeurs en parallèle du dev, pas après le build. Sinon vous attendez une semaine pour réunir les gens, puis les 14 jours fixes — total 3 semaines perdues.
2. Gardez le même Product ID iOS et Android pour les IAP. Sinon votre code Flutter doit gérer deux chemins, et vos analytics se compliquent.
3. Créez le keystore une bonne fois pour toutes et backupez-le en 3 endroits dès la première seconde. C'est l'élément le plus critique de votre publication.
4. Si vous publiez iOS d'abord (recommandé), vous pouvez réutiliser quasi tous vos assets sur Android : icône (resize 512), screenshots (juste padding latéral pour le ratio 9:16), description (à adapter pour éviter le duplicate content vs App Store).
5. Le delta entre iOS et Android sur Macrodiet a été de ~10 jours de fix : Apple Sign-In conditionnel, URL d'abonnement platform-aware, permission POST_NOTIFICATIONS, AD_ID transitif à exclure. Anticipez ces 4 fixes dès l'écriture du code, c'est plus rapide.

Questions fréquentes