Vérification développeur Android en vigueur : la checklist conformité OEM

Réponse directe — que signifie l’application de la vérification développeur Android pour les jeux distribués sur des stores OEM ? Depuis le 30 septembre 2026, la vérification développeur Android de Google s’applique aux installations depuis sept stores nommément désignés — Google Play, HONOR App Market, OPPO App Market, Samsung Galaxy Store, Transsion Palm Store, vivo V-Appstore et Xiaomi GetApps — pour les utilisateurs au Brésil, en Indonésie, à Singapour et en Thaïlande, sur des appareils Android certifiés sous Android 7 ou supérieur. Si votre identité développeur n’est pas vérifiée et que le nom de votre package n’est pas enregistré, Google indique que votre application ne peut pas être installée depuis ces stores dans ces pays. En dehors de ces quatre pays, et en dehors de ces sept stores, rien ne change pour l’instant — mais Google indique qu’il étendra l’exigence à l’échelle mondiale en 2027.

Cette checklist s’adresse aux studios et éditeurs qui diffusent sur Play et sur un ou plusieurs stores OEM : êtes-vous conforme, que se passe-t-il si vous ne l’êtes pas, et que verrouiller avant que 2027 ne transforme une exigence à quatre pays en exigence mondiale.

Qu’est-ce qui a exactement démarré le 30 septembre 2026 ?

La page de vérification développeur de Google indique qu’au 30 septembre 2026, « Les protections entrent en vigueur pour tous les utilisateurs qui installent des applications depuis les stores participants au Brésil, en Indonésie, à Singapour et en Thaïlande, sur des appareils certifiés sous Android 7+. » La page des guides liste les stores participants : Google (Google Play), Honor (HONOR App Market), OPlus (OPPO App Market), Samsung (Galaxy Store), Transsion (Palm Store), vivo (V-Appstore) et Xiaomi (GetApps). Au 1er octobre, les pages développeurs de Google affichent toujours cette date et cette liste de pays ; nous n’avons trouvé aucune annonce officielle d’un report.

Le mécanisme compte. En juin 2026, Google annonçait « déployer un nouveau service système qui sera automatiquement installé sur la plupart des appareils Android », qui « sera utilisé plus tard dans l’année pour vérifier l’enregistrement des développeurs ». L’application de la règle, c’est l’appareil qui refuse l’installation, pas d’abord un retrait du jeu par le store. Le centre d’aide de Google formule la conséquence ainsi : les applications deviennent « indisponibles pour toute nouvelle installation sur les appareils Android certifiés dans les pays concernés ».

Une incohérence à noter : cette même page du centre d’aide pour l’Android Developer Console ne liste que l’Indonésie, Singapour et la Thaïlande. Les guides de developer.android.com et l’annonce de Google de juin 2026 citent, eux, le Brésil en plus. Retenez la lecture à quatre pays — un plan de conformité bâti sur la liste la plus courte est celui qui échoue.

Trois limites de périmètre comptent tout autant que la règle elle-même :

• Seulement les sept stores participants. La FAQ de Google est explicite : « L’échéance du 30 septembre 2026 ne s’applique qu’aux stores participants spécifiques. Si vous distribuez votre application via d’autres stores, ou si les utilisateurs la sideloadent directement, ces nouvelles exigences de vérification ne s’appliquent pas encore à votre application. »
• Seulement les appareils certifiés sous Android 7 ou supérieur. La FAQ précise que l’exigence « s’appliquera à tous les appareils Android certifiés fonctionnant sous Android 7 ou supérieur ».
• Les applications non vérifiées ne sont pas bannies de la plateforme. Le billet de juin de Google indique que « les applications non enregistrées peuvent être sideloadées via Android Debug Bridge (adb) ou le flux avancé ». Le billet de mars 2026 de Google décrit le flux avancé comme une configuration ponctuelle pour utilisateurs avertis, avec « une attente ponctuelle d’un jour » avant que l’utilisateur puisse confirmer. Pour un titre commercial, ce n’est pas un canal de distribution.

Quels canaux de store OEM sont réellement concernés ?

Pour un éditeur de jeux, la liste dit tout : chaque grand store OEM qu’un studio ajouterait à une fiche Play pour atteindre les joueurs indonésiens, thaïlandais ou brésiliens y figure. Si les stores OEM étaient votre route « facile » sur ces marchés, cette route passe désormais par le même contrôle d’identité que Play.

Les stores indépendants plus modestes, les vitrines d’agrégateurs et les APK en direct ne sont pas couverts « pour l’instant », selon la FAQ de Google — une fenêtre temporaire, pas une stratégie. L’annonce de juin de Google indique : « nous étendrons ces protections à l’échelle mondiale pour toutes les applications sur les appareils Android certifiés en 2027 ».

Quels stores OEM prioriser commercialement est traité dans notre comparatif Galaxy Store, GetApps et AppGallery ; cet article couvre la couche conformité sous-jacente. Positionner un titre précis face à ces canaux et piloter les opérations store par store, c’est le rôle de notre offre de distribution.

Suis-je déjà conforme ? Tout dépend de votre mode de diffusion

Les guides de Google décrivent trois parcours, selon votre empreinte de distribution.

Votre configuration	Où vérifier	Ce que dit Google
Google Play uniquement	Play Console	Les noms de package créés dans Play Console sont enregistrés automatiquement. « Pour la plupart des développeurs Play, aucune action supplémentaire n’est requise pour la vérification d’identité. »
Google Play plus stores OEM	Play Console	Play Console peut être « l’endroit unique pour gérer toutes leurs exigences de vérification, y compris pour leurs applications distribuées en dehors de Play ».
Stores OEM uniquement, pas de fiche Play	Android Developer Console	« Si vous distribuez des applications uniquement en dehors de Google Play, utilisez l’Android Developer Console pour gérer votre identité développeur et enregistrer les noms de package de votre application. »

Les studios Play-first sont dans l’ensemble couverts — mais vérifiez, ne présumez pas. Le guide Play Console de Google indique que « 99 % des applications sur Play ont été enregistrées automatiquement » et invite les développeurs à vérifier leur page d’accueil Play Console. Les applications utilisant Play App Signing font partie de l’enregistrement automatique. Le risque résiduel se situe dans les cas particuliers : titres absents de Play, noms de package hérités, et builds OEM signés différemment de votre build Play.

Les éditeurs OEM-only ont un vrai travail à fournir. Si vous diffusez un titre exclusivement via Galaxy Store, GetApps ou un autre canal OEM, vous avez besoin d’un compte de distribution complète sur l’Android Developer Console. La FAQ de Google précise que « les 25 $ de frais pour le compte Full Distribution de l’ADC contribuent à couvrir les coûts administratifs », un montant comparable aux 25 $ de frais d’inscription de Play.

Les builds de prototype et de test ont une voie gratuite. Le compte de distribution limitée permet de « partager des applications avec jusqu’à 20 appareils spécifiques pour des tests et un usage personnel, sans frais et sans vérification d’identité ». Utile pour des playtests sur du matériel OEM, pas pour un lancement.

La checklist de conformité post-échéance

À appliquer titre par titre et store par store. L’échec typique, c’est un build, sur un store, signé avec une clé que personne n’a enregistrée.

1. Confirmez que votre identité développeur est vérifiée sur la bonne console. Développeurs Play : Play Console. Éditeurs exclusivement hors Play : Android Developer Console, compte de distribution complète. Les organisations ont besoin d’un numéro D-U-N-S — Google le décrit comme « un identifiant unique à 9 chiffres pour votre organisation, fourni par Dun & Bradstreet » — plus un site web vérifié via Google Search Console et des documents officiels de l’organisation. Les particuliers soumettent une pièce d’identité officielle avec photo et un justificatif de domicile. Google indique que le processus « prend généralement environ 10 minutes si vous disposez de toutes les informations requises » — le vrai frein, ce sont les documents.
2. Recensez chaque nom de package que vous diffusez, sur chaque store. Incluez les variantes régionales, les builds spécifiques OEM et les titres hérités qui ne sont plus sur Play. Tout ce qui n’est pas sur Play n’est pas couvert par l’enregistrement automatique de Play.
3. Recensez chaque clé de signature derrière ces packages. Un studio qui utilise Play App Signing sur Play mais signe lui-même l’APK qu’il upload sur GetApps ou Palm Store diffuse le même nom de package sous deux clés. La FAQ de Google indique que l’Android Developer Console « permet d’ajouter et de vérifier plusieurs clés de signature pour un même package » — enregistrez donc chaque clé que vous utilisez réellement.
4. Enregistrez les packages manquants. Dans l’Android Developer Console, vous saisissez le nom du package, ajoutez l’empreinte de certificat SHA-256 de votre clé de signature, et, pour un nom de package existant, prouvez la propriété en uploadant un APK signé avec votre clé privée. Les développeurs Play font l’équivalent depuis Play Console.
5. Vérifiez le statut, ne le supposez pas. Google liste trois endroits où consulter le statut d’enregistrement : la page de vérification développeur Android dans Play Console, l’onglet Noms de package dans l’Android Developer Console, et Android Studio lors de la génération d’un App Bundle ou APK signé (Android Studio Panda 4 et supérieur).
6. Sécurisez vos clés. La FAQ de Google est sans détour : « Si vous perdez votre clé de signature, vous ne pourrez plus enregistrer vos packages. »
7. Surveillez les conflits de noms de package. Lorsqu’un nom de package est déjà utilisé, Google peut vous indiquer que votre clé n’est « pas éligible pour le revendiquer d’emblée » et suggérer un nom de package différent ; demander quand même ce nom déclenche une revue supplémentaire.

Ce qu’on ne sait pas encore — et ce qu’il faut demander à vos partenaires OEM

Google documente le contrôle côté appareil, pas côté store. Les pages que nous avons examinées ne précisent pas :

• si les stores OEM participants masqueront ou retireront les applications non vérifiées dans les quatre pays, ou laisseront simplement l’installation échouer sur l’appareil ;
• comment sont traitées les mises à jour de copies déjà installées avant le 30 septembre — le centre d’aide ne parle que de « nouvelle installation » ;
• comment le contrôle de Google s’articule avec l’onboarding développeur propre à chaque store. Le Palm Store de Transsion, par exemple, exige déjà sa propre vérification d’identité réelle des développeurs ; rien dans la documentation de Google ne suggère que l’un remplace l’autre.

Si vous avez des titres actifs sur ces stores en Asie du Sud-Est ou au Brésil et plus largement en LATAM, demandez par écrit à votre partner manager de chaque store OEM comment les fiches non vérifiées sont traitées en interne depuis le 30 septembre, et s’ils remontent les installations échouées. Si vous distribuez via Palm Store principalement pour l’Afrique, notez qu’aucun pays africain ne figure dans cette première vague — jusqu’en 2027.

Ce qu’il faut surveiller avant le déploiement mondial de 2027

Google n’a publié aucune date précise pour 2027 sur les pages que nous avons examinées. Deux conséquences pratiques :

• Votre périmètre de conformité passe de sept stores à toute la distribution. Aujourd’hui, les stores plus modestes et les APK en direct sont hors périmètre. En 2027, Google indique que l’exigence couvrira toutes les applications sur appareils certifiés. Enregistrez dès maintenant les builds hors store — APK de web-shop, builds hébergés par des partenaires, vitrines d’agrégateurs — pendant qu’une erreur ne coûte que quatre pays, pas tous.
• Prévoyez de l’outillage, pas un nettoyage ponctuel. La feuille de route de juin 2026 de Google programmait l’Android Developer ID Status API, qui vérifie si un nom de package est enregistré, pour juillet 2026, et l’Android Developer Console API, qui enregistre et gère les noms de package depuis votre environnement de développement, pour un lancement mondial en août 2026. Si vous diffusez de nombreux builds sur de nombreux stores, intégrez ce contrôle de statut à votre processus de release.

FAQ

La vérification développeur Android s’applique-t-elle aux applications distribuées en dehors de Google Play ?

Oui, mais par étapes. Depuis le 30 septembre 2026, elle s’applique aux installations depuis sept stores participants — Google Play, HONOR App Market, OPPO App Market, Samsung Galaxy Store, Transsion Palm Store, vivo V-Appstore et Xiaomi GetApps — pour les utilisateurs au Brésil, en Indonésie, à Singapour et en Thaïlande. La FAQ de Google précise que pour les autres stores ou le sideload direct, les exigences « ne s’appliquent pas encore à votre application ». Google indique qu’il étendra la vérification à l’échelle mondiale pour toutes les applications sur appareils Android certifiés en 2027.

Que se passe-t-il pour une application non vérifiée sur un store OEM dans les quatre pays de la première vague ?

Google indique que les applications des développeurs qui n’ont pas effectué la vérification et l’enregistrement « deviendront indisponibles pour toute nouvelle installation sur les appareils Android certifiés dans les pays concernés » lors d’une installation depuis les stores participants. Les utilisateurs peuvent toujours installer des applications non enregistrées via adb ou le flux avancé d’Android, une configuration ponctuelle pour utilisateurs avertis avec une attente d’un jour. Les pages de Google ne précisent pas si les stores OEM retireront également ces applications ; vérifiez donc auprès de chaque store.

Ai-je besoin de l’Android Developer Console si je publie déjà sur Google Play ?

Généralement non. Google indique que la plupart des développeurs Play n’ont besoin d’aucune nouvelle vérification d’identité, et que Play Console peut aussi gérer la vérification pour les applications distribuées hors de Play. L’Android Developer Console s’adresse aux développeurs qui distribuent uniquement en dehors de Google Play ; son compte de distribution complète coûte 25 $. Les étudiants et amateurs peuvent utiliser un compte de distribution limitée gratuit, couvrant jusqu’à 20 appareils.

Y a-t-il une échéance après le 30 septembre 2026 ?

Google a annoncé une extension mondiale en 2027, mais n’a publié aucune date précise pour 2027 sur ses pages de vérification développeur. La phase à quatre pays est déjà en vigueur : finalisez dès maintenant l’enregistrement des titres exclusivement OEM, des packages hérités et des clés de signature alternatives.

---

La vérification développeur réduit la distribution OEM à une identité et un registre de packages uniques, dont dépend chaque canal. Bien faire les choses sur Play, Galaxy Store, GetApps, Palm Store et le reste — avant que 2027 ne rende cela mondial — c’est exactement le travail d’opérations canal que notre Founding Developer Program retire des épaules d’un studio.