Exigences de publication Google Play pour les nouveaux développeurs en 2026

Google Play ne délivre pas une approbation unique. Il retient une version derrière une succession de verrous indépendants, et chaque verrou a sa propre règle d’applicabilité : une bonne partie de ce qui suit ne vous concernera donc pas.

Chaque exigence ci-dessous comporte les mêmes quatre éléments : à qui elle s’applique, ce que vous faites, ce qui prouve qu’elle est remplie et la page officielle dont elle provient. Lorsque les pages de Google se contredisent entre elles, ce qui arrive sur deux points dans ce guide, vous obtenez les deux versions plutôt que notre supposition.

Les exigences de publication Google Play en un coup d’œil

Tous les verrous figurent ci-dessous, avec la règle qui décide s’il vous concerne et l’élément de Play Console qui prouve qu’il est franchi. Les lignes marquées conditionnel ne s’appliquent pas à tout le monde : une partie des éditeurs les saute entièrement.

L’ordre dans lequel tout cela arrive vraiment

Huit étapes, et cet ordre n’est pas une préférence : trois d’entre elles sont des prérequis stricts de celle qui suit.

1. Choisir et faire vérifier votre compte de développeur Type de compte, frais, identité et vérification de l’appareil lorsque Play Console l’affiche.
2. Créer l’application et préparer un build conforme Création de l’application et ID d’application, App Bundle et signature, API cible, contrôles préalables du build.
3. Vérifier l’enregistrement du développeur Android Un contrôle d’état dans Play Console, une fois l’application et son package créés.
4. Compléter la fiche Play Store et les visuels Limites de caractères, visuels obligatoires, masque de l’icône, déclarations sur les visuels générés par IA.
5. Compléter Contenu de l’application et l’accès pour l’équipe d’examen Confidentialité, Sécurité des données, suppression, classification, public cible, annonces, les deux déclarations universelles et les instructions de connexion.
6. Exécuter le test fermé qualifiant 12 testeurs inscrits pendant 14 jours sans interruption. Comptes personnels créés après le 13 novembre 2023 uniquement.
7. Demander un accès en production Le questionnaire en trois parties sur votre test, votre application et votre préparation.
8. Envoyer et publier la version de production Pays, tarification, bundle, notes de version, envoi pour examen, puis publication.

1. Choisir et faire vérifier votre compte de développeur

Il vous faut un compte Google avec la validation en deux étapes activée, et vous acceptez à l’inscription l’Accord de distribution pour les développeurs ainsi que les Conditions d’utilisation de Play Console. Trois éléments doivent ensuite être validés avant de pouvoir publier : les frais, votre identité et, lorsque Play Console l’affiche, une vérification de l’appareil.

Ce que couvrent les 25 $US, et ce qu’ils ne couvrent pas

Les frais se règlent uniquement par carte de crédit ou de débit. Les types de carte acceptés varient selon le pays, et Google indique explicitement que les cartes prépayées ne sont pas acceptées.

Personnel ou organisation, et quand le choix est déjà fait

Posez d’abord la question de la catégorie, car pour certaines applications il n’y a aucun choix à faire.

Si aucune de ces catégories ne vous concerne, le choix vous appartient. Les deux types peuvent publier et monétiser, et une partie de la différence tient simplement à ce que Google vérifie à votre sujet, mais ce n’est pas qu’une question de paperasse. Un compte personnel créé après le 13 novembre 2023 est en outre soumis à un test fermé qualifiant, l’élément incompressible le plus long de ce guide. Comparaison détaillée : comptes personnels et comptes d’organisation.

Ce qu’exige la vérification du compte, et pourquoi les délais varient

Google vérifie votre identité au niveau du compte avant que vous puissiez publier. Un compte personnel fournit une pièce d’identité officielle ; une organisation fournit en plus les informations de la structure. Ce qui vous est demandé peut dépendre de ce que votre profil de paiement vérifie déjà, et c’est pourquoi deux personnes qui suivent le même guide se voient réclamer des pièces différentes. Vérifier votre identité de développeur

Google ne publie aucun délai de traitement garanti pour l’examen de l’identité d’un compte Play, et le « jusqu’à 5 jours » souvent cité n’en est pas un : ce chiffre provient de la documentation de Google sur les paiements, pas de la page consacrée à l’identité Play. Effectuez les tâches que Play Console affiche et prévoyez d’éventuelles vérifications de documents supplémentaires. La vérification du moyen de paiement est encore autre chose : un contrôle marchand lié à l’encaissement, pas une étape que tout développeur d’application gratuite doit engager. Informations sur le compte et contrôles marchands

Terminé quand : Play Console n’affiche plus la tâche de vérification d’identité pour votre compte. Considérez « envoyé » et « validé » comme deux états distincts : un document envoyé ne débloque pas la publication.

Vérification de l’appareil : le verrou que la plupart des guides oublient

Les nouveaux comptes de développeur personnels ont une tâche distincte liée à l’appareil. Vous confirmez l’accès à un appareil mobile Android physique, non rooté, sous Android 10 ou version ultérieure, depuis l’application mobile Play Console et connecté en tant que propriétaire du compte. Exigences de vérification de l’appareil

Ce que ce n’est pas : le contrôle d’identité, le test fermé qualifiant ou une règle qui porterait sur vos testeurs. Rien ici n’impose que les 12 personnes de votre test fermé disposent d’un appareil répondant à ces caractéristiques. C’est un élément à part sur la page d’accueil de Play Console, et un émulateur ne suffit pas à le valider.

Terminé quand : La tâche de vérification de l’appareil disparaît de la page d’accueil de Play Console.

Changer de type de compte par la suite

Vous pouvez convertir un compte de développeur personnel en compte d’organisation via la procédure de vérification de Google : vérifiez le site web de l’organisation, créez ou sélectionnez puis vérifiez son profil de paiement, et finalisez le changement dans le compte existant. Google conseille d’attendre au moins 72 heures après la conversion avant d’envoyer de nouvelles applications. Le sens inverse, d’organisation vers personnel, impose en revanche un nouveau compte. Conversion du type de compte

2. Créer votre application et préparer un build conforme

Deux moitiés : l’application que vous créez dans Play Console, et l’artefact que vous y importez. Une décision prise ici suit l’application toute sa vie, elle mérite donc trente secondes d’attention.

Les décisions définitives

Créer l’application dans Play Console fixe son nom, sa langue par défaut, son type (application ou jeu) et son caractère gratuit ou payant. L’ID d’application est autre chose : il vit dans votre configuration de build, pas dans ce formulaire de Play Console, et les deux se rejoignent au moment de l’import. Vérifiez donc l’ID d’application dans votre build avant de l’importer, plutôt que de supposer qu’une fiche encore vide dans Play Console l’a déjà figé. Créer et configurer votre applicationID d’application

L’Android App Bundle et les deux rôles de signature

Pour une nouvelle application publique ordinaire, Google Play accepte l’Android App Bundle (.aab) et non un APK, et l’application utilise Play App Signing. Ce périmètre mérite d’être posé une fois plutôt qu’énoncé comme une règle absolue : les anciennes applications éligibles conservent des parcours APK, l’App Bundle est obligatoire pour toutes les applications Android TV depuis juin 2023, et la distribution privée en entreprise obéit encore à d’autres règles. Android App BundleApplications privées

Play App Signing sépare deux rôles, ce qui n’est pas la même chose que deux clés physiques que vous détiendriez. La clé de signature de l’application est gérée par Google et signe ce que les utilisateurs installent. La clé d’importation signe votre bundle avant l’import, pour que Google sache qu’il vient bien de vous. Les deux rôles peuvent reposer sur la même clé ou sur deux clés distinctes ; une clé d’importation distincte est la configuration recommandée, car elle peut être réinitialisée en cas de perte. Signer votre application

Niveau d’API cible, par type d’appareil

C’est l’exigence la plus susceptible de bloquer net un import, et ce n’est pas un chiffre unique : il varie selon ce que vous envoyez.

Google documente des fenêtres de prolongation qui courent jusqu’au 1er novembre 2026 dans certains cas, mais l’éligibilité se décide pour votre application précise, dans Play Console. Exigences de niveau d’API cible Le détail de la migration figure dans le guide de l’API cible.

Contrôles préalables : ce qui peut faire rejeter un bundle en apparence valide

Deux contrôles rattrapent des projets qui paraissent pourtant terminés. Les deux sont conditionnels : si aucun ne concerne votre application, passez directement à la suite.

Bibliothèques natives : 64 bits et pages de 16 Ko

Si votre application embarque du code natif, directement, via un SDK ou généré par un créateur d’applications, vérifiez sa prise en charge du 64 bits et sa compatibilité avec les pages de 16 Ko, et testez-la dans un environnement 16 Ko. Les applications écrites uniquement en Java ou en Kotlin, dépendances comprises, prennent déjà en charge la taille de page concernée. Contrôlez le bundle que vous importez réellement : une dépendance peut réintroduire une bibliothèque 32 bits ou alignée sur 4 Ko sans la moindre modification de votre côté. Tailles de page de 16 Ko64 bits

Version de la Play Billing Library

Si, et seulement si, votre application intègre Play Billing, les nouveaux envois exigent normalement la version 8 ou une version plus récente de la Billing Library. L’échéance ordinaire de la version 7 était le 31 août 2026, et une prolongation applicable peut aller jusqu’au 1er novembre 2026. Rien de tout cela ne concerne une application sans cette intégration, et cela ne signifie pas que les applications déjà installées cessent de fonctionner. Calendrier d’abandon de Billing

Terminé quand : Un fichier .aab signé s’importe sans erreur de format ni d’API cible, le code de version est supérieur à tout ce que vous avez importé auparavant et, si l’application embarque du code natif, vos contrôles de compatibilité et une exécution dans un environnement 16 Ko passent tous les deux. Un import validé par Play Console ne veut pas dire que vos dépendances ont été testées ; corrigez les problèmes bloquants et lisez les avertissements.

3. Vérifier l’enregistrement du développeur Android dans Play Console

Cette étape vient après la précédente parce qu’elle suppose que l’application existe : l’enregistrement rattache une application, via son nom de package et l’empreinte de sa clé de signature, à une identité de développeur vérifiée, à l’échelle de l’écosystème Android et pas seulement de Google Play. C’est autre chose que le contrôle d’identité au niveau du compte de l’étape 1, qui atteste qui vous êtes pour pouvoir détenir un compte.

Pour un éditeur Play, la question pratique est étroite : votre application est-elle enregistrée ? Vérifiez son état sur la page Vérification des développeurs Android de Play Console. Google tente un enregistrement automatique et réutilise la vérification d’identité que vous avez déjà effectuée : pour la plupart des éditeurs Play, c’est donc un contrôle d’état plutôt qu’une tâche. Vous n’avez pas besoin d’un compte Android Developer Console distinct et vous ne refaites pas la vérification d’identité. Confirmez l’enregistrement et effectuez toute action en attente qui y serait signalée. Enregistrer les noms de package Play

Les applications qui restent non enregistrées risquent une suppression de Google Play à l’échelle mondiale à partir du 30 septembre 2026 ; c’est une échéance facile à manquer, car la plupart des articles consacrés à cette date ne décrivent que la phase d’installation dans quatre pays, une autre partie du même programme. Deux points que vous pouvez laisser de côté : le compte gratuit Limited Distribution s’adresse aux amateurs qui diffusent sur une poignée d’appareils et n’est pas une voie d’accès gratuite à Google Play ; et la version minimale d’Android exigée par le vérificateur embarqué est documentée de façon contradictoire (la FAQ Android Developers indique 7 et versions ultérieures, l’aide Android indique 8 et versions ultérieures), ce qui relève d’un conflit non résolu entre deux pages de Google plutôt que d’une exigence à appliquer. Aide Android

Terminé quand : La page Vérification des développeurs Android de Play Console indique l’application comme enregistrée, sans aucune action en attente à son sujet.

4. Compléter votre fiche Play Store et vos visuels

La fiche est ce que les utilisateurs et l’équipe d’examen voient en premier, et elle impose des limites strictes qui bloquent l’enregistrement. La distinction utile passe entre ce que Google exige pour publier et ce qu’il recommande pour être mis en avant ; les deux sont séparés ci-dessous.

Obligatoire pour publier

Google Play Console · capture réelle

Recommandé, mais sans effet bloquant sur la publication

Les consignes de Google sur les visuels de présentation décrivent aussi ce qui rend une fiche éligible aux formats larges et aux emplacements de recommandation : davantage de captures, des résolutions plus élevées, des jeux d’images pour les catégories d’appareils sur lesquelles vous voulez être mis en avant. En omettre ne bloque aucune publication. Les fiches Wear OS, TV et XR ajoutent par-dessus leurs propres règles de visuels. Visuels de présentation

Le masque d’angles de l’icône

Vous importez une icône carrée complète et Google Play applique un masque d’angles dynamique dont le rayon équivaut à 30 % de la taille de l’icône : tout ce qui se trouve près d’un angle est donc rogné dans le rendu. C’est la spécification actuelle, et non, comme on le répète souvent, un changement introduit en 2026. La date de modification d’une page source ne prouve pas à partir de quand une règle s’applique. Spécifications de conception des icônes

Déclarations IA pour les visuels générés

Si vous générez ou retouchez avec l’IA des images, des vidéos ou du matériel promotionnel destinés à votre fiche, Play Console propose désormais des déclarations sur l’honneur, élément par élément, dans ses parcours de création de contenu, avec des libellés appliqués aux éléments qui entrent dans le champ réglementaire applicable. La page d’aide de Google n’indique ni date d’entrée en vigueur ni liste exhaustive des règles couvertes : nous n’inventerons ni l’une ni l’autre. Il s’agit ici des visuels de la fiche, distincts des règles qui encadrent ce qu’une application générative produit pour ses utilisateurs. Déclarer les contenus générés par IA

Les règles de métadonnées qui font refuser une fiche

Les consignes de Google sur les fiches sont strictes quant au langage promotionnel dans les champs qui apparaissent dans les résultats de recherche et les sélections du Play Store : le titre, l’icône, le nom du développeur et la description courte.

Terminé quand : La fiche Play Store principale s’enregistre sans erreur d’élément manquant, et les visuels que vous avez importés restent lisibles une fois le masque d’angles appliqué.

5. Compléter Contenu de l’application et l’accès pour l’équipe d’examen

Contenu de l’application est la partie que les éditeurs débutants sous-estiment, parce que rien n’y relève de la technique et que tout y est bloquant. C’est un empilement de déclarations, et une réponse incomplète ou inexacte compte parmi les causes les plus fréquentes de lancement enlisé.

Règles de confidentialité : toutes les applications, à deux endroits

Toute application a besoin de règles de confidentialité, et pas seulement les applications destinées aux enfants, comme on le présente souvent. Indiquez le lien dans Play Console et un lien ou le texte des règles dans l’application. Utilisez une URL active, publique et sans restriction géographique, pas un PDF. Une application qui ne collecte aucune donnée en a quand même besoin, et « nous ne collectons rien » ne constitue pas des règles de confidentialité : il faut encore identifier l’application et le développeur, donner un contact pour les questions de confidentialité et décrire comment les données éventuellement touchées sont traitées et conservées. Règles relatives aux données utilisateur

Sécurité des données

Toute application présente sur un canal de test fermé, de test ouvert ou de production remplit le formulaire Sécurité des données. Les applications qui ne quittent jamais le canal de test interne en sont exemptées, ce qui est une vraie raison d’utiliser le test interne tôt. Une application qui ne collecte rien remplit quand même le formulaire et le déclare. Sécurité des données

Déclarez ce que votre application collecte et partage réellement, y compris ce que vos SDK font pour votre compte. C’est la partie la plus souvent fausse : un SDK d’analyse, de publicité ou de rapport de plantage collecte des données, que vous ayez écrit ce code ou non, et la déclaration vous incombe. Lisez la documentation propre à chaque SDK plutôt que de supposer qu’un fournisseur se comporte partout de la même façon.

Suppression du compte et des données

Si les utilisateurs peuvent créer un compte dans votre application, vous devez leur permettre d’en demander la suppression depuis l’application et depuis l’extérieur, via une URL web accessible publiquement, et la suppression du compte doit entraîner celle des données associées. Lorsque la loi ou un motif commercial légitime vous impose d’en conserver une partie, indiquez-le.

Tout le reste dans Contenu de l’application

Au-delà de la confidentialité, de la Sécurité des données, de la suppression et de l’Accès à l’application vus plus haut, il reste ceci. Deux de ces déclarations piègent les développeurs parce que leur nom sonne comme une condition : les déclarations Applications de santé et Fonctionnalités financières sont exigées de toute application publique ordinaire présente sur un canal de test fermé, de test ouvert ou de production, même lorsqu’elle n’a ni l’un ni l’autre type de fonctionnalité. Les deux formulaires proposent une réponse « aucune fonctionnalité », et en remplir un ne vous soumet pas pour autant aux règles d’agrément médical ou financier. Déclaration Applications de santéDéclaration Fonctionnalités financières

Google Play Console · capture réelle

Donnez à l’équipe d’examen un accès qui fonctionne

Si une partie de votre application se trouve derrière une connexion ou un autre verrou, renseignez Accès à l’application. Play Console accepte jusqu’à cinq jeux d’instructions, des jeux d’instructions et pas nécessairement cinq jeux d’identifiants, ce qui compte si vous avez un seul compte de connexion et plusieurs parcours protégés. Préparer votre application pour l’examen

Avant l’envoi, vérifiez que les identifiants fonctionnent toujours et que chaque fonctionnalité protégée est accessible à quelqu’un d’autre que vous. Les comptes expirés, les codes à usage unique qui arrivent sur votre téléphone et les fonctionnalités qui ne se débloquent que pour un compte interne sont les échecs habituels.

Terminé quand : Contenu de l’application n’affiche plus aucune tâche en attente, et une autre personne que vous parvient à se connecter avec exactement ce que vous avez saisi dans Accès à l’application.

Déclarations propres à certaines catégories

Au-delà des formulaires ci-dessus, certaines règles dépendent de ce que fait réellement l’application. Celles-ci sont véritablement conditionnelles :

• Applications de santé, au-delà de la déclaration. Si l’application a réellement des fonctionnalités de santé, les règles relatives aux contenus et services de santé ajoutent un étiquetage de dispositif médical et une obligation d’avertissement pour les applications de santé non réglementées, et les applications de santé des types visés exigent un compte d’organisation. Contenus et services de santé
• Applications d’IA générative. Empêchez la production de contenus interdits et donnez aux utilisateurs un moyen de les signaler depuis l’application. Il s’agit ici de ce que l’application produit, distinct des déclarations sur les visuels de la fiche vues plus haut, et ce n’est pas une règle qui imposerait un libellé à toute application assistée par IA. Règles relatives aux contenus générés par IA
• Autorisations pour les photos et les vidéos. Ne demandez un accès étendu que si une fonctionnalité centrale l’exige ; sinon, utilisez le sélecteur de photos du système.
• Localisation et contacts. Les deux font l’objet d’exigences de portée minimale à venir, avec des dates réelles et un périmètre étroit : voir échéances et changements conditionnels.
• Autres catégories. Actualités et magazines, services financiers, applications gouvernementales et d’autres encore disposent chacune d’une page de règles accessible depuis Contenu de l’application.

6. Réaliser le test fermé requis, le cas échéant

S’applique à : les comptes de développeur personnels créés après le 13 novembre 2023. Les comptes d’organisation, ainsi que les comptes personnels créés avant cette date, n’y sont pas soumis du tout : si c’est votre cas, passez directement à l’envoi de la version.

La règle tient en une phrase : exécutez un test fermé avec au moins 12 testeurs inscrits pendant les 14 jours sans interruption qui précèdent votre demande d’accès en production. Le passage de 20 à 12 testeurs est entré en vigueur le 11 décembre 2024 et a conservé les mêmes 14 jours. Exigences de testLe passage de 20 à 12 testeurs

Google Play Console · capture réelle

Trois canaux, et un seul compte vraiment

Le test interne ressemble au raccourci évident et il est réellement utile, mais pas pour cela.

Google évalue deux choses : le nombre de testeurs et leur engagement. Parmi les exemples que Google donne des raisons pour lesquelles il demande des tests supplémentaires figurent des testeurs qui n’ont pas utilisé l’application pendant le test : 12 noms sur une liste ne constituent donc pas l’exigence. Ce que Google ne publie pas, c’est une règle sur le nombre de minutes par jour ou de sessions ; si vous avez lu un chiffre quotidien précis, il ne vient pas de Google, et votre test ne doit pas être planifié autour de lui.

Comment y répondre concrètement

Toutes les autres exigences de ce guide relèvent de la paperasse ou d’un travail technique que vous maîtrisez. Celle-ci demande 12 personnes réelles, sur de vrais appareils Android, qui s’inscrivent et restent inscrites pendant 14 jours sans interruption.

Terminé quand : Play Console affiche 12 testeurs inscrits ou plus et un test fermé actif depuis au moins 14 jours sans interruption, et l’action Demander un accès en production devient disponible sur le tableau de bord.

7. Demander un accès en production, si nécessaire

S’applique à : les mêmes comptes que le test fermé, c’est-à-dire les comptes personnels créés après le 13 novembre 2023. Tous les autres passent directement à la version.

Remplir les critères du test fermé ne vous fait pas passer en production pour autant. Vous déposez la demande depuis le tableau de bord de Play Console et répondez à un questionnaire. On le présente souvent comme un formulaire figé de dix questions ; Google en fait évoluer la formulation au fil du temps, alors retenez-en plutôt trois sujets.

Rédigez à partir du test que vous avez réellement mené. Aucune formulation ne garantit une approbation ; ce sont les détails concrets sur un test réel et des changements réels qui aident. Les réponses génériques mènent notoirement à une demande de tests supplémentaires. Les exemples rédigés sont là pour vous montrer comment décrire votre propre test, pas pour vous fournir un script.

Google indique que cet examen prend habituellement sept jours ou moins, mais qu’il peut parfois durer plus longtemps : prévoyez sept jours sans y voir un plafond. Délais d’examen de l’accès en production Si l’accès est refusé, l’issue habituelle est une demande de tests supplémentaires plutôt qu’un refus définitif, et votre test fermé n’a pas besoin de s’arrêter pendant que vous préparez une nouvelle demande. Que faire après « tests supplémentaires requis ».

Terminé quand : Play Console indique que l’accès en production est accordé. Rien de ce qui précède, ni une liste de contrôle complète, ni 14 jours entiers, ne constitue cet accord : la décision appartient à Google.

8. Envoyer et publier la version de production

L’accès en production, là où il s’applique, débloque le canal ; il ne publie rien. La version suit sa propre séquence, et c’est là que l’on se retrouve avec tout de terminé et rien en ligne. Préparer et déployer une version

1. Pays et régions Commencez restreint et élargissez plus tard si vous le souhaitez.
2. Tarification À fixer avant la première version. Une application gratuite ne pourra pas devenir payante par la suite sous le même nom de package.
3. Ajouter le bundle de la version Sélectionnez un bundle éligible que vous avez déjà importé pour les tests, ou importez un nouveau build avec un code de version supérieur. Faire passer un artefact déjà testé dans la version de production n’oblige pas en soi à le recompiler.
4. Nom de la version et notes de version Le nom est interne ; les notes sont ce que les utilisateurs voient pour cette version.
5. Lisez les erreurs et les avertissements Play Console bloque sur les erreurs et laisse passer les avertissements. Lisez les deux : c’est souvent l’avertissement qui comptera plus tard.
6. Envoyer les modifications pour examen Rien n’est envoyé tant que vous ne l’avez pas fait. Une page de version terminée dont les modifications n’ont jamais été envoyées est l’une des façons les plus discrètes d’enliser un lancement.
7. Suivez-la jusqu’à l’examen et la publication En cours d’examen, prêt à publier et en ligne sont trois états différents. Si la publication gérée est disponible et activée, les modifications approuvées attendent que vous sélectionniez Publier les modifications : une approbation seule ne vaut pas publication. La fiche peut ensuite mettre du temps à apparaître.

Terminé quand : L’aperçu de publication n’affiche plus de modifications non envoyées, et la version de production est indiquée comme en ligne, et pas seulement approuvée. Là où la publication gérée s’applique, cette dernière étape vous revient. Publication gérée et états de publication

Combien de temps prend la publication et ce qui peut se chevaucher

Deux examens se trouvent près de la ligne d’arrivée, et ils sont distincts : l’examen de l’accès en production après votre questionnaire, et l’examen de la version elle-même. Google indique que l’examen de l’accès prend habituellement sept jours ou moins, mais qu’il peut durer plus longtemps, et que l’examen de l’application peut lui aussi dépasser sept jours dans des cas exceptionnels. Aucun des deux n’est plafonné à une semaine. Délais d’examen et de publication Les chiffres étape par étape : le guide des délais d’examen.

Ce qui bloque réellement quoi

L’essentiel peut être traité dans n’importe quel ordre. Quatre éléments font exception, et savoir lesquels fait la différence entre un lancement en trois semaines et un lancement en six.

Une estimation de planification, clairement annoncée comme telle

De trois à cinq semaines, voire davantage : c’est un plan raisonnable pour un nouveau compte personnel. Il s’agit de notre estimation de planification, pas d’un engagement de service de Google, et elle suppose une application déjà largement développée, des testeurs qui s’inscrivent rapidement et aucune reprise majeure. Le développement de l’application n’entre pas dans ce chiffre, et un cycle de reprises vient s’y ajouter.

Ce que Play Console vous dit, et où le corriger

Presque tous les blocages se présentent sous la forme de l’un de ces six messages. Identifiez celui qui vous concerne au lieu de renvoyer votre demande en espérant.

Votre liste de contrôle adaptée à votre étape

Indiquez le compte dont vous disposez et l’objectif que vous visez. L’outil distingue trois choses que les listes habituelles mélangent : ce dont vous avez besoin maintenant, ce qui sera exigé plus tard et ce qui ne vous concerne pas du tout. C’est un suivi pour votre usage personnel : il ne voit pas votre Play Console, et le terminer ne vaut pas approbation.

Échéances actuelles et changements de règles conditionnels

Voici les éléments datés qui peuvent changer ce que vous développez ou le moment où vous publiez. La plupart ne concerneront pas votre application : lisez la troisième colonne avant d’agir sur l’un d’eux.

Exigences permanentes, sans échéance associée

En vigueur dès maintenant, et absentes de toute liste des « nouveautés » : c’est pourquoi elles piègent les personnes qui ont appris cette procédure il y a un an ou deux.

• Test fermé : 12 testeurs, 14 jours sans interruption, pour les comptes personnels créés après le 13 novembre 2023. Le seuil est passé de 20 à 12 testeurs le 11 décembre 2024.
• Les transferts de propriété d’un compte passent par la procédure de transfert de Play Console. Le transfert direct du titulaire couvre les organisations et les comptes personnels qui ne monétisent pas ; un compte personnel qui monétise emprunte une autre voie, avec un nouveau compte et un transfert d’applications. Acheter, louer ou vendre des comptes par l’intermédiaire de tiers est interdit. Transférer la propriété
• Le compte d’organisation est obligatoire pour certaines applications de services financiers, les applications de santé, les applications VpnService approuvées et les applications gouvernementales.
• Les autorisations photos et vidéos sont déjà appliquées. Un accès étendu uniquement là où une fonctionnalité centrale l’exige ; sinon, le sélecteur de photos du système.

PolicyBytes : mises à jour des règles d’avril 2026

L’équipe Developer Experience de Google revient sur les règles relatives aux contacts et au transfert de compte, ainsi que sur les mises à jour concernant la localisation et les contenus soumis à une limite d’âge évoquées plus haut. Facultatif ; le tableau en donne la version directement exploitable.

YouTube

Comment PrimeTestLab vous aide sur le test fermé

Sept des huit étapes relèvent de la paperasse et d’un travail technique que vous maîtrisez. Une seule demande 12 personnes réelles, sur de vrais appareils Android, inscrites et réellement actives pendant 14 jours sans interruption : c’est l’étape sur laquelle les développeurs solo se bloquent, et la seule que nous prenons en charge.

Vous partagez le lien d’activation de votre test fermé. Nous nous occupons des invitations, de la confirmation des inscriptions, du suivi quotidien de l’activité et du maintien sur les 14 jours complets, en remplaçant toute personne qui abandonne. Quelle que soit la langue de l’application, avec un ciblage par pays souple.

Nos formules actuelles

Garantie de remboursement · Le test démarre généralement sous de 4 à 6 heures · Sans abonnement

Questions fréquentes

Que faire ensuite

D’où vient chaque exigence

Chaque affirmation qui porte à conséquence renvoie à sa source à l’endroit où elle est faite ; voici la version répertoire. Les pages d’aide de Google sont pour l’essentiel non datées : la date de modification d’une page ne prouve donc pas à quel moment une règle est entrée en vigueur.

Ce qui a changé dans cette révision

11 septembre 2026

Reconstruit à partir de la documentation de Google consultée le 8 septembre, puis révisé de nouveau après un ré-audit de cette reconstruction. Corrigé : l’exigence de niveau d’API cible, désormais présentée par type d’appareil ; l’ordre des prérequis du test fermé ; la conversion d’un compte personnel en compte d’organisation ; les délais du numéro D-U-N-S ; la portée de l’échéance d’enregistrement du 30 septembre 2026 et la voie qui y mène, à savoir un contrôle d’état dans Play Console une fois l’application créée ; les contacts et la localisation au 27 janvier 2027 pour l’API 37 et plus, l’implémentation et la déclaration étant cumulatives ; les spécifications de l’icône, des captures et de la vidéo de présentation ; l’accès pour l’examen, compris comme cinq jeux d’instructions ; l’ID d’application, propriété du build et non de la fiche dans Play Console ; et la mécanique de publication, où un bundle déjà testé et éligible peut être réutilisé et où une approbation ne vaut pas publication lorsque la publication gérée s’applique. Ajouté : la vérification de l’appareil, les étapes de création de l’application et de publication, les contrôles préalables du code natif et de Play Billing, les déclarations IA sur les visuels de la fiche, les déclarations Applications de santé et Fonctionnalités financières (obligatoires même en l’absence de telles fonctionnalités), un tableau des blocages, et une source à côté de chaque affirmation qui porte à conséquence. Supprimé faute de source : la date de migration des comptes de santé du 28 janvier 2026, le mythe des « cinq jours » de vérification d’identité, l’explication d’avril 2025 sur l’identifiant Android, le plafond de 1 Mo de l’image de présentation et le classement « refus le plus évitable ». La liste de contrôle de préparation a été reconstruite deux fois : elle distingue désormais « exigé plus tard » de « ne s’applique pas », et ne considère plus un travail envoyé comme terminé.

24 juin 2026

Première publication.