Non: aucune remise à zéro
Une mise à jour ordinaire laisse courir le temps d’inscription de vos testeursGoogle ne publie aucune règle selon laquelle la création d’une nouvelle version fait recommencer le test fermé. L’exigence porte sur le fait que chaque testeur reste inscrit pendant 14 jours continus, avec au moins 12 testeurs dans ce cas au moment de votre demande. Votre code de version et le nombre de versions importées n’en font pas partie.
Des testeurs quittent le test, si bien que moins de 12 cumulent 14 jours sans interruption.
Un testeur qui quitte le test puis le rejoint recommence ses propres 14 jours, et un remplaçant part du premier jour. Si, du coup, moins de 12 testeurs cumulent 14 jours sans interruption, votre demande doit attendre. La mise à jour n’en est pas la cause.
Réponse rapide
Non. Mettre à jour la même application sur son canal de test fermé (closed testing) en cours ne fait pas, à elle seule, recommencer le temps d’inscription de vos testeurs. Pour les comptes de développeur personnels créés après le 13 novembre 2023, l’application doit compter au moins 12 testeurs restés chacun inscrits pendant les 14 derniers jours consécutifs au moment où vous demandez l’accès en production. Un testeur qui quitte le test recommence ses propres 14 jours. Google recommande de tenir compte des commentaires, mais ne publie aucun nombre de versions obligatoire. Si les testeurs ne voient pas une nouvelle version, vérifiez la publication, l’éligibilité au déploiement et la mise à jour sur l’appareil.
C’est l’une des craintes les plus courantes pendant un test fermé: à mi-parcours de la période de 14 jours, vous repérez un bug et n’osez plus importer le correctif, de peur d’effacer votre progression et de devoir recommencer les deux semaines. Cela n’arrivera pas. L’exigence des 14 jours suit vos testeurs, pas vos versions. Ce guide distingue ce qui interrompt la période de test fermé de ce qui ne change rien, propose deux outils interactifs pour vérifier vous-même n’importe quelle action et explique quoi vérifier quand les testeurs ne voient pas une nouvelle version. Il a été vérifié pour la dernière fois par rapport aux pages d’aide de Google le 16 octobre 2026.
Dans ce guide
Une mise à jour de mon application réinitialise-t-elle le compteur de 14 jours du test fermé?
Non. C’est la crainte la plus courante des développeurs pendant leur période de test, et la réponse est rassurante: importer un nouvel app bundle sur votre canal de test fermé existant ne fait pas, à lui seul, recommencer le temps d’inscription de vos testeurs.
L’exigence des 14 jours est liée à vos testeurs, pas à votre version. Google la mesure par testeur: au moment de votre demande d’accès en production, au moins 12 testeurs doivent chacun être inscrits sans interruption depuis les 14 derniers jours. Le numéro de version de l’application, le nombre de nouveaux AAB importés et les modifications de vos notes de version ne font pas partie de cette exigence.
Cette question revient sans cesse dans la communauté des développeurs Google Play. L’aide de la Play Console définit l’exigence uniquement en termes de testeurs inscrits et de durée, jamais en termes de versions importées. Un expert produit Google a donné la réponse pratique dans une réponse acceptée de la communauté en janvier 2024: une mise à jour pendant le test peut nécessiter un examen, mais elle ne réinitialise pas les 14 jours. Il s’agit de la lecture d’un expert, pas d’une phrase tirée des règles elles-mêmes.
Vous hésitez sur une action précise? Utilisez l’outil ci-dessous: choisissez ce que vous vous apprêtez à faire et il vous indique si cela touche les 14 jours de vos testeurs.
Quelle action vous préoccupe?
Fondé sur l’exigence publiée par Google pour la Play Console, soit testeurs inscrits × jours sans interruption, et sur l’expérience de nombreux développeurs. Les deux risques signalés uniquement par la communauté sont clairement indiqués.
Qu’est-ce qui réinitialise vraiment le compteur de 14 jours?
La période de 14 jours sans interruption est un contrôle de continuité, pas un simple compte à rebours calendaire. Google veut vérifier que vous avez maintenu au moins 12 testeurs inscrits sans interruption. Seuls deux déclencheurs confirmés rompent cette continuité:
Le nombre de testeurs inscrits passe sous 12
Si un testeur part et que vous tombez à 11 testeurs qualifiés, vous ne pouvez pas faire votre demande tant qu’un douzième testeur n’a pas cumulé 14 jours sans interruption, et un remplaçant part du premier jour. C’est pourquoi fonctionner avec exactement 12 testeurs est risqué.
Des testeurs quittent officiellement le test
Un testeur quitte le test en ouvrant le lien web du test et en choisissant de se retirer. Ce n’est pas la même chose que désinstaller l’application. Les 14 jours de ce testeur s’arrêtent, et s’il rejoint le test, ils recommencent. Cela ne retarde votre demande que s’il reste moins de 12 testeurs qualifiés.
Importer une nouvelle version ne figure pas dans cette liste. Corriger une faute dans la fiche, recevoir un commentaire ou voir l’application planter sur l’appareil d’un testeur n’y figurent pas non plus. Ce dernier cas est précisément l’intérêt du test. Le simulateur ci-dessous montre clairement la différence: publiez une mise à jour et la série continue, perdez assez de testeurs pour passer sous 12 et elle s’interrompt.
Ce qui ne remet PAS le compteur à zéro
Importer un nouvel AAB sur le même canal
Modifier les notes de version ou la fiche
Recevoir le commentaire d’un testeur
Voir l’application planter sur un appareil
Augmenter le versionCode ou changer le nom de version
Un testeur désinstalle sans quitter le test
Comment publier une mise à jour pendant un test fermé?
Le processus est le même que pour votre première version, avec une différence importante: vous créez la nouvelle version sur le même canal de test fermé auquel vos testeurs sont déjà inscrits. Vous ne lancez pas un nouveau test, vous ajoutez une version au test en cours. Le compteur de 14 jours continue donc. Voici les deux étapes dans la Play Console.
Créez une version sur votre canal fermé Test and release > Testing > Closed testing > Manage track
Ouvrez le canal de test fermé déjà en cours, cliquez sur Create new release et importez votre app bundle actualisé (AAB). Gardez le même nom de package et la même configuration de signature, et attribuez à la version un versionCode plus élevé: modifier uniquement le versionName ne constitue pas une mise à niveau. Ajoutez de brèves notes de version décrivant les changements, puis enregistrez. Restez sur le même canal: c’est ce qui permet aux 14 jours de vos testeurs de continuer.
Examinez et déployez la mise à jour Review release > Start roll-out
Continuez avec Next puis Review release, et lancez le déploiement sur votre canal fermé. Ouvrez ensuite Publishing overview: si des modifications sont en attente, choisissez Send changes for review, et si la publication gérée est activée, publiez vous-même les modifications approuvées. Une mise à jour envoyée peut afficher In review avant que les testeurs ne la reçoivent, et Google précise qu’une modification publiée peut mettre plusieurs heures à parvenir aux testeurs. Les testeurs existants reçoivent normalement la mise à jour par-dessus leur installation, sans réinstallation ni nouvelle inscription.
Cette opération ne fait pas recommencer le temps d’inscription de vos testeurs. Vous publiez sur le même canal fermé auquel vos testeurs sont déjà inscrits, leurs 14 jours continuent donc de courir sous la nouvelle version. Vous ajoutez une version, vous ne commencez pas un nouveau test. Si les testeurs ne voient toujours pas la nouvelle version, suivez les vérifications de la section suivante.
Pourquoi les testeurs ne reçoivent-ils pas le nouveau build?
Vérifiez d’abord si le build prévu est publié sur le canal du testeur, puis vérifiez le compte du testeur et la version installée, et seulement ensuite le téléphone. Il s’agit d’un ordre de vérification, pas d’un classement des causes les plus fréquentes. C’est terminé quand un testeur éligible a installé le build prévu et retesté la modification; une nouvelle date sur la fiche Play Store ne suffit pas.
Ma mise à jour est toujours en cours d’examen
Une mise à jour envoyée peut devoir être examinée avant que ce build n’atteigne les testeurs. Ouvrez la vue d’ensemble de la publication (Publishing overview) dans Play Console et agissez selon ce qu’elle affiche:
- Modifications pas encore envoyées: vérifiez la liste et choisissez Send changes for review (envoyer les modifications pour examen).
- En cours d’examen: confirmez qu’il s’agit de la bonne application, du bon canal et de la bonne version, et suivez tout message affiché dans la Console. N’importez pas un autre build juste pour relancer l’examen; Google compte la durée d’examen à partir de la dernière modification envoyée.
- Modifications prêtes à être publiées: la publication gérée est activée, vous devez donc publier vous-même les modifications approuvées.
Une version en attente d’examen et des testeurs qui restent inscrits sont deux états distincts. Google ne documente pas qu’un examen de mise à jour ordinaire suspende ou remette à zéro la durée d’inscription de vos testeurs.
Seuls certains testeurs peuvent faire la mise à jour
Une mise à jour publiée n’atteint que les testeurs auxquels elle est déployée et qui y sont éligibles. Vérifiez ces points dans l’ordre:
- Déploiement progressif: les mises à jour sur les canaux de test, test fermé compris, peuvent utiliser un pourcentage de déploiement, et ce pourcentage n’augmente pas tout seul. Dans Closed testing > Releases, ouvrez Manage rollout pour voir le pourcentage et savoir si le déploiement est interrompu.
- Compte: l’adresse figurant sur votre liste ou dans votre Google Group, le compte qui s’est inscrit au test et le compte connecté au Play Store doivent être identiques.
- Test interne: un testeur encore inscrit à votre test interne ne peut pas recevoir les versions du test fermé tant qu’il n’a pas quitté le test interne et rejoint le test fermé. Il s’agit d’une réparation de l’inscription, pas d’une étape normale de mise à jour.
- Code de version: Google Play installe le versionCode compatible le plus élevé auquel le testeur a droit. Modifier uniquement le versionName ne constitue pas une mise à niveau.
- Appareil: la version doit être compatible avec l’appareil du testeur, et vos paramètres de distribution doivent l’inclure.
La version est disponible, mais le téléphone a toujours l’ancienne
Utilisez le parcours de mise à jour du Play Store avant de toucher à l’inscription du testeur:
- Ouvrez la fiche Play de l’application via votre lien de test et appuyez sur Mettre à jour si le bouton apparaît, ou allez dans votre profil > Gérer les applications et l’appareil > Mises à jour disponibles.
- Vérifiez la mise à jour automatique: elle peut être désactivée, limitée au Wi-Fi ou désactivée pour cette seule application.
- Vérifiez la connexion et l’espace de stockage libre, puis fermez et rouvrez le Play Store.
- Seulement ensuite, videz le cache du Play Store (infos sur l’application > Stockage et cache > Vider le cache). Vider le cache ne peut pas publier une version encore en cours d’examen.
Ne demandez pas aux testeurs de quitter le test puis de le rejoindre pour obtenir une mise à jour. Quitter le test interrompt les 14 jours sans interruption de ce testeur. Désinstaller l’application, effacer les données des services Google Play ou réinitialiser le téléphone ne fait pas non plus partie d’une mise à jour normale.
Quelle est la différence entre testeurs invités et testeurs inscrits?
Cette distinction piège plus de nouveaux éditeurs que toute autre. Elle explique aussi pourquoi les versions ne comptent pas dans le calcul. Le système de Google fait progresser les testeurs par plusieurs étapes, et seules les dernières ont du poids.
Invité
Vous avez ajouté une adresse e-mail à votre liste de diffusion ou à un Google Group. Rien d’autre ne s’est encore produit.
Inscrit au test
Le testeur a cliqué sur votre lien partageable, s’est connecté à son compte Google et a accepté de participer. C’est le statut mesuré par le compteur de 14 jours.
Installation active
Le testeur a téléchargé l’application et continue à l’utiliser. Cela ne change pas l’effectif brut, mais montre la participation réelle examinée par Google lors de la demande d’accès en production.
La documentation de Google est claire: ajouter une adresse e-mail ne suffit pas. Chaque testeur doit ouvrir le lien du test, s’authentifier et accepter explicitement de participer avant de compter. Voilà aussi pourquoi une mise à jour ordinaire de l’application ne fait pas recommencer votre progression: vos testeurs restent inscrits, et leurs jours continuent de compter d’une version à l’autre. Pour voir tout le processus, consultez notre guide sur la bonne façon d’inviter des testeurs.
Conseil tiré de la gestion de milliers de tests: gérez vos testeurs avec un Google Group plutôt qu’avec une liste d’adresses statique. Google indique que l’importation d’un fichier CSV remplace la liste de testeurs précédente: un groupe vous évite donc de supprimer accidentellement des testeurs actifs lorsque vous la modifiez. Un groupe n’est pas pour autant une garantie: l’appartenance au groupe contrôle toujours l’accès, donc retirer quelqu’un du groupe ou associer un autre groupe change les personnes éligibles.
Quelle est la formulation exacte de l’exigence de Google?
La page d’aide officielle de la Play Console consacrée aux exigences de test des nouveaux comptes de développeur personnels l’énonce précisément:
"Si vous avez un compte de développeur personnel nouvellement créé, 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 de la Play Console · réponse 14151465La même page précise également la situation au moment de demander un accès en production:
"Au moins 12 testeurs doivent être inscrits à votre test fermé lorsque vous demandez un accès en production. Ils doivent être inscrits depuis les 14 derniers jours sans interruption."
Aide de la Play Console · réponse 14151465Google indique aussi que les jours doivent être consécutifs. Un testeur qui s’inscrit, participe moins de 14 jours puis quitte le test ne compte pas. Même s’il se réinscrit, une nouvelle période commence, car les 14 jours doivent être consécutifs. Cette seule précision réfute le mythe des 14 jours cumulés et, tout aussi important, elle ne dit rien sur les versions de votre application.
Trois faits à retenir
Publier des mises à jour pendant le test est-il utile?
La crainte du développeur devient ici une occasion d’améliorer l’application. Publier des mises à jour pendant le test fermé est généralement perçu comme un signe de participation réelle. Il faut toutefois distinguer les recommandations officielles de Google des conclusions de la communauté, car elles se rejoignent sans être identiques:
Continuez à améliorer et corriger
L’aide de la Play Console encourage les améliorations continues. Continuez à utiliser le test fermé pendant que vous corrigez les problèmes et bugs signalés par les utilisateurs. Mettre l’application à jour avant la production est aussi présenté comme un excellent moyen de réduire les avis et notes de mauvaise qualité.
Lorsque vous demandez un accès en production, le questionnaire vous invite à décrire la participation obtenue et la manière dont vous avez utilisé les commentaires des testeurs.
Une application active est plus crédible
Les praticiens vont plus loin: une application figée en version 1.0 pendant 14 jours, sans aucune activité, ressemble à un test mené pour cocher une case, alors qu’une application qui publie des correctifs en réponse aux commentaires ressemble à un véritable travail de développement. Certains développeurs publient deux ou trois petites mises à jour pour montrer leur réactivité, mais Google ne publie aucun quota de ce type (voir la section sur le nombre de versions ci-dessous).
Il s’agit d’une opinion de la communauté et d’une déduction raisonnable, pas d’une règle publiée par Google. Google n’a fixé aucune exigence chiffrée du type "publiez X mises à jour".
En bref, mettre l’application à jour est sans risque et encouragé. La participation que vous démontrez ainsi peut vous aider à répondre au questionnaire d’accès en production. Le seul vrai risque tient au contenu de la version publiée, pas au fait de la publier. C’est la seule réserve importante.
Faut-il publier deux ou trois versions pendant le test fermé?
Les recommandations publiées par Google sur le test fermé ne fixent aucun nombre minimal de versions. Google recommande de tenir compte des commentaires des testeurs et de corriger les problèmes détectés, et la demande d’accès en production vous invite à décrire les modifications apportées. Le nombre d’importations ne fait pas partie de l’exigence.
- Garder au moins 12 testeurs inscrits pendant 14 jours sans interruption (exigence publiée)
Protégez l’inscription continue de chaque testeur dès le premier jour. - Tenir compte des commentaires et corriger les problèmes détectés (recommandation de Google)
Notez brièvement le commentaire, le correctif et le nouveau test. - Publier deux ou trois versions quoi qu’il arrive (croyance de la communauté, aucun quota publié)
N’inventez pas de modifications et ne comptez pas sur un nombre de versions pour obtenir l’approbation.
D’où vient ce conseil: la plus ancienne version explicite que nous ayons trouvée est la supposition d’un développeur, dans une discussion d’octobre 2024, selon laquelle deux ou trois mises à jour pourraient montrer à Google un travail guidé par les commentaires. Elle a été reprise dans des fils de la communauté en quelques semaines, puis dans des guides comme s’il s’agissait d’une recommandation de Google. La source d’origine est inconnue, et des développeurs signalent des refus avec comme sans plusieurs mises à jour: un nombre de versions ne prouve donc rien à lui seul.
Si le test révèle un vrai problème, corrigez-le, publiez la version et demandez aux testeurs de tester à nouveau. Sinon, dites-le honnêtement lorsque vous répondez au questionnaire d’accès en production. Importer des versions purement cosmétiques pendant qu’une mise à jour est en cours d’examen peut aussi repousser votre application dans la file d’examen, car Google compte la durée d’examen à partir de la dernière modification envoyée.
Une mauvaise mise à jour peut-elle indirectement remettre le compteur à zéro?
Oui, et c’est la seule réserve qui compte. La mise à jour elle-même ne réinitialise jamais directement le compteur, mais les conséquences d’une version instable peuvent le faire. Voici la chaîne:
La règle est donc simple: publiez librement vos mises à jour, mais vérifiez la stabilité de base de chaque version avant de l’envoyer sur le canal fermé. Évitez aussi de fonctionner avec exactement 12 testeurs, car un seul départ provoqué par une mauvaise version peut vous faire échouer. Une marge de testeurs au-delà de 12 absorbe ce risque.
Relisez bien la chaîne: la mise à jour ne fait recommencer le temps d’inscription de personne. Le retard vient de la perte de testeurs qualifiés; la version instable n’est que ce qui a déclenché les départs. Gardez des versions stables et une marge de testeurs, et le risque indirect devient bien plus faible.
Les testeurs doivent-ils réinstaller l’application ou se réinscrire après une mise à jour?
Non. Les testeurs déjà inscrits qui ont installé votre application reçoivent normalement la mise à jour via Google Play, directement par-dessus l’installation existante. Ils n’ont pas à s’inscrire de nouveau, et vous n’avez pas à renvoyer le lien.
Les mises à jour s’installent normalement par-dessus l’existant
Dans la page d’aide Set up an open, closed, or internal test (en anglais, réponse 9845334), Google explique qu’après l’installation de l’application, les testeurs reçoivent automatiquement la version de test en quelques minutes. Ils restent inscrits d’une version à l’autre, sans réinstallation ni second clic.
La même page apporte une précision sur le délai: les modifications supplémentaires peuvent ne pas être disponibles pour les testeurs pendant plusieurs heures avant le début de la mise à jour automatique sur l’appareil. Leur statut d’inscription, qui est ce que mesure le compteur de 14 jours, reste toutefois intact avec chaque nouvel AAB. Une nouvelle version ne remet donc pas le compteur à zéro, puisque les testeurs n’ont jamais quitté le test.
Exception importante De nouvelles autorisations peuvent interrompre la mise à jour silencieuse
Un type de version ne se déploie pas toujours sans intervention: celle qui ajoute une nouvelle autorisation dangereuse ou sensible, comme ACCESS_FINE_LOCATION, l’appareil photo ou le microphone. Selon l’autorisation et le niveau d’API cible, Google Play peut afficher un bouton Update que le testeur doit toucher et approuver au lieu d’installer la version en arrière-plan. La personne qui l’ignore reste sur l’ancienne version. Même lors d’une installation silencieuse, la nouvelle autorisation n’est accordée qu’au moment de l’utilisation. Une fonction qui en dépend peut donc sembler cassée tant que le testeur ne l’a pas autorisée.
Pendant un test fermé, ce piège est discret: publiez en plein test une mise à jour riche en autorisations et certains testeurs peuvent rester sur l’ancienne version ou voir une fonctionnalité bloquée tant qu’ils n’ont pas accordé l’autorisation. Une nouvelle autorisation à haut risque peut aussi nécessiter une déclaration des autorisations dans la Play Console avant même que la version puisse être publiée. Le consentement sur le téléphone et la déclaration dans la Console sont deux contrôles distincts.
Avant une publication en cours de test: comparez les autorisations du nouveau manifeste à celles de la version disponible. Si elles ont changé, demandez aux testeurs d’ouvrir le Play Store, d’effectuer la mise à jour manuellement et d’accepter la nouvelle demande. Prévoyez aussi une marge au cas où un examen de la déclaration serait nécessaire.
Cinq mythes courants sur le test fermé
La plupart des inquiétudes entourant les mises à jour viennent de quelques idées reçues. Voici les cinq mythes qui préoccupent le plus les développeurs, avec les faits:
Mythe 1"Créer une nouvelle version remet le compteur à zéro."
Mythe 2"Désinstaller revient à quitter le test."
Mythe 3"Les 14 jours sont cumulables."
Mythe 4"Exactement 12 testeurs suffisent."
Mythe 5"Les testeurs doivent utiliser l’application chaque jour."
Ce qui remet le compteur à zéro et ce qui ne change rien
Voici toute la réponse sur un seul écran. Enregistrez ce tableau, faites-en une capture ou envoyez-le à votre équipe. Tout ce qui concerne la version est sans risque. Seul ce qui touche au nombre de testeurs inscrits peut interrompre la série.
| Action | Remet les 14 jours à zéro? |
|---|---|
| Importer un nouvel AAB sur le même canal fermé | Non |
| Modifier les notes de version ou les métadonnées de la fiche | Non |
| Recevoir le commentaire d’un testeur | Non |
| Voir l’application planter sur l’appareil d’un testeur | Non |
| Un testeur désinstalle sans quitter le test | Non* |
| Le nombre de testeurs inscrits passe sous 12 | Oui |
| Un testeur quitte officiellement depuis la page du test | Oui** |
| Publier une version instable qui provoque assez de départs pour passer sous 12 | Indirectement |
| Suspendre le canal de test fermé | Risque signalé |
| Écraser la liste et omettre des testeurs actifs | Risque signalé |
* Ce n’est pas un départ du test, mais un testeur sans l’application installée ne la teste pas. ** Seulement s’il reste moins de 12 testeurs qualifiés. "Oui" signifie ici que votre date de demande la plus proche recule: les testeurs restés conservent leurs jours, mais un remplaçant part du premier jour. Google indique que l’importation d’un CSV remplace la liste précédente et que la suspension d’un test bloque ses mises à jour; la façon dont les jours sont comptés ensuite n’est pas documentée, considérez donc les deux dernières lignes comme "à ne pas risquer".
Comment l’exigence a évolué
Si vous consultez d’anciens tutoriels, cette évolution explique les chiffres contradictoires. La durée est toujours restée de 14 jours sans interruption. Seul le nombre de testeurs a changé.
Avant novembre 2023, aucun test fermé obligatoire ne bloquait l’accès en production. Une application pouvait être publiée sans recruter de testeurs.
Google a annoncé l’exigence le 9 novembre 2023. Les comptes personnels créés après le 13 novembre 2023 devaient exécuter un test fermé avec 20 testeurs inscrits pendant 14 jours sans interruption. Les comptes d’organisation étaient exemptés.
Le 11 décembre 2024, le minimum est passé de 20 à 12 testeurs. La durée de 14 jours n’a pas changé et les comptes d’organisation restent exemptés.
Tout guide qui vous demande encore de recruter 20 testeurs est obsolète. Nous détaillons cette évolution dans notre article sur le passage de 20 à 12 testeurs.
Les changements de politique à connaître en 2026
Le test fermé ne se déroule pas isolément. Plusieurs échéances de 2026 peuvent croiser votre calendrier de lancement. Aucune ne change le fonctionnement des 14 jours, mais elles peuvent perturber votre période si vous ne les anticipez pas:
Échéances 2026 à intégrer au calendrier
Dates issues de l’aide de la Play Console sur le niveau d’API cible et de l’Android Developers Blog sur la vérification des développeurs. Le déploiement de la vérification se fait par phases et peut s’étendre en 2026-2027. Consultez donc les pages officielles avant d’organiser votre lancement autour de ces dates. Notre guide des exigences de publication en 2026 tient la liste complète à jour.
Comment PrimeTestLab maintient votre série
Le plus difficile dans un test fermé n’est pas de comprendre les règles. Il faut maintenir au moins 12 personnes réelles inscrites et actives pendant 14 jours consécutifs tout en améliorant l’application. PrimeTestLab est conçu précisément pour cela. Nous fournissons des testeurs inscrits sur de vrais appareils et vous guidons dans la configuration de la Play Console, afin que le compteur démarre correctement et continue pendant vos correctifs. Consultez notre service de test fermé Google Play pour connaître tout ce qui est inclus. Notre taux de réussite est de 99.9% sur 12 100+ applications, avec un démarrage en 4-6 heures.
Vous ajoutez nos testeurs dans la Play Console, partagez le lien du test et les 14 jours démarrent. Vous pouvez ensuite publier des mises à jour quand vous en avez besoin: les testeurs restent inscrits pendant que vous itérez.
Minimum exact de Google, sans marge
+5% de frais de service
Plus grande marge contre les départs
+5% de frais de service
Bon équilibre pour plus de sérénité
+5% de frais de service
Un plan au-delà du minimum de 12 testeurs vous apporte des testeurs supplémentaires qui démarrent le même jour: un départ, même causé par une version défectueuse, ne vous fait donc pas passer sous 12. Une marge n’aide que si ces testeurs s’inscrivent tôt: un remplaçant tardif recommence ses propres 14 jours. Les prix s’entendent par application, plus 5% de frais de service (minimum $1.50) au paiement.
Questions fréquentes
Puis-je mettre mon application à jour pendant le test fermé sans recommencer les 14 jours?
Oui. Une mise à jour ordinaire de la même application sur son canal fermé en cours ne fait pas, à elle seule, recommencer le temps d’inscription des testeurs. Gardez vos testeurs actuels éligibles et inscrits. La nouvelle version peut toutefois devoir être examinée et publiée avant que les testeurs puissent l’installer: vérifiez donc la distribution séparément de l’exigence de test.
Qu’est-ce qui réinitialise réellement le compteur du test fermé?
Google ne publie aucune liste des réinitialisations couvrant chaque action de la Console. L’exigence porte sur l’inscription continue de chaque testeur. Un testeur qui quitte le test puis le rejoint recommence ses propres 14 jours, et la perte d’un nombre suffisant de testeurs qualifiés peut retarder votre demande. Un nouveau remplaçant part du premier jour. Une mise à jour ordinaire de la version est un événement différent.
Quelle est la différence entre un testeur invité et un testeur inscrit?
Invité signifie que le compte figure sur votre liste de testeurs ou dans votre Google Group. Inscrit signifie que le testeur a ouvert le lien du test avec ce compte et a rejoint le test. Ajouter une adresse ne suffit pas à finaliser l’inscription. Demandez aux testeurs de confirmer le compte utilisé, puis d’installer l’application, de l’utiliser et d’envoyer des commentaires utiles.
Les testeurs doivent-ils se réinscrire après une mise à jour?
Normalement, non. Les testeurs éligibles déjà inscrits reçoivent une mise à jour ordinaire via Google Play sans rejoindre à nouveau le même test. Préservez leur inscription, puis demandez-leur de vérifier la fiche et la version installée. L’installation automatique dépend de la disponibilité de la version et des paramètres de l’appareil: ne promettez donc pas à chaque testeur la mise à jour en quelques minutes.
Désinstaller l’application revient-il à quitter le test?
Non. Désinstaller retire l’application d’un téléphone, alors que quitter le test modifie la participation au test. Ni le nombre d’installations du jour ni la liste d’invitations du jour ne prouvent une inscription continue. Un testeur qui a désinstallé ne peut pas non plus tester cette installation: vérifiez qu’il est toujours inscrit au test et demandez-lui de réinstaller l’application et de continuer à tester.
Google souhaite-t-il que je publie des mises à jour pendant le test?
Google recommande de tenir compte des commentaires des testeurs et de corriger les problèmes, et la demande d’accès en production vous demande ce que vous avez modifié après le test. Google ne publie aucun nombre de versions obligatoire. Publiez des correctifs utiles quand vous en avez besoin, notez ce qui a changé et testez-les à nouveau. Ne publiez pas de versions cosmétiques uniquement pour respecter une prétendue règle des deux ou trois mises à jour.
Combien de testeurs faut-il réellement pour un test fermé?
Pour les comptes personnels créés après le 13 novembre 2023, le minimum est de 12 testeurs restés chacun inscrits pendant les 14 derniers jours consécutifs au moment de votre demande. Recruter des testeurs supplémentaires tôt vous donne une marge. Les remplaçants ajoutés tardivement n’héritent pas des jours des testeurs partis, et aucun nombre de testeurs ne garantit l’accès en production.
Dois-je publier deux ou trois mises à jour pour être accepté?
Les recommandations publiées par Google ne fixent pas ce quota. Google pose des questions sur le test, les commentaires, les modifications et l’état de préparation. Si le test révèle un vrai problème, corrigez-le et notez le nouveau test. Sinon, décrivez honnêtement le test réalisé. Un nombre de versions ne prouve pas à lui seul que le test a été utile et ne garantit pas que l’accès en production sera accordé.
Ma version est disponible, alors pourquoi mon testeur a-t-il toujours l’ancienne?
Vérifiez le compte Google du testeur, son inscription au canal, le pourcentage de déploiement et le versionCode. Demandez-lui ensuite d’ouvrir la fiche Play et de chercher le bouton Mettre à jour. La mise à jour automatique peut être désactivée ou retardée par l’état de l’appareil. Confirmez que la version est réellement installée: la date de mise à jour de la fiche ne suffit pas.
Le statut "En cours d’examen" met-il mon test de 14 jours en pause?
Une mise à jour en cours d’examen attend que Google traite cette version. Google n’indique nulle part que l’examen d’une mise à jour ordinaire suspend le temps d’inscription déjà accumulé par vos testeurs. Vérifiez que le test en cours reste disponible et que les inscriptions sont intactes. Un nouvel envoi peut retarder l’examen de la version, ce qui est distinct de l’exigence de test continu.
Les testeurs doivent-ils quitter le test et le rejoindre pour obtenir la mise à jour?
Non. Quitter puis rejoindre le test fermé ne règle pas un problème de mise à jour, et cela interrompt les jours consécutifs d’inscription de ce testeur. Vérifiez d’abord la publication, le compte du testeur, le déploiement et le versionCode, puis essayez le parcours de mise à jour normal du Play Store. Réparez séparément une inscription réellement erronée, en sachant ce que cela implique pour les 14 jours de ce testeur.
En résumé
L’essentiel
Mettre votre application à jour pendant le test fermé de 14 jours est sans risque, normal et encouragé. Google mesure l’inscription sans interruption de chaque testeur, donc une mise à jour ordinaire sur le même canal fermé ne fait pas recommencer les 14 jours de vos testeurs. Les vrais risques sont de perdre des testeurs qualifiés, de voir des testeurs quitter officiellement le test ou de publier une version si instable que les testeurs abandonnent. Publiez de vrais correctifs, tenez compte des commentaires et protégez votre effectif avec une marge recrutée tôt. Si vous voulez de l’aide pour garder au moins 12 testeurs inscrits, PrimeTestLab fournit de 12 à 25 testeurs réels dès $19.99, plus 5% de frais de service (minimum $1.50), avec un test lancé en 4-6 heures. Si l’accès en production n’est pas accordé après le test complet, vous choisissez entre un nouveau test gratuit ou un remboursement intégral. Voir les plans →