Réponse rapide
Rédigez vos réponses à partir de vos propres relevés de recrutement, de test, de commentaires, de modifications et de préparation. Utilisez les exemples ci-dessous comme trames de rédaction, remplacez chaque détail factuel, puis respectez la formulation et la limite de caractères affichées dans votre propre formulaire Play Console.
Le formulaire porte sur le test que vous venez de mener, sur l’application que vous avez développée et sur votre décision de la publier. Cette page parcourt chaque champ, en donne un exemple rédigé et explique quoi écrire lorsque vos preuves sont minces, qualitatives, ou n’ont donné lieu à aucune modification du code.
Qu’est-ce que le questionnaire d’accès en production ?
Lorsque votre test fermé remplit les critères, Play Console affiche « Demander l’accès à la production » sur le tableau de bord de votre application. Ce panneau liste les critères qui vous manquent encore et comporte un lien Aperçu des questions, qui vous permet de lire le formulaire avant de commencer. Google pose ses questions en trois sections :
Google décrit l’objectif de la section sur le test fermé comme la confirmation que les applications sont testées de façon satisfaisante avant publication. La section 2 est la plus légère : Google précise que ces réponses ne sont pas affichées sur Google Play et n’ont aucune incidence sur l’accès aux fonctionnalités de Play Console.
Ce que Google publie
- L’examen prend généralement 7 jours ou moins, et peut prendre plus longtemps.
- Google peut vous demander de poursuivre les tests si vous n’avez pas 12 testeurs éligibles, ou si les testeurs ne se sont pas montrés engagés avec l’application.
- Les réponses de la section 2 ne sont pas publiées et n’influent pas sur l’accès aux fonctionnalités.
- Quitter le formulaire sans le dérouler jusqu’au bout peut effacer les réponses non enregistrées : utilisez Suivant entre les sections, puis Envoyer à la fin.
Source : aide Play Console, conditions de test pour les comptes de développeur personnels.
Cette page couvre neuf questions de la demande initiale, plus une question de nouvelle demande signalée par des développeurs à qui Google avait demandé de poursuivre les tests. Google ne publie aucune liste figée : la formulation rapportée, le type de champ et les questions qui apparaissent varient d’un compte à l’autre. Suivez votre propre formulaire.
Chaque exemple de cette page fait moins de 300 caractères et affiche son propre décompte. Des développeurs signalent une limite proche de ce chiffre, mais aucune limite universelle actuelle n’a pu être vérifiée : le compteur de votre propre formulaire fait foi. Aucune preuve publiée ne relie la longueur d’une réponse au résultat.
Quelles preuves faut-il préparer ?
Faites ce travail une fois et le formulaire cesse d’être un exercice de rédaction. Réunissez ces trois éléments avant de l’ouvrir : toutes les réponses de cette page en découlent.
Les chiffres sur lesquels vous serez interrogé, relevés dans les informations d’éligibilité de Play Console et dans vos propres relevés, pour que les deux concordent avec ce que vous écrivez.
- Combien de testeurs étaient inscrits, et à quelles dates.
- Si l’inscription est restée ininterrompue pendant les 14 derniers jours, sans aucune coupure.
- Sur quelle version chaque testeur a terminé le test.
Désinstaller n’est pas quitter le test. Un testeur qui supprime l’application reste inscrit ; quitter le test est un geste délibéré, depuis le lien du test ou la section bêta de l’application dans le Play Store (quitter le programme bêta d’une application). Un nombre d’installations ne prouve donc ni que le test a eu lieu, ni qu’il s’est arrêté.
Des activités, pas des adjectifs. Notez les parcours qu’ils ont menés à bout et comment vous le savez.
- Quels parcours principaux ont été empruntés : inscription, tâche principale, partage, paramètres, paiement.
- À quelle fréquence, en gros, l’application a été ouverte, et sur quelle période.
- Là où les testeurs ont buté, et sur quels appareils ou quelles versions d’Android si vous le savez.
Indiquez la source de chaque affirmation. Un décompte fondé sur les retours des testeurs n’est pas la même chose qu’un décompte enregistré par des statistiques d’usage, même si les deux s’écrivent en chiffres. Les deux sont exploitables ; dites lequel vous avez.
Google renvoie les développeurs vers la page « Commentaires sur les tests » de Play Console et recommande d’en tenir un relevé. Une ligne par constat suffit :
- Par où le commentaire est arrivé (commentaires Play Console, formulaire intégré, groupe de discussion, e-mail).
- Ce que vous avez publié en réponse, et dans quelle version.
- Comment vous avez confirmé que cela fonctionnait, et quels constats restent ouverts.
Un relevé qui répond à quatre des neuf questions
Trois colonnes suffisent. Les lignes ci-dessous appartiennent à l’application fictive présentée dans la section suivante ; les vôtres n’y ressembleront en rien, et c’est bien l’idée.
| Ce que le test a révélé | Ce qui a été publié | Comment cela a été vérifié |
|---|---|---|
| Les rappels de service ne se déclenchaient plus après la modification d’un planning. | Version 1.4.1 : reprogrammation des rappels corrigée après modification du planning. | Les deux testeurs qui l’avaient signalé ont confirmé que les rappels arrivaient pour les deux services suivants. |
| La publication d’un planning échouait sur connexion lente et le brouillon était perdu. | Version 1.4.2 : le brouillon est conservé en local et la publication est retentée jusqu’à réussir. | Nouveau test sur connexion bridée avant et après : le brouillon a survécu. |
| La vue hebdomadaire était à l’étroit sur les petits écrans. | Non publié. Prévu après le lancement. | Ouvert. Mentionné comme point ouvert dans la réponse sur la préparation, et non présenté comme corrigé. |
Et si vous n’avez pas de statistiques détaillées ?
Si vous n’avez pas collecté de statistiques de session, vous pouvez tout de même répondre à chaque question. Ce que vous ne pouvez pas faire, c’est transformer une impression en mesure. Dites ce que vous savez et précisez comment vous le savez. « Dix testeurs sur douze m’ont dit avoir créé au moins un planning ; je n’avais pas de statistiques de session » est exploitable et vérifiable. Une durée moyenne de session inventée ne l’est pas.
Il en va de même pour le rapport pré-lancement : Google le décrit comme un test automatisé sur ses propres appareils, avec des limites de couverture (utiliser un rapport pré-lancement pour identifier les problèmes). Il atteste d’une exploration automatisée, pas d’un test humain.
Si Android vitals n’affiche aucun plantage
Un tableau de bord vide ne démontre pas l’absence de plantages. Android vitals dépend des données de diagnostic éligibles, et Google signale qu’un affichage vide peut signifier des données insuffisantes avec les filtres que vous avez choisis (Android vitals). Si les données sont minces, signalez cette limite.
Rédigez d’abord vos réponses ailleurs
Google avertit que quitter le formulaire sans cliquer sur Suivant à chaque section, puis sur Envoyer à la fin, peut faire perdre votre travail. Rédigez vos réponses dans un document, confrontez-les entre elles, puis collez-les.
Encore besoin de testeurs ?
Si vous avez terminé le test, utilisez les exemples ci-dessous pour préparer vos réponses à partir de vos propres relevés, et vérifiez chaque réponse au regard de ce qui s’est réellement passé. S’il vous faut encore des testeurs, comparez nos offres de test: PrimeTestLab fournit des réponses au questionnaire après son test, puis vous les vérifiez et envoyez la demande.
Comment utiliser ces exemples de réponses
Tous les faits de tous les exemples ci-dessous sont inventés. Ils décrivent une seule application fictive, pour montrer comment un même historique de test donne neuf réponses cohérentes. Aucun n’est une réponse prête à être envoyée pour votre application, et aucun ne le devient en étant raccourci.
Remplacez chaque nom, chiffre, date, fonctionnalité et constat par les vôtres avant de reprendre quoi que ce soit de cette page. Une réponse qui parle encore de « Shiftly », ou qui annonce douze testeurs sur quatorze jours alors que ce n’est pas ce qui s’est passé, décrit le test de quelqu’un d’autre.
Quelle variante choisir ?
Les exemples par défaut suivent tous le test fictif de Shiftly. Les autres onglets décrivent d’autres circonstances : une autre méthode de recrutement, des preuves plus minces, un autre type d’application. Choisissez celui qui correspond à votre test, puis mettez les réponses liées en accord. Une réponse « aucune modification publiée » ne peut pas voisiner avec des réponses sur les commentaires et la préparation qui annoncent des correctifs publiés, et l’onglet jeu porte sur un jeu fictif distinct.
Comment lire un exemple
- Un texte marqué ainsi est un fait que vous devez remplacer.
- Copier comme modèle remplace chacun de ces passages par une consigne entre crochets, jamais par une phrase toute faite.
- Les explications sont hors du panneau d’exemple : vous ne pouvez donc pas coller une remarque éditoriale dans le formulaire.
- Le décompte de caractères mesure l’exemple, pas le texte qui le remplacera.
Exemple illustratif, pas une application réelle
ShiftlyUne application fictive de gestion des plannings pour petits commerces et cafés, utilisée sur toute cette page uniquement pour garder les neuf réponses cohérentes. Ni un client, ni une étude de cas, et aucun résultat ne lui est attribué.
- Test fermé 12 testeurs, 14 jours sans interruption
- Parcours principaux Inscription, création d’un planning hebdomadaire, invitation d’un collègue, publication, réception d’un rappel de service
- Versions publiées pendant le test 1.4.1 et 1.4.2
- Point ouvert Vue hebdomadaire à l’étroit sur les petits écrans
Partie 1 : à propos de votre test fermé
Cette section vous demande de décrire le recrutement, l’activité et les commentaires. Gardez vos réponses cohérentes avec les informations d’éligibilité de Play Console et avec vos propres relevés de test, et expliquez les activités, les commentaires et les vérifications qu’aucun indicateur de tableau de bord ne capte.
Comment avez-vous recruté les utilisateurs de votre test fermé ?
Google demande d’où viennent vos testeurs. Nommez la source que vous avez réellement utilisée et dites qui a mené le test. Diversifier est une bonne pratique, pas une règle interdisant une source unique : un seul canal, annoncé honnêtement, vaut mieux qu’une liste inventée.
Ce que ce champ demande
- Le ou les canaux que vous avez réellement utilisés.
- Qui sont les testeurs par rapport au public de votre application.
- Qui a défini les scénarios, lu les commentaires et publié les modifications.
Exemple rédigé (fictif)
J’ai recruté 12 testeurs via mon propre réseau : cinq collègues d’un espace de coworking, quatre amis qui gèrent des plannings et trois d’un forum de test. Tous se sont inscrits en deux jours et le sont restés les 14 jours complets. J’ai défini les scénarios et lu les commentaires moi-même.
Copie indisponible. Sélectionnez et copiez le modèle ci-dessous.
Exemple rédigé (fictif)
J’ai recruté 12 testeurs via un service de test payant. J’ai choisi les scénarios, lu les commentaires dans Play Console et dans les rapports du prestataire, publié deux mises à jour pendant le test et demandé à chaque testeur concerné de confirmer le correctif.
Copie indisponible. Sélectionnez et copiez le modèle ci-dessous.
Exemple rédigé (fictif)
Mes 12 testeurs venaient tous d’une même source : un groupe de commerçants indépendants dont je fais déjà partie. Ce sont exactement les gens pour qui l’application est faite. J’ai invité chacun d’eux directement, sans publier de lien de test public.
Copie indisponible. Sélectionnez et copiez le modèle ci-dessous.
Une version plus faible, et ce qu’elle laisse de côté
« J’ai trouvé des testeurs en ligne. »
Aucun canal nommé, aucun lien avec votre public, et personne d’identifié pour avoir mené le test.
Aucune documentation publiée ne laisse entendre que nommer un prestataire influe sur le résultat. Ce qui compte, c’est que le reste de votre formulaire concorde : si un prestataire a recruté les testeurs, dites qui a défini les scénarios, lu les commentaires, effectué les modifications et les a vérifiées.
Le recrutement des testeurs a-t-il été facile ?
Une échelle allant de très difficile à très facile. Choisissez l’option qui correspond à ce que vous avez vécu. Aucune documentation publiée ne désigne d’option préférable. Les lignes ci-dessous sont des illustrations approximatives, pas des critères : le recrutement peut être difficile ou facile pour des raisons qu’aucune d’elles ne couvre.
- Très difficile Vous n’avez pas atteint 12 testeurs, et le test a pris du retard ou s’est enlisé.
- Difficile Il a fallu redemander plusieurs fois, ou multiplier les tentatives sur une longue période.
- Ni facile ni difficile Cela a demandé un peu d’effort et à peu près le temps que vous aviez prévu.
- Facile Une ou deux demandes ont suffi à remplir la liste.
- Très facile Vous aviez plus de volontaires que de places.
Aucune option n’est recommandée ici. La formulation et le nombre de choix peuvent différer de ce qui est montré ci-dessus ; lisez votre propre formulaire.
Décrivez l’engagement de vos testeurs
Les exemples donnés par Google portent ici sur l’usage des fonctionnalités et sur sa ressemblance avec un usage réel en production. « Très engagés » ne décrit rien que l’on puisse se représenter. Donnez les parcours, la période, le rythme d’usage et l’origine de vos chiffres.
Ce que ce champ demande
- Combien de testeurs, et sur quelle période.
- Deux à quatre parcours qu’ils ont réellement menés à bout, nommés.
- Le rythme d’usage, et d’où viennent les chiffres.
Exemple rédigé (fictif)
Sur 14 jours, 12 testeurs ont créé 31 plannings ; tous se sont inscrits, neuf ont invité un collègue, sept ont reçu un rappel. Les testeurs multi-boutiques l’ouvraient presque tous les jours, les autres une fois par semaine. Chiffres tirés de la journalisation d’événements.
Copie indisponible. Sélectionnez et copiez le modèle ci-dessous.
Exemple rédigé (fictif)
Je n’avais pas de statistiques de session pendant le test. Dix testeurs sur douze m’ont dit avoir créé au moins un planning hebdomadaire, et six avoir invité un collègue. J’ai vu deux testeurs s’inscrire en partage d’écran. Je ne peux pas donner de nombre de sessions.
Copie indisponible. Sélectionnez et copiez le modèle ci-dessous.
Une version plus faible, et ce qu’elle laisse de côté
« Les testeurs étaient actifs et ont utilisé l’application. »
Aucun chiffre, aucune période, aucun parcours nommé, et aucune source pour tout cela.
Résumez les commentaires que vous avez reçus
Google demande à la fois ce que disaient les commentaires et comment vous les avez recueillis. Donnez le canal, les thèmes qui sont réellement ressortis et ce que vous avez fait de chacun, y compris ce qui n’est pas fait. Faire tenir plusieurs constats dans un champ court, c’est la partie qui demande de la réécriture.
Ce que ce champ demande
- Par où les commentaires sont arrivés.
- Les thèmes qui sont réellement ressortis, quel qu’en soit le nombre.
- Ceux que vous avez corrigés et publiés, et ceux qui restent ouverts.
Exemple rédigé (fictif)
Les commentaires sont arrivés via Play Console et un groupe de discussion. Les thèmes : rappels non déclenchés après modification d’un planning, publication en échec sur connexion lente, vue hebdomadaire à l’étroit. Les deux premiers sont corrigés et publiés, le troisième reste ouvert.
Copie indisponible. Sélectionnez et copiez le modèle ci-dessous.
Une version plus faible, et ce qu’elle laisse de côté
« Les commentaires étaient positifs. »
Ni canal, ni thème, ni réponse apportée, c’est-à-dire les trois choses que le champ demande.
Si les commentaires étaient réellement tous positifs, dites-le et dites sur quoi ils portaient. Un défaut inventé devrait en plus rester cohérent avec Q8 et Q9.
Il vous manque des testeurs qui resteront inscrits 14 jours sans interruption ?
PrimeTestLab fournit 12 testeurs pré-qualifiés à partir de 19,99 $US, avec un démarrage sous de 4 à 6 heures.
Partie 2 : à propos de votre application ou de votre jeu
Google précise que ces réponses ne sont pas affichées sur Google Play et n’ont aucune incidence sur votre accès aux fonctionnalités de Play Console. Écrivez-les simplement : ce n’est pas une fiche Play Store, et il n’y a rien à gagner à faire de la vente ici.
À qui votre application s’adresse-t-elle ?
Google demande d’être précis. « Tout le monde » ne décrit personne. Dites qui sont ces personnes, quel problème elles rencontrent et à quel moment elles ouvrent l’application. Si vous avez réellement deux types d’utilisateurs, nommez les deux.
Ce que ce champ demande
- Qui elles sont : rôle, situation, ou tranche d’âge si c’est vraiment pertinent.
- Le problème qu’elles rencontrent sans votre application.
- Quand et à quelle fréquence elles l’utilisent.
Exemple rédigé (fictif)
Shiftly s’adresse aux gérants de commerces et de cafés de 3 à 20 salariés qui aujourd’hui font leurs plannings sur papier ou dans une appli de notes. Ils l’utilisent une fois par semaine pour préparer la semaine suivante, et brièvement quand quelqu’un demande à échanger un service.
Copie indisponible. Sélectionnez et copiez le modèle ci-dessous.
Une version plus faible, et ce qu’elle laisse de côté
« Tout le monde. »
Aucun utilisateur, aucun problème, aucune occasion d’usage, et c’est presque toujours faux.
Décrivez la valeur que votre application apporte aux utilisateurs
Commencez par le résultat, puis nommez les deux ou trois fonctionnalités qui le produisent. Pour un jeu, la valeur tient à l’expérience : la boucle de jeu, ce qui la rend distinctive, la durée d’une partie et ce qui donne envie d’y revenir.
Ce que ce champ demande
- Le résultat, en une phrase, avant toute liste de fonctionnalités.
- Deux ou trois fonctionnalités qui produisent ce résultat.
- Pour un jeu : la boucle, l’élément distinctif, la durée d’une partie.
Exemple rédigé (fictif)
Shiftly permet aux gérants de boutique de réutiliser le planning de la semaine passée, de publier les services et d’envoyer un rappel avant chaque service. Les employés demandent leurs échanges dans l’application plutôt que par message.
Copie indisponible. Sélectionnez et copiez le modèle ci-dessous.
Exemple rédigé (fictif)
Les joueurs vident un plateau en enchaînant des alignements de couleurs avant la fin d’un chrono de 90 secondes. Chaque plateau réussi réécrit le suivant, donc aucune partie ne se répète. Une partie dure environ trois minutes, et les joueurs reviennent pour le plateau du jour.
Copie indisponible. Sélectionnez et copiez le modèle ci-dessous.
Une version plus faible, et ce qu’elle laisse de côté
« Mon application est utile et a de bonnes fonctionnalités. »
Aucun résultat, aucune fonctionnalité, aucun utilisateur, dans un champ que Google ne publie de toute façon pas.
L’onglet Jeu est un second exemple fictif, pas Shiftly. Si vous le reprenez, le reste de vos réponses décrit votre jeu, pas une application de planning.
Combien d’installations attendez-vous la première année ?
Google indique qu’une estimation approximative suffit et que les fourchettes sont volontairement larges. Choisissez celle que soutiennent votre public et votre estimation de lancement. Aucune documentation publiée ne désigne de fourchette préférable, et rien ne fonde le conseil courant de viser une tranche médiane.
- 0 à 10 000
- 10 000 à 100 000
- 100 000 à 1 million
- 1 million et plus
- Je ne sais pas Une option à part entière, et plus défendable qu’un chiffre inventé.
Aucune option n’est recommandée ici, et aucune de ces fourchettes ne dit quoi que ce soit de votre application. Les libellés et la formulation varient ; lisez votre propre formulaire.
Partie 3 : préparation à la production
Cette section demande ce que le test a produit et pourquoi vous avez décidé de publier. Les deux réponses doivent se lire comme des conclusions tirées du relevé que vous avez constitué plus tôt, et non comme des affirmations qui apparaissent ici pour la première fois.
Quelles modifications avez-vous apportées à la suite de votre test fermé ?
Décrivez les modifications que vous avez réellement apportées et la façon dont vous les avez vérifiées. La documentation publiée n’énonce ni formule de notation pour ce champ, ni nombre minimal de mises à jour. Cela ne veut pas dire que la réponse est sans effet, et cela n’excuse pas un problème bloquant ou un manquement aux règles déjà connu. Distinguez ce qui est fait de ce qui est prévu.
Ce que ce champ demande
- Ce que le test a révélé, avec vos propres mots.
- Ce que vous avez publié en réponse, avec un numéro de version si vous en avez un.
- Comment vous l’avez vérifié, et ce qui reste ouvert.
Exemple rédigé (fictif)
Deux versions publiées pendant le test. 1.4.1 corrige la reprogrammation des rappels ; 1.4.2 corrige la publication sur connexion lente. Les testeurs qui l’avaient signalé l’ont confirmé et j’ai retesté la publication en débit bridé. La vue hebdomadaire à l’étroit reste ouverte, non corrigée.
Copie indisponible. Sélectionnez et copiez le modèle ci-dessous.
Exemple rédigé (fictif)
Aucune modification publiée pendant ce test. Les testeurs ont vérifié l’inscription sur Android 10, la publication en connexion lente, les rappels sur 3 modèles. Résultats : aucun échec signalé, aucun plantage dans Android vitals sur une période aux données suffisantes. Petits écrans non testés.
Copie indisponible. Sélectionnez et copiez le modèle ci-dessous.
Une version plus faible, et ce qu’elle laisse de côté
« Nous avons amélioré l’application. »
Aucun constat, aucune version, aucune vérification : impossible de faire concorder cette réponse avec celle sur les commentaires.
Et si vous n’avez fait aucune modification ?
La documentation ne prescrit aucun nombre de mises à jour, et une application inchangée ne rend pas automatiquement votre demande faible. Ce qui affaiblit une réponse, c’est un test que rien n’explique. Utilisez l’onglet Aucune modification publiée ci-dessus : quels parcours et quelles conditions ont été vérifiés, quels ont été les résultats et d’où ils viennent, et ce qui reste non résolu. N’inventez pas un défaut pour avoir un correctif à annoncer.
Comment avez-vous décidé que votre application était prête pour la production ?
Google demande vos critères de décision, pas votre degré de confiance. Nommez les deux ou trois éléments que vous avez regardés et la preuve qui soutient chacun. Tout ce qui figure ici devrait déjà apparaître plus haut dans le formulaire, avec le même historique de vérification.
Ce que ce champ demande
- Les critères que vous avez retenus, énoncés comme des critères.
- La preuve qui soutient chacun d’eux.
- Les points ouverts, et pourquoi ils ne bloquent pas la publication.
Exemple rédigé (fictif)
Trois critères. Le correctif des rappels a été confirmé par les testeurs concernés. J’ai retesté la publication des plannings en débit bridé après la 1.4.2. La vue hebdomadaire à l’étroit reste ouverte : c’est cosmétique, et les parcours principaux testés sont utilisables.
Copie indisponible. Sélectionnez et copiez le modèle ci-dessous.
Une version plus faible, et ce qu’elle laisse de côté
« Je sentais que l’application était prête. »
Un ressenti n’est pas un critère : il n’y a rien ici avec quoi être d’accord ou non.
Erreurs de réponse fréquentes
Aucune de ces erreurs n’est une règle publiée par Google. Ce sont les habitudes qui font qu’une réponse dit moins que ce que le développeur voulait dire.
« Très engagés », « très positifs », « testé en profondeur ». Chacun occupe de la place dans un champ court sans nommer un parcours, un chiffre ou une période.
« Aucun problème détecté » dans un champ et « j’ai corrigé plusieurs bugs » dans le suivant. Les deux ne peuvent pas être vrais, et rien ne permet au lecteur de savoir lequel l’est.
Si vous rapportez des commentaires, dites par où ils sont arrivés : commentaires sur les tests dans Play Console, formulaire intégré, groupe de discussion, e-mail. Sans cela, le résumé est sans source.
Un exemple collé qui décrit encore l’application, le public ou le bug de quelqu’un d’autre ne décrit pas votre test. Tous les modèles partagent ce défaut, y compris ceux de cette page.
Un pourcentage inventé pour faire sérieux est une affirmation que vous ne pouvez pas étayer. Un décompte issu des retours des testeurs est parfaitement exploitable : dites simplement que c’en est un.
Dites quels correctifs ont été publiés et lesquels sont programmés. Présenter un projet comme une version publiée est démenti par votre propre historique de versions.
Choisir l’option qui sonne le mieux plutôt que celle qui correspond à ce qui s’est passé met votre liste déroulante en contradiction avec votre texte libre, et aucune documentation publiée ne désigne de choix préférable.
Vérifiez vos réponses avant de les envoyer
Le formulaire se lit comme un seul document. Ce qui l’affaiblit le plus souvent n’est pas une mauvaise phrase, mais deux phrases qui se contredisent. Faites cette passe avec les neuf réponses côte à côte.
Rien dans cette liste ne prédit une décision. C’est la passe qui empêche votre formulaire de se contredire lui-même.
Que se passe-t-il après votre demande ?
Quatre issues méritent d’être distinguées, car deux d’entre elles sont régulièrement confondues. Un examen encore en cours n’est pas une demande de tests supplémentaires, et un accès accordé n’est pas une application publiée.
Suivre l’examen
Examen en coursGoogle indique que l’examen prend généralement 7 jours ou moins, et peut prendre plus longtemps. Surveillez Play Console et l’adresse e-mail du compte, et répondez à toute demande de Google. Une longue attente, à elle seule, n’est pas une raison de renvoyer le formulaire ni de relancer le test.
Encore une étape
Accès en production accordéL’accès et une application en ligne sont deux choses différentes. Vous devez encore préparer et déployer une version de production, qui fait l’objet de son propre examen. Voyez le processus de publication de Google, ainsi que nos délais d’examen de l’accès en production et des versions.
Lire le message reçu
Tests supplémentaires requisUne décision qui porte sur votre test, pas seulement sur votre formulation. Marche à suivre complète ci-dessous.
Un problème d’application, pas de formulation
L’examinateur n’a pas pu ouvrir l’applicationSi votre application est protégée par une connexion ou autrement restreinte, l’examinateur a besoin d’identifiants qui fonctionnent. Fournissez-les dans les informations de connexion pour l’examen. Aucune réponse du questionnaire ne remplace un accès.
Si Google vous demande de poursuivre les tests
Ne renvoyez pas le même formulaire et ne supposez pas que le problème venait de votre rédaction. Procédez dans cet ordre.
La notification indique généralement un motif : moins de 12 testeurs éligibles, une inscription interrompue pendant les 14 jours, ou des testeurs qui ne se sont pas montrés engagés. Ce message fait autorité avant tout guide général, y compris celui-ci.
Si vous manquiez de testeurs, ou si une inscription a été interrompue, revenez à 12 testeurs éligibles avec un historique récent sans coupure avant de refaire une demande, ce qui, pour de nouveaux testeurs, suppose 14 jours complets de plus. Réécrire des réponses par-dessus un historique de testeurs inchangé ne change rien aux informations d’éligibilité.
Mettez à jour les faits qui ont changé et clarifiez toute réponse incomplète ou ambiguë : une réponse peut échouer à transmettre des preuves que vous aviez déjà. Ce qu’une reformulation ne peut pas faire, c’est corriger un problème de test sous-jacent. Un second test peut produire de nouvelles observations, de nouveaux commentaires, des modifications ou des vérifications, mais rien n’est garanti et une nouvelle version n’est pas exigée.
Google exige que les 14 derniers jours consécutifs comptent des testeurs éligibles : ne faites donc jamais de demande si vous êtes en dessous de 12. Au-delà, certains messages de refus indiquent un délai supplémentaire et d’autres non : Google ne publie aucun délai universel avant une nouvelle demande. Notre guide pour refaire une demande après un refus « tests supplémentaires requis » couvre les deux cas, et explique pourquoi demander à vos testeurs de se désinscrire puis de revenir détruit l’historique que vous avez déjà.
Si vous cherchez ce qui a cloché dans le test lui-même plutôt que dans le formulaire, commencez par le diagnostic d’un refus de test fermé.
Qu’avez-vous fait différemment cette fois ?
Signalée par des développeurs qui refont une demande après s’être vu demander de poursuivre les tests. La formulation rapportée varie et tous les comptes ne signalent pas l’avoir vue : vérifiez votre propre formulaire plutôt que de supposer qu’elle apparaîtra ou non.
Nommez ce qui a changé dans les faits, pas ce qui a changé dans votre état d’esprit. Si le second test ressemblait au premier, c’est cela qu’il faut corriger avant de refaire une demande.
Ce que ce champ demande
- Ce qui a changé dans le test lui-même.
- Ce que cela a produit : constats, versions publiées, confirmations.
- En quoi les preuves actuelles répondent à la décision précédente.
Exemple rédigé (fictif)
Depuis la demande précédente, j’ai mené un nouveau test de 14 jours avec 12 testeurs et noté ce que chacun a fait. Deux défauts de rappel ont été trouvés, corrigés en 1.4.3 et confirmés par les testeurs qui les avaient signalés. Ces réponses décrivent ce test et ces versions.
Copie indisponible. Sélectionnez et copiez le modèle ci-dessous.
Une version plus faible, et ce qu’elle laisse de côté
« Cette fois, je me suis concentré sur la collecte et la prise en compte des commentaires. »
Cela décrit une intention, pas une différence, or la différence est la seule chose que ce champ demande.
Cet exemple relève d’un scénario ultérieur : un second test avec sa propre version, la 1.4.3. S’il correspond à votre cas, le reste de vos réponses décrit ce test récent, et non l’historique antérieur des versions 1.4.1 et 1.4.2.
Comment PrimeTestLab accompagne votre test et votre demande
Tout ce qui précède suppose que vous ayez un relevé sur lequel vous appuyer. Si le blocage, c’est justement ce relevé, autrement dit trouver 12 personnes qui restent inscrites 14 jours sans interruption, c’est cette partie-là que nous prenons en charge. De vraies personnes sur de vrais appareils, un démarrage sous de 4 à 6 heures, les 14 jours complets, et une progression que vous suivez pendant qu’elle a lieu.
Notre formule Starter fournit 12 testeurs pour 19,99 $US, la formule Professional 20 testeurs pour 29,99 $US, et la formule Enterprise 25 testeurs pour 27,99 $US, toutes avec la garantie des 14 jours complets.
L’exigence minimale, remplie exactement
Une couverture accrue sur les mêmes 14 jours
Plus d’engagement sur les mêmes 14 jours
Ce que cela vous apporte pour le formulaire
Des testeurs identifiés avec un historique d’inscription sans coupure, un relevé de ce qu’ils ont fait et leurs commentaires par écrit : la matière première de Q1, Q3, Q4 et Q8. Les réponses, c’est vous qui les écrivez, car elles doivent être les vôtres.
Ce que cela ne vous apporte pas
Nous n’envoyons pas le questionnaire à votre place, nous ne pouvons pas influencer un examen, et rien sur cette page ne prédit une décision. Si un service vous dit le contraire, c’est cette promesse qu’il faut vérifier en premier.
Comparer les formules de test fermé
Questions fréquentes
Puis-je utiliser ces exemples comme modèle ?
Comme trame, oui. Comme texte à envoyer, non. Tous les faits qu’ils contiennent appartiennent à une application fictive : une réponse qui les conserve décrit le test de quelqu’un d’autre. Remplacez chaque nom, chiffre, fonctionnalité et constat ; c’est exactement pour cela que le bouton de copie vous remet un modèle entre crochets.
Qu’est-ce que le questionnaire d’accès en production ?
C’est le formulaire que vous remplissez pour demander l’accès en production après un test fermé. Il porte sur le test que vous avez mené, sur votre application ou votre jeu, et sur votre préparation à la production. Vous y accédez depuis « Demander l’accès à la production » sur le tableau de bord de votre application dans Play Console, et vous pouvez le lire à l’avance grâce au lien Aperçu des questions.
Quelle longueur chaque réponse peut-elle faire ?
Chaque exemple de cette page fait moins de 300 caractères, et des développeurs signalent une limite proche de ce chiffre. Aucune limite universelle actuelle n’a pu être vérifiée : le compteur de votre propre formulaire fait foi. Aucune preuve publiée ne relie la longueur d’une réponse à vos chances.
Dois-je dire que j’ai fait appel à un service de test payant ?
Vous pouvez répondre honnêtement. Aucune documentation publiée ne laisse entendre que nommer un prestataire influe sur le résultat, et une liste de canaux inventée est le risque le plus grand. Nommez la source, puis dites qui a défini les scénarios, lu les commentaires, effectué les modifications et les a vérifiées.
Et si je n’ai aucune statistique pour le test ?
Si vous n’avez pas collecté de statistiques de session, rapportez ce que vous savez et précisez comment vous le savez. « Dix testeurs sur douze m’ont dit avoir terminé l’inscription » est exploitable ; une durée moyenne de session inventée ne l’est pas. Un décompte issu des retours des testeurs reste un décompte, du moment que vous le dites.
Et si je n’ai fait aucune modification pendant le test fermé ?
La documentation ne prescrit aucun nombre de mises à jour, et une application inchangée ne rend pas automatiquement votre demande faible. Ce qui affaiblit une réponse, c’est un test que rien n’explique. Dites quels parcours et quelles conditions ont été vérifiés, quels ont été les résultats et d’où ils viennent, et ce qui reste non résolu.
Combien de temps prend l’examen de l’accès en production ?
Google indique qu’il prend généralement 7 jours ou moins, et qu’il peut prendre plus longtemps. Un examen encore en cours n’est pas un refus. Surveillez Play Console et l’adresse e-mail du compte, et répondez à toute demande de Google.
Google m’a demandé de poursuivre les tests. Quand puis-je refaire une demande ?
Lisez le message que vous avez reçu : certains indiquent un délai supplémentaire précis, d’autres non, et Google ne publie aucun délai universel avant une nouvelle demande. Dans tous les cas, les 14 derniers jours consécutifs doivent compter au moins 12 testeurs éligibles. Voyez la marche à suivre ci-dessus et le guide complet tests supplémentaires requis.
L’essentiel
En bref
Rédigez chaque réponse à partir de votre propre relevé : qui a testé, ce que ces personnes ont fait, ce qu’elles ont rapporté, ce que vous avez publié et comment vous l’avez vérifié. Remplacez chaque détail inventé de cette page, choisissez dans les listes déroulantes les options qui correspondent à votre situation, suivez la formulation et le compteur de votre propre formulaire, et relisez vos réponses ensemble pour qu’elles concordent.
Si c’est le relevé qui vous manque, comparez les formules de test fermé.