Non: aucune remise à zéro
Mettez l’application à jour librement, le compteur de 14 jours continueAucune règle ne dit que la création d’une nouvelle version réinitialise le compteur du test fermé. L’exigence des 14 jours mesure le maintien d’au moins 12 testeurs inscrits sans interruption. Elle ne dépend ni de la version de votre application, ni du versionCode, ni du nombre de versions importées.
Le nombre de testeurs inscrits passe sous 12.
Si des testeurs quittent officiellement le test et que l’effectif tombe sous le minimum, la série est interrompue. La cause est le passage sous 12, pas la mise à jour.
Réponse rapide
Non: mettre votre application à jour pendant le test fermé (closed testing) de 14 jours ne remet pas le compteur à zéro. Vous pouvez publier autant de versions que nécessaire. Importer un nouvel AAB sur votre canal de test fermé existant ne recommence pas les 14 jours. Le compteur dépend du maintien d’au moins 12 testeurs inscrits sans interruption, pas de la version de l’application, du versionCode ou de la clé de signature. La période continue ne se rompt que si le nombre de testeurs inscrits passe sous 12, notamment lorsque des testeurs quittent officiellement le test. Les mises à jour sont sans risque et Google les encourage. PrimeTestLab maintient au moins 12 testeurs réels inscrits sans interruption afin que votre série continue pendant que vous publiez vos correctifs.
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. Le compteur de 14 jours suit vos testeurs, pas vos versions. Ce guide distingue précisément les actions qui remettent le compteur à zéro de celles qui ne changent rien. Il propose aussi deux outils interactifs pour vérifier votre situation et explique pourquoi Google souhaite voir de vraies améliorations. Informations mises à jour le 30 juin 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. La réponse est rassurante: importer un nouvel app bundle sur votre canal de test fermé existant ne réinitialise pas l’exigence des 14 jours sans interruption.
Le compteur de 14 jours est lié à vos testeurs, pas à votre version. Google vérifie si vous avez maintenu au moins 12 testeurs inscrits pendant les 14 derniers jours sans interruption. Le numéro de version de l’application, le nombre de nouveaux AAB importés et les modifications apportées aux notes de version n’entrent tout simplement pas dans ce calcul.
La communauté des développeurs Google Play revient sans cesse sur la même question: une nouvelle version destinée au test fermé recommence-t-elle les 14 jours? Plutôt que de reprendre mot pour mot des réponses de forums impossibles à confirmer indépendamment, ce guide s’appuie sur la documentation d’aide de la Play Console. Google y définit l’exigence uniquement par le nombre de testeurs inscrits et la durée, jamais par le nombre de versions importées.
Sur les 7 400+ applications que nous avons accompagnées dans ce processus, une mise à jour ordinaire publiée sur le même canal fermé n’a jamais, à elle seule, remis le compteur à zéro. Vous hésitez sur une action précise? Utilisez l’outil ci-dessous: choisissez ce que vous vous apprêtez à faire et vous saurez immédiatement si cela touche votre période de 14 jours.
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 seul testeur quitte le test et que vous tombez à 11, la série peut être interrompue et les deux semaines recommencent. C’est la première cause d’échec des tests menés sans accompagnement.
Des testeurs quittent officiellement le test
Un testeur se retire en ouvrant la page du test et en choisissant de quitter. Ce n’est pas la même chose que désinstaller l’application, et le compteur n’est touché que si l’effectif passe sous 12.
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é 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). Ajoutez de brèves notes de version décrivant les changements, puis enregistrez. Restez sur le même canal: c’est ce qui préserve la période de 14 jours sans interruption.
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é. Si nécessaire, cliquez sur Send changes for review dans Publishing overview. Une modification publiée peut mettre plusieurs heures à parvenir aux testeurs. Dès que la nouvelle version est disponible, leurs appareils se mettent à jour automatiquement: sans réinstallation et sans nouvelle inscription.
Cette opération ne remet jamais le compteur à zéro. Vous publiez sur le même canal fermé auquel vos testeurs sont déjà inscrits, la période de 14 jours sans interruption continue donc avec la nouvelle version. Vous ajoutez une version, vous ne commencez pas un nouveau test. Toute la réponse tient dans cette distinction.
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 ne réinitialise jamais votre progression. Les testeurs restent inscrits et le compteur continue avec chaque nouvelle version. Pour voir tout le processus, consultez notre guide sur la bonne façon d’inviter des testeurs.
Conseil tiré de milliers de tests: gérez vos testeurs avec un Google Group plutôt qu’avec une liste d’adresses statique. Lorsqu’un groupe est relié à la Play Console, vous ajoutez ou retirez un testeur en modifiant le groupe. Le lien du test ne change pas et le canal reste actif. Vous évitez ainsi de supprimer accidentellement des participants actifs lors d’une modification de la liste, l’un des rares gestes susceptibles d’interrompre votre série.
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é, peut donner l’impression d’un test mené uniquement pour cocher une case. À l’inverse, une application améliorée en réponse aux commentaires ressemble à un véritable travail de développement. Certains développeurs publient volontairement deux ou trois petits correctifs utiles pour montrer leur réactivité.
Il s’agit d’un consensus de la communauté et d’une déduction raisonnable, pas d’une règle publiée par Google. Google n’impose aucun nombre précis de 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.
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 remise à zéro n’est jamais causée par la mise à jour. Elle vient du passage sous 12 testeurs inscrits. La version instable ne fait que déclencher les départs. Gardez des versions stables et une marge de testeurs, et le risque indirect disparaît lui aussi.
Les testeurs doivent-ils réinstaller l’application ou se réinscrire après une mise à jour?
Non. Une fois qu’un testeur s’est inscrit et a installé votre application, Google distribue les mises à jour automatiquement. Il n’a rien à cliquer et vous n’avez rien à lui renvoyer.
Les mises à jour sont distribuées automatiquement
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 une version riche en nouvelles autorisations au jour 5 et le nombre de testeurs actifs peut diminuer, car certains n’auront jamais vu la demande. Vous affaiblissez alors précisément la participation examinée par Google lors de la demande d’accès en production. Une nouvelle autorisation à haut risque peut aussi déclencher un examen de la déclaration des autorisations et retarder entièrement la publication.
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é |
* Le compteur continue en principe, mais une personne qui désinstalle revient rarement. ** Seulement si le départ vous fait passer sous 12. Les deux dernières lignes sont des précautions signalées par la communauté, pas des règles confirmées dans la documentation de Google. Considérez-les comme des risques à éviter. Un Google Group supprime entièrement le risque d’écraser la liste.
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.
Les comptes de développeur 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 7 400+ applications, avec un démarrage en 4-6 heures.
Vous ajoutez nos testeurs dans la Play Console, partagez le lien du test et le compteur démarre. Vous pouvez ensuite publier autant de versions que nécessaire. Les testeurs restent inscrits et la série continue. Si vous gérez plusieurs canaux de test, restez sur le même canal fermé pendant toute la série.
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
+5% de frais de service · Nouveau test gratuit ou remboursement intégral
La plupart des développeurs choisissent plus que le minimum de 12 testeurs afin qu’un seul départ, même provoqué par une mauvaise version, ne les fasse pas passer sous 12. Cette marge est la protection la moins coûteuse contre le seul événement qui interrompt réellement la série.
Questions fréquentes
Puis-je mettre mon application à jour pendant le test fermé sans recommencer les 14 jours?
Oui. Importer une nouvelle version sur votre canal de test fermé existant ne réinitialise pas la période de 14 jours sans interruption. Le compteur dépend du maintien d’au moins 12 testeurs inscrits, pas de la version de votre application. Les testeurs reçoivent automatiquement la mise à jour et restent inscrits, votre progression se poursuit donc d’une version à l’autre.
Qu’est-ce qui réinitialise réellement le compteur du test fermé?
La période de 14 jours sans interruption est rompue lorsque le nombre de testeurs inscrits passe sous 12. Cela peut arriver si des testeurs quittent officiellement le test et vous font tomber sous le minimum. Les nouvelles versions, les modifications de la fiche Play Store et les plantages ne réinitialisent pas le compteur. Garder quelques testeurs au-delà de 12 est le moyen le plus fiable de protéger votre série.
Quelle est la différence entre un testeur invité et un testeur inscrit?
Invité signifie que vous avez ajouté son adresse e-mail à votre liste, ce qui ne suffit pas. Inscrit signifie qu’il a ouvert votre lien partageable, s’est connecté et a accepté de participer: c’est ce statut que mesure le compteur de 14 jours. Seuls les testeurs inscrits comptent, vérifiez donc toujours qu’ils ont terminé cette étape.
Les testeurs doivent-ils se réinscrire après une mise à jour?
Non. Une fois qu’un testeur s’est inscrit et a installé votre application, Google lui distribue automatiquement les mises à jour en quelques minutes. Il n’a ni à réinstaller l’application ni à cliquer de nouveau sur le lien. Son inscription, qui est le statut mesuré par l’exigence des 14 jours, continue sans interruption pour chaque nouvelle version publiée sur le même canal fermé.
Désinstaller l’application revient-il à quitter le test?
Non. Un testeur ne quitte officiellement le test qu’en ouvrant la page du test et en choisissant de se retirer. S’il se contente de désinstaller l’application, le compteur continue en principe. Dans la pratique, un testeur qui désinstalle revient rarement, ce qui peut affaiblir la participation présentée dans votre demande d’accès en production. Il reste donc utile de garder vos testeurs actifs.
Google souhaite-t-il que je publie des mises à jour pendant le test?
La documentation de Google recommande de continuer à corriger les problèmes pendant le test fermé avant la production et de tester régulièrement les futures versions. La communauté des développeurs considère aussi les mises à jour utiles comme un signe de participation réelle, contrairement à une application figée qui semble simplement cocher une case. Google n’impose toutefois aucun nombre de mises à jour: améliorez réellement l’application, sans publier pour la forme.
Combien de testeurs faut-il réellement pour un test fermé?
Le minimum de Google est de 12 testeurs inscrits pendant 14 jours sans interruption pour les comptes de développeur personnels créés après le 13 novembre 2023. Comme un seul départ peut vous faire passer sous 12 et interrompre la série, beaucoup de développeurs prévoient 20 à 25 testeurs. PrimeTestLab propose des plans de 12, 20 et 25 testeurs dès $19.99, plus 5% de frais de service.
En résumé
L’essentiel
Mettre votre application à jour pendant le test fermé de 14 jours est sans risque, normal et encouragé. Le compteur dépend du maintien d’au moins 12 testeurs inscrits sans interruption, une nouvelle version ne le réinitialise donc jamais à elle seule. Les vrais risques sont de passer sous 12 testeurs inscrits, de voir des participants quitter officiellement le test ou de publier une version si instable qu’elle les pousse à partir. Publiez vos correctifs, améliorez l’application à partir des commentaires et protégez votre effectif avec quelques testeurs au-delà du minimum. Pour une série qui ne se rompt pas, PrimeTestLab maintient de 12 à 25 testeurs réels inscrits dès $19.99, plus 5% de frais de service, avec un démarrage en 4-6 heures. Voir les plans →