Contexte de la décision

En août 2025, Google a annoncé qu'à partir de 2027, chaque développeur d’applications Android devra s’enregistrer auprès d’un service centralisé avant que son logiciel ne puisse être installé sur un appareil. L’obligation s’applique à toutes les applications, y compris celles distribuées hors du Play Store, via F‑Droid ou par partage direct. Le processus d’enregistrement impose le paiement d’une redevance, l’acceptation des conditions d’utilisation, la remise d’une pièce d’identité gouvernementale, la preuve de la clé de signature privée et la déclaration exhaustive des identifiants d’application actuels et futurs. Tout développeur qui ne se conforme pas voit ses applications bloquées silencieusement sur chaque appareil Android du monde, sans possibilité d’opt‑out.

Mécanisme de blocage et flux d’échappement

Le blocage s’appuie sur Google Play Services, un composant propriétaire installé sur la quasi‑totalité des appareils Android. Lors de la mise à jour silencieuse prévue pour 2027, Play Services interroge la base de données centrale de Google pour vérifier la présence d’un enregistrement valide. En l’absence de correspondance, le package manager du système refuse l’installation et désactive les applications déjà présentes. Cette implémentation, indépendante du noyau Android, permet à Google de modifier ou de supprimer le contrôle sans publier de mise à jour du système d’exploitation.

1. Ouvrir Paramètres → À propos du téléphone
2. Taper le numéro de build 7 fois pour activer le mode développeur
3. Confirmer le code PIN
4. Redémarrer l’appareil
5. Attendre 24 heures
6. Revenir dans les paramètres
7. Choisir "Autoriser temporairement" (7 jours) ou "Autoriser indéfiniment"
8. Confirmer la prise de conscience des risques

Ce flux, décrit comme une « porte de sortie », comporte neuf étapes et impose un délai de refroidissement de 24 heures. Il est entièrement géré par Play Services, ce qui signifie que Google peut le restreindre ou le supprimer à tout moment, rendant la sideloading pratiquement inaccessible.

Analyse des impacts techniques et des limites

Sur le plan technique, la mesure introduit un point de contrôle unique au niveau du service cloud, contournant les mécanismes de vérification de signature déjà présents dans Android. La chaîne de confiance traditionnelle repose sur la correspondance entre la signature du package et la clé publique stockée sur l’appareil. En ajoutant une validation serveur, Google crée une dépendance réseau qui peut être désactivée par un pare‑feu ou un appareil sans connexion, mais qui, dans la pratique, reste active sur la plupart des smartphones modernes. Cette architecture augmente la surface d’attaque : une compromission du serveur d’enregistrement pourrait bloquer ou autoriser arbitrairement des applications à grande échelle.

Pour les projets open‑source et les communautés comme F‑Droid, la contrainte d’identification gouvernementale constitue une barrière juridique et logistique. Les développeurs situés dans des régions à faible accès bancaire ou sous des régimes répressifs ne peuvent pas fournir les documents requis, ce qui entraîne la disparition de leurs applications du marché Android. De plus, la capacité de Google à révoquer le flux d’échappement via une mise à jour de Play Services élimine toute forme de contournement technique, contrairement à une solution implémentée au niveau du système d’exploitation qui resterait sous le contrôle de l’utilisateur.

Enfin, la justification de sécurité – « Google Play Protect » – apparaît contradictoire. Play Protect analyse déjà les binaires sans recourir à l’identité du développeur. L’ajout d’une vérification d’identité ne renforce pas la détection de malware, mais introduit un vecteur de censure, car les autorités peuvent contraindre Google à refuser l’enregistrement de certains acteurs. En résumé, la mesure transforme Android d’une plateforme ouverte en un écosystème à contrôle centralisé, avec des implications majeures pour la souveraineté logicielle et la résilience du modèle de distribution d’applications.