Commencer
← Blog

Exigences

Questionnaire d'accès en production : comment y répondre (exemples question par question)

Quand vous demandez l'accès en production à la fin du test fermé, vous devez répondre à des questions sur votre test. Une personne lit et évalue vos réponses : des réponses trop sommaires mènent au refus. Nous passons en revue les trois parties du questionnaire de Google, question par question, en comparant réponses faibles et bonnes réponses pour vous montrer quoi écrire.

Dernière vérification : 20 sept. 2026.

1. Ce que le questionnaire évalue

Une fois les 14 jours de test fermé effectués, vous pouvez demander l'accès en production dans la Play Console. Vous devez alors répondre à des questions sur votre test fermé, et vos réponses sont lues et examinées par une personne chez Google. L'examen prend généralement 7 jours au maximum.

Une seule chose compte : Google vérifie si le test a réellement eu lieu, et pas seulement pour la forme. Une phrase comme “Le test s'est bien passé” n'apporte aucune information et constitue donc une réponse faible ; une réponse solide explique ce que vous avez observé et ce que vous avez corrigé.

Les questions sont présentées d'après l'article du Centre d'aide Play Console. Google retouche régulièrement les libellés de l'écran : la formulation peut donc légèrement différer.

2. Étape 1 : votre test fermé

Cette étape porte sur le déroulement du test. Elle comporte quatre questions.

A-t-il été difficile de recruter des testeurs ?

C'est une question sur la difficulté : il n'y a pas de bonne réponse. Répondez honnêtement et ajoutez une phrase sur la façon dont vous les avez trouvés, cela suffit.

Réponse trop faible

Non. C'était facile.

Bonne réponse

Ce n'était pas facile. Mes proches et les communautés ne suffisaient pas : j'ai aussi fait appel à un service de test sur appareils réels pour réunir plus de 12 testeurs.

Les testeurs ont-ils utilisé toutes les fonctionnalités de l'application ?

Plutôt que d'affirmer que tout a été utilisé, précisez jusqu'où les vérifications sont allées : c'est plus crédible. S'il y a des fonctionnalités qui n'ont pas pu être testées, expliquez aussi pourquoi.

Réponse trop faible

Oui, toutes les fonctionnalités ont été utilisées.

Bonne réponse

Du premier lancement aux écrans principaux (accueil, liste et détail, utilisables sans connexion), tout a été vérifié sur tous les appareils. Le paiement et les notifications push nécessitant un vrai compte, je les ai vérifiés uniquement avec mon compte développeur.

L'utilisation des testeurs ressemblait-elle à celle de vrais utilisateurs ?

Réponse trop faible

Oui, elle était similaire.

Bonne réponse

Les testeurs lançaient l'application chaque jour après l'installation et vérifiaient l'arrivée sur l'écran d'accueil : la durée d'utilisation diffère donc de celle de vrais utilisateurs qui l'ouvrent plusieurs fois par jour et longtemps. En revanche, j'ai vérifié à plusieurs reprises que le premier lancement fonctionnait sur des appareils de différents fabricants et versions d'Android.

Quels retours avez-vous recueillis, et comment ?

C'est la question la plus importante. Distinguez la méthode de collecte et le contenu recueilli.

Réponse trop faible

Les testeurs ont dit que l'application fonctionnait bien.

Bonne réponse

J'ai vérifié les journaux d'exécution par appareil et les captures d'écran des lancements, et consigné le code d'erreur et le modèle d'appareil de chaque exécution en échec. J'ai découvert sur 2 appareils sous Android 11 que l'écran de demande d'autorisation passait en arrière-plan au premier lancement.

3. Étape 2 : votre application

Ces questions portent sur l'application elle-même : audience cible, proposition de valeur et nombre d'installations prévu la première année. Elles sont sans rapport avec le test : écrivez des faits plutôt que des formules marketing.

  • Audience cible : soyez précis, par exemple “actifs de 20 à 39 ans qui ont du mal à se lever le matin”. Évitez “tous les utilisateurs”.
  • Proposition de valeur : ce qui vous distingue des applications concurrentes, en une phrase. Plutôt qu'une liste de fonctionnalités, dites “ce que l'application fait à la place de l'utilisateur”.
  • Installations prévues la première année : répondez par une fourchette. Mieux vaut ne pas exagérer : un chiffre élevé sans justification fait douter de votre niveau de préparation.

4. Étape 3 : préparation à la production

On vous demande comment vous avez intégré à l'application ce que le test vous a appris. C'est la question qui fait le plus souvent la différence pour l'approbation.

Réponse trop faible

J'ai corrigé des bugs et stabilisé l'application.

Bonne réponse

J'ai publié trois mises à jour pendant le test. La 1.0.3 corrige le problème d'écran d'autorisation masqué sous Android 11 ; avec la 1.0.4, j'ai raccourci l'écran de démarrage après avoir constaté que le premier chargement était long ; la 1.0.5 réduit la consommation de mémoire sur les appareils d'entrée de gamme.

Avec les numéros de version et ce qui a été corrigé, l'examinateur peut vérifier. C'est pourquoi publier une mise à jour tous les 3 à 4 jours pendant le test vous aide énormément à rédiger cette réponse.

5. Ce qu'il faut réunir avant de répondre

Répondre de mémoire donne des réponses vagues. Réunissez d'abord les cinq éléments ci-dessous : vous pourrez ensuite les reprendre directement pour chaque question.

  1. Les dates de début et de fin du test, et le nombre d'appareils sur lesquels l'application est restée installée
  2. La liste des versions publiées pendant le test et ce qui a changé dans chacune
  3. Les appareils sur lesquels une exécution a échoué, avec l'erreur et la version d'Android
  4. Des captures d'écran du premier lancement (pour montrer que la demande d'autorisation et l'accueil s'affichent correctement)
  5. Les fonctionnalités que vous n'avez pas pu vérifier, et pourquoi
Avec DUIRE, ces cinq éléments sont consignés automatiquement. À la fin des 14 jours, nous réunissons la période de test, le nombre d'appareils, l'historique des mises à jour et les journaux d'exécution par appareil dans un rapport de test final, que vous pouvez télécharger en PDF et utiliser directement comme base.

6. Les réponses à éviter

  • Inventer des retours qui n'ont pas eu lieu. Si vous écrivez des phrases invérifiables comme “Les 12 testeurs ont trouvé l'interface pratique”, c'est votre compte, et pas seulement l'application, qui sera en danger en cas de problème.
  • Répondre “Oui” à toutes les questions. Une réponse selon laquelle il n'y a eu aucune difficulté donne plutôt l'impression que le test n'a pas eu lieu.
  • Soumettre un modèle copié tel quel. Quand les mêmes phrases reviennent pour plusieurs applications, l'examinateur le remarque.
  • Remplir avec une liste de fonctionnalités. Ce qu'on vous demande, ce n'est pas une liste de fonctionnalités, mais ce que le test vous a appris.

Questions fréquentes

Puis-je faire appel à un service qui remplit le questionnaire à ma place ?
Nous le déconseillons. Soumettre des expériences de testeurs inventées revient à fournir de fausses informations à Google, et en cas de problème, c'est votre compte développeur, et pas seulement l'application, qui est en danger. Rédiger vous-même vos réponses à partir de ce qui s'est réellement passé est plus sûr, et vous avez aussi plus de chances d'être approuvé.
Faut-il répondre en anglais ?
Vous pouvez répondre en français. Mais des phrases longues et vagues passent mal : mieux vaut rester concis, en privilégiant les chiffres et les faits concrets.
Mes testeurs ne m'ont donné aucun retour. Que dois-je écrire ?
N'inventez pas de retours que vous n'avez pas reçus : décrivez ce que vous avez réellement fait. Par exemple, les erreurs constatées lors des exécutions sur chaque appareil, les journaux de plantage ou la version d'Android des appareils où l'installation a échoué : les faits observés pendant le test sont une base tout à fait suffisante.
Quelle longueur doivent avoir les réponses ?
La précision compte plus que la longueur. 3 à 5 phrases par question suffisent ; l'important est d'y inclure des chiffres (nombre d'appareils, durée, nombre de versions) et les modifications réellement apportées.
En cas de refus, faut-il tout recommencer ?
Cela dépend du motif du refus. Si le questionnaire était insuffisant, vous pouvez le compléter et refaire une demande ; mais si le test lui-même ne remplissait pas l'exigence, vous devrez peut-être poursuivre le test fermé.

Remplir l'exigence sans recruter de testeurs

DUIRE rejoint votre test fermé avec de vrais appareils Android et lance votre application chaque jour pendant 14 jours. L'enregistrement de l'application et la vérification d'installabilité sont gratuits.