Depuis novembre 2023, Google Play exige des nouveaux comptes personnels de développeur qu'ils démontrent qu'une application a été testée par de vraies personnes avant de pouvoir être publiée. La règle est simple à énoncer et facile à enfreindre : au moins 12 testeurs doivent être inscrits à un test fermé pendant 14 jours consécutifs, puis une demande d'accès à la production doit être soumise ; Google l'examine et peut la refuser. Voici comment cette exigence fonctionne en pratique et comment effectuer un test accepté dès la première fois.
À qui la règle s'applique-t-elle ?
| Compte | Test fermé obligatoire avant la production ? |
|---|---|
| Compte personnel créé après le 13 novembre 2023 | Oui, pour chaque application que vous souhaitez publier en production |
| Compte personnel créé le 13 novembre 2023 ou avant | Non |
| Compte d'organisation | Non |
L'exigence a commencé avec 20 testeurs en novembre 2023 et a été réduite à 12 le 11 décembre 2024. La période de 14 jours n'a pas changé. Si vous publiez pour une entreprise, le moyen le plus simple d'éviter cette règle consiste à publier depuis un compte d'organisation au nom de l'entreprise, ce qui est de toute façon le compte approprié pour une application professionnelle ; la configuration est expliquée dans comment publier sur Google Play en 2026.
Comment fonctionne réellement le délai de 14 jours
La formulation de Google est précise : au moins 12 testeurs doivent être inscrits à votre test fermé lorsque vous demandez l'accès à la production, et ils doivent y être inscrits sans interruption pendant les 14 jours précédents. Trois conséquences en découlent :
- Être invité ne signifie pas être inscrit. Un testeur n'est comptabilisé qu'après avoir accepté l'invitation via le lien d'inscription au test, tout en étant connecté au compte Google figurant sur votre liste. Envoyer un e-mail ne suffit pas ; vérifiez le nombre dans la Play Console.
- La continuité est importante. Un testeur qui quitte le test puis le rejoint à nouveau commence une nouvelle période continue. Si votre nombre passe sous 12 pendant la quinzaine, vous ne disposez pas de 12 testeurs ayant cumulé 14 jours consécutifs le jour de votre demande.
- Prévoyez une marge. Recrutez 15 à 20 testeurs afin que quelques désistements ne réinitialisent pas votre calendrier.
Ce que demande la demande d'accès à la production
Une fois les critères remplis, vous effectuez la demande depuis le tableau de bord de la Play Console. Le formulaire comporte trois parties :
- À propos de votre test fermé : la facilité avec laquelle vous avez recruté les testeurs, la manière dont ils ont utilisé l'application et un résumé des commentaires reçus.
- À propos de votre application : le public visé, la valeur apportée par l'application et le nombre d'installations que vous prévoyez au cours de la première année.
- À propos de votre préparation à la production : les changements apportés à la suite des tests et la manière dont vous avez déterminé que l'application était prête.
Google indique que l'examen prend généralement sept jours ou moins, mais qu'il peut durer plus longtemps. Ajoutez cette semaine à votre plan de lancement : avec le test de 14 jours, le délai minimal entre la première version fermée et la production est d'environ trois semaines.
Pourquoi les demandes sont-elles refusées ?
Lorsqu'une demande échoue, Google vous demande de poursuivre les tests. Les raisons indiquées sont un nombre inférieur à 12 testeurs inscrits ou un engagement insuffisant des testeurs. En pratique, un engagement insuffisant prend généralement l'une des formes suivantes :
- Des testeurs qui ont installé l'application une fois sans jamais la rouvrir
- Aucun commentaire, ou des commentaires génériques (« application sympa ») qui n'entraînent aucune modification
- Aucune nouvelle version pendant le test, de sorte qu'il n'existe aucune preuve que les tests ont influencé le produit
- Des réponses à la demande vagues, copiées ou incohérentes avec ce que montrent les tests
- Une application visiblement inachevée : écrans provisoires, parcours défaillants, plantages
Un plan de test qui passe
| Moment | Action à effectuer |
|---|---|
| Avant le jour 0 | Recrutez 15 à 20 personnes réelles de votre public cible : clients, employés, personnes inscrites sur une liste d'attente. Recueillez le compte Google que chacune utilisera. |
| Jour 0 | Importez une version complète dans la piste de test fermé, ajoutez les testeurs (une liste de diffusion ou un groupe convient bien) et envoyez le lien d'inscription avec les instructions d'installation. |
| Jours 1 à 3 | Confirmez que chaque testeur s'est inscrit et a installé l'application. Envoyez un court scénario de test couvrant les parcours essentiels de l'application. |
| Jours 4 à 10 | Centralisez les commentaires, corrigez les problèmes réels et publiez au moins une ou deux mises à jour avec des notes de version claires. |
| Jours 11 à 14 | Demandez aux testeurs de répéter les parcours essentiels sur la dernière version ; notez ce qui a changé et pourquoi. |
| Jour 14 ou plus tard | Vérifiez qu'au moins 12 testeurs affichent 14 jours consécutifs, puis effectuez la demande en répondant à partir de votre journal de commentaires plutôt que de mémoire. |
Le journal de commentaires est le document le plus utile que vous produirez. Il transforme les questions de la demande en faits : qui a testé, ce que ces personnes ont trouvé et ce que vous avez modifié. La même rigueur s'applique à toute publication, comme nous l'avons expliqué dans les tests d'acceptation et la validation finale.
À propos des services de testeurs payants
Des services qui vendent des groupes de testeurs existent et sont largement proposés. L'exigence concerne des tests authentiques, et les demandes dont les testeurs montrent peu d'engagement et dont les réponses ne révèlent aucune modification fondée sur les commentaires sont précisément celles qui sont refusées pour des tests supplémentaires. Les testeurs qui désinstallent l'application ou quittent le groupe rompent également la continuité mesurée par la règle. Si vous faites appel à une aide externe, utilisez-la pour atteindre de véritables utilisateurs correspondant au type de votre application, et appliquez tout de même le plan de test ci-dessus.
Après l'accès à la production
L'accès à la production s'applique à l'application qui a réussi. Une nouvelle application du même compte personnel doit effectuer son propre test fermé. Les mises à jour d'une application qui dispose déjà de l'accès à la production ne répètent pas cette exigence, mais elles font l'objet de l'examen habituel et doivent respecter les règles techniques en vigueur, notamment l'exigence d'API cible Android 16 pour les mises à jour depuis le 31 août 2026 et l'enregistrement de l'application pour la vérification des développeurs Android.
Questions fréquemment posées
Les testeurs peuvent-ils faire partie de mon équipe ?
Ils peuvent en faire partie, mais un test effectué uniquement par des collègues produit rarement l'engagement et les commentaires sur lesquels porte la demande. Intégrez de véritables utilisateurs cibles.
Puis-je utiliser les tests internes à la place ?
Non. L'exigence concerne un test fermé. Les tests internes restent utiles pour votre équipe avant le début du test fermé.
Le passage à un compte d'organisation est-il utile ?
Les comptes d'organisation ne sont pas soumis à cette exigence. Pour une application professionnelle, il s'agit de toute façon du type de compte approprié, mais il nécessite un numéro D-U-N-S et une vérification de l'organisation, qui demandent chacun du temps.
Services Manboo associés
- Développement d'applications Android, y compris la configuration de la Play Console, les pistes de publication et les déclarations de conformité.
- Développement d'applications iOS, y compris App Store Connect, TestFlight et la préparation à l'examen de l'application.
- Développement d'applications Flutter lorsqu'une seule base de code doit passer les examens des deux boutiques.
- Maintenance logicielle pour les applications existantes nécessitant des mises à jour de l'API cible, du SDK ou des règles.
- Demander un examen du périmètre et une estimation pour le lancement sur une boutique ou une soumission refusée.