La Play Console propose trois façons de mettre un build entre les mains de testeurs avant qu’il n’atteigne tout le monde : les tests internes, les tests fermés et les tests ouverts. Ils se ressemblent dans la console, mais ils sont conçus pour des étapes différentes d’une sortie, et sur un nouveau compte de développeur personnel, un seul d’entre eux vous aide à atteindre la production.
Cet article explique à quoi sert chaque canal, comment ils se comparent et l’ordre qui a du sens pour une toute nouvelle app.
Les trois canaux en un coup d’œil
| Tests internes | Tests fermés | Tests ouverts | |
|---|---|---|---|
| Qui peut participer | Jusqu’à 100 testeurs que vous désignez par e-mail | Les testeurs de vos listes d’adresses e-mail ou de vos Google Groupes | Toute personne qui trouve le test sur Google Play |
| Comment les testeurs rejoignent | Lien d’inscription | Lien d’inscription | Depuis votre fiche Play Store ou le lien d’inscription |
| Rapidité | Conçu pour itérer vite | Passe par l’examen | Passe par l’examen |
| Visible sur Google Play | Non | Non | Oui, comme programme d’accès anticipé ou de test |
| Compte pour la règle des 12 testeurs pendant 14 jours | Non | Oui | Non |
| Disponible sur un nouveau compte personnel | Oui | Oui | Seulement après l’octroi de l’accès en production |
Tests internes : votre équipe, rapidement
Les tests internes sont destinés à vous et aux personnes qui développent l’app avec vous. Vous pouvez ajouter jusqu’à 100 testeurs par e-mail, et les nouveaux builds sont conçus pour leur parvenir rapidement : c’est donc le bon endroit pour vérifier qu’une release fonctionne avant que quiconque hors de l’équipe ne la voie.
Servez-vous-en pour confirmer que le bundle s’installe depuis Google Play, que la connexion, les achats intégrés et les autres services Play se comportent correctement avec le nom de package de production, et que rien n’est cassé sur les quelques appareils de votre équipe.
Il existe aussi le partage interne d’applications, une fonctionnalité distincte qui permet d’importer un build et de partager un lien sans gérer de canal du tout. C’est pratique pour une vérification rapide avec un collègue, mais ce n’est pas un canal de test et cela ne compte pas non plus.
Tests fermés : des testeurs invités, et le canal qui compte
Les tests fermés s’adressent à un groupe plus large de personnes que vous invitez. Les testeurs sont ajoutés via des listes d’adresses e-mail ou des Google Groupes, ouvrent votre lien d’inscription, acceptent l’invitation et installent l’app depuis Google Play. L’app n’est pas visible du public, et seuls les comptes invités peuvent l’installer. Nos instructions pour les testeurs les guident pas à pas.
Pour les comptes de développeur personnels créés après le 13 novembre 2023, c’est le canal qui compte le plus : il vous faut au moins 12 testeurs inscrits à un test fermé pendant 14 jours consécutifs avant de pouvoir demander l’accès en production. Consultez l’exigence expliquée pour savoir comment les jours sont comptés.
Quand utiliser les tests fermés
- Pour remplir l’exigence des 12 testeurs pendant 14 jours sur un nouveau compte personnel.
- Pour une bêta avec un groupe précis, comme vos premiers clients, le personnel d’une entreprise ou une communauté que vous gérez.
- Pour mener plusieurs tests en parallèle. Vous pouvez créer des canaux fermés supplémentaires, par exemple un par fonctionnalité ou par client.
Les releases de tests fermés passent par l’examen de Google : prévoyez ce délai avant que les testeurs puissent installer l’app. Notre guide de configuration du test fermé couvre chaque étape.
Tests ouverts : la bêta publique
Les tests ouverts rendent votre version de test visible sur Google Play. Tout le monde peut la trouver et la rejoindre, et vous pouvez plafonner le nombre de testeurs si vous voulez que cela reste gérable. Les personnes qui rejoignent reçoivent la version de test de votre app au lieu de la version de production.
C’est idéal pour une grande bêta publique avant le lancement, ou pour essayer une refonte importante auprès de volontaires inscrits à l’accès anticipé.
Sur un nouveau compte personnel, en revanche, les tests ouverts ne sont pas disponibles tant que votre app n’a pas l’accès en production. Certains développeurs espèrent s’en servir pour recruter des testeurs pour l’exigence, mais celle-ci doit d’abord être remplie avec un test fermé.
Production : tout le monde
La production, c’est la version que tout le monde peut installer sur Google Play. Sur les nouveaux comptes personnels, elle se débloque app par app : terminez le test fermé, cliquez sur Demander l’accès en production dans le Tableau de bord et répondez aux questions de Google. Notre guide pour répondre aux questions d’accès en production montre ce que cherchent les réviseurs.
Même après le lancement, la production permet les déploiements progressifs : vous pouvez publier une mise à jour d’abord pour un pourcentage d’utilisateurs, puis l’élargir tant que les taux de plantage restent sains. Voyez-le comme un quatrième filet de sécurité après les canaux de test.
L’ordre qui fonctionne pour un nouveau compte personnel
- Tests internes pendant quelques jours : installez l’app vous-même depuis Google Play, vérifiez la connexion, la facturation et les parcours principaux.
- Tests fermés pendant au moins 14 jours avec 12 testeurs engagés ou plus. Publiez au moins une mise à jour basée sur leurs retours.
- Demander l’accès en production et répondre aux questions avec des éléments précis tirés du test fermé.
- Production avec un déploiement progressif, et éventuellement des tests ouverts pour les futures bêtas une fois débloqués.
Vous n’êtes pas obligé de faire passer le même build par tous les canaux. Il est courant de garder un test interne actif pour l’équipe pendant que le test fermé utilise un build un peu plus ancien et plus stable.
Les points qui prêtent souvent à confusion
Promouvoir une release d’un canal à l’autre
Vous pouvez promouvoir une release des tests internes vers les tests fermés, ou des tests fermés vers la production, au lieu d’importer à nouveau le bundle. Le code de version reste le même, ce qui garde votre historique de releases propre.
Des testeurs sur plusieurs canaux
Si la même personne est testeur sur plusieurs canaux, elle reçoit généralement le build avec le code de version le plus élevé qui lui est accessible. Si vos testeurs du test fermé disent voir un build interne plus récent, vérifiez qui figure sur quelle liste.
Retirer un testeur
Retirer quelqu’un de votre liste d’adresses e-mail ou de votre groupe Google signifie qu’il ne compte plus comme testeur inscrit. Faites-le à dessein, et assurez-vous de rester au-dessus de 12 pendant les 14 jours.
Quel canal pour quelle situation
| Situation | Canal à utiliser |
|---|---|
| Vous voulez vérifier un build sur votre propre téléphone avant que quiconque ne le voie | Tests internes |
| Votre nouveau compte personnel a besoin de 12 testeurs pendant 14 jours | Tests fermés |
| Un client ou une entreprise veut essayer l’app en privé | Tests fermés, avec leur groupe Google |
| Vous voulez une bêta publique avec des milliers de volontaires | Tests ouverts, une fois la production débloquée |
| Vous devez partager un build avec un collègue tout de suite | Partage interne d’applications |
| Vous publiez une mise à jour et voulez limiter les risques | Production avec un déploiement progressif |
L’erreur la plus courante sur les nouveaux comptes est de passer la première semaine de test sur le canal interne, puis de découvrir qu’elle n’a jamais compté. Si votre objectif est l’accès en production, placez vos testeurs sur un canal fermé dès le départ et réservez les tests internes à vos propres vérifications rapides.
En résumé
Utilisez les tests internes pour des vérifications rapides avec votre équipe, les tests fermés pour les testeurs invités et la règle des 12 testeurs pendant 14 jours, les tests ouverts pour les bêtas publiques une fois la production débloquée, et la production avec un déploiement progressif pour le lancement lui-même. Si trouver des testeurs pour le test fermé est votre goulot d’étranglement, voici les options réalistes, y compris des services comme TesterBie qui mènent le test fermé sur de vrais téléphones Android. Les prix figurent dans notre section tarifs.
Questions fréquentes
Les tests internes comptent-ils pour l’exigence des 12 testeurs ?
Non. Seuls les testeurs inscrits à un canal de tests fermés comptent pour l’exigence d’au moins 12 testeurs pendant 14 jours consécutifs.
Puis-je utiliser les tests ouverts au lieu des tests fermés sur un nouveau compte ?
Non. Sur les comptes personnels créés après le 13 novembre 2023, les tests ouverts deviennent disponibles en même temps que l’accès en production, une fois l’exigence de test fermé remplie et approuvée.
Puis-je mener des tests internes et fermés en même temps ?
Oui. Les canaux sont indépendants. Beaucoup de développeurs gardent un canal interne qui évolue vite pour l’équipe pendant que le test fermé tourne sur un build plus stable.
L’examen des tests fermés prend-il autant de temps que celui de la production ?
Les deux passent par l’examen de Google, et les délais varient. Le premier examen d’une nouvelle app est souvent le plus lent : envoyez votre release de test fermé le plus tôt possible.