Un autre genre de confinement

Après une première annonce en 2023, Canonical semblait avoir laissé tomber son idée d’un Ubuntu Core Desktop, un système pensé pour être immuable, atomique et attestable. Voilà pourtant qu’elle remet le couvert, affirmant cette fois accélérer le projet.

Pour comprendre les enjeux, il faut revenir aux définitions : qu’est-ce qu’un système d’exploitation immuable, atomique et attestable ? D’abord, immuable : c’est un système dont les fichiers essentiels sont en lecture seule. Avec ce fonctionnement, en théorie, aucun utilisateur ni aucune application ne peut les modifier.

Ensuite, lorsque l’on parle de système atomique, on évoque surtout ses mises à jour : elles s’appliquent soit entièrement, soit pas du tout. Les deux vont très souvent de pair, de sorte que le système vise une prévisibilité extrême, la base ne changeant pas. Les applications sont isolées, aussi bien du système qu’entre elles, chacune résidant dans son propre conteneur. Dans le cas de Canonical, vous l’aurez deviné, on parle bien de Snap.

Sur ce socle vient se greffer un système d’attestation. Une telle version d’Ubuntu doit ainsi prouver à tout moment ce qu’elle exécute. Interrogée, la machine peut démontrer quels logiciels elle fait tourner, simplifiant les vérifications et rendant les altérations plus complexes. Ce type de mécanisme passe souvent par un composant matériel dédié, TPM dans la grande majorité des cas.

Le retour d’Ubuntu Core Desktop

Dans son nouveau billet du 28 octobre, Canonical reconnait que la préversion de 2023 n’a pas été à la hauteur. Les débuts ont certes été encourageants, mais le projet est devenu très silencieux dès l’année suivante. Selon le site It’s FOSS, l’explication tient dans la manière dont Canonical avait dessiné son système, une grande partie du bureau (dont GNOME et l’écran de connexion) étant réunie dans un seul snap volumineux.

Dans le fond, le principe est inchangé. Tous les composants sont livrés sous forme de snaps, dont le chargeur d’amorçage, le noyau, l’environnement de bureau, les démons (services) et toutes les applications. Mais en pratique, l’approche est cette fois beaucoup plus modulaire. Canonical dit vouloir définir des interfaces claires entre les composants. Ainsi, le gestionnaire d’affichage, l’environnement de bureau, les serveurs multimédias, le réseau et les autres fonctions devront respecter des interfaces clairement définies sans dépendre d’une implémentation particulière.

Dans ce fonctionnement, chaque partie du bureau peut évoluer individuellement. C’est effectivement à la base la promesse des snaps et, plus généralement, de tous les conteneurs logiciels. Bénéfice de cette évolution modulaire, il ne serait plus nécessaire de reconstruire tout le système à chaque changement. Selon Canonical, ce facteur différencierait Ubuntu Core Desktop des autres systèmes immuables comme Fedora Silverblue ou openSUSE Aeon.

Conséquence, cette version du système n’obligerait pas à utiliser GNOME. Canonical indique s’être rapprochée de l’équipe de KDE Neon Core et avoir produit une variante de KDE Neon fondée sur Ubuntu Core.

• KDE fête ses 30 ans

Canonical vise trois cas d’usage pour la 27.04

L’entreprise explique qu’une équipe dédiée est désormais constituée pour travailler sur Ubuntu Core Desktop et que des préversions quotidiennes seront construites pendant le cycle de développement d’Ubuntu 27.04. Pour l’instant, la nouvelle équipe remet en place les chaînes de production d’images et fait le point sur la situation.

Canonical indique que trois cas d’usage prioritaires sont visés. D’abord, le navigateur, cas jugé le plus simple car Firefox et Chromium sont livrés en snaps depuis des années. Ils sont compatibles avec le système de permissions et peuvent donc accorder l’accès à la caméra et au micro.

Ensuite, le développement logiciel. Cette fois, la situation se complique : un système de fichiers en lecture seule et des permissions strictes ne font pas forcément bon ménage avec les habitudes des développeurs. De plus, des outils répandus comme Visual Studio Code fonctionnent en mode « classic », qui accorde de nombreuses permissions au système. VSC ne fonctionne d’ailleurs pas sur Ubuntu Core. Solution envisagée par Canonical : placer ces applications dans Workshop, un environnement de développement isolé propre à l’entreprise, tandis que les fenêtres associées seraient affichées sur le bureau principal. Canonical compare directement cette solution à WSLg (Windows Subsystem for Linux GUI) de Microsoft.

Enfin, le jeu vidéo, avec l’objectif affiché de pouvoir fonctionner aussi bien sur ordinateur classique que sur des consoles portables comme le Steam Deck. Techniquement, le snap de Steam satisfait déjà les exigences de confinement strict, mais il a été largement mis de côté ces deux dernières années. Dans l’idéal, les composants graphiques seront eux aussi modulaires, afin que Mesa et Proton puissent être mis à jour sans toucher au reste du système. Canonical dit aussi étudier des modes de commande où l’appareil démarre directement sur une interface de jeu plutôt que sur un bureau classique.

La route sera longue

Dans tous les cas, le principal obstacle est la disponibilité des applications en snaps. Core Desktop ne peut pas exécuter un autre format. Il faut également que les permissions soient gérées, afin qu’une application puisse toujours demander l’autorisation avant d’accéder à la caméra, au micro ou à un dossier personnel. Autre défi, la modularisation complète du bureau et la prise en charge de KDE Plasma au même niveau que GNOME.

Le projet reste jeune, voire très jeune. Canonical précise d’ailleurs que la version classique d’Ubuntu est là pour rester, aucun calendrier n’étant donné pour une éventuelle bascule par défaut sur Core Desktop. Concernant les variantes officielles du système (les flavors comme Kubuntu, Edubuntu, Xubuntu…), le billet indique que les mainteneurs concernés seront libres de proposer leur propre variante de Core Desktop, s’ils le souhaitent.

Oui, c'est compliqué

Argon tout juste présenté il y a un mois, Google l’éclipse déjà par un nouveau venu : Carbon. Il prend la tête des modèles de pointe de l’entreprise, mais il n’est pas encore disponible et les détails manquent.

Google a présenté Argon le 30 septembre comme premier représentant de la famille Gemini 4. Il n’a cependant pas été disponible de tout de suite, le LLM ayant dans un premier temps été examiné par le gouvernement américain. Le 13 octobre, le nouveau modèle a finalement été lancé publiquement. À peine deux semaines plus tard, voilà qu’Argon est déjà remplacé.

Son successeur se nomme Carbon. Il prend ainsi la tête des LLM frontière (de pointe) chez Google et, si l’on en croit les chiffres communiqués, de bon nombre de classements tous modèles confondus. Ce n’est pas tout à fait une surprise cependant, des rumeurs circulaient depuis trois semaines environ sur cette arrivée.

Des performances à l’avenant, mais…

Au vu des scores donnés par Google, Carbon est premier dans 15 des 17 benchmarks référencés. Il n’est derrière que sur deux des tests : FrontierSWE 2, où Carbon obtient 61,2 %, derrière GPT-6 Astra (65,5 %) et Opus 5.5 (62,3 %), et OSWorld, où Opus reste en tête avec 87,2 %, contre 81,5 % pour Carbon.

Artificial Analysis classe Carbon (en effort High) premier de son Intelligence Index v5.0 avec 59 points, devant Claude Opus 5.5 (58), GPT-6 Astra (57) et Argon (50). Attention avec cette version 5 de l’indice, car elle a été révisée pour limiter la saturation (les notes maximales devenaient souvent atteintes). 60 % des tests étant désormais privés ou à réponses non publiées, les scores ne sont pas comparables à ceux des versions précédentes.

Carbon surpasse son prédécesseur dans tous les cas de figure, avec des bonds parfois importants dans certains domaines, comme un passage de 42 à 54,8 % sur ExploitGym. La cybersécurité est d’ailleurs mise en avant par Google, qui précise tout de même que ses tests ont été menés sans aucun garde-fou. Impossible en l’état de savoir ce que les clients auront réellement entre les mains, même si ce n’est que l’un des nombreux points que Google n’aborde pas dans sa présentation.

Parmi les progrès que Google revendique face à Argon, on peut voir un taux de triche désormais à 0,0 % sur Terminal-Bench 4.0, une baisse de 80 % des alertes de désalignement graves dans ses environnements internes de développement, ou encore une réduction de moitié des réponses non étayées.

… peu d’informations concrètes

Problème, Carbon a beau sembler puissant, Google tait pour l’instant de nombreuses informations. La plupart des données fournies émanent de tests internes ou de formulations floues, par exemple sur l’utilisation enthousiasmée des employés qui l’ont testé pendant plusieurs jours. Google ne dit rien non plus de la disponibilité. Si l’on applique le calendrier d’Argon, la sortie publique pourrait intervenir dans deux semaines. Un petit nombre de spécialistes de la cybersécurité y a cependant accès, le nombre devant augmenter progressivement via le programme Fairwind.

Côté tarifs, puisque Carbon remplace Argon, il reprend les mêmes : 2 dollars par million de jetons en entrée, 10 dollars en sortie, avec une remise de 95 % sur les jetons d’entrée en cache. À l’issue de la période de lancement, le tarif passera respectivement à 4 et 20 dollars, mais Google ne donne aucun détail temporel. Carbon, comme Argon, est donc un modèle onéreux. Il est d’ailleurs épinglé comme tel par Artificial Analysis, dont l’indice maison affiche un coût de 7,76 dollars par tâche, qui reste cependant moins élevé que ceux affichés par les derniers modèles Anthropic en effort maximal.

Si Carbon est présenté explicitement comme un successeur d’Argon, sur lequel il est bâti, la gamme Gemini manque de lisibilité, d’autant qu’Argon reste au catalogue. Sa période promotionnelle se finit le 1er décembre, et on peut se demander si Google ne compte pas le retirer alors, pour laisser place à Carbon et sa propre période promotionnelle. Le nouveau venu serait sinon moins cher que son grand frère, ce qui n’aurait guère de sens.

Chacun ses apps, et les vaches...

Et si l’IA ouvrait grandes les portes d’une forme de réappropriation technologique ? Une certaine ironie, quand on connait ses effets sur le prix de la mémoire. Mais un nombre croissant de personnes se lancent dans des projets permettant de modifier en profondeur certains produits, notamment les TV connectées.

Il n’y a qu’à se plonger dans les dernières récriminations autour des téléviseurs connectés LG pour saisir l’agacement. Ces produits proposent de tout réunir dans une même interface, mais intègrent souvent de nombreux mécanismes de pistage pour mieux servir de la publicité sur mesure. Un mécanisme classique, non spécifique à cette gamme de produits connectés.

Si l’on en croit plusieurs sites comme TechCrunch et Tom’s Guide, un nombre croissant de développeurs en herbe ne sont plus disposés à accepter la situation. Dans un mouvement que l’on retrouve plutôt sur Windows habituellement, certains ont donc eu une idée : et s’ils modifiaient leur appareil pour supprimer tout ce qui ne leur plaisait pas ?

Ménage d’automne

L’effet est documenté depuis un moment déjà et ressort régulièrement, jusque dans les rapports de Linux Foundation : l’IA générative abaisse le ticket d’entrée. Comprendre par là qu’une idée peut rapidement se transformer en un code concret, les générations successives de modèles rendant l’opération de plus en plus simple.

La vague du « vibe coding » s’étend dans toutes les directions et nos confrères notent en particulier un front ouvert sur les TV connectées. Ainsi, le projet dumbtv annonce clairement la couleur : « Votre téléviseur doit faire ce pour quoi vous avez payé : vos applications, vos entrées HDMI, et rien d’autre. Pas de publicités directement sur la télé, pas de suivi des visionnages, pas de mise à jour que vous n’avez pas demandée ».

Sur le site dédié (en plus du dépôt GitHub), le projet se propose de remanier complètement les appareils sous Fire TV, dont les dongles Amazon. L’installation requiert un ordinateur, un accès réseau pour l’appareil visé ainsi que l’activation du mode ADB (Android Debug Bridge) sur ce même appareil. Après quoi, avec quelques manipulations, on peut en théorie supprimer les publications, les contenus sponsorisés, les techniques de création d’empreinte numérique (fingerprinting) et ainsi de suite.

Si le projet a rapidement dépassé les 1 700 étoiles sur GitHub, un autre a attiré encore plus les regards : CleanYourTV. Le dépôt correspondant dépasse les 43 000 étoiles et affiche fièrement sa médaille d’or obtenue comme dépôt le plus « tendance » de la semaine du 19 octobre. Et pour cause : le projet propose ni plus ni moins que de lancer un grand nettoyage sur votre TV connectée à la seule condition qu’elle embarque Android TV ou Google TV (toujours via le mode ADB).

En tant que tel, CleanYourTV ne désinstalle rien. Il cache les éléments et les désactive : télémétrie, services publicitaires et bon nombre de composants sont ainsi remisés au placard. Le choix de ne pas les désinstaller semble une mesure de sécurité, afin qu’un simple script de restauration puisse remettre la TV dans son état original. En revanche, l’outil installe son propre lanceur (décrit comme léger et natif), autrement dit l’interface principale avec les applications, dans une version plus sobre ressemblant fortement à l’Apple TV.

Une forme de réappropriation

Dans une série de tweets publiés le 17 octobre, l’auteur de CleanMyTV explique simplement avoir « vibe codé » la télé de ses parents. Elle affichait des publicités avant même de pouvoir atteindre Netflix. Le produit est un modèle Xiaomi selon ses dires, dont la référence a été donnée à Claude Code dans le prompt. L’appareil a été trouvé sur le Wi-Fi, aboutissant à la suppression de 25 composants Xiaomi. De là est née l’idée du projet et de sa mise à disposition (le code est sous licence open source MIT).

Ces projets ne sont pas isolés, on en trouve d’autres sur X, racontant tous la même histoire : un constat d’interface lente, des applications inutiles, des publicités trop nombreuses. Le désir est donc systématiquement le même, une reprise en main d’un produit payé mais dont l’expérience utilisateur s’est révélée insatisfaisante, voire franchement agaçante.

Dans la plupart des cas, on trouve Claude parmi les contributeurs des projets, confirmation que le projet a été largement accéléré par un agent. Les personnes derrière ces créations sont souvent elles-mêmes des développeurs, mais on peut se poser la question : se seraient-elles lancées dans ces opérations sans IA ?

« Ça ne me plait pas, donc je modifie »

La question est d’autant plus intéressante qu’elle permet d’entrevoir une longue liste de possibilités. The Verge a par exemple relevé récemment que le même vibe coding permettait à des passionnés des modifications poussées de produits utilisés dans la production musicale, via la création de firmwares personnalisés. Nos confrères indiquaient avoir remarqué une « explosion » de ces microgiciels sur le subreddit r/synthesizers. Précédemment, ce type d’opération nécessitait de vastes compétences, affirment nos confrères.

Sans tomber dans une longue liste d’exemples, l’IA semble avoir déclenché une vague d’interrogations sur une partie des produits qui nous entourent. Le développeur italien Carmine Paolino, par exemple, n’apprécie pas les technologies web dans les applications. Il a donc créé des versions natives pour plusieurs d’entre elles, en particulier pour Spotify et WhatsApp, avec respectivement Spotifast et ZapFast.

L’obtention de meilleures performances est un puissant moteur de motivation. Dans notre cas, nous nous amusons par exemple à créer un client alternatif et multiplateforme pour Mattermost (sur une base Rust, C# et Avalonia) pour explorer la manière dont on peut alléger la pression sur la mémoire vive, en particulier dans cette période d’explosion des prix. Sur cette petite application (qui se limite volontairement à la partie messagerie texte pour une seule équipe), la consommation tourne en moyenne autour de 130 à 150 Mo, contre 600 Mo en moyenne pour Mattermost, dont le client officiel est basé sur Electron (qui simplifie largement les problématiques de support multiplateforme).

Les mises en garde restent les mêmes

Mais attention, les bonnes performances ont beau être agréables, elles « n’excusent » pas tout. Point commun à pratiquement tous ces projets, ils s’attaquent à des produits commerciaux d’entreprises qui goûtent sans doute peu de voir leur matériel ou leur application ainsi modifiée. Des sociétés comme Spotify ou Meta (pour WhatsApp) pourraient voir d’un très mauvais œil l’arrivée de ces versions et modifier leur licence pour en interdire la fabrication. Mais qui sait, Meta pourrait tenir compte du message sous-jacent : des utilisateurs ne sont pas disposés à consacrer 1 à 3 Go de mémoire pour une simple messagerie.

En outre, si le phénomène peut être enthousiasmant dans tout son potentiel, il est facile de lancer des projets, beaucoup moins de les entretenir, et encore moins de le faire sérieusement. Les IA peuvent se tromper, des secrets peuvent se glisser dans le code et des erreurs énormes peuvent apparaitre, avec à la clé de possibles failles de sécurité béantes chez les utilisateurs. L’aspect systématiquement open source de ces travaux (toujours sous licence MIT ou Apache 2.0) limite en théorie la casse, mais la prudence reste de mise.

• #Nextquick : libre et open source ne sont pas synonymes de sécurité