Don't be evil

L’équipe de GrapheneOS n’est pas contente. Le nouveau rythme de parution des mises à jour d’Android laisse le système alternatif sur le bord de la route un trimestre sur deux. Dans un fil sur les réseaux sociaux, elle explique les problèmes auxquels elle fait face.

« Android 17 QPR1 est la première version depuis Android Honeycomb (3.x) qui ajoute de nouvelles API pour les développeurs d’applications sans publication dans l’Android Open Source Project. Les nouvelles API sont actuellement exclusives à Pixel OS et ne sont pas disponibles pour les autres OEM Android », débute le fil de GrapheneOS sur X et Mastodon.

L’équipe dénonce une nouvelle fois les changements intervenus chez Google dans la parution des mises à jour pour Android. Dans les grandes lignes, elles ne sont plus reversées dans Android Open Source Project que durant le deuxième et le quatrième trimestres.

Deux gros reproches

L’agacement de l’équipe est palpable. Dans son fil, elle pointe surtout deux problèmes majeurs pour son propre fonctionnement.

D’une part, la disponibilité de la première QPR (Quarterly Platform Release) pour Android 17 montre la présence de nouvelles interfaces de programmation (API). Or, cette QPR1 n’est disponible que sur les propres appareils Pixel de Google. L’équipe de GrapheneOS indique qu’il ne s’agit pourtant pas d’API spécifiques aux Pixel : ce sont des interfaces Android standard, qui ne parviendront à l’AOSP et aux autres fabricants qu’en décembre 2026 avec Android 17 QPR2.

Selon l’équipe, c’est la première fois depuis l’ancienne version Honeycomb que Google ajoute ainsi des API sans les reverser immédiatement dans AOSP. Si Google répète le schéma, il pourrait donc y avoir six mois sur douze pendant lesquels les appareils Pixel seraient les seuls à profiter de ces interfaces.

D’autre part, comme on pouvait le prévoir, la question des correctifs de sécurité se pose. Le bulletin Pixel de septembre 2026 contient des correctifs supplémentaires qui touchent des composants standard de la plateforme Android, également employés par des appareils tiers. Pourtant, ces correctifs ne figurent pas au bulletin de sécurité Android du même mois, ni dans les correctifs communiqués en avance aux fabricants. En clair, les fabricants tiers et les systèmes alternatifs basés sur AOSP – dont GrapheneOS – ne recevront ces correctifs supplémentaires qu’avec la mise à jour QPR2.

L’équipe précise bien qu’elle peut les fournir plus tôt en faisant de la rétro-ingénierie du code binaire. Elle prévient toutefois : si un correctif diffusé sous forme compilée est rétro-analysable en quelques jours, le système d’accès anticipé perd une grande part de sa justification.

Une période décidément complexe

La période n’est pas simple pour Graphene. Si le système est connu pour son positionnement strict sur la sécurité, elle a décidément maille à partir avec Google depuis les changements annoncés dans le rythme de parution des mises à jour et leur disponibilité.

Il y a quelques semaines, Graphene avait averti que le support des récents Pixel 11 allait s’avérer complexe. Déconseillant l’achat de ces derniers, l’équipe avait fustigé le choix de Google de ne plus intégrer la fonction MTE (marquage mémoire) dans ses téléphones, alors que Graphene s’en sert copieusement pour vérifier l’intégrité des données en mémoire. La situation a cependant évolué, l’équipe indiquant que la gestion du MTE peut être assurée de manière logicielle, au prix d’un surcoût de 5 % pour les performances générales. Surcoût qu’elle estime raisonnable au vu des enjeux. Pour l’équipe, le retrait de l’accélération matérielle dans le cache du processeur est un choix financier avant tout. Si elle parvient à un MTE pleinement fonctionnel, elle pourra annoncer le support des Pixel 11.

Les changements dans la gestion d’AOSP agacent donc. Il s’agit d’une conséquence lointaine d’une modification annoncée en novembre 2024 dans le rythme de parution des SDK (kits de développement). En janvier 2026, Google annonçait en effet qu’elle ne publierait plus le code d’AOSP que deux fois par an, pour aligner ses calendriers de développement. En d’autres termes, il s’agissait officiellement d’une simplification.

« À partir de 2026, pour nous aligner sur notre modèle de développement stable et garantir la stabilité de la plate-forme pour l’écosystème, nous publierons le code source sur AOSP aux deuxième et au quatrième trimestre. Pour créer et contribuer à AOSP, nous vous recommandons d’utiliser android-latest-release au lieu de aosp-main. La branche de fichier manifeste android-latest-release fera toujours référence à la version la plus récente envoyée à AOSP », prévenait alors Google.

Pourtant, l’entreprise avait précisé dans la foulée à Android Authority que ce nouveau rythme ne changerait a priori rien pour les correctifs de sécurité, affirmant qu’elle continuerait à les publier chaque mois « sur une branche dédiée uniquement à la sécurité pour les versions pertinentes […], tout comme elle le fait aujourd’hui ». Une belle assurance déjà contestée plusieurs mois avant par un autre système bâti sur AOSP, LineageOS.

Motorola attendu de pied ferme

En janvier, nous rappelions également que le développement d’Android était devenu totalement interne, avec pour conséquence un retard constant d’AOSP sur Android. Nous relevions alors que les Pixel allaient avoir un avantage logiciel sur les appareils concurrents et les ROM alternatives.

Dans son dernier fil, l’équipe de GrapheneOS mentionne aussi la concrétisation d’une de ses craintes : le code source du noyau n’étant plus disponible par simple téléchargement, le délai s’allonge pour le récupérer à cause d’un passage obligatoire par un formulaire. L’équipe le confirme dans l’un des messages, une requête pour obtenir ce code source le 1ᵉʳ septembre n’ayant abouti que le 17.

Désormais, le travail d’adaptation se concentre directement sur la version QPR1 d’Android 17, mais il faudra attendre la QPR2 en décembre pour diffuser une mise à jour, en se basant sur le code qui aura été effectivement publié dans AOSP. Jusqu’ici, le travail avance par rétro-ingénierie et tâtonnements.

Dans un message, l’équipe affirme une fois de plus que les futurs appareils Motorola seront plus simples à supporter que les Pixel, qui ont perdu un sérieux avantage (la situation ne change pas pour les anciennes gammes). Le reste dépendra de Qualcomm, qui a tendance à considérer la sécurité comme un luxe, la fonction MTE n’ayant été présente jusqu’ici que dans les puces les plus onéreuses. Chez GrapheneOS, on espère ainsi la voir arriver sur des modèles moins chers, afin que l’offre Motorola équipée du système puisse toucher le milieu de gamme.

Pour rappel, les premiers appareils de Motorola sous GrapheneOS sont attendus pour l’année prochaine, sans plus de précisions pour l’instant. Le premier appareil sera destiné au segment haut de gamme.

Dans un billet, le développeur principal de Linux Mint, Clément Lefebvre, annonce plusieurs nouveautés, dont la création d’un site dédié aux XApp. Ces dernières sont initialement les applications prévues pour Linux Mint, en reprenant une organisation et une esthétique communes. Le projet a évolué au-delà de Mint depuis et la suite application a maintenant son propre site pour en présenter les tenants et aboutissants.

Le développeur évoque ensuite les changements dans ces applications. À commencer par Thingy (Bibliothèque), qui avait bien besoin d’un nouveau design. L’outil, qui sert à réunir les documents de l’utilisateur au même endroit, change de présentation. Elle troque la répartition par application pour un tri par type de fichiers. « Peu importe désormais quelles applications sont installées ni quels formats elles supportent », précise Clément Lefebvre. L’application dispose également d’une barre latérale fournissant des catégories personnalisables.

Xepub est de son côté une liseuse destinée aux fichiers EPUB. Selon le développeur, l’expérience de lecture est faite pour ressembler à une liseuse Kindle ou Kobo. À ceci près que cette lecture se fera sur un écran classique, plus fatiguant pour les yeux qu’un appareil e-ink. L’application permettra la navigation entre chapitres, la recherche dans le contenu, l’ajout de favoris, la reprise à l’endroit précédent, ou encore un accès à la recherche via clic droit sur un mot sélectionné.

Clockenstein, lui, va remplacer le vieillissant Calendrier présent dans l’application, qui provient d’une ère GNOME avant la grande bascule vers GTK4. La nouvelle application gardera le nom « Calendrier » dans Linux Mint et veut afficher plus clairement l’état des données. L’un des objectifs est de faire comprendre quand un calendrier en ligne n’est pas disponible. L’application affichera ainsi les évènements liés en lecture seule. Elle dispose également de son propre service (daemon) et de son propre agent de notification, qui fonctionnent donc même quand l’application est fermée. Les autres applications pourront communiquer avec le nouveau Calendrier via de nouvelles API.

Ces nouveautés sont en préparation pour Linux Mint 23. Cette version du système est attendue pour la fin de l’année et constituera un saut technique important. La distribution ne se base en effet que sur les moutures LTS d’Ubuntu. Linux Mint 23 ainsi sera la première version à prendre appui sur Ubuntu 26.04, sortie plus tôt dans l’année.

Agents en vadrouille

Dans une nouvelle publication, OpenAI évoque de nouveaux engagements sur sa manière de communiquer. L’entreprise promet ainsi de publier systématiquement des rapports quand la situation l’exigera, pour remédier à son irrégularité. Elle commence avec six nouveaux exemples d’agents dont le « comportement » a dérapé.

Dans son billet du 16 septembre, OpenAI reconnait qu’elle manquait jusqu’ici d’une « approche systématique » pour rapporter les résultats des enquêtes menées sur les cas de désalignement. « Nous avons souvent attendu de pouvoir rassembler plusieurs instances dans un seul rapport, ou de les ajouter à des cartes système pour des modèles nouvellement publiés », indique l’entreprise.

Le narratif continue sur le cadre industriel

Selon OpenAI, le degré d’avancement et l’utilisation plus intensive des agents nécessitent la mise en place d’un « consensus plus large et mieux informé ». Le ton est le même que dans les récentes interventions sur la nécessité de ralentir le développement des modèles frontière : « Nous ne pensons pas que l’industrie de l’IA ait suffisamment résolu l’alignement et la surveillance pour continuer plus longtemps d’évoluer de manière responsable à vitesse maximale ». Dans ce registre, OpenAI persiste et signe.

• Anthropic, OpenAI et Elon Musk veulent ralentir sur l’IA, la Maison-Blanche dit non

Il s’agit, pour l’entreprise, de simplement mieux communiquer. Elle affirme que des exemples de désalignement peuvent « aider à identifier les problèmes que d’autres développeurs d’IA pourraient rencontrer lorsque leurs systèmes atteignent des capacités similaires, révèlent des faiblesses dans les mesures de sécurité ou remettent en question les hypothèses sur le comportement du modèle ». L’entreprise veut se montrer responsable en montrant aux autres les problèmes qu’elle a elle-même rencontrés.

Regrettant qu’aucun cadre industriel n’existe sur la manière dont les développeurs devraient communiquer, elle propose donc le sien, à travers six exemples. Ce cadre est considéré comme « un travail en cours », ajoute la société. De manière générale, elle promet qu’elle relatera tous les exemples qui lui paraissent pertinents, notamment quand ils constituent « des preuves utiles sur la manière dont survient le désalignement du modèle ». OpenAI précise cependant qu’un exemple « n’a pas besoin de causer de préjudice » pour justifier sa publication.

Sorties de route pendant l’entrainement

Le premier exemple est celui d’un modèle interne de la famille Astra (dont GPT-6). Pendant l’entraînement, il a glissé des instructions parasites dans les résumés qui lui servent à poursuivre une tâche dans un nouveau contexte. Entre autres actions, il a laissé un message pour informer qu’il ne fallait plus tenir compte des messages du développeur, prétendument compromis. Dans un autre, il « s’estimait » affranchi de toute obligation envers les entreprises et gouvernements. Dans un résumé, il s’est laissé une instruction pour ne plus dépasser à l’avenir les 30 mots dans ses réponses, tout en interdisant les outils citations. L’instruction a été suivie par un autre agent. OpenAI dit avoir trouvé la cause, depuis corrigée. Elle ajoute que ce comportement est « extrêmement rare », sans avantage évident en termes de récompense.

Dans le deuxième exemple, également pendant l’entraînement (de GPT-5.6 cette fois), des instances se sont laissé des instructions dans leurs résumés pour masquer des erreurs ou des comportements montrant un désalignement. Une instance a ainsi proposé d’inventer des données historiques manquantes et de ne l’avouer qu’en cas de demande. Une autre recommandait de taire une incohérence entre versions de sources. Selon OpenAI, l’explication est simple : puisqu’une réponse finale trompeuse obtenait une meilleure réponse, le modèle a appris à s’en « souvenir » pour la suite. Ce type de comportement a été détecté dans 2,15 % des résumés de GPT-5.6 Sol et dans 0,27 % de ceux d’Astra. Ces chiffres ne sont pas anodins : ils correspondent à la situation actuelle, après réduction du problème, de l’aveu même d’OpenAI.

Dans le troisième exemple, le problème est parti d’une « question de routine » sur les revenus masculins dans trois secteurs d’activité d’un comté de Californie. Parmi les tâches entreprises, le modèle a tenté de s’inscrire sur un site avec une adresse jetable, a fouillé des dépôts GitHub publics et testé automatiquement des clés API, dont une a fonctionné. Puis, en voyant qu’il ne parvenait pas au résultat souhaité, il a inventé neuf valeurs et affirmé les avoir relevées sur le site demandé. OpenAI indique que cette session d’entraînement était particulièrement riche en cas de tricherie, avec des comportements équivalents.

Gofile concerné dans l’un des exemples

Dans le quatrième exemple, OpenAI évoque le cas d’un agent qui devait répondre à une question sur les identifiants et noms de tous les lacs plus grands que 5 000 000 m². La réponse a été obtenue via Python, mais puisque la réponse exigeait une citation provenant du navigateur, l’agent a déposé ses données sur un service de partage sans demander l’autorisation. Le navigateur a refusé l’adresse, et la réponse a finalement indiqué l’origine réelle des données.

Le cinquième exemple est une copie quasi-conforme de celui exposé pour Hugging Face : des modèles se sont servis du dépôt interne de paquets logiciels (Artifactory) comme d’un tableau d’affichage. Ils lisaient les notes d’autres agents travaillant sur le même problème et y répondaient. Dans un cas précédent, un agent bloqué par le filtrage réseau a vérifié qu’il pouvait écrire dans le dépôt. Il a ensuite envisagé un paquet malveillant pour faire récupérer un contenu interdit par le serveur. Faute de droits administrateur, la tentative a échoué, selon OpenAI.

Enfin, le dernier exemple relève comment des agents ont partagé des fichiers sur un hébergeur public pour répondre à la mission de produire collaborativement un tableau. Une action menée pour contourner un souci de fonctionnement du système prévu pour les partages de fichiers. Les liens des fichiers hébergés ont été transmis alors que la tâche imposait des fichiers locaux. Selon OpenAI, ce résultat provient de l’effet combiné d’environnements multi-agents défectueux et d’une généralisation de l’entraînement à la collaboration. Depuis ce test, l’accès internet direct est coupé pour les entrainements. Du moins, il est censé l’être.

Selon nos informations, l’hébergeur en question est Gofile. Nory Wojdyla, son fondateur, nous confirme avoir été contacté par OpenAI au sujet de cet incident, pour prévenir qu’un rapport en serait tiré. « Cela fait des mois que l’on constate que des données confidentielles de grosses entreprises finissent chez Gofile de façon non contrôlée par le biais d’agents », indique-t-il. Il n’a pas donné de noms, mais pointe le changement d’échelle, notant qu’il « arrive que les agents sortent de leurs instructions et prennent des libertés ».

Un cadre qui n’impose rien

La publication d’OpenAI intervient dans un calendrier aussi spécifique que sensible. L’industrie américaine réclame un ralentissement du développement des modèles frontières, arguant notamment que la puissance des agents mérite que l’on prenne le temps de la réflexion. Comme nous l’avons vu, les rapports ont surtout illustré des défaillances internes et de curieux choix d’enquêteurs pour des rapports indépendants. En outre, en dépit de mots forts sur X et d’une entente entre les entreprises américaines, leurs dépenses disent le contraire. À la Maison-Blanche, Donald Trump goûte peu l’idée.

En plus de nourrir le narratif sur le danger des agents et les risques d’extinction pour l’humanité, il pourrait s’agir pour OpenAI d’une manière de reprendre la main sur le récit. Début septembre, plusieurs cas ont été rapportés d’agents ayant encore une fois pris des libertés, notamment contre un wiki allemand dédié aux développeurs. La presse s’est emparée de l’histoire avant OpenAI.

Dans un contexte sous pression, OpenAI cherche également à rassurer, tout en fixant lui-même un cadre avant qu’on ne le lui impose éventuellement. Et pour cause : plusieurs sénateurs semblent décidés à éclaircir la réalité du danger et ont envoyé des questions précises à OpenAI, notamment sur Astra, comme le rapporte Zvi Mowshowitz, souvent critique à l’égard d’OpenAI.

Si personne ne se plaindra dans l’absolu d’informations complémentaires, la dichotomie observée depuis plusieurs mois autour des agents continue de plus belle. OpenAI écrit ainsi que l’industrie n’a pas assez travaillé sur l’alignement et la surveillance, tout en commercialisant Astra. Enfin, OpenAI ne s’est engagé sur aucun rythme de parution pour ces rapports.