--- title: "Test fermé Google Play : 12 testeurs, 14 jours, en solo" description: "Google demande une chose simple, formulée de façon intimidante : avant de pouvoir demander l'accès à la production, votre app doit avoir vécu un test fermé avec" canonical_url: "https://fr.goodbarber.com/blog/test-ferme-google-play-le-guide-pour-reussir-les-12-testeurs-pendant-14-jours-en-solo-a1444/" lang: fr date: 2026-09-11 last_updated: 2026-09-11 --- # Test fermé Google Play : 12 testeurs, 14 jours, en solo [Retour](/blog/reussir-mon-app-r13/) # Test fermé Google Play : le guide pour réussir les 12 testeurs pendant 14 jours en solo Ecrit par [Florian Luccioni](https://fr.goodbarber.com/blog/author/flo-luccioni/) le Vendredi 11 Septembre 2026 ## Depuis novembre 2023, Google impose aux nouveaux comptes développeur personnels un test fermé d'au moins 14 jours avec 12 testeurs inscrits en continu, avant d'autoriser la moindre publication en production. Quand on crée son app seul, cette règle ressemble à un mur : douze personnes, quatorze jours, et personne sous la main. Ce guide la démonte étape par étape — préparer le fichier .aab, recruter au-delà du minimum, automatiser l'accès avec un groupe Google, tenir les deux semaines sans épuiser ses proches, et répondre au questionnaire final du premier coup. ## La règle de Google, en une minute ![](https://cmsphoto.ww-cdn.com/superstatic/40142/art/grande/97993737-68226788.jpg?v=1789121019.187595) Google demande une chose simple, formulée de façon intimidante : avant de pouvoir demander l'accès à la production, votre app doit avoir vécu un test fermé avec **au minimum 12 testeurs inscrits en continu pendant au moins 14 jours**. | Question | Réponse | | -------------------------- | ----------------------------------------------------------------------------------------- | | Qui est concerné ? | Les comptes développeur **personnels** créés à partir du 13 novembre 2023 | | Qui ne l'est pas ? | Les comptes **organisation**, et les comptes personnels créés avant cette date | | Combien de testeurs ? | 12 au minimum, simultanément | | Combien de temps ? | 14 jours, consécutifs | | Ce qui casse le compteur | Un testeur qui quitte le programme. S'il revient, ses 14 jours repartent de zéro | | Ce qui débloque la suite | Le bouton « Demander l'accès à la production » dans le tableau de bord de la Play Console | | Délai de réponse de Google | Généralement 7 jours ou moins | Source : [Play Console Help — App testing requirements for new personal developer accounts](https://support.google.com/googleplay/android-developer/answer/14151465), consultée le 11 septembre 2026. Deux précisions qui évitent beaucoup d'angoisse. D'abord, le compteur suit **l'inscription des testeurs, pas vos versions** : publier une nouvelle build sur la piste fermée pendant les 14 jours ne remet rien à zéro. Ensuite, ce sont bien 12 **comptes Google** inscrits, pas 12 appareils, pas 12 avis cinq étoiles. ## Ce n'est pas un examen, c'est une case à cocher La règle est vécue comme un jugement sur la qualité de l'app. Elle n'en est pas un. Google ne vous demande pas de réussir votre lancement : il vérifie que votre app a tourné sur de vrais téléphones, entre les mains de vraies personnes, et que vous savez raconter ce qui s'est passé. Personne ne note votre taux de rétention. Le vrai coût n'est d'ailleurs pas les 14 jours. Ce sont les examens de Google qui les encadrent : jusqu'à sept jours pour valider la piste fermée avant que vos testeurs puissent installer quoi que ce soit, puis généralement sept jours ou moins pour la demande d'accès à la production, puis autant pour la version de production elle-même. **Comptez quatre à six semaines entre le premier clic et l'app publique** — et calez votre communication dessus plutôt que sur le chiffre 14. Reste l'autre façon de lire la contrainte. Douze personnes qui utilisent votre app pendant deux semaines, c'est le test utilisateur que vous n'auriez jamais organisé tout seul, et que la plupart des projets solo n'ont jamais. Vous allez apprendre où les gens se perdent sur le premier écran, quel mot de votre menu ne veut rien dire pour eux, et si votre app survit à un téléphone Android de 2019 avec 8 % de batterie. Google vous oblige à faire ce que vous auriez dû faire de toute façon. ## Étape 1 — Préparer votre fichier .aab dans GoodBarber Le format attendu par Google est l'**Android App Bundle** (`.aab`), pas l'APK. C'est la partie que la plateforme prend en charge de bout en bout. Avant de soumettre quoi que ce soit, générez et installez la **version Ad Hoc** de votre app Android sur votre propre téléphone. C'est votre dernier filet : ce que vous ne voyez pas dans l'aperçu du back-office, vous le verrez là. Ensuite, dans le back-office : **Canaux de vente > App Android > Mettre à jour**, puis « Soumettre mon application ». La page **Soumission à Google Play** s'ouvre et vous rend votre fichier `.aab` en un clic. Rangez-le quelque part d'accessible, vous allez le téléverser dans la minute. Vous n'ouvrez ni Android Studio, ni Gradle, ni ligne de commande. GoodBarber compile un binaire Android natif en Kotlin et vous le rend prêt à téléverser — c'est exactement le fichier que la Play Console attend. Un détail qui vous fera gagner du temps plus loin dans le parcours : les moteurs de compilation n'embarquent une librairie que si la fonctionnalité correspondante est activée dans votre back-office. Désactivez-la, la plateforme recompile, la librairie disparaît du binaire. La section « Sécurité des données » de la Play Console, que beaucoup de créateurs solo redoutent, porte donc sur ce que votre app fait réellement — pas sur un paquet de SDK génériques livrés d'office avec le builder. **Les six vérifications avant de créer la piste fermée** 1. **La version Ad Hoc tourne sur un vrai appareil Android.** Pas seulement dans l'aperçu. 2. **Les visuels sont prêts** : icône 512 × 512 px, image de présentation 1024 × 500 px, et 2 à 8 captures d'écran de téléphone. 3. **La fiche Play Store est remplie** : nom, description courte, description complète, catégorie, adresse e-mail de contact. 4. **La section « Contenu de l'application » est complète** : politique de confidentialité, sécurité des données, publicités, audience cible. 5. **Les pays et régions de la piste fermée sont sélectionnés** — et c'est le piège numéro un. Play Console se base sur le **pays du compte Google** du testeur, pas sur l'endroit où il se trouve. Votre cousin installé au Québec avec un compte Google canadien ne verra rien si vous n'avez coché que la France. Dans le doute, cochez tous les pays : une piste fermée n'est visible que par vos testeurs. 6. **Le canal de retour est renseigné** (une adresse e-mail ou une URL). Google le demande, et c'est par là que va arriver la matière du questionnaire final. Le tutoriel complet, écran par écran, vit dans notre centre d'aide : [Publier votre app sur Google Play avec un compte personnel](https://fr.goodbarber.com/help/shop/publier-votre-app-android-en-solo-r62/publier-votre-app-sur-google-play-avec-un-compte-personnel-a513/). ## Étape 2 — Recruter 15 à 20 testeurs quand on n'a pas de réseau Visez 15 à 20 personnes. Pas par excès de zèle : par arithmétique. Sur dix personnes qui vous disent oui, une vous donnera une adresse e-mail qui n'est pas son compte Google, une autre ne cliquera jamais sur le lien d'inscription, une troisième se désinscrira au bout de six jours en faisant le ménage dans son téléphone. Si vous partez à 12 pile, vous découvrez le problème au douzième jour et vous recommencez. Un point à comprendre avant de démarcher qui que ce soit : **vous demandez une inscription, pas une corvée**. Vos testeurs installent l'app depuis le Play Store comme n'importe quelle autre, après un clic sur un lien. Il n'y a pas de fichier à charger à la main, pas de manipulation obscure, pas de risque pour leur téléphone. Le dire dès la première phrase double le taux de oui. | Canal | Ce que ça donne | Ce qu'il faut y mettre | | --------------------------------------------------------------------------------------------------------- | -------------------------------------------- | -------------------------------------------------------------------------------------------- | | **Cercle proche** (famille, amis, collègues) | 5 à 8 inscriptions fiables en 48 h | Leur **adresse Gmail exacte**, pas leur adresse professionnelle | | **r/AndroidAppTesters** et **r/AndroidClosedTesting** sur Reddit | Le complément qui vous amène au-delà de 12 | Du test croisé : vous testez leur app, ils testent la vôtre, pendant 14 jours des deux côtés | | **Serveurs Discord et groupes Telegram de tests croisés** | Même logique, rythme plus rapide | La même rigueur : un engagement pris est un engagement tenu | | **La communauté de votre sujet** (forums no-code, groupes Facebook de votre métier, Slack professionnels) | Les retours les plus utiles du lot | Un vrai message, pas une annonce. Dites ce que fait l'app et pourquoi elle existe | | **Une page d'attente ou le lien PWA de votre app** | Une liste que vous réutiliserez au lancement | Un formulaire à un champ, et le lien vers la version web de votre app | Deux mises en garde honnêtes sur ces canaux. **r/androiddev n'est pas le bon endroit pour recruter.** C'est un forum de discussion technique, les demandes de test y sont retirées. Les communautés dédiées citées ci-dessus existent précisément parce que cette règle Google a créé le besoin. **Le test croisé remplit le compteur, pas le questionnaire.** Douze développeurs qui installent votre app pour que vous installiez la leur satisfont Google sur le nombre — mais le formulaire d'accès à la production vous demandera quels retours vous avez reçus et ce que vous avez changé. Mélangez : quelques testeurs croisés pour atteindre le seuil, quelques personnes réellement concernées par votre sujet pour avoir quelque chose à raconter. Et quand vous allez chercher ces dernières dans une communauté, apportez quelque chose avant de demander. Un message qui ne sert qu'à placer un lien se fait retirer, et c'est justice. **Le message qui obtient un oui** Court, précis, avec le coût réel annoncé. Quelque chose comme : *« Je sors une app pour [le sujet]. Google me demande 12 personnes qui l'installent et la gardent 14 jours. Concrètement : un clic sur un lien, l'installation depuis le Play Store, et vous la laissez sur votre téléphone deux semaines. Il me faut l'adresse Gmail de votre téléphone Android. Si vous l'ouvrez deux ou trois fois et que vous me dites ce qui vous agace, c'est parfait. »* Si votre offre GoodBarber inclut les apps natives, elle inclut aussi la **PWA** générée depuis la même configuration. Envoyez ce lien web avant de demander l'inscription : les gens disent beaucoup plus facilement oui à une app qu'ils ont déjà vue tourner dans leur navigateur. ## Étape 3 — Automatiser l'accès avec un groupe Google La Play Console accepte deux façons de désigner vos testeurs : une liste d'adresses e-mail, ou l'adresse d'un **groupe Google**. Choisissez le groupe, pour une raison très concrète : avec une liste, chaque nouveau testeur vous oblige à rouvrir la piste, modifier la liste et enregistrer ; avec un groupe, vous collez une adresse une seule fois dans la Play Console, et vous gérez ensuite les arrivées depuis Google Groupes. Sur trois semaines de recrutement décalé, c'est une dizaine d'allers-retours en moins. 1. Rendez-vous sur [groups.google.com](https://groups.google.com) et créez un groupe — par exemple `testeurs-monapp@googlegroups.com`. 2. Dans les paramètres d'accès, autorisez-vous à **ajouter directement des membres** : vos testeurs n'auront aucune démarche à faire de leur côté. 3. Ajoutez les adresses Gmail que vous avez collectées, au fur et à mesure. 4. Dans la Play Console, ouvrez **Tester et publier > Tests > Tests fermés**, puis l'onglet **Testeurs** de votre piste, et déclarez le groupe par son adresse e-mail. 5. Enregistrez, puis **envoyez les modifications pour examen**. **Éviter l'erreur « Application non disponible »** C'est le message que voient vos testeurs quand ils cliquent trop tôt, et c'est de loin le plus démoralisant de l'opération : vous avez fait le travail, et les dix premières personnes que vous avez sollicitées vous répondent que ça ne marche pas. **La règle tient en une phrase : on publie d'abord, on envoie le lien ensuite.** Tant que votre piste fermée affiche l'état « Brouillon », Google est encore en train de l'examiner et le lien ne mène nulle part. Attendez que l'état passe à « Test fermé » — c'est le signal, et il peut prendre jusqu'à sept jours. Si le message persiste une fois la piste publiée, la cause est presque toujours dans cette liste : - le testeur n'a pas ouvert le lien d'inscription « Join on Android » avant d'aller chercher l'app dans le Play Store ; - il est connecté au Play Store avec un **autre compte Google** que celui inscrit dans votre groupe ; - le pays de son compte Google ne fait pas partie des pays/régions cochés sur la piste ; - il vient d'être ajouté au groupe et la propagation n'est pas terminée : laissez passer quelques minutes à quelques heures. ## Étape 4 — Tenir 14 jours sans épuiser vos proches Le réflexe naturel est de relancer tous les jours. C'est le meilleur moyen de faire désinstaller votre app par les gens qui vous aiment. **Trois messages suffisent**, et chacun a un rôle différent. **Jour 0 — le lien et une seule question.** Le lien d'inscription, la marche à suivre en deux lignes, et une question précise plutôt qu'un « dites-moi ce que vous en pensez » qui n'obtient jamais de réponse. *« Sur le premier écran, qu'est-ce que vous ne comprenez pas ? »* produit dix réponses utilisables. **Jour 7 — montrez que ça bouge.** C'est le moment où l'app disparaît mentalement du téléphone de vos testeurs, et c'est là que la plateforme vous aide. Publiez du contenu neuf depuis le CMS : il arrive dans l'app immédiatement, sans nouvelle build, sans nouvel examen de Google. Accompagnez-le d'une notification push à vos testeurs. Vous venez de prouver que l'app est vivante sans avoir rien resoumis. Si vous voulez pousser une vraie mise à jour du binaire — un bug corrigé, un écran retravaillé — repassez par **Canaux de vente > App Android > Mettre à jour**, récupérez le nouveau `.aab` et déposez-le comme une nouvelle version sur la même piste fermée. Vos testeurs la reçoivent automatiquement, et, encore une fois, cela ne remet pas le compteur des 14 jours à zéro. **Jour 12 — le dernier appel.** Demandez un retour final, et surtout demandez explicitement à chacun de **rester inscrit jusqu'au jour 15**. Deux jours de marge coûtent un message et vous évitent de découvrir un désistement au moment de cliquer sur « Demander l'accès à la production ». Entre ces trois messages, tenez un journal. Une ligne par retour : la date, qui l'a dit, ce qu'il a dit, ce que vous avez changé, dans quelle version. Ce fichier n'est pas de la bureaucratie — c'est littéralement la réponse à la troisième section du questionnaire, et vous l'aurez écrite sans effort. ## Étape 5 — Réussir le questionnaire d'accès à la production Une fois les 14 jours écoulés, ouvrez le **tableau de bord** de la Play Console et cliquez sur **« Demander l'accès à la production »**. Google pose ses questions en trois blocs. **Votre test fermé.** Comment vous avez recruté vos testeurs, quel a été leur niveau d'engagement, quels retours vous avez reçus. Soyez factuel et chiffré : *« 24 personnes sollicitées, 17 inscrites, 15 encore inscrites au terme des 14 jours ; recrutées dans mon entourage professionnel et sur deux communautés de testeurs Android ; 11 ont ouvert l'app plus de trois fois. »* **Votre app.** L'audience visée, ce que l'app apporte, et une estimation du nombre d'installations attendu. Une estimation modeste et argumentée passe mieux qu'un chiffre rond sorti de nulle part. **Votre préparation à la production.** Ce que les retours ont changé, et pourquoi vous considérez l'app prête. C'est ici que votre journal paie : citez deux ou trois retours précis et le correctif qui a suivi. La checklist avant d'envoyer : - au moins 12 testeurs **encore inscrits** au moment de la demande ; - des réponses spécifiques, jamais génériques — une réponse en deux lignes vagues est le premier motif de second tour ; - des retours réels cités, pas résumés ; - au moins un changement concret attribué à un retour, avec la version qui le porte ; - aucun chiffre gonflé : n'annoncez pas 20 testeurs si vous en avez eu 15. Comptez généralement sept jours ou moins pour la réponse, envoyée par e-mail au propriétaire du compte. En cas d'approbation, direction **Tester et publier > Production** : vous créez une version, vous y ajoutez depuis la bibliothèque le dernier App Bundle utilisé en test fermé, et vous envoyez pour examen final. ## Le calendrier réaliste | Étape | Durée à prévoir | | --------------------------------------------------- | ----------------------------- | | Préparer la fiche Play Store et récupérer le `.aab` | 1 à 2 jours | | Examen Google de la piste fermée | Jusqu'à 7 jours | | Recrutement des testeurs (en parallèle de l'examen) | 3 à 7 jours | | Test fermé | 14 jours minimum | | Examen de la demande d'accès à la production | Généralement 7 jours ou moins | | Examen de la version de production | Généralement 7 jours ou moins | | **Total** | **4 à 6 semaines** | Le seul poste sur lequel vous avez la main, c'est le recrutement. Lancez-le le jour où vous envoyez la piste fermée à l'examen, pas le jour où elle est validée : les deux compteurs tournent alors en même temps. ## Questions fréquentes **Les 14 jours démarrent-ils à la soumission ou à l'inscription des testeurs ?** À l'inscription des testeurs. Il faut 12 comptes inscrits **en continu** pendant 14 jours : le jour 1 est celui où le douzième testeur est inscrit, pas celui où vous avez envoyé votre app à l'examen. **Puis-je publier une mise à jour pendant le test fermé ?** Oui, et c'est même recommandé. Vous déposez une nouvelle version sur la même piste. Le compteur porte sur l'inscription de vos testeurs, pas sur vos versions. **Est-ce 12 testeurs ou 12 appareils ?** 12 comptes Google inscrits à votre piste fermée. Une même personne avec deux téléphones reste un testeur. **Mon compte est-il concerné ?** Si c'est un compte développeur **personnel** créé à partir du 13 novembre 2023, oui. Les comptes créés avant cette date et les comptes **organisation** ne sont pas soumis à cette exigence. **Un compte organisation permet-il d'éviter la règle ?** Techniquement oui, mais ce n'est pas un raccourci : un compte organisation suppose une entité juridique enregistrée et un numéro D-U-N-S vérifié. Si vous publiez à titre personnel, la voie du test fermé reste la plus courte. Et la règle porte sur le compte, pas sur la personne qui appuie sur le bouton — déléguer la publication ne la fait pas disparaître. **La même contrainte existe-t-elle sur l'App Store ?** Non. Apple n'impose ni nombre minimum de testeurs, ni durée de test avant publication. Le parcours iOS a ses propres exigences, décrites dans notre guide [Publier votre App iOS en Solo](https://fr.goodbarber.com/help/shop/publier-votre-app-ios-en-solo-r75/). **Et si Google refuse ma demande d'accès à la production ?** Vous pouvez redemander. Reprenez les trois sections en remplaçant chaque formulation générale par un fait : un chiffre, un retour cité, un changement daté. Le refus sanctionne presque toujours une réponse trop vague, rarement l'app elle-même. **Je préfère ne pas m'en occuper. C'est possible ?** Oui : l'option [GBTC](https://fr.goodbarber.com/help/shop/deleguer-la-publication-au-service-gbtc-r80/) confie la publication à l'équipe de GoodBarber. Attention toutefois : si votre compte développeur est un compte personnel récent, l'exigence des 12 testeurs sur 14 jours reste attachée à ce compte. ## Votre version de test est à un clic La partie technique de cette histoire — compiler une app Android native, produire un `.aab` conforme, le régénérer à chaque mise à jour — est celle qui bloquait le plus de créateurs solo il y a dix ans. C'est aujourd'hui un bouton dans un back-office. Ce qui reste entre vous et le Play Store, ce sont douze personnes et quatorze jours, et vous savez maintenant comment les obtenir. **Votre projet est prêt ?** Ouvrez **Canaux de vente > App Android > Mettre à jour** dans votre dashboard GoodBarber et récupérez votre fichier `.aab`. Pas encore d'app ? [Démarrez gratuitement](https://fr.goodbarber.com/create/) — 30 jours, sans carte bancaire. ![Flo Luccioni](https://blog.goodbarber.com/_public/profile/6a/6ac86fe0c44e1457a046324ec18c6897e8e94b27-default.jpg) À propos de l'auteur[Flo Luccioni](https://fr.goodbarber.com/blog/author/flo-luccioni/)PWA Developer Je suis développeur frontend dans l’équipe Progressive Web Apps de GoodBarber, où nous construisons le moteur de rendu de notre plateforme no-code pour les navigateurs. Je travaille sur les fondations UI et les performances qui transforment l’expérience no-code de nos utilisateurs en produits web rapides, soignés et accessibles, se rapprochant du natif sur tous les appareils. [En savoir plus](https://fr.goodbarber.com/blog/author/flo-luccioni/) [![LinkedIn](https://portal.ww-cdn.com/portal_static/svg/base2021/linkedin.3ed8162e2a2b.svg)](https://www.linkedin.com/in/floluccioni/)