Publier une application Kotlin sur le Play Store : signing et bundle pas à pas

Une application Kotlin testée et fonctionnelle ne devient une vraie application qu’au moment où elle atterrit sur la fiche d’un magasin. Pour Android, c’est Google Play Console. La chaîne entre le projet Android Studio et le téléchargement par un utilisateur passe par cinq grandes étapes : créer un compte Play Console, générer une keystore de signature, configurer le build release, produire un Android App Bundle (.aab), uploader le bundle et passer la revue Google. Chaque étape a ses pièges. Ce tutoriel les passe en revue dans l’ordre, avec les versions et politiques à jour au 17 mai 2026, dont le seuil 16 KB déjà obligatoire depuis le 1er novembre 2025 pour Android 15+ et le target SDK 36 obligatoire à partir du 31 août 2026.

Prérequis

• Application Kotlin Compose fonctionnelle, testée sur émulateur et device physique
• Compte Google personnel (sera utilisé pour Play Console)
• 25 USD pour les frais d’inscription développeur (une fois pour toutes, paiement par carte)
• Pièce d’identité valide (vérification d’identité requise depuis 2024)
• Adresse postale réelle (carte de visite, dispatcher courrier acceptés)
• Temps estimé : 4 à 6 heures incluant les revues Google (qui prennent quelques jours)

Étape 1 — Créer un compte Play Console

Rendez-vous sur play.google.com/console et cliquez sur « Commencer ». Choisissez « Compte personnel » sauf si vous publiez au nom d’une entreprise déjà enregistrée. Le compte personnel impose un délai de probation : les 14 premiers jours, l’application n’est visible que par un groupe restreint de testeurs, et il faut au moins 12 testeurs opt-in continûment sur 14 jours pour publier en production. C’est une mesure anti-spam introduite en novembre 2023 (initialement 20 testeurs, abaissée à 12 le 11 décembre 2024). Pour les entreprises déjà constituées, créer un compte « Entreprise » dispense de cette contrainte.

Payez les 25 USD de frais. La carte doit être au nom de la personne créant le compte. Google vérifie ensuite votre identité via un upload de pièce d’identité (passeport, CNI) et confirmation d’adresse — comptez 24 à 72 heures pour la validation. Pendant ce temps, vous pouvez préparer la suite : configurer votre projet, générer la keystore, produire un premier bundle de test.

Étape 2 — Générer une keystore de signature

Toute application Android distribuée doit être signée cryptographiquement. La signature garantit qu’une mise à jour vient bien du même éditeur que la version initiale. La clé de signature est précieuse : si vous la perdez, vous ne pourrez plus mettre à jour votre application sans publier sous un nouveau package ID (perdre tous les utilisateurs). On la sauvegarde donc dans un coffre.

keytool -genkey -v \
  -keystore release.keystore \
  -keyalg RSA -keysize 2048 \
  -validity 25000 \
  -alias monalias

Quatre points cruciaux. Stockez release.keystore hors du repo (jamais commité), chiffré sur un cloud privé ou un coffre type Bitwarden. Notez les deux mots de passe (keystore + alias) au même endroit. La validité de 25 000 jours (68 ans) couvre la durée raisonnable de toute application. RSA 2048 bits est le standard accepté par Google ; ne pas descendre en dessous.

Étape 3 — Configurer signingConfig dans Gradle

Dans app/build.gradle.kts, on déclare une signingConfig qui pointe vers la keystore. Pour éviter de hardcoder les mots de passe dans le repo, on les lit depuis un fichier keystore.properties à la racine du projet, lui-même ajouté au .gitignore.

// keystore.properties (NE PAS COMMITER)
storeFile=/Users/moi/secrets/release.keystore
storePassword=mot_de_passe_keystore
keyAlias=monalias
keyPassword=mot_de_passe_alias

// build.gradle.kts (module app)
val keystorePropertiesFile = rootProject.file("keystore.properties")
val keystoreProperties = Properties().apply {
    if (keystorePropertiesFile.exists()) {
        load(FileInputStream(keystorePropertiesFile))
    }
}

android {
    signingConfigs {
        create("release") {
            storeFile = file(keystoreProperties.getProperty("storeFile") ?: "dummy")
            storePassword = keystoreProperties.getProperty("storePassword")
            keyAlias = keystoreProperties.getProperty("keyAlias")
            keyPassword = keystoreProperties.getProperty("keyPassword")
        }
    }

    buildTypes {
        release {
            signingConfig = signingConfigs.getByName("release")
            isMinifyEnabled = true
            isShrinkResources = true
            proguardFiles(getDefaultProguardFile("proguard-android-optimize.txt"), "proguard-rules.pro")
        }
    }
}

Deux options activent l’optimisation du build release. isMinifyEnabled = true lance R8 qui minifie et obfusque le code Kotlin, réduisant la taille de l’APK de 30 à 50 %. isShrinkResources = true retire les ressources (drawables, strings) non référencées, gain supplémentaire de 5 à 15 %. Le fichier proguard-rules.pro contient les règles personnalisées si une bibliothèque tierce a besoin de conserver certaines classes.

Étape 4 — Configurer le manifest et la conformité 2026

Le AndroidManifest.xml doit contenir un identifiant unique de package, une version code (entière, croissante), une version name (texte affiché), et déclarer les permissions strictement nécessaires. Le build.gradle.kts centralise ces valeurs.

android {
    namespace = "io.itskillscenter.monapp"
    compileSdk = 36

    defaultConfig {
        applicationId = "io.itskillscenter.monapp"
        minSdk = 24
        targetSdk = 36
        versionCode = 1
        versionName = "1.0.0"
    }

    packaging {
        jniLibs {
            useLegacyPackaging = false
        }
    }
}

Trois exigences 2026 à respecter. targetSdk = 36 obligatoire à partir du 31 août pour toute nouvelle soumission. compileSdk = 36 imposé par les dépendances AndroidX récentes. useLegacyPackaging = false garantit que les bibliothèques natives restent non-compressées et alignées 16 KB — exigé par Google Play depuis le 1er novembre 2025. Si votre application embarque du NDK ou des bibliothèques natives, recompiler avec NDK r28+ et vérifier l’alignement avec readelf -l libnative.so | grep LOAD.

Étape 5 — Produire l’Android App Bundle (.aab)

Depuis 2021, Google Play exige le format Android App Bundle (.aab) pour les nouvelles applications. Contrairement à l’APK monolithique, le bundle contient toutes les ressources et Google génère à la volée un APK optimisé par device (par taille d’écran, par langue, par architecture CPU). Pour l’utilisateur, c’est typiquement 30 à 50 % de moins à télécharger.

# Construire le bundle release signé
./gradlew bundleRelease

# Le bundle se trouve dans :
# app/build/outputs/bundle/release/app-release.aab

# Vérifier la signature
jarsigner -verify -verbose -certs app-release.aab

Le build prend 2 à 10 minutes selon la machine et la taille du projet. À la fin, vérifiez la sortie : aucune erreur, signature confirmée. Avant l’upload, testez localement le bundle avec bundletool (Google) qui simule ce que Google Play générera comme APK :

java -jar bundletool.jar build-apks \
  --bundle=app-release.aab \
  --output=test.apks \
  --mode=universal

java -jar bundletool.jar install-apks --apks=test.apks

Cette validation locale évite de découvrir un crash après l’upload. Elle vérifie aussi que toutes les ressources sont bien empaquetées et que la signature fonctionne.

Étape 6 — Créer la fiche Play Console

Dans Play Console, cliquez sur « Créer une application ». Renseignez : nom de l’application (50 caractères), langue par défaut, type (application ou jeu), gratuit/payant. Acceptez les déclarations Google (politique de contenu, lois sur les exportations US).

Avant tout upload, complétez les sections obligatoires du tableau de bord. Confidentialité des données : déclarer chaque type de donnée collectée (e-mail, géolocalisation, identifiants device), la finalité, et si la donnée est chiffrée en transit. Contenu de l’application : public cible (âge minimal), accessibilité, contenu publicitaire, politique de confidentialité (URL d’une page hébergée). Fiche du Play Store : description courte (80 car.), description complète (4000 car.), captures d’écran (au moins 2 en mode portrait), icône 512×512 px PNG, bannière 1024×500 px PNG. Sans ces éléments, l’application reste bloquée en brouillon.

Étape 7 — Uploader et déployer progressivement

Dans le menu « Production » de la console, cliquez sur « Créer une release ». Activez Play App Signing (recommandé par Google depuis 2021) : Google génère et conserve la clé finale de signature, votre keystore ne sert que pour la signature d’upload. Si vous perdez votre keystore d’upload, Google peut la régénérer — un filet de sécurité qui justifie largement le passage par cette option.

Uploadez le fichier app-release.aab. La console l’analyse en 2-3 minutes : compatibilité, taille, permissions déclarées, manifeste. Si tout passe, ajoutez les notes de version (texte affiché aux utilisateurs lors de la mise à jour, 500 caractères max) et soumettez pour revue.

Choisissez un déploiement progressif (rollout). Recommandé : commencer à 5 % des utilisateurs pendant 24 heures, monter à 20 % le lendemain si aucun crash anormal n’est remonté, puis 50 %, puis 100 % au bout d’une semaine. Cette progression permet d’arrêter le rollout en un clic si un bug critique apparaît.

Étape 8 — Suivre la santé de l’application

Une fois l’application en ligne, le travail commence vraiment. Play Console expose plusieurs dashboards à surveiller en continu. Vitals : taux de crash (objectif < 1,09 %), ANR rate (objectif < 0,47 %), démarrages lents — au-delà des seuils, Google déprécie la fiche dans les recherches. Avis utilisateurs : répondre dans les 48 heures aux notes ≤ 3 étoiles avec un message qui propose une solution ou une voie de contact (sans demander de modifier la note). Statistiques : installations, désinstallations, fonctionnalités utilisées.

Configurez Firebase Crashlytics pour récupérer les stack traces des crashs en quasi-temps réel — Play Console les remonte aussi mais avec un délai de 24-48 heures et des stack traces moins détaillées. Crashlytics est gratuit, s’intègre en cinq minutes, et révèle souvent des bugs invisibles en test interne.

Erreurs fréquentes au publishing

Adapter à différents profils d’éditeur

Pour un développeur indépendant publiant son premier projet, garder la simplicité : compte personnel (acceptez la phase fermée 14 jours), pas de monétisation au démarrage, déploiement à 5 % puis 100 %. Pour une PME publiant une application client, créer un compte Entreprise avec le numéro de TVA et un compte bancaire pro pour recevoir les paiements. Pour les agences ou freelances qui publient pour des clients, ne JAMAIS publier sous votre compte : créer un compte au nom du client, ajouter votre adresse e-mail en collaborateur. Sinon vous gardez le contrôle légal de l’application et c’est une source de litige garantie en cas de séparation.

Pour les applications cross-platform Flutter ou React Native, la chaîne est identique côté Android : la publication Flutter sur Play Console détaille la production du bundle depuis un projet Dart, mais les étapes Play Console (compte, fiche, rollout, vitals) sont les mêmes.

Foire aux questions

Faut-il vraiment 25 USD à payer ?
Oui, une seule fois. Apple facture 99 USD/an, Google est en comparaison une affaire pour la durée.

Mon application n’apparaît pas après publication ?
Indexation Play prend 1-4 heures après validation. Au-delà, vérifier que la fiche est bien Disponible dans ce pays dans les paramètres de distribution.

Comment migrer depuis APK vers AAB ?
Activer Play App Signing dans Play Console, uploader le bundle au lieu de l’APK lors de la prochaine release. Aucune migration côté code, juste la commande Gradle qui change.

Combien de temps pour la première revue ?
3 à 7 jours typiquement. Les revues suivantes sont plus rapides (souvent 1-2 jours) tant qu’on ne change pas la nature de l’application.

Peut-on tester sans publier en production ?
Oui via les pistes Internal, Closed et Open Testing. L’Internal Testing accepte 100 testeurs et propage en minutes ; idéal pour la pré-validation rapide.

Que faire si l’application est suspendue ?
Lire attentivement le motif, corriger, demander un re-examen via l’aide de Play Console. Si l’application est supprimée trois fois, le compte est définitivement banni.

Pour aller plus loin

L’application est en production. Le cycle suivant : itérer sur le feedback utilisateurs, monitorer Crashlytics, sortir une release par mois en moyenne. Pour reprendre le panorama complet de la stack Android native moderne (Kotlin 2.3, Compose, architecture, Jetpack), revenir au guide principal Kotlin et Jetpack Compose.

Ressources et références

• Android App Bundle — documentation officielle
• App signing — Android Studio
• Target API requirements — Google Play
• 16 KB page size support
• Aide Play Console
• bundletool — GitHub Google