Google déploie en août la nouvelle étape de sa vérification des développeurs Android : comptes de distribution limitée, API Android Developer Console et parcours avancé pour installer une application provenant d’un développeur non vérifié. Le système prépare les premières obligations du 30 septembre 2026, avant une extension mondiale annoncée pour 2027.

Le changement ne supprime pas le sideloading et ne transforme pas immédiatement Android en magasin unique. Il relie progressivement les noms de paquets à une identité enregistrée, y compris pour certaines applications distribuées hors de Google Play. Pour les équipes, l’enjeu devient opérationnel : inventorier les applications, protéger les clés de signature et intégrer l’enregistrement aux chaînes CI/CD.

La réponse rapide

QuestionRéponse
Android interdit-il le sideloading ?Non. ADB reste disponible et un parcours avancé permet aux utilisateurs avertis d’installer depuis un développeur non vérifié.
Qui est concerné en premier ?À partir du 30 septembre, certaines boutiques dans quatre pays : Brésil, Indonésie, Singapour et Thaïlande.
La France est-elle concernée maintenant ?Pas par cette première obligation, mais Google annonce une extension mondiale en 2027.
Faut-il être présent sur Google Play ?Non. L’Android Developer Console vise aussi les développeurs qui distribuent ailleurs.
Un étudiant doit-il fournir une pièce d’identité ?Le compte de distribution limitée permet de partager avec jusqu’à 20 appareils, sans frais ni pièce d’identité gouvernementale.
Qu’apporte l’API ?Elle permet de vérifier et gérer l’enregistrement des noms de paquets depuis les outils et pipelines.

Ce qui est réellement lancé en août

Le premier élément est le compte de distribution limitée dans Android Developer Console. Il cible les étudiants, amateurs et personnes en apprentissage qui veulent partager une application avec un petit groupe. Google fixe la limite à 20 appareils identifiés, sans frais et sans document d’identité gouvernemental.

Ce compte ne remplace pas une distribution publique. Il répond plutôt au cas d’une application personnelle, d’un projet scolaire ou d’un prototype partagé avec quelques testeurs. Une application destinée à un public ouvert, à une entreprise ou à un grand parc d’appareils devra suivre le parcours complet.

Le deuxième élément est l’Android Developer Console API. Elle doit permettre d’enregistrer et gérer des noms de paquets sans effectuer chaque action manuellement dans une interface Web. Pour une organisation possédant plusieurs applications, variantes ou marques blanches, cette automatisation évite que la conformité dépende d’une personne et d’une liste tenue à la main.

Enfin, Android introduit un parcours avancé pour les utilisateurs qui veulent installer une application provenant d’un développeur non vérifié. Google annonce des contrôles destinés à résister aux arnaques sous contrainte, par exemple lorsqu’un fraudeur guide sa victime au téléphone. Le parcours ajoute donc de la friction sans supprimer la possibilité technique.

Le calendrier ne concerne pas encore toute la planète

Le 30 septembre 2026, l’enregistrement devient obligatoire dans sept boutiques participantes pour les utilisateurs du Brésil, d’Indonésie, de Singapour et de Thaïlande. La liste comprend Google Play ainsi que les boutiques de Samsung, Xiaomi, Oppo, Honor, vivo et Transsion citées par Google.

Cette première échéance ne bloque pas toutes les installations directes dans ces pays. La FAQ précise que les applications distribuées depuis une boutique non participante ou installées directement ne sont pas soumises à cette phase initiale. ADB et le parcours avancé restent également des solutions prévues.

Google annonce toutefois une extension mondiale sur les appareils Android certifiés à partir de 2027. Le mécanisme s’appliquera aux appareils sous Android 7 ou version ultérieure grâce à des composants distribués via les services Google Play. Une application ancienne peut donc être concernée même si elle n’a jamais ciblé la dernière version du système.

Pourquoi Google veut connaître l’identité du développeur

Les logiciels malveillants distribués hors des boutiques officielles utilisent souvent plusieurs comptes et noms de paquets. Lorsqu’une identité est bloquée, l’opérateur réapparaît sous une autre identité. Relier les paquets à un développeur vérifié vise à augmenter le coût de cette rotation et à rendre les sanctions plus persistantes.

La vérification ne prouve pas qu’une application est sûre. Une entreprise identifiable peut livrer une version vulnérable, subir un vol de clé ou intégrer une dépendance compromise. Le mécanisme fournit une information sur l’éditeur déclaré ; il ne remplace ni l’analyse du code, ni la réputation, ni les protections de l’appareil.

Il faut aussi distinguer identité et signature. La signature cryptographique permet à Android de vérifier qu’une mise à jour provient du détenteur de la même clé. L’enregistrement ajoute une relation administrative entre cette application, son nom de paquet et un compte développeur. Si les clés sont mal gérées, l’identité vérifiée ne répare pas la chaîne de confiance.

Ce que les équipes doivent inventorier maintenant

Une organisation devrait commencer par lister tous les noms de paquets encore installés : production, bêta, applications internes, variantes régionales, outils de diagnostic et anciens produits maintenus pour quelques clients. Il faut associer chaque paquet à un propriétaire, une méthode de distribution, une clé de signature et un statut d’enregistrement.

Les applications en marque blanche demandent une attention particulière. Une même base de code peut produire des dizaines de paquets pour différents clients. L’équipe doit déterminer qui porte l’identité de distribution et qui conservera l’accès au compte si le contrat ou le prestataire change.

Les applications internes installées par MDM ne doivent pas être supposées hors périmètre sans vérification. Le calendrier initial est limité, mais le déploiement 2027 et les modalités propres aux systèmes de gestion d’entreprise doivent être suivis. Une preuve de concept réalisée avant l’échéance évite de découvrir un blocage lors d’un renouvellement de flotte.

Intégrer l’enregistrement au CI/CD sans exposer les clés

L’API Android Developer Console ouvre la voie à une gestion automatisée des paquets. Elle ne doit cependant pas conduire à placer un compte personnel ou un secret permanent dans toutes les pipelines. Le principe du moindre privilège reste applicable : identité technique dédiée, jetons courts lorsque possible, environnement protégé et journaux d’audit.

L’enregistrement d’un nouveau paquet devrait devenir une étape gouvernée, distincte de chaque compilation. Une pipeline peut vérifier que le paquet existe déjà et échouer proprement lorsqu’il manque, tandis qu’un workflow approuvé réalise la création. Cette séparation évite qu’une branche ou une contribution externe puisse enregistrer des noms arbitraires.

Les secrets de signature Android restent plus sensibles encore. Ils ne doivent pas être envoyés à l’API ni confondus avec les identifiants de console. Une architecture mature sépare la compilation, la signature, l’enregistrement administratif et la publication, avec des droits et des traces différents.

Les développeurs indépendants conservent plusieurs chemins

Un développeur qui publie sur Google Play est généralement déjà vérifié et Google indique que plus de 99 % des applications Play sont enregistrées. Il faut néanmoins consulter l’état dans Play Console, notamment pour les paquets anciens ou distribués par plusieurs canaux.

Une personne qui distribue uniquement un APK depuis son site peut utiliser Android Developer Console sans rejoindre Google Play. Le compte complet est annoncé à 25 dollars, tandis que le compte limité reste gratuit. Ce choix dépend de l’audience : 20 appareils nommés pour un projet privé, ou distribution publique avec identité vérifiée.

Les utilisateurs expérimentés conservent ADB et le parcours avancé. Mais ce parcours est volontairement plus difficile, car les fraudeurs demandent précisément aux victimes d’ignorer les avertissements. Android essaie donc de préserver l’ouverture pour ceux qui comprennent le risque sans laisser un simple bouton facilement dicté par un escroc.

Une protection utile, mais un pouvoir à surveiller

La vérification peut réduire la capacité d’un opérateur malveillant à changer d’identité en boucle. Elle peut aussi centraliser un pouvoir important sur la distribution d’applications. Les procédures de recours, les erreurs d’identité, la disponibilité dans tous les pays et le traitement des projets libres devront être observés pendant le déploiement.

Pour les entreprises comme pour les indépendants, attendre 2027 serait une mauvaise stratégie. L’inventaire des paquets et des signatures prend du temps, surtout après plusieurs changements d’équipe. Le bon objectif pour 2026 est de savoir qui possède chaque application, comment elle est signée et par quel chemin elle sera enregistrée, tout en conservant une voie documentée pour les tests et distributions privées.