Mettre à jour son app pendant les 14 jours de test fermé : le compteur repart-il à zéro ?
Corriger un bug sur la même piste fermée est prévu par Google Play. Le point à protéger n’est pas l’ancien bundle, mais l’opt-in continu de vos testeurs.

Sommaire du guide
Vous découvrez un crash au jour 6 du test fermé. Faut-il attendre huit jours avec une version défectueuse, ou publier une correction et risquer de perdre le compteur ? La bonne réponse est de corriger l’application sur la même piste fermée. Google recommande explicitement de continuer le test pendant la résolution des bugs et de mettre à jour l’application avant la production.
La condition des 14 jours porte sur les testeurs restés opt-in en continu. Elle ne demande pas que les 12 personnes conservent exactement le même App Bundle pendant toute la période. Une mise à jour bien préparée n’interrompt donc pas, à elle seule, leur inscription au programme de test.
Ce que Google mesure réellement
Au moment de la demande d’accès production, au moins 12 testeurs doivent être inscrits au test fermé et l’avoir été sans interruption pendant les 14 jours précédents. Si une personne quitte le programme puis revient, sa propre continuité recommence à la nouvelle date d’opt-in.
Le critère officiel est donc l’inscription continue à la piste, pas l’utilisation d’un numéro de version unique. La documentation de Play Console prévoit d’ailleurs la diffusion de nouvelles versions aux testeurs : leur application reçoit la version publiée la plus élevée à laquelle leur compte et leur appareil sont éligibles.
La méthode sûre pour publier une correction
- Ouvrez la piste fermée qui sert déjà au test obligatoire.
- Préparez un nouvel Android App Bundle avec un versionCode supérieur au précédent.
- Gardez le même nom de package et la même clé de signature.
- Ajoutez des notes de version courtes qui indiquent le bug corrigé.
- Déployez le bundle sur cette même piste, sans la mettre en pause.
- Prévenez les testeurs et demandez-leur de vérifier la mise à jour dans Google Play.
- Contrôlez le numéro de version sur deux ou trois appareils avant de considérer le correctif comme distribué.
Le premier déploiement d’une piste peut demander plusieurs heures avant que le lien et la version soient accessibles. Les changements suivants peuvent eux aussi prendre du temps à se propager : ne concluez pas à un échec après quelques minutes.
Ce qui risque vraiment de casser la continuité
La mise à jour du bundle est normale. Les opérations dangereuses sont celles qui modifient l’éligibilité ou l’inscription :
- mettre la piste fermée en pause ;
- retirer une liste e-mail ou un Google Group de la piste ;
- supprimer un testeur puis le rajouter ;
- demander aux participants de quitter le programme pour changer de piste ;
- déplacer le groupe vers le test interne, qui entre en conflit avec l’accès aux tests ouverts et fermés ;
- publier sur une nouvelle piste sans vérifier que les mêmes comptes y sont autorisés et opt-in.
Avant toute modification de configuration, faites une capture du tableau de bord et exportez votre suivi. Si votre seul objectif est de corriger le code, ne touchez ni au groupe ni à la piste.
Comment obtenir un vrai retour sur la nouvelle version
Un message « mettez à jour l’app » donne peu d’informations. Envoyez plutôt une mini-mission :
- installer la nouvelle version ;
- ouvrir le parcours qui posait problème ;
- reproduire les anciennes étapes ;
- indiquer appareil, version Android et résultat ;
- signaler tout nouveau comportement inattendu.
Notez la version testée dans votre tableau de suivi. Cette trace vous aidera dans le questionnaire de production, où Google demande quels retours ont été reçus et quels changements ont été réalisés grâce au test.
Faut-il attendre la fin des 14 jours pour une grosse refonte ?
Un correctif ciblé est raisonnable. Une refonte qui change l’audience, le parcours principal ou le modèle de données mérite davantage de prudence : la période déjà effectuée ne prouve pas que la nouvelle expérience a été suffisamment testée. Même si le compteur d’opt-in reste visible, accordez assez de temps aux participants pour utiliser les fonctions modifiées avant d’envoyer la demande.
La règle pratique est simple : corrigez sur la même piste, conservez les mêmes inscriptions et documentez chaque version. Pour suivre précisément les participants, utilisez aussi notre guide du tableau de bord des testeurs Play Console.
Transparence éditoriale
Sources consultées
Questions fréquentes
L’essentiel, sans jargon.
Une nouvelle version remet-elle automatiquement les 14 jours à zéro ?
Non, Google définit l’éligibilité par la continuité de l’opt-in des testeurs, pas par leur maintien sur un bundle unique. Publiez la mise à jour sur la même piste fermée et vérifiez que la piste reste active et que les testeurs restent inscrits.
Les testeurs doivent-ils réutiliser le lien d’opt-in après chaque mise à jour ?
Normalement non. Un testeur toujours inscrit reçoit la version de test compatible ayant le code de version le plus élevé. Demandez-lui plutôt de vérifier la mise à jour dans Google Play et de confirmer le numéro de version installé.
Puis-je changer de piste fermée pendant les 14 jours ?
Évitez-le. Une autre piste possède sa propre configuration d’éligibilité. Pour réduire le risque, gardez la piste initiale, son groupe de testeurs et son lien d’opt-in jusqu’à la demande d’accès production.
Commentaires
Continuez votre parcours


