Réponse rapide
« Tests supplémentaires requis » est le résultat d’une demande d’accès en production, pas une sanction liée aux règles visant votre application. Google examine le test fermé (closed testing) que vous avez mené et les réponses que vous avez données, puis écrit par e-mail au propriétaire du compte. Si l’examen ne conclut pas favorablement, il vous est demandé de poursuivre les tests. Commencez par déterminer quelle décision vous avez reçue, puis ce que vos propres relevés établissent sur l’éligibilité, l’utilisation de l’application, les commentaires et la préparation.
Si votre application ou votre version a été refusée pour un problème précis, suivez plutôt les instructions de correction et de nouvelle soumission propres à ce problème. Ajouter des testeurs ne lève pas une décision liée aux règles.
Cet article est le diagnostic: quelle décision vous avez reçue, ce que chaque élément de preuve établit ou non, et ce qu’il faut corriger avant de refaire une demande. Il s’appuie sur les tests fermés que PrimeTestLab mène chaque semaine et sur les instructions de Google, dont les liens figurent au fil du texte. À jour au 11 septembre 2026.
Comment lire cet article
- Exigence de Google Une condition obligatoire d’éligibilité, de soumission ou de règles.
- Conseil de Google Google le recommande, ou la demande pose la question. Aucun seuil n’est publié.
- Notre suggestion Une pratique de terrain, issue des tests que nous menons, et non une règle sur laquelle vous êtes évalué.
Sur cette page
Commencez par identifier ce que Google a refusé
Trois décisions différentes sont toutes appelées « refus du test fermé », et chacune demande un travail différent. Partez de la formulation exacte que vous avez reçue.
Quel message avez-vous reçu?
| Ce que vous avez reçu | Ce que cela signifie | Que faire ensuite |
|---|---|---|
| Le tableau de bord indique une éligibilité aux tests incomplète | Le tableau de bord signale une condition de test non remplie. Vérifiez la condition précise affichée avant de décider ce qu’il faut poursuivre. | Terminez le test fermé: au moins 12 testeurs, chacun inscrit pendant les 14 derniers jours consécutifs. |
| « Tests supplémentaires requis » après la demande | Votre demande a été examinée et n’est pas encore acceptée. Google vous demande de poursuivre les tests; la décision et l’e-mail adressé au propriétaire du compte précisent les points relevés. | Passez en revue les cinq points ci-dessous, corrigez ce que vous trouvez, puis refaites votre demande depuis votre compte. |
| Application ou version refusée pour un problème précis | Une décision qui porte sur l’application elle-même et qui nomme un problème de règles ou de qualité. Ce n’est pas un jugement sur votre nombre de testeurs. | Suivez les instructions de correction et de nouvelle soumission propres au problème nommé. Ajouter des testeurs n’y changera rien. |
Un canal Production verrouillé ne dit pas à lui seul si ce qui reste en attente est l’éligibilité aux tests, une décision sur votre demande ou une autre étape liée au compte. Orientez-vous avec le message précis que vous avez reçu, pas avec le verrou.
Sources: exigences de test des applications et accès en production, et publication et état de l’examen.
Vérifiez que l’exigence s’applique à vous
Exigence de GoogleL’exigence s’applique aux comptes de développeur personnels créés après le 13 novembre 2023. Google indique que ces comptes doivent remplir des exigences de test précises avant qu’une application puisse être publiée. Si le vôtre est concerné, trois étapes s’enchaînent dans cet ordre:
- 1Menez un test fermé, et pas seulement un test interne.
- 2Maintenez au moins 12 testeurs inscrits pendant 14 jours consécutifs.
- 3Demandez l’accès en production et répondez aux questions sur le test, l’application et la préparation.
L’éligibilité n’est pas une approbation
Remplir l’exigence vous rend éligible à la demande. Celle-ci est examinée séparément: 14 jours sans accroc marquent donc le début du processus, et non sa fin. Tous les détails: comment fonctionne l’exigence de testeurs.
Diagnostiquez le problème en cinq minutes
Ouvrez la Play Console à côté de cette liste et répondez honnêtement à chaque question. Tout ce à quoi vous ne pouvez pas répondre indique par où commencer votre lecture.
Ce que cet outil fait et ne fait pas
Cet outil ne lit rien dans votre compte Play Console et ne peut pas confirmer votre nombre de testeurs ni vos dates d’inscription. Il ne fait que remettre ce que vous savez déjà dans l’ordre où l’examen l’aborde.
Étape suivante
Suivez le guide pour refaire une demande pour les étapes qui suivent une décision de tests supplémentaires. Si votre diagnostic montre qu’il vous faut davantage de tests humains, comparez nos offres de test. Si Google a signalé un problème lié à l’application ou à une règle, corrigez-le d’abord: un nouveau groupe de testeurs ne le résoudra pas.
Cinq points à vérifier après un refus d’accès en production
Des points à examiner, dans l’ordre où vous pouvez les examiner. Ils ne sont pas classés selon la fréquence à laquelle ils entraînent un refus, car aucune donnée publiée n’établit ce classement.
L’éligibilité ou la continuité des testeurs est incomplète
Google demande un minimum de 12 testeurs inscrits depuis au moins les 14 derniers jours sans interruption. La continuité s’apprécie testeur par testeur: une personne qui s’inscrit, teste moins de 14 jours puis se désinscrit ne compte pas pour cette période interrompue. Un testeur qui revient peut de nouveau remplir la condition après une nouvelle période d’inscription de 14 jours sans interruption.
À vérifier
- Vérifiez que vous êtes bien sur le canal fermé. Un testeur encore inscrit à un test interne doit le quitter avant que votre test fermé ne lui parvienne.
- Comptez les personnes qui se sont inscrites, pas les adresses que vous avez ajoutées à une liste. Ajouter une adresse ne produit aucun effet tant que la personne n’a pas accepté le lien.
- Demandez à vos testeurs de rester inscrits jusqu’au moment où vous demandez l’accès en production, et pas seulement pendant les 14 jours qui précèdent.
Exemple: la continuité s’apprécie testeur par testeur
Si 15 testeurs se sont inscrits ensemble et que l’un s’en va, les 14 restants peuvent tout de même remplir la condition, car chacun a conservé sa propre période ininterrompue. Un remplaçant qui arrive plus tard démarre son propre compteur et n’hérite pas du temps déjà écoulé du testeur parti.
Gardez une petite marge au-dessus du minimum. Exactement 12 testeurs suffisent: la marge relève de notre pratique, pour absorber une désinscription sans que le décompte passe sous la barre, et non d’une exigence de Google.
Sources: exigences de test pour les nouveaux comptes de développeur personnels, et configurer un test ouvert, fermé ou interne pour les listes de testeurs et les liens d’inscription. Guides pratiques: vérifier les invitations et l’inscription des testeurs et test interne ou test fermé.
Les testeurs n’ont pas réellement utilisé l’application
La demande vous interroge sur l’utilisation des fonctionnalités par les testeurs et sur la ressemblance entre cet usage et celui que vous attendez en production. Google indique aussi qu’il peut vous être demandé de poursuivre les tests lorsque les testeurs ne se sont pas montrés actifs. Les instructions consultées ne fixent aucun seuil chiffré d’engagement: le travail consiste donc à décrire un usage réel.
Trois chiffres qui ne mesurent pas la même chose
| Indicateur | Ce qu’il mesure | Ce que cet indicateur établit |
|---|---|---|
| Testeurs inscrits | Les personnes qui ont accepté le lien d’inscription à votre canal fermé et qui sont restées inscrites. | Le chiffre de l’éligibilité, et le seul des trois lié à la règle des 12 testeurs et des 14 jours. |
| Audience installée | Les utilisateurs qui ont votre application installée sur au moins un appareil dont ils se sont servis au cours des 30 derniers jours. | L’application est arrivée sur un appareil en service. Cela n’établit pas que quelqu’un l’a ouverte. |
| Utilisateurs actifs quotidiens | Les personnes qui ont ouvert l’application un jour donné. | Des ouvertures ont eu lieu. Cela ne dit toujours pas quelles fonctionnalités ont été utilisées, ni ce que les testeurs en ont pensé. |
Source: consulter les statistiques de l’application. Google dispose bien de données d’utilisation: l’engagement ne lui est donc pas invisible. Ce qui n’est pas documenté, c’est quels signaux l’examen prend en compte, et à quel niveau.
À vérifier
- Donnez à vos testeurs une consigne courte qui nomme les parcours à tester, et un seul canal pour répondre.
- Demandez des observations précises, pas un verdict: ce qu’ils ont essayé, sur quel appareil, ce qui s’est passé.
- Demandez à vos testeurs de revenir sur une correction importante dès qu’elle est livrée, pour que votre relevé montre une modification effectivement vérifiée.
Demandez à vos testeurs d’accomplir les tâches qui comptent pour votre application, de rapporter ce qu’ils constatent avec leurs propres mots et de revenir sur les corrections importantes une fois celles-ci livrées. Une consigne fixe comme « ouvrir l’application une fois par jour » est une routine de test facultative, pas une règle de Google.
Les commentaires et les réponses de la demande manquent d’éléments précis
Le formulaire vous demande de résumer les commentaires reçus et les modifications apportées. Google recommande de consigner au fil du test les thèmes qui ressortent des commentaires, et ce relevé fait toute la différence entre une réponse précise et une réponse vague.
Exemple de relevé de test (la structure, pas un contenu à recopier)
| Build, parcours, environnement | Constat | Action ou vérification |
|---|---|---|
| Build 8; réinitialisation du mot de passe; Android 14 | Le message de nouvelle tentative manquait de clarté | Clarifié dans le build 9; le testeur a revérifié |
| Build 9; paramètres enregistrés; Android 13 | Les paramètres ont été conservés après réouverture | Consigné comme réussi; aucune modification nécessaire |
Il s’agit d’un format de relevé suggéré, pas d’un modèle ni d’une pièce jointe exigés par Google. Servez-vous des colonnes pour la structure; ne reprenez jamais les lignes comme des faits à recopier. Consigner une vérification réussie compte autant que consigner un problème: c’est ce qui vous permet de répondre à la question de la préparation sans inventer de défaut.
À vérifier
- Utilisez la section des commentaires de test dans la Play Console, ainsi que tout canal que vous avez donné à vos testeurs. Les notes publiques du Play Store n’entrent pas dans ce cadre.
- Regroupez d’abord les commentaires par thèmes, pour qu’un signalement isolé mais bruyant ne devienne pas tout le résumé.
- Conservez l’observation précise, que vous citiez le testeur ou que vous la résumiez fidèlement.
- Vérifiez que les fonctionnalités décrites dans votre demande étaient présentes dans le build testé et qu’elles ont bien été utilisées. Signalez tout ce qui a été testé séparément ou laissé en dehors de ce test.
Sources: configurer un test ouvert, fermé ou interne et instructions sur l’accès en production. Un modèle de relevé réutilisable figure dans notre article sur la reprise après un refus, et préparer des réponses exactes pour l’accès en production parcourt le formulaire lui-même.
Les constats n’ont pas été traités ou la préparation n’est pas claire
La demande vous interroge sur ce que vous avez changé à partir de ce que vous avez appris, et Google recommande d’agir sur les commentaires pendant le test. Aucun quota de versions n’apparaît dans les instructions consultées: ce qui compte, c’est que votre réponse reflète ce que le test a établi.
Que répondre quand rien n’avait besoin d’être changé
Si le test n’a fait ressortir aucun problème à corriger, décrivez les parcours vérifiés, les appareils sur lesquels ils ont été exécutés et les résultats obtenus, puis expliquez votre décision sur la préparation à partir de ce relevé. Inventer un problème, ou publier une version cosmétique pour avoir une modification à signaler, affaiblit la réponse.
À vérifier
- Traitez d’abord les constats réels, et indiquez quel build a porté chaque correction.
- Rattachez chaque modification au commentaire qui l’a motivée, pour que la réponse se lise comme une cause et son effet.
- Si un problème important reste ouvert, réglez-le avant de présenter l’application comme prête.
Là où cette réponse pèche
La réponse faible dit que le test s’est bien passé. La réponse solide nomme ce qui a été vérifié, ce qui a été trouvé, ce qui a été fait et comment le résultat a été confirmé. Une réponse précise est plus facile à évaluer.
Des problèmes d’accès, de stabilité ou de fonctionnement subsistent
Google n’autorise pas les applications qui plantent, se figent ou ne fonctionnent pas normalement d’une autre manière. L’examen doit lui aussi pouvoir accéder à l’application: dès qu’un élément se trouve derrière une connexion, des identifiants fonctionnels et des instructions accompagnent la version.
À vérifier
- Fournissez des identifiants de connexion fonctionnels pour l’examen, ainsi que les étapes nécessaires pour atteindre les fonctionnalités restreintes, pour le build que vous avez soumis.
- Vérifiez que vos testeurs peuvent installer et ouvrir ce build. Toute personne encore inscrite à un test interne doit d’abord le quitter.
- Lancez un rapport pré-lancement, puis examinez les signaux de plantage et d’ANR pour les parcours utilisés par vos testeurs, et corrigez ce qui est reproductible.
Ce qu’un rapport sans erreur ne prouve pas
Les rapports pré-lancement s’exécutent automatiquement lorsque la capacité le permet. Des identifiants ou une configuration personnalisée peuvent être nécessaires pour atteindre les contenus protégés et tester les parcours concernés. Un résultat automatisé sans erreur ne remplace pas non plus un test manuel. Android vitals s’appuie sur des données de diagnostic transmises volontairement par une partie seulement des appareils et des versions du système d’exploitation: une vue indisponible peut donc refléter trop peu de points de données à l’intérieur des filtres que vous avez sélectionnés. Les seuils de mauvais comportement publiés par Android vitals concernent la qualité technique, pas une note de passage pour l’accès en production.
Sources: fonctionnalités, contenu et expérience utilisateur, préparer votre application pour l’examen, utiliser un rapport pré-lancement pour repérer les problèmes, et surveiller la qualité technique avec Android vitals.
Ce que chaque élément de preuve établit, et ce qu’il n’établit pas
Savoir à quelle question répond chaque élément, c’est ce qui distingue un problème de testeurs d’un problème de preuves ou d’un problème d’application.
ÉtablitSi vous étiez éligible à la demande: au moins 12 testeurs, chacun inscrit pendant les 14 derniers jours consécutifs.
N’établit pasSi l’un d’eux a utilisé l’application, ou si vos réponses étaient assez précises.
ÉtablitCombien d’utilisateurs ont ouvert l’application chaque jour affiché.
N’établit pasCombien de fois chaque personne l’a ouverte, quelles fonctionnalités elle a utilisées, ou ce qu’elle a pensé de l’expérience.
ÉtablitQue la vue sélectionnée ne contient pas assez de données pour repérer des problèmes avec les filtres actuels.
N’établit pasQue l’application n’a pas planté. Vitals s’appuie sur des données transmises volontairement par une partie seulement des appareils et des versions: une vue vide peut donc signifier que trop peu de données ont été collectées, et non qu’aucun problème n’est survenu.
ÉtablitQu’un autre développeur a rapporté cette formulation. Utile à lire pour comprendre la forme que prend la décision.
N’établit pasCe qui a été dit à votre propre compte. Les messages recopiés dans les communautés restent anecdotiques et ne peuvent pas fixer votre calendrier.
ÉtablitUne observation précise que vous pouvez traiter et décrire, dans les mots du testeur.
N’établit pasSi le problème est répandu. Un signalement est une piste; c’est la récurrence chez plusieurs testeurs qui fait le constat.
Ce qu’il faut vérifier avant de refaire une demande
Conseil de Google- 1Lisez à la fois la décision affichée dans la Play Console et l’e-mail adressé au propriétaire du compte, puis suivez les instructions fournies pour votre application.
- 2Menez à terme toute période de test supplémentaire réellement indiquée pour votre application, et laissez le canal fermé actif pendant ce temps.
- 3Continuez à régler les points signalés par la décision, puis refaites votre demande en suivant les instructions affichées dans votre compte.
Deux conclusions à ne pas tirer
L’absence de durée n’est pas une autorisation de refaire une demande immédiatement. Et une instruction de poursuivre les tests ne prouve pas que le temps déjà écoulé de chaque testeur a été effacé: les instructions publiques consultées ne précisent aucune règle universelle de remise à zéro. Considérez donc ces deux points comme inconnus jusqu’à ce que votre propre compte indique le contraire.
Google décrit l’examen qui suit comme prenant généralement sept jours ou moins, tout en précisant qu’il peut parfois être plus long. Il s’agit de l’examen, pas des tests qui le précèdent. Pas à pas: comment refaire une demande après une décision « Tests supplémentaires requis ».
Source: les étapes suivantes pour l’accès en production.
Comment maintenir l’engagement des testeurs
Conseil de GoogleGoogle indique que de nombreux développeurs recrutent auprès de leurs amis, de leur famille, de leurs collègues, de communautés et de réseaux sociaux, et recommande des testeurs représentatifs de vos utilisateurs cibles, assez variés pour faire apparaître les problèmes propres à certains appareils.
Le recrutement peut échouer quand la participation et les commentaires ne sont pas encadrés: un engagement de 14 jours sans aucun cadre entre en concurrence avec tout le reste de la semaine d’un bénévole. Trois problèmes de participation et de commentaires à surveiller:
Là où un groupe autogéré laisse filer la période
Source: exigences de test des applications, la page où Google parle du recrutement des testeurs. Les options sont comparées dans les moyens légitimes de trouver 12 testeurs.
Test autogéré ou test géré
Les deux voies remplissent la même exigence. La différence tient à qui surveille le décompte et relance les testeurs pour obtenir des commentaires pendant 14 jours.
| Ce dont dépend la demande | Groupe autogéré | Test géré |
|---|---|---|
| Maintenir 12 testeurs inscrits pendant 14 jours consécutifs | À vous de surveiller le décompte. Une désinscription peut retarder l’éligibilité s’il reste trop peu de testeurs remplissant la condition. | Surveillé pour vous, avec un effectif maintenu au-dessus du minimum. |
| Appareils réels | Les appareils que vos bénévoles possèdent, quels qu’ils soient. | Des appareils Android réels, d’Android 7 à Android 17. |
| Mise en route | Le temps que prend le recrutement. | Les testeurs commencent généralement dans un délai de 4 à 6 heures. |
| Des commentaires que vous pouvez résumer | Dépend entièrement de votre façon de les recueillir. | Recueillis par un seul canal, puis rapportés dans un compte rendu qui vous est remis. |
| Coût | Gratuit, plus votre propre temps pendant 14 jours. | À partir de 19,99 $US pour 12 testeurs. |
Aucune des deux voies ne change la façon dont la demande est examinée. Le test géré supprime le risque lié à la participation; il ne répond pas à votre place aux questions sur les commentaires et la préparation, et personne ne peut promettre une approbation.
Accompagnement des tests
Notre suggestionSi votre diagnostic pointe la participation, PrimeTestLab mène le test fermé pour vous: des testeurs inscrits sur appareils réels pendant les 14 jours complets, un effectif maintenu au-dessus du minimum, des commentaires rassemblés en un seul endroit. Si le manque vient d’une connexion cassée ou d’un problème de règles nommément identifié, ajouter des testeurs n’y changera rien.
Starter
12 testeurs réels
$19.99
Enterprise
25 testeurs réels
$27.99
Professional
20 testeurs réels
$29.99
Ce chiffre d’achèvement est notre propre relevé opérationnel, pas un taux d’approbation de Google: le test géré a maintenu le nombre de testeurs exigé et une période d’inscription ininterrompue jusqu’à sa date de fin.
Questions et réponses
Pourquoi Google Play affiche-t-il « Tests supplémentaires requis »?
Votre demande d’accès en production a été examinée et n’est pas encore acceptée: Google vous demande donc de poursuivre les tests. Parmi les exemples qu’il donne: ne pas avoir 12 testeurs inscrits, et des testeurs qui ne se sont pas montrés actifs pendant le test fermé. Lisez à la fois la décision affichée dans la Play Console et l’e-mail envoyé au propriétaire du compte pour connaître les points relevés.
Ai-je besoin de 12 testeurs inscrits pendant 14 jours consécutifs?
Pour un compte de développeur personnel créé après le 13 novembre 2023, oui. Google exige un test fermé avec un minimum de 12 testeurs inscrits depuis au moins les 14 derniers jours sans interruption. Exactement 12 testeurs suffisent, et les adresses invitées ne comptent pas tant que chaque personne ne s’est pas inscrite.
Un testeur s’est désinscrit pendant les 14 jours. Dois-je tout recommencer?
Pas nécessairement. La continuité se mesure testeur par testeur: toute personne qui a conservé sa propre période ininterrompue compte toujours. La période interrompue, elle, ne compte pas, mais un testeur qui revient peut de nouveau remplir la condition après une nouvelle période d’inscription de 14 jours sans interruption. Ce qui n’existe pas, c’est l’héritage: un remplaçant qui arrive plus tard démarre sa propre période au lieu de reprendre le temps déjà écoulé du testeur parti.
Que répondre si le test n’a rien révélé à corriger?
Décrivez les parcours que vous avez vérifiés, les appareils sur lesquels ils ont été exécutés et les résultats obtenus, puis expliquez votre décision sur la préparation à partir de ce relevé. Aucun quota de versions n’apparaît dans les instructions consultées, et rien n’y indique que vous devez publier une mise à jour pendant le test. Inventer un problème ne fait qu’affaiblir la réponse.
Puis-je refaire une demande immédiatement après un refus?
Refaites votre demande une fois la cause profonde corrigée, et fixez le calendrier d’après votre propre préparation. Certains messages indiquent une période supplémentaire de test fermé; d’autres demandent seulement de poursuivre les tests, sans donner de durée. L’absence de durée n’est pas une autorisation de refaire une demande immédiatement, et les instructions publiques consultées ne précisent aucune règle universelle de remise à zéro.
Combien de temps Google met-il pour examiner une demande d’accès en production?
Google décrit l’examen comme prenant généralement sept jours ou moins, et précise qu’il peut parfois être plus long. Cela ne concerne que l’examen. Le test fermé qui le précède représente 14 jours consécutifs distincts, et tout test supplémentaire demandé par votre décision s’y ajoute encore.
Votre prochaine étape
Revenez au diagnostic en cinq minutes et reprenez la première question à laquelle vous n’avez pas pu répondre. Corrigez ce point précis, consignez ce que le test a réellement établi, et refaites votre demande en suivant les instructions affichées dans votre compte. Si le manque porte sur la participation plutôt que sur les preuves, organisez vos testeurs avant la prochaine tentative pour que la période ne soit pas de nouveau interrompue en cours de test.
L’essentiel
« Tests supplémentaires requis » est une décision qui porte sur le test que vous avez mené, les réponses que vous avez données et la préparation de l’application. Le plancher est fixe et public: au moins 12 testeurs inscrits pendant 14 jours consécutifs, pour un compte de développeur personnel créé après le 13 novembre 2023. Au-delà, vos réponses doivent expliquer fidèlement ce que le test a établi. Une formulation claire ne remplace ni un test réel ni une application qui fonctionne.
Documentation officielle de Google