12TesteuresGoogle Play · Guides indépendants
Guides

Comment lancer un test fermé Google Play : étapes, lien et checklist

De la création de la piste au premier opt-in, voici l’ordre exact des opérations pour lancer un test fermé Google Play sans bloquer vos testeurs.

Par La rédaction 12Testeures9 min de lecture
Une personne vérifie une application mobile sur un smartphone
Sommaire du guide
  1. 1. Préparer l’application et la version
  2. 2. Créer la piste fermée
  3. 3. Choisir l’accès des testeurs
  4. 4. Ajouter le canal de feedback
  5. 5. Publier et vérifier le lien
  6. 6. Suivre les 14 jours
  7. Checklist de lancement

Un test fermé Google Play sert à distribuer une version à un groupe contrôlé avant la mise en production. Pour un compte développeur personnel créé après le 13 novembre 2023, cette étape précède aussi la demande d’accès à la production : Google demande au minimum 12 testeurs restés opt-in pendant 14 jours consécutifs.

Le piège n’est pas la création de la piste. Il vient surtout de l’ordre des opérations : une liste d’adresses n’est pas encore un opt-in, un lien copié trop tôt peut ne pas fonctionner et une personne inscrite sur le test interne n’est pas immédiatement éligible au test fermé.

1. Préparer l’application et la version

Avant d’ouvrir Play Console, vérifiez que votre application dispose d’un Android App Bundle valide, d’un numéro de version correct et des informations minimales demandées par la console. Le test fermé doit permettre de recueillir des retours sur une version que vos participants peuvent réellement utiliser.

Préparez aussi une liste de parcours à vérifier : création de compte, fonction principale, notifications, achats éventuels, permissions et suppression des données. Ces notes vous serviront ensuite pour le questionnaire d’accès à la production.

2. Créer la piste fermée

Dans Play Console, sélectionnez l’application puis ouvrez Tester et publier > Tests > Test fermé. Créez une piste si nécessaire et donnez-lui un nom compréhensible, par exemple closed-test-v1.

Ajoutez votre App Bundle à la version de test et suivez le flux de vérification. Ne partagez pas un ancien lien récupéré dans un brouillon : attendez que la piste et la version soient publiées selon le statut demandé par Play Console.

3. Choisir l’accès des testeurs

Play Console propose principalement une liste d’adresses e-mail ou un Google Group.

  • Liste e-mail : pratique pour 12 à 15 personnes identifiées.
  • Google Group : utile pour une communauté ou des remplacements fréquents.

Chaque participant doit utiliser l’adresse du compte Google présent sur son téléphone. Pour comparer les méthodes, consultez notre guide liste e-mail ou Google Group pour un test fermé.

4. Ajouter le canal de feedback

Dans l’onglet Testeurs, renseignez une adresse e-mail ou une URL de feedback. Demandez aux participants de noter le modèle de téléphone, la version Android, les étapes reproduites et le résultat obtenu. Ces quatre informations sont plus utiles qu’un simple « ça ne marche pas ».

5. Publier et vérifier le lien

Une application en brouillon ou en attente de publication peut ne pas afficher de lien d’opt-in utilisable. Une fois le lien disponible, testez-le vous-même avec un compte de test.

Le parcours attendu est le suivant :

  1. ouvrir le lien avec le bon compte Google ;
  2. rejoindre le Google Group au préalable si nécessaire ;
  3. accepter explicitement le programme de test ;
  4. installer l’application depuis Google Play ;
  5. envoyer un retour via le canal indiqué.

Une adresse ajoutée à la liste mais qui n’a pas terminé l’opt-in ne doit pas être confondue avec un testeur actif. Si le lien affiche une erreur, suivez les 7 vérifications du lien d’opt-in Google Play.

6. Suivre les 14 jours

Pour le compte concerné par la règle, gardez au moins 12 testeurs opt-in en continu pendant les 14 jours précédant la demande de production. En pratique, recrutez deux ou trois personnes de réserve et notez la date d’opt-in de chaque participant.

Le tableau de suivi peut contenir l’identifiant interne, la date d’opt-in, la piste utilisée, l’installation confirmée, le dernier retour et un éventuel retrait du test. Consultez aussi le tableau de bord des testeurs Play Console.

Le test interne reste utile pour les vérifications rapides, mais il ne remplace pas la piste fermée. Un utilisateur inscrit au test interne de la même application peut devoir s’en désinscrire avant de rejoindre le test fermé.

Checklist de lancement

Avant d’envoyer le lien, vérifiez :

  • la bonne application et le bon package sont ouverts ;
  • la version est sur la piste fermée ;
  • la liste ou le Google Group contient les bonnes adresses ;
  • le canal de feedback est visible ;
  • la piste n’est plus au statut brouillon ;
  • chaque testeur sait qu’il doit cliquer sur l’opt-in ;
  • vous avez une réserve et un tableau de suivi.

Après le test, ne répondez pas au questionnaire avec des phrases génériques. Décrivez l’audience, les parcours testés, les retours reçus et les changements réalisés. Voir aussi le guide du questionnaire d’accès production.

Transparence éditoriale

Sources consultées

Questions fréquentes

L’essentiel, sans jargon.

Faut-il publier l’application en production pour lancer un test fermé ?

Non. Il faut publier une version sur la piste de test fermé, mais l’application n’est pas encore disponible publiquement en production.

Quel lien faut-il envoyer aux testeurs ?

Envoyez le lien partageable de la piste fermée affiché dans l’onglet Testeurs. Avec un Google Group, la personne doit d’abord rejoindre le groupe avec le même compte Google.

Une piste de test interne remplace-t-elle le test fermé ?

Non. Le test interne est utile pour vérifier une version, mais l’accès production des nouveaux comptes personnels demande un test fermé conforme avec au moins 12 testeurs opt-in pendant 14 jours continus.

Commentaires

Laisser un commentaire