Test fermé Google Play pour les apps Flutter

Flutter ne change rien à la règle de Google. Si votre compte Play Console est un compte personnel créé après le 13 novembre 2023, vous devez mener un test fermé avec au moins 12 testeurs inscrits pendant 14 jours sans interruption avant de pouvoir demander l'accès production (Aide Play Console). Ce que Flutter change, c'est le chemin : d'où vient le SDK cible, comment se règlent les codes de version, et quelques bugs propres au build release que les testeurs trouvent avant vous.

Cette page traite du côté Flutter. Pour la règle complète et chaque écran de la Play Console, commencez par le guide du test fermé Google Play.

Étape 1 : fixez l'identifiant d'application avant le premier envoi

Ouvrez android/app/build.gradle.kts (ou build.gradle dans les projets plus anciens). Le modèle est livré avec applicationId = "com.example.[project]". Remplacez-le dès maintenant par votre propre identifiant en nom de domaine inversé.

Deux raisons :

• La documentation Flutter est claire : une fois l'app envoyée sur le Play Store, vous ne pouvez plus changer l'identifiant d'application (doc Flutter). Google dit la même chose du nom du package après le premier envoi (Aide Play Console).
• Quand vous créez une app dans la Play Console, Google associe ce nom de package à votre compte pour la vérification des développeurs Android. Si un autre développeur utilise déjà ce nom, la Play Console vous demande d'en choisir un autre (Android Developers).

Si vous changez applicationId, changez aussi namespace et déplacez MainActivity.kt dans le dossier correspondant, avec la ligne package correspondante. La documentation Flutter mentionne cette étape parce que le build casse sans elle.

Étape 2 : vérifiez le SDK cible (API 36)

Depuis le 31 août 2026, les nouvelles apps et les mises à jour doivent cibler Android 16 (niveau d'API 36) ou une version ultérieure. Les apps Wear OS et Android Automotive OS doivent cibler l'API 35, les apps Android TV et Android XR l'API 34 (Aide Play Console).

Dans un projet Flutter, regardez defaultConfig :

minSdk = flutter.minSdkVersion
targetSdk = flutter.targetSdkVersion

Les valeurs qui commencent par flutter. viennent du plugin Gradle Flutter du SDK avec lequel vous compilez. Sur la branche stable vérifiée le 8 novembre 2026 (Flutter 3.47), le plugin fixe targetSdkVersion = 36, compileSdkVersion = 36 et minSdkVersion = 24 (code source Flutter).

Deux cas à surveiller :

• Vous voyez un nombre écrit en dur. La documentation Flutter indique qu'on peut remplacer les variables par des entiers pour figer les versions. Ce blocage survit aux mises à jour de Flutter. S'il indique 34 ou 35, la Play Console refusera le bundle. Passez à 36 et testez.
• Vous voyez flutter.targetSdkVersion mais compilez avec un vieux Flutter. Lancez flutter --version. La valeur suit votre SDK, pas la date. Mettez Flutter à jour, puis recompilez.

Le guide de l'API cible 36 détaille les changements de comportement à tester après la mise à niveau.

Étape 3 : signez avec une clé d'importation, et mettez-la à l'abri

Le guide Flutter détaille la marche à suivre (doc Flutter) :

1. Créez un keystore d'importation avec keytool (la commande est dans la documentation ; flutter doctor -v indique où se trouve Java si keytool n'est pas dans votre path).
2. Créez android/key.properties avec le mot de passe du keystore, le mot de passe de la clé, l'alias et le chemin du fichier.
3. Chargez-le dans build.gradle.kts et ajoutez une configuration de signature release. Utilisez-la dans buildTypes.release.
4. Lancez flutter clean si la signature semble ignorée.

Ne commitez jamais le keystore ni key.properties.

Avec la Signature d'application Play, Google détient la clé de signature d'application et vous détenez la clé d'importation. Si vous perdez la clé d'importation, Google peut la réinitialiser (Aide Play Console). Si vous gérez vous-même la clé de signature d'application et que vous la perdez, elle ne peut pas être réinitialisée.

La vérification des développeurs alourdit l'enjeu. Enregistrer un package peut exiger la preuve que vous possédez sa clé de signature privée, et la FAQ de Google précise que si vous perdez votre clé de signature, vous ne pourrez pas enregistrer vos packages (FAQ Android Developers). Sauvegardez le keystore et les deux mots de passe ailleurs que sur votre ordinateur portable. Le guide de la vérification des développeurs explique ce que cela change pour les apps que vous distribuez aussi hors de Google Play.

Firebase et Google Sign-In. Comme Google signe l'APK final, vous devez enregistrer auprès de vos fournisseurs d'API l'empreinte de la clé de signature d'application détenue par Google, et pas seulement votre clé d'importation locale (Aide Play Console). Copiez le SHA-1 ou le SHA-256 depuis la Play Console (Protégé avec Play > Distribution sur le Play Store > Accéder à la signature d'application Play, section « Clé de signature d'application ») dans Firebase. Si vous sautez cette étape, la connexion peut marcher sur votre machine et échouer pour chaque testeur qui a installé l'app depuis Google Play.

Étape 4 : les codes de version viennent de pubspec.yaml

Flutter lit version: 1.0.0+1 dans pubspec.yaml. La partie avant le + devient versionName, le nombre après devient versionCode. Vous pouvez remplacer les deux avec --build-name et --build-number (doc Flutter).

versionCode doit augmenter à chaque version, jusqu'à un maximum de 2 100 000 000 (Aide Play Console). Vous publierez des correctifs pendant les 14 jours, ce que Google recommande : augmentez +N à chaque fois. Un simple +1, +2, +3 suffit.

Étape 5 : vérifiez le manifeste et les autorisations

Deux vérifications propres à Flutter dans android/app/src/main/AndroidManifest.xml :

• INTERNET. La documentation Flutter précise que le modèle standard n'inclut pas android.permission.INTERNET mais autorise le réseau pendant le développement. Ajoutez la balise si votre app parle à un serveur, quel qu'il soit. Sans elle, un build release peut afficher des listes vides ou des indicateurs de chargement qui tournent sans fin, et vos testeurs signalent une app cassée.
• Libellé. Donnez à android:label le vrai nom de l'app. Les testeurs le voient sur leur écran d'accueil.

Les plugins fusionnent leurs propres autorisations dans le manifeste final. Si un plugin apporte une autorisation sensible ou à haut risque (SMS, journal d'appels), la Play Console affiche un formulaire de déclaration des autorisations pendant la publication de la version. Google évalue aussi les demandes d'autorisation sur les canaux de test, et une autorisation non déclarée sur une version fermée active peut vous empêcher de publier des modifications (Aide Play Console). Vérifiez le manifeste fusionné dans Android Studio avant l'envoi.

Étape 6 : compilez et testez le bundle release

flutter build appbundle

Le bundle arrive dans build/app/outputs/bundle/release/. Par défaut, il contient le code pour armeabi-v7a, arm64-v8a et x86-64 (doc Flutter).

La réduction de code R8 est toujours active dans les builds release de Flutter. Les problèmes de réduction et d'obscurcissement n'apparaissent qu'en release : lancez flutter run --release sur un vrai téléphone avant l'envoi. Testez la connexion, les paiements, les notifications push et tout ce qui, dans un plugin, utilise la réflexion.

Vous pouvez aussi vérifier le bundle sur le canal de test interne. Réservez ce canal à vos propres comptes : Google indique qu'un utilisateur inscrit à votre test interne ne peut plus recevoir votre test fermé (Aide Play Console).

Étape 7 : publiez sur la piste de test fermé

Dans la Play Console, allez dans Tester et publier > Tests > Tests fermés, puis Gérer le canal. Créez une version, importez le .aab, ajoutez les testeurs dans l'onglet Testeurs (listes d'adresses e-mail ou groupe Google), choisissez les pays, et envoyez les modifications pour examen.

Le lien d'inscription (opt-in) n'apparaît qu'une fois l'app à l'état « Publiée », et la première fois, il peut mettre plusieurs heures à fonctionner (Aide Play Console). Le guide de configuration pas à pas couvre chaque écran.

Ce que rencontrent les testeurs avec les builds Flutter

• « Your device isn't compatible with this version. » (Votre appareil n'est pas compatible avec cette version.) Le minSdk par défaut de Flutter est 24 (Android 7). Un plugin qui relève minSdk écarte sans bruit les téléphones plus anciens. Consultez le catalogue d'appareils de la Play Console après l'envoi.
• Écrans de connexion. Si votre app exige un compte, donnez aux testeurs des identifiants qui fonctionnent, et remplissez la section Accès aux applications de la Play Console pour que les examinateurs de Google puissent entrer (Aide Play Console).
• Versions périmées. Google indique que les modifications faites après la première publication peuvent aussi mettre plusieurs heures à atteindre les testeurs (Aide Play Console). Attendez avant de recueillir des retours sur un correctif, et augmentez le numéro de build pour que les testeurs distinguent les versions.

Combien de temps ça prend vraiment

• Premier build release signé à partir d'un projet Flutter qui marche : prévoyez un après-midi (keystore, Gradle, un passage complet en release sur un téléphone).
• Première version fermée : l'examen des nouveaux comptes par Google peut prendre jusqu'à sept jours, davantage dans des cas exceptionnels (Aide Play Console). Ensuite, le lien peut mettre plusieurs heures.
• Le test lui-même : 14 jours sans interruption avec au moins 12 testeurs inscrits.
• L'examen de l'accès production : généralement une semaine ou moins, parfois plus (Aide Play Console).

Comptez trois à quatre semaines entre votre premier envoi en test fermé et une publication en production. L'essentiel, c'est de l'attente : profitez des 14 jours pour corriger ce que signalent les testeurs et publier des mises à jour.