Les utilisateurs européens devront se contenter de la portion congrue. Le gros morceau des systèmes d’exploitation « 27 » d’Apple, Siri AI, ne sera en effet pas lancé dans l’UE pour cause de bisbilles entre Apple et Bruxelles sur le DMA. Est-ce une raison de bouder la première bêta publique ?
C’est devenu une tradition au fil des ans : avant la version finale de ses nouveaux systèmes d’exploitation, Apple propose à tous ceux qui veulent mettre les mains dans le cambouis de se frotter à une bêta publique. Plus solide que la bêta pour les développeurs, mais forcément susceptible de bugguer davantage qu’une mouture finale, cette préversion permet tout de même de profiter des nouveautés d’une manière relativement confortable. Ce d’autant qu’iOS 27 se montre, d’après nos tests, plutôt stable.
Apple vient donc de mettre en ligne la bêta publique pour iOS 27, iPadOS 27, macOS 27 Golden Gate, watchOS 27, tvOS 27, HomePod OS 27 et le logiciel interne des AirPods (ouf !). La grande affaire de cette nouvelle mouture n’est autre que Siri AI, qui se montre enfin à peu près au niveau des autres assistants du même genre – grâce à un coup de main de Google et de ses modèles Gemini.
Hélas, ce nouveau Siri ne sera pas livré dans l’UE sur iPhone et iPad. L’assistant ne sera dans un premier temps disponible qu’en anglais (en saisissant des requêtes textes en français, il saura répondre en français mais uniquement en texte). Mais surtout, Apple reproche au règlement sur les marchés numériques (DMA) de l’empêcher de proposer Siri AI en Europe. « [Le] refus [de la Commission] de s’engager de manière constructive sur des solutions qui préservent la vie privée et la sécurité signifie que nous n’avons pas encore de calendrier pour la disponibilité de Siri AI sur iOS et iPadOS dans l’UE », indiquait l’entreprise.
Optimisations au menu
En Europe, Siri AI sera néanmoins proposé sur macOS, qui ne fait pas partie des plateformes essentielles au sens du DMA. C’est dommage, mais Apple et la Commission finiront peut-être par trouver une solution. En attendant, il est vrai que les nouveautés des OS 27 d’Apple sont assez ténues. La plus significative est certainement le travail de ripolinage de Liquid Glass : le langage de design gagne une réglette globale pour réduire les effets de transparence.
Sur macOS, les gros écueils de la nouvelle interface ont aussi été rabotés, au plus grand plaisir de nombreux utilisateurs pas très friands de certaines excentricités de Liquid Glass. Apple Intelligence continue de déployer ses ailes pour les retouches photo et Image Playground qui devient un peu plus utilisable. L’app Raccourcis peut désormais générer des raccourcis en fonction d’une requête. Safari sait regrouper des onglets automatiquement.
Toutes ces fonctions restent cependant soumises à des exigences matérielles relativement élevées, en particulier sur les smartphones : il faut posséder un iPhone 15 Pro ou 15 Pro Max, un iPhone 16 (tous modèles) pour prétendre à Apple Intelligence. C’est plus généreux sur les tablettes : à partir de l’iPad mini (A17 Pro) et tous les iPad avec puce Mx. Le MacBook Neo (A18 Pro) et tous les modèles de Mac avec puce Mx sont également compatibles.
Les OS 27 ont surtout fait l’objet d’un gros travail de stabilité et d’optimisation. Les apps se lancent plus vite, les transitions entre réseaux se veulent plus fluides, la recherche s’améliore (enfin !) dans Mail, et beaucoup d’autres petites améliorations ici et là vont faciliter la vie de tous les utilisateurs, pas uniquement ceux qui possèdent le dernier iPhone à la mode.
Pour télécharger la bêta publique, il faut s’inscrire sur le site dédié (il suffit de renseigner les identifiants de son compte Apple). Ensuite, rendez-vous dans le panneau Mise à jour logicielle (dans les réglages Général) puis sélectionnez le menu Mises à jour bêta. On ne recommande pas l’opération sur des machines de production ! La bêta publique est la bêta 3 qu’Apple a livrée aux développeurs la semaine dernière.
Les utilisateurs européens devront se contenter de la portion congrue. Le gros morceau des systèmes d’exploitation « 27 » d’Apple, Siri AI, ne sera en effet pas lancé dans l’UE pour cause de bisbilles entre Apple et Bruxelles sur le DMA. Est-ce une raison de bouder la première bêta publique ?
C’est devenu une tradition au fil des ans : avant la version finale de ses nouveaux systèmes d’exploitation, Apple propose à tous ceux qui veulent mettre les mains dans le cambouis de se frotter à une bêta publique. Plus solide que la bêta pour les développeurs, mais forcément susceptible de bugguer davantage qu’une mouture finale, cette préversion permet tout de même de profiter des nouveautés d’une manière relativement confortable. Ce d’autant qu’iOS 27 se montre, d’après nos tests, plutôt stable.
Apple vient donc de mettre en ligne la bêta publique pour iOS 27, iPadOS 27, macOS 27 Golden Gate, watchOS 27, tvOS 27, HomePod OS 27 et le logiciel interne des AirPods (ouf !). La grande affaire de cette nouvelle mouture n’est autre que Siri AI, qui se montre enfin à peu près au niveau des autres assistants du même genre – grâce à un coup de main de Google et de ses modèles Gemini.
Hélas, ce nouveau Siri ne sera pas livré dans l’UE sur iPhone et iPad. L’assistant ne sera dans un premier temps disponible qu’en anglais (en saisissant des requêtes textes en français, il saura répondre en français mais uniquement en texte). Mais surtout, Apple reproche au règlement sur les marchés numériques (DMA) de l’empêcher de proposer Siri AI en Europe. « [Le] refus [de la Commission] de s’engager de manière constructive sur des solutions qui préservent la vie privée et la sécurité signifie que nous n’avons pas encore de calendrier pour la disponibilité de Siri AI sur iOS et iPadOS dans l’UE », indiquait l’entreprise.
Optimisations au menu
En Europe, Siri AI sera néanmoins proposé sur macOS, qui ne fait pas partie des plateformes essentielles au sens du DMA. C’est dommage, mais Apple et la Commission finiront peut-être par trouver une solution. En attendant, il est vrai que les nouveautés des OS 27 d’Apple sont assez ténues. La plus significative est certainement le travail de ripolinage de Liquid Glass : le langage de design gagne une réglette globale pour réduire les effets de transparence.
Sur macOS, les gros écueils de la nouvelle interface ont aussi été rabotés, au plus grand plaisir de nombreux utilisateurs pas très friands de certaines excentricités de Liquid Glass. Apple Intelligence continue de déployer ses ailes pour les retouches photo et Image Playground qui devient un peu plus utilisable. L’app Raccourcis peut désormais générer des raccourcis en fonction d’une requête. Safari sait regrouper des onglets automatiquement.
Toutes ces fonctions restent cependant soumises à des exigences matérielles relativement élevées, en particulier sur les smartphones : il faut posséder un iPhone 15 Pro ou 15 Pro Max, un iPhone 16 (tous modèles) pour prétendre à Apple Intelligence. C’est plus généreux sur les tablettes : à partir de l’iPad mini (A17 Pro) et tous les iPad avec puce Mx. Le MacBook Neo (A18 Pro) et tous les modèles de Mac avec puce Mx sont également compatibles.
Les OS 27 ont surtout fait l’objet d’un gros travail de stabilité et d’optimisation. Les apps se lancent plus vite, les transitions entre réseaux se veulent plus fluides, la recherche s’améliore (enfin !) dans Mail, et beaucoup d’autres petites améliorations ici et là vont faciliter la vie de tous les utilisateurs, pas uniquement ceux qui possèdent le dernier iPhone à la mode.
Pour télécharger la bêta publique, il faut s’inscrire sur le site dédié (il suffit de renseigner les identifiants de son compte Apple). Ensuite, rendez-vous dans le panneau Mise à jour logicielle (dans les réglages Général) puis sélectionnez le menu Mises à jour bêta. On ne recommande pas l’opération sur des machines de production ! La bêta publique est la bêta 3 qu’Apple a livrée aux développeurs la semaine dernière.
Dans un billet d’actualités mensuel, publié le 8 juillet, Clément Lefebvre, fondateur et principal développeur de la distribution Linux Mint, a indiqué que le support de Wayland dans Cinnamon n’était plus expérimental.
La prochaine version majeure de Linux Mint, estampillée 23 et prévue pour la fin de l’année, proposera donc une « vraie » session Wayland, aux côtés de la session X11 classique, qui restera telle quelle. Le développeur ne dit pas en revanche si la session Wayland sera utilisée par défaut, ou si le choix sera plus conservateur. La décision sera probablement annoncée dans les mois qui viennent.
Clément Lefebvre indique que le travail sur le support de Wayland a été intense, avec de nombreux résultats positifs. On note ainsi des améliorations pour la stabilité générale, la gestion des fenêtres, le support du multi-écran, la prise en charge du HiDPI et de l’échelle fractionnaire ou encore des GPU NVIDIA.
Illustration : Flock
Ces nouveautés étant prévues pour la prochaine version de Cinnamon, elles seront automatiquement reprises dans Linux Mint 23, qui doit arriver en décembre. S’agissant de la première mouture à sortir après la publication d’Ubuntu 26.04, elle en reprendra donc les bases, avec à la clé une vaste modernisation de la base technique.
Les améliorations citées ne seront pas les seules. Lefebvre évoque par exemple une cartographie correcte de la taille et de la position des fenêtres quand Cinnamon est utilisé avec Wayland. Même chose pour les applets et les menus de contenu. Le prochain Cinnamon intègrera aussi un mécanisme de prévention du vol de focus (« focus stealing » en VO), pour s’assurer que la saisie ou les clics ne se fassent pas dans une autre application sans interaction explicite de l’utilisateur. Nous avions souligné ce risque de sécurité dans notre dossier consacré à la transition de X11 vers Wayland.
D’autres apports sont prévus et seront probablement accueillis avec joie par les utilisateurs. Par exemple, l’accélération matérielle a été intégrée au compositeur, au bureau et aux clients Wayland et XWayland (mécanisme de compatibilité pour les applications X11 dans une session Wayland). On note aussi la prise en charge de la session graphique de systemd pour améliorer la compatibilité avec d’autres distributions (Cinnamon peut être installé sur d’autres systèmes, comme Ubuntu et Fedora)
Dans un billet d’actualités mensuel, publié le 8 juillet, Clément Lefebvre, fondateur et principal développeur de la distribution Linux Mint, a indiqué que le support de Wayland dans Cinnamon n’était plus expérimental.
La prochaine version majeure de Linux Mint, estampillée 23 et prévue pour la fin de l’année, proposera donc une « vraie » session Wayland, aux côtés de la session X11 classique, qui restera telle quelle. Le développeur ne dit pas en revanche si la session Wayland sera utilisée par défaut, ou si le choix sera plus conservateur. La décision sera probablement annoncée dans les mois qui viennent.
Clément Lefebvre indique que le travail sur le support de Wayland a été intense, avec de nombreux résultats positifs. On note ainsi des améliorations pour la stabilité générale, la gestion des fenêtres, le support du multi-écran, la prise en charge du HiDPI et de l’échelle fractionnaire ou encore des GPU NVIDIA.
Illustration : Flock
Ces nouveautés étant prévues pour la prochaine version de Cinnamon, elles seront automatiquement reprises dans Linux Mint 23, qui doit arriver en décembre. S’agissant de la première mouture à sortir après la publication d’Ubuntu 26.04, elle en reprendra donc les bases, avec à la clé une vaste modernisation de la base technique.
Les améliorations citées ne seront pas les seules. Lefebvre évoque par exemple une cartographie correcte de la taille et de la position des fenêtres quand Cinnamon est utilisé avec Wayland. Même chose pour les applets et les menus de contenu. Le prochain Cinnamon intègrera aussi un mécanisme de prévention du vol de focus (« focus stealing » en VO), pour s’assurer que la saisie ou les clics ne se fassent pas dans une autre application sans interaction explicite de l’utilisateur. Nous avions souligné ce risque de sécurité dans notre dossier consacré à la transition de X11 vers Wayland.
D’autres apports sont prévus et seront probablement accueillis avec joie par les utilisateurs. Par exemple, l’accélération matérielle a été intégrée au compositeur, au bureau et aux clients Wayland et XWayland (mécanisme de compatibilité pour les applications X11 dans une session Wayland). On note aussi la prise en charge de la session graphique de systemd pour améliorer la compatibilité avec d’autres distributions (Cinnamon peut être installé sur d’autres systèmes, comme Ubuntu et Fedora)
Ubuntu 26.10 remplace enfin dbus-daemon par dbus-broker comme implémentation par défaut de D-Bus, un changement essentiellement interne visant à améliorer les performances, la robustesse et l’extensibilité. Aucun impact particulier n’est attendu sur les applications.
D-bus est un bus de messages : grâce à lui, les processus Linux peuvent communiquer entre eux. Ce composant est crucial, car il permet aux fonctions d’avoir le résultat attendu. Par exemple, le gestionnaire de fichiers demande au système de monter une clé USB pour en afficher le contenu, le panneau de configuration modifie la luminosité de l’écran, une application demande l’ouverture du sélecteur de fichiers, etc.
Pour quoi faire ?
À compter d’Ubuntu 26.10, le composant chargé des messages internes sera changé. dbus-daemon sera remplacé par dbus-broker, avec à la clé de sérieux avantages techniques : traitement asynchrone des messages, meilleure gestion des ressources, comptabilisation plus précise des clients, ou encore meilleure résistance générale lors de pics de trafic D-bus.
Il ne devrait y avoir aucun changement visible dans la grande majorité des scénarios. Bien que dbus-broker soit plus moderne, il est davantage pensé pour éviter les goulets d’étranglement que pour fournir une accélération dans les opérations basiques.
Si Canonical a décidé ce remplacement, c’est que dbus-daemon a été créé il y a 22 ans. Malgré son âge vénérable, il a reçu de nombreuses évolutions. Cependant, il accuse le poids des années : son architecture a été conçue à une époque où le nombre de services système était bien plus faible qu’aujourd’hui, où les environnements de bureau étaient plus simples et les charges de travail beaucoup moins importantes.
Pourquoi pas avant ?
Cette décision n’a rien d’avant-garde. Fedora, souvent la première distribution à opérer des changements techniques d’envergure, a déjà réalisé cette bascule en 2019. Pourquoi Canonical a-t-elle attendu si longtemps ? L’entreprise cite deux raisons :
Il a fallu attendre que GDM (le gestionnaire de connexion/bureau de GNOME) se débarrasse de ses dépendances à dbus-daemon, ce qui a fini par arriver avec GNOME 49
et attendre que dbus-broker atteigne une compatibilité complète avec AppArmor, notamment pour certaines fonctions liées à la gestion des paquets Snap
La stratégie de Canonical face à la nouveauté ne change pas. Les bascules ne s’opèrent que lorsque l’entreprise estime que la situation s’y prête. On se souvient par exemple que le passage à Wayland s’était fait plusieurs années après d’autres distributions, un peu plus de cinq ans après celle de Fedora, par exemple. Le remplacement des composants historiques se fait progressivement, pour éviter une cassure chez les utilisateurs, Ubuntu étant la distribution Linux la plus utilisée au monde.
Ubuntu 26.10 remplace enfin dbus-daemon par dbus-broker comme implémentation par défaut de D-Bus, un changement essentiellement interne visant à améliorer les performances, la robustesse et l’extensibilité. Aucun impact particulier n’est attendu sur les applications.
D-bus est un bus de messages : grâce à lui, les processus Linux peuvent communiquer entre eux. Ce composant est crucial, car il permet aux fonctions d’avoir le résultat attendu. Par exemple, le gestionnaire de fichiers demande au système de monter une clé USB pour en afficher le contenu, le panneau de configuration modifie la luminosité de l’écran, une application demande l’ouverture du sélecteur de fichiers, etc.
Pour quoi faire ?
À compter d’Ubuntu 26.10, le composant chargé des messages internes sera changé. dbus-daemon sera remplacé par dbus-broker, avec à la clé de sérieux avantages techniques : traitement asynchrone des messages, meilleure gestion des ressources, comptabilisation plus précise des clients, ou encore meilleure résistance générale lors de pics de trafic D-bus.
Il ne devrait y avoir aucun changement visible dans la grande majorité des scénarios. Bien que dbus-broker soit plus moderne, il est davantage pensé pour éviter les goulets d’étranglement que pour fournir une accélération dans les opérations basiques.
Si Canonical a décidé ce remplacement, c’est que dbus-daemon a été créé il y a 22 ans. Malgré son âge vénérable, il a reçu de nombreuses évolutions. Cependant, il accuse le poids des années : son architecture a été conçue à une époque où le nombre de services système était bien plus faible qu’aujourd’hui, où les environnements de bureau étaient plus simples et les charges de travail beaucoup moins importantes.
Pourquoi pas avant ?
Cette décision n’a rien d’avant-garde. Fedora, souvent la première distribution à opérer des changements techniques d’envergure, a déjà réalisé cette bascule en 2019. Pourquoi Canonical a-t-elle attendu si longtemps ? L’entreprise cite deux raisons :
Il a fallu attendre que GDM (le gestionnaire de connexion/bureau de GNOME) se débarrasse de ses dépendances à dbus-daemon, ce qui a fini par arriver avec GNOME 49
et attendre que dbus-broker atteigne une compatibilité complète avec AppArmor, notamment pour certaines fonctions liées à la gestion des paquets Snap
La stratégie de Canonical face à la nouveauté ne change pas. Les bascules ne s’opèrent que lorsque l’entreprise estime que la situation s’y prête. On se souvient par exemple que le passage à Wayland s’était fait plusieurs années après d’autres distributions, un peu plus de cinq ans après celle de Fedora, par exemple. Le remplacement des composants historiques se fait progressivement, pour éviter une cassure chez les utilisateurs, Ubuntu étant la distribution Linux la plus utilisée au monde.
Bun, un environnement d’exécution JavaScript et un gestionnaire de paquets, a annoncé le 8 juillet une conversion complète de son code vers Rust en un temps record. L’opération a été en grande partie menée grâce à l’utilisation de Claude Fable 5. Bien qu’il s’agisse d’un exemple concret en production, il ne peut pas être appliqué à tout type de projet.
Bun est un environnement et un gestionnaire de paquets pour JavaScript. Il est développé avec le langage Zig, est open source et sous licence MIT. Le projet est relativement récent sur la scène du développement, car la version 1.0 stable est sortie en septembre 2023. La dernière révision stable est la 1.3, publiée fin 2025. Elle a notamment ajouté le remplacement à chaud des modules (Bun est également un groupeur de modules, ou module bundler).
Les projecteurs se sont brusquement braqués sur Bun au même moment, quand Anthropic a annoncé son rachat. Une opération logique pour Anthropic, Bun étant déjà utilisé pour certains composants de Claude Code.
Et voilà que Bun vient d’annoncer la réécriture complète de son code Zig en Rust… en seulement 11 jours, entre les 3 et 14 mai.
Dans son billet, Jarred Sumner, à la tête du développement de Bun, explique que la version initiale de Bun avait été écrite en un an et en Zig, avant l’apparition des LLM. Aujourd’hui, le CLI (interface en ligne de commande) de Bun est téléchargé 22 millions de fois par mois. Alors pourquoi une réécriture totale en Rust ?
Selon Sumner, le choix n’est pas idéologique, mais motivé par une liste précise de bugs récurrents dans la version Zig : des dizaines de bugs de type use-after-free (le noyau réutilise un pan de mémoire qu’il a déjà libéré), double-free (double utilisation de la fonction free() sur la même adresse mémoire) et fuites mémoire dans des modules critiques (node:zlib, node:http2, UDPSocket, crypto.scrypt, TLS…).
L’argument central de Sumner est que Zig, comme le C, ne gère pas la mémoire pour vous, et ne dispose pas de constructeurs/destructeurs. Le nettoyage repose sur le mot-clé explicite defer. Il est manuel et il faut donc penser à l’utiliser, rendant l’erreur humaine quasi inévitable à grande échelle.
« Chaque allocation mémoire doit être examinée avec minutie. Où ces octets sont-ils libérés ? Comment s’assurer qu’il ne soit libéré qu’une seule fois ? Avons-nous bien vérifié les exceptions JavaScript ? Ce pointeur collecté à la poubelle est-il visible pour le scanner de pile conservateur ? Est-ce de la mémoire récupérée ou de la mémoire gérée manuellement ? », liste Jarred Sumner, parmi les questions récurrentes.
Après avoir envisagé le C++, il se tourne finalement vers le Rust, car une bonne partie des problèmes rencontrés sont liés à la gestion de la mémoire. Avec le « nouveau » langage, loué pour la sécurité induite justement en mémoire, ces problèmes apparaissent à la compilation. Encore faut-il que le code soit en Rust « sûr » (safe).
Sumner aborde d’ailleurs ce point. 4 % du code Rust de Bun se trouvaient ainsi dans un bloc unsafe, soit environ 13 000 mots-clés unsafe dans environ 27 000 lignes sur un total d’environ 780 000. La totalité du code ne peut pas être en Rust safe, car Bun continue d’embarquer des dépendances C/C++ significatives, comme JavaScriptCore, uWebSockets, BoringSSL, SQLite et lshpack/lsquic.
Le rôle prépondérant de Claude Fable 5
Le billet détaille amplement les méthodes utilisées. Par exemple, le choix d’une réécriture complète (plutôt qu’incrémentale) a été motivé par la propre expérience de Jarred Sumner dans ce type d’opération, et par la disponibilité d’une suite de tests indépendante du langage d’implémentation. Selon Sumner, elle a permis de garder un filet de sécurité comportemental identique pour l’avant/après.
On apprend en outre que la « revue adversariale » a été faite par deux instances Claude en contexte séparé, chargées de débusquer les bugs et présentées comme le mécanisme central de contrôle qualité. Et c’est justement la présence de Fable 5 au cœur du mécanisme qui rend l’annonce si visible.
La version de test a été produite en 11 jours. Les chiffres associés sont impressionnants : 5,9 milliards de tokens d’entrée non mis en cache, 690 millions de tokens de sortie, et 72 milliards de tokens d’entrée lus en cache. Soit environ 165 000 dollars au tarif de l’API, contre une estimation d’environ un an de travail pour trois ingénieurs à temps plein sur le code existant pour les 535 496 lignes de code, selon Jarred Sumner.
Source : Bun
Cette performance – en moyenne 1 300 lignes de code à la minute – concerne cependant la phase de génération brute, pas le code fonctionnel. Le billet précise qu’à ce stade, « absolument rien ne fonctionnait encore ». Une performance à relativiser également sur l’utilisation du LLM, car elle n’avait rien de « naïf ». L’orchestration humaine a été lourde, avec environ 50 flux de travail dynamiques et jusqu’à 64 instances de Claude en parallèle, réparties en quatre arbres de travail (worktrees). Sumner dit avoir lui-même surveillé manuellement les sorties pendant l’essentiel des 11 jours de travail.
Le billet documente aussi des échecs répétés du modèle dans des cas précis : interprétation erronée de consignes, ajout de commentaires justificatifs longs pour masquer des contournements… Un comportement suffisamment problématique pour que Sumner ait fini par ajouter une règle explicite aux réviseurs adversariaux : « Si vous avez besoin d’un paragraphe entier pour justifier qu’un contournement est correct, c’est que le code n’est pas bon – corrigez le code ».
Bon… et alors ?
Selon Jarred Sumner, les avantages de Rust sont évidents dans la préversion. Allègement des binaires, consommation de mémoire réduite, résolution de nombreux bugs liés à la mémoire existants dans la version actuelle 1.3.14… Sur le plan des performances, les gains sont plus mesurés, avec 2 à 5 % en moyenne selon les scénarios.
Jarred Sumner veut pour preuve de sa réussite que la version 2.1.181 de Claude Code, publiée le 17 juin, utilise la version de Bun réécrite en Rust. Cela signifie-t-il que tout est parfait et que tout le monde devrait se lancer dans le même type d’opération ? Pas du tout.
Le billet de Bun est assez transparent sur les défis restants. Bun 1.4.0 sera bien la première version intégralement en Rust et des corrections continueront pendant toute la phase de test. Mais plusieurs éléments méritent d’être soulignés, dont le caractère même du billet : intéressant dans le retour d’expérience qu’il rapporte, mais qui reste une communication d’entreprise puisque Jarred Sumner travaille pour Anthropic et a pu bénéficier de Fable 5 quand presque plus personne n’y avait droit en mai.
On pourrait souligner également que des régressions peuvent apparaître avant et après la version finale. 19 ont ainsi été détectées et corrigées, mais la suite de tests, malgré le grand nombre d’exercices (plus de 60 000) a été écrite avant la réécriture de Bun, son périmètre n’est donc pas optimal. En outre, Jarred Sumner ne dit rien des bugs qui ont pu échapper aux instances adversariales bâties sur Claude et qui ont pu être détectés avec d’autres méthodes. Faisons remarquer aussi que les 165 000 dollars présentés comme facture de la migration peuvent être trompeurs : ils n’incluent pas le lourd temps humain de supervision pendant les 11 jours, ni l’infrastructure de calcul, ni le travail de fusion et post-fusion du code.
Ce cas ne peut pas être généralisé. Même si la réécriture de Bun doit s’avérer une franche réussite, elle le devra en bonne partie à la suite de tests indépendants du langage d’implémentation, qui a permis la validation des opérations menées par les agents, en comparant les situations avant et après.
Le résultat ne sera pas non plus un code Rust « idiomatique ». Il sera loin d’être parfait et de répondre aux standards de sécurité auxquels un code dans ce langage peut prétendre, mais le billet est transparent sur la question. Sumner indique que l’objectif était bien la parité comportementale. Le code safe et profitant vraiment de tous les avantages de Rust viendra plus tard, lors de « refactorings ultérieurs ». Il ne donne pas plus de précisions.
Enfin, il ne s’agit clairement pas d’un scénario « lancer et oublier ». Le cas présenté est celui d’un ingénieur senior utilisant des agents comme amplificateurs, pas en remplacement de son expertise. Lancer Fable 5 et lui demander simplement de réécrire du code en Rust n’a aucune chance de donner un résultat approchant.
Le projet Bun disposait d’ailleurs de conditions favorables à la base, comme sa structure pensée pour la portabilité, l’absence de dépendance à des paradigmes très spécifiques au C/C++, ou même le fait que Jarred Sumner est l’auteur principal, travaillant seul sur une bonne partie des tâches.
Un projet C/C++ ancien, avec de multiples contributeurs, des conventions peu claires, des dépendances à des extensions spécifiques de compilateur, ou surtout une suite de tests incomplète ou couplée au langage source, rencontrerait des difficultés bien plus importantes avec cette même méthode. Et les coûts s’envoleraient d’autant.
Bun, un environnement d’exécution JavaScript et un gestionnaire de paquets, a annoncé le 8 juillet une conversion complète de son code vers Rust en un temps record. L’opération a été en grande partie menée grâce à l’utilisation de Claude Fable 5. Bien qu’il s’agisse d’un exemple concret en production, il ne peut pas être appliqué à tout type de projet.
Bun est un environnement et un gestionnaire de paquets pour JavaScript. Il est développé avec le langage Zig, est open source et sous licence MIT. Le projet est relativement récent sur la scène du développement, car la version 1.0 stable est sortie en septembre 2023. La dernière révision stable est la 1.3, publiée fin 2025. Elle a notamment ajouté le remplacement à chaud des modules (Bun est également un groupeur de modules, ou module bundler).
Les projecteurs se sont brusquement braqués sur Bun au même moment, quand Anthropic a annoncé son rachat. Une opération logique pour Anthropic, Bun étant déjà utilisé pour certains composants de Claude Code.
Et voilà que Bun vient d’annoncer la réécriture complète de son code Zig en Rust… en seulement 11 jours, entre les 3 et 14 mai.
Dans son billet, Jarred Sumner, à la tête du développement de Bun, explique que la version initiale de Bun avait été écrite en un an et en Zig, avant l’apparition des LLM. Aujourd’hui, le CLI (interface en ligne de commande) de Bun est téléchargé 22 millions de fois par mois. Alors pourquoi une réécriture totale en Rust ?
Selon Sumner, le choix n’est pas idéologique, mais motivé par une liste précise de bugs récurrents dans la version Zig : des dizaines de bugs de type use-after-free (le noyau réutilise un pan de mémoire qu’il a déjà libéré), double-free (double utilisation de la fonction free() sur la même adresse mémoire) et fuites mémoire dans des modules critiques (node:zlib, node:http2, UDPSocket, crypto.scrypt, TLS…).
L’argument central de Sumner est que Zig, comme le C, ne gère pas la mémoire pour vous, et ne dispose pas de constructeurs/destructeurs. Le nettoyage repose sur le mot-clé explicite defer. Il est manuel et il faut donc penser à l’utiliser, rendant l’erreur humaine quasi inévitable à grande échelle.
« Chaque allocation mémoire doit être examinée avec minutie. Où ces octets sont-ils libérés ? Comment s’assurer qu’il ne soit libéré qu’une seule fois ? Avons-nous bien vérifié les exceptions JavaScript ? Ce pointeur collecté à la poubelle est-il visible pour le scanner de pile conservateur ? Est-ce de la mémoire récupérée ou de la mémoire gérée manuellement ? », liste Jarred Sumner, parmi les questions récurrentes.
Après avoir envisagé le C++, il se tourne finalement vers le Rust, car une bonne partie des problèmes rencontrés sont liés à la gestion de la mémoire. Avec le « nouveau » langage, loué pour la sécurité induite justement en mémoire, ces problèmes apparaissent à la compilation. Encore faut-il que le code soit en Rust « sûr » (safe).
Sumner aborde d’ailleurs ce point. 4 % du code Rust de Bun se trouvaient ainsi dans un bloc unsafe, soit environ 13 000 mots-clés unsafe dans environ 27 000 lignes sur un total d’environ 780 000. La totalité du code ne peut pas être en Rust safe, car Bun continue d’embarquer des dépendances C/C++ significatives, comme JavaScriptCore, uWebSockets, BoringSSL, SQLite et lshpack/lsquic.
Le rôle prépondérant de Claude Fable 5
Le billet détaille amplement les méthodes utilisées. Par exemple, le choix d’une réécriture complète (plutôt qu’incrémentale) a été motivé par la propre expérience de Jarred Sumner dans ce type d’opération, et par la disponibilité d’une suite de tests indépendante du langage d’implémentation. Selon Sumner, elle a permis de garder un filet de sécurité comportemental identique pour l’avant/après.
On apprend en outre que la « revue adversariale » a été faite par deux instances Claude en contexte séparé, chargées de débusquer les bugs et présentées comme le mécanisme central de contrôle qualité. Et c’est justement la présence de Fable 5 au cœur du mécanisme qui rend l’annonce si visible.
La version de test a été produite en 11 jours. Les chiffres associés sont impressionnants : 5,9 milliards de tokens d’entrée non mis en cache, 690 millions de tokens de sortie, et 72 milliards de tokens d’entrée lus en cache. Soit environ 165 000 dollars au tarif de l’API, contre une estimation d’environ un an de travail pour trois ingénieurs à temps plein sur le code existant pour les 535 496 lignes de code, selon Jarred Sumner.
Source : Bun
Cette performance – en moyenne 1 300 lignes de code à la minute – concerne cependant la phase de génération brute, pas le code fonctionnel. Le billet précise qu’à ce stade, « absolument rien ne fonctionnait encore ». Une performance à relativiser également sur l’utilisation du LLM, car elle n’avait rien de « naïf ». L’orchestration humaine a été lourde, avec environ 50 flux de travail dynamiques et jusqu’à 64 instances de Claude en parallèle, réparties en quatre arbres de travail (worktrees). Sumner dit avoir lui-même surveillé manuellement les sorties pendant l’essentiel des 11 jours de travail.
Le billet documente aussi des échecs répétés du modèle dans des cas précis : interprétation erronée de consignes, ajout de commentaires justificatifs longs pour masquer des contournements… Un comportement suffisamment problématique pour que Sumner ait fini par ajouter une règle explicite aux réviseurs adversariaux : « Si vous avez besoin d’un paragraphe entier pour justifier qu’un contournement est correct, c’est que le code n’est pas bon – corrigez le code ».
Bon… et alors ?
Selon Jarred Sumner, les avantages de Rust sont évidents dans la préversion. Allègement des binaires, consommation de mémoire réduite, résolution de nombreux bugs liés à la mémoire existants dans la version actuelle 1.3.14… Sur le plan des performances, les gains sont plus mesurés, avec 2 à 5 % en moyenne selon les scénarios.
Jarred Sumner veut pour preuve de sa réussite que la version 2.1.181 de Claude Code, publiée le 17 juin, utilise la version de Bun réécrite en Rust. Cela signifie-t-il que tout est parfait et que tout le monde devrait se lancer dans le même type d’opération ? Pas du tout.
Le billet de Bun est assez transparent sur les défis restants. Bun 1.4.0 sera bien la première version intégralement en Rust et des corrections continueront pendant toute la phase de test. Mais plusieurs éléments méritent d’être soulignés, dont le caractère même du billet : intéressant dans le retour d’expérience qu’il rapporte, mais qui reste une communication d’entreprise puisque Jarred Sumner travaille pour Anthropic et a pu bénéficier de Fable 5 quand presque plus personne n’y avait droit en mai.
On pourrait souligner également que des régressions peuvent apparaître avant et après la version finale. 19 ont ainsi été détectées et corrigées, mais la suite de tests, malgré le grand nombre d’exercices (plus de 60 000) a été écrite avant la réécriture de Bun, son périmètre n’est donc pas optimal. En outre, Jarred Sumner ne dit rien des bugs qui ont pu échapper aux instances adversariales bâties sur Claude et qui ont pu être détectés avec d’autres méthodes. Faisons remarquer aussi que les 165 000 dollars présentés comme facture de la migration peuvent être trompeurs : ils n’incluent pas le lourd temps humain de supervision pendant les 11 jours, ni l’infrastructure de calcul, ni le travail de fusion et post-fusion du code.
Ce cas ne peut pas être généralisé. Même si la réécriture de Bun doit s’avérer une franche réussite, elle le devra en bonne partie à la suite de tests indépendants du langage d’implémentation, qui a permis la validation des opérations menées par les agents, en comparant les situations avant et après.
Le résultat ne sera pas non plus un code Rust « idiomatique ». Il sera loin d’être parfait et de répondre aux standards de sécurité auxquels un code dans ce langage peut prétendre, mais le billet est transparent sur la question. Sumner indique que l’objectif était bien la parité comportementale. Le code safe et profitant vraiment de tous les avantages de Rust viendra plus tard, lors de « refactorings ultérieurs ». Il ne donne pas plus de précisions.
Enfin, il ne s’agit clairement pas d’un scénario « lancer et oublier ». Le cas présenté est celui d’un ingénieur senior utilisant des agents comme amplificateurs, pas en remplacement de son expertise. Lancer Fable 5 et lui demander simplement de réécrire du code en Rust n’a aucune chance de donner un résultat approchant.
Le projet Bun disposait d’ailleurs de conditions favorables à la base, comme sa structure pensée pour la portabilité, l’absence de dépendance à des paradigmes très spécifiques au C/C++, ou même le fait que Jarred Sumner est l’auteur principal, travaillant seul sur une bonne partie des tâches.
Un projet C/C++ ancien, avec de multiples contributeurs, des conventions peu claires, des dépendances à des extensions spécifiques de compilateur, ou surtout une suite de tests incomplète ou couplée au langage source, rencontrerait des difficultés bien plus importantes avec cette même méthode. Et les coûts s’envoleraient d’autant.
Dans une note technique publiée le 7 juillet, Apple commence à informer d’un changement important à venir dans la mouture 28 de macOS, qui sortira l’année prochaine : la fin de la prise en charge des volumes en HFS+ chiffrés. Ces derniers ne pourront plus être montés dans le système : ils n’apparaitront tout simplement plus.
On y apprend que dès macOS 26 – la version actuelle – des avertissements vont être affichés pour les personnes concernées. Le système de fichiers HFS+ (aussi appelé HFS Extended ou Mac OS Étendu) a longtemps été utilisé sur les Mac. Il a depuis plusieurs années été remplacé par défaut par APFS, pensé pour la mémoire flash et disposant de fonctions plus modernes : schéma de partition GPT (GUID Partition Table), instruction TRIM, inodes 64 bits, instantanés (snapshots), ou encore chiffrement intégral ou par fichier.
Les volumes HFS+ chiffrés sont donc anciens. Il peut s’agir de Mac dont la transition vers APFS n’a pas été faite, ou plus probablement de périphériques de stockage sur lesquels cette opération n’a pas eu lieu.
Apple précise que la notification émise par macOS pointera directement le volume concerné. On peut quand même vérifier manuellement quel système de fichiers est utilisé sur ses volumes via les manipulations suivantes :
ouvrir l’Utilitaire de disque, dans Applications > Utilitaires ;
dans le menu Affichage de la barre de menu, choisir « Afficher uniquement les volumes » ;
dans la barre latérale de l’Utilitaire de disque, sélectionner le nom du volume ;
chercher les informations affichées directement en-dessous du nom de volume à droite : si « Mac OS Extended » et « Encrypted » apparaissent tous deux, le volume sera concerné par la fin de prise en charge.
Pour s’éviter une rupture dans l’utilisation, il n’y a que deux solutions possibles : déchiffrer le disque ou reformater. Le déchiffrement est l’opération la plus rapide et Apple en donne la marche à suivre dans sa note. Car si le HFS+ chiffré n’est plus supporté, le HFS+ classique le sera encore. L’autre solution est de reformater le volume en APFS ou en HFS+, mais l’opération nécessite des déplacements de données. Pour les supports utilisés régulièrement, Apple recommande le reformatage en APFS.
S’agissant d’anciennes technologies, il est probable que peu de personnes soient concernées. L’avertissement devrait remplir son office, car il reste plus d’un an avant l’abandon de la version chiffrée du HFS+.
Dans une note technique publiée le 7 juillet, Apple commence à informer d’un changement important à venir dans la mouture 28 de macOS, qui sortira l’année prochaine : la fin de la prise en charge des volumes en HFS+ chiffrés. Ces derniers ne pourront plus être montés dans le système : ils n’apparaitront tout simplement plus.
On y apprend que dès macOS 26 – la version actuelle – des avertissements vont être affichés pour les personnes concernées. Le système de fichiers HFS+ (aussi appelé HFS Extended ou Mac OS Étendu) a longtemps été utilisé sur les Mac. Il a depuis plusieurs années été remplacé par défaut par APFS, pensé pour la mémoire flash et disposant de fonctions plus modernes : schéma de partition GPT (GUID Partition Table), instruction TRIM, inodes 64 bits, instantanés (snapshots), ou encore chiffrement intégral ou par fichier.
Les volumes HFS+ chiffrés sont donc anciens. Il peut s’agir de Mac dont la transition vers APFS n’a pas été faite, ou plus probablement de périphériques de stockage sur lesquels cette opération n’a pas eu lieu.
Apple précise que la notification émise par macOS pointera directement le volume concerné. On peut quand même vérifier manuellement quel système de fichiers est utilisé sur ses volumes via les manipulations suivantes :
ouvrir l’Utilitaire de disque, dans Applications > Utilitaires ;
dans le menu Affichage de la barre de menu, choisir « Afficher uniquement les volumes » ;
dans la barre latérale de l’Utilitaire de disque, sélectionner le nom du volume ;
chercher les informations affichées directement en-dessous du nom de volume à droite : si « Mac OS Extended » et « Encrypted » apparaissent tous deux, le volume sera concerné par la fin de prise en charge.
Pour s’éviter une rupture dans l’utilisation, il n’y a que deux solutions possibles : déchiffrer le disque ou reformater. Le déchiffrement est l’opération la plus rapide et Apple en donne la marche à suivre dans sa note. Car si le HFS+ chiffré n’est plus supporté, le HFS+ classique le sera encore. L’autre solution est de reformater le volume en APFS ou en HFS+, mais l’opération nécessite des déplacements de données. Pour les supports utilisés régulièrement, Apple recommande le reformatage en APFS.
S’agissant d’anciennes technologies, il est probable que peu de personnes soient concernées. L’avertissement devrait remplir son office, car il reste plus d’un an avant l’abandon de la version chiffrée du HFS+.
Apple a cessé de signer le firmware du modem associé à plusieurs vieilles versions d’iOS, empêchant ainsi la restauration logicielle d’anciens iPhone et iPad cellulaires. Les appareils en question restent utilisables, même si on doute que beaucoup soient encore en circulation aujourd’hui. On parle en effet de modèles sortis il y a une quinzaine d’années.
Le changement est plus limité qu’un arrêt classique de signature, une procédure de validation confiée aux serveurs d’Apple au moment de l’installation ou de la restauration. Quand on restaure un iPhone ou un iPad, l’appareil contacte le constructeur pour vérifier que la version du système d’exploitation et certains composants (comme le firmware du modem) sont bien autorisés pour installation. Si Apple ne signe plus cette version ou un composant logiciel, la restauration est bloquée. Il n’est plus possible non plus de procéder à une installation propre de ces OS.
Une liste qui ne rajeunira personne
Apple ne publie pas de liste officielle des version d’iOS signées ou non signées. Il est cependant possible d’obtenir cette information par des voies détournées, ce qui permet à MacRumors de fournir la liste des appareils et des systèmes d’exploitation concernés.
Il s’agit de l’iPhone 4 CDMA (vendu par Verizon en 2011), sur lequel il n’est plus possible de restaurer l’image système IPSW iOS 7.1.2 depuis un Mac. L’iPhone 4S est lui aussi privé de restauration avec les versions « over the air » (OTA) d’iOS 6.1.3 et 8.4.1, ainsi qu’avec les IPSW iOS 9.3.5 et 9.3.6. C’est également le cas de l’iPhone 5 (iOS 8.4.1 en OTA, iOS 10.3.3/iOS 10.3.4 en IPSW) et de l’iPhone 5c (iOS 10.3.3 IPSW).
Du côté des iPad, seuls les modèles cellulaires sont touchés. Cela concerne l’iPad 2 avec iOS 6.1.3/8.4.1 OTA, ainsi qu’iOS 9.3.5/9.3.6 IPSW ; l’iPad 3 (iOS 8.4.1 OTA et iOS 9.3.5/9.3.6 IPSW) ; l’iPad 4e génération (iOS 8.4.1 OTA, iOS 10.3.3/10.3.4 IPSW) ; l’iPad mini (iOS 8.4.1 OTA, iOS 9.3.5/9.3.6 IPSW). Apple n’a commencé à décliner iOS dans une version spécifique à l’iPad (iPadOS) qu’à partir de 2019 et iPadOS 13.
Une tuile pour les bidouilleurs
Puisque le changement porte sur le baseband, les iPad uniquement Wi-Fi ne sont pas concernés par ce retrait de signature : ils n’ont pas de modem cellulaire, donc pas de firmware baseband à valider.
IPSW, qui signifie simplement « iPhone Software », est l’image système utilisée pour restaurer ou mettre à jour un appareil depuis un Mac, un PC, iTunes, ou encore l’app Appareils Apple. On peut télécharger les différentes IPSW pour iPhone et iPad sur le site référence en la matière, IPSW.me, qui ne reflète cependant pas encore ces changements de signature.
Apple fournit aussi des mises à jour OTA signées qui s’installent directement sur l’appareil. Le constructeur pouvait encore signer certaines versions d’iOS quand elles servaient d’étape intermédiaire. C’était le cas d’iOS 8.4.1 qui permettait à certains terminaux à faire la transition vers iOS 9. Elle était aussi utilisée comme point de retour pour les restaurations. C’est une porte qui se referme pour les appareils cités.
Au vu de l’ancienneté de ces terminaux et de ces systèmes d’exploitation, l’arrêt de la signature ne sera pas un problème pour la vaste majorité des utilisateurs de produits Apple. Ce d’autant qu’encore une fois, ils restent fonctionnels. Mais il n’y aura aucune solution en cas de problème qui nécessiterait normalement une restauration ou une installation propre d’iOS.
Ce sera un souci pour les collectionneurs et les bidouilleurs qui veulent conserver ou restaurer de vieux appareils dans un état logiciel précis. Les développeurs qui testent encore d’anciennes versions pour s’assurer de la compatibilité de leurs applications seront aussi dans la panade, comme ceux qui se servent encore de ces iPhone et iPad comme machines de secours.
Apple a cessé de signer le firmware du modem associé à plusieurs vieilles versions d’iOS, empêchant ainsi la restauration logicielle d’anciens iPhone et iPad cellulaires. Les appareils en question restent utilisables, même si on doute que beaucoup soient encore en circulation aujourd’hui. On parle en effet de modèles sortis il y a une quinzaine d’années.
Le changement est plus limité qu’un arrêt classique de signature, une procédure de validation confiée aux serveurs d’Apple au moment de l’installation ou de la restauration. Quand on restaure un iPhone ou un iPad, l’appareil contacte le constructeur pour vérifier que la version du système d’exploitation et certains composants (comme le firmware du modem) sont bien autorisés pour installation. Si Apple ne signe plus cette version ou un composant logiciel, la restauration est bloquée. Il n’est plus possible non plus de procéder à une installation propre de ces OS.
Une liste qui ne rajeunira personne
Apple ne publie pas de liste officielle des version d’iOS signées ou non signées. Il est cependant possible d’obtenir cette information par des voies détournées, ce qui permet à MacRumors de fournir la liste des appareils et des systèmes d’exploitation concernés.
Il s’agit de l’iPhone 4 CDMA (vendu par Verizon en 2011), sur lequel il n’est plus possible de restaurer l’image système IPSW iOS 7.1.2 depuis un Mac. L’iPhone 4S est lui aussi privé de restauration avec les versions « over the air » (OTA) d’iOS 6.1.3 et 8.4.1, ainsi qu’avec les IPSW iOS 9.3.5 et 9.3.6. C’est également le cas de l’iPhone 5 (iOS 8.4.1 en OTA, iOS 10.3.3/iOS 10.3.4 en IPSW) et de l’iPhone 5c (iOS 10.3.3 IPSW).
Du côté des iPad, seuls les modèles cellulaires sont touchés. Cela concerne l’iPad 2 avec iOS 6.1.3/8.4.1 OTA, ainsi qu’iOS 9.3.5/9.3.6 IPSW ; l’iPad 3 (iOS 8.4.1 OTA et iOS 9.3.5/9.3.6 IPSW) ; l’iPad 4e génération (iOS 8.4.1 OTA, iOS 10.3.3/10.3.4 IPSW) ; l’iPad mini (iOS 8.4.1 OTA, iOS 9.3.5/9.3.6 IPSW). Apple n’a commencé à décliner iOS dans une version spécifique à l’iPad (iPadOS) qu’à partir de 2019 et iPadOS 13.
Une tuile pour les bidouilleurs
Puisque le changement porte sur le baseband, les iPad uniquement Wi-Fi ne sont pas concernés par ce retrait de signature : ils n’ont pas de modem cellulaire, donc pas de firmware baseband à valider.
IPSW, qui signifie simplement « iPhone Software », est l’image système utilisée pour restaurer ou mettre à jour un appareil depuis un Mac, un PC, iTunes, ou encore l’app Appareils Apple. On peut télécharger les différentes IPSW pour iPhone et iPad sur le site référence en la matière, IPSW.me, qui ne reflète cependant pas encore ces changements de signature.
Apple fournit aussi des mises à jour OTA signées qui s’installent directement sur l’appareil. Le constructeur pouvait encore signer certaines versions d’iOS quand elles servaient d’étape intermédiaire. C’était le cas d’iOS 8.4.1 qui permettait à certains terminaux à faire la transition vers iOS 9. Elle était aussi utilisée comme point de retour pour les restaurations. C’est une porte qui se referme pour les appareils cités.
Au vu de l’ancienneté de ces terminaux et de ces systèmes d’exploitation, l’arrêt de la signature ne sera pas un problème pour la vaste majorité des utilisateurs de produits Apple. Ce d’autant qu’encore une fois, ils restent fonctionnels. Mais il n’y aura aucune solution en cas de problème qui nécessiterait normalement une restauration ou une installation propre d’iOS.
Ce sera un souci pour les collectionneurs et les bidouilleurs qui veulent conserver ou restaurer de vieux appareils dans un état logiciel précis. Les développeurs qui testent encore d’anciennes versions pour s’assurer de la compatibilité de leurs applications seront aussi dans la panade, comme ceux qui se servent encore de ces iPhone et iPad comme machines de secours.
Le prochain macOS, alias Golden Gate, fournira plusieurs améliorations à sa virtualisation. Parmi elles, le très demandé accès aux périphériques USB ou encore les images disque en calques.
macOS expose aujourd’hui deux couches de virtualisation. La couche basse, Hypervisor.framework, donne un accès quasi brut aux extensions de virtualisation matérielle du processeur (VT-x sur Intel, EL2 sur Apple Silicon) sans imposer de modèle de périphériques. Tout éditeur tiers peut choisir de construire une solution de virtualisation basée sur cet hyperviseur.
La couche haute, Virtualization.framework, fournit au contraire un ensemble complet et prêt à l’emploi de périphériques virtuels (disque, réseau, GPU paravirtualisé, etc.), pensé pour des applications qui veulent créer rapidement des VM macOS ou Linux sans réinventer tout le modèle matériel.
C’est sur cette seconde couche que les améliorations ont été annoncées durant une session technique de la dernière WWDC, même si ces informations étaient restées discrètes jusqu’ici. Les annonces autour de l’intelligence artificielle ont largement éclipsé le reste.
C’est la fonctionnalité la plus demandée par les utilisateurs de machines virtuelles. La prise en charge du stockage externe et d’autres périphériques USB connectés au Mac hôte fonctionne de façon simple : lorsqu’un périphérique compatible est branché pendant qu’une VM tourne, une icône apparaît dans la barre des menus pour autoriser l’affectation à la machine virtuelle. Si cette approbation est donnée, le périphérique devient accessible dans la VM presque immédiatement. Un fonctionnement que l’on retrouve dans de nombreux clients de virtualisation, comme Fusion et Workstation chez VMware ou VirtualBox chez Oracle, et que l’on nomme communément le « passthrough USB ».
Côté API, Apple expose cette fonctionnalité via le framework Accessory Access. Ce dernier permet de faire transiter directement des accessoires USB vers les machines virtuelles et donne à l’utilisateur un contrôle explicite sur les périphériques physiques transmis, comme des disques externes. L’entitlement associé est com.apple.developer.accessory-access.usb. Un entitlement est une paire clé-valeur signée numériquement qui accorde à une application une autorisation spécifique au-delà de ce que permet par défaut la sandbox de macOS ou iOS, comme l’explique Apple dans sa documentation.
Ce fonctionnement répond à un principe de moindre privilège très classique : par défaut, une application sandboxée (confinée) n’a accès qu’à son propre conteneur et ne peut pas, par exemple, lire des fichiers arbitraires sur le disque, ouvrir une connexion réseau brute ou accéder à des périphériques matériels.
Des images disque en calques
Voilà un autre changement important dans macOS 27. Jusqu’à présent, chaque VM reposait sur une image disque unique et autonome, au format brut (raw) ou ASIF (Apple Sparse Image Format, inauguré avec macOS 26). L’introduction de DiskImageKit change la donne car il permet de construire une pile d’images où les écritures vont dans une couche de superposition (overlay) sans modifier la couche de base. Il prend également en charge les images disque brutes.
Comme l’indique Apple, l’architecture distingue plusieurs types de couches : la couche de base peut être dans n’importe quel format pris en charge par DiskImageKit, tandis que les couches supérieures sont toujours au format ASIF et peuvent être soit des couches de cache, soit des couches de superposition. Une couche de cache fait ce qu’est toujours censé faire un cache : améliorer les performances. Dans le cas présent, elles peuvent être mises en place lorsque les couches sous-jacentes résident sur un support lent comme un système de fichiers réseau distant, en stockant une copie des données lues depuis les couches inférieures.
Concrètement, la couche de base contient un socle en lecture seule – comme le volume Système de macOS – qui peut être partagé entre plusieurs VM et stocké sur un support plus lent comme un disque dur. Au-dessus se greffe une couche de superposition en lecture-écriture qui stocke les fichiers additionnels et les modifications apportées aux données de la couche de base. On est clairement dans le fonctionnement général des instantanés (snapshots).
Ainsi, au lieu d’avoir plusieurs gros fichiers de 60 Go, on peut n’avoir qu’une seule base de 50 Go et autant de couches de superposition que nécessaire pour gérer les modifications, comme le pointe notamment MacGeneration. Un fonctionnement plus souple qui peut entrainer des gains conséquents sur le stockage. À noter que sur le site Eclectic Light, certains commentaires soulignent des carences dans l’implémentation actuelle. Par exemple, l’absence de mécanisme pour aplatir (« flatten ») les couches de superposition et les fusionner dans l’image de base.
Du provisionnage automatique pour les invités
Depuis que macOS fournit des capacités de virtualisation, la création du compte administrateur exige de passer manuellement par l’assistant de configuration à chaque nouvelle VM. Mais la nouvelle API VZMacGuestProvisioningOptions permet de définir des identifiants et d’activer des fonctions comme la connexion automatique et SSH dès le premier démarrage.
Le mécanisme technique consiste à construire un objet VZMacGuestProvisioningOptions, à l’attacher à un objet VZMacOSVirtualMachineStartOptions via sa propriété de « guest provisioning » (provisionnage d’invité), puis à démarrer la VM avec ces options. Au premier démarrage, ces paramètres sont automatiquement transmis à l’assistant de configuration, qui crée l’utilisateur avec les identifiants indiqués et active la connexion automatique et l’accès distant si demandé. D’après la documentation d’Apple, cela inclut le nom complet, le nom court, le mot de passe, l’activation ou non de la connexion automatique au démarrage, et l’activation de SSH. Cela ne fonctionne toutefois qu’au premier démarrage de la machine virtuelle.
Autres capacités
Plusieurs autres apports sont mentionnés dans la vidéo dédiée. Par exemple, il est possible désormais de configurer des topologies réseau complexes en intégrant le framework vmnet à Virtualization, pour définir précisément comment plusieurs machines virtuelles interagissent entre elles et avec l’hôte, avec également de la redirection de port.
On note aussi le framework Virtualization, qui permet d’implémenter ses propres périphériques Virtio (protocole standard de l’industrie pour la paravirtualisation), autorisant une communication personnalisée entre l’application hôte et les VM Linux. L’ajout devrait se montrer particulièrement utile pour les scénarios sensibles aux performances, nécessitant une communication à faible latence et fort débit, via la nouvelle classe VZCustomVirtioDevice. Ce point est abordé dans la dernière partie de la vidéo d’Apple.
Ces nouveautés requièrent la préversion de macOS 27 pour les tester. Le système n’est pour l’instant disponible qu’en bêta pour les développeurs (la troisième est sortie ce 6 juillet), mais la bêta publique est prévue pour ce mois-ci, probablement aux alentours du 20 juillet, en même temps que la bêta 4 pour les développeurs.
Le prochain macOS, alias Golden Gate, fournira plusieurs améliorations à sa virtualisation. Parmi elles, le très demandé accès aux périphériques USB ou encore les images disque en calques.
macOS expose aujourd’hui deux couches de virtualisation. La couche basse, Hypervisor.framework, donne un accès quasi brut aux extensions de virtualisation matérielle du processeur (VT-x sur Intel, EL2 sur Apple Silicon) sans imposer de modèle de périphériques. Tout éditeur tiers peut choisir de construire une solution de virtualisation basée sur cet hyperviseur.
La couche haute, Virtualization.framework, fournit au contraire un ensemble complet et prêt à l’emploi de périphériques virtuels (disque, réseau, GPU paravirtualisé, etc.), pensé pour des applications qui veulent créer rapidement des VM macOS ou Linux sans réinventer tout le modèle matériel.
C’est sur cette seconde couche que les améliorations ont été annoncées durant une session technique de la dernière WWDC, même si ces informations étaient restées discrètes jusqu’ici. Les annonces autour de l’intelligence artificielle ont largement éclipsé le reste.
C’est la fonctionnalité la plus demandée par les utilisateurs de machines virtuelles. La prise en charge du stockage externe et d’autres périphériques USB connectés au Mac hôte fonctionne de façon simple : lorsqu’un périphérique compatible est branché pendant qu’une VM tourne, une icône apparaît dans la barre des menus pour autoriser l’affectation à la machine virtuelle. Si cette approbation est donnée, le périphérique devient accessible dans la VM presque immédiatement. Un fonctionnement que l’on retrouve dans de nombreux clients de virtualisation, comme Fusion et Workstation chez VMware ou VirtualBox chez Oracle, et que l’on nomme communément le « passthrough USB ».
Côté API, Apple expose cette fonctionnalité via le framework Accessory Access. Ce dernier permet de faire transiter directement des accessoires USB vers les machines virtuelles et donne à l’utilisateur un contrôle explicite sur les périphériques physiques transmis, comme des disques externes. L’entitlement associé est com.apple.developer.accessory-access.usb. Un entitlement est une paire clé-valeur signée numériquement qui accorde à une application une autorisation spécifique au-delà de ce que permet par défaut la sandbox de macOS ou iOS, comme l’explique Apple dans sa documentation.
Ce fonctionnement répond à un principe de moindre privilège très classique : par défaut, une application sandboxée (confinée) n’a accès qu’à son propre conteneur et ne peut pas, par exemple, lire des fichiers arbitraires sur le disque, ouvrir une connexion réseau brute ou accéder à des périphériques matériels.
Des images disque en calques
Voilà un autre changement important dans macOS 27. Jusqu’à présent, chaque VM reposait sur une image disque unique et autonome, au format brut (raw) ou ASIF (Apple Sparse Image Format, inauguré avec macOS 26). L’introduction de DiskImageKit change la donne car il permet de construire une pile d’images où les écritures vont dans une couche de superposition (overlay) sans modifier la couche de base. Il prend également en charge les images disque brutes.
Comme l’indique Apple, l’architecture distingue plusieurs types de couches : la couche de base peut être dans n’importe quel format pris en charge par DiskImageKit, tandis que les couches supérieures sont toujours au format ASIF et peuvent être soit des couches de cache, soit des couches de superposition. Une couche de cache fait ce qu’est toujours censé faire un cache : améliorer les performances. Dans le cas présent, elles peuvent être mises en place lorsque les couches sous-jacentes résident sur un support lent comme un système de fichiers réseau distant, en stockant une copie des données lues depuis les couches inférieures.
Concrètement, la couche de base contient un socle en lecture seule – comme le volume Système de macOS – qui peut être partagé entre plusieurs VM et stocké sur un support plus lent comme un disque dur. Au-dessus se greffe une couche de superposition en lecture-écriture qui stocke les fichiers additionnels et les modifications apportées aux données de la couche de base. On est clairement dans le fonctionnement général des instantanés (snapshots).
Ainsi, au lieu d’avoir plusieurs gros fichiers de 60 Go, on peut n’avoir qu’une seule base de 50 Go et autant de couches de superposition que nécessaire pour gérer les modifications, comme le pointe notamment MacGeneration. Un fonctionnement plus souple qui peut entrainer des gains conséquents sur le stockage. À noter que sur le site Eclectic Light, certains commentaires soulignent des carences dans l’implémentation actuelle. Par exemple, l’absence de mécanisme pour aplatir (« flatten ») les couches de superposition et les fusionner dans l’image de base.
Du provisionnage automatique pour les invités
Depuis que macOS fournit des capacités de virtualisation, la création du compte administrateur exige de passer manuellement par l’assistant de configuration à chaque nouvelle VM. Mais la nouvelle API VZMacGuestProvisioningOptions permet de définir des identifiants et d’activer des fonctions comme la connexion automatique et SSH dès le premier démarrage.
Le mécanisme technique consiste à construire un objet VZMacGuestProvisioningOptions, à l’attacher à un objet VZMacOSVirtualMachineStartOptions via sa propriété de « guest provisioning » (provisionnage d’invité), puis à démarrer la VM avec ces options. Au premier démarrage, ces paramètres sont automatiquement transmis à l’assistant de configuration, qui crée l’utilisateur avec les identifiants indiqués et active la connexion automatique et l’accès distant si demandé. D’après la documentation d’Apple, cela inclut le nom complet, le nom court, le mot de passe, l’activation ou non de la connexion automatique au démarrage, et l’activation de SSH. Cela ne fonctionne toutefois qu’au premier démarrage de la machine virtuelle.
Autres capacités
Plusieurs autres apports sont mentionnés dans la vidéo dédiée. Par exemple, il est possible désormais de configurer des topologies réseau complexes en intégrant le framework vmnet à Virtualization, pour définir précisément comment plusieurs machines virtuelles interagissent entre elles et avec l’hôte, avec également de la redirection de port.
On note aussi le framework Virtualization, qui permet d’implémenter ses propres périphériques Virtio (protocole standard de l’industrie pour la paravirtualisation), autorisant une communication personnalisée entre l’application hôte et les VM Linux. L’ajout devrait se montrer particulièrement utile pour les scénarios sensibles aux performances, nécessitant une communication à faible latence et fort débit, via la nouvelle classe VZCustomVirtioDevice. Ce point est abordé dans la dernière partie de la vidéo d’Apple.
Ces nouveautés requièrent la préversion de macOS 27 pour les tester. Le système n’est pour l’instant disponible qu’en bêta pour les développeurs (la troisième est sortie ce 6 juillet), mais la bêta publique est prévue pour ce mois-ci, probablement aux alentours du 20 juillet, en même temps que la bêta 4 pour les développeurs.
La nouvelle mouture de TypeScript est annoncée avec des performances largement revues à la hausse. L’essentiel des nouveautés se concentre sur ces gains, le langage n’apportant rien de vraiment neuf sur les types et la syntaxe.
Ce n’est pas tous les jours que l’on peut annoncer des hausses majeures de performances sur des technologies. Microsoft vient pourtant de lancer la version 7.0 de son langage open source TypeScript, un surensemble de JavaScript sous licence Apache 2.0. Depuis sa sortie, le langage a rencontré un grand succès.
Hop, une division par 10
La plus grosse nouveauté de TypeScript 7.0 est son compilateur. Ce dernier était lui-même compilé en TypeScript/JavaScript jusqu’ici, mais c’est fini : le nouveau est écrit en Go. Le code produit est strictement le même, mais avec une différence de taille : le temps de compilation est en moyenne divisé par 10. En fonction des cas, ce facteur alterne entre 8 et 12, le gain de temps étant dans tous les cas énorme.
Ce gain de performances rejaillit sous de nombreux aspects. La compilation complète bien sûr, en passant de plusieurs dizaines de secondes à quelques secondes, mais aussi une réaction beaucoup plus rapide de tsc –watch, l’accélération de l’analyse des types ou encore une consommation de mémoire vive revue à la baisse, le plus souvent entre 5 et 25 % selon les cas.
Source : Microsoft
Microsoft insiste également sur la solidité de cette version, car elle a bénéficié d’une année de tests. Ces derniers ont aussi bien lieu avec d’autres équipes de Microsoft (Loop, Office, PowerBI, Teams ou encore Xbox) qu’avec des entreprises tierces : Bloomberg, Canva, Figma, Google, Lattice, Linear, Miro, Notion, Sentry, Slack, Vanta, Vercel, VoidZero et autres. Les retours auraient été unanimes : des gains de temps conséquents et des économies de ressources.
La nouvelle version a en outre des conséquences positives sur Visual Studio Code. Dans un test, Microsoft a pu mesurer que le temps passé à ouvrir un fichier avec une erreur dans Visual Studio Code était réduit à 1,3 seconde, contre 17,5 auparavant, soit une division par 13. L’autocomplétion est aussi plus rapide, la fonction « Go to Definition » est presque instantanée, le renommage va plus vite, les diagnostics apparaissent plus rapidement, etc. Microsoft ajoute que plus les monorepos sont volumineux, plus la différence se sent. Une bonne part de ces améliorations vient d’une parallélisation beaucoup plus importante des instructions.
Une transition « transparente »
On aurait pu s’attendre à de nouvelles fonctions, des types et autres syntaxes, mais cette version 7.0 ne change pratiquement rien de ce côté. La plus grosse partie du travail s’étant concentrée sur les performances, TypeScript 7 reste donc compatible avec la version 6. La migration se veut la plus transparente possible, la nouvelle version n’étant livrée avec aucune API. Celle-ci arrivera avec TypeScript 7.1 mais, en attendant, Microsoft a fait le choix « de garantir que TypeScript puisse être exécuté parallèlement à TypeScript 6.0 pour les utilitaires nécessitant encore un certain accès programmatique au compilateur (comme typescript-eslint) ».
L’éditeur ajoute que dans le cadre de cette transition, un paquet de compatibilité a été publié. Il fournit un exécutable nommé pour que les développeurs puissent installer TypeScript 7.0 (qui publie son propre binaire) côte à côte, sans conflit de nommage. « Le nouveau package réexporte également l’API TypeScript 6.0, afin que vous puissiez l’utiliser pour TypeScript 7, tandis que d’autres outils peuvent continuer à s’appuyer sur la version 6.0 », précise Microsoft.
La nouvelle mouture de TypeScript est annoncée avec des performances largement revues à la hausse. L’essentiel des nouveautés se concentre sur ces gains, le langage n’apportant rien de vraiment neuf sur les types et la syntaxe.
Ce n’est pas tous les jours que l’on peut annoncer des hausses majeures de performances sur des technologies. Microsoft vient pourtant de lancer la version 7.0 de son langage open source TypeScript, un surensemble de JavaScript sous licence Apache 2.0. Depuis sa sortie, le langage a rencontré un grand succès.
Hop, une division par 10
La plus grosse nouveauté de TypeScript 7.0 est son compilateur. Ce dernier était lui-même compilé en TypeScript/JavaScript jusqu’ici, mais c’est fini : le nouveau est écrit en Go. Le code produit est strictement le même, mais avec une différence de taille : le temps de compilation est en moyenne divisé par 10. En fonction des cas, ce facteur alterne entre 8 et 12, le gain de temps étant dans tous les cas énorme.
Ce gain de performances rejaillit sous de nombreux aspects. La compilation complète bien sûr, en passant de plusieurs dizaines de secondes à quelques secondes, mais aussi une réaction beaucoup plus rapide de tsc –watch, l’accélération de l’analyse des types ou encore une consommation de mémoire vive revue à la baisse, le plus souvent entre 5 et 25 % selon les cas.
Source : Microsoft
Microsoft insiste également sur la solidité de cette version, car elle a bénéficié d’une année de tests. Ces derniers ont aussi bien lieu avec d’autres équipes de Microsoft (Loop, Office, PowerBI, Teams ou encore Xbox) qu’avec des entreprises tierces : Bloomberg, Canva, Figma, Google, Lattice, Linear, Miro, Notion, Sentry, Slack, Vanta, Vercel, VoidZero et autres. Les retours auraient été unanimes : des gains de temps conséquents et des économies de ressources.
La nouvelle version a en outre des conséquences positives sur Visual Studio Code. Dans un test, Microsoft a pu mesurer que le temps passé à ouvrir un fichier avec une erreur dans Visual Studio Code était réduit à 1,3 seconde, contre 17,5 auparavant, soit une division par 13. L’autocomplétion est aussi plus rapide, la fonction « Go to Definition » est presque instantanée, le renommage va plus vite, les diagnostics apparaissent plus rapidement, etc. Microsoft ajoute que plus les monorepos sont volumineux, plus la différence se sent. Une bonne part de ces améliorations vient d’une parallélisation beaucoup plus importante des instructions.
Une transition « transparente »
On aurait pu s’attendre à de nouvelles fonctions, des types et autres syntaxes, mais cette version 7.0 ne change pratiquement rien de ce côté. La plus grosse partie du travail s’étant concentrée sur les performances, TypeScript 7 reste donc compatible avec la version 6. La migration se veut la plus transparente possible, la nouvelle version n’étant livrée avec aucune API. Celle-ci arrivera avec TypeScript 7.1 mais, en attendant, Microsoft a fait le choix « de garantir que TypeScript puisse être exécuté parallèlement à TypeScript 6.0 pour les utilitaires nécessitant encore un certain accès programmatique au compilateur (comme typescript-eslint) ».
L’éditeur ajoute que dans le cadre de cette transition, un paquet de compatibilité a été publié. Il fournit un exécutable nommé pour que les développeurs puissent installer TypeScript 7.0 (qui publie son propre binaire) côte à côte, sans conflit de nommage. « Le nouveau package réexporte également l’API TypeScript 6.0, afin que vous puissiez l’utiliser pour TypeScript 7, tandis que d’autres outils peuvent continuer à s’appuyer sur la version 6.0 », précise Microsoft.
L’équipe de développement de Tuxedo OS a annoncé qu’elle abandonnait Ubuntu pour Debian comme base pour sa propre distribution. Parmi les raisons citées, des difficultés à adapter le code vieillissant (LTS), une feuille de route IA jugée « opaque » et surtout l’omniprésence des paquets Snap. Ce n’est pas la première fois que le système de Canonical crispe la scène de l’open source.
Tuxedo est une société allemande commercialisant des ordinateurs. À l’instar de System76 avec Pop!_OS aux États-Unis, l’entreprise a fini par créer sa propre distribution, baptisée Tuxedo OS. Elle est basée sur la branche LTS (Long Term Support) d’Ubuntu, à laquelle elle apporte des personnalisations, notamment pour s’assurer que le matériel de ses ordinateurs est correctement pris en charge. Comme pour System76 toutefois, la distribution est librement téléchargeable depuis le site officiel.
Et voilà que dans un communiqué daté du 7 juillet, l’entreprise annonce qu’elle n’utilisera plus Ubuntu LTS. Plutôt que de passer sur la branche classique de la distribution de Canonical, Tuxedo prend un virage plus radical : elle se basera désormais sur Debian Testing, avec une bêta prévue pour « bientôt ». Les raisons données et le choix dans la bascule ont provoqué de nouveaux débats.
Les raisons de Tuxedo
Dans son billet officiel, l’éditeur évoque son modèle hybride : base Ubuntu LTS stable et composants comme le noyau, les navigateurs, la pile graphique et KDE Plasma mis à jour en continu. Or, cette approche devient intenable à mesure qu’une version LTS vieillit : le rétroportage de logiciels modernes devient de plus en plus difficile, les dépendances plus récentes étant souvent indisponibles ou fournies uniquement dans des versions obsolètes. Tuxedo OS suit un modèle de publication hybride qui combine, selon l’entreprise, les points forts des versions continues et des versions ponctuelles.
La société allemande cite cependant trois autres facteurs, propres à la stratégie de Canonical. D’une part, la difficulté croissante à tenir le système de paquets Snap à l’écart du système, Canonical distribuant de plus en plus d’applications au format Snap exclusivement, tout en reléguant progressivement les paquets DEB traditionnels au second plan.
D’autre part, la feuille de route IA annoncée par Mark Shuttleworth lors du dernier Ubuntu Summit, dont la mise en œuvre concrète reste insuffisamment transparente. Enfin, des mises à jour de sécurité qui, selon Tuxedo, mettent parfois plus de temps que nécessaire à atteindre les utilisateurs.
L’entreprise a donc fait le choix de Debian dans sa branche Testing en continu. Ce qui veut dire qu’à la sortie de la version stable de Debian 14, Tuxedo OS restera sur la branche testing, Debian ayant une approche conservatrice des paquets. Outre la modernisation inhérente aux paquets plus récents, cette bascule permet à Tuxedo OS de récupérer des fonctions qui lui faisaient défaut selon elle, notamment le système de fichiers Btrfs – qui sera utilisé par défaut – et Snapper. L’un et l’autre permettront la création automatique d’instantanés (snapshots) et la restauration simplifiée du système. Ces fonctions ne seront disponibles qu’avec Btrfs.
Tuxedo indique dans son billet que le passage de la version actuelle à la prochaine basée sur Debian ne sera pas possible « pour des raisons techniques ». Elle précise cependant qu’un guide complet de migration sera fourni « bien avant la publication finale » du nouveau système, pour expliquer notamment comment transférer les données personnelles. En revanche, un chemin de migration existera vers Kubuntu 26.04. Lui aussi sera publié plus tard.
Les paquets Snap encore dans la ligne de mire
Hors de la stratégie propre à Canonical sur les versions LTS, les critiques de Tuxedo tournent essentiellement sur les paquets Snap et la feuille de route sur l’IA. Même si Mark Shuttleworth, CEO de Canonical, n’a pas été « assez clair » sur cette feuille lors de la conférence Ubuntu Summit, plusieurs points ont été éclaircis depuis. On sait par exemple que Canonical utilisera des modèles locaux pour renforcer certaines capacités « implicites », comme l’amélioration de l’image de la webcam ou la normalisation du son pour le microphone. L’accessibilité sera également aux premières loges, avec notamment une reconnaissance vocale pour tous les champs de saisie présents à l’écran.
Il reste 62% de l'article à découvrir. Vous devez être abonné•e pour lire la suite de cet article. Déjà abonné•e ? Générez une clé RSS dans votre profil.
Six semaines après la sortie de Vivaldi 8.0 et de sa nouvelle interface, l’équipe livre une version de maintenance, estampillée 8.1, qui intervient principalement pour corriger les erreurs de jeunesse et optimiser le fonctionnement du navigateur. « Cette année est considérée comme une année à moustiques, nous avons donc amené notre spray », plaisante Jon von Tetzchner, CEO et cofondateur de Vivaldi, dans un billet d’annonce.
Outre sa promesse de design unifié au sein des différents éléments de l’interface, Vivaldi 8.0 introduisait en effet de nombreuses petites nouveautés au niveau de la gestion des onglets et de la capacité à masquer automatiquement des éléments non utilisés.
Vivaldi passe en version 8.1, avec déploiement automatique de la mise à jour – capture d’écran Next
Ces fonctionnalités, prometteuses pour les internautes qui aiment pouvoir paramétrer de façon très poussée leur navigateur, ont toutefois entraîné leur lot de dysfonctionnements, comme en témoigne les copieuses notes de version publiées par l’éditeur.
Vivaldi 8.1 passe pour l’occasion sur la branche 150 de Chromium, ce qui se traduit par la disparition des derniers éléments permettant aux extensions basées sur le Manifest V2 de fonctionner.
L’éditeur en profite pour rappeler aux éventuels déçus qu’il embarque son propre outil de blocage des publicités et des outils de suivi comportemental. « Il n’est pas nécessaire d’installer une extension tierce pour accélérer le chargement des pages web et protéger vos appareils contre l’espionnage malveillant », fait valoir Jon von Tetzchner.
Sous Linux, Vivaldi 8.1 profite également d’une version patchée de FFmpeg pour assurer la prise en charge des codecs propriétaires de type H.264 ou AAC.
Six semaines après la sortie de Vivaldi 8.0 et de sa nouvelle interface, l’équipe livre une version de maintenance, estampillée 8.1, qui intervient principalement pour corriger les erreurs de jeunesse et optimiser le fonctionnement du navigateur. « Cette année est considérée comme une année à moustiques, nous avons donc amené notre spray », plaisante Jon von Tetzchner, CEO et cofondateur de Vivaldi, dans un billet d’annonce.
Outre sa promesse de design unifié au sein des différents éléments de l’interface, Vivaldi 8.0 introduisait en effet de nombreuses petites nouveautés au niveau de la gestion des onglets et de la capacité à masquer automatiquement des éléments non utilisés.
Vivaldi passe en version 8.1, avec déploiement automatique de la mise à jour – capture d’écran Next
Ces fonctionnalités, prometteuses pour les internautes qui aiment pouvoir paramétrer de façon très poussée leur navigateur, ont toutefois entraîné leur lot de dysfonctionnements, comme en témoigne les copieuses notes de version publiées par l’éditeur.
Vivaldi 8.1 passe pour l’occasion sur la branche 150 de Chromium, ce qui se traduit par la disparition des derniers éléments permettant aux extensions basées sur le Manifest V2 de fonctionner.
L’éditeur en profite pour rappeler aux éventuels déçus qu’il embarque son propre outil de blocage des publicités et des outils de suivi comportemental. « Il n’est pas nécessaire d’installer une extension tierce pour accélérer le chargement des pages web et protéger vos appareils contre l’espionnage malveillant », fait valoir Jon von Tetzchner.
Sous Linux, Vivaldi 8.1 profite également d’une version patchée de FFmpeg pour assurer la prise en charge des codecs propriétaires de type H.264 ou AAC.
DuckDuckGo se paie un gros coup de pub… en les supprimant de YouTube. La dernière version du navigateur web embarque en effet une nouvelle option permettant de bloquer les réclames sur la plateforme vidéo de Google. Qui doit regarder tout ça d’un œil mauvais.
Depuis 2023, Google mène la lutte contre les bloqueurs de pub. Le mastodonte du web utilise tout l’arsenal possible et imaginable pour forcer les utilisateurs excédés par la réclame à souscrire à un abonnement payant. Mais la vie trouve toujours un chemin : des bidouilles font régulièrement surface pour supprimer les pubs, que Google se fait fort de bloquer.
On verra combien de temps DuckDuckGo tiendra, mais la dernière version du navigateur désactive la publicité sur YouTube, au début d’une vidéo comme au milieu. Cela fonctionne sur Windows, macOS et iOS, avec un réglage activé par défaut. Sur Android, il faut l’activer à la main, mais l’option sera également proposée par défaut dans quelque temps.
DuckDuckGo proposait déjà une option pour regarder des vidéos sans pause publicitaire, via le Duck Player, un lecteur embarqué dans le navigateur. Ce dernier n’a pas disparu, il est simplement complémentaire : en plus de supprimer les pubs, le Player empêche le traçage de YouTube. Les vidéos regardées dans le lecteur Duck n’alimentent donc pas les recommandations de la plateforme.
La nouvelle fonction de blocage des pubs conserve « l’expérience » YouTube dans sa totalité, modulo la publicité. Il est possible d’utiliser les deux fonctionnalités simultanément.
DuckDuckGo bloque les publicités YouTube grâce à des listes de filtres communautaires issues d’uBlock Origin. Elles sont régulièrement mises à jour par la communauté. Le service du navigateur peut aussi ajouter ses propres règles pour éviter les bugs et améliorer la compatibilité. Comme avec beaucoup de bloqueurs de pub, cela peut rallonger un peu le temps de chargement des vidéos, mais la lecture se fait ensuite sans être embêté par la réclame.
Connexion
