Publier sa première app Android en 2026 : le test fermé (12 testeurs, 14 jours) pas à pas

En bref

• Si votre compte développeur personnel a été créé après le 13 novembre 2023, Google exige un test fermé avec au moins 12 testeurs inscrits sans interruption pendant 14 jours avant de vous laisser publier en production.
• Le test interne ne compte pas. Seul le test fermé fait avancer le compteur. J'ai moi-même confondu les deux liens.
• Depuis le 31 août 2026, une nouvelle app doit cibler Android 16 (niveau d'API 36). Vérifiez-le avant tout le reste : c'est le seul point qui peut tout bloquer.
• La partie la plus longue n'est ni le code ni la fiche : c'est réunir 12 vraies personnes et les garder 14 jours. Visez 15 à 20.
• Comptez environ 3 semaines entre le premier envoi et l'accès à la production, dont 14 jours d'attente incompressibles.
• Je vous donne ma checklist, mes modèles de messages et le calendrier que j'ai suivi, tirés de la publication de Qodex.

Pourquoi j'écris ce guide

J'ai publié Qodex, un scanner de QR codes et de codes-barres 100 % hors ligne, en octobre 2026. Sur le papier, la procédure tient en une page. En pratique, j'ai buté sur une dizaine de détails que la documentation mentionne à peine : une bannière refusée sans explication, un avertissement sur des « symboles de débogage natifs », une question sur l'IA générative, un lien de test qui n'était pas le bon, et surtout la question qui fâche : où trouver 12 testeurs quand on n'a pas d'audience ?

Ce guide suit l'ordre réel dans lequel les choses se passent dans la Play Console. Chaque étape indique ce qu'il faut préparer, le temps que ça m'a pris, et le piège que j'ai rencontré. Les règles de Google citées ici ont été vérifiées sur les pages d'aide officielles en octobre 2026. Elles changent régulièrement : un lien vers la source est donné à chaque fois.

1. Avant de commencer : les 4 vérifications qui évitent de tout refaire

1.1 Votre type de compte

Google propose deux types de comptes développeur : personnel et organisation. Le choix est définitif.

• Compte personnel créé après le 13 novembre 2023 : vous êtes soumis à l'obligation de test fermé (12 testeurs, 14 jours). C'est mon cas.
• Compte organisation : pas d'obligation de test fermé, mais il faut une structure légale et, en général, un numéro D-U-N-S.

L'inscription coûte 25 dollars US, une seule fois, et Google peut vous demander une pièce d'identité officielle et une carte bancaire à votre nom légal. Les cartes prépayées ne sont pas acceptées. Source : Google Play Console, création du compte.

1.2 Le niveau d'API ciblé (targetSdk)

C'est le point qui m'a fait changer d'app au dernier moment. Ma première candidate ciblait l'API 35. Or, depuis le 31 août 2026, les nouvelles apps et les mises à jour doivent cibler Android 16 (API 36) pour être acceptées. Une prolongation jusqu'au 1er novembre 2026 peut être demandée dans la Console, mais je ne recommande pas de démarrer une première publication sur un sursis. Source : exigences de niveau d'API cible.

Comment vérifier :

• Projet Kotlin/Java : ouvrez app/build.gradle.kts et cherchez targetSdk = 36.
• Projet Flutter : la valeur vient souvent de flutter.targetSdkVersion, qui dépend de votre version de Flutter. Une version ancienne de Flutter peut vous laisser en API 35 sans que vous l'ayez choisi. Fixez la valeur explicitement ou mettez Flutter à jour.

Ma règle depuis : pour une toute première publication, je choisis l'app la plus « propre » (API 36, peu de permissions, pas de données collectées), pas l'app la plus ambitieuse. Le but est d'obtenir l'accès à la production. Les apps complexes viendront ensuite sur un compte déjà validé.

1.3 Un nom de paquet définitif

L'identifiant (applicationId, par exemple com.oufrid.qodex) ne peut jamais être changé après le premier envoi. Vérifiez aussi que le nom de l'app est cohérent partout : chaînes de caractères, écran « À propos », nom des fichiers exportés. Sur Qodex, deux restes de l'ancien nom de projet traînaient encore dans le presse-papiers et dans le nom du fichier CSV exporté. Aucun outil ne les signale : il faut chercher l'ancien nom dans tout le code.

1.4 Une clé de signature sauvegardée

Vous signez votre AAB avec une clé d'importation (upload key). Google re-signe ensuite l'app avec sa propre clé grâce à Play App Signing. Si vous perdez votre clé d'importation, Google peut la réinitialiser, mais c'est une procédure dont on se passe volontiers. Gardez le fichier .jks et ses mots de passe dans un gestionnaire de mots de passe, jamais dans le dépôt Git ni dans une conversation.

2. Le temps à prévoir, étape par étape

Google indique que l'examen de la demande d'accès à la production prend « généralement sept jours ou moins, mais parfois plus ». Source : exigences de test pour les nouveaux comptes personnels.

3. Préparer l'AAB : le fichier que vous envoyez à Google

Google Play n'accepte plus d'APK pour les nouvelles apps : il faut un Android App Bundle (AAB). Google génère ensuite les APK adaptés à chaque téléphone.

Checklist avant l'envoi :

1. targetSdk à 36 (voir plus haut).
2. versionCode entier, qui augmentera à chaque envoi (1, 2, 3…). Il ne peut jamais redescendre.
3. versionName lisible (par exemple 1.0.1), c'est ce que voient les utilisateurs.
4. AAB signé avec votre clé d'importation, en mode release.
5. Minification activée si possible (isMinifyEnabled = true) et testée : une minification mal configurée provoque des plantages qui n'apparaissent qu'en release.
6. Test sur un vrai téléphone de l'APK release (pas seulement la version debug).

Pour mes apps, la compilation est faite par GitHub Actions : chaque version taguée produit une Release contenant l'AAB et tous les APK (universel et par architecture). Avantage : je peux installer l'APK universel sur mon téléphone pour vérifier exactement ce que j'envoie à Google.

L'avertissement « symboles de débogage natifs »

Après l'envoi de l'AAB, la Console m'a affiché : « Cet App Bundle contient du code natif et vous n'avez pas importé de symboles de débogage. »

J'avais pourtant debugSymbolLevel = "SYMBOL_TABLE" dans ma configuration. L'explication : le code natif de Qodex ne vient pas de moi, il vient de ML Kit, la bibliothèque de Google qui reconnaît les codes-barres. Ces bibliothèques sont livrées déjà compilées et sans symboles. Il n'existe donc rien à importer.

Verdict : c'est un avertissement, pas une erreur. Il ne bloque ni l'examen ni la publication. Si votre app contient votre propre code C ou C++, importez les symboles. Si le code natif vient uniquement de bibliothèques tierces (ML Kit, TensorFlow Lite, certains moteurs de jeu), vous pouvez l'ignorer.

4. La fiche du Store : textes et visuels

4.1 Les textes

Rédigez chaque langue séparément. Une traduction automatique brute se remarque, surtout en arabe. Pour aller plus vite, j'ai créé le générateur de fiche Play Store du Lab : il compte les caractères en direct dans les trois langues et vous signale ce qui dépasse.

4.2 Les visuels : le tableau que j'aurais aimé avoir

Spécifications officielles vérifiées sur la page d'aide des ressources graphiques :

Pour être éligible aux recommandations de Google Play, la même page recommande au moins 4 captures de 1080 px minimum (par exemple 1080 × 1920 en portrait).

4.3 Mon problème de bannière (et la solution)

Mon icône est passée du premier coup. La bannière, elle, affichait en boucle « Impossible de charger, veuillez réessayer ». J'ai vérifié le fichier : exactement 1024 × 500, sans canal alpha, 238 Ko. Donc conforme.

Ce qui a débloqué la situation :

1. Réexporter la bannière en JPEG (qualité 90 environ), en supprimant les métadonnées et le profil de couleur intégré.
2. Recharger la page de la Console, puis réessayer, au besoin dans un autre navigateur ou en navigation privée (les extensions bloqueuses de publicité perturbent parfois l'envoi).

Le JPEG reste le format le plus sûr pour la bannière : il ne peut pas contenir de canal alpha, et c'est l'option la plus tolérante à l'envoi.

4.4 Des captures qui vendent

• Prenez les captures sur un vrai téléphone, l'app remplie de données réalistes (pas un historique vide).
• Mettez en premier l'écran qui montre le résultat (pour Qodex : un code scanné et décodé), pas l'écran d'accueil.
• Retirez les captures de dialogues système (demande de permission caméra, par exemple).
• Vérifiez que le nom affiché partout dans l'app est bien le nom final.

5. Les déclarations : contenu de l'app

C'est la partie « administrative ». Elle prend moins d'une heure si vous connaissez les réponses.

5.1 Sécurité des données

Ce formulaire décrit ce que votre app collecte et partage. Soyez exact : une déclaration fausse peut entraîner un retrait. Pour Qodex, la réponse était simple : aucune donnée collectée, aucune donnée partagée, l'app ne demande même pas la permission Internet.

Attention : les bibliothèques tierces comptent. Si vous intégrez un SDK d'analyse, de publicité ou de rapports de plantage, ce qu'il collecte doit être déclaré.

5.2 Classification du contenu

Un questionnaire (violence, contenu sexuel, langage, jeux d'argent, contenu généré par les utilisateurs…). Pour un utilitaire sans contenu sensible, vous obtenez une classification « tout public ».

5.3 La question sur l'IA générative

La Console m'a demandé si mon app contenait du contenu généré par IA, avec le choix de « labelliser » ou non. J'ai hésité, parce que ma description parlait d'« IA embarquée ».

Ce qu'il faut comprendre : la question vise les apps qui génèrent du contenu (texte, image, voix, vidéo) avec un modèle génératif. Qodex utilise de l'IA de reconnaissance : elle lit un code-barres, elle ne crée rien. J'ai donc répondu non.

Répondre « oui » à tort n'apporte rien et ajoute des obligations, par exemple permettre aux utilisateurs de signaler du contenu généré offensant. Répondez selon ce que fait réellement votre app. Si votre app génère vraiment du contenu, déclarez-le.

5.4 Les autres déclarations

• Public cible : si vous cochez une tranche d'âge incluant des enfants, des règles supplémentaires s'appliquent (programme Familles).
• Publicités : oui ou non, selon votre app.
• Accès à l'app : si une partie de l'app est protégée par un compte, fournissez des identifiants de test aux examinateurs.
• Politique de confidentialité : une URL publique est obligatoire. Celle de Qodex est générée automatiquement par mon site à partir des données de l'app.

6. Le test fermé : la partie que tout le monde sous-estime

6.1 Test interne ou test fermé : ne vous trompez pas de lien

La Console propose plusieurs pistes de test. Je les ai confondues, et j'ai failli lancer mes 14 jours sur la mauvaise.

Le premier lien que j'ai copié était un lien de test interne. Si vous voyez internaltest dans l'URL, ce n'est pas le bon.

6.2 La règle exacte, telle que Google l'écrit

Pour les comptes personnels créés après le 13 novembre 2023, il faut un test fermé avec au moins 12 testeurs inscrits sans interruption depuis au moins 14 jours. Tant que ce n'est pas fait, la production est désactivée. Source : Google Play Console Help.

Ce que ça implique en pratique :

• « Sans interruption » : un testeur qui se désinscrit au jour 10 ne compte plus. Plusieurs développeurs rapportent que si le nombre de testeurs repasse sous 12, le décompte repart de zéro. Ne prenez aucun risque : visez 15 à 20 testeurs.
• Inscrit ne veut pas dire « présent dans votre liste » : la personne doit avoir cliqué sur le lien d'inscription et accepté l'invitation avec le bon compte Google.

6.3 Liste d'e-mails ou groupe Google : prenez le groupe

Pour définir qui a le droit de tester, la Console accepte une liste d'adresses ou un groupe Google. J'ai choisi le groupe :

• on l'ajoute une seule fois dans la Console ;
• ensuite, on gère les membres dans Google Groupes, sans retoucher la Console ;
• on peut l'ouvrir aux demandes d'adhésion pour que les gens s'inscrivent eux-mêmes.

Mise en place :

1. Créez le groupe sur Google Groupes (le mien : une adresse en @googlegroups.com).
2. Réglez qui peut rejoindre : « sur demande » si vous voulez valider chaque personne, ou ajout direct par vous.
3. Dans la Console : Test fermé → Testeurs → Groupes Google → collez l'adresse du groupe.
4. Copiez le lien d'inscription affiché dans cette même page.

6.4 Le canal de feedback : un e-mail suffit

La Console demande une adresse e-mail ou une URL pour les retours des testeurs. Pour un test fermé de 15 à 20 personnes, un e-mail est le meilleur choix : direct, personnel, sans formulaire à maintenir. Un formulaire structuré ne devient utile qu'avec des dizaines de testeurs.

6.5 Le parcours testeur en 2 étapes (le piège du lien qui ne marche pas)

Le lien d'inscription ne fonctionne que pour quelqu'un qui fait déjà partie du groupe. Une personne qui clique avant d'y être ajoutée voit simplement qu'elle n'est pas testeuse. Si vous partagez seulement ce lien, vous perdez des gens.

J'ai donc construit sur la page de Qodex un parcours en deux étapes numérotées :

1. S'inscrire comme testeur : un bouton vers mon Google Form, qui demande l'adresse Gmail utilisée sur le téléphone Android.
2. Rejoindre le test et installer : une fois l'inscription validée (je préviens la personne), elle revient, clique sur le lien d'inscription, accepte, puis installe depuis Google Play.

Un avertissement rappelle que l'étape 2 ne fonctionne qu'après validation, sur Android uniquement, avec le Gmail indiqué. Depuis, toute app que je passe en test reçoit automatiquement ce même parcours sur mon site.

7. Trouver 12 testeurs quand on n'a pas d'audience

C'est le vrai sujet. Avec la famille et les amis, c'est facile : on envoie un message, on demande le Gmail, c'est réglé. Mais demander son adresse e-mail à un inconnu en message privé, ça inspire de la méfiance. La solution : ce sont les inconnus qui viennent à vous, dans un cadre où donner son Gmail est normal.

7.1 Les quatre sources qui fonctionnent

1. Votre entourage (famille, amis, collègues, clients) : la base, avec un Android et un compte Gmail. Ils n'ont pas besoin d'utiliser l'app intensivement, juste de la garder installée.
2. Les communautés d'échange de testeurs : depuis l'arrivée de la règle, des développeurs se testent mutuellement sur Reddit (cherchez « closed testing » dans les communautés Android et bêta-test), sur Telegram et sur Discord. Vous testez leurs apps, ils testent la vôtre. Là-bas, donner son Gmail est le principe même de l'échange.
3. Un formulaire public sur votre site, relayé sur vos réseaux (LinkedIn, X, groupes Facebook de développeurs) : ceux qui le remplissent sont volontaires.
4. Les services payants de testeurs : ils existent, mais la qualité est variable et ils ne remplacent pas de vrais utilisateurs. Je les garde en dernier recours.

7.2 Lever le doute : la phrase qui rassure

Quand vous expliquez pourquoi vous demandez l'adresse, la méfiance tombe. Voici la formule que j'utilise :

C'est simplement le compte Google que vous utilisez déjà sur le Play Store. Je ne vois jamais votre mot de passe : Google a seulement besoin de la liste des comptes autorisés à tester. Vous pouvez quitter le test quand vous voulez. C'est une exigence officielle de Google avant toute publication.

7.3 Modèle de message : entourage (WhatsApp)

Salut ! Je viens de publier ma première app Android, Qodex :
un scanner de QR codes et codes-barres 100 % hors ligne,
sans pub ni traqueur. Avant la sortie publique, Google me
demande quelques testeurs. Tu peux m'aider ? Il suffit de
l'installer et de la garder environ 2 semaines.
Si oui, envoie-moi l'adresse Gmail de ton téléphone Android.

7.4 Modèle de message : communauté d'échange (Reddit, Telegram)

[Échange de test fermé] Qodex : scanner QR et codes-barres hors ligne

Je cherche des testeurs pour mon test fermé (règle des 12 / 14 jours).
En échange, je teste votre app et je la garde installée 14 jours.

1. Inscription (Gmail du téléphone Android) : <lien du formulaire>
2. Je vous ajoute sous 24 h et je vous préviens.
3. Vous rejoignez le test : <lien du test fermé>

Laissez le lien de votre test en réponse, je m'inscris dans la journée.

Deux règles dans ces communautés : tenez votre part de l'échange (gardez leurs apps 14 jours vous aussi), et soyez réactif pour ajouter les gens au groupe, sinon ils abandonnent.

7.5 Modèle de message : une fois la personne ajoutée

C'est bon, tu es inscrit comme testeur. Trois étapes :
1. Ouvre ce lien : <lien du test fermé>
2. Appuie sur « Devenir testeur »
3. Appuie sur « Télécharger sur Google Play » et installe
Important : utilise le téléphone avec le Gmail que tu m'as donné,
et garde l'app installée environ 2 semaines. Merci !

8. Le calendrier type, de J-0 à la production

Conseil : ne lancez pas le décompte avec 3 testeurs. Rassemblez d'abord une quinzaine d'inscrits, ajoutez-les tous, puis partagez le lien. Les 14 jours seront plus sûrs.

9. Demander l'accès à la production

Quand les conditions sont remplies, un bouton apparaît dans le tableau de bord. Le formulaire comporte trois parties : votre test fermé, votre app, et sa préparation pour la production. Répondez concrètement :

• Comment avez-vous recruté vos testeurs ? Dites-le honnêtement (entourage, communautés, formulaire).
• Quels retours avez-vous reçus et qu'avez-vous changé ? Citez des exemples précis : un bug corrigé, un texte clarifié. C'est là qu'un vrai test fait la différence.
• Pourquoi l'app est-elle prête ? Stabilité, absence de plantages, fonctions testées.

Si Google estime que l'app n'est pas prête, il peut vous demander de poursuivre le test. Ce n'est pas un refus définitif.

10. Les pièges et leurs solutions

11. Et pour les APK hors Google Play ?

Si vous distribuez aussi vos apps en APK sur votre site, une nouvelle règle vous concerne. Google a lancé la vérification des développeurs Android : dans un premier temps au Brésil, en Indonésie, à Singapour et en Thaïlande, avec une extension mondiale prévue en 2027. Les apps de développeurs non vérifiés y deviennent plus difficiles à installer sur les appareils certifiés. Source : Android developer verification.

Si vous publiez sur Google Play avec un compte vérifié, vous êtes déjà dans le bon cadre. Pour les APK distribués ailleurs, suivez l'évolution de cette page.

FAQ

Le test interne compte-t-il dans les 14 jours ?

Non. Seul le test fermé compte. Le test interne sert à vérifier rapidement l'installation avec jusqu'à 100 testeurs, mais il ne débloque pas la production.

Mon compte organisation est-il concerné par les 12 testeurs ?

Non. La règle vise les comptes développeur personnels créés après le 13 novembre 2023. Les comptes organisation n'y sont pas soumis.

Les testeurs doivent-ils utiliser l'app tous les jours ?

La règle porte sur le fait d'être inscrit sans interruption pendant 14 jours. Dans votre demande d'accès à la production, Google vous interroge sur le test et les retours reçus : des testeurs qui ouvrent l'app et vous font des remarques rendent votre dossier bien plus solide.

Que se passe-t-il si un testeur se désinscrit pendant le test ?

Il ne compte plus. Si vous repassez sous 12 testeurs, vous risquez de devoir reprendre le décompte. C'est pour ça qu'il faut recruter une marge de 3 à 8 personnes.

Puis-je publier une mise à jour pendant le test fermé ?

Oui. Envoyez un nouvel AAB avec un versionCode supérieur sur la même piste. Les testeurs inscrits restent inscrits. Corriger les retours pendant le test est même un bon argument pour la demande de production.

Faut-il déclarer l'IA si mon app utilise ML Kit ?

La question concerne l'IA générative, qui produit du contenu. La reconnaissance (codes-barres, texte, visages) n'en fait pas partie. Répondez selon ce que fait réellement votre app.

Combien de temps faut-il au total ?

Dans mon cas, il faut compter environ trois semaines entre le premier envoi et l'accès à la production : quelques jours d'examen, le temps de réunir 12 testeurs, 14 jours de test, puis environ 7 jours d'examen final.

---

Vous préparez la publication d'une app et vous voulez éviter ces trois semaines d'essais et d'erreurs ? Je conçois et publie des applications Android de bout en bout, compte, fiche et test fermé compris. Parlons de votre projet. Et si vous voulez tester mes prochaines apps avant tout le monde, rejoignez le club des testeurs.