Réponse rapide
Google Play applique à un jeu Android le même prérequis de test fermé pour l’accès en production qu’à n’importe quelle autre application. Si le jeu est publié depuis un compte de développeur personnel créé après le 13 novembre 2023, au moins 12 testeurs doivent être inscrits à un test fermé pendant au moins les 14 derniers jours sans interruption avant que vous puissiez demander un accès en production. Google exigeait à l’origine 20 testeurs et a abaissé le minimum à 12 le 11 décembre 2024; aucun nombre de testeurs, aucune durée ni aucune exemption spécifique aux jeux n’apparaît dans sa documentation actuelle. Atteindre le nombre ne vaut pas approbation, car Google demande aussi comment les testeurs se sont engagés, quels commentaires ils ont donnés et ce que vous avez changé, et il peut exiger des tests supplémentaires. Les jeux portent ensuite des risques de publication que ce compteur ne mesure jamais: livraison des assets, temps par image, code natif 64 bits, test des achats intégrés et autorisation Play Games Services. Si le volet testeurs est la partie que vous ne pouvez pas assurer, PrimeTestLab s’en charge avec de vrais testeurs sur de vrais appareils.
Également en vigueur pour les éditeurs de jeux
Le 31 août 2026 est passé: les jeux mobiles nouveaux et mis à jour doivent cibler Android 16 (niveau d’API 36) ou une version ultérieure, et Play Billing Library 7 a dépassé son échéance pour les nouvelles applications comme pour les mises à jour. Les soumissions Wear OS et Android Automotive OS demandent l’API 35, et Android TV et Android XR l’API 34. Si vous disposez d’un délai supplémentaire, il court jusqu’au 1er novembre 2026. Ni l’un ni l’autre ne fait partie de l’exigence de testeurs, et les deux peuvent bloquer la publication que cette exigence est censée débloquer.
La plupart des guides existants ne répondent qu’à une moitié du problème. Les pages générales sur le test fermé expliquent l’exigence de 12 testeurs sans toucher aux risques de publication propres à un jeu, tandis que les pages de QA de jeux parlent de performances et de laboratoires d’appareils sans expliquer le portail d’accès en production qui bloque réellement le lancement. Les fils de discussion communautaires comblent l’espace entre les deux avec un folklore assuré: jouer une fois par jour, publier trois mises à jour, trente minutes par session, un nombre minimal de niveaux. Aucune de ces affirmations n’est une règle publiée par Google, et cet article le dit chaque fois que l’une d’elles revient. Tout ce qui suit est à jour au 12 août 2026, avec les dates limites des règles revérifiées le 14 août 2026, et tout est rattaché à la documentation primaire de Google; là où la réponse honnête est « Google ne publie pas cette information », la page l’écrit au lieu d’avancer un chiffre.
L’ordre ci-dessous suit la manière dont le problème se résout vraiment. D’abord le portail lui-même, parce que vous ne pouvez rien planifier tant que vous ne savez pas s’il vous concerne ni ce qu’il compte exactement. Ensuite la couche propre aux jeux: ce qu’un test qui se contente d’accumuler des comptes inscrits ne détecte pas, et comment tester chacun de ces risques avant que les examinateurs de Google n’en voient le résultat.
L’établi
Trois instruments conçus pour les trois questions auxquelles un développeur de jeu ne peut pas répondre avec la seule documentation de Google. Chacun fonctionne entièrement dans votre navigateur, à partir des valeurs que vous saisissez. Rien n’est envoyé, et aucun compte n’est nécessaire.
Sommaire
Google Play exige-t-il un test fermé pour les jeux Android?
Oui, dans les mêmes conditions que pour n’importe quelle autre application. Si le jeu est publié depuis un compte de développeur personnel créé après le 13 novembre 2023, vous devez exécuter un test fermé auprès d’au moins 12 testeurs inscrits depuis les 14 derniers jours sans interruption avant de pouvoir demander un accès en production. Google ne publie aucun nombre de testeurs distinct, aucune durée plus courte ni aucune exemption pour les jeux.
« Si vous venez de créer un compte de développeur personnel, vous devez exécuter un test fermé pour votre application auprès d’au moins 12 testeurs inscrits depuis au moins 14 jours sans interruption. »
Aide Play Console, answer 14151465
Lisez cette phrase pour ce qu’elle ne dit pas. Elle ne mentionne aucune catégorie d’application. Le déclencheur tient au compte, pas à ce que vous importez: le fait que votre bundle soit classé comme un jeu ne change donc rien à l’application de ce portail. Les documents de Google sur le test fermé traitent des applications et des jeux à l’intérieur du même processus d’accès en production, et ils citent explicitement le test avant lancement des jeux mobiles comme un usage des canaux de test.
Relisez-la une fois de plus pour les mots votre application. La date de création du compte détermine si l’exigence vous concerne, mais le test qualifiant et la demande d’accès en production se font pour une application donnée. Avoir franchi le processus pour un jeu ne se reporte pas sur le package suivant publié depuis le même compte: un deuxième jeu a droit à son propre test fermé, à ses propres 12 testeurs et à sa propre quinzaine. Cette conclusion repose sur le fait que Google écrit la condition à propos de « votre application » et que l’accès en production se demande package par package, et non sur une phrase publiée qui exclurait explicitement le report; prévoyez un nouveau test par jeu, et vérifiez le tableau de bord de la Console pour l’application concernée avant de trancher dans un sens ou dans l’autre.
Constat négatif « Il n’existe aucune exemption pour les jeux » est une conclusion tirée de l’absence d’une telle exemption dans la documentation actuelle de Google, pas une phrase publiée par Google. La distinction a du sens et cet article la maintient: aucun nombre de testeurs ni aucune durée différente pour les jeux n’a été trouvé où que ce soit dans les documents actuels sur l’accès en production, la lecture prudente est donc que les comptes personnels concernés relèvent du même prérequis, quoi qu’ils publient.
Ce que la règle compte réellement
12
Testeurs, minimumDes comptes individuels qui sont allés au bout de l’inscription. Pas des personnes à qui vous avez écrit, ni des personnes qui ont dit oui.
14
Jours sans interruptionChacun de ces 12 comptes doit avoir été inscrit pendant la totalité des 14 derniers jours au moment de la demande.
1
Compte concerné, test par applicationC’est le compte qui détermine si la règle s’applique. Le test qualifiant, lui, se mène application par application.
Si vous avez lu que le nombre est de 20, la page que vous avez lue n’est plus à jour. Google avait fixé le seuil à 20 testeurs à l’origine et l’a abaissé à 12 le 11 décembre 2024, décrivant le changement dans ses propres mots comme exigeant « 12 testeurs au lieu de 20 », tout en laissant la période de deux semaines intacte. L’historique est détaillé dans l’article sur le passage de 20 à 12 testeurs, et le fonctionnement de l’exigence elle-même dans l’article sur l’exigence des 12 testeurs. Le présent article tient les deux pour acquis et se concentre sur ce qui change pour un jeu.
Quels développeurs de jeux ont réellement besoin de 12 testeurs?
Le prérequis vise les comptes de développeur personnels créés après le 13 novembre 2023. Les comptes d’organisation et les comptes personnels plus anciens sont hors de cette exigence précise. Importer un jeu plutôt qu’une application ne vous y soumet pas et ne vous en dispense pas, et mener un test interne avec jusqu’à 100 personnes ne la remplit pas.
| Votre situation | 12 testeurs, 14 jours? | L’explication prudente |
|---|---|---|
| Compte personnel créé après le 13 nov. 2023 | Oui | Menez un test fermé avec au moins 12 testeurs inscrits sans interruption pendant les 14 derniers jours, puis demandez un accès en production. |
| Compte personnel créé avant cette date limite | Pas au titre de cette règle | Google limite l’exigence aux comptes personnels créés après le 13 novembre 2023. |
| Compte d’organisation | Pas au titre de cette règle | L’exigence est expressément écrite pour les comptes personnels concernés. Ce n’est pas la même chose qu’être dispensé de test, de qualité ou d’examen des règles. |
| Un jeu plutôt qu’une application ordinaire | Aucun cas particulier | Aucun nombre de testeurs ni aucune durée différents pour les jeux n’apparaît dans la documentation actuelle de Google sur l’accès en production. |
| Vous avez déjà mené un test interne avec 100 personnes | Toujours requis | Le test interne et le test fermé sont des canaux distincts. Le prérequis exige spécifiquement un test fermé. |
| Vous l’avez déjà validé pour un autre jeu sur le même compte | Toujours requis | Google formule l’exigence comme un test fermé « pour votre application ». Le compte détermine si la règle s’applique; le test qualifiant se fait par nom de package. |
« Les comptes d’organisation sont exemptés » est la mauvaise phrase
Un compte d’organisation se situe en dehors de ce prérequis précis lié aux nouveaux comptes personnels. Il reste soumis à toutes les obligations habituelles: examen, règles de contenu, normes de qualité, déclarations et règles de distribution. S’enregistrer comme organisation pour contourner une exigence de testeurs implique aussi d’assumer la vérification d’organisation, et le type de compte que vous choisissez a des conséquences bien au-delà de ce seul portail. Les arbitrages sont détaillés dans l’article sur le compte personnel face au compte d’organisation.
Un point de contexte général sur les comptes, parce qu’il revient dans la même phrase et se confond souvent avec le coût du test: Google demande un versement unique de 25 USD pour ouvrir un compte de développeur. Ces frais n’ont rien à voir avec l’exigence de test. Mener un test fermé ne coûte rien dans Play Console; ce qui coûte, c’est de trouver douze personnes qui resteront.
C’est là le vrai problème pour un jeu. Comparé à une application utilitaire, un jeu a généralement besoin de sessions plus profondes avant que ses défauts n’apparaissent: la progression et les sauvegardes, la livraison des assets, le comportement thermique et la monétisation ne déraillent qu’une fois que quelqu’un a joué assez loin pour avoir quelque chose à perdre. Aucune des deux catégories n’est correctement testée par des gens qui installent un build et le laissent de côté pendant une quinzaine, et Google pèse l’engagement et les commentaires pour les applications comme pour les jeux. Un jeu rend simplement la version superficielle de cette erreur plus coûteuse, parce qu’il vous faut des gens qui jouent vraiment, sur un matériel qui ressemble à celui d’un joueur, assez longtemps pour atteindre le deuxième acte. C’est l’écart dont traite le reste de cet article.
Comment se déroule le test fermé de 14 jours pour un jeu?
Publiez une version sur un canal fermé, amenez au moins 12 testeurs au bout d’une inscription complète, et gardez-les inscrits pendant qu’ils jouent vraiment. Au moment de la demande, au moins 12 d’entre eux doivent chacun avoir été inscrits pendant les 14 derniers jours sans interruption. Demandez ensuite l’accès en production depuis le tableau de bord de Play Console. Le test interne accepte jusqu’à 100 testeurs et reste utile, mais il ne satisfait pas cette étape.
Source: l’exigence de test fermé pour les nouveaux comptes personnels (answer 14151465). Le minimum de 12 testeurs a remplacé 20 le 11 décembre 2024; la période de 14 jours sans interruption n’a pas changé.
-
01
Avant le premier jour
Publiez la version de test fermé et rendez-la accessible à vos testeurs. Vérifiez que le build livré par Play s’installe et se lance, que les packs d’assets arrivent, que la connexion Play Games fonctionne et que tout ce que le test doit atteindre est atteignable. Un build qui fonctionne depuis votre machine ne prouve rien sur le build que Play assemble.
-
02
Inscription
Chaque testeur doit accepter l’invitation, pas simplement figurer sur une liste. C’est un piège constant: être ajouté à une liste de diffusion ou à un Google Group est votre action, s’inscrire est la leur. Ne comptez que les comptes qui sont allés au bout.
-
03
Du premier au quatorzième jour
Au moins 12 testeurs restent inscrits sans interruption pendant qu’ils jouent. Recrutez au-dessus du minimum pour qu’un seul désistement ne vous mette pas en dessous. Google interroge sur l’engagement et les commentaires au moment de la demande: le produit utile de cette quinzaine est donc une liste de ce que les gens vous ont dit, pas une capture d’écran d’un compteur.
-
04
Pendant le test
Corrigez les vrais défauts et continuez à mettre le build à jour. Importer de nouvelles versions pendant la fenêtre est normal et ne remet rien à zéro: la condition d’éligibilité est écrite sur l’historique d’inscription des testeurs, pas sur l’ancienneté d’un build figé. Cela découle de la formulation de Google sur l’inscription continue de chaque testeur; Google ne publie aucune règle distincte sur les mises à jour de build, dans un sens comme dans l’autre. Éprouvez les parcours d’installation et de mise à jour, la progression et les sauvegardes, les téléchargements d’assets, les plantages, les performances, les achats et Play Games selon l’usage qu’en fait votre jeu.
-
05
Après la fenêtre d’éligibilité
Allez dans Dashboard > Apply for production et répondez honnêtement: qui a testé, comment ces testeurs se sont engagés, ce qu’ils ont dit, ce que vous avez changé et pourquoi le jeu est prêt.
-
06
Examen
Google indique que cela prend généralement 7 jours ou moins et peut occasionnellement durer plus longtemps. Ce n’est pas un engagement de niveau de service et personne ne peut vous promettre une date.
Une correction à faire tôt, parce qu’elle coûte une quinzaine à beaucoup de monde. Le test interne est un autre canal de test, au plafond bien plus haut: jusqu’à 100 testeurs, disponible rapidement. Il est réellement utile pour mettre un build entre les mains de vrais utilisateurs sans attendre. Il ne remplace pas le test fermé que le prérequis désigne. Les différences entre les trois canaux sont détaillées dans l’article sur le test interne, le test fermé et le test ouvert, et le test ouvert ne devient accessible qu’une fois l’accès en production obtenu.
Les testeurs doivent-ils jouer au jeu tous les jours?
C’est là que presque toutes les réponses communautaires se trompent, alors voici les trois catégories, tenues séparées.
Exigé, et publié
- Au moins 12 testeurs inscrits.
- Inscrits pendant les 14 derniers jours sans interruption.
- Un test fermé précisément, pas un test interne.
- Des réponses honnêtes dans la demande d’accès en production.
Bonne pratique, pas une règle
- Des testeurs qui atteignent vraiment la boucle de jeu principale, pas seulement l’écran-titre.
- Des sessions assez longues pour que la chaleur et la pression mémoire se manifestent.
- Des commentaires écrits que vous pourrez citer au moment de la demande.
- Des correctifs livrés pendant la fenêtre, quand les commentaires le justifient.
Pas une règle publiée
- Ouvrir le jeu une fois par jour.
- Un nombre minimal de minutes par session.
- Un nombre de builds imposé pendant le test.
- Un nombre minimal de niveaux, d’écrans ou de mécaniques.
Google exige une inscription continue et indique que l’engagement compte au moment où il examine votre demande. Il ne publie ni quota d’ouvertures quotidiennes, ni durée minimale par session, ni nombre de mises à jour. Prenez la colonne de droite pour ce qu’elle est: des conseils devenus folklore à force d’être répétés avec assurance. Visez un vrai test et vous satisfaites la colonne du milieu sans avoir besoin de la troisième.
Si un testeur se retire, la quinzaine repart-elle à zéro?
Pas en soi, et c’est la règle la plus exagérée qui circule. La condition de Google se mesure au moment de la demande: au moins 12 testeurs, chacun inscrit pendant les 14 jours précédents sans interruption. Il n’est pas exigé qu’un groupe intact de douze personnes exactement traverse la quinzaine sans changement.
L’arithmétique se fait donc par testeur, pas par cohorte. Commencez avec exactement 12 et perdez-en un le neuvième jour: vous êtes en dessous. Il vous reste onze comptes capables de justifier la fenêtre complète, et le douzième, son remplaçant, doit accomplir ses propres 14 jours sans interruption avant que vous puissiez faire la demande. Commencez avec quinze et perdez-en un: les quatorze restants peuvent chacun remplir la condition, et vous ne perdez que de la marge. C’est tout l’argument en faveur d’un recrutement au-dessus du minimum plutôt qu’exactement au minimum.
Comment nous le savons Cette lecture découle de la formulation de Google sur l’inscription continue de chaque testeur, sur laquelle l’exigence est écrite. Google ne publie aucune règle distincte de remise à zéro de la cohorte disant noir sur blanc que le départ d’un testeur préserve la période de tous les autres: considérez donc ceci comme une lecture attentive de la condition publiée, et non comme une phrase que vous pourriez citer à un examinateur. Le conseil pratique ne change pas pour autant: recrutez au-dessus de 12 pour que la question n’ait jamais à être tranchée.
Que se passe-t-il après le 14e jour?
Vous faites la demande, et Google lit les réponses. La demande d’accès en production porte sur la façon dont les testeurs se sont engagés avec le jeu, les commentaires qu’ils ont donnés, ce que vous avez changé en conséquence et les raisons pour lesquelles vous le jugez prêt. Pour un jeu, s’ajoute une question propre à la catégorie: décrire ce qui le distingue. Cette question n’est pas non plus une formalité: c’est là qu’un jeu fonctionnellement correct mais qui n’a rien à dire sur lui-même commence à ressembler à un jeu que personne n’a testé sérieusement.
Rédigez les réponses pendant le test, pas après
Les questions portent sur ce qui s’est passé pendant quatorze jours. Si vous attendez le quinzième jour pour y réfléchir, vous reconstituerez de mémoire, et cela se voit. Tenez une note au fil de l’eau de ce que les testeurs ont signalé et de ce que vous avez livré en réponse; la demande prend alors vingt minutes et dit quelque chose de vrai. Un parcours complet du questionnaire figure dans l’article sur le questionnaire d’accès en production.
Qu’est-ce qu’un test d’application générique rate sur un jeu?
Un test bâti sur « installez-le et restez inscrit » mesure le compteur et rien d’autre. Les jeux imposent une charge CPU et GPU soutenue, livrent de gros volumes d’assets par un système de distribution qui a ses propres modes de défaillance, embarquent le plus souvent des binaires natifs, conservent un état de progression d’une session à l’autre et encaissent souvent de l’argent. Chacun de ces points est un endroit où un build passe sur votre bureau et échoue sur le téléphone d’un joueur.
Aucun de ces risques n’est propre aux jeux, et cet article ne prétend pas le contraire: quantité d’applications ordinaires embarquent des bibliothèques natives, vendent des abonnements ou livrent de gros assets. Ce qui est distinctif, c’est la concentration. Un jeu rencontre en général la majeure partie de cette liste d’un coup, dans le même build, pendant la même quinzaine, et c’est pourquoi une checklist écrite pour une application générique laisse une si grande part d’un jeu non testée.
Voici la carte du reste de cet article. La colonne de droite est celle que l’on se trompe dans les deux sens: certains points sont des exigences de Google avec des conséquences, d’autres relèvent de la simple pratique qualité qu’aucune règle ne mentionne. Prendre une pratique pour une règle gaspille votre quinzaine, et prendre une règle pour une pratique vous coûte la publication.
| Domaine de risque | Pourquoi un jeu est différent | Statut |
|---|---|---|
| Livraison des assets et taille | De gros volumes répartis entre des packs install-time, fast-follow et on-demand, chacun avec ses propres limites et sa propre façon d’arriver en retard ou pas du tout. | Limites Google |
| Temps par image et chaleur | Une charge de rendu soutenue fait chauffer l’appareil, le système bride, et les temps par image grimpent à la sixième minute d’une session qui paraissait saine à la première. | Métrique vitals |
| Code natif et 64 bits | Les moteurs et les plugins livrent des binaires compilés. Une couverture 64 bits absente ou une mauvaise ABI met hors jeu des familles entières d’appareils, pas une seule fonctionnalité. | Exigence Google |
| Achats intégrés | Appartenir à un canal de test ne rend pas les achats gratuits, et un achat de test non acquitté disparaît au bout de trois minutes. | Mécanisme Google |
| Play Games Services | Une seconde couche d’autorisation, avec sa propre liste de testeurs, qui échoue avec des erreurs OAuth et 404 quand elle n’est pas configurée. | Exigence Google |
| Monétisation et règles de contenu | L’affichage des probabilités des objets aléatoires, les mécaniques en argent réel et l’exactitude du questionnaire de classification forment une exposition aux règles propre aux jeux, qu’une application utilitaire ordinaire ne rencontre jamais. | Règle Google |
| Progression et sauvegardes | Quitter, reprendre, réinstaller et changer d’appareil doivent tous préserver la progression, et un bug de sauvegarde reste invisible tant que personne ne joue assez loin pour avoir quelque chose à perdre. | Pratique QA |
| Profondeur de session | Les défaillances qui comptent se trouvent au-delà du tutoriel. Un testeur qui ouvre le jeu une seule fois ne produit aucune preuve sur la moindre ligne ci-dessus. | Pratique QA |
Remarquez ce qui ne figure pas dans ce tableau: un nombre d’appareils imposé, une durée de session imposée, une fréquence d’images imposée ou un nombre minimal de niveaux. Ces points sont affirmés en permanence et aucun n’est publié. Ce que Google publie, ce sont des limites, des seuils, des mécanismes et des règles, et chacun d’eux est testable pendant la quinzaine que vous consacrez déjà au compteur.
Quelle taille votre jeu peut-il atteindre sur Google Play?
Au 12 août 2026, l’aide Play Console indique un module de base de 500 MB, 500 MB par module de fonctionnalité, 1.5 GB par pack d’assets, 4 GB pour l’ensemble des modules et des packs d’assets install-time, 30 GB pour les packs fast-follow et on-demand, et un maximum total de 34 GB. Chacune de ces valeurs est une taille de téléchargement compressée calculée par Play Console, pas la taille du .aab posé sur votre disque.
C’est le fait qui a le plus de chances d’être faux dans ce que vous avez lu avant d’arriver ici. Le chiffre de 200 MB qui circule encore était la limite de base il y a des années, et certaines anciennes pages de Google consacrées aux jeux Android n’ont pas rattrapé la page de l’aide Play Console qui régit les imports réels. Quand deux pages de Google se contredisent, la page dédiée aux limites de taille dans l’aide Play Console est la page spécifique et à jour pour ce que la Console acceptera. Revérifiez-la avant de bâtir une version autour de l’un des chiffres ci-dessous.
Instrument 01
Jauge de budget de build
Saisissez vos tailles de téléchargement compressées en mégaoctets. Tout s’exécute dans cette page; rien n’est envoyé. Ce calculateur utilise 1 GB = 1024 MB.
Limites vérifiées auprès de l’aide Play Console le 12 août 2026. Google les calcule à partir de la taille de téléchargement compressée qu’il déduit de votre bundle: la taille du fichier sur votre disque n’est donc qu’une approximation de ce qui sera mesuré. Sources: les limites de taille maximale des applications (answer 9859372) et Play Asset Delivery.
Le tableau complet des limites
| Composant | Limite actuelle | Ce à quoi elle s’applique |
|---|---|---|
| Module de base | 500 MB | Le module de base du bundle, seul. |
| Module de fonctionnalité | 500 MB | Chaque module de fonctionnalité, mesuré séparément. |
| Pack d’assets | 1.5 GB | Chaque pack d’assets, mesuré séparément. |
| Modules et packs install-time | 4 GB | Total cumulé de tout ce qui est livré pendant l’installation. |
| Packs fast-follow et on-demand | 30 GB | Total cumulé de tout ce qui est livré après l’installation. |
| Téléchargement total | 34 GB | Taille de téléchargement compressée maximale, tous éléments confondus. |
| Packs d’assets par bundle | 100 | Nombre maximal de packs d’assets dans un app bundle. |
| Applications de plus de 1 GB | minSdk 21 | Tout ce qui dépasse 1 GB doit cibler au minimum Android 5.0 Lollipop. |
| Avertissement données mobiles | 200 MB | Au-delà, les installations en données mobiles affichent une boîte de dialogue non bloquante signalant la taille. |
| Ancien format APK | 100 MB | Maximum pour un APK unique dans l’ancien mode de publication par APK. |
Limites de taille Google Play vérifiées le 12 août 2026. Toutes les valeurs sont des tailles de téléchargement compressées calculées par Play Console. Sources: les limites de taille maximale des applications (answer 9859372) et Play Asset Delivery.
Quel mode Play Asset Delivery votre jeu doit-il tester?
Play Asset Delivery compte trois modes, et chacun échoue à un endroit différent. Le mode choisi dans votre build détermine les cas de test qui comptent: parcourez donc ce tableau et ne testez que les lignes que votre jeu utilise réellement.
| Mode | Quand il arrive | Prêt au lancement? | Dans la taille annoncée sur le Store? | Le cas de test qui trouve les bugs |
|---|---|---|---|---|
| Install-time | Livré pendant l’installation sous forme de split APK. | Oui | Oui | Le premier lancement, le parcours de mise à jour, et l’installation sur un appareil presque à court de stockage. |
| Fast-follow | Se télécharge automatiquement juste après l’installation, sans bloquer l’entrée dans le jeu. | Pas forcément | Non | Un joueur qui ouvre le jeu avant la fin du pack, et la reprise après un téléchargement interrompu. |
| On-demand | Téléchargé pendant que le jeu tourne, quand votre code le demande. | Seulement une fois demandé | Non | Entrer dans le niveau ou la fonctionnalité avant que son pack soit disponible, plus les reprises et les interruptions. |
Ne partez pas du principe que les packs restent où vous les avez laissés
Google prévient que les fichiers d’archive fast-follow et on-demand peuvent être supprimés par l’utilisateur ou déplacés par la bibliothèque Play Asset Delivery d’une session à l’autre: un jeu ne doit donc pas supposer qu’un pack présent hier se trouve encore au même endroit aujourd’hui. Testez le deuxième et le troisième lancement, pas seulement le premier, et testez ce qui se passe quand une mise à jour invalide un pack. Le ciblage par format de compression de textures ajoute une dimension: Play peut livrer des assets de textures différents selon ce que l’appareil prend en charge, et les assets que reçoit votre appareil de test ne sont donc pas forcément ceux que reçoit un autre appareil.
Un test local de livraison d’assets ne reproduit pas exactement la livraison par Play. Google documente qu’en test local un pack fast-follow se comporte comme un pack on-demand, et que certains comportements réseau et d’attente du Wi-Fi ne peuvent pas être reproduits localement. C’est l’argument en faveur d’un test sur le build que Play livre réellement à un testeur du canal fermé plutôt que sur le build produit par votre éditeur, et c’est l’un des rares endroits où le test fermé fait véritablement du travail de QA au lieu de satisfaire un compteur.
Quels chiffres de fréquence d’images et de plantages Google publie-t-il réellement?
Android vitals publie un seuil de taux de plantages perçus par l’utilisateur de 1.09% au global et de 8% par modèle de téléphone, ainsi qu’un taux d’ANR perçus par l’utilisateur de 0.47% au global et de 8% par modèle de téléphone. Pour les jeux en particulier, il définit une session lente comme une session où plus de 25% des images sont lentes, mesurée par rapport à 50 ms (20 FPS) comme métrique principale et à 34 ms (environ 30 FPS) comme métrique secondaire. Aucun de ces chiffres n’est un seuil d’approbation publié pour le test fermé.
La distinction compte parce qu’elle se perd régulièrement. Les seuils de vitals décrivent la qualité technique, et Google a annoncé qu’à terme Play détournera les utilisateurs des jeux incapables d’atteindre 20 FPS sur leur téléphone. C’est un mécanisme de découvrabilité et de qualité. Ce n’est pas l’examen d’accès en production, et aucune source de Google ne transforme une fréquence d’images en note de passage pour le test de 14 jours. Les deux peuvent être vrais en même temps: votre jeu peut franchir le portail des testeurs et rester un jeu que Play cessera discrètement de recommander.
Instrument 02
Labo des sessions lentes
Quarante images d’une même session de jeu. Déplacez le curseur pour indiquer combien d’entre elles ont été rendues lentement, et le labo applique la définition de Google au résultat.
Android vitals ne commence à surveiller la fréquence d’images d’un jeu qu’après 1 minute d’exécution, ce qui explique aussi pourquoi un testeur qui ouvre un jeu puis le referme ne produit aucun signal de performance exploitable. Cette minute est un point de départ de mesure, pas une durée de session de jeu imposée. Source: Sessions lentes dans Android vitals.
Les chiffres, et ce que chacun n’est pas
| Métrique | Valeur de Google | Ce que cela signifie | Ce que cela ne signifie pas |
|---|---|---|---|
| Taux de plantages perçus par l’utilisateur | 1.09% | Seuil de qualité technique Android vitals, mesuré au global. | En aucun cas un seuil de test fermé. |
| Taux de plantages par modèle de téléphone | 8% | Le seuil vitals propre à un appareil. | Pas l’autorisation de tolérer 8% de plantages dans votre propre QA. |
| Taux d’ANR perçus par l’utilisateur | 0.47% | Seuil de qualité technique Android vitals, mesuré au global. | Ne fait pas partie de la formule d’accès en production. |
| Taux d’ANR par modèle de téléphone | 8% | Le seuil vitals propre à un appareil. | Pas un objectif à viser en conception. |
| Session lente | >25% d’images lentes | La définition de qualité d’image réservée aux jeux. | Pas une mesure de l’engagement des testeurs. |
| Image lente, principale | 50 ms, 20 FPS | Le temps de référence principal des sessions lentes. | Pas un minimum de FPS publié pour l’accès en production. |
| Image lente, secondaire | 34 ms, environ 30 FPS | Une métrique supplémentaire des sessions lentes que vitals rapporte. | Pas une preuve que Google exige 30 FPS pour tous les jeux. |
| Début de la surveillance | Après 1 minute | La collecte de la fréquence d’images démarre après une minute d’exécution du jeu. | Pas la durée de session de jeu exigée par Google. |
Le bug qui n’apparaît qu’à la sixième minute
Google cite la surchauffe et le bridage thermique parmi les causes documentées d’images lentes: une charge CPU et GPU soutenue fait chauffer l’appareil, le système bride, et les temps par image grimpent. Ce mode de défaillance est invisible dans un test de fumée de deux minutes et évident dans une session de vingt minutes sur un téléphone chaud. C’est aussi l’illustration la plus nette de la raison pour laquelle un jeu a besoin de testeurs qui jouent vraiment plutôt que de testeurs qui installent. Si vous profilez ce comportement, l’Android Dynamic Performance Framework (ADPF) expose des signaux de gestion thermique, CPU et GPU précisément pour cela, afin que le jeu s’adapte avant que le bridage ne devienne sévère.
Bibliothèques natives et 64 bits
Les jeux bâtis sur Unity, Unreal, Cocos ou tout moteur doté de plugins natifs embarquent des binaires compilés, et ces binaires obéissent à leurs propres règles de compatibilité, indépendantes de tout ce qui figure dans cet article. Google Play impose aux applications la prise en charge des architectures 64 bits: dès qu’une architecture native 32 bits est prise en charge, l’architecture 64 bits correspondante doit l’être aussi. Testez dans un environnement 64 bits, et partez du principe que chaque plugin tiers peut livrer son propre binaire incompatible, quoi qu’annonce la version de votre moteur.
Si votre build déclenche aussi l’avertissement de taille de page mémoire 16 KB pendant ces travaux, il s’agit d’une exigence distincte, avec sa propre échéance et son propre chemin de correction, traitée dans l’article sur la correction de l’erreur de taille de page 16 KB.
Pas une règle publiée Google ne publie aucun nombre d’appareils, de versions d’Android ni de familles de GPU sur lesquels un jeu devrait être testé pour obtenir l’accès en production. Quiconque cite « cinq téléphones et trois versions d’Android » cite une préférence, pas une règle. Couvrez l’éventail que votre jeu prend réellement en charge, pondéré par le matériel que votre public a le plus de chances d’avoir en main, et rappelez-vous qu’un émulateur ne vous apprendra rien d’utile sur le comportement thermique.
Comment tester les achats intégrés sans débiter vos testeurs?
Ajoutez sous Settings > License testing dans Play Console chaque compte qui effectuera un achat de test. Être sur votre canal fermé ne rend pas les achats gratuits. Un testeur ordinaire qui appuie sur Acheter dans votre jeu non publié peut être débité en argent réel, et la seule chose qui change cela, c’est le statut de testeur de licence du compte qui effectue l’achat.
« Les utilisateurs sont réellement débités ... sauf si l’utilisateur est un testeur de licence. »
Google Play Billing, documentation sur le test de la facturation intégrée
Deux listes distinctes contrôlent deux choses distinctes. La liste des testeurs du canal fermé décide qui peut installer le build non publié. La liste des testeurs de licence décide de qui verra ses achats passer par les moyens de paiement de test de Google plutôt que par une vraie carte. Un développeur qui ajoute douze personnes à la première liste et aucune à la seconde a monté un test où chaque achat est réel, et la première personne à s’en apercevoir est en général un testeur qui réclame un remboursement.
Instrument 03
Vérificateur de débit testeur
Répondez pour l’appareil et le compte précis qui s’apprêtent à effectuer l’achat. Le verdict change pour chaque compte, pas pour chaque build.
Testeur du canal fermé ou testeur de licence
| Situation | Sur le canal fermé? | Testeur de licence? | Ce qui se passe quand ils achètent |
|---|---|---|---|
| Un testeur invité ordinaire | Oui | Non | Peut installer le build non publié, et ses achats peuvent être de vraies transactions débitées. |
| Un testeur de licence qui est aussi sur le canal | Oui | Oui | Installe le build fermé et obtient les moyens de paiement de test de Google. |
| Un testeur de licence avec un build local au nom de package identique | Pas forcément | Oui | Google autorise les testeurs de licence à tester la facturation sans l’exigence habituelle d’un build importé et signé, dès lors que les conditions de package et de compte sont réunies. |
| Un appareil avec plusieurs comptes Google | L’un ou l’autre | Selon le compte | L’achat utilise normalement le compte qui a téléchargé l’application; si aucun ne l’a fait, Google utilise le premier compte. |
| Un achat de test jamais acquitté | L’un ou l’autre | Oui | Remboursé automatiquement au bout de 3 minutes dans l’environnement de test accéléré. |
Les tests d’achat qu’un jeu monétisé devrait exécuter
| Test | Mécanisme | Comportement attendu |
|---|---|---|
| Achat de consommable réussi | L’instrument de test qui approuve toujours. | Objet accordé, puis acquitté ou consommé correctement. |
| Achat refusé | L’instrument de test qui refuse toujours. | Aucun objet accordé, et aucun état partiel laissé derrière. |
| Consommable racheté | Racheter le même consommable. | Le deuxième et le troisième achat fonctionnent exactement comme le premier. |
| Non consommable | Un achat de test réussi. | Accordé une seule fois, tout rachat involontaire étant empêché. |
| En attente, puis validé | Le moyen de paiement de test qui approuve avec délai. | Rien n’est accordé tant que l’état n’est pas passé à acheté, puis accordé une seule fois. |
| En attente, puis échoué | Le moyen de paiement de test qui refuse avec délai. | Le droit n’est accordé à aucun moment. |
| Redémarrage en plein achat | Fermer et rouvrir le jeu pendant un état en attente. | L’état du droit se réconcilie correctement au relancement. |
| Acquittement | Un achat réussi laissé en l’état. | Survit au-delà de 3 minutes au lieu d’être remboursé automatiquement. |
| Mauvais compte | Un appareil avec plusieurs comptes Google connectés. | Le compte de facturation est bien le testeur de licence prévu. |
Avant que tout cela fonctionne
Le test de licence se trouve sous Settings > License testing dans Play Console, et la liste d’adresses e-mail y accepte jusqu’à 2 000 adresses, tandis qu’un Google Group peut être utilisé sans cette limite de liste d’utilisateurs. Vos produits ponctuels et vos abonnements doivent aussi être configurés et publiés comme il se doit avant de pouvoir être testés correctement: un produit non publié provoque des échecs qui ressemblent à des bugs de facturation et qui sont en réalité des trous de configuration.
Calendrier de la bibliothèque de facturation: Play Billing Library 7 a dépassé son échéance pour les nouvelles applications et les mises à jour le 31 août 2026. Si vous disposez d’une prolongation, elle court jusqu’au 1er novembre 2026; sinon, les nouvelles versions doivent utiliser une version ultérieure prise en charge. Être la version la plus récente n’est pas la même chose qu’être la version minimale autorisée: visez donc une version maintenue et prise en charge plutôt que de supposer que la dernière est obligatoire. Source: Tester la facturation intégrée, y compris les testeurs de licence.
Les loot boxes font-elles de votre jeu une application de jeux d’argent?
Non. Google distingue les objets virtuels aléatoires payants des jeux d’argent réel. Si les joueurs dépensent de l’argent ou une valeur achetée pour des objets virtuels aléatoires comme des loot boxes, vous devez afficher clairement les probabilités avant l’achat et juste à côté de celui-ci. Payer pour tenter de gagner un lot réel relève d’un autre régime de règles, avec ses propres critères d’éligibilité et ses propres exigences de licence.
| Votre mécanique | La règle concernée | Ce que vous devez faire |
|---|---|---|
| Le joueur achète un objet virtuel connu et fixe | Les règles ordinaires d’achat numérique. | Testez l’achat correctement et respectez les règles de facturation Play applicables. Rien de particulier. |
| Le joueur dépense de l’argent ou une valeur pour un objet virtuel aléatoire | La règle sur les objets aléatoires, qui nomme explicitement les loot boxes. | Affichez les probabilités avant l’achat et juste à côté de celui-ci, là où le joueur peut réellement les voir. |
| Le jeu représente des jeux d’argent simulés | Classification du contenu. | Répondez avec exactitude au questionnaire de classification. La classification obtenue dépend de l’organisme compétent et du questionnaire applicable. |
| Le joueur paie pour tenter de gagner un lot réel | La règle distincte sur les jeux d’argent, jeux et concours en argent réel. | Traitez cela comme une catégorie soumise à restrictions, pas comme une monétisation ordinaire par loot boxes. |
| Produit de jeux d’argent réel sous licence | Règles spécifiques d’éligibilité, de pays et de licence. | Hors du périmètre des conseils habituels pour un jeu indépendant. Appuyez-vous directement sur la règle dédiée de Google sur les jeux d’argent. |
Le questionnaire de classification du contenu n’est pas une formalité
Chaque jeu a besoin de réponses exactes et complètes au questionnaire de classification du contenu, accessible via Policy > App content dans Play Console, et il faut le mettre à jour dès que le contenu ou les fonctionnalités qu’il décrit changent. Présenter faussement ce que contient un jeu peut mener à un retrait ou à une suspension, ce qui fait d’un questionnaire inexact une erreur bien plus coûteuse qu’une image lente.
Les jeux touchent une surface de questionnaire plus large que les applications: violence, jeux d’argent simulés, achats dans le jeu, communication entre utilisateurs, contenu généré par les utilisateurs. Si votre test fermé ajoute une fonction de chat ou une récompense aléatoire en deuxième semaine, les réponses données en première semaine sont désormais fausses. Rouvrez le questionnaire avant de demander l’accès en production, plutôt qu’après que quelqu’un l’a remarqué.
La règle sur les fonctionnalités de base et la qualité sous-tend tout cela: les applications et les jeux doivent offrir une expérience stable, réactive et suffisamment fonctionnelle, et ce qui plante, ne se charge pas ou reste concrètement inutilisable peut l’enfreindre. Pas une règle publiée Aucun nombre minimal de niveaux, d’écrans, de mécaniques ou de minutes de jeu n’est publié. Un jeu court n’est pas un problème de règles; un jeu cassé, si.
Source: la règle de Google Play sur les objets virtuels aléatoires (answer 9858738), qui impose d’afficher les probabilités avant l’achat et juste à côté de celui-ci.
Pourquoi la connexion Play Games échoue-t-elle pendant le test fermé?
Parce que Play Games Services tient sa propre liste de testeurs. Tant que votre configuration Play Games Services n’est pas publiée, les testeurs doivent être autorisés individuellement ou via un canal de publication activé, faute de quoi Google indique qu’ils rencontreront des erreurs OAuth et 404. Figurer sur le canal fermé donne au testeur accès au build. Cela ne lui donne pas la couche Play Games.
Le symptôme est caractéristique et trompeur: la connexion fonctionne sur votre machine, fonctionne pour vous sur un appareil, puis échoue pour tous les autres dès que le build arrive depuis Play. Cela ressemble à une version cassée, ce qui pousse les développeurs à reconstruire quelque chose qui n’a jamais été en cause.
La configuration qui règle le problème
-
01
Ouvrez la liste des testeurs Play Games Services
Dans Play Console: Grow users > Play Games Services > Setup and management > Testers. Cette liste est distincte de la liste de testeurs de votre canal fermé et n’en hérite rien.
-
02
Autorisez les testeurs, ou activez le canal
Ajoutez les comptes un par un, ou activez le canal de publication Play Console concerné pour les tests Play Games Services, afin que toute personne ayant accès au build de test obtienne aussi l’accès Play Games. La seconde option est celle qui tient au-delà d’une poignée de personnes.
-
03
Vérifiez que les identifiants correspondent au build
L’authentification échoue quand le nom de package ou l’empreinte du certificat de signature configurés ne correspondent pas à ce qui a été importé. Dès lors que Play App Signing entre en jeu, l’empreinte dont votre configuration Play Games a besoin est celle qu’utilise Play, pas celle de votre poste de travail.
-
04
Testez chaque fonctionnalité que vous avez réellement activée
La connexion d’abord, puis les succès, les classements et les parties sauvegardées selon l’usage qu’en fait votre jeu. Les parties sauvegardées méritent une attention particulière parce qu’elles touchent à la progression: une sauvegarde qui ne se restaure pas est un bug que vos testeurs ne trouveront que s’ils avancent assez loin pour avoir une progression à restaurer.
| Système | Ce qu’il contrôle | Remplace le test fermé 12/14? | Où cela se configure |
|---|---|---|---|
| Test fermé | Qui peut obtenir le jeu non publié et, pour les comptes personnels concernés, le prérequis d’accès en production lui-même. | C’est le portail obligatoire. | Canal de test fermé de Play Console. |
| Tests Play Games Services | L’accès à une configuration Play Games Services non publiée et à ses API. | Non | Grow users > Play Games Services > Setup and management > Testers. |
| Test interne | Distribution initiale rapide à 100 testeurs maximum. | Non | Un canal de test facultatif distinct. |
| Préinscription | Une campagne de notoriété de lancement sur la boutique. | Non | Désactivée au départ pour les développeurs soumis au prérequis de test. |
Quatre systèmes, quatre listes, un seul jeu. Si cette section existe, c’est que trois de ces quatre-là sont invisibles depuis l’écran du canal fermé: un développeur qui a correctement configuré celui qu’il voit suppose donc raisonnablement que les autres suivent. Ce n’est pas le cas.
Source: Configuration de Play Games Services dans la Console et autorisation des testeurs, qui documente la liste de testeurs, l’alternative du canal activé et les erreurs OAuth et 404 que voit un testeur non autorisé.
Pouvez-vous utiliser la préinscription pendant que votre jeu est en test fermé?
Pas au départ. Pour les développeurs soumis à l’exigence de test des nouveaux comptes personnels, la préinscription fait partie des fonctionnalités désactivées tant que l’exigence n’est pas remplie. Une fois disponible, une campagne de préinscription peut durer jusqu’à 90 jours, et un développeur peut avoir au maximum 2 applications ou jeux en préinscription en même temps.
Ce point fait plus mal aux jeux qu’aux applications, parce que la préinscription est un outil de lancement et qu’un lancement de jeu se planifie généralement à rebours depuis une date. Si votre plan prévoyait une campagne de préinscription en parallèle du test fermé, il faut le réordonner: validez d’abord le prérequis, puis lancez la campagne, puis publiez.
| Étape | Test fermé | Préinscription |
|---|---|---|
| Avant que l’exigence soit remplie | En cours: c’est la fenêtre qualifiante. | Désactivée pour les comptes concernés. |
| Après l’octroi de l’accès en production | Facultatif, et toujours utile pour les mises à jour futures. | Disponible, jusqu’à 90 jours par campagne. |
| Plusieurs titres en parallèle | Chaque nouvelle application doit valider l’exigence pour son propre nom de package. | Au maximum 2 titres en préinscription à la fois. |
| Test ouvert | C’est le canal fermé que nomme le prérequis. | Le test ouvert devient disponible une fois l’accès en production obtenu. |
L’enchaînement concret pour un premier jeu: lancez le test fermé dès que le build est jouable plutôt que d’attendre qu’il paraisse terminé, car la quinzaine se déroule en parallèle du travail que vous faites de toute façon. Le marketing qui dépend des fonctionnalités de la boutique vient après, pas pendant.
Source: l’exigence de test fermé pour les nouveaux comptes personnels (answer 14151465), où Google indique que l’accès en production et la préinscription restent restreints tant que l’exigence n’est pas remplie.
Que doivent réellement faire vos testeurs avec le jeu?
Parcourez les chemins où un jeu casse autrement qu’une application: l’installation livrée par Play, le tutoriel, la boucle principale, la progression sauvegardée d’un redémarrage à l’autre, une session assez longue pour faire chauffer l’appareil, la mise en arrière-plan et la reprise, les téléchargements d’assets, les achats et la connexion Play Games. Google ne publie ni nombre d’appareils requis ni durée de session, alors couvrez l’éventail que votre jeu prend réellement en charge et investissez la profondeur là où votre jeu sort de l’ordinaire.
| Zone de test | À couvrir | Pourquoi cela vaut le temps passé | Statut |
|---|---|---|---|
| Installation et premier lancement | Une installation neuve depuis Play, les autorisations et la première livraison d’assets. | Un jeu qui s’installe en local peut quand même échouer à cause du comportement des splits et des assets livrés par Play. | Pratique QA |
| Tutoriel et prise en main | Chaque étape, plus la navigation arrière et les chemins que les gens empruntent par accident. | L’accès en production interroge sur l’engagement des testeurs, et les premières minutes sont ce que la plupart d’entre eux verront. | Pratique QA |
| Boucle de jeu principale | Assez de jeu pour éprouver les commandes, une victoire, une défaite, un redémarrage et une progression normale. | C’est toute la différence entre un test qui a du sens et une installation passive. | Pratique QA |
| Progression et sauvegardes | Quitter, reprendre, relancer l’application, redémarrer l’appareil et recharger la progression. | La perte de sauvegarde est la panne que les joueurs sanctionnent le plus durement, et il faut quelqu’un qui ait de la progression à perdre pour la détecter. | Pratique QA |
| Performance dans la durée | Jouer bien au-delà de la première minute et guetter la dégradation des images et les saccades. | Android vitals ne commence à mesurer la fréquence d’images qu’après une minute, et la chaleur arrive plus tard encore. | Métrique vitals |
| Diversité des appareils | De vrais appareils couvrant l’éventail pris en charge par votre jeu, pondérés par ce que vos joueurs ont en main. | La couverture doit être fondée sur le risque; aucun nombre fixe d’appareils ou de GPU n’est publié. | Pratique QA |
| Chemins graphiques | Les chemins de rendu et les variantes de textures que votre build embarque réellement. | Le ciblage par compression de textures fait que des appareils différents peuvent recevoir des assets différents. | Pratique QA |
| Mémoire et stabilité | Transitions de niveaux, redémarrages répétés, scènes lourdes et sessions longues. | Les plantages et les ANR sont des métriques de qualité mesurées par Play, avec des seuils publiés. | Métrique vitals |
| Arrière-plan et reprise | Bouton d’accueil, notification qui interrompt, écran éteint puis rallumé, recréation du processus quand c’est praticable. | Les jeux perdent leur état et leur contexte de rendu au moment des changements de cycle de vie plus souvent que les applications. | Pratique QA |
| Livraison des assets | Ceux des modes install-time, fast-follow et on-demand que votre jeu utilise, y compris les téléchargements interrompus. | Ces modes se comportent différemment et un test local ne reproduit pas la livraison par Play. | Limites Google |
| 64 bits | Le build exécuté dans un environnement 64 bits, surtout en présence de plugins natifs. | Google Play exige la prise en charge du 64 bits pour les applications publiées. | Exigence Google |
| Achats intégrés | Accepté, refusé, en attente, consommable racheté, droit accordé et acquittement. | Google fournit des instruments de test de licence précisément pour ces scénarios. | Mécanisme Google |
| Play Games Services | La connexion, plus chaque succès, classement et fonction de partie sauvegardée que vous avez activés. | Les configurations non publiées exigent une autorisation de testeur distincte et des identifiants concordants. | Exigence Google |
| Déclarations de contenu | Le questionnaire de classification, le public cible et tout affichage des probabilités sur les objets aléatoires. | Une classification inexacte ou une divulgation manquante est un risque de non-conformité, indépendamment du test. | Règle Google |
Donnez un parcours à vos testeurs, pas une consigne du genre « testez-le »
Le moyen le plus rapide de transformer douze installations en douze rapports utiles, c’est de remettre aux gens un court parcours numéroté dans le jeu, avec une chose à observer à chaque étape et une question à laquelle vous voulez vraiment une réponse. Les testeurs à qui l’on demande d’explorer ne rapportent rien; ceux à qui l’on dit « atteignez le niveau trois, puis fermez le jeu, puis rouvrez-le, et dites-moi si votre progression est toujours là » signalent le bug de sauvegarde le deuxième jour plutôt que le treizième. Les émulateurs ne peuvent rien pour les lignes ci-dessus qui dépendent de la chaleur, de vrais GPU ou de vraies conditions réseau, et les risques qu’il y a à s’appuyer sur eux sont traités dans l’article sur les émulateurs en test fermé.
Pourquoi Google réclame-t-il 14 jours de plus une fois les 12 testeurs atteints?
Parce que l’accès en production examine la qualité du test, pas seulement le compteur. Google demande ce que les testeurs ont fait, quels commentaires ils ont donnés et ce que vous avez changé, et il cite des testeurs peu engagés avec votre application comme motif possible d’exiger des tests supplémentaires. Atteindre 12 et 14 est le plancher d’éligibilité, pas une approbation.
Les développeurs rapportent régulièrement ce dénouement: les chiffres étaient atteints, la demande est partie, et la réponse a été davantage de tests. Rapporté par la communauté Les fils de discussion concordent sur l’expérience vécue et sont bien moins fiables sur la cause, puisque personne hors de Google ne voit le raisonnement. Ce que la documentation de Google permet d’affirmer, c’est que l’engagement et les commentaires font partie de ce qui est évalué, et cela suffit pour agir.
| Symptôme | À vérifier en premier | La correction factuelle |
|---|---|---|
| Play indique qu’il n’y a pas assez de testeurs éligibles | Quelqu’un n’a jamais terminé son inscription, quelqu’un est parti, ou la fenêtre continue n’est pas terminée. | Vérifiez qu’au moins 12 comptes éligibles sont restés inscrits sans interruption pendant toute la fenêtre requise. |
| 12 testeurs et 14 jours faits, accès refusé | Google a jugé que davantage de tests étaient nécessaires, ce qui peut recouvrir un engagement faible ou une collecte de commentaires trop mince. | Lisez la réponse, continuez à tester sérieusement, recueillez de vrais commentaires, corrigez ce qu’ils révèlent et répondez avec exactitude dans la demande. |
| Le jeu marche en local, les assets échouent depuis Play | Mode de livraison des assets, comportement de mise à jour ou pression sur le stockage différents de votre environnement local. | Testez le build livré par Play et gérez la disponibilité des packs et les états de mise à jour, au lieu de supposer que le comportement local se transpose. |
| Le jeu saccade après une longue session de jeu | Goulet d’étranglement CPU ou GPU, bridage thermique, cadencement des images ou fréquence de rafraîchissement mal accordée. | Profilez des sessions longues et l’état thermique plutôt que des sessions courtes, avec l’outillage de performance de jeu Android. |
| La boîte de dialogue d’achat affiche une vraie carte | Le compte n’agit pas comme testeur de licence, ou c’est un autre compte de l’appareil qui achète. | Ajoutez le compte visé sous Settings > License testing et vérifiez quel compte a téléchargé le build. |
| Achat de test remboursé quelques minutes plus tard | L’achat n’a jamais été acquitté. | Corrigez la logique d’acquittement ou de consommation. Les achats en test de licence sont remboursés automatiquement au bout de 3 minutes s’ils ne sont pas acquittés. |
| La connexion Play Games renvoie une erreur OAuth ou 404 | Le testeur n’est pas autorisé pour la configuration Play Games non publiée. | Ajoutez le testeur Play Games individuellement, ou activez le canal de publication pour les tests Play Games. |
| Play Games fonctionnait, puis a cassé après l’import | Une discordance de nom de package ou de certificat de signature entre la configuration et le build importé. | Vérifiez l’empreinte Play App Signing, le nom de package et l’identifiant associé. |
| Jeu natif absent sur certains appareils | Une lacune de prise en charge des ABI ou du 64 bits. | Vérifiez qu’une bibliothèque 64 bits correspondante existe pour chaque architecture native prise en charge, et testez dans un environnement 64 bits. |
| Signalé pour fonctionnalité cassée ou insignifiante | Le jeu plante, ne se charge pas, ou n’offre aucune fonctionnalité opérante. | Corrigez les problèmes fonctionnels. N’allez pas chercher un nombre minimal de niveaux imaginaire à satisfaire. |
| Achat d’objet aléatoire remis en question | Les probabilités des objets aléatoires payants ne sont pas affichées là où les joueurs les voient. | Affichez les probabilités avant l’achat et juste à côté de celui-ci. |
À quoi devrait ressembler un second cycle
Si l’on vous demande davantage de tests, la tentation est de refaire le premier passage avec le même schéma d’installations passives, en espérant une autre réponse. Un second cycle utile change quelque chose de réel: gardez le groupe stable, donnez aux testeurs un véritable parcours dans le jeu, consignez par écrit ce qu’ils rapportent, livrez les correctifs que leurs commentaires justifient, et décrivez tout cela simplement au moment de redéposer la demande. Ce n’est pas un hasard: c’est aussi ce qui produit un meilleur jeu.
Ce qu’il ne doit pas comporter, c’est un rituel inventé. Il n’existe aucun nombre de lancements publié, aucun nombre de mises à jour imposé et aucun quota de jeu quotidien qui transforme un refus en approbation, et personne ne peut vous promettre qu’un schéma d’activité particulier changera la décision de Google. Plus de détails sur les motifs de refus en général dans l’article sur les raisons pour lesquelles un test fermé est refusé.
Échéances clés de Google Play pour les éditeurs de jeux en 2026 et début 2027
Le 31 août 2026 est passé: les jeux mobiles nouveaux et mis à jour doivent cibler Android 16 (niveau d’API 36) ou une version ultérieure, et Play Billing Library 7 a dépassé son échéance pour les nouvelles applications et les mises à jour. Si vous disposez d’une prolongation, elle court jusqu’au 1er novembre 2026, dans 57 jours.
Trois autres échéances les entourent: le 30 septembre 2026 pour l’enregistrement des noms de package Play et pour la première vague d’application de la vérification des développeurs, et le 1er février 2027 pour les pages mémoire de 16 KB, celle qui a le plus de chances de rattraper un jeu bâti sur un moteur. Aucune ne fait partie de l’exigence de testeurs, et chacune peut bloquer la publication que cette exigence est censée débloquer.
| Date | Exigence | Ce que cela implique pour un jeu |
|---|---|---|
| 31 août 2026 | Niveau d’API cible | Les jeux mobiles nouveaux et mis à jour doivent cibler Android 16, niveau d’API 36 ou ultérieur. Les autres facteurs de forme diffèrent: Wear OS et Android Automotive OS demandent l’API 35, Android TV et Android XR l’API 34. Détail complet dans l’article sur le niveau d’API cible. |
| 31 août 2026 | Play Billing Library | Play Billing Library 7 atteint son échéance pour les nouvelles applications et pour les mises à jour. Les jeux monétisés doivent passer à une version ultérieure prise en charge pour leurs nouvelles versions, sauf prolongation. |
| 30 septembre 2026 | Enregistrement des noms de package Play | Toute application ou tout jeu Play dont le nom de package n’est toujours pas enregistré à cette date risque d’être retiré de Play. La mesure s’applique partout et n’a rien à voir avec l’ancienneté de votre compte. |
| 30 septembre 2026 | Vérification des développeurs, première vague | Première application de la vérification des développeurs Android, pour les installations passant par les boutiques participantes au Brésil, en Indonésie, à Singapour et en Thaïlande. Ce n’est pas une coupure mondiale. Détail dans l’article sur la vérification des développeurs. |
| 1er novembre 2026 | Fin de la prolongation | La dernière date couverte par la prolongation disponible, à la fois pour l’exigence de ciblage et pour Play Billing Library 7. Les prolongations se demandent depuis l’avertissement correspondant dans Play Console, elles ne sont pas accordées automatiquement. |
| 1er février 2027 | Pages mémoire de 16 KB | Les mises à jour concernées qui ciblent le niveau d’API 35 ou ultérieur et embarquent du code natif ne peuvent pas être publiées sans compatibilité avec les pages de 16 KB. Les binaires du moteur et des plugins sont exactement là où cela fait mal. Marche à suivre dans l’article sur l’erreur 16 KB. |
| 27 janvier 2027 | Autorisations Contacts | Ne concerne que les applications ciblant Android 17, niveau d’API 37 ou ultérieur, qui utilisent l’accès étendu aux contacts visé, ce que la plupart des jeux ne demandent jamais. Le calendrier des règles de Google et le tableau des échéances de l’aide Play Console indiquent désormais tous deux cette date. |
Ces dates bougent sans annonce
Revérifiez avant de planifier Google publie les dates limites de ses règles sur deux surfaces qui divergent, puis sont réconciliées en silence. Les échéances contacts et localisation ci-dessus indiquaient le 28 octobre 2026 sur le calendrier Android Developers jusqu’à la mi-août 2026, lorsque cette page a été modifiée en 27 janvier 2027 pour s’aligner sur l’aide Play Console, sans aucune entrée dans le journal des modifications. D’anciennes newsletters de Google citent encore la date abandonnée. Confrontez le tableau des échéances de l’aide Play Console et le calendrier des règles avant de bâtir un plan de publication sur l’une des lignes ci-dessus, et ne croyez ni une newsletter ni un article de blog davantage que les pages en ligne. Une ligne reste en désaccord aujourd’hui: Child Safety Standards est au 26 août 2026 dans le tableau de l’aide et au 28 octobre 2026 sur le calendrier. Préparez-vous pour le 26 août.
Sources: les exigences de niveau d’API cible (answer 11926878) pour les dates de ciblage du 31 août et les niveaux par facteur de forme, et les deux surfaces de règles de Google pour le reste: le tableau des échéances de l’aide Play Console et le calendrier des règles Android Developers.
Autant le dire simplement, parce que l’enchaînement piège beaucoup de monde: aucune de ces dates n’a le moindre rapport avec l’exigence de testeurs, et valider cette exigence ne vous dispense d’aucune d’entre elles. Un jeu peut terminer un test fermé de 14 jours impeccable et rester impubliable parce que le build cible le mauvais niveau d’API. Vérifiez les exigences qui bloquent la publication avant de commencer la quinzaine, pas après.
Où trouver 12 vrais testeurs pour un jeu?
Les recruter est la partie que la plupart des développeurs solo sous-estiment. L’exigence de test publiée par Google ne prescrit pas la façon dont les testeurs doivent être recrutés: payer pour de la QA n’est donc pas disqualifiant en soi, mais lisez cela comme l’absence d’interdiction, et non comme un aval de Google aux services de testeurs en tant que catégorie, car Google n’a publié aucun aval de ce genre. Ce que les règles de Google interdisent, c’est de manipuler les notes, les avis, le classement ou le nombre d’installations par des moyens illégitimes: bots, faux comptes, installations frauduleuses, engagement manipulé. La barre à franchir, ce sont de vraies personnes qui testent réellement et donnent des commentaires honnêtes, quelle que soit la façon dont vous les avez trouvées.
Si les communautés de moteurs de jeu débordent de messages « besoin de 12 testeurs », c’est une affaire d’arithmétique: un développeur de jeu débutant ne connaît généralement pas douze personnes qui possèdent un téléphone Android, iront au bout d’une inscription et seront encore inscrites quinze jours plus tard. Les amis installent, jouent une fois par politesse, puis s’éloignent. Rien là-dedans n’est un défaut de caractère. C’est simplement qu’un service rendu a une demi-vie d’environ trois jours, alors que l’exigence, elle, court sur quatorze.
Les groupes d’échange de testeurs règlent le décompte et souvent pas grand-chose d’autre, parce qu’un partenaire d’échange a exactement la même motivation que vous: s’inscrire, rester inscrit, passer à autre chose. Cela satisfait le compteur tout en produisant précisément le schéma d’engagement passif sur lequel Google vous interroge dans le formulaire de demande. Pour un jeu, c’est pire que pour une application, parce que les défaillances qui comptent se logent plusieurs sessions plus loin, et un testeur réciproque n’ira jamais jusque-là.
Ce que couvre un test géré
PrimeTestLab fournit 12 testeurs réels sur de vrais appareils, d’Android 7 à 17, inscrits et maintenus pendant les 14 jours complets, le test démarrant en 4-6 heures. Nous l’avons fait sur 7 400+ applications dans 120+ pays avec un taux de réussite de 99.9%, et le cycle est couvert par un nouveau test gratuit ou un remboursement intégral. Les plans démarrent à $19.99.
Soyons clairs sur la frontière, parce qu’un jeu comporte des parties que personne ne peut reprendre à votre place: un test géré tient le volet testeurs de la quinzaine. Il ne reconstruit pas vos packs d’assets, n’optimise pas vos temps par image, n’implémente pas l’acquittement dans votre code de facturation et ne remplit pas votre questionnaire de classification. Cela vous revient, et les sections ci-dessus existent pour raccourcir ce travail. Ce qui disparaît, c’est la course au recrutement et le risque de voir le groupe s’effondrer le neuvième jour.
Recruter vous-même ou passer par un test géré
| L’exigence de Google | Recruter vous-même | Un test géré |
|---|---|---|
| Au moins 12 testeurs inscrits | Trouver, briefer et relancer de vraies personnes, puis espérer que chacune aille au bout de l’inscription. | 12 fournis et maintenus pendant toute la fenêtre. |
| 14 jours sans interruption | Un désistement ne vous coûte le cycle que s’il laisse moins de 12 testeurs capables de justifier chacun 14 jours sans interruption au moment de la demande. | Le groupe est surveillé pour que la fenêtre reste intacte. |
| Appareils réels, personnes réelles | Les émulateurs et les comptes dormants sont le raccourci habituel, et la raison habituelle pour laquelle un cycle ne produit rien à raconter. | De vrais appareils, d’Android 7 à 17. |
| Un engagement dont vous pouvez parler à Google | Dépend entièrement du fait que vos testeurs jouent ou non au-delà du tutoriel. | Des testeurs qui jouent au jeu plutôt que de le laisser dormir sur un écran d’accueil. |
| Délai avant la première inscription | Des jours, selon qui vous répond. | Le test démarre en 4-6 heures. |
| Coût | Votre temps, pendant la quinzaine que vous consacrez déjà au build. | À partir de $19.99, avec un nouveau test gratuit ou un remboursement intégral. |
Une chose qu’aucun service ne peut offrir, et méfiez-vous de quiconque le prétend: l’accès en production lui-même. C’est Google qui en décide, il pèse la qualité de votre test autant que le décompte, et il peut demander un nouveau cycle. Ce qui peut être promis, c’est le groupe de testeurs, la quinzaine et la garantie qui va avec. Voir les plans et ce que chacun comprend →
Questions fréquentes
Les jeux ont-ils besoin de 12 testeurs pendant 14 jours sur Google Play?
Oui, lorsque le jeu est publié depuis un compte de développeur Google Play personnel créé après le 13 novembre 2023. Google exige qu’au moins 12 testeurs soient inscrits sans interruption à un test fermé pendant au moins les 14 derniers jours avant que ce développeur puisse demander un accès en production, et aucun minimum de testeurs propre aux jeux n’apparaît nulle part dans la documentation actuelle. Google traite les applications et les jeux à l’intérieur du même processus d’accès en production.
Je lis partout qu’il faut 20 testeurs. Est-ce 12 ou 20 en 2026?
C’est 12. Google exigeait à l’origine 20 testeurs et a officiellement abaissé le minimum à 12 le 11 décembre 2024, décrivant le changement comme exigeant 12 testeurs au lieu de 20. La période de test continue de deux semaines n’a pas changé. Les pages qui citent encore 20 ont été écrites avant cette modification.
Chaque nouveau jeu a-t-il besoin de son propre test fermé?
Oui, pour les comptes de développeur personnels concernés. La date de création du compte détermine si l’exigence s’applique à vous, mais Google formule la condition comme un test fermé « pour votre application », et la demande d’accès en production se dépose pour un nom de package précis. Un test qualifiant pour un jeu ne se reporte pas sur le jeu suivant que vous publiez depuis le même compte.
Mes 12 testeurs doivent-ils jouer au jeu tous les jours?
L’inscription continue est la règle explicite. Google exige que les testeurs qualifiants restent inscrits sans interruption et indique que leur engagement compte au moment où il examine l’accès en production, mais il ne publie aucune règle du type ouvrir le jeu une fois par jour ou jouer un nombre de minutes défini. De vraies sessions de jeu utiles, avec des commentaires exploitables, sont l’objectif sûr. Un quota de jeu quotidien relève du folklore communautaire, pas des règles.
Le départ d’un seul testeur relance-t-il les 14 jours en entier?
Pas automatiquement. Au moment de votre demande, au moins 12 testeurs doivent chacun être restés inscrits pendant les 14 jours consécutifs précédents. Si vous avez démarré avec plus de 12 testeurs et qu’il vous en reste autant qui remplissent la condition, un désistement n’invalide pas le test. Si ce désistement vous laisse à onze, vous devez attendre qu’un testeur de remplacement ait accompli sa propre période continue de 14 jours. C’est l’argument en faveur d’un recrutement au-dessus du minimum.
Puis-je importer un nouveau build du jeu pendant le test de 14 jours?
Oui. La condition qualifiante publiée par Google repose sur l’historique d’inscription des testeurs, pas sur le maintien d’un build figé pendant 14 jours: publier une nouvelle version n’efface donc pas en soi la période d’inscription continue des testeurs. Laissez à la nouvelle version le temps d’achever son traitement, demandez aux testeurs de mettre à jour, et continuez à documenter les commentaires et les correctifs qui en découlent. Google note que les modifications apportées à un test peuvent mettre plusieurs heures à parvenir aux testeurs.
Suffit-il de laisser mon jeu installé pendant 14 jours?
Ne prenez pas la simple installation pour une preuve de test. Le prérequis chiffré est l’inscription continue, mais la demande d’accès en production porte sur la façon dont les testeurs se sont engagés avec le jeu, les commentaires recueillis et ce qui a changé en conséquence. Google cite des testeurs qui ne se sont pas engagés avec votre application comme un motif pour lequel il peut exiger des tests supplémentaires.
Désinstaller le jeu remet-il à zéro le test de 14 jours?
Google ne publie aucune règle distincte selon laquelle une désinstallation remettrait à elle seule la période d’inscription à zéro; l’exigence chiffrée explicite porte sur l’inscription continue. Mais un jeu désinstallé ne produit ni session de jeu, ni commentaires, ni preuve de test, et Google peut exiger des tests supplémentaires quand l’engagement est insuffisant. Rester inscrit sans jamais ouvrir le jeu n’est pas une stratégie sûre et, pour un jeu, cela signifie aussi que personne n’éprouve les chemins de sauvegarde, de livraison des assets et de performance qui cassent réellement.
Puis-je utiliser le test interne à la place du test fermé à 12 personnes?
Pas pour ce prérequis. Le test interne est un canal distinct qui accepte jusqu’à 100 testeurs, mais l’exigence de Google pour les nouveaux comptes personnels concernés impose spécifiquement un test fermé qualifiant avant toute demande d’accès en production. Le test interne est utile pour distribuer vite et tôt; il ne remplit pas l’étape de test fermé exigée.
Quelle taille mon jeu Android peut-il atteindre sur Google Play en 2026?
L’aide Play Console indique un module de base de 500 MB, 500 MB par module de fonctionnalité, 1.5 GB par pack d’assets, 4 GB cumulés pour l’ensemble des modules et des packs d’assets install-time, 30 GB cumulés pour les packs fast-follow et on-demand, et une taille de téléchargement compressée totale maximale de 34 GB, avec un maximum de 100 packs d’assets par bundle. Ce sont des tailles de téléchargement compressées calculées par Play Console, et non la taille du bundle sur votre disque. Valeurs vérifiées le 12 août 2026.
Les testeurs doivent-ils acheter un jeu payant pendant le test fermé?
Oui. Les testeurs d’un test ouvert ou fermé doivent toujours acheter un jeu payant. Les testeurs du canal de test interne peuvent installer un jeu payant gratuitement. C’est un mécanisme distinct du test de licence pour les achats intégrés, qui détermine si un IAP passe par les moyens de paiement de test de Google plutôt que par un débit réel.
Pourquoi Google Play débite-t-il mes joueurs du test fermé pour les achats intégrés?
Appartenir au canal fermé et être testeur de licence pour la facturation sont deux choses différentes. Google indique que les utilisateurs sont réellement débités à moins d’être testeurs de licence: un testeur ordinaire de votre canal fermé peut donc être débité en argent réel. Ajoutez les comptes destinés au test des achats sous Settings puis License testing pour obtenir les moyens de paiement de test de Google, y compris les scénarios qui approuvent toujours, refusent toujours et se déclenchent en différé.
Pourquoi la connexion Google Play Games échoue-t-elle sur mon jeu en test fermé?
Play Games Services possède sa propre couche d’accès. Tant que la configuration Play Games Services n’est pas publiée, les testeurs doivent être autorisés individuellement ou via un canal de publication Play Console activé, faute de quoi Google indique qu’ils rencontreront des erreurs OAuth et 404. Ajoutez-les sous Grow users, Play Games Services, Setup and management, Testers, et vérifiez que le nom de package et l’empreinte du certificat de signature correspondent au build.
Un jeu petit ou simple est-il refusé pour fonctionnalités insuffisantes?
Google applique une règle de fonctionnalité et de qualité qui exige des expériences stables, réactives et suffisamment fonctionnelles, et les applications ou jeux qui plantent, ne se chargent pas ou restent concrètement inutilisables peuvent l’enfreindre. Aucune source primaire de Google ne publie de nombre minimal fixe de niveaux, d’écrans, de mécaniques ou de minutes de jeu. Tenez tout chiffre précis que vous lisez pour du folklore et corrigez plutôt les vrais problèmes fonctionnels.
Les loot boxes font-elles automatiquement d’un jeu Android une application de jeux d’argent?
Non. Les règles de Google distinguent les objets virtuels aléatoires payants des jeux d’argent réel. Les jeux qui proposent des objets virtuels aléatoires comme des loot boxes doivent afficher clairement les probabilités avant l’achat et juste à côté de celui-ci. Payer de l’argent ou une valeur achetée pour tenter de gagner un lot réel relève de la règle distincte de Google sur les jeux d’argent, jeux et concours en argent réel, un régime différent avec ses propres critères d’éligibilité et ses propres exigences de licence.
Quelqu’un d’autre peut-il fournir les 12 testeurs de mon jeu?
Oui. L’exigence de test de Google ne prescrit pas la façon dont les testeurs doivent être recrutés: payer pour de la QA n’est donc pas disqualifiant en soi. Lisez cela comme l’absence d’interdiction, et non comme un aval de Google aux services de testeurs, qu’il n’a jamais donné. Ce qui enfreint les règles, c’est de manipuler les notes, les avis, le classement ou le nombre d’installations par des moyens illégitimes: bots, faux comptes ou installations frauduleuses. PrimeTestLab fournit 12 testeurs réels sur de vrais appareils à partir de $19.99, maintient le groupe inscrit pendant les 14 jours complets et couvre le cycle par un nouveau test gratuit ou un remboursement intégral. Personne ne peut promettre l’accès en production, car cette décision appartient à Google, qui pèse la qualité de votre test autant que le nombre.
L’essentiel
Résumé
Google Play ne prévoit aucune clause propre aux jeux. Un compte de développeur personnel créé après le 13 novembre 2023 doit réunir 12 testeurs inscrits pendant 14 jours sans interruption avant de pouvoir demander un accès en production, qu’il publie un jeu ou une calculatrice, et le chiffre 20 qui circule encore a été remplacé le 11 décembre 2024. Valider ce compteur est le plancher, pas le verdict: Google demande ce que vos testeurs ont fait, ce qu’ils vous ont dit et ce que vous avez changé. Un jeu affronte ensuite une seconde couche que le compteur ne touche jamais, et c’est là que la quinzaine vaut vraiment quelque chose: des packs d’assets qui ne déraillent qu’une fois livrés par Play, des images qui ralentissent quand le téléphone chauffe, des binaires natifs 64 bits, des testeurs débités en argent réel parce que personne n’a été ajouté sous Settings > License testing, une connexion Play Games qui renvoie 404 à tout le monde sauf à vous, et l’affichage des probabilités sur les objets aléatoires. Testez tout cela pendant la quinzaine que vous passez de toute façon. Si c’est le volet testeurs que vous ne pouvez pas assurer, PrimeTestLab fournit 12 testeurs réels à partir de $19.99, avec un nouveau test gratuit ou un remboursement intégral. Voir les plans tarifaires →
Sources primaires
Ce qui, sur cette page, se périmera en premier
- Les limites de taille. Le tableau le plus risqué de cette page. La page dédiée aux tailles dans Play Console et certaines anciennes pages Android consacrées aux jeux se contredisent déjà, et les plafonds fast-follow et on-demand semblent avoir été relevés récemment. Revérifiez la page des tailles avant de planifier une version autour de 30 GB ou 34 GB.
- Les dates de facturation. Les fenêtres de prise en charge de Play Billing Library bougent version après version, et les dates du 31 août et du 1er novembre citées ici changent de sens dès qu’elles sont passées. Cette page bascule sa propre formulation à ces dates; le tableau de prise en charge sous-jacent reste à relire.
- Les dates limites des règles. L’élément le plus mouvant de cette page. Google a déplacé les échéances contacts et localisation du 28 octobre 2026 au 27 janvier 2027 sur une seule surface à la mi-août 2026, sans annonce, et ses propres newsletters ont continué à citer la date abandonnée. Tranchez toute date de cette page à partir des deux pages de règles en ligne de Google, plutôt qu’à partir d’une newsletter ou d’un article, celui-ci compris.
- Les chemins dans la Console. Settings > License testing, Policy > App content et le chemin des testeurs Play Games Services correspondent à la formulation actuelle, et la navigation de la Console évolue indépendamment des règles.
- Les seuils Android vitals. Les valeurs de plantages, d’ANR et de sessions lentes sont des seuils de qualité que Google peut réviser selon son propre calendrier, séparément de tout ce qui touche aux exigences de test.
- Les nombres de testeurs. Le point le moins risqué de la liste, mais 20 est déjà devenu 12 une fois. Si un nombre indiqué ici contredit la page de Google, c’est la page de Google qui a raison et celle-ci qui a vieilli.
Vérifié auprès de la documentation de Google le 12 août 2026. Dates limites des règles revérifiées le 14 août 2026.