Réponse rapide
Au 13 août 2026, vos testeurs peuvent toujours installer un APK brut que vous partagez directement avec eux. L’entrée en vigueur du 30 septembre 2026 au Brésil, en Indonésie, à Singapour et en Thaïlande ne s’applique d’abord qu’à sept boutiques d’applications participantes, et la FAQ de Google du 15 juillet indique que les installations directes ne sont pas encore couvertes. Google prévoit une application plus large sur les appareils certifiés sous Android 7 et plus en 2027, sans date précise annoncée. Une fois cette phase active, les applications enregistrées auprès d’un développeur vérifié conservent le parcours d’installation habituel, tandis que les applications non enregistrées restent installables via ADB ou via le parcours avancé de Google. Firebase App Distribution reste utile pour la QA, mais il n’effectue pas la vérification des développeurs Android et il ne vaut pas le test fermé Google Play, qui exige 12 testeurs inscrits pendant 14 jours sans interruption.
Comment cet article note chaque affirmation
- Vérifié signifie que l’affirmation vient directement d’une page Google, Android ou Firebase à jour. La majeure partie de cet article est vérifiée. Vérifié
- Partiel signifie que les sources primaires soutiennent la conclusion mais qu’il faut une étape de déduction, ou que les pages de Google laissent le cas particulier sans réponse. Partiel
- Signalé par la communauté signifie des témoignages répétés de développeurs sur Stack Overflow, Reddit ou les forums de Google. Utile pour le dépannage, pas pour les règles. Communauté
- Non documenté signifie que Google n’a rien publié sur ce cas précis, et nous le disons plutôt que de deviner. Non documenté
Le récit qui s’est répandu en 2025 était simple: Android met fin à l’installation directe. La position que Google documente réellement en août 2026 est plus étroite, plus précise, et bien moins vendeuse comme titre. Google a précisé en juin et en juillet 2026 la portée de la première phase d’application, et le 15 juillet 2026 il a écrit cette restriction en une seule phrase: l’échéance du 30 septembre "ne s’applique qu’aux boutiques participantes concernées". Une grande partie de la couverture de 2025 et du début 2026 encore en circulation a été publiée avant que cette phrase n’existe et décrit un premier déploiement plus large que celui que Google applique réellement.
Cet article est donc organisé autour de la décision que vous devez réellement prendre, et non autour de la polémique. Vous avez douze amis, collègues ou testeurs et un build à installer sur leurs téléphones. Pouvez-vous encore envoyer l’APK par e-mail? Faut-il passer par ADB? Firebase App Distribution fonctionne-t-il? Et la question qui arrive presque chaque semaine dans la boîte de réception de PrimeTestLab: est-ce que tout cela compte pour le test fermé à 12 testeurs que Google exige avant l’accès en production? Chaque date, chaque chiffre et chaque mécanisme ci-dessous a été vérifié sur les pages de Google le 13 août 2026, et là où Google n’a rien publié, cet article signale le vide plutôt que de le combler.
Vos testeurs peuvent-ils encore installer votre APK après le 30 septembre 2026?
Oui. Sous les règles actuelles de Google, un testeur peut toujours installer un APK que vous lui envoyez directement après le 30 septembre 2026. La date est réelle, les quatre pays sont réels et l’application des règles est réelle, mais la FAQ actuelle de Google dit que l’échéance "ne s’applique qu’aux boutiques participantes concernées". Pour une installation directe, la même FAQ dit qu’elle "ne s’appliquera pas encore à votre application".
Les termes exacts de Google, fragment par fragment
L’échéance "ne s’applique qu’aux boutiques participantes concernées" · pour une installation directe, elle "ne s’appliquera pas encore à votre application" · l’application vise les "appareils Android certifiés sous Android 7 ou plus" · Google va "étendre l’exigence de vérification Android au monde entier" en 2027
Fragments cités un par un depuis la FAQ de Google sur la vérification des développeurs Android (mise à jour le 10 août 2026) et l’annonce du 18 juin 2026, toutes deux consultées le 13 août 2026. Les pages sources sont en anglais: la formulation française ci-dessus est notre traduction. Vérifié
Ce que le 30 septembre touche, et ce qu’il ne touche pas
Trois lignes règlent la question pour presque tous les lecteurs. C’est celle du milieu qui diffère de beaucoup d’articles plus anciens sur cette date.
Concerné le 30 septembre 2026
Installer via l’une des sept boutiques participantes au Brésil, en Indonésie, à Singapour ou en ThaïlandeL’application doit être enregistrée auprès d’un développeur vérifié pour que l’installation ordinaire aboutisse. Google précise que la partie hors Play de cette application régionale initiale concerne les formats mobile et tablette.
Pas encore couvert par la première phase
Un APK direct: envoyé par e-mail, téléchargé depuis votre site, partagé sur Drive ou installé via ADBLa FAQ de Google du 15 juillet dit que l’échéance du 30 septembre ne s’applique pas encore à l’installation directe. Les boutiques d’applications absentes de la liste participante sont elles aussi hors de cette première phase. Le mot qui porte tout le sens dans ces deux phrases, c’est encore. Un APK Firebase App Distribution devrait hériter de la même réponse, puisqu’il s’agit d’une distribution directe d’un APK signé, mais Google n’a publié aucune décision propre à Firebase. Partiel, déduction
Inchangé de toute façon
Les règles de publication propres à Google PlayPlay exige séparément que chaque package Play soit enregistré, et le test fermé à 12 testeurs pour les nouveaux comptes personnels concernés n’est touché par rien de tout cela. La vérification ne le raccourcit pas, ne l’annule pas et ne le remplace pas.
Portée tirée de la FAQ de Google sur la vérification des développeurs Android (mise à jour du 10 août 2026) et de l’annonce du 18 juin 2026 qui nomme la date, les quatre pays et les sept boutiques. Exigence de test fermé Play tirée de la réponse 14151465 de l’aide Play Console. Toutes consultées le 13 août 2026.
Pourquoi ce n’est pas une faille
"Pas encore couvert" décrit une phase de déploiement, pas une exemption permanente, et le prendre pour une exemption est l’exacte image inversée de l’erreur que cet article corrige. Google a annoncé que l’exigence s’étend au monde entier en 2027. La bonne réaction à cette section est un soulagement pour septembre et une préparation pour l’année suivante, ce à quoi sert précisément la checklist vers la fin. Vérifié
Ce qui change vraiment le 30 septembre 2026
Google a fixé la date le 18 juin 2026, puis l’a restreinte par écrit le 15 juillet. À partir du 30 septembre, une installation via l’une des sept boutiques nommées dans quatre pays nommés est contrôlée: l’application doit être enregistrée auprès d’un développeur vérifié. La FAQ actuelle de Google dit que cette première phase s’applique aux boutiques participantes nommées, et que l’installation directe ainsi que les boutiques non participantes ne sont pas encore couvertes.
Si vous publiez sur Google Play
Enregistrez chaque package restant avant le 30 septembre 2026. Le guide Play Console de Google dit d’enregistrer toutes les applications que vous voulez continuer à distribuer pour "éviter une suppression mondiale de Google Play". Cette obligation est mondiale. Elle n’a rien à voir avec les quatre pays et s’applique même si aucun de vos utilisateurs n’y vit.
Ce que les utilisateurs vivent le 30 septembre
L’application côté appareil ne démarre que dans quatre pays. Le premier contrôle à l’installation couvre les sept boutiques participantes au Brésil, en Indonésie, à Singapour et en Thaïlande. Il ne touche ni le sideload direct ni les boutiques absentes de cette liste.
Ce sont deux obligations distinctes du 30 septembre, et les confondre est la façon la plus courante de mal lire cette date. L’enregistrement des packages Play est mondial et décide si votre fiche reste en ligne; l’application à l’installation est régionale et décide de ce qui se passe sur le téléphone d’un utilisateur. Vérifié
Les sept boutiques participantes
Nommez-les exactement. Décrire cela comme une restriction visant toutes les boutiques d’applications est trop large au regard de la formulation actuelle de Google pour la première phase: selon la liste que Google a publiée, une boutique qui n’est pas nommée ici est hors du déploiement du 30 septembre.
| Entreprise | Boutique participante | Contrôlée dès le 30 sept. dans les quatre pays? |
|---|---|---|
| Google Play | Oui | |
| HONOR | HONOR App Market | Oui |
| OPlus | OPPO App Market | Oui |
| Samsung | Galaxy Store | Oui |
| Transsion | Palm Store | Oui |
| vivo | V-Appstore | Oui |
| Xiaomi | GetApps | Oui |
| Vous, directement | E-mail, lien de téléchargement, votre site, Drive et, par déduction, un APK Firebase App Distribution | Non, pas encore |
| N’importe qui d’autre | Toute boutique d’applications non nommée ci-dessus | Non, pas encore |
Liste des boutiques et pays tirée de l’annonce de Google du 18 juin 2026; l’exclusion de l’installation directe et des boutiques non participantes vient de la FAQ de vérification mise à jour le 10 août 2026. Consultées le 13 août 2026. Vérifié
Les quatre pays, et les formats d’appareil à l’intérieur
Deux détails restreignent encore la chose et méritent d’être retenus. Pour la distribution hors Google Play, la FAQ de vérification de Google précise que l’application dans les régions sélectionnées concerne d’abord les formats mobile et tablette. La même FAQ indique que les protections passent par Google Play services sur les appareils Android certifiés sous Android 7 ou plus, ce qui décrit la portée finale en termes d’appareils, pas une limite propre à septembre.
Ce qui ne change pas en septembre
La liste ci-dessous est courte, mais elle couvre la façon dont la plupart des petites équipes déplacent réellement un build. Rien de tout cela n’est touché par la phase du 30 septembre.
Une installation directe. Pas couverte par la première phase.
Également une installation directe, avec la même réponse.
Distribution directe d’un APK signé à des testeurs invités. Voir la section 08 pour le tableau complet. Google ne publie aucune décision propre à Firebase: c’est donc une déduction tirée de la règle du sideload direct, pas une exemption explicite. Partiel, déduction
Google indique qu’il n’y a aucun changement dans le fonctionnement d’ADB. Section 05.
Hors de la première phase, selon la même réponse de la FAQ.
C’est une exigence Play à part entière, et elle est mondiale. Google a indiqué le 18 juin 2026 que plus de 99% des applications des développeurs Play avaient déjà été enregistrées automatiquement.
Le chiffre de 99% porte une date
Le plus de 99% d’enregistrement automatique vient de la mise à jour de Google du 18 juin 2026. Certains contenus reprennent encore un ancien chiffre d’environ 98%. Utilisez le plus récent, et citez-le avec sa date plutôt que comme un fait intemporel, parce que Google actualise ses statistiques d’adoption au fil du déploiement. La page de présentation actuelle de Google sur la vérification des développeurs arrondit désormais ce même chiffre à 99%: citez donc l'un ou l'autre avec sa source et sa date plutôt que comme une constante exacte. Vérifié
Ce qui se passe quand la vérification s’étend au monde entier en 2027
Google annonce que l’exigence s’étend au monde entier en 2027 et au-delà, aux applications installées sur des appareils Android certifiés sous Android 7 ou plus, via Google Play services. Il n’a pas annoncé de date mondiale précise ni de calendrier pays par pays. Traitez toute date 2027 précise comme non officielle tant que Google ne l’a pas publiée.
La chronologie, et ce que chaque date fait à un APK partagé
-
30 mars 2026
Le déploiement de la vérification commence pour tous les développeurs
Google a commencé à déployer la vérification des développeurs Android auprès de tous les développeurs dans Play Console et l’Android Developer Console.
APK brut Aucun changement d’installation visible par l’utilisateur du seul fait de cette date. Application non vérifiée Toujours installable selon le comportement Android existant. -
Août 2026
Le parcours avancé et les comptes à distribution limitée passent au mondial
Google a programmé le lancement mondial du parcours d’installation avancé et des comptes à distribution limitée pour ce mois-ci. Au 13 août 2026, les sources examinées nomment le mois mais pas un jour précis, et n’établissent pas que le parcours a déjà atteint tous les utilisateurs. Partiel
APK brut Toujours disponible. Application non vérifiée Le parcours avancé est le mécanisme censé en préserver l’installation. -
30 septembre 2026
L’application de l’enregistrement commence dans sept boutiques, quatre pays
Les installations via Google Play, HONOR App Market, OPPO App Market, Samsung Galaxy Store, Transsion Palm Store, vivo V-Appstore et Xiaomi GetApps au Brésil, en Indonésie, à Singapour et en Thaïlande exigent que l’application soit enregistrée auprès d’un développeur vérifié. Vérifié
APK brut Pas encore couvert par cette phase initiale. Application non vérifiée Une installation via une boutique participante peut être restreinte; le parcours direct n’est pas touché dans cette phase. -
2027 et au-delà
Extension mondiale aux appareils Android certifiés
La vérification s’étend au monde entier pour les applications installées sur des appareils Android certifiés sous Android 7 ou plus. C’est la phase où la réponse sur l’installation directe change. Vérifié
APK brut Application enregistrée: le parcours d’installation habituel. Application non enregistrée: parcours avancé ou ADB selon le modèle annoncé. Application non vérifiée Le parcours avancé ou ADB reste le parcours annoncé. -
Date exacte en 2027
Non annoncée au 13 août 2026
Le calendrier publié par Google dit 2027 et au-delà, rien de plus précis. Aucune séquence par pays n’a été communiquée non plus. Non documenté
APK brut Ne planifiez pas sur un jour précis. Application non vérifiée Ne planifiez pas sur un jour précis.
Chronologie tirée du billet de déploiement de Google du 30 mars 2026, de l’annonce du 18 juin 2026 et de la FAQ sur la vérification des développeurs Android mise à jour le 10 août 2026. Consultées le 13 août 2026.
L’échéance qui n’existe pas
Le "1er janvier 2027" apparaît dans des articles de seconde main et dans des réponses d’assistants IA. Il ne figure dans aucune source Google examinée pour cet article. Google s’est engagé sur 2027 et au-delà sans nommer de jour. Si l’un de vos plans dépend de connaître cette date, le statut honnête est que personne en dehors de Google ne la connaît encore, et la parade pratique consiste à faire enregistrer vos packages bien avant le début de l’année. Non documenté
APK vérifié ou non vérifié: ce qu’Android contrôle vraiment
"Suis-je vérifié?" est à soi seul la mauvaise question. La vérification des développeurs Android crée ce que Google appelle un lien formel et vérifiable entre une identité de développeur, le nom de package d’une application et la ou les clés de signature de ce package. La vérification d’identité est un maillon de cette chaîne, pas la chaîne entière.
La chaîne, maillon par maillon
Qui vous êtes, confirmé une seule fois via Play Console ou l’Android Developer Console.
Une fois par compteL’identifiant de l’application, par exemple com.example.app, enregistré auprès de cette identité vérifiée.
La propriété se prouve en fournissant un APK signé avec votre clé privée. La Console permet d’ajouter et de vérifier plusieurs clés pour un même package.
Par clé, pas par buildLorsque la chaîne est complète, Google indique que l’expérience d’installation habituelle des utilisateurs est préservée une fois le contrôle élargi en vigueur.
Le résultat recherchéChaîne tirée des guides de Google sur la vérification des développeurs Android, y compris la description de la preuve de propriété, et de la prise en charge de plusieurs clés de signature documentée dans la FAQ de vérification. Consultés le 13 août 2026. Vérifié
Google est explicite: l’installation directe est fondamentale pour Android, et les développeurs vérifiés peuvent continuer à distribuer directement. La nuance que cette formule masque, c’est qu’une installation sans accroc dépend de l’enregistrement de l’application, et pas seulement du fait que vous ayez passé un contrôle d’identité. C’est pourquoi cet article dit "enregistrée auprès d’un développeur vérifié" à chaque fois, plutôt que le raccourci plus flou "application vérifiée".
Et si vous utilisez une clé de débogage ou une clé de signature QA distincte?
C’est là que les vraies équipes QA se font piéger, parce qu’il est parfaitement normal de livrer un build signé en débogage aux testeurs internes et un build signé en version à la boutique. Ce sont deux certificats différents pour un même nom de package.
Audit des clés de signature, quatre questions
- Quel certificat signe réellement l’APK que vos utilisateurs installent? C’est celui-là qu’il faut enregistrer. Avec Play App Signing, la clé de signature de l’application signe l’APK installé depuis Google Play, tandis que la clé d’importation ne fait qu’authentifier l’artefact envoyé à Play et n’est pas automatiquement le certificat de la version installée. Une clé de débogage, de CI, de QA ou d’importation ne compte pour la distribution directe que si elle signe l’APK remis aux testeurs.
- Les clés concernées sont-elles enregistrées pour le package? Google permet d’ajouter et de vérifier plusieurs clés de signature pour un même nom de package: vous n’êtes donc pas obligé de tout ramener à une seule clé.
- Ne supposez pas que la vérification d’identité couvre toutes les clés. Passer l’étape d’identité ne valide pas en silence chaque certificat que vous avez utilisé un jour.
- Deux APK qui partagent un nom de package mais pas une signature ne sont pas interchangeables. C’est le comportement ordinaire de la signature Android, largement antérieur à la vérification, mais on le confond facilement avec un problème de vérification. Voir la section 12.
Cinq cas limites auxquels Google a réellement répondu
Ces cinq questions reviennent sans arrêt et ont toutes une réponse publiée. Inutile de deviner.
Questions de périmètre avec réponse documentée
- Android 6 ou antérieur? Hors du périmètre annoncé. Google indique que l’application concerne les appareils Android certifiés sous Android 7 ou plus, via les services Google Play. Vérifié
- Appareils non certifiés ou ROM personnalisées sans services Google Play? Google décrit cette application pour les appareils Android certifiés, via les services Play. Ne généralisez pas la règle à toutes les ROM personnalisées ou aux appareils non certifiés: ils sortent du mécanisme que Google documente. Non documenté pour ces appareils
- Applications d’entreprise sur appareils gérés? Les applications distribuées via la boutique de votre organisation vers des appareils gérés n’ont pas à passer la vérification, puisque votre administrateur informatique les a validées. Google recommande quand même de les enregistrer, au cas où l’application serait aussi installée depuis une autre source ou sur un appareil non géré. Vérifié
- Où vérifier qu’un package est enregistré? Développeurs Play: la page de vérification des développeurs Android dans la Play Console, qui affiche le statut à côté de chaque application. Développeurs hors Play: l’onglet Noms de packages de l’Android Developer Console, avec Enregistré, Non enregistré ou Brouillon. Android Studio Panda 4 et versions ultérieures affichent aussi ce statut lors de la génération d’un APK ou d’un App Bundle signé. Vérifié
- Les développeurs hors Play paient-ils 25 dollars? Le compte Android Developer Console en distribution complète coûte 25 dollars. Le compte en distribution limitée est gratuit, ne demande pas de pièce d’identité officielle et plafonne à 20 appareils autorisés. Si vous publiez déjà sur Google Play, la vérification se gère dans la Play Console plutôt qu’avec un compte séparé. Vérifiez d’abord la disponibilité: au 13 août 2026, l’accès anticipé était encore fermé. Disponibilité partielle
Firebase exige aussi une signature, pour une autre raison
Firebase App Distribution exige qu’un APK soit signé avec une clé de débogage ou une clé de signature d’application avant de le distribuer. C’est une exigence Firebase portant sur la validité du build, pas une étape de la vérification des développeurs Android. Les deux systèmes utilisent le mot "enregistrer", et les distinguer est une nuance importante dans tout ce sujet. La section 08 les sépare. Vérifié
La distinction entre clé d’importation et clé de signature explique aussi le ticket Firebase le plus fréquent. Une copie de votre application installée depuis Play peut être signée par la clé de signature de Google Play, alors que l’APK Firebase remis au même testeur est signé localement avec une clé d’importation, de release ou de débogage. Android ne peut pas installer l’un par-dessus l’autre tant que les identités de signature acceptées ne correspondent pas: le testeur voit alors une erreur qui ressemble à un problème de vérification sans en être un. Vérifié
ADB reste autorisé, mais c’est un workflow de développeur
L’engagement le plus clair de Google dans tout ce programme, tiré de sa FAQ de vérification: le fonctionnement d’ADB ne change pas. Les développeurs et les utilisateurs avancés peuvent continuer à installer des applications ainsi, et le délai d’attente de 24 heures du parcours avancé ne s’applique pas aux installations ADB. C’est la méthode la plus durable de cet article, et aussi la moins adaptée à des testeurs ordinaires.
Bon pour
- Vous, sur votre propre appareil, toute la journée
- Une équipe QA technique qui a déjà Android Studio installé
- Les chaînes d’intégration continue et les fermes d’appareils
- Installer un build non enregistré sans subir le délai d’un jour du parcours avancé
- Un collègue assis à côté de vous avec un câble USB
Mauvais pour
- Douze amis, membres de la famille ou testeurs recrutés
- Toute personne que vous ne pouvez pas guider dans les options pour les développeurs par téléphone
- Des testeurs à distance dans d’autres pays, sans câble ni ordinateur portable
- L’itération rapide: chaque nouveau build demande un accès à l’appareil et une commande d’installation de plus, même si le testeur ne refait pas toute la configuration
- Tout ce que vous voulez faire compter par Google Play. Les installations ADB sont invisibles pour les exigences de test de Play
Ce qu’un testeur doit faire au préalable
La documentation d’outillage de Google est catégorique sur le prérequis: pour utiliser ADB via USB, vous devez activer le débogage USB dans les options pour les développeurs de l’appareil. Sur un téléphone récent, cela veut dire trouver le numéro de build, le toucher sept fois pour débloquer les options pour les développeurs, puis activer le débogage USB dans un écran de réglages qui affiche une boîte de dialogue d’avertissement. Ce parcours est praticable pour un testeur technique et pesant pour une personne qui s’est simplement portée volontaire pour essayer votre application.
La configuration ne se refait pas à chaque build, et c’est le détail que la plupart des articles ratent. Une fois que le testeur a autorisé votre poste de travail, cette autorisation reste valable jusqu’à ce qu’il la révoque ou oublie l’appareil. Un nouveau build coûte donc un adb install -r de plus et un accès au téléphone, pas un nouveau passage par les options pour les développeurs. Android 11 et versions ultérieures prennent aussi en charge le débogage sans fil: le testeur associe le téléphone au poste une seule fois via un QR code ou un code d’association, puis vous installez par le réseau tant que les deux appareils y sont, sans aucun câble. Cela supprime le câble, pas le prérequis technique.
Les trois commandes qui couvrent presque toutes les installations chez un testeur. Rien ici n’est nouveau en 2026: c’est le workflow que Google dit inchangé.
adb devicesadb install app-release.apkadb install -r app-release.apkCelle qui surprend: -r ne fonctionne que si le nouvel APK est signé avec le même certificat que celui déjà installé. Un build signé avec une autre clé doit d’abord être désinstallé, ce qui emporte les données de l’application. C’est le comportement standard de la signature Android, pas une règle de vérification.
Utilisez ADB comme secours, pas comme plan
Dans le modèle annoncé par Google, ADB est un secours documenté pour installer des applications non vérifiées, y compris pendant le déploiement élargi prévu. C’est la méthode qui continue de fonctionner quand un build n’est pas enregistré et que le testeur n’attendra pas un jour entier. Il reste utile de revérifier la règle avant de compter là-dessus en 2027. Ce que ce n’est pas, c’est un moyen d’embarquer douze personnes ordinaires, et cela ne satisfera jamais l’exigence de test de Google Play pour l’accès en production. Vérifié
Qu’est-ce que le parcours avancé d’Android pour les applications non vérifiées?
Google a construit un parcours délibéré pour les utilisateurs qui veulent quand même installer une application d’un développeur non vérifié. C’est une configuration unique avec une étape de friction au milieu: activer le mode développeur, confirmer que personne ne vous guide, redémarrer, attendre un jour, s’authentifier, puis autoriser les installations non vérifiées pendant 7 jours ou indéfiniment. L’attente de 24 heures fait partie de cette configuration, ce n’est pas un délai avant chaque APK.
-
01
Activer le mode développeur
L’utilisateur active le mode développeur ou le réglage équivalent sur son appareil.
Google: cela empêche les déclenchements accidentels et les contournements en un geste utilisés dans les arnaques sous pression -
02
Confirmer que personne ne le guide
L’utilisateur confirme qu’aucune autre personne ne le guide dans cette modification de sécurité.
Google: une vérification rapide que personne ne vous pousse à désactiver votre sécurité -
03
Redémarrer et se réauthentifier
L’appareil redémarre et l’utilisateur se reconnecte.
Google: cela coupe l’accès à distance ou l’appel en cours dont se sert un escroc pour vous observer -
04
Attendre 24 heures, une seule fois
Google décrit cela comme une attente unique d’un jour. Elle se produit pendant la configuration, et c’est l’étape que tout le monde rapporte de travers.
Pas 24 heures avant chaque APK. Une fois, par compte. -
05
Vérifier son identité sur l’appareil
L’utilisateur confirme la modification par biométrie ou avec le code de l’appareil.
Google: la biométrie ou le code PIN confirme que c’est le propriétaire de l’appareil qui fait le changement -
06
Autoriser les installations non vérifiées pendant 7 jours ou indéfiniment
Configuration terminée. L’utilisateur choisit la durée, puis peut passer l’avertissement de développeur non vérifié au moment d’installer.
Son choix, son risque, son appareil
Séquence, formulation et options de durée tirées de la FAQ de Google sur la vérification des développeurs Android, consultée le 13 août 2026. Google publie une raison pour chaque étape de ce parcours: les notes ci-dessus rapportent donc sa justification au lieu de la déduire. Vérifié
Trois choses que l’on comprend de travers
"Donc chaque installation demande une attente de 24 heures?"
Non. Google décrit une attente unique d’un jour à l’intérieur de la configuration. Ensuite, l’utilisateur choisit 7 jours ou indéfiniment pour la durée pendant laquelle les installations non vérifiées restent autorisées.
"Faut-il tout refaire sur chaque nouveau téléphone?"
Google dit non. La FAQ décrit la configuration comme unique par compte, conservée sur un nouvel appareil.
"ADB a-t-il aussi besoin de cette attente?"
Non. Google indique explicitement que le délai d’attente de 24 heures ne s’applique pas aux installations ADB. Section 05.
Les options pour les développeurs n’ont pas à rester activées
Un testeur peut désactiver de nouveau les options pour les développeurs une fois le parcours avancé activé. La FAQ de Google le dit directement: vous n’avez pas à laisser les options pour les développeurs activées, car une fois la modification faite sur l’appareil, le réglage est actif. C’est important pour les testeurs dont les applications bancaires ou d’entreprise protestent quand ces options restent activées. Google précise aussi que la configuration se fait une fois par compte et se transmet à un nouvel appareil: elle ne se répète ni pour chaque application ni pour chaque téléphone. Vérifié
Est-il actif en ce moment?
Statut honnête au 13 août 2026
Google a programmé le lancement du parcours avancé dans le monde entier en août 2026. Les sources examinées pour cet article nomment le mois mais pas un jour précis, et aucune n’établit que le parcours a déjà atteint tous les utilisateurs. Ce qu’il faut donc dire aujourd’hui à un testeur, c’est que la méthode existe et est programmée, pas qu’il pourra certainement l’utiliser cet après-midi. Vérifiez les pages de vérification de Google avant de bâtir un script de support autour. Partiel
La lecture pratique pour un développeur: le parcours avancé est une réponse réelle et documentée à "un utilisateur peut-il encore installer mon application non vérifiée?" et une mauvaise réponse à "comment livrer un build à douze testeurs cette semaine?". Un délai de sécurité d’un jour au milieu de l’intégration ajoute une vraie friction pour des testeurs occasionnels ou distants. Si vos testeurs sont des utilisateurs ordinaires, les méthodes qui respectent leur temps sont comparées en section 09.
Qu’arrive-t-il aux APK déjà installés?
La documentation de Google couvre l’installation et la mise à jour. Une fois l’application des règles en vigueur, une application non enregistrée ne peut pas être installée ni mise à jour normalement, et Google indique qu’une mise à jour ordinaire "échouera". Ce que la documentation consultée ne dit pas, c’est que les copies déjà présentes sur les téléphones seraient supprimées ou empêchées de se lancer.
| Situation une fois l’application élargie en vigueur | Résultat documenté | Preuve |
|---|---|---|
| L’application est déjà installée et l’utilisateur l’ouvre simplement | La documentation Google consultée n’annonce pas de suppression forcée ni de blocage à l’exécution. Elle traite de l’installation et des mises à jour. | Partiel |
| Un utilisateur tente d’installer normalement une application non enregistrée | L’installation normale est restreinte. | Vérifié |
| L’utilisateur a activé le parcours avancé | L’application non enregistrée peut être installée. | Vérifié |
| L’installation passe par ADB | L’application non enregistrée peut être installée. Aucune attente du parcours avancé ne s’applique. | Vérifié |
| Une application non enregistrée déjà installée reçoit une mise à jour ordinaire, parcours avancé désactivé | Google indique que la mise à jour échoue. | Vérifié |
| Cette même application est mise à jour via ADB | Autorisé, selon l’exception annoncée par Google. | Vérifié |
Comportement tiré de la FAQ de Google sur la vérification des développeurs Android, consultée le 13 août 2026. La première ligne constate l’absence d’un mécanisme annoncé, ce qui n’est pas la même chose qu’une promesse que ce comportement ne changera jamais.
N’écrivez pas "votre application sera supprimée"
C’est l’affirmation la plus virale sur ce sujet et elle n’est pas étayée. La formulation exacte, celle utilisée dans tout cet article, est: Google documente des restrictions d’installation et de mise à jour; il n’a pas annoncé que les copies déjà installées seraient retirées des appareils ni empêchées de se lancer. Rapporter l’absence de source est honnête. Convertir cette absence en garantie de tranquillité ou en prédiction de suppression massive ne l’est pas. Partiel, absence de source
Cette distinction change ce que vous devez réellement faire. Une mise à jour bloquée est un problème opérationnel réel et documenté: un testeur concerné peut rester sur un build ancien parce que la mise à jour ne s’installe pas par le parcours normal, et il ne le signalera peut-être jamais, parce que de son côté il ne s’est rien passé. Une désinstallation de masse serait une urgence d’une tout autre nature, appelant une communication d’une tout autre nature. Une seule des deux figure au dossier.
La place de Firebase App Distribution après la vérification
Firebase App Distribution sert à installer des builds de préproduction sur les appareils de vos testeurs. Ce n’est pas un système de vérification, ce n’est pas un canal de test Google Play, et cela n’exempte rien de la vérification des développeurs Android. Ce qu’il fait bien, c’est supprimer le travail manuel qu’il y a à remettre un build signé à une liste de personnes.
Comment se déroule vraiment le parcours APK
Vous importez un APK signé dans la console Firebase. Firebase exige qu’il soit signé avec une clé de débogage ou une clé de signature d’application.
Sélectionnez des groupes de testeurs ou des testeurs individuels pour cette version.
Les testeurs reçoivent une invitation et installent le build distribué.
Les builds distribués restent disponibles 150 jours. Les invitations de testeurs expirent après 30 jours, et Firebase prévient 5 jours avant.
Parcours, exigence de signature, conservation des builds pendant 150 jours et expiration des invitations à 30 jours tirés de la documentation Android de Firebase App Distribution, consultée le 13 août 2026. Vérifié
Deux compteurs d’expiration, deux tickets de support différents
L’expiration des invitations à 30 jours et la conservation des builds pendant 150 jours sont deux choses distinctes. Un testeur qui laisse traîner l’e-mail cinq semaines a une invitation expirée alors que le build, lui, est parfaitement vivant. Cela produit un message confus du type "le lien est cassé" qui n’a rien à voir avec la vérification, la signature ou Android. Vérifié
Firebase fonctionne-t-il toujours pendant la phase de septembre?
Presque certainement oui, et la manière d’arriver à cette conclusion compte. Le parcours APK de Firebase est une distribution directe d’un APK signé à des testeurs invités. La FAQ de Google dit que l’installation directe n’est pas couverte par la phase du 30 septembre. Rapprochez ces deux faits et la distribution d’APK par Firebase devrait rester utilisable pendant toute cette première phase.
Cette conclusion est une déduction, et elle est signalée comme telle
Aucune source Google ne nomme Firebase App Distribution pour lui accorder une exemption. La conclusion ci-dessus découle de deux faits vérifiés: les installations directes sont hors de l’application initiale de septembre, et le parcours APK de Firebase est une distribution directe. C’est une déduction solide, et cela reste une déduction: c’est pourquoi cet article la note au lieu de l’affirmer sèchement. Partiel, déduction
La distribution Firebase en APK et en AAB, ce n’est pas la même chose
C’est la nuance que presque tous les articles écrasent. Firebase prend en charge les deux, et ils empruntent des routes différentes jusqu’au téléphone du testeur.
| Parcours Firebase | Comment le build atteint le testeur | Comment y penser du point de vue de la vérification |
|---|---|---|
| APK | Firebase distribue l’APK signé directement aux testeurs invités. | Distribution directe. Se comporte comme la voie de l’installation directe, y compris en septembre. Partiel |
| Android App Bundle (AAB) | Le parcours AAB de Firebase s’intègre au partage interne d’applications de Google Play. | Un parcours connecté à Play: ne raisonnez donc pas dessus comme s’il s’agissait de la voie de l’APK brut. Google n’a pas indiqué comment il est traité au titre de l’application de septembre. Intégration vérifiée Application non documentée |
Un AAB ne peut pas être sideloadé du tout
Avant même les questions de vérification, il y en a une plus simple sur laquelle beaucoup butent: un Android App Bundle ne s’installe pas directement sur un téléphone. Un fichier .aab est un format de publication, pas un paquet prêt pour l’appareil. Google Play, le parcours AAB de Firebase relié à Play, ou bundletool doit d’abord le transformer en APK. Donc si vous avez besoin d’un fichier à envoyer par e-mail, à déposer sur Drive ou à remettre directement à un testeur, compilez un APK. La documentation de build d’Android indique elle-même qu’un app bundle ne peut pas être déployé directement sur un appareil. Vérifié
La question "Firebase fonctionne-t-il toujours?" a donc deux réponses selon l’artefact que vous importez. Quand vous écrivez à ce sujet, ou quand vous interrogez un collègue, précisez distribution Firebase en APK ou distribution Firebase en AAB. Le raccourci cache un détail qui change matériellement l’analyse.
Firebase App Distribution compte-t-il pour la règle des 12 testeurs?
Non. L’exigence d’accès en production de Google pour les comptes concernés demande au moins 12 testeurs inscrits à un test fermé Google Play, sans interruption, pendant les 14 jours précédents. Les testeurs Firebase ne sont pas inscrits à un test fermé Play: tester via Firebase ne satisfait donc pas cette exigence, quel que soit le nombre de participants ou la qualité de leurs tests.
| Question | Firebase App Distribution | Test fermé Google Play |
|---|---|---|
| À quoi cela sert-il? | À livrer vite des builds de préproduction à des testeurs | À satisfaire la porte de préproduction de Play, et à tester sur la boutique |
| Où les testeurs s’inscrivent-ils? | Par un e-mail d’invitation Firebase | Par un lien d’inscription Play, sur le canal fermé |
| Cela enregistre-t-il votre application pour la vérification des développeurs Android? | Non l’"enregistrement de votre application" dans Firebase est un processus entièrement différent | Non l’enregistrement des packages est une tâche à part |
| Cela satisfait-il l’exigence de 12 testeurs pendant 14 jours sans interruption? | Non | Oui pour les testeurs et les comptes éligibles |
| Cela vaut-il quand même la peine? | Oui comme canal de QA, à côté du test fermé | Oui c’est le parcours exigé |
Exigence Play tirée de la réponse 14151465 de l’aide Play Console; comportement de Firebase tiré de la documentation Firebase App Distribution. Toutes deux consultées le 13 août 2026. Les deux produits définissent des processus différents qui partagent le mot "enregistrer". Vérifié
Le schéma que cela crée mérite d’être nommé, parce qu’il coûte deux semaines. Un développeur mène un test Firebase réellement rigoureux avec quinze testeurs impliqués, en conclut que la case test est cochée, ouvre Play Console pour demander l’accès en production, et découvre que le compteur des 14 jours n’a pas démarré. La section 10 met les deux exigences côte à côte pour que cela ne puisse pas vous arriver.
La meilleure façon de livrer un build à 12 testeurs en 2026
Il n’y a pas de gagnant unique, parce que les méthodes ne résolvent pas le même problème. Un APK brut est la chose la plus simple qui fonctionne aujourd’hui. ADB est la plus durable et la moins utilisable. Firebase est le meilleur canal de QA pur. Et une seule méthode de cette page satisfait l’exigence d’accès en production de Google Play, celle qui décide vraiment de votre date de lancement.
Vérificateur de méthode de distribution
Rien n’est envoyé nulle part. La logique s’exécute dans votre navigateur à partir de la portée publiée par Google, de la documentation Firebase et de la règle d’accès en production de Play.
1 Comment leur livrez-vous le build?
2 Où sont vos testeurs?
3 L’application est-elle enregistrée auprès d’un développeur vérifié?
Portée tirée de la FAQ de vérification de Google (10 août 2026), de la documentation Firebase App Distribution et de la réponse 14151465 de l’aide Play Console. Consultées le 13 août 2026.
Les sept méthodes, côte à côte
L’outil répond à une situation. Ce tableau répond à toutes, y compris les deux colonnes que l’on saute jusqu’à ce qu’il soit trop tard: le comportement annoncé pour 2027, et le fait de savoir si la méthode sert à quoi que ce soit pour votre demande d’accès en production sur Play.
| Méthode | Ce que le testeur doit faire | Première phase du 30 sept. 2026 | Modèle annoncé pour 2027 | Compte pour les 12/14 de Play? | Verdict pratique |
|---|---|---|---|---|---|
| APK brut par e-mail, Drive ou site web | Télécharger l’APK et autoriser l’installation depuis cette source | Toujours viable l’installation directe n’est pas encore couverte | Application enregistrée: installation normale; application non enregistrée: parcours avancé ou ADB attendus | Non | Très bien pour de la QA ponctuelle aujourd’hui. Ce n’est pas le test d’accès en production. |
| ADB | Activer les options pour les développeurs et le débogage USB, connecter, installer avec les outils de développement | Oui | Oui Google préserve explicitement ADB | Non | Durable, mais trop technique pour des testeurs ordinaires. |
| Firebase App Distribution, APK | Accepter l’e-mail d’invitation et installer le build distribué | Probablement pas concerné d’après la règle du sideload direct. Aucune décision propre à Firebase. Partiel | Un package enregistré devrait rester fluide; un package non enregistré suit le modèle élargi de l’installation directe | Non | Excellent workflow de QA. Pas un substitut au test Play. |
| Firebase App Distribution, AAB | Recevoir le build par un parcours intégré au partage interne d’applications Play | Non documenté connecté à Play via le partage interne; Google n’a pas indiqué comment ce parcours est traité Non documenté | Dépend de Play et de l’enregistrement du package | Non | Utile, et mérite sa propre explication plutôt que d’être confondu avec Firebase APK. |
| Test interne Google Play | Rejoindre le test interne et installer depuis Play | Viable pour une application Play correctement enregistrée | Viable | Non ce n’est pas un substitut au test fermé exigé | Bonne QA rapide fondée sur Play. Jusqu’à 100 testeurs. |
| Test fermé Google Play | S’inscrire via le lien du test fermé et rester inscrit | Viable | Viable | Oui pour les testeurs et les comptes éligibles | Le parcours exigé pour les nouveaux comptes personnels concernés qui veulent l’accès en production. |
| Distribution limitée Android | Avoir un appareil autorisé dans le système de distribution limitée | Programmée pour août 2026, accès anticipé encore fermé Partiel | Conçue comme un parcours durable pour petit public | Non | Pour des amateurs qui partagent avec jusqu’à 20 appareils. Gratuit, sans pièce d’identité officielle, ne permet pas de publier sur Play. |
Sources: la FAQ et les guides de vérification de Google, la documentation de l’outil ADB, la documentation Firebase App Distribution, la distribution limitée, l’aide Play Console sur le test interne et sur les exigences de test pour l’accès en production. Toutes consultées le 13 août 2026.
La recommandation honnête
Menez deux chantiers en parallèle, parce qu’ils répondent à des questions différentes. Utilisez ce qui met un build sur des appareils le plus vite possible pour la vraie QA: un APK brut pour un collègue, Firebase pour un groupe, ADB quand il faut tout contourner. Puis, séparément et le plus tôt possible, menez le test fermé Play si votre compte est soumis à l’exigence d’accès en production, parce que celui-là se mesure en jours calendaires et ne se comprime pas en travaillant plus.
L’erreur à éviter est de les traiter comme séquentiels. Terminer un test Firebase approfondi ne fait pas avancer le compteur des 14 jours d’une seule journée.
La vérification des développeurs ne remplace pas le test fermé Google Play
Ce sont deux exigences sans rapport que les gens fusionnent en une seule case mentale. La vérification répond à "qui a créé et signé ce package?" Le test fermé répond à "ce compte a-t-il terminé le test de préproduction de Google?" Satisfaire l’une ne fait absolument rien pour l’autre.
Modèle de vérification tiré des guides de Google sur la vérification des développeurs Android; exigence de test tirée de la réponse 14151465 de l’aide Play Console et de la page sur le test interne (réponse 9845334). Consultées le 13 août 2026.
Pourquoi "le test interne compte, c’est quand même un test Play" est faux
Google autorise jusqu’à 100 testeurs sur un test interne, ce qui le fait paraître plus sérieux. Mais l’exigence d’accès en production est écrite autour d’un canal précis: les testeurs pris en compte doivent avoir été inscrits à un test fermé pendant les 14 derniers jours sans interruption. Le test interne est un autre canal: il ne satisfait donc pas cette phrase.
Une note sur la source de cette affirmation
Google ne publie pas de phrase disant "le test interne ne compte pas". Ce qu’il publie, c’est une exigence qui précise un test fermé. La conclusion découle de la définition et non d’une citation, et cet article le formule ainsi plutôt que de mettre des mots dans la bouche de Google. Vérifié par la définition de l’exigence
Les chiffres, et d’où ils viennent
Deux éléments d’histoire règlent des questions qui reviennent sans arrêt. Google a annoncé l’exigence le 9 novembre 2023, et la règle actuelle l’applique aux comptes personnels créés après le 13 novembre 2023: deux dates différentes qui veulent dire deux choses différentes. Et le minimum était à l’origine de 20 personnes pendant au moins deux semaines; le guide communautaire de Google indique lui-même que la réduction à 12 a eu lieu en décembre 2024. Des témoignages de développeurs de l’époque situent le changement dans Play Console au 11 décembre 2024, mais aucune annonce Google datée de ce jour précis n’a pu être retrouvée: traitez donc ce jour comme rapporté et non comme officiel. Partiel
Les comptes d’organisation sont hors de cette porte précise: l’exigence vise les comptes personnels éligibles. Et les frais ne changent pas dans un cas comme dans l’autre: un versement unique de 25 USD pour l’inscription à Google Play. Si vous voulez la comparaison complète des types de compte plutôt qu’un paragraphe, elle est traitée dans compte personnel ou compte d’organisation.
Dix affirmations sur ce sujet qui ne sont plus à jour
Une bonne partie des articles sur la vérification des développeurs Android a été écrite avant que Google ne restreigne la première phase en juin et juillet 2026. Les affirmations ci-dessous ne sont pas des mensonges; plusieurs étaient exactes au moment de leur publication. Elles décrivent simplement une version de la règle qui ne correspond plus aux pages actuelles de Google.
Affirmation Toutes les installations directes d’APK sont bloquées à partir du 30 septembre dans les quatre pays.
Règle actuelle Faux au regard de la FAQ de Google du 15 juillet 2026. Le 30 septembre couvre sept boutiques participantes. Les installations directes ne sont pas encore couvertes. Vérifié
Affirmation La vérification des développeurs signifie qu’on ne peut plus installer une application d’un développeur non vérifié.
Règle actuelle Trop absolu. ADB reste disponible, et Google a construit le parcours avancé précisément pour les applications non vérifiées. Vérifié
Affirmation L’échéance mondiale est le 1er janvier 2027.
Règle actuelle Non étayé. Google a annoncé "2027 et au-delà" et aucune date mondiale précise. Non documenté
Affirmation Une fois votre identité vérifiée, n’importe quel APK que vous signez passe.
Règle actuelle Incomplet. Le nom de package et les clés de signature concernées doivent aussi être enregistrés. Vérifié
Affirmation Firebase App Distribution vérifie votre application Android.
Règle actuelle Confusion. L’"enregistrement de votre application" dans Firebase et l’enregistrement de la vérification des développeurs Android sont deux systèmes différents. Vérifié
Affirmation Les testeurs Firebase comptent pour les 12 testeurs de Google.
Règle actuelle Faux. Google exige 12 testeurs inscrits au test fermé Play. Vérifié
Affirmation Le test interne Play compte, puisque c’est quand même un test Play.
Règle actuelle Pas pour cette porte. L’exigence d’accès en production nomme précisément un test fermé. Vérifié par définition
Affirmation Les applications non vérifiées déjà installées seront supprimées.
Règle actuelle Non étayé. Google documente des restrictions d’installation et de mise à jour et n’annonce aucun retrait automatique des copies installées. Partiel, absence de source
Affirmation Le parcours avancé est forcément actif partout, puisqu’on est en août.
Règle actuelle Trop fort. Google a programmé un lancement mondial en août 2026 sans publier de jour de mise en service précis. Partiel
Affirmation Environ 98% des applications Play ont été enregistrées automatiquement.
Règle actuelle Périmé. La mise à jour de Google du 18 juin 2026 dit plus de 99%. Vérifié
Là où les deux pages de Google semblent se contredire
Cela mérite d’être nommé, parce qu’un lecteur attentif va tomber dessus. La formulation générale de l’aide de Google dit que les applications dont les développeurs n’ont pas rempli l’exigence deviennent indisponibles pour de nouvelles installations dans les pays concernés, ce qui sonne plus large que l’exception limitée aux boutiques. La FAQ, plus spécifique et mise à jour le 10 août 2026, dit que l’échéance du 30 septembre ne s’applique qu’aux boutiques participantes et n’atteint pas encore l’installation directe.
Comment ce billet tranche, et pourquoi c’est un choix éditorial
Interprétation éditoriale. Pour la première phase du 30 septembre, ce billet suit la réponse de FAQ la plus récente et la plus spécifique au scénario, parce qu’elle nomme explicitement le sideload direct et les boutiques non participantes au lieu de les sous-entendre, et parce que sa réponse sur le sideload direct porte la date du 15 juillet 2026. Le texte d’aide général décrit le programme dans son ensemble. Google n’a pas publié de règle formelle disant qu’une source prime sur l’autre: c’est donc notre choix éditorial, annoncé ouvertement plutôt que masqué. Mieux vaut lire les deux pages comme décrivant des couches différentes du même déploiement que comme une contradiction. Interprétation éditoriale
Du symptôme à la solution: ce qui ne va vraiment pas
Trouvez la phrase que vous ou votre testeur avez réellement prononcée. Une cause fréquente d’échec d’installation ou de mise à jour chez un testeur est une incompatibilité de certificat de signature, qui est un comportement Android ordinaire, n’a rien à voir avec la vérification des développeurs et la précède d’une décennie.
"Mon ami n’arrive pas à installer l’APK depuis la vérification"
Explication probable. Presque certainement pas la vérification des développeurs. Avant le déploiement élargi de 2027, un échec d’installation d’APK en direct n’est pas causé par la règle du 30 septembre, puisque cette règle ne touche pas encore ce parcours. La cause réelle la plus fréquente est une non-correspondance de certificat de signature: le téléphone a déjà une copie de l’application signée avec un autre certificat.
Vérification la plus sûre, dans cet ordre. Traitez d’abord les échecs d’installation Android ordinaires: une copie installée signée avec un autre certificat, un versionCode inférieur à celui déjà installé, une version d’Android ou une architecture CPU non prise en charge, un téléchargement tronqué ou corrompu, un espace de stockage insuffisant, l’autorisation d’installation non accordée à l’application qui livre le fichier, ou un avertissement Play Protect que le testeur a ignoré. Ensuite, et seulement si l’installation passe par une boutique participante ou si l’application élargie a commencé, vérifiez l’enregistrement du package et de la clé de signature.
Concept vérifié
"Firebase dit que l’installation a échoué par-dessus ma version Play"
Explication probable. Un testeur qui a déjà un build signé par Play installé ne peut pas le mettre à jour sur place avec un APK Firebase signé par un autre certificat. Des développeurs ont signalé exactement cela, et les testeurs comprennent rarement le message d’erreur.
Vérification la plus sûre. Comparez les certificats de signature des deux artefacts. Soit vous utilisez un chemin de signature compatible, soit le testeur désinstalle d’abord l’ancien build, ce qui emporte ses données: prévenez-le.
Exemple signalé par la communauté
"Dois-je attendre 24 heures pour installer via ADB?"
Réponse. Non. Google indique que le délai d’attente de 24 heures du parcours avancé ne s’applique pas aux installations ADB.
Étape suivante. Utilisez le workflow ADB habituel. La section 05 contient les commandes.
Vérifié
"Mon application non enregistrée était déjà installée mais refuse de se mettre à jour"
Explication probable. Une fois les règles appliquées à ce parcours d’installation, Google indique que les mises à jour d’une application non enregistrée exigent le parcours avancé ou ADB, et qu’une mise à jour ordinaire échoue.
Vérification la plus sûre. Enregistrez correctement le package. En attendant, le testeur peut activer le parcours avancé ou vous pouvez pousser la mise à jour via ADB.
Vérifié
"J’ai testé avec 12 personnes dans Firebase mais Play refuse toujours ma demande d’accès en production"
Explication probable. Les testeurs Firebase ne sont pas inscrits à un canal de test fermé Play: rien de ces tests n’est comptabilisé pour l’exigence d’accès en production.
Vérification la plus sûre. Lancez le test fermé Play: au moins 12 testeurs éligibles, inscrits et qui le restent, pendant 14 jours sans interruption. Le compteur démarre quand ils sont réellement inscrits, pas quand vous avez commencé à tester.
Vérifié
"J’ai utilisé 12 personnes en test interne Play mais la production reste bloquée"
Explication probable. Le test interne n’est pas le canal que nomme l’exigence d’accès en production. La règle demande un test fermé.
Vérification la plus sûre. Déplacez le test qui compte vers un canal fermé Play. Le test interne reste utile pour une QA rapide en parallèle.
Vérifié par la définition de la règle
"Mon testeur n’a jamais reçu l’invitation Firebase, ou dit que le lien est mort"
Explication probable. Les invitations de testeurs Firebase expirent après 30 jours, avec un avertissement 5 jours avant. Un testeur qui a laissé l’e-mail de côté pendant un mois a une invitation expirée alors que le build lui-même reste disponible 150 jours.
Vérification la plus sûre. Renvoyez l’invitation avant de supposer quoi que ce soit sur la signature, la vérification ou l’appareil. Les échecs d’intégration des testeurs dans App Distribution sont souvent signalés comme des problèmes de compte, d’invitation ou de source d’installation plutôt que comme des problèmes de build.
Vérifié Schéma signalé par la communauté
"Un article dit que toute installation directe s’arrête le 30 septembre"
Explication probable. Il s’appuie sur des articles de 2025 ou du début 2026 écrits avant que Google ne restreigne la portée initiale.
Vérification la plus sûre. Lisez directement la FAQ de vérification de Google. La réponse actuelle est que l’échéance du 30 septembre concerne les boutiques participantes et ne couvre pas encore l’installation directe.
Correction vérifiée
La règle qui fait gagner le plus de temps de support
Deux APK portant le même nom de package mais des signatures sans rapport ne sont pas interchangeables, et ne l’ont jamais été. Avant de diagnostiquer quoi que ce soit comme un problème de vérification des développeurs, vérifiez si vous ne demandez pas simplement à Android de remplacer une application par un sosie signé différemment. L’architecture de la vérification rappelle pourquoi l’identité de signature compte, mais cet échec-là se confond facilement avec un problème de vérification des développeurs alors qu’il n’est ni nouveau ni lié.
Ce que vous devez vraiment faire avant le 30 septembre
Si vous ne distribuez que des APK en direct, la première phase du 30 septembre n’applique pas la vérification des développeurs sur ce parcours. C’est temporaire et non définitif: Google recommande de terminer la vérification avant le déploiement mondial qui commence en 2027. Si vous publiez sur Google Play, il demande une seule chose: chaque package enregistré. Et indépendamment des deux, si votre compte est soumis à la porte de l’accès en production, le compteur de 14 jours est l’élément qui décide de votre date de lancement: il devrait donc déjà tourner.
Suivi avant échéance
Douze éléments dans l’ordre où ils se produisent vraiment. Cochez au fur et à mesure; rien n’est enregistré, alors terminez d’une traite ou gardez l’onglet ouvert.
0 / 12 terminés
Rien de coché pour l’instant. Commencez par déterminer sur quelle voie vous êtes.
Quand cet article ne sera plus à jour
C’est un article inhabituellement périssable et il serait malhonnête de le présenter comme intemporel. Voici les éléments les plus susceptibles de changer en premier, et ce qui rendrait chacun d’eux faux.
Le déclencheur de mise à jour le plus important de la page. Si Google reformule la réponse de la FAQ qui dit aujourd’hui que l’installation directe n’est pas encore couverte, toute la première moitié de cet article change.
Sept boutiques, quatre pays. Google peut ajouter des boutiques ou préciser le comportement le jour même. À vérifier le 29 septembre, le jour même, et une semaine après.
Les deux étaient programmés pour un lancement mondial en août 2026 sans jour publié. Leur statut peut changer sans aucun changement de règle.
Dès que Google nomme des pays ou des dates pour 2027, cet article aura besoin d’un tableau par pays qu’il n’a aujourd’hui, à juste titre, pas.
Les documentations APK et AAB de Firebase évoluent indépendamment l’une de l’autre, et l’exigence Play de 12 testeurs pendant 14 jours vit sur une page d’aide que Google révise sans annonce.
Cadence de mise à jour retenue pour cet article: hebdomadaire jusqu’au 30 septembre 2026, puis le jour de l’entrée en vigueur et environ une semaine après pour les précisions de mise en oeuvre, puis mensuelle jusqu’à ce que Google publie un calendrier 2027 concret. Cette cadence est un choix éditorial fondé sur la fréquence à laquelle Google a révisé ce programme en 2026, pas un calendrier officiel de Google.
Ce que PrimeTestLab couvre, et ce qu’il ne couvre pas
La limite d’abord, parce que c’est la partie honnête. PrimeTestLab ne vérifie pas votre identité, n’enregistre pas vos noms de package et ne transforme pas un test Firebase en test fermé Play. Cela vous appartient, et cet article est toute notre contribution sur ces points. Ce que nous couvrons, c’est la seule exigence de cette page qui est faite de temps calendaire et non de paperasse: 12 testeurs réels, inscrits pendant 14 jours consécutifs sur un canal de test fermé Play. Google publie bien des API et une délégation OAuth permettant à une plateforme autorisée d’aider un développeur pour l’enregistrement, mais c’est à vous d’accorder cet accès et vous restez responsable du compte et de l’identité de l’application.
Cette distinction a exactement la forme du problème que cet article existe pour corriger. Un développeur distribue ses builds à la perfection: groupes Firebase, notes de version soignées, testeurs impliqués, vrais rapports de bug. Puis il ouvre Play Console pour demander l’accès en production et découvre que rien de tout cela n’a compté. La distribution est un problème résolu. La fenêtre d’inscription de 14 jours est la partie qu’on ne peut pas comprimer en étant mieux organisé.
Mener le test fermé vous-même ou nous le confier
Google décide de l’enregistrement des packages, de la vérification d’identité et de l’accès en production. Aucun des trois n’est quelque chose que nous faisons à votre place. Ce qu’un test géré supprime, c’est le risque de recrutement et de continuité des testeurs, l’étape sur laquelle la plupart des premiers éditeurs calent vraiment. Taux de réussite sur 7 400+ applications testées: 99,9%, dans 120+ pays.
Trois plans, un seul paiement
Starter
12 testeurs $19.99 +5% de frais de serviceExactement le minimum Google, pour une seule application à faire passer.
Professional
20 testeurs $29.99 +5% de frais de serviceDe la marge au-dessus du minimum, pour qu’un désistement ne mette pas fin au test.
Enterprise
25 testeurs $27.99 +5% de frais de servicePour une couverture plus large en appareils et en régions sur les 14 jours.
Chaque plan mobilise de vrais testeurs sur de vrais appareils pendant la totalité des 14 jours, le test démarre généralement en 4-6 heures, et si un test ne donne rien vous avez un nouveau test gratuit ou un remboursement intégral. Nous ne promettons pas l’approbation de Google, parce que personne ne le peut.
Questions fréquentes
Mes amis pourront-ils encore installer un APK que je leur envoie par e-mail après le 30 septembre 2026?
Oui, sous les règles actuelles du déploiement initial de Google. L’échéance du 30 septembre au Brésil, en Indonésie, à Singapour et en Thaïlande concerne sept boutiques d’applications participantes, et la FAQ de Google du 15 juillet 2026 dit explicitement que l’installation directe n’est pas encore couverte. L’exigence plus large doit toujours s’étendre au monde entier en 2027: considérez donc cela comme une limite de première phase et non comme une exemption permanente.
Google bloque-t-il toute installation directe au Brésil, en Indonésie, à Singapour et en Thaïlande le 30 septembre?
Non, et c’est la correction la plus importante à apporter aux articles plus anciens. L’application initiale se limite à Google Play, HONOR App Market, OPPO App Market, Samsung Galaxy Store, Transsion Palm Store, vivo V-Appstore et Xiaomi GetApps. L’installation directe et les boutiques absentes de cette liste sont explicitement hors de la première phase. Pour la distribution hors Play, Google précise que l’application dans les régions sélectionnées concerne d’abord les formats mobile et tablette.
Pourrai-je encore installer des APK directement après le déploiement mondial?
Pour une application correctement enregistrée auprès d’un développeur vérifié, Google indique que l’expérience d’installation habituelle des utilisateurs ne devrait pas changer. Pour une application non vérifiée ou non enregistrée, Google a préservé deux parcours: ADB, et un parcours avancé par lequel un utilisateur peut délibérément choisir de l’installer. Google n’a annoncé aucune date mondiale précise pour cette phase élargie, seulement 2027 et au-delà.
Faut-il la vérification des développeurs Android pour utiliser ADB?
Non. Google indique que les développeurs et les utilisateurs avancés peuvent continuer d’utiliser ADB pour installer des applications non vérifiées, et que le délai d’attente de 24 heures du parcours avancé ne s’applique pas à ADB. ADB via USB exige en revanche que les options pour les développeurs et le débogage USB soient activés sur l’appareil: il convient donc bien mieux aux développeurs et aux testeurs techniques qu’aux utilisateurs occasionnels.
Le parcours avancé impose-t-il d’attendre 24 heures pour chaque APK?
Non. Google décrit le délai de 24 heures comme faisant partie de la configuration unique du parcours avancé. Une fois cette configuration terminée, l’utilisateur peut autoriser l’installation d’applications de développeurs non vérifiés pendant sept jours ou indéfiniment. Google décrit aussi cette configuration comme unique par compte, et elle est conservée sur un nouvel appareil.
Android va-t-il supprimer une application non vérifiée déjà installée?
La documentation de Google consultée ne dit pas que les copies existantes seront désinstallées automatiquement ni empêchées de se lancer. Elle dit en revanche qu’une fois l’application des règles active, une application non enregistrée ne peut pas être installée ni mise à jour normalement sans le parcours avancé ou ADB, et qu’une mise à jour ordinaire échouera. La façon exacte de décrire cela est de parler de restrictions d’installation et de mise à jour, pas de suppression.
Firebase App Distribution permet-il de contourner la vérification des développeurs?
Non. Firebase est un service de distribution de builds de test, et enregistrer une application dans Firebase n’est pas la même chose que la vérification des développeurs Android, qui relie un développeur vérifié à des noms de package et à des clés de signature. La distribution d’APK par Firebase devrait rester hors de l’application initiale de septembre en boutique, parce que la FAQ de Google dit que l’installation directe n’est pas encore couverte, mais c’est une déduction tirée de la règle sur l’installation directe et non une exemption propre à Firebase: préparez malgré tout l’enregistrement de vos packages pour le déploiement de 2027.
Les testeurs Firebase App Distribution comptent-ils pour l’exigence de 12 testeurs de Google?
Non. Google exige des comptes concernés au moins 12 testeurs inscrits à un test fermé Google Play pendant les 14 jours précédents sans interruption avant de demander l’accès en production. Firebase App Distribution est utile pour trouver des bugs, mais ces testeurs ne sont pas inscrits à un canal de test fermé Play et ne satisfont pas cette exigence.
Le test interne Play compte-t-il pour les 12 testeurs?
Non, le test interne ne remplace pas le test fermé exigé. Google autorise jusqu’à 100 testeurs sur un test interne, mais l’exigence d’accès en production dit précisément que les testeurs pris en compte doivent avoir été inscrits à un test fermé pendant 14 jours sans interruption. Le test interne reste utile pour une assurance qualité rapide, en parallèle du test fermé.
J’ai déjà vérifié mon identité. Tout APK que je compile est-il automatiquement en règle?
Ne partez pas de ce principe. La vérification des développeurs Android implique aussi d’enregistrer le nom de package et sa ou ses clés de signature, et Google permet d’ajouter et de vérifier plusieurs clés de signature pour un même package. Cela compte surtout lorsque les builds de QA ou de débogage et les builds de version utilisent des certificats de signature différents, un montage tout à fait normal que la seule vérification d’identité ne couvre pas.
La vérification signifie-t-elle que mon APK installé directement doit désormais respecter toutes les règles de Google Play?
La documentation de vérification de Google décrit une confirmation d’identité et un enregistrement de packages, pas une extension de toutes les règles de publication Play à l’ensemble de la distribution directe. Google distingue aussi le fait de vérifier qui est un développeur du contrôle de sécurité appliqué au contenu des applications. Établir une identité n’équivaut pas à approuver ce que vous avez livré: ne traitez donc pas la distribution hors Play comme équivalente à un examen sur le Play Store.
Résumé
Résumé
Au 13 août 2026, vos testeurs peuvent toujours installer un APK brut que vous leur transmettez directement. L’entrée en vigueur du 30 septembre 2026 au Brésil, en Indonésie, à Singapour et en Thaïlande ne s’applique d’abord qu’à sept boutiques d’applications participantes, et la FAQ de Google du 15 juillet indique que les installations directes ne sont pas encore concernées. Google prévoit une application plus large sur les appareils Android 7 et plus certifiés en 2027, sans date mondiale précise annoncée. Une fois cette phase active, les applications enregistrées auprès d’un développeur vérifié conservent le parcours d’installation directe habituel, tandis que les applications non enregistrées restent installables via ADB, qui n’impose aucune attente de 24 heures, ou via le parcours avancé de Google, dont le délai de 24 heures est une étape de configuration unique. Firebase App Distribution reste un excellent canal de QA, mais il n’effectue pas la vérification des développeurs Android, ses parcours APK et AAB se comportent différemment, et ce n’est pas le test fermé Google Play qui exige 12 testeurs inscrits pendant 14 jours sans interruption. Si c’est cette étape de test qui bloque réellement votre lancement, PrimeTestLab fournit 12 testeurs réels à partir de $19.99 plus 5% de frais de service. Voir les plans tarifaires →
Sources primaires utilisées pour cet article
Dernier contrôle des règles: 13 août 2026. La page FAQ de Google sur la vérification des développeurs a été mise à jour le 10 août 2026, la réponse sur le sideload direct qu'elle contient date du 15 juillet 2026, et la documentation Android de Firebase App Distribution a été mise à jour le 11 août 2026. La vérification des développeurs Android est en cours de déploiement actif: la portée du 30 septembre, la liste des boutiques participantes, la disponibilité du parcours avancé et le calendrier 2027 doivent tous être revérifiés sur les pages de Google avant d’agir. Cet article est programmé pour une revérification hebdomadaire jusqu’au 30 septembre 2026, à nouveau le jour de l’entrée en vigueur et environ une semaine après, puis mensuellement jusqu’à ce que Google publie une géographie ou une date concrète pour 2027.