Flutter & développement mobile
Publier une application sur Google Play : du compte à la validation
Pour publier sur Google Play, ouvrez un compte Play Console (25 dollars US, une fois), envoyez un fichier AAB qui cible Android 16, remplissez le formulaire Data safety et soumettez l’application. Un compte personnel créé après le 13 novembre 2023 doit d’abord mener un test fermé de 14 jours avec 12 testeurs : comptez trois à quatre semaines.
Publier une application sur Google Play n’est plus une simple formalité de fin de projet. Un compte personnel récent doit d’abord mener un test fermé de 14 jours, le format AAB est obligatoire, le niveau d’API cible monte chaque année et le formulaire Data safety engage votre responsabilité. Chez AppliWin, je publie les applications Flutter de mes clients sur les deux stores dans le cadre de mes projets de développement d’application iOS et Android : voici le parcours réel, étape par étape, avec les délais à intégrer dans votre planning.
Ce guide suppose que l’application est prête techniquement. Si vous hésitez encore sur la technologie, commencez par mon comparatif Flutter ou React Native.
Play Console : ouvrir et vérifier son compte développeur
Pour publier sur Google Play, il faut ouvrir un compte développeur Google Play dans la Play Console : 25 dollars US payés une seule fois, une vérification d’identité obligatoire et, pour une entreprise, un numéro D-U-N-S. Choisissez le type de compte dès le départ : un compte organisation échappe au test fermé imposé aux comptes personnels récents.
Google propose deux types de compte. Le compte personnel convient à un indépendant qui publie en son nom. Le compte organisation s’adresse aux sociétés, associations et collectivités : il exige des informations d’entreprise vérifiées, dont le numéro D-U-N-S, délivré gratuitement par Dun & Bradstreet mais dont l’obtention peut prendre plusieurs jours, voire quelques semaines. Anticipez-le dès le cadrage.
| Critère | Compte personnel | Compte organisation |
|---|---|---|
| Frais d’inscription | 25 dollars US, une seule fois | 25 dollars US, une seule fois |
| Vérification | Identité, adresse, e-mail, téléphone | Données de la structure + numéro D-U-N-S |
| Test fermé avant production | Obligatoire si le compte a été créé après le 13 novembre 2023 | Non exigé |
| Nom affiché sur la fiche | Le nom de développeur choisi | Le nom de la structure vérifiée |
| Profil conseillé | Indépendant, projet personnel | Entreprise cliente, association, marque |
Un principe que je recommande toujours : le compte doit appartenir au client, pas au développeur. C’est lui qui possède l’application, ses avis et ses statistiques. Le développeur y est invité comme utilisateur, avec les seules permissions nécessaires, et perd l’accès en deux clics à la fin de la mission.
Test fermé : 12 testeurs pendant 14 jours
Si votre compte personnel a été créé après le 13 novembre 2023, Google exige un test fermé avec au moins 12 testeurs inscrits sans interruption pendant les 14 derniers jours avant de demander l’accès à la production. Vous remplissez ensuite un questionnaire sur ce test, examiné en général en sept jours au plus.
Le seuil était de 20 testeurs jusqu’en décembre 2024 ; il est descendu à 12. La règle porte sur la continuité : un testeur qui se désinscrit casse la série, et le compteur de 14 jours repart dès que vous passez sous 12 personnes inscrites. Tant que la condition n’est pas remplie, la Play Console laisse la piste de production désactivée. La règle est décrite dans l’aide de la Play Console : exigences de test pour les nouveaux comptes personnels.
Recruter et garder 12 vrais testeurs pour le test fermé Google Play
- Constituez une liste de 15 à 20 personnes pour garder une marge : collaborateurs, clients fidèles, proches équipés d’Android.
- Gérez les invitations par un groupe Google ou une liste d’adresses Gmail, puis partagez le lien d’inscription au test.
- Demandez une utilisation réelle : ouvrir l’app plusieurs fois, parcourir les écrans clés, signaler les bugs.
- Publiez au moins une mise à jour pendant le test, en corrigeant ce que les testeurs ont remonté.
- Méfiez-vous des services de « testeurs à vendre » : un engagement artificiel se repère, et Google peut exiger un nouveau test.
Le questionnaire d’accès à la production
À l’issue des 14 jours, la Play Console vous pose une série de questions : comment vous avez recruté les testeurs, quels retours vous avez reçus, ce que vous avez modifié, pourquoi l’application est prête. Répondez précisément, avec des exemples concrets de corrections. Google peut accepter, refuser ou demander un test plus long.
Test interne
Premier envoi de l’AAB, contrôles techniques sur quelques appareils.
Test fermé
Ouverture à 12 testeurs minimum, collecte des retours, mise à jour corrective.
Demande d’accès
Questionnaire sur le test, examen par Google.
Production
Envoi de la version publique et examen de la fiche.
AAB, signature et API cible : les exigences techniques
Google Play n’accepte plus d’APK pour une nouvelle application : depuis août 2021, il faut un Android App Bundle (AAB) avec la signature d’application Play. Le niveau d’API cible exigé est relevé chaque année fin août : depuis le 31 août 2026, toute nouvelle app ou mise à jour doit cibler Android 16 (API 36).
Avec Flutter, la commande flutter build appbundle produit le fichier .aab. Google en tire ensuite des APK optimisés pour chaque appareil, ce qui réduit la taille téléchargée. Deux clés entrent en jeu : la clé de signature de l’application, conservée par Google, et la clé d’importation, que vous gardez. Perdre la clé d’importation n’est plus fatal, car sa réinitialisation se demande depuis la Play Console (Intégrité de l’application), mais la procédure retarde vos mises à jour de quelques jours. Google publie le calendrier des exigences de niveau d’API cible, et avait annoncé l’obligation du format AAB sur le blog Android Developers.
| Exigence | Ce que Google demande | Côté Flutter |
|---|---|---|
| Format | Android App Bundle (.aab) pour toute nouvelle application | flutter build appbundle |
| Signature | Signature d’application Play + clé d’importation | Keystore d’importation sauvegardé hors du dépôt de code |
| Version | versionCode strictement croissant à chaque envoi | Numéro placé après le « + » dans pubspec.yaml |
| API cible | Relevée chaque année fin août : API 36 pour toute nouvelle app ou mise à jour depuis le 31 août 2026 ; API 35 au minimum pour qu’une app existante reste proposée aux nouveaux utilisateurs | targetSdkVersion à jour, SDK Flutter récent |
| Pages mémoire de 16 Ko | Exigées depuis le 1er novembre 2025 pour les apps qui ciblent Android 15 ou plus | Version récente de Flutter, plugins natifs mis à jour |
Le relèvement annuel de l’API cible explique pourquoi une application n’est jamais « finie » : sans mise à jour, elle cesse d’être proposée aux nouveaux utilisateurs des versions récentes d’Android, et vous ne pouvez plus publier de correctif. C’est l’un des postes de la maintenance d’une application mobile, à prévoir dès le budget initial.
Data safety et contenu de l’application : les déclarations obligatoires
Avant la première revue, la Play Console exige plusieurs déclarations : le formulaire Data safety (données collectées, partagées, chiffrées, supprimables), une politique de confidentialité en ligne, la classification du contenu, le public cible, la présence de publicités et un accès de test pour l’examinateur. Une déclaration inexacte expose à un refus ou à un retrait.
Le piège classique du formulaire Data safety de Google Play : oublier les données collectées par les bibliothèques tierces. Firebase Cloud Messaging pour les notifications, un outil d’analyse ou de rapport de plantage, un module de paiement : chacun collecte quelque chose, et c’est à vous de le déclarer. Pour une application comme LSF-CFB, qui combine comptes utilisateurs, paiement Stripe, lecture vidéo en streaming et stockage sécurisé sur le téléphone, ce formulaire se remplit à partir de la liste exacte des SDK intégrés, jamais de mémoire.
- Politique de confidentialité publiée à une URL publique, propre à l’application.
- Formulaire Data safety cohérent avec le code et les SDK réellement intégrés.
- Suppression de compte : si l’app permet d’en créer un, un parcours de suppression dans l’app et une page web dédiée.
- Accès à l’application : identifiants de démonstration pour l’examinateur si une connexion est requise.
- Classification du contenu (questionnaire IARC), public cible et déclaration des publicités.
- Autorisations sensibles (localisation en arrière-plan, SMS, contacts) justifiées par une fonctionnalité visible.
La fiche Play Store
Côté vitrine, prévoyez un titre de 30 caractères maximum, une description courte de 80 caractères, une description longue jusqu’à 4 000 caractères, une icône de 512 × 512 pixels, une image de présentation de 1 024 × 500 pixels et des captures d’écran soignées. La fiche se travaille comme une page de vente : c’est elle qui transforme une visite en installation.
Combien de temps pour être publié sur Google Play ?
Une mise à jour d’un compte établi passe souvent en quelques heures à deux jours. Une première publication peut demander jusqu’à sept jours d’examen, parfois davantage pour une app sensible. Pour un compte personnel récent, ajoutez les 14 jours de test fermé et l’examen de la demande d’accès : trois à quatre semaines au total est une hypothèse réaliste.
La plupart des retards ne viennent pas de Google mais d’un refus évitable, qui renvoie au début de la file d’attente. Les causes se répètent d’un projet à l’autre.
| Cause de refus | Parade |
|---|---|
| Data safety incohérent avec les SDK intégrés | Inventaire des bibliothèques et de leurs données avant de remplir le formulaire |
| Politique de confidentialité absente ou générique | Page dédiée à l’application, qui cite les données et les sous-traitants |
| Examinateur bloqué à l’écran de connexion | Compte de démonstration renseigné dans « Accès à l’application » |
| Autorisation sensible non justifiée | Retirer l’autorisation ou montrer la fonctionnalité qui en dépend |
| Fiche trompeuse (captures, promesses, mots-clés) | Captures réelles, texte factuel, aucune liste de mots-clés |
| Suppression de compte introuvable | Bouton dans les réglages + lien web déclaré dans la console |
Google Play et App Store : un code Flutter, deux procédures
Avec Flutter, un seul code produit l’application Android et l’application iOS, mais chaque store garde sa procédure. Apple facture 99 € par an, passe par TestFlight et App Store Connect, et examine chaque version selon ses propres règles. Je mène les deux publications en parallèle pour viser une sortie simultanée sur les deux stores.
Le parcours Apple fait l’objet d’un guide à part : publier sur l’App Store, de TestFlight à la validation. Retenez que la revue d’Apple se montre plus exigeante sur le design et la valeur ajoutée de l’app, celle de Google sur les déclarations de données et le test fermé. Dans les deux cas, un back-office commun et un seul code réduisent le travail de mise à jour : une correction profite aux deux plateformes.
À retenir
Choisissez le type de compte avant tout développement, lancez le test fermé pendant la recette, remplissez Data safety à partir de la liste réelle des SDK et prévoyez la mise à jour annuelle de l’API cible. Pour un compte personnel récent, comptez trois à quatre semaines entre le premier envoi et la mise en production.
Questions fréquentes sur la publication Google Play
Combien coûte la publication d’une application sur Google Play ?
L’inscription à la Play Console coûte 25 dollars US, payés une seule fois, sans renouvellement annuel, contrairement à Apple (99 € par an). La publication elle-même est gratuite. Si vous vendez des contenus numériques ou des abonnements dans l’app, Google prélève en plus une commission sur ces ventes ; son barème a évolué, notamment dans l’Espace économique européen, donc vérifiez la grille en vigueur dans la Play Console avant de fixer vos prix. Le vrai coût reste le développement et la maintenance.
Comment trouver 12 testeurs pour Google Play ?
Commencez par votre cercle professionnel : collaborateurs, clients fidèles, partenaires, proches équipés d’un téléphone Android. Chaque testeur a besoin d’un compte Google ; vous l’ajoutez à une liste d’adresses ou à un groupe Google, puis vous lui envoyez le lien d’inscription au test. Visez 15 à 20 personnes : sous le seuil de 12 inscrits, le compteur de 14 jours repart de zéro. Demandez-leur d’ouvrir réellement l’application et de vous signaler les bugs, car vos réponses au questionnaire d’accès à la production s’appuient sur ces retours. Évitez les services qui vendent des testeurs : un engagement artificiel peut vous valoir un refus.
Peut-on publier sur Google Play sans test fermé ?
Oui, si l’application est publiée depuis un compte organisation, ou depuis un compte personnel créé avant le 13 novembre 2023. C’est une raison de plus pour ouvrir le compte au nom de l’entreprise, avec son numéro D-U-N-S. Même sans obligation, un test fermé reste une bonne pratique : il fait remonter les bugs propres à certains modèles Android, très nombreux sur le marché, avant les premiers avis publics.
Peut-on encore publier un fichier APK sur Google Play ?
Non pour une nouvelle application : depuis août 2021, Google Play exige le format Android App Bundle (.aab) et la signature d’application Play. L’APK reste utile pour installer une version de test directement sur un téléphone ou pour d’autres boutiques, pas pour une nouvelle fiche Google Play. Avec Flutter, passer de l’un à l’autre ne demande qu’une commande de compilation différente.
Faut-il une entreprise pour publier une application sur Google Play ?
Non, un particulier ou un indépendant peut ouvrir un compte personnel. Pour une application professionnelle, le compte organisation reste préférable : nom de la structure affiché sur la fiche, propriété claire de l’application, pas de test fermé obligatoire. Il demande un numéro D-U-N-S, gratuit, à anticiper car son obtention prend parfois plusieurs semaines.
Publier sans mauvaise surprise
Publier une application sur Google Play se prépare comme un lancement : compte au bon nom, test fermé planifié, AAB signé, API cible à jour, déclarations exactes et fiche soignée. Rien de tout cela n’est difficile, mais chaque oubli coûte une semaine. Si vous préparez une application iOS et Android et cherchez un développeur qui prend en charge la publication sur les deux stores, décrivez votre projet : le cadrage est gratuit.