Google Play « Tests supplémentaires requis » : décoder l'e-mail et redemander l'accès à la production (2026)

L'e-mail Google Play « Tests supplémentaires requis pour accéder à la production Google Play » signifie que Google a refusé votre demande d'accès à la production. Ce n'est pas un avertissement pour non-respect des règles et votre application n'est pas suspendue. En revanche, cela vous coûte du temps : il vous faut un nouveau bloc de 14 jours de test fermé avant de redéposer une demande. Ce guide décrypte chaque motif mentionné dans l'e-mail, liste ce qu'il faut changer pendant ces 14 jours supplémentaires et montre comment réécrire le questionnaire pour que votre deuxième demande soit la dernière. Si vous n'avez pas encore lancé de test fermé, commencez par notre plan de test 12 testeurs, 14 jours.

Que signifie « Tests supplémentaires requis pour accéder à la production Google Play » ?

Cela signifie qu'un examinateur Google a lu votre demande d'accès à la production et a jugé que votre test fermé n'avait pas produit assez d'éléments prouvant que l'application est prête pour le public. La production et la pré-inscription restent verrouillées tant que vous n'avez pas effectué davantage de tests et redéposé une demande.

En novembre 2026, les exigences de test des applications de Google s'appliquent aux comptes de développeur personnels créés après le 13 novembre 2023. Ces comptes doivent mener « un test fermé de leur application avec au moins 12 testeurs inscrits sans interruption depuis au moins 14 jours ». Atteindre ces chiffres vous permet seulement de postuler. La demande elle-même est examinée, et Google cite deux raisons pour lesquelles des tests supplémentaires peuvent être nécessaires : « avoir moins de 12 testeurs inscrits ou un engagement insuffisant des testeurs pendant la période de test ». Google précise que l'examen « prend généralement sept jours ou moins, mais peut parfois prendre plus de temps », et le propriétaire du compte reçoit la décision par e-mail.

Que signifie chaque motif de l'e-mail de refus ?

Chaque ligne de l'e-mail désigne une lacune précise : des testeurs qui n'ont pas vraiment utilisé l'application, un test sans changement visible en réponse aux retours, ou des réponses au questionnaire trop vagues pour être évaluées. L'e-mail peut mentionner un, deux ou les trois motifs.

Les développeurs qui ont publié l'e-mail citent les mêmes motifs : « Les testeurs n'ont pas interagi avec votre application pendant votre test fermé », « Vous n'avez pas suivi les bonnes pratiques de test, ce qui peut inclure la collecte des retours des utilisateurs et leur prise en compte via des mises à jour de votre application », et des réponses sur l'application, le test fermé ou la préparation à la production jugées « incomplètes ou insuffisantes ». La consigne finale est : « Avant de postuler à nouveau, testez votre application en test fermé pendant 14 jours supplémentaires avec de vrais testeurs. » Google ne publie pas sa façon de mesurer l'engagement ; le tableau associe donc chaque motif au texte correspondant de la page d'aide de Google et à une correction.

Que faire juste après le refus ?

Laissez le test fermé actif, demandez à vos testeurs de rester inscrits et publiez une nouvelle version sur le canal fermé sous quelques jours. La page de Google indique que si vous n'êtes pas approuvé, « vous devrez peut-être continuer votre test fermé » : supprimer le test pour en lancer un nouveau revient à jeter votre base de testeurs.

1. Ne supprimez ni le canal fermé ni votre liste de testeurs. Google prévient que « si un testeur se désinscrit puis se réinscrit plus tard, les 14 jours doivent être consécutifs » : tout testeur qui part maintenant relance son propre compteur.
2. Écrivez à chaque testeur. Expliquez que le test continue pendant 14 jours de plus, qu'il doit rester inscrit et ce que vous voulez qu'il essaie lors de cette session.
3. Vérifiez le nombre de testeurs dans la Play Console. Remplacez ceux qui n'ont jamais installé l'application par des personnes qui l'utiliseront vraiment. Les amis qui installent l'application sans jamais l'ouvrir sont la cause habituelle du motif « n'ont pas interagi ».
4. Mettez en place un canal de retours unique. Google suggère un groupe de discussion ; un formulaire partagé fonctionne aussi. Quel que soit votre choix, conservez chaque message avec sa date.
5. Rédigez une liste de tâches couvrant chaque fonctionnalité principale : inscription, action centrale, paramètres, achats (avec des testeurs de licence si l'application intègre la facturation) et tous les parcours hors ligne ou liés aux notifications.
6. Publiez dès la première semaine une mise à jour sur le canal fermé qui corrige un problème signalé par un testeur, et nommez cette correction dans les notes de version. Prévoyez une deuxième mise à jour avant le jour 14.
7. Lancez le rapport de pré-lancement et corrigez les plantages et les avertissements d'accessibilité qu'il détecte.
8. Avant de repostuler, vérifiez que la classification du contenu, l'audience cible et le formulaire Sécurité des données sont exacts. Si l'application nécessite une connexion, fournissez des « identifiants de connexion valides et fonctionnels », comme le demande la page de Google.

Si votre application doit aussi relever son SDK cible avant de pouvoir être publiée, faites-le dans la même fenêtre. Notre guide sur le niveau d'API cible 36 couvre l'échéance du 1er novembre 2026.

Comment réécrire les réponses au questionnaire d'accès à la production ?

Remplacez les affirmations générales par des détails : quelles fonctionnalités les testeurs ont utilisées, combien de signalements vous avez reçus, comment vous les avez recueillis, quelle version a corrigé quoi et quels éléments prouvaient la stabilité de l'application. Chaque réponse doit être quelque chose que seul un développeur ayant mené un vrai test pourrait écrire.

Vous ouvrez le formulaire depuis le Tableau de bord de la Play Console avec Demander l'accès à la production. Il comporte trois parties : votre test fermé, votre application et votre préparation à la production. Votre progression est perdue si vous quittez une partie avant de cliquer sur Suivant ; rédigez donc d'abord vos réponses dans un document. Un développeur sur itch.io a signalé « une limite de 300 caractères par réponse », une raison de plus de rédiger et raccourcir à l'avance. Les réponses de la partie 2 ne sont pas rendues publiques et n'affectent pas la visibilité de votre application.

Exemple concret pour une application fictive de suivi d'habitudes. Les réponses faibles sont typiques des demandes renvoyées avec la mention « incomplètes ou insuffisantes » :

Qu'ont rapporté d'autres développeurs après un refus « tests supplémentaires » ?

Les témoignages publics suivent un même schéma : des testeurs inscrits mais qui n'ont jamais envoyé de retours ont mené au refus, tandis qu'un petit groupe qui a envoyé des retours et vu l'application évoluer a été approuvé. Le nombre de testeurs comptait moins que la preuve d'utilisation.

• Sur la communauté MIT App Inventor, le développeur shigeki_suzuki a rapporté en juillet 2024 que son application Season Clock avait atteint 20 testeurs pendant 14 jours grâce à une application d'échange de testeurs, avant de recevoir « Tests supplémentaires requis pour accéder à la production Google Play » avec « Les testeurs n'ont pas interagi avec votre application pendant votre test fermé ». Il a écrit qu'il ne savait pas qui étaient les testeurs et n'avait reçu aucun retour, si bien qu'il ne pouvait décrire ni le déroulement des tests ni ce qui avait changé. Il a dû refaire le test.
• Sur le forum Adalo, l'utilisateur siang32195 a signalé le même message « Tests supplémentaires requis » en août 2024 après avoir fait appel à des testeurs recrutés. Il demandait comment vérifier que les testeurs avaient réellement utilisé l'application. La réponse suggérait des outils de suivi du temps ou un rapport écrit listant les scénarios de test couverts par chaque testeur. Le fil ne précise pas si la deuxième demande a abouti.
• Un développeur de jeux indépendant écrivant sur itch.io n'avait « à peine 12 testeurs », mais a écrit avoir « fait plusieurs mises à jour du jeu » et avoir « consigné tout ce que je pouvais de mes échanges avec mes testeurs ». Il a utilisé ce registre dans sa demande et a rapporté : « Moins de 36 heures après avoir envoyé la demande, j'ai obtenu l'accès à la production. »

La comparaison : 20 testeurs sans trace de retours ont été refusés, tandis que 12 testeurs avec un historique documenté de retours et de mises à jour ont été approuvés. Repostulez lorsque vos notes permettent de répondre à chaque champ du questionnaire avec des détails précis, et non dès que le compteur atteint 14 jours.

Quand cliquer à nouveau sur Demander l'accès à la production ?

Repostulez une fois qu'au moins 12 testeurs sont restés inscrits pendant 14 nouveaux jours consécutifs et que vous avez publié des mises à jour issues des retours pendant cette période. La page de Google ne mentionne aucun délai d'attente, mais postuler avec les mêmes éléments risque fort de vous valoir la même réponse.

• Au moins 12 testeurs inscrits, sans interruption due à une désinscription, pendant 14 nouveaux jours consécutifs (visez 15 ou plus pour avoir une marge)
• Au moins deux versions publiées sur le canal fermé depuis le refus, chacune avec des notes de version mentionnant une correction signalée par un testeur
• Un journal daté des retours, avec des totaux par type (bugs, UX, demandes) et la façon dont chaque élément a été recueilli
• Des testeurs ayant utilisé chaque fonctionnalité principale, y compris la connexion, les achats et les notifications le cas échéant
• Un rapport de pré-lancement sans plantage non résolu
• Une classification du contenu, une audience cible et un formulaire Sécurité des données exacts, ainsi que des identifiants de connexion fonctionnels pour l'examinateur
• Des réponses au questionnaire rédigées dans un document, avec fonctionnalités, chiffres et numéros de version

La page de Google prévient aussi que « soumettre des applications non conformes en comptant sur les examinateurs pour identifier les problèmes entraîne des refus, des retards d'examen et des procédures de recours plus longues » : corrigez donc tout problème de règles avant de postuler, pas après. Si vous préférez confier à quelqu'un d'autre la configuration de la Play Console, le plan de test fermé et la demande, notre service de soumission sur les stores couvre les deux stores pour $599. Les frais de compte développeur sont en sus.