Chapitre 13.4 — ⚠️ Le test fermé obligatoire

Où on en est : fiche prête, app sur la piste interne. Voici l’étape que 100 % des devs solo découvrent en gémissant : Google exige que de VRAIS testeurs utilisent l’app pendant deux semaines avant d’ouvrir la production. Stratégies incluses.

⏱️ TL;DR — Pour les comptes personnels créés après fin 2023 : ≥ 12 testeurs opt-in pendant 14 jours consécutifs sur une piste de test fermé, PUIS un questionnaire (« qu’avez- vous appris ? ») conditionnent l’accès à la production. Les testeurs = des comptes Google que vous invitez (email ou lien). Le but affiché : élever la qualité moyenne du Store. Le plan de bataille : recruter AVANT (famille, amis, collègues, communautés d’entraide), faciliter l’opt-in, maintenir l’engagement 14 jours, et utiliser VRAIMENT les retours.

🎯 Objectifs

• Connaître la règle exacte (qui, combien, combien de temps, quoi ensuite).
• Monter la piste fermée et le parcours d’opt-in des testeurs.
• Recruter 12+ testeurs sans réseau — les stratégies qui marchent.
• Transformer la contrainte en vrai bêta-test (retours exploités).

La règle exacte

Pour tout compte personnel créé après le 13 novembre 2023, chaque app doit, AVANT de pouvoir prétendre à la production :

1. Mener un test fermé avec au moins 12 testeurs opt-in en continu sur 14 jours consécutifs (le compteur ne démarre que quand 12 sont actifs opt-in ; s’il en tombe à 11, le chrono peut se figer).
2. Puis répondre au questionnaire de production dans la Console : qui a testé, ce que vous avez appris, ce que vous avez corrigé — des réponses substantielles (c’est relu).
3. Google accorde (ou pas — rarement refusé si le dossier est réel) l’accès à la production.

Les comptes organisation sautent tout ça (ch. 13.1). Les 25 $ d’Apple-envy s’inversent ici : la barrière Android est en nature, pas en dollars.

Monter la piste

Console → Tests → Test fermé → créer la piste (une suffit) :

• Uploadez la release (le même AAB que l’interne, ou eas submit --track ajusté).
• La liste d’emails : créez une liste de testeurs, collez les adresses Google des volontaires (ou activez le lien d’opt-in ouvert à qui a l’URL — plus simple à diffuser).
• Chaque testeur : clique le lien d’opt-in → accepte → installe depuis le Play Store (fiche normale, badge test). L’app se met à jour comme une app normale.

Le parcours a de la friction (compte Google requis, deux écrans d’opt-in) : votre message d’invitation doit la réduire — voir plus bas.

Recruter 12 testeurs — les stratégies réelles

Par ordre d’efficacité constatée :

1. Le premier cercle (famille, amis, collègues) : 6-10 personnes atteignables. Le message-type : « J’ai fait une app, Google exige 12 testeurs pendant 2 semaines pour la publier. Il suffit d’installer via ce lien et de l’OUVRIR de temps en temps — je te relancerai deux fois, promis. » L’honnêteté sur l’engagement (14 jours !) évite les abandons qui gèlent le chrono.
2. Les communautés d’entraide entre devs : le besoin étant universel, des groupes « testeurs mutuels » existent (subreddits dédiés au closed testing, Discord d’Expo/RN, forums). Le deal : je teste la tienne, tu testes la mienne. Efficace, mais des testeurs zombies (installent, n’ouvrent plus) — sur-recrutez.
3. Votre audience si vous en avez une (X/LinkedIn, la newsletter du boulot…).

La règle d’or : visez 16-18 opt-in pour tenir 12 actifs — la déperdition est la norme.

Tenir 14 jours — et en tirer quelque chose

Le chrono tourne sur l’engagement continu — deux relances prévues (J+5, J+10 : « pense à ouvrir l’app 1 min ») font partie du plan. Mais surtout : c’est un VRAI bêta-test gratuit — ne le gâchez pas :

• Le défi quotidien (ch. 9.2) est votre allié rétention : suggérez aux testeurs de l’activer — l’app les relance à votre place.
• Poussez une OTA pendant le test (channel de la piste) : vous validez le pipeline complet en conditions réelles, et les testeurs voient l’app s’améliorer.
• Collectez : un petit formulaire (Google Forms), ou juste « réponds à ce mail » — les réponses alimentent le questionnaire de production (Google demande précisément ça).

⚠️ Piège — Les « services de 12 testeurs » payants qui pullulent : outre le principe (contourner l’esprit de la règle), Google détecte les fermes de testeurs et le questionnaire de production demande des RETOURS substantiels — « j’ai payé des inconnus » s’y lit. Et un refus de production après un test bidon coûte plus cher (re-test) que les 14 jours honnêtes. Le premier cercle + l’entraide couvrent le besoin, gratuitement.

💡 Pour un dev Next.js — Il n’existe AUCUN équivalent web (imaginez Vercel exigeant 12 visiteurs quotidiens avant d’autoriser un domaine…). Prenez-le comme Google le vend : un forcing de bêta-test que les devs solo ne s’imposent jamais d’eux-mêmes. Les retours de 12 vrais humains sur une app qu’on croyait finie sont — l’expérience le confirme — systématiquement humiliants et précieux.

✏️ Exercices

1. Écrivez votre message d’invitation (2 versions : premier cercle, communauté d’entraide) — avec le lien, l’engagement exact demandé, et la promesse de relance bornée.

2. Planifiez la timeline du test de bout en bout (rétro-planning du ch. 13.1, zoomé) : que se passe-t-il chaque jour de J-7 à J+16 ?

3. Rédigez trois questions de feedback qui produisent des réponses EXPLOITABLES (pas « c’est bien ? ») — et qui rempliront le questionnaire Google.

🧠 Quiz

1. Qui est soumis au test fermé obligatoire, et quelles sont les exigences chiffrées ?

2. Pourquoi sur-recruter à 16-18 ?

3. Que demande le questionnaire de production ?

4. Citez deux leviers pour maintenir l’engagement 14 jours.

5. Pourquoi éviter les services de testeurs payants ?

👉 Chapitre suivant : 13.5 — Publication & review — le dernier guichet : la review, ses délais, ses rejets.