Le projet AluminiumOS n’avance pas comme on aurait pu l’imaginer à un rythme de sénateur, mais à la vitesse d’un bon vieux tracteur Massey Ferguson. Tranquille, pépère avec ce bruit si caractéristique du modèle MF35. Et la version qui traîne dans les canaux de développement, la fameuse 146.0.7639.0_pre1570614 à la date du 21 janvier 2026, vient de lâcher une bombe technique. On n’est plus sur de la simple mise à jour de routine, mais sur une véritable mutation génétique. Google est en train de basculer tout le système vers un noyau Android. C’est le projet AluminiumOS, et cela montre que Google installe sur des bases solides son futur OS.
Si on voit passer de plus en plus d’infos sur AluminiumOS, en supposant que ce soit bien son petit nom final, ce n’est pas par hasard. Google avance ses pions avec une précision chirurgicale. Par petites touches, presque l’air de rien, ils préparent le terrain pour une mutation qui va secouer nos habitudes, et c’est exactement ce qu’on va décortiquer ensemble.
Comme d’habitude, j’ai fait le tri pour vous épargner le mal de crâne : les termes barbares et les fonctions complexes sont traduits en langage humain. Et comme d’habitude, vous trouverez des notes de bas de page. Une question ? Un doute ? Lâchez-vous dans les commentaires ou venez en discuter en direct sur le forum Discord, on est là pour ça.
A retenir :
La version 146 confirme que les bases d’Android ne sont plus seulement une option, mais deviennent la nouvelle structure porteuse de ChromeOS pour unifier l’écosystème Google.
Ce qui se trame réellement dans la machine
En fouillant dans les entrailles de cette version « Canary », on tombe sur des mentions explicites qui ne trompent pas. Le but ? Unifier le mobile et le PC pour que l’IA, Gemini en tête, puisse enfin s’exprimer sans ramer. Ce pivot, prévu pour 2025/2026, n’est pas une simple évolution, c’est une refonte pour rendre les Chromebook aussi agiles que nos smartphones.
Voici comment ça se répercute sur le terrain pour les différentes machines de test :
| Nom de l’Appareil | Carte Mère (Board) | Version Plateforme | État de la Migration |
| Lenovo Flex 5i | Taeko | 16557.0.0 | Staging Actif |
| HP Chromebook Plus 15 | Yaviks | 16557.0.0 | Préparation Noyau |
| ASUS Chromebook Vibe CX55 | Delbin | 16557.0.0 | Intégration Framework |
| ASUS Chromebox 5 | Lisbon | 16557.0.0 | Optimisation Pilote |
| Google Pixelbook | Bard | 16557.0.0 | Noyau Android Staging |
Cette bascule technologique soulève une question : pourquoi abandonner ce qui fonctionnait ? Tout est une question de fluidité. Jusqu’ici, pour faire tourner des applis Android, le système créait une « bulle » isolée (ARCVM). C’était sécurisé, mais ça bouffait une énergie monstre. Avec le noyau Android natif, Google vire cette barrière. Et comme je l’ai déjà expliqué, il s’agit d’intégrer de manière plus importante l’IA Gemini dans les Chromebook.
La face cachée du build : quand le numéro de version fige
Faut pas se faire avoir par l’étiquette. Sur les versions suffixées _pre, il arrive que le numéro du navigateur (ex: 146.0.7639.0) reste fixe alors que dessous, c’est le chantier permanent. C’est la Platform Version qui fait foi. En seulement trois itérations, le système a fait des bonds discrets mais costauds :
16558.0.0 : Cette version est actuellement répertoriée comme la version « Canary » pour les flottes de matériel spécialisé, notamment le Google Meet Hardware.
16559.0.0 : Elle a été spécifiquement déployée pour des cartes comme rynax (Acer Chromebook 511) et bard (Pixelbook interne).
Un contenu de qualité, sans publicité.
Vous aimez notre travail ? Soutenez notre indépendance en devenant membre sur Patreon.
Soutenir MyChromebook.fr16560.0.0 : C’est la version cible actuelle pour le gros du parc matériel récent en canal Canary, incluant les modèles ASUS Chromebook Plus CX34 (mithrax), Acer Chromebook Spin 714 (kano), et les Dell Latitude 5430 (crota).
Maintenir ce numéro de release stable permet aux ingénieurs de solidifier la couche Aluminium sans perturber le cycle de Chrome. On prépare l’infrastructure pour que Gemini et les frameworks Android s’exécutent nativement, sans avoir à changer de version majeure à chaque réglage de pilote. Cette « mutation » ne s’opère pas que dans la version 146.0.7639.0_pre. J’en veux pour preuve avec la version 146.0.7636.0_pre1569741 mise en ligne le 17 janvier 2025 (et ses itérations de plateforme comme la 16560.0.0) qui contient explicitement des lignes de code préparant cette transition. On observe notamment l’intégration de briques Android comme la pile Bluetooth Fluoride au cœur de ChromeOS.
Sous le capot : l’optimisation « invisible » et le défi x86
Il y a un truc qu’on ne voit jamais, c’est le profil AFDO1. Le système observe comment vous bossez, puis demande au compilateur de réorganiser le code machine. Sur cette branche 146, Google a optimisé l’architecture Atom pour booster la réactivité sans changer une ligne de code visible.
En parallèle, entre les plateformes 16557 et 16560, environ 57 changements internes ont été injectés (commits LKGM). On parle de stabiliser le noyau 6.6.99 et de mettre à jour les microcodes pour les puces X86_64. Car c’est là le vrai défi : Android est né pour les puces mobiles (ARM). Faire tourner ce noyau sur du Intel ou du AMD sans perte de performance demande une ingénierie de pointe.
| Composant | Avant (Pre-146) | Après (Aluminium) |
| Noyau | Linux Mainline | Android Linux Kernel |
| Gestion des Apps | Virtualisation (ARCVM) | Exécution Native |
| Pile Bluetooth | Linux (BlueZ) | Android (Fluoride) |
| Services IA | Cloud / API distantes | Intégration NPU Native |
Transition et survie du parc existant
On ne change pas les tripes d’un parc informatique mondial en un week-end. Google va gérer une période de cohabitation. John Maletis l’a promis : l’engagement des 10 ans de mises à jour tient toujours.
- Les machines récentes (gamme Plus) vont migrer totalement vers le nouveau stack Android.
- Les vieux coucous resteront sur la base Linux classique qui voit sa version évoluée. Ils auront la sécurité et le navigateur à jour, mais pas les fonctions IA « Aluminium ».
- L’impact pro/éducatif : Les deux versions coexisteront des années, simplifiant la gestion des flottes (EMM) car les politiques de sécurité seront enfin identiques entre smartphones et PC.
| Étape de Release | Canal | Objectif de la 146 | Probabilité de bug |
| 146.0.7639.0_pre | Canary | Staging noyau Android | Très Forte |
| 146.0.7636.x | Dev | Tests de compatibilité | Haute |
| 144.0.7559.x | Stable | Maintenance classique | Faible |
2026 : un année de transition pour ChromeOS
D’ici fin 2026, l’idée de « navigateur encapsulé » aura vécu. Le Chromebook de demain sera une extension ultra-puissante de l’écosystème Android, taillée pour l’IA générative. On gagne en performance, en autonomie (surtout sur puces Qualcomm) et en cohérence. C’est la fin d’une ère et le début d’une convergence totale.J’ai hâte de voir enfin tout ce que imaginons fonctionner et donc voir des Chromebook doper à l’IA nous étonner une fois de plus. Et vous que pensez-vous de ce mouvement de fond qui s’instaure pour avoir demain des Chromebook encore plus performant ?
- Le profil AFDO (Automatic Feedback Directed Optimizer) est une technique avancée d’optimisation utilisée par Google pour améliorer les performances de ChromeOS sans modifier le code source lui-même.
Voici ce qu’il faut retenir sur son fonctionnement et son utilité :
1. Une optimisation basée sur le comportement réel
Le compilateur (le logiciel qui transforme le code écrit par les ingénieurs en instructions pour la machine) ne sait pas toujours quelle partie du code sera la plus utilisée. L’AFDO résout ce problème en enregistrant des données de performance lors de l’exécution réelle du système ou lors de tests de référence (benchmarks). Ces données indiquent quelles fonctions sont les plus « chaudes » (utilisées fréquemment) et lesquelles sont « froides » (rarement utilisées).
2. Le fonctionnement technique
Collecte de données : Le système collecte des échantillons d’exécution (souvent via un profileur commeperfsous Linux).
Réinjection : Ces échantillons sont transformés en un « profil » que le compilateur utilise lors de la prochaine génération du système.
Optimisation ciblée : Grâce à ce profil, le compilateur peut réorganiser le code machine pour que les instructions les plus courantes s’exécutent plus rapidement et occupent mieux la mémoire cache du processeur.
3. Spécificité par architecture
Sur ChromeOS, les profils AFDO ne sont pas génériques. Ils sont créés spécifiquement pour des familles de processeurs afin d’en tirer le maximum. On trouve souvent :
Atom AFDO : Optimisé pour les processeurs Intel basse consommation (souvent utilisés dans les Chromebooks éducatifs).
Bigcore AFDO : Optimisé pour les processeurs plus puissants (Intel Core i3/i5/i7).
Arm AFDO : Pour les processeurs basés sur l’architecture ARM (MediaTek, Qualcomm).
4. Pourquoi le numéro de version ne change pas?
Lorsqu’un « roll » (une mise à jour) du profil AFDO est effectué, comme c’est le cas pour la version146.0.7639.0_pre1570614, les ingénieurs remplacent simplement l’ancien fichier de profil par un nouveau, plus récent et plus précis. Cela permet d’affiner la fluidité du système ou de corriger des problèmes de latence très spécifiques à un matériel sans avoir besoin de modifier le numéro de version du navigateur Chrome. ↩︎
FAQ (Foire Aux Questions) qui ne va pas migrer
Est-ce qu’Android est juste une mise à jour pour ChromeOS ?
Non, c’est bien plus profond. Google est en train de fixer les bases d’Android directement au niveau du noyau (kernel). Ce n’est plus une application qu’on ajoute par-dessus, c’est le système qui change de fondation.
Pourquoi fixer les bases d’Android maintenant ?
Parce que l’IA Gemini a besoin d’un accès direct au matériel pour être performante. En ancrant les bases d’Android dans ChromeOS, Google supprime les couches inutiles et permet à l’IA de fonctionner comme sur les smartphones les plus puissants.
Qu’est-ce que la « Platform Version » nous apprend ?
Elle montre que même quand le numéro de Chrome ne bouge pas, les fondations Android progressent. Les versions 16558 à 16560 prouvent que Google injecte les briques d’Android par petites touches successives pour stabiliser l’édifice.
