Vérification des développeurs Android 2026: dates et étapes

Presque tout ce qui a été écrit sur la vérification des développeurs Android en 2025 est aujourd’hui faux sur au moins un point important, et une bonne partie de ce qui a été écrit début 2026 l’est aussi. La conception du programme a changé après l’annonce initiale, la date d’application exacte n’est tombée qu’en juin 2026, et la portée a été réduite noir sur blanc le 22 juillet 2026. Or la question que les développeurs tapent réellement dans la recherche n’est pas "qu’est-ce que la vérification des développeurs?" C’est: Google me dit que j’ai échoué, qu’est-ce qui cloche exactement, que se passe-t-il maintenant, et est-ce que je ne l’avais pas déjà fait?

Cet article est donc écrit comme une réponse à incident plutôt que comme un commentaire de politique. Il répond d’abord à la question "est-ce que c’est déjà fait?", donne la navigation exacte dans Play Console au lieu de conseils vagues, sépare les deux couches d’application que toutes les autres pages fusionnent en une seule phrase inquiétante, et dit explicitement là où Google n’a rien publié. Il trace aussi une ligne nette entre la vérification et la règle distincte des 12 testeurs en test fermé, parce que cette confusion arrive presque chaque semaine dans la boîte de réception de PrimeTestLab. Chaque date et chaque chiffre ci-dessous ont été confrontés aux pages de Google le 9 août 2026.

La vérification des développeurs Android, c’est deux tâches et non une

Si vous publiez sur Google Play, la vérification des développeurs Android vous demande deux choses distinctes: vérifier votre identité, et enregistrer les noms de package de vos applications. La plupart des développeurs Play existants ont déjà satisfait la première et, dans la très grande majorité des cas, la seconde s’est faite automatiquement. Pour beaucoup de comptes, il ne reste qu’à contrôler deux écrans, même si Google ne publie aucun délai universel et qu’un problème de document ou de compte peut prendre nettement plus de temps.

Ce que chaque porte établit réellement

Les deux tâches répondent à deux questions différentes, et réussir l’une n’apprend rien à Google sur l’autre. Les garder séparées est la chose la plus utile que cette page puisse vous faire faire, parce que les modes d’échec, les correctifs et jusqu’aux écrans de Play Console sont différents.

Un compte peut donc être entièrement vérifié côté identité et garder malgré tout un package non enregistré, assis tranquillement dans la liste. C’est exactement cette combinaison qui tourne mal un jour de date limite, parce que le développeur a regardé l’écran qui affiche "vérifié" et n’a jamais ouvert celui qui liste les applications.

La réponse en une minute pour un développeur Play Console existant

Si vous publiez déjà sur Google Play, voici tout le parcours de conformité dans l’ordre où il doit être contrôlé. La plupart des lecteurs s’arrêtent à l’étape deux.

1. 01

   Confirmez votre statut d’identité

   Ouvrez Compte de développeur dans Play Console. Le guide de vérification de Google décrit ce chemin comme Paramètres › Compte de développeur, tandis que sa documentation plus récente sur la gestion de compte passe par Compte de développeur › À propos de vous. Dans les deux cas, Google indique que si vous avez déjà réussi la vérification d’identité, vous n’aurez pas à repasser cette étape. Vérifié

2. 02

   Confirmez que chaque package est enregistré

   Ouvrez la page Vérification des développeurs Android dans Play Console et regardez l’état d’enregistrement de chaque application. L’accueil de Play Console peut aussi faire remonter les informations d’enregistrement des applications. Si tous vos noms de package ont été enregistrés automatiquement, Google indique qu’aucune action d’enregistrement supplémentaire n’est requise pour ces applications. Vérifié

3. 03

   Revendiquez le reste avant le 30 septembre

   Pour un package qui n’a pas été enregistré automatiquement, suivez l’enregistrement manuel de Google. Sa forme dépend du nom de package: un nom qu’Android n’a jamais vu ne demande que les données du package et votre certificat public de signature, tandis qu’un nom qui a déjà des installations demande un APK de preuve signé démontrant que vous détenez la clé privée. Les deux parcours sont en section 05.

Si vous publiez sur Google Play, utilisez Play Console

C’est le piège qui envoie les développeurs faire un détour d’une heure. Il y a deux consoles dans ce programme. Play Console est l’endroit où les développeurs Google Play accomplissent les deux tâches. L’Android Developer Console est une surface distincte, pour les développeurs qui distribuent en dehors de Google Play, et ses pages d’aide décrivent un parcours différent, avec notamment la vérification du site web de l’organisation via Google Search Console. Les deux jeux d’instructions se positionnent sur les mêmes recherches.

Quatre routes de distribution, quatre réponses. Trouvez votre ligne avant de lire un mot de plus de la documentation de Google, parce que la mauvaise ligne vous coûte un après-midi:

Correspondance des routes issue du guide de vérification Play Console et du guide de distribution limitée de Google, consultés le 13 août 2026. Vérifié

La chronologie 2026 de la vérification, et la date que les articles continuent de rater

La vérification n’est pas arrivée en une annonce. Elle est arrivée en cinq, chacune resserrant ou corrigeant la précédente. La chronologie ci-dessous prend les documents Google de juin et juillet 2026 comme source de référence, ce qui compte parce que la prévision de mars, très citée, a été remplacée.

Comment le programme est réellement arrivé, étape par étape

Chaque entrée associe ce que Google a publié et ce qu’un développeur Play doit en retenir, parce que plusieurs de ces dates sont citées isolément ailleurs et se lisent très différemment une fois la séquence visible.

1. novembre 2025

   Ouverture de l’accès anticipé

   Les développeurs invités à l’accès anticipé pouvaient commencer à vérifier des applications distribuées en dehors de Google Play.

   Ce qu’il faut en déduire: jalon historique uniquement. Rien ici ne crée d’obligation pour un développeur Play aujourd’hui.

2. 30 mars 2026

   Le déploiement vers tous les développeurs commence

   Google a annoncé qu’il commençait à déployer la vérification des développeurs Android auprès de tous les développeurs, dans Play Console comme dans l’Android Developer Console, et a dit aux développeurs Play de guetter cet accès dans les semaines suivantes. Vérifié

   Ce qu’il faut en déduire: ne lisez pas cela comme "tous les comptes Play ont reçu la vérification le 30 mars". La formulation de Google est que le déploiement a commencé ce jour-là.

3. juin 2026

   Le service système Android Developer Verifier est déployé

   La chronologie mise à jour de Google place le déploiement du service système de vérification en juin 2026. Vérifié

   Ce qu’il faut en déduire: retenez juin. Le billet du 30 mars avait annoncé avril, et plusieurs articles tiers actuels répètent encore cette prévision comme si c’était de l’histoire.

4. 18 juin 2026

   La date d’application exacte tombe

   Google a annoncé le 30 septembre 2026 comme première date d’application, a nommé les sept boutiques participantes et a indiqué que plus de 99% des applications des développeurs Play étaient déjà enregistrées. Vérifié

   Ce qu’il faut en déduire: c’est la source unique la plus solide, à la fois pour la date et pour le chiffre d’enregistrement automatique. Tout ce qui a été publié avant devine la date.

5. juillet 2026

   L’outillage: l’API ID Status et l’API Console

   L’Android Developer ID Status API a été déployée mondialement, avec l’API Console et la distribution limitée en accès anticipé.

   Ce qu’il faut en déduire: pertinent pour les équipes d’automatisation et d’outillage, pas pour un premier éditeur qui avance à la main dans Play Console.

6. 15 juillet 2026

   Les guides actuels sont publiés

   Le guide de vérification général de Google et son guide Play Console ont été mis à jour, avec notamment la portée initiale par boutique et les instructions d’enregistrement des packages Play. Vérifié

   Ce qu’il faut en déduire: traitez ces deux pages comme la documentation de référence actuelle pour tout ce qui est opérationnel.

7. 22 juillet 2026

   La FAQ resserre la portée noir sur blanc

   La FAQ de Google a précisé que les boutiques hors de la liste participante et l’installation directe d’APK ne sont pas concernées par la phase du 30 septembre. Vérifié

   Ce qu’il faut en déduire: c’est la phrase qui enterre le récit de 2025, "Google met fin au sideloading à cette date". C’est une limite de première phase, pas une exemption permanente.

8. août 2026

   Prévu pour une disponibilité mondiale: distribution limitée et parcours avancé

   La page de vérification de Google présente les comptes de distribution limitée, l’API Android Developer Console et le parcours d’installation avancé comme des lancements d’août 2026. Au 13 août 2026, son guide dédié à la distribution limitée indique toujours que les inscriptions à l’accès anticipé sont fermées et que davantage d’informations arriveront en août 2026: cette ligne est donc dessinée comme prévue et non livrée. Partiel, lancement non confirmé

   Ce qu’il faut en déduire: c’est l’élément qui bouge le plus vite sur cette page, et le fait que le calendrier soit passé en août ne prouve pas la livraison. Consultez la page de vérification de Google pour l’état actuel plutôt que de faire confiance à un article publié en milieu de mois, celui-ci compris.

9. 30 septembre 2026

   Deux choses arrivent le même jour

   L’enregistrement des applications devient obligatoire pour les installations via les sept boutiques participantes au Brésil, en Indonésie, à Singapour et en Thaïlande. Séparément, au titre des exigences Play Console, tous les packages Play doivent être enregistrés, et Google indique que les applications non enregistrées seront retirées de Google Play. Vérifié

   Ce qu’il faut en déduire: une date, deux conséquences indépendantes. La section 03 les sépare correctement.

10. 2027 et au-delà

    Extension mondiale, date non annoncée

    Google annonce une extension mondiale des protections en 2027. Au 9 août 2026, aucune date mondiale précise et aucun calendrier de pays supplémentaire n’ont été publiés. Vérifié

    Ce qu’il faut en déduire: traitez tout "1er janvier 2027" ou "début 2027" lu ailleurs comme une prédiction. Google n’en a publié aucune.

Le 30 septembre 2026 est-il une date limite mondiale?

Non pour l’application au niveau de l’appareil Android, et oui pour la date limite d’enregistrement des packages Google Play. Ce sont deux règles différentes qui partagent une date, et presque tous les articles sur ce programme les fusionnent. La règle appareil démarre dans quatre pays via sept boutiques. La règle Play s’applique à votre fiche Play, et Google décrit la conséquence d’un manquement comme un retrait mondial de Google Play.

Les quatre pays et les sept boutiques

Google nomme les deux listes avec précision: il n’y a donc aucune interprétation à faire. La première phase d’application couvre les installations d’applications dans ces quatre pays:

Et elle s’applique aux installations via ces sept boutiques d’applications participantes:

Les deux listes sont reprises de l’annonce Google du 18 juin 2026 et de son guide de vérification du 15 juillet 2026, consultés le 9 août 2026. Google peut ajouter des boutiques ou des régions: revérifiez la source avant d’agir sur cette liste à l’approche de la date.

Le 30 septembre vous concerne-t-il? Résolvez votre propre canal

Répondez à deux questions et l’outil ci-dessous applique les deux couches à votre canal de distribution précis. Il est volontairement direct sur les cas où la réponse de Google est "pas encore", parce que "pas encore" n’est pas "jamais".

Comment savoir si vous êtes déjà vérifié

Deux écrans répondent à toute la question. Compte de développeur porte votre identité et les informations du compte. La page Vérification des développeurs Android porte l’état d’enregistrement de chaque application. Si vous n’ouvrez jamais que le premier, vous pouvez réussir un audit que vous n’avez pas réellement passé.

Les quatre endroits où un statut peut apparaître

Du statut à l’action, sans inventer de libellés

Google publie où regarder et quoi faire. Il ne publie pas de glossaire exhaustif des libellés de statut d’identité Play: cet article n’en invente donc pas. Le tableau ci-dessous est organisé par ce que vous contrôlez et à quoi ressemble le "fait", ce qui est précisément la partie que Google documente.

Navigation et définitions du "fait" issues de l’aide Play Console réponse 16984799, du guide de vérification Play Console de Google et de la page d’aide sur les informations du compte de développeur; la ligne test fermé vient de l’aide Play Console réponse 14151465. Toutes consultées le 9 août 2026. Les pages de Google utilisent aujourd’hui deux formulations différentes pour le chemin d’identité, la navigation de Play Console change souvent, et les libellés sont donnés ici en français alors que votre Console peut afficher un intitulé légèrement différent: traitez donc chaque chemin comme valable à cette date plutôt que comme permanent.

Ce que "enregistré automatiquement" veut dire exactement

L’enregistrement automatique porte sur une seule relation, très étroite: le lien entre le nom de package d’une application et les éléments de signature qui prouvent qui la contrôle. Google indique que les applications éligibles qui utilisent Play App Signing font partie du processus d’enregistrement automatique, parce que Google détient déjà les informations de propriété et de signature dont il a besoin.

Si tous vos noms de package ont été enregistrés automatiquement avec succès, Google indique qu’aucune action d’enregistrement supplémentaire n’est requise pour les applications Play correspondantes. Cette phrase fait exactement le travail qu’elle annonce, et pas un gramme de plus.

Ce dernier point mérite qu’on s’y arrête. L’enregistrement se fait par package: un compte avec six applications peut donc être fait aux quatre sixièmes et n’afficher rien d’alarmant nulle part, sauf sur la seule page qui les liste. Google présente par ailleurs la vérification comme une confirmation de l’identité du développeur, et la décrit comme distincte du filtrage de sécurité appliqué au contenu des applications: rien ici ne dit donc si votre application est conforme aux règles de Play.

Que faire quand une application n’a pas été enregistrée automatiquement

L’enregistrement manuel prend deux formes, et celle qui vous concerne dépend du nom de package, pas de vous. Pour un nom de package qu’Android n’a jamais vu, vous fournissez les données du package et le certificat public de votre clé de signature. Pour un nom de package qui porte déjà des installations, vous prouvez en plus que vous détenez la clé privée correspondante, en important un APK contenant un extrait fourni par Google. Seul le second cas demande un APK de preuve signé, et aucun des deux ne demande votre vrai APK de production.

D’abord, déterminez votre cas

Cinq lignes, et aujourd’hui vous appartenez à exactement l’une d’elles. Se tromper ici est l’erreur la plus coûteuse de cette section, parce que la route de l’APK de preuve est un travail de compilation et que trois de ces lignes n’en ont pas besoin du tout.

Distinction des cas issue de l’aide Play Console, "Registering Android package names" (réponse 16761053), consultée le 13 août 2026. Vérifié

A. Enregistrer un nouveau nom de package

Le parcours court. Tout se passe dans Play Console, rien ne touche votre environnement de compilation, et il n’y a aucun APK à produire.

1. 01

   Ouvrez la page Vérification des développeurs Android

   Dans Play Console, ouvrez la page Vérification des développeurs Android et passez en revue l’état d’enregistrement de chaque nom de package du compte. L’accueil de Play Console peut aussi faire remonter les informations d’enregistrement des applications.

2. 02

   Choisissez Enregistrer un nom de package

   Cela démarre un enregistrement neuf plutôt qu’une revendication sur un nom déjà existant.

3. 03

   Saisissez le nom de package et un nom convivial

   Le nom convivial est une étiquette interne pour votre propre liste. Ce n’est pas ce que les utilisateurs voient sur votre fiche Store.

4. 04

   Choisissez Ajouter une clé

   C’est le début de l’association entre une clé de signature que vous contrôlez et le nom de package que vous enregistrez.

5. 05

   Fournissez le certificat public de signature

   Donnez le certificat public issu de la paire de clés de signature de votre application. Comme Android n’a jamais vu ce nom de package, ce certificat suffit à Google. Votre clé privée ne quitte jamais votre machine.

6. 06

   Validez et attendez la confirmation

   Google envoie un e-mail une fois le nom de package enregistré avec succès, et le statut mis à jour devient visible dans Play Console.

B. Enregistrer un nom de package existant

C’est le parcours le plus long, et celui que tous les articles décrivent comme s’il était le seul. Il s’applique quand le nom de package a déjà des installations sur Android, parce qu’alors Google ne vous croit pas sur parole: vous devez démontrer le contrôle de la clé privée. Deux de ces étapes se passent en dehors de Play Console, ouvrez donc votre environnement de compilation avant de commencer.

1. 01

   Saisissez les données du package

   Sur la page Vérification des développeurs Android, lancez l’enregistrement du nom de package que vous revendiquez.

2. 02

   Ouvrez Sélectionner une clé

   Google propose les certificats qu’il considère comme éligibles pour ce nom de package, sur la base des preuves d’installation.

3. 03

   Choisissez une empreinte de certificat public éligible

   Prenez l’empreinte de la clé que vous détenez réellement. Si rien d’éligible n’est proposé, arrêtez-vous ici et lisez les règles d’éligibilité plus bas avant d’essayer autre chose.

4. 04

   Lancez le parcours de propriété et copiez l’extrait de Google

   Google génère un extrait unique pour cette revendication. Copiez-le exactement. C’est la valeur qui prouve que l’APK que vous allez construire a été fait pour ce défi précis.

5. 05

   Créez assets/adi-registration.properties

   Dans le dossier assets d’un projet APK, créez un fichier nommé exactement adi-registration.properties. Le chemin et le nom du fichier sont tous deux littéraux. Une faute de frappe ici est la façon la plus courante de faire échouer cette étape.

6. 06

   Collez l’extrait dans ce fichier

   Rien d’autre n’a besoin d’y figurer. Ce fichier existe uniquement pour porter la chaîne.

7. 07

   Construisez un APK de version

   Google précise que vous pouvez le construire à partir de l’application réelle ou d’un projet vide utilisant le même nom de package. Le projet vide est en général plus rapide et plus sûr, parce que rien de votre code de production n’est impliqué.

8. 08

   Signez-le avec la clé privée correspondante

   C’est tout l’objet de l’exercice. C’est la signature qui fait preuve, pas le contenu.

9. 09

   Importez-le via Play Console

   Importez l’APK de preuve signé dans le parcours de propriété. Ce n’est pas une publication, cela n’atteint aucun utilisateur, et votre artefact de production reste en dehors.

10. 10

    Surveillez le statut et l’e-mail de confirmation

    Google envoie un e-mail une fois le nom de package enregistré avec succès, et le statut mis à jour devient visible dans Play Console.

C. Si votre clé de signature est détenue par un autre store

Certains stores signent à la place du développeur, et vous ne pouvez alors pas produire vous-même un APK de preuve correctement signé. Google documente un parcours dédié pour ce cas, et il est court:

1. 01

   Construisez la version et importez-la dans ce store

   Faites passer le build portant l’extrait par le processus de publication normal de la plateforme tierce.

2. 02

   Téléchargez l’APK final signé depuis ce store

   Il vous faut l’artefact tel que le store l’a signé, pas celui que vous avez importé.

3. 03

   Importez cet APK signé par le store dans Play Console

   C’est la signature du store qui satisfait le contrôle de propriété.

Étapes du déroulé issues de l’aide Play Console, "Registering Android package names" (réponse 16761053), consultée le 13 août 2026. Vérifié

Ajouter d’autres clés plus tard

Un nom de package peut être associé à plusieurs clés de signature. Google indique que la console permet d’ajouter et de vérifier plusieurs clés de signature pour un même package, et la procédure reprend le parcours B: créer assets/adi-registration.properties avec l’extrait correspondant à cette clé, construire et signer un APK de version avec la clé privée correspondante, puis l’importer. Enregistrez d’abord le nom de package, ajoutez ensuite les clés supplémentaires.

Si aucune clé éligible n’est proposée: les règles de priorité

La plupart des développeurs ne voient jamais cela. Cela compte quand un nom de package a été signé par plusieurs clés au cours de sa vie, ou quand plusieurs parties ont une revendication plausible dessus. Google tranche avec une hiérarchie fondée sur les installations.

Hiérarchie d’éligibilité issue de l’aide Play Console réponse 16761053, consultée le 13 août 2026. Vérifié

En pratique, formulé avec soin: si votre clé de signature satisfait clairement la hiérarchie ci-dessus, elle devrait apparaître comme directement éligible pour la revendication. Cela décide si Google vous laisse enregistrer directement plutôt que de passer par une demande examinée. Cela ne réalise pas l’enregistrement à votre place. Un package laissé de côté par l’enregistrement automatique doit quand même passer par le parcours B, à la main. Le palier premier arrivé premier servi est celui sur lequel il faut avancer vite, parce qu’il se décide sur qui agit et non sur qui a raison.

Ce qu’un compte de développeur personnel doit fournir

Deux couches: des informations universelles, et des documents propres à chaque pays. La partie universelle, c’est que votre identité légale et votre adresse doivent correspondre exactement au profil de paiement Google lié au compte. La partie documentaire dépend entièrement du pays ou de la région de ce profil, et c’est pourquoi aucun article honnête ne peut vous tendre une liste mondiale unique.

La partie identique partout

Les comptes personnels fournissent des informations d’identité légale et de compte, et l’aide Play actuelle cite parmi elles le nom légal et l’adresse légale. Le processus de vérification s’appuie sur le profil de paiement Google lié, et la page de Google sur les exigences documentaires indique que les données d’identité personnelle, le nom de l’organisation le cas échéant et les informations d’adresse doivent correspondre exactement aux informations de votre profil de paiement.

Ce mot "exactement" porte toute cette section, et c’est la raison d’être de l’outil qui suit.

La partie qui n’est pas la même partout

La page de Google dit que les documents acceptés dépendent de votre localisation géographique. Le sélecteur de pays de cette page fait autorité pour votre cas, pas une liste reproduite ailleurs. Pour donner une idée concrète de la forme de l’exigence sans prétendre qu’elle est universelle, voici ce que la page États-Unis de Google demande actuellement aux particuliers:

Les exigences d’image que Google énonce noir sur blanc

Elles portent sur la pièce d’identité avec photo elle-même et elles sont sans ambiguïté, ce qui en fait les causes d’échec les moins chères à éliminer avant tout envoi:

• La pièce d’identité officielle avec photo doit être valide et non expirée.
• L’image doit être en couleur.
• L’image doit être nette et bien éclairée.
• L’image ne doit pas être une photocopie.

Google indique également que sa page actuelle sur les exigences documentaires désigne les documents non acceptés comme la première cause d’échec de la vérification des développeurs, et que des documents falsifiés ou modifiés peuvent entraîner des sanctions lourdes, jusqu’à la suppression du compte et des applications. Rien sur cette page ne vaut de prendre ce risque.

Le contrôle à faire avant d’envoyer quoi que ce soit

Google ne publie pas le nombre de tentatives de vérification auxquelles vous avez droit, et des développeurs signalent régulièrement arriver à un état où le bouton de nouvelle tentative n’est tout simplement plus visible. Cette combinaison rend un envoi négligent réellement coûteux. Faites d’abord cet audit.

L’erreur à contrôler avant tout envoi

Si vous ne retenez qu’une seule instruction de cet article, prenez celle-ci: ouvrez votre profil de paiement Google et comparez le nom légal et l’adresse à vos documents, champ par champ, avant de toucher au bouton d’envoi. Google exige que les informations correspondent; il ne publie pas de règle au caractère ou à la ponctuation près, alors traitez le "champ par champ" comme la façon pratique de satisfaire l’exigence plutôt que comme une règle en soi.

La première moitié de cette phrase est l’exigence énoncée par Google. La seconde, c’est ce dont les forums d’assistance de 2026 sont pleins. Les fils d’avril, juin, juillet et août 2026 suivent tous la même forme: un développeur est certain que ses documents sont corrects, la vérification échoue sans motif précis, et la réponse de la communauté renvoie à un écart entre l’identité soumise et le profil de paiement. Dans plusieurs de ces fils, le développeur n’a découvert le problème de nom sur le profil qu’après un recours infructueux.

Ce dont les comptes d’organisation ont besoin

Les organisations se vérifient avec des informations légales d’entreprise plutôt qu’avec une identité personnelle, et il leur faut généralement un numéro D-U-N-S: un identifiant unique à neuf chiffres délivré par Dun and Bradstreet. La documentation Play de Google prévoit des exceptions pour certaines entités publiques. Google indique que les développeurs qui n’en ont pas peuvent l’obtenir gratuitement, mais prévient que cela peut prendre des semaines, ce qui en fait le seul élément de cette page avec un vrai délai d’obtention. Les pages de Google se contredisent sur la durée: sa FAQ de vérification Android dit jusqu’à 28 jours et l’aide actuelle du compte Play Console dit jusqu’à 30. Cet article planifie sur 30.

Ce qu’une organisation prépare par ailleurs

• Les informations légales de l’organisation conformes à vos documents d’immatriculation, plus le représentant autorisé et les informations du compte.
• Le numéro D-U-N-S à neuf chiffres, gratuit auprès de Dun and Bradstreet, et soumis aux exceptions énoncées par Google pour certaines organisations publiques. Ces exceptions sont étroites: elles ne veulent pas dire que les organisations publiques échappent à la vérification.
• Les documents pertinents de l’organisation et les documents d’identité du représentant, selon les mêmes règles de spécificité par pays et de correspondance exacte que pour les comptes personnels.
• Un site web vérifié, si vous êtes une organisation en distribution complète en dehors de Google Play. Le guide de vérification de Google indique que les organisations fournissent un site web qui doit être vérifié via Google Search Console. Cette étape appartient au parcours Android Developer Console, pas à Play Console.

Une chose qu’un compte d’organisation ne change pas: si vous publiez aussi sur Google Play, cela reste du travail dans Play Console. Et si vous hésitez entre personnel et organisation pour un nouveau compte, les arbitrages vont bien au-delà de la vérification, une décision que la comparaison entre compte personnel et compte d’organisation traite comme il faut.

Ce qui se passe réellement si vous n’êtes pas vérifié au 30 septembre

Quatre choses différentes, selon la façon dont votre application atteint ses utilisateurs. Google documente des restrictions sur la nouvelle installation, sur les mises à jour là où les contrôles s’appliquent, et le retrait de Google Play pour les packages Play non enregistrés. Il ne documente pas la désinstallation forcée d’applications déjà présentes sur les téléphones.

Conséquences issues de l’aide Play Console réponse 16984799, du guide de vérification Play Console de Google, du billet de déploiement du 30 mars, de la chronologie de l’aide Android Developer Console et de la FAQ du 22 juillet. Toutes consultées le 9 août 2026.

L’affirmation à manier avec le plus de prudence

Cette distinction n’est pas du pinaillage. Elle change ce que vous devez faire ce mois-ci. Un retrait de Play est une urgence de distribution que l’on règle en enregistrant un package. Une hypothétique désinstallation de masse serait une urgence de relation client demandant une communication complètement différente. Une seule des deux est documentée.

Comment le parcours avancé fonctionne vraiment

Google documente le parcours avancé comme un chemin volontairement lent, pas comme un interrupteur, et la friction est le but: chaque étape existe pour empêcher qu’on vous la dicte au téléphone alors que l’appel est encore en cours.

1. 01

   Activez le mode développeur dans les paramètres système

   Un premier geste délibéré, pour que rien ici ne se déclenche par accident ni par un contournement en un seul appui comme dans les arnaques.

2. 02

   Confirmez que personne ne vous guide

   Une vérification rapide que personne ne fait pression sur vous pour désactiver une protection.

3. 03

   Redémarrez le téléphone et réauthentifiez-vous

   Cela coupe l’accès à distance ou un appel en cours dont quelqu’un pourrait se servir pour observer la suite.

4. 04

   Revenez après le délai de protection

   Google le décrit comme une attente d’un jour, une seule fois. Vous confirmez ensuite par authentification biométrique ou par le code de l’appareil.

5. 05

   Installez depuis des développeurs non vérifiés

   Vous pouvez l’autoriser sept jours ou indéfiniment. Un avertissement continue de s’afficher à chaque installation et c’est vous qui le validez.

Étapes du parcours avancé issues de la FAQ de vérification des développeurs Android de Google, consultée le 13 août 2026. Vérifié

La question du sideloading, en un paragraphe

La phase du 30 septembre ne s’applique pas encore à l’installation directe d’APK ni aux boutiques d’applications hors de la liste participante de Google, et Google continue de prendre en charge l’installation par ADB ainsi qu’un flux avancé pour les utilisateurs qui choisissent sciemment d’installer depuis des développeurs non vérifiés. C’est la position actuelle et documentée au 9 août 2026, et elle est très différente du récit "Google met fin au sideloading" qui a circulé après l’annonce initiale de 2025. C’est aussi explicitement une première phase: y voir un résultat définitif serait l’erreur symétrique. Si ce sont les implications pour le sideloading et l’écosystème ouvert qui vous ont amené ici plutôt qu’une date limite Play, cela mérite un traitement à part et non un paragraphe au milieu d’un article de conformité.

La vérification ne remplace pas le test fermé de 12 testeurs

Ce sont deux exigences sans rapport, qui doivent toutes les deux être satisfaites quand elles vous concernent toutes les deux. La vérification des développeurs Android répond à "qui possède ce compte et ce package?" La règle d’accès en production répond à "cette application a-t-elle été testée par de vraies personnes?" Vous pouvez réussir l’une parfaitement et rester complètement bloqué par l’autre.

L’exigence de Google pour les nouveaux comptes de développeur personnels concernés n’est modifiée en rien par le programme de vérification: au moins 12 testeurs inscrits sans interruption à un test fermé pendant les 14 jours précédents au moment où vous demandez l’accès en production.

Colonnes vérification issues du guide de vérification de Google et de l’aide Play Console réponse 16984799; colonnes test fermé issues de l’aide Play Console réponse 14151465 et de la page d’aide sur le test interne. Toutes consultées le 9 août 2026. Vérifié

Pourquoi cela prend les gens au piège

Parce que les deux s’appellent des "exigences", que les deux vivent dans Play Console, et que les deux se dressent entre un développeur et une application publiée. Un compte qui vient de passer la vérification d’identité se sent donc arrivé. Puis l’accès en production est refusé, et rien dans les écrans de vérification n’explique pourquoi, parce que ce n’est pas là que se trouve la réponse.

La séquence qui met réellement un nouveau compte personnel en ligne est: identité vérifiée, chaque package enregistré, et séparément un test fermé avec au moins 12 testeurs inscrits sans interruption pendant 14 jours avant la demande d’accès en production. La règle des 14 jours consécutifs comporte plus de cas particuliers que la plupart des développeurs ne l’imaginent, et c’est la partie de cette séquence qu’on ne peut pas comprimer en travaillant plus dur.

Le test interne compte-t-il à la place?

Non, et il vaut la peine d’être précis sur le pourquoi, parce que "le test interne ne sert à rien" est faux aussi. Google autorise le test interne avec jusqu’à 100 testeurs, et c’est un très bon moyen de détecter des problèmes rapidement. Mais l’exigence d’accès en production nomme précisément un test fermé remplissant la condition des 12 testeurs pendant 14 jours. Le test interne est un canal distinct: y participer n’est donc pas le test qualifiant pour cette exigence précise.

Les comptes d’organisation méritent une phrase de clarification ici aussi: l’exigence de test pour l’accès en production est expressément écrite pour les nouveaux comptes de développeur personnels, donc les comptes d’organisation ne sont pas la classe de comptes couverte par cette règle précise des 12 testeurs. C’est une question distincte de la vérification, qui touche elle les deux types de compte.

Si la vérification a échoué, contrôlez ceci avant de réessayer

Les développeurs signalent fréquemment des messages de refus non spécifiques, et Google ne documente pas la cause de chaque refus individuel. La bonne démarche n’est donc pas de deviner le message mais de reprendre les exigences que Google publie réellement. Choisissez ci-dessous le symptôme que vous constatez. Chacun mène au premier point à contrôler, à la solidité de la preuve derrière ce conseil, et à l’action sûre qui suit.

Partez du symptôme que vous voyez réellement

Les dix entrées ci-dessous sont formulées comme les développeurs les formulent sur les forums d’assistance de Google, y compris celles écrites à deux heures du matin. En sélectionner une vous donne le contrôle le plus utile pour ce symptôme, plutôt qu’une liste de tout ce qui pourrait théoriquement clocher.

Ce que la preuve étaye, et ce qu’elle n’étaye pas

Les schémas d’échec ci-dessous proviennent des fils de la communauté d’aide aux développeurs Google Play tout au long de 2026, avec notamment des cas du Brésil, d’Inde, d’Ouzbékistan et plusieurs fils en portugais, plus d’anciens signalements sur Reddit et Stack Overflow. Ils sont regroupés selon la solidité réelle de la preuve, parce que cela change ce que vous devez en faire.

La checklist avant la date limite

Cinq états décident si le 30 septembre est une date dans votre agenda ou un problème dans votre boîte de réception. Quatre concernent tous les développeurs Play. Le cinquième ne concerne que les comptes soumis à la règle du test fermé, et c’est celui qui consomme du temps de calendrier réel.

Les quatre points à régler

Cochez honnêtement plutôt qu’avec optimisme. Chaque ligne renvoie à la section qui la résout: une case non cochée est donc un détour de deux minutes, pas une impasse. Deux d’entre eux sont conditionnels: ils sont formulés pour être cochés quand ils ne vous ont jamais concerné. Qui a vu toutes ses applications enregistrées automatiquement n’a aucune revendication manuelle à clore, et qui était déjà vérifié sans aucune demande de document n’a rien à corriger.

Où PrimeTestLab intervient, et où non

Soyons d’abord clairs sur la frontière: personne ne peut vérifier votre identité à votre place. Importer vos documents, faire correspondre votre profil de paiement et revendiquer vos noms de package sont des choses que seul le titulaire du compte peut faire, et cet article est toute notre contribution sur ce terrain. Ce que nous couvrons, c’est l’exigence qui arrive juste après la vérification pour un nouveau compte personnel: les 12 testeurs réels, inscrits pendant 14 jours consécutifs.

C’est le partage qui arrive dans notre boîte de réception toujours sous la même forme. Un développeur passe la vérification d’identité, voit un état vert dans Play Console, en conclut que la voie est ouverte, puis découvre que l’accès en production est une porte complètement séparée avec un plancher de deux semaines accroché dessus. La vérification, c’est de la paperasse, et sa durée dépend de vos documents et de votre compte. Le test fermé, c’est du temps de calendrier que vous ne pouvez pas comprimer.

Mener le test fermé vous-même ou le confier

L’ordre qui coûte le moins de temps

Si la vérification et le test fermé sont tous les deux devant vous, menez-les en parallèle plutôt qu’en séquence. Les 14 jours d’inscription continue des testeurs sont du temps réel qui ne démarre qu’une fois 12 personnes effectivement inscrites: c’est donc l’élément qui décide de votre vraie date de lancement. Lancez ce compteur pendant que vous travaillez les documents, pas après.

Questions fréquentes

Résumé

Dernier contrôle des règles: 13 août 2026. Le déploiement du 30 septembre de Google et son extension 2027 évoluent encore: les dates et la couverture géographique doivent donc être revérifiées sur la page Vérification des développeurs Android de Google avant d’agir. Cet article est programmé pour une nouvelle vérification le 30 septembre 2026 et juste après le début de l’application, puis à chaque fois que Google publiera une géographie ou une date pour 2027.