Une première en 13 ans : de nouvelles API sans code source
Android s’est longtemps proclamé l’un des plus vastes projets open source de la planète. Pourtant, le 15 septembre 2026, la publication d’Android 17 QPR1 (Quarterly Platform Release 1) a marqué un tournant inédit depuis 2012 : l’introduction de nouvelles API destinées aux développeurs sans la moindre mise à disposition du code source correspondant au sein d’AOSP (Android Open Source Project). Ces nouvelles interfaces ne fonctionnent pour l’heure que sur les smartphones Pixel de Google, laissant les constructeurs tiers comme Samsung, Xiaomi ou OPPO dans l’impossibilité totale d’y accéder.
La dernière occurrence d’une telle pratique remonte à Android 3.x Honeycomb — cette déclinaison exclusivement réservée aux tablettes dont le code source n’a jamais été formellement ouvert. Après l’épisode Honeycomb, Google a passé plus d’une décennie à démontrer au monde qu’Android était résolument open source. Avec Android 17, la firme de Mountain View vient d’assortir cette promesse historique d’un astérisque bien visible.
GrapheneOS sonne l’alarme
Le 16 septembre, GrapheneOS — le système d’exploitation alternatif axé sur la confidentialité et la sécurité — a dénoncé publiquement cette dérive sur le réseau décentralisé Mastodon, récoltant rapidement 51 partages et 92 mentions « j’aime ». L’équipe de GrapheneOS a révélé un détail particulièrement piquant : ses développeurs avaient déjà finalisé le portage de leur système sur Android 17 QPR1 avant même son lancement officiel le 15 septembre, « sans toutefois obtenir l’autorisation de le publier ».
Figure : Publication officielle de GrapheneOS sur Mastodon dénonçant l’absence du code source d’Android 17 QPR1 sur AOSP. Source : Compte Mastodon de GrapheneOS
En d’autres termes, le code était fin prêt, mais le feu vert de Google n’est jamais venu. GrapheneOS se trouve désormais contraint de procéder à rebours : rétro-porter (backport) les firmwares des Pixel, les pilotes de noyau, les modules de l’espace utilisateur et les couches d’abstraction matérielle (HAL) depuis Android 17 QPR1 vers la branche standard d’Android 17. Pour les autres constructeurs de smartphones, la situation est encore plus délicate : ils devront patienter jusqu’à la mise à jour QPR2 en décembre 2026 pour bénéficier de ces correctifs. Google s’octroie ainsi une fenêtre d’exclusivité fonctionnelle de trois mois pleins au profit de sa gamme Pixel.
Bien que la licence GNU GPL impose légalement à Google de distribuer le code source de ses modifications, elle ne dicte en aucun cas la cadence de publication. GrapheneOS avait formellement réclamé le code source de la compilation CD1A.260905.001.A1 dès le 1er septembre, mais n’en a obtenu l’accès que le 17 septembre — soit un délai de 16 jours. La licence stipule certes l’obligation de fournir le code, mais nullement celle de le faire sur-le-champ.
Les correctifs de sécurité pris dans la fenêtre d’exclusivité
Une exclusivité portant sur de simples fonctionnalités pourrait encore se justifier par une politique commerciale offensive. En revanche, appliquer cette même rétention à des correctifs de sécurité franchit une ligne critique.
GrapheneOS a souligné que le bulletin de mise à jour des Pixel de septembre 2026 intègre des correctifs de sécurité supplémentaires pour des composants standard de la plateforme Android partagés avec l’ensemble des appareils tiers. Ces composants présentent rigoureusement les mêmes vulnérabilités sur les terminaux concurrents. Pourtant, ces correctifs n’ont figuré ni dans le bulletin de sécurité Android général de septembre 2026, ni dans les paquets de préversion mis à disposition des partenaires.
Figure : Page des différences entre les niveaux d’API 37 et 37.1 sur le portail officiel Android Developer. Source : developer.android.com
Les déclarations de GrapheneOS ont été sans détours : « Google ne devrait pas faire de rétention sur les correctifs de sécurité du code standard de la plateforme Android vis-à-vis des autres constructeurs, mais c’est pourtant ce qu’ils ont commencé à faire ». Et d’ajouter avec ironie : « Il serait curieux de savoir si les équipes juridiques de Google ont conscience qu’elles offrent aux Pixel plusieurs mois d’accès exclusif à de nouvelles fonctions et à des résolutions de bugs, parmi lesquels figurent d’importants correctifs de sécurité. »
Sur le plan commercial, ce retard offre à la gamme Pixel une avance de trois mois. Mais à l’échelle des utilisateurs, cela signifie que des milliards d’appareils Android non-Pixel à travers le monde restent inutilement exposés à des failles connues pendant quatre-vingt-dix jours supplémentaires. L’ajout de nouvelles fonctions peut attendre ; une faille de sécurité n’attend pas.
La communauté appelle au fork, mais qui supportera la charge d’ingénierie ?
Ces révélations ont déclenché un débat houleux sur Hacker News, accumulant 389 points et 177 commentaires. Le commentaire le plus plébiscité a mis en perspective les récentes initiatives de Google — retards dans l’intégration des correctifs amont, embargos sur le code source, durcissement de l’attestation matérielle — pour aboutir à une conclusion sans appel : « Google regrette tout simplement d’avoir rendu Android open source ». Un autre intervenant s’est montré encore plus radical : un hard fork doit être amorcé immédiatement, sous peine de voir disparaître toute alternative viable.
Néanmoins, les déclarations d’intention se heurtent à la dure réalité de l’ingénierie logicielle. Maintenir un fork indépendant d’Android exigerait de la communauté qu’elle supporte une charge de travail comparable à celle déployée par Google : portage des pilotes matériels, intégration mensuelle des correctifs de sécurité, validation sur la suite de tests de compatibilité (CTS) et maintenance d’un écosystème tentaculaire. Chacun de ces chantiers requiert des investissements financiers et humains colossaux sur la durée. Si l’environnement de bureau Linux n’a pas réussi à remplacer Windows en vingt ans, forker un système mobile de l’envergure d’Android relève d’un défi bien plus vertigineux encore. GrapheneOS a d’ailleurs reconnu que les Pixel sont désormais devenus « nettement plus difficiles à prendre en charge ». L’atout historique majeur des Pixel — leur proximité avec l’AOSP pur qui en faisait les appareils privilégiés des ROMs tierces — est en train de disparaître.
Les licences open source régissent le code, pas le calendrier
Le modèle open source d’Android a toujours reposé sur un postulat historique souvent occulté : Google s’est tourné vers l’open source en 2008 par absolue nécessité, afin d’inciter les constructeurs de matériel à l’aider à conquérir le marché. Samsung, Huawei et Xiaomi ont permis d’installer Android sur plus de 70 % des smartphones à l’échelle mondiale. Une fois cette hégémonie solidement assise, l’open source est passé du statut de principe intangible à celui de levier de négociation opportuniste. Android 17 QPR1 en est l’illustration la plus éclatante : les nouveautés logicielles et les correctifs de sécurité sont d’abord réservés aux Pixel pendant trois mois.
Pour l’écosystème en aval, il ne reste dès lors que trois options : les constructeurs attendent patiemment la mise à jour QPR2 de décembre ; des projets comme GrapheneOS s’échinent dans une rétro-ingénierie titanesque ; ou les utilisateurs finissent par acheter un Pixel. Ces trois chemins mènent au même dénouement : Google reste le seul maître des horloges. Les licences open source garantissent que le code finira tôt ou tard par être rendu public. Mais les trois mois glissés au cœur de ce « tôt ou tard » suffisent amplement aux Pixel pour creuser un écart décisif sur le terrain des fonctionnalités, de la sécurité et du marché.
Liens de référence :
- Publication de GrapheneOS sur Mastodon
- Discussion sur Hacker News
- Page des différences d’API sur le portail Android Developer
- Bulletin de sécurité Android (septembre 2026)
