Google Play exige 12 testeurs. Nous les avons.

L’exigence est arrivée fin 2023, quand Google a durci les règles pour les nouveaux comptes de développeur personnels. L’objectif affiché est la qualité: les apps doivent atteindre la boutique publique après avoir été réellement utilisées par de vraies personnes, pas directement depuis une machine de build. Pour Google, deux semaines d’activité de test réelle filtrent les soumissions bâclées et le spam bien plus sûrement qu’une revue de code.

L’exigence a d’ailleurs démarré plus dure qu’aujourd’hui: les nouveaux comptes devaient réunir 20 testeurs, et Google a réduit le nombre à 12 en décembre 2024 en gardant la même durée de 14 jours. Si un fil de forum réclame 20 testeurs, il est obsolète; notre article sur le passage de 20 à 12 testeurs (en anglais) donne les détails.

Un point sur lequel Google est clair: la façon de trouver vos testeurs vous appartient. Amis, collègues, communautés ou un service de testeurs payant sont tous acceptables, car Google ne restreint ni qui sont vos testeurs ni comment vous les recrutez. Ce qui viole la politique, c’est l’activité artificielle: bots, fermes d’émulateurs et installations incitées qui ne reflètent pas un usage réel. Cette distinction est exactement la raison pour laquelle nous ne faisons tourner que de vraies personnes sur de vrais appareils.

La plupart des tentatives échouées que nous reprenons ont enfreint l’une de ces cinq règles:

1. Ajouté n’est pas inscrit. Coller des e-mails dans la liste de testeurs ne fait qu’envoyer des invitations. Chaque testeur doit ouvrir votre lien de test et accepter avant que Google ne le compte. Ajouter 12 personnes et en voir 0 comptées est la confusion la plus fréquente que nous voyons; voici pourquoi les testeurs ajoutés apparaissent comme non comptés.
2. Les 14 jours sont sans interruption. Google cherche une fenêtre continue avec au moins 12 testeurs inscrits. Si votre effectif tombe à 11 au jour 9, la série est cassée et la fenêtre repart de zéro. C’est ainsi que "presque fini" devient la quatrième semaine.
3. C’est par application, pas par compte. Valider l’exigence une fois ne débloque pas votre compte; chaque nouvelle app (chaque nouveau nom de package) exécute son propre test fermé. Prévoyez-le si vous lancez un portefeuille; voir faut-il 12 testeurs pour chaque app.
4. Mettre à jour votre app ne pose aucun problème. Déployer de nouvelles versions pendant le test ne remet pas le compteur à zéro; Google vous encourage à itérer pendant le test. Ce qui casse la progression, c’est de perdre des testeurs, pas de publier des correctifs. Détails dans mettre à jour son app pendant le test fermé.
5. Se désinscrire n’est pas désinstaller. Un testeur qui se désinscrit cesse de compter même si l’app reste sur son téléphone. Les volontaires occasionnels se désinscrivent discrètement tout le temps; c’est pourquoi les tests menés avec exactement 12 vagues connaissances échouent si souvent.

Jour 0. Vous commandez avec une simple adresse e-mail et recevez votre liste de testeurs en CSV sous 4-6 heures, tous les jours de la semaine. Vous la collez dans la Play Console, vous nous partagez votre lien de test, et nos testeurs commencent à accepter le jour même. Votre part prend environ 7 minutes; si vous bloquez, le support vous guide sur WhatsApp.

Jours 1 à 14. 12 testeurs vérifiés ou plus (20 ou 25 sur les plans supérieurs, pour qu’un abandon ne fasse jamais couler l’effectif) utilisent votre app chaque jour sur leurs propres appareils Android. Vous suivez le nombre d’inscrits et la série de jours en direct sur votre tableau de bord, et si un testeur décroche, nous le remplaçons immédiatement depuis le même vivier. C’est la partie difficile à reproduire avec des volontaires: garder 12 inconnus actifs chaque jour pendant deux semaines.

Jour 14 et après. Vous demandez l’accès en production et répondez au questionnaire de Google. Nous vous remettons des réponses qui ont fonctionné plus de 7 400 fois, et si Google demande plus de tests, nous relançons le cycle gratuitement. Sur l’ensemble de ces apps, notre taux de réussite est de 99.9%. La page du processus complet montre chaque étape avec des captures, ou allez directement aux tarifs.

Un testeur réel est une personne réelle avec son propre compte Google, qui utilise votre app sur un appareil Android physique. Notre vivier couvre Samsung, Pixel, Xiaomi, OnePlus et d’autres appareils du quotidien dans 120+ pays, ce qui expose aussi votre app à un éventail de tailles d’écran, de versions d’Android et de conditions réseau qu’un simple cercle d’amis ne couvre jamais.

La localisation des testeurs ne joue aucun rôle dans l’exigence. L’accès en production et la disponibilité sur la boutique sont deux portes distinctes: Google compte les testeurs inscrits où qu’ils vivent, et les pays de lancement de votre app sont ceux que vous sélectionnez dans votre fiche. Si vos testeurs sont dans 15 pays et que votre app ne vise que le Canada, tout va bien; notre article sur les testeurs dans différents pays détaille les deux portes.

Ce qui ne compte pas: les émulateurs, les fermes d’appareils et les comptes bots. En général, ils ne sont pas comptés comme de vrais testeurs et peuvent être détectés, et c’est le compte qui les paie qui prend le risque. C’est le vrai coût caché des missions de testeurs à cinq dollars, et c’est pourquoi émulateurs et test fermé ne font pas bon ménage. Nous n’y touchons jamais, point final.

Trois choses, toutes vérifiables avant de payer. D’abord, un tableau de bord en direct sur notre site qui suit chaque testeur et chaque jour de votre fenêtre de 14 jours, pour toujours savoir exactement où en est votre test. Ensuite, des notes de bugs à mesure que nos testeurs rencontrent des problèmes, classées par sévérité et priorité. Enfin, un rapport final en PDF à la fin du cycle: de base sur Starter, détaillé sur Professional, complet sur Enterprise. Vous pouvez ouvrir un vrai rapport client (en anglais) dès maintenant et voir le format exact.

Derrière les livrables, la garantie: si votre app n’est pas approuvée après nos tests, vous choisissez entre un nouveau test gratuit et un remboursement intégral. Cette promesse est écrite dans notre politique de remboursement, pas seulement sur cette page.

Quand la console indique que l’exigence est remplie, le bouton de demande d’accès en production se débloque. Google vous pose alors un court questionnaire en trois sections: sur votre test fermé, sur votre app et sur votre préparation à la production. Les réponses comptent; les réponses vagues sont une cause fréquente de refus. Nous remettons à chaque client des réponses éprouvées pour le questionnaire à adapter, fondées sur ce qui a réellement passé l’examen.

Google indique que l’examen de production prend généralement 7 jours ou moins, même s’il peut parfois durer plus longtemps, et dans notre expérience la plupart des apps le passent confortablement dans cette fenêtre. Une fois l’approbation obtenue, votre app est en ligne sur Google Play et l’exigence du test fermé est derrière vous pour cette app, définitivement. Si Google émet des réserves à la place, vous ne repartez pas seul: nous relançons le cycle de 14 jours sans frais et restons avec vous jusqu’à l’arrivée de l’e-mail d’approbation. Cet e-mail est toute la raison d’être de cette page, et vos 12 testeurs sont prêts quand vous l’êtes.

L’exigence des 12 testeurs s’applique à un seul groupe: les comptes de développeur personnels créés après le 13 novembre 2023. Si c’est vous, et pour presque chaque développeur solo qui s’inscrit aujourd’hui c’est le cas, le test fermé est obligatoire. Deux groupes sont exemptés: les comptes d’organisation et les comptes personnels antérieurs à cette date.

En lisant cela, certains développeurs envisagent de s’inscrire comme organisation juste pour éviter la porte de test. Pour la plupart, le remède est pire que le mal. Un compte d’organisation demande un numéro D-U-N-S, dont Google précise qu’il peut prendre jusqu’à 28 jours à obtenir ou vérifier, plus des informations d’entreprise qu’un développeur solo n’a souvent pas. Autrement dit, l’échappatoire peut prendre deux fois plus de temps que d’exécuter simplement le test de 14 jours, et elle change la façon dont votre nom de développeur apparaît sur la boutique. Il existe de bonnes raisons de s’inscrire comme organisation (une vraie société, l’accès en équipe, certaines catégories d’apps), mais esquiver le test fermé en fait rarement partie.

Si vous hésitez vraiment, notre article sur compte personnel ou compte d’organisation déroule la décision. En résumé: inscrivez le type de compte qui correspond à qui vous êtes, et si cela vous met sur la route des 12 testeurs, cette route est exactement ce pour quoi cette page et ce service existent.

Voici la séquence complète pour un tout nouveau compte personnel, avec des délais réalistes. Vous payez les $25 d’inscription uniques et terminez la vérification d’identité de Google. Vous importez (téléversez) votre app en app bundle et, si vous voulez une vérification rapide, poussez-la d’abord en test interne, disponible en quelques minutes (même si le lien du test interne peut mettre quelques heures à apparaître après une première publication). Le test interne est facultatif et ne compte pas pour l’exigence.

Puis la partie qui dicte le calendrier: le test fermé. La configuration avec nous prend 4-6 heures, le test lui-même dure un incompressible 14 jours, pour nous comme pour n’importe qui. Après le jour 14, vous demandez la production, et l’examen de Google prend généralement 7 jours ou moins. Au total, pour un premier essai propre, comptez environ trois semaines entre les frais d’inscription et l’app en ligne, dont le test de 14 jours est le plancher, tout le reste étant marginal.

Le pire ennemi du calendrier n’est pas l’examen de Google; c’est une série cassée. Chaque jour où le nombre d’inscrits passe sous 12, la fenêtre repart et le calendrier glisse de deux semaines de plus. C’est l’argument le plus fort pour mener le test avec des testeurs encadrés et une marge. Si vous venez de payer les frais et vous demandez par quoi commencer, ouvrez notre feuille de route pour les nouveaux comptes développeur.

Vous n’avez pas besoin de nous. Cela mérite d’être dit clairement: recruter vos propres testeurs est gratuit, autorisé, et fonctionne quand vous avez vraiment les personnes. La vraie question est de savoir si vous avez 12 humains engagés qui ouvriront votre app chaque jour pendant 14 jours, plus quelques remplaçants pour ceux qui décrochent en silence. Les amis et la famille disent oui puis oublient au cinquième jour. Les communautés et les groupes d’échange de testeurs peuvent remplir une liste, mais l’échange vous coûte des heures à tester les apps des autres, et des inconnus ne vous doivent rien au neuvième jour. Notre article sur les sept façons légitimes d’obtenir 12 testeurs couvre chaque piste avec son vrai coût.

Le schéma que nous voyons dans les tentatives solo échouées est toujours le même: un bon départ, l’attrition en deuxième semaine, une série cassée découverte trop tard, et on recommence. Répétez cela deux fois et une méthode gratuite a coûté six semaines de retard de lancement.

Le raccourci à cinq dollars est la seule option que nous vous déconseillons formellement: les missions de "testeurs" en masse tournent sur des émulateurs et des comptes bots qui, en général, ne comptent pas et peuvent être détectés, et le compte qui prend ce risque est le vôtre. Un service encadré coûte plus que $5 et moins que votre temps: dès $19.99, un seul paiement, un effectif garanti avec remplaçants, un rapport écrit et une garantie de remboursement. Si la date de lancement compte, le calcul est vite fait. Comparez les plans et décidez avec les chiffres sous les yeux.

Une tentative échouée ne bloque rien. Google ne vous pénalise pas pour un test fermé qui s’est essoufflé; l’exigence reste simplement non remplie jusqu’à ce qu’une vraie fenêtre de 14 jours se termine. Quand nous reprenons après un échec, nous lançons un cycle neuf avec nos propres testeurs vérifiés, nous ajoutons une marge pour que l’effectif ne baisse jamais, et nous corrigeons ce qui a coulé le premier essai, le plus souvent des testeurs jamais inscrits ou une activité qui s’est éteinte en cours de fenêtre. Un de nos clients est arrivé après deux tentatives échouées et a été mis en ligne au cycle suivant; son histoire est la vidéo plus haut sur cette page, et l’analyse complète est dans l’étude de cas.

Si votre test tourne en ce moment et vacille, vous n’avez peut-être pas besoin de tout recommencer. On peut ajouter des testeurs à un canal actif à tout moment, donc renforcer une liste fragile est permis. La partie sans pitié, c’est la série: si votre nombre d’inscrits n’est jamais passé sous 12, vos jours écoulés comptent toujours, mais s’il a baissé, la fenêtre continue est déjà repartie, que la console le montre clairement ou non. Écrivez-nous sur WhatsApp avec une capture de votre canal avant de changer quoi que ce soit; diagnostiquer un test en cours ne coûte rien et prend quelques minutes.

Le test fermé est la plus grosse porte, mais une poignée d’autres exigences peuvent bloquer un lancement à la dernière étape, et toutes se règlent à l’avance à peu de frais. Le formulaire de sécurité des données est requis avant de publier sur les canaux fermé, ouvert ou production (seul le test interne en est exempté), et les apps qui ne collectent aucune donnée doivent quand même le remplir. Votre build doit respecter le niveau d’API minimal: l’API 35 est en vigueur aujourd’hui, et les nouvelles apps et mises à jour devront cibler l’API 36 à partir du 31 août 2026. Les nouvelles apps se livrent en Android App Bundle avec la signature Play App Signing, et le nom de package est permanent: il ne peut être ni supprimé ni réutilisé, alors choisissez votre applicationId comme si vous alliez vivre avec pour toujours, parce que c’est le cas.

La fiche de la boutique a aussi ses minimums: un nom d’app jusqu’à 30 caractères, une description courte jusqu’à 80, une description complète jusqu’à 4 000, une icône 512x512 et au moins deux captures d’écran de téléphone avant de pouvoir publier. Rien de difficile, mais le découvrir au jour 14 d’un test fermé terminé casse l’élan. Notre article sur les exigences de publication Google Play est la liste de contrôle complète; parcourez-la pendant que votre test tourne: au bout des deux semaines, tout est prêt à soumettre.

La documentation de Google et la moitié des fils de forum supposent que vous parlez déjà le langage de la Console. Voici le vocabulaire de cette page, défini une fois pour toutes:

Canal de test fermé

Un canal de distribution de la Play Console qui livre votre app uniquement aux testeurs invités. C’est là que l’exigence des 12 testeurs se mesure.

Lien de test (lien partageable)

L’URL que Google génère pour votre canal. Un testeur ne devient réel pour Google qu’après l’avoir ouverte et avoir accepté; figurer sur votre liste d’e-mails ne suffit pas.

Testeur inscrit

Une personne qui a accepté le lien de test avec son compte Google et compte dans vos 12. Se désinscrire la retire du compte même si l’app reste installée.

Les 14 jours sans interruption

Une fenêtre continue pendant laquelle votre canal garde 12+ testeurs inscrits. Un seul jour sous la barre fait repartir la fenêtre.

Accès en production

La permission de publier sur le Play Store public. Pour les nouveaux comptes personnels, il ne se débloque qu’une fois l’exigence du test fermé remplie et la demande approuvée.

Le questionnaire

Le formulaire en trois sections (votre test fermé, votre app, votre préparation) que Google pose quand vous demandez la production. Les réponses faibles sont une cause fréquente de refus.

Test interne

Un canal rapide distinct pour jusqu’à 100 testeurs, actif en quelques minutes. Utile pour vérifier un build; ne contribue en rien à l’exigence des 12 testeurs.

Nom de package

L’identifiant permanent de votre app (applicationId). L’exigence se valide par nom de package, c’est pourquoi chaque nouvelle app exécute son propre test.