Quand votre test fermé a compté au moins 12 testeurs inscrits pendant 14 jours d’affilée, le Tableau de bord de la Play Console débloque Demander l’accès en production (Apply for production). Un clic ouvre un court formulaire. Il ressemble à une formalité, mais c’est l’étape où un réviseur humain décide si votre test était réel et si l’app est prête, et des réponses faibles sont une raison fréquente pour laquelle on demande aux développeurs de continuer à tester.
Ce guide passe en revue les questions, ce que chacune demande vraiment et comment y répondre avec des éléments précis. Google ajuste la formulation de temps en temps : considérez les intitulés ci-dessous comme une paraphrase fidèle plutôt qu’une copie exacte.
Avant de faire votre demande
Les bonnes réponses s’écrivent à partir de notes, pas de mémoire ; notre plan jour par jour pour le test de 14 jours indique quoi noter au fil de l’eau. Avant d’ouvrir le formulaire, rassemblez :
- Comment vous avez recruté les testeurs, et combien vous en avez invité par rapport au nombre d’inscrits.
- Ce que les testeurs ont fait : quelles fonctionnalités ils ont utilisées et à peu près à quelle fréquence.
- Chaque retour reçu et sa provenance (e-mail de commentaires, formulaire, chat, rapports de bugs).
- Les mises à jour publiées pendant le test, avec les numéros de version et ce que chacune a changé.
- Les chiffres de plantages et d’ANR d’Android vitals, et tout ce que le rapport de prélancement a signalé.
Partie 1 : votre test fermé
Dans quelle mesure a-t-il été facile de recruter des testeurs pour votre app ?
C’est une question à choix multiples, de « très facile » à « très difficile ». Il n’y a pas de bonne réponse : choisissez la réponse honnête. Certains formulaires vous demandent ensuite de décrire comment vous avez recruté, alors soyez prêt à citer vos canaux : amis et collègues, une communauté de développeurs, votre propre liste de diffusion ou un service de test.
Décrivez l’engagement des testeurs pendant votre test fermé
Les réviseurs veulent la preuve que les testeurs ont utilisé l’app, et pas seulement qu’ils se sont inscrits. Décrivez quelles fonctionnalités ont été utilisées, à quelle fréquence, sur quels types d’appareils, et tout ce qui vous a marqué dans vos statistiques ou vos vitals.
Une réponse faible : « Les testeurs ont utilisé l’app et l’ont aimée. »
Une réponse plus solide, pour une app de suivi d’habitudes prise en exemple : « 15 testeurs se sont inscrits et 14 sont restés pendant tout le test. La plupart ouvraient l’app chaque jour pour noter leurs habitudes ; les écrans de rappels et de séries étaient les plus utilisés. Les testeurs avaient des téléphones de cinq fabricants, sous Android 10 à 15, dont deux tablettes. Android vitals a enregistré deux plantages la première semaine, tous deux sous Android 10, que nous avons corrigés dans la version 1.0.2. »
Résumez les retours reçus et la façon dont vous les avez recueillis
Citez les canaux, puis regroupez les retours par thèmes. Mentionnez les retours positifs comme négatifs : un test où personne n’a rien trouvé à améliorer est moins crédible qu’un test avec quelques vrais problèmes.
Exemple : « Nous avons recueilli les retours via l’e-mail de commentaires du canal de test et un court formulaire mis en lien dans les notes de version. Les testeurs ont signalé que les rappels ne se déclenchaient plus après un redémarrage du téléphone, que le thème sombre avait un texte peu contrasté sur l’écran de statistiques, et ont demandé un récapitulatif hebdomadaire. Ils ont trouvé la prise en main claire. »
Partie 2 : votre app ou votre jeu
À qui s’adresse votre app ?
Soyez précis sur le public visé et la raison. « Tout le monde » n’est pas un public. Exemple : « Des adultes qui veulent prendre de petites habitudes quotidiennes, comme boire de l’eau ou lire, et qui préfèrent une app simple, sans compte ni fonctionnalités sociales. »
Décrivez ce que votre app apporte aux utilisateurs
Expliquez le problème et comment l’app le résout, en deux ou trois phrases. Montrez ce qui en fait plus qu’une simple coquille autour d’un site web ou d’un modèle, car les apps aux fonctionnalités minimales posent un problème au regard des règles de Google Play.
Combien d’installations prévoyez-vous la première année ?
Vous choisissez une fourchette. Prenez-en une réaliste, en fonction de vos projets marketing. Exagérer n’apporte rien, et une estimation modeste est tout à fait normale pour une première app.
Partie 3 : préparation à la production
Quelles modifications avez-vous apportées à votre app d’après ce que vous avez appris pendant le test fermé ?
C’est souvent la réponse la plus importante. Google veut voir que le test a fait évoluer l’app. Listez des changements concrets avec les numéros de version, et reliez chacun au retour ou aux données qui l’ont motivé.
Exemple : « La version 1.0.2 a corrigé les deux plantages sous Android 10 repérés dans les vitals. La version 1.0.3 reprogramme les rappels après un redémarrage de l’appareil et augmente le contraste du texte en thème sombre, deux points signalés par les testeurs. Nous avons aussi ajouté un écran de récapitulatif hebdomadaire, demandé par plusieurs testeurs. »
Si vous n’avez publié aucune mise à jour pendant le test, vous n’aurez presque rien à écrire ici. C’est pourquoi nous recommandons au moins une mise à jour pendant chaque test fermé, même petite.
Comment avez-vous déterminé que votre app était prête pour la production ?
Donnez des critères, pas des impressions. Par exemple : aucun rapport de plantage ouvert la dernière semaine, tous les bugs signalés corrigés ou volontairement planifiés, les parcours principaux testés sur plusieurs versions d’Android et tailles d’écran, et une fiche Play Store et des informations de sécurité des données complètes.
À faire et à éviter
| À faire | À éviter |
|---|---|
| Donner des chiffres : testeurs, jours, versions, appareils | Répondre en une seule ligne |
| Mentionner les vrais problèmes trouvés et corrigés | Prétendre que les testeurs n’ont rien trouvé du tout |
| Décrire comment les retours ont été recueillis | Coller la même réponse générique dans chaque champ |
| Garder des réponses cohérentes avec les données de la Play Console | Inventer un engagement ou des retours qui n’ont pas eu lieu |
| Réutiliser vos notes pour l’app suivante | Copier un modèle de réponse sans l’adapter |
L’honnêteté compte ici. Google voit votre canal de test, le nombre de testeurs et les vitals, et des réponses qui ne correspondent pas aux données ne convainquent pas.
Après l’envoi
Google indique examiner généralement les demandes sous 7 jours, mais cela peut prendre plus longtemps. Vous recevrez un e-mail et un message dans la Play Console. Si vous êtes approuvé, vous pouvez créer une release de production, idéalement avec un déploiement progressif. Sinon, le message explique qu’il faut tester davantage et que vous pourrez refaire une demande plus tard ; notre guide que faire quand l’accès en production est refusé détaille la suite.
Pendant l’attente, résistez à l’envie de modifier votre fiche Play Store ou vos déclarations, sauf si quelque chose est faux. Les réviseurs comparent ce que vous avez écrit avec ce qu’ils voient, et un ensemble cohérent est plus facile à approuver. Si vous remarquez une erreur dans vos réponses après l’envoi, notez la correction pour pouvoir l’utiliser si vous devez refaire une demande.
Laissez votre test fermé tourner pendant l’attente. Si des testeurs décrochent pendant l’examen, vous aurez peut-être moins à montrer si Google demande de tester davantage.
Rendez les réponses faciles à écrire
Les meilleures réponses viennent d’un test qui a produit de quoi raconter : une utilisation régulière, quelques bugs, des retours et une ou deux mises à jour. Si vous préparez votre test maintenant, lisez comment configurer un test fermé et où trouver 12 testeurs.
Avec TesterBie, de vrais téléphones Android utilisent votre app chaque jour pendant 14 jours, les plantages et les écrans cassés sont signalés avec le modèle du téléphone, la version d’Android et une capture d’écran, et le tableau de bord conserve un journal d’activité quotidien. À la fin, vous recevez un rapport et des conseils pour ces questions, afin que vos réponses reposent sur ce qui s’est réellement passé. Voir les formules.
Questions fréquentes
Dois-je répondre aux questions d’accès en production en anglais ?
Google n’exige pas l’anglais, mais un anglais clair reste le choix le plus sûr, car n’importe quel réviseur peut le lire facilement.
Puis-je utiliser un modèle de réponse trouvé en ligne ?
Servez-vous des modèles uniquement pour la structure. Les réviseurs voient beaucoup de réponses identiques : parlez de vos propres testeurs, retours et changements, et gardez des détails cohérents avec les données de votre Play Console.
Combien de temps Google met-il à examiner une demande d’accès en production ?
Google indique que l’examen prend généralement 7 jours ou moins, même si certains prennent plus de temps. Vous êtes prévenu par e-mail et dans la Play Console.
Que se passe-t-il si ma demande est refusée ?
Google vous indique qu’il faut tester davantage. Laissez le test fermé tourner avec au moins 12 testeurs engagés, publiez des améliorations et refaites une demande quand la Play Console le permet, avec des réponses plus précises.