Liste e-mail ou Google Group pour un test fermé : quelle méthode choisir ?

Au moment de configurer un test fermé, Play Console propose deux méthodes principales pour autoriser les participants : sélectionner une ou plusieurs listes d’adresses e-mail, ou saisir l’adresse d’un Google Group. Les deux donnent accès à la même piste, mais leur gestion quotidienne est très différente.

Le bon choix dépend moins du nombre minimum de 12 testeurs que de la stabilité de votre groupe. Si les mêmes personnes restent pendant tout le test, une liste suffit. Si vous gérez une communauté, plusieurs applications ou des remplacements fréquents, un groupe peut éviter beaucoup de manipulations.

Option 1 : la liste d’e-mails Play Console

La liste est gérée directement dans Play Console. Vous lui donnez un nom, ajoutez les adresses séparées par des virgules ou importez un fichier CSV, puis vous associez cette liste à la piste fermée.

Selon la documentation Google, vous pouvez créer jusqu’à 200 listes, placer jusqu’à 2 000 utilisateurs dans chaque liste et associer jusqu’à 50 listes à une piste. Ces plafonds dépassent largement les besoins d’un développeur qui cherche ses 12 premiers testeurs.

La liste e-mail convient bien lorsque :

• vous connaissez personnellement les testeurs ;
• le groupe est petit et ne change presque pas ;
• vous voulez contrôler précisément chaque adresse autorisée ;
• vous n’avez pas besoin d’un espace communautaire séparé.

Son principal avantage est la lisibilité : l’autorisation d’accès est visible au même endroit que la piste. Son principal défaut apparaît lorsqu’un testeur doit être remplacé : il faut modifier la liste, enregistrer et attendre éventuellement la propagation du changement.

Attention à l’import CSV

L’import n’ajoute pas simplement de nouvelles lignes à la liste existante : Google précise qu’un CSV importé remplace les adresses déjà présentes. Sauvegardez donc la liste complète avant de charger un nouveau fichier.

Play Console n’accepte pas non plus les CSV encodés en UTF-8 avec BOM. Si un fichier correctement structuré est rejeté, réexportez-le en CSV UTF-8 sans BOM. Pour seulement 12 à 15 personnes, la saisie directe séparée par des virgules reste souvent plus rapide et moins risquée.

Option 2 : Google Groups

Avec cette méthode, Play Console autorise l’adresse du groupe, au format nomdugroupe@googlegroups.com. L’appartenance au groupe décide qui peut ensuite rejoindre le test.

Google Groups est utile lorsque :

• vous maintenez un pool de testeurs pour plusieurs applications ;
• des membres doivent être ajoutés ou retirés régulièrement ;
• les testeurs rejoignent une communauté existante ;
• un responsable autre que le propriétaire Play Console gère les participants.

Vous modifiez alors les membres dans Google Groups sans rééditer chaque fois la liste de la piste. Cette séparation facilite la gestion, mais crée aussi une étape supplémentaire pour le testeur.

L’erreur classique avec un Google Group

Partager seulement le lien d’opt-in ne suffit pas. Pour un test fermé géré par groupe, la personne doit :

1. se connecter avec le compte Google qu’elle utilisera sur le Play Store ;
2. rejoindre le Google Group ;
3. ouvrir le lien d’opt-in de la piste ;
4. accepter le programme de test ;
5. installer l’application.

Si elle ouvre le lien avant d’être membre, l’accès peut être refusé. Si elle rejoint le groupe avec une adresse puis ouvre Play Store avec une autre, Play Console ne la reconnaît pas comme éligible.

Ce que les deux méthodes ne changent pas

Une adresse autorisée n’est pas encore un testeur comptabilisé. Avec une liste comme avec un groupe, chaque personne doit confirmer son opt-in. Le compteur des 14 jours concerne les testeurs inscrits sans interruption, pas le nombre d’adresses que vous avez préparées.

Les deux méthodes demandent également un canal de feedback. Vous pouvez renseigner une adresse e-mail ou une URL ; elle apparaît sur la page d’inscription du testeur. Les participants aux tests ouverts ou fermés peuvent aussi envoyer des commentaires privés via Google Play.

Enfin, évitez de réutiliser simultanément les mêmes personnes sur la piste interne. Google indique qu’un utilisateur inscrit au test interne doit d’abord en sortir avant de devenir éligible au test fermé ou ouvert de la même application.

Tableau de décision rapide

Votre situation	Méthode conseillée
12 à 15 proches, groupe stable	Liste e-mail
Communauté qui recrute en continu	Google Group
Plusieurs applications avec les mêmes testeurs	Google Group
Contrôle individuel strict des accès	Liste e-mail
Gestion déléguée à un community manager	Google Group
Ajout ponctuel de deux remplaçants	Liste e-mail

Ce tableau est une recommandation d’organisation, pas une différence de valeur aux yeux de Google. Une personne recrutée via un groupe ne « compte » pas davantage qu’une personne ajoutée par e-mail.

La méthode hybride à éviter

Multiplier sans raison les listes et les groupes sur la même piste complique le diagnostic : lorsqu’un testeur n’arrive pas à rejoindre l’application, vous ne savez plus quelle source est censée l’autoriser. Pour un premier test, choisissez une méthode principale et documentez-la.

Vous pouvez garder une petite liste de secours séparée pour vos deux ou trois remplaçants, mais ne l’activez pas sans vérifier l’impact sur votre suivi. L’objectif est de savoir qui est autorisé, qui a réellement opt-in et depuis quelle date.

Notre recommandation pour un premier lancement

Si vous avez déjà réuni 12 à 15 adresses fiables, commencez par une liste e-mail nommée clairement, par exemple closed-test-production-2026. Ajoutez le canal de feedback, publiez la piste, puis envoyez le lien avec une checklist courte.

Si vous recrutez dans une communauté ou comptez publier plusieurs applications, créez un Google Group avec des règles visibles et un message épinglé contenant les étapes d’inscription. Dans les deux cas, contrôlez ensuite le statut réel dans le tableau de bord des testeurs Play Console, car votre liste de départ ne prouve pas que les personnes ont terminé l’opt-in.