Vérification des développeurs Android : ce qui a vraiment commencé le 30 septembre, et qui garde la main

Depuis le 30 septembre 2026, la vérification des développeurs Android s’applique au Brésil, en Indonésie, à Singapour et en Thaïlande, mais sur un périmètre plus étroit que celui annoncé au printemps : seules les applications installées depuis sept boutiques partenaires doivent venir d’un développeur enregistré auprès de Google. Le fichier APK installé directement, ou depuis une boutique comme F-Droid, n’est pas encore concerné. En France, rien ne change avant l’extension mondiale que Google prévoit pour 2027.

Ce qui a réellement démarré le 30 septembre

Au printemps, le calendrier de Google annonçait pour le 30 septembre, dans les quatre pays, que toute application devrait être enregistrée par un développeur vérifié pour être installée ou mise à jour sur un appareil certifié, Play Store ou non (billet du 30 mars 2026). C’est aussi ainsi que la lettre ouverte de F-Droid décrivait la mesure. Le texte que Google applique aujourd’hui est différent. La page officielle du programme, Android developer verification, indique que les protections démarrent pour les utilisateurs qui installent des applications depuis les boutiques participantes, dans les quatre pays cités, sur des appareils certifiés sous Android 7 et plus.

Google a même ajouté une mise au point en tête de son billet du 30 mars 2026, datée du 29 septembre :

« On September 30, 2026, developer verification protections will begin rolling out to participating stores in select regions on certified Android devices. In 2027, we’ll expand this globally. » (Google, Android Developers Blog, note du 29/09/2026)

La FAQ destinée aux développeurs lève l’ambiguïté pour le cas qui intéresse le plus les lecteurs de GadGeek : « If you distribute your app through other stores, or if users sideload your app directly, these new verification requirements won’t apply to your app yet. » Le mot qui compte est « yet » : le report est provisoire.

Les sept boutiques concernées

D’après le billet du 18 juin 2026 signé par Matthew Forsythe, directeur de la gestion produit pour la sécurité des applications Android (Android App Safety) chez Google, la première phase vise :

• Google Play ;
• Galaxy Store (Samsung) ;
• HONOR App Market ;
• OPPO App Market ;
• V-Appstore (vivo) ;
• GetApps (Xiaomi) ;
• Palm Store (Transsion).

Toutes appartiennent à Google ou à des fabricants de téléphones (Samsung, Honor, OPlus, vivo, Xiaomi, Transsion). Aucune boutique indépendante ou communautaire ne figure dans la liste.

Capture de la note du 29/09/2026 en tête du billet « Android developer verification: Rolling out to all developers… » (Android Developers Blog), le 06/10/2026.

Calendrier de la vérification des développeurs Android

Le tableau ci-dessous reprend les étapes publiées par Google sur sa page développeurs et dans ses billets de mars et juin 2026. Les dates ont glissé d’un billet à l’autre : nous indiquons la plus récente.

La ligne 2027 est la plus importante pour un lecteur européen. Selon la page du programme, la vérification sera alors étendue à toutes les applications sur les appareils Android certifiés, ce qui inclut cette fois l’installation directe d’un APK. Google n’a pas publié de date précise pour la France.

Capture du calendrier publié sur la page « Android developer verification » (developer.android.com), le 06/10/2026.

Ce que la vérification des développeurs Android exige, et de qui

La mesure repose sur un registre : chaque développeur prouve son identité, puis déclare ses noms de paquets (l’identifiant technique d’une application, du type org.exemple.appli) et l’empreinte SHA-256 de la clé qui signe ses fichiers. Le téléphone vérifie ensuite qu’une application installée correspond à une entrée de ce registre. Plusieurs statuts coexistent.

Ces conditions proviennent de la FAQ et du billet du 19 mars 2026. Google y affirme que le programme ne collecte aucune information sur le contenu ou les fonctions des applications, seulement l’identité et le lien entre paquets et clés. Plus de 99 % des applications des développeurs Play étaient déjà enregistrées en juin (source : Google, billet du 18 juin 2026).

Le cas des logiciels libres est plus délicat. Certaines plateformes open source signent l’application avec leur propre clé. Le guide de Google pour l’open source prévoit alors que le développeur enregistre l’empreinte de la clé de la plateforme ; pour une application déjà publiée, il doit en plus ajouter un fichier adi-registration.properties dans le dossier assets de son projet et publier une nouvelle version. Le guide précise que l’enregistrement n’est pas obligatoire pour continuer à distribuer sur ces plateformes, mais sans lui, les utilisateurs passeront par le flux avancé. Autrement dit, un projet distribué hors de Google doit passer par une console Google pour rester installable sans détour.

Installer une application non vérifiée : les deux portes qui restent

Google n’interdit pas l’installation d’une application non enregistrée. Il la rend plus lente, à dessein.

Le flux avancé

Décrit dans le billet du 19 mars 2026 et repris dans la FAQ, il se déroule en cinq temps :

1. activer le mode développeur dans les paramètres du téléphone ;
2. confirmer que personne ne vous pousse à le faire ;
3. redémarrer le téléphone et s’authentifier à nouveau ;
4. attendre 24 heures, puis confirmer par empreinte, visage ou code ;
5. installer avec un avertissement, en autorisant les applications non vérifiées pour 7 jours ou sans limite de durée.

Cette procédure ne se fait qu’une fois par appareil, pas pour chaque application. Google la justifie par les arnaques par téléphone, où un escroc guide sa victime pas à pas et compte sur l’urgence : l’attente d’une journée et le redémarrage cassent ce scénario.

ADB

L’outil de débogage Android Debug Bridge reste utilisable pour installer une application non enregistrée depuis un ordinateur relié au téléphone. Google le cite comme voie maintenue dans son billet de juin et dans sa FAQ, qui précise que l’attente de 24 heures ne s’applique pas à ADB. C’est une solution de développeur : elle demande un ordinateur, un câble et l’activation du débogage USB.

Un cas limite mérite d’être connu : selon la même FAQ, une application non enregistrée ne peut être installée ni mise à jour que si le flux avancé est activé ou par ADB. Désactiver le flux avancé fait donc échouer les mises à jour de ces applications.

Qui contrôle ce que votre téléphone a le droit d’installer ?

Sur un téléphone Android certifié, la décision d’installer une application se partageait jusqu’ici entre l’utilisateur, qui cochait « sources inconnues », et le développeur, qui signait son fichier. La vérification des développeurs Android ajoute un troisième acteur permanent : Google, qui tient le registre de référence.

Où vont les données

Côté développeur, l’identité, la pièce officielle ou le numéro D-U-N-S, les noms de paquets et les empreintes de clés sont transmis à Google, groupe américain, par la console Play ou la console Android Developer. Côté téléphone, Google indique que ces mises à jour sont livrées par les services Google Play, et que le service système Android Developer Verifier sert à vérifier si une application est enregistrée. La documentation consultée ne détaille pas les informations que le téléphone échange avec Google au moment d’une installation : c’est la question qui reste ouverte, et qui mérite d’être posée par les autorités de protection des données. Pour comprendre ce qu’implique la juridiction d’un éditeur américain, notre article sur le CLOUD Act fait le point.

Qui décide

Google fixe trois choses : la liste des boutiques « participantes » (sept, toutes de Google ou de fabricants), les conditions pour figurer au registre, et le calendrier. Un développeur qui refuse de transmettre ses papiers à Google n’est pas interdit, mais ses utilisateurs devront passer par le flux avancé à partir de 2027. Une question n’est pas tranchée par la documentation : ce que devient une application libre dont l’auteur a disparu, et que personne ne peut donc enregistrer en son nom. La FAQ indique seulement qu’un développeur qui a perdu sa clé de signature ne pourra pas enregistrer ses paquets. Le 24 février 2026, F-Droid a annoncé signer une lettre ouverte contre le programme, aux côtés notamment de l’Electronic Frontier Foundation, de la Free Software Foundation Europe et de la Software Freedom Conservancy. La boutique y parle d’un verrouillage d’Android et déconseille aux développeurs de s’inscrire.

Comment reprendre la main

• Activer le flux avancé une fois, quand il sera disponible sur votre appareil, si vous installez régulièrement des applications libres. Limite : l’avertissement reste affiché à chaque installation.
• Utiliser un système non certifié par Google : Google limite expressément la mesure aux appareils certifiés, et GrapheneOS, par exemple, indique dans sa documentation ne pas être certifié par Google. Limite : installation technique, liste d’appareils compatibles restreinte, et la même documentation prévient que les applications bancaires vérifient de plus en plus le statut de certification du système. Nous n’avons pas trouvé de documentation sur le comportement de la vérification avec les services Google Play installés en bac à sable sur GrapheneOS.
• Côté développeur, le compte à distribution limitée suffit pour un projet personnel diffusé à 20 appareils au plus, sans pièce d’identité.

Pour une démarche plus large, notre méthode pour réduire sa dépendance aux GAFAM classe les étapes par effort.

Notre lecture : une sécurité défendable, une centralisation à surveiller

L’argument de sécurité n’est pas creux. Les arnaques où une victime installe une application espion sous la dictée d’un faux conseiller sont un problème réel, et le flux avancé est mieux conçu qu’une simple case à cocher : l’attente de 24 heures vise précisément le moment où la victime est sous pression. Google avance aussi que les sources hors Play contiennent plus de 90 fois plus de logiciels malveillants que sa boutique, dans son billet du 30 mars. Ce chiffre vient de Google et n’est pas vérifiable de l’extérieur : il faut le lire comme un argument de l’entreprise, pas comme une mesure indépendante.

Deux limites tiennent pourtant. D’abord, la vérification prouve qui est le développeur, pas que son application est saine : un développeur identifié peut publier un logiciel abusif. Ensuite, le registre donne à une seule entreprise un levier sur la distribution de toutes les applications, y compris celles qui ne passent jamais par ses boutiques. C’est une question de souveraineté technologique plus que de sécurité.

Notre avis, appuyé sur les documents de Google eux-mêmes : le resserrement du 29 septembre montre que le calendrier bouge encore. Pour un utilisateur français, il n’y a rien à faire aujourd’hui. Pour un développeur d’application libre, mieux vaut décider dès maintenant s’il s’enregistre, et documenter le flux avancé pour ses utilisateurs s’il refuse.

Questions fréquentes

Dernière vérification : 06/10/2026