À balles réelles

Un lourd rapport a été publié ce 15 juillet, suite aux travaux de la commission lancée en février pour analyser les dépendances structurelles et les vulnérabilités systémiques dans le secteur du numérique et les risques pour l’indépendance de la France. Cette commission, présidée par Philippe Latombe avec Cyrielle Chatelain comme rapporteure, pointe six grandes catégories de failles et liste de nombreuses recommandations, dont certaines radicales.

Cet épais rapport sur la souveraineté numérique de 453 pages est le fruit d’un travail ayant réuni 26 députés issus de l’ensemble des groupes politiques. Le rapport a été adopté le 8 juillet, à l’issue de 45 auditions, 112 personnes ayant été entendues. Une semaine plus tard, le rapport est en ligne et une conférence de presse a été organisée pour en brosser les grandes lignes.

Constats amers

Dès l’avant-propos, Philippe Latombe donne le ton. Lui qui est également président de la commission chargée d’examiner le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité situe le rapport dans la continuité d’une mission d’information qu’il avait déjà consacrée à la souveraineté numérique en 2021. Le propos se fait volontiers acide : « Mon principal regret reste sans doute qu’il ait fallu attendre l’ère MAGA pour qu’un plus grand nombre de politiques et de groupes parlementaires s’intéresse aux dépendances structurelles et aux vulnérabilités systémiques de la France dans le secteur du numérique, ainsi qu’aux risques pour l’indépendance et la souveraineté de notre pays ».

Le député dit avoir été « peu suivi » et « trop souvent cantonné au rôle de Cassandre ». À ceci près que le personnage mythologique « n’avait à alerter que sur un cheval de Troie, alors que nous devons faire face à une multitude de vulnérabilités : fournisseurs américains de cloud, systèmes d’exploitation étrangers, nombreux composants électroniques asiatiques, infrastructures internet mondiales… ».

L’introduction situe ensuite le périmètre retenu. D’une part, les administrations publiques et les entreprises d’intérêt vital, jugées prioritaires en raison de leur criticité. D’autre part une approche plus large des « dépendances systémiques », couvrant six familles de vulnérabilités. La commission indique explicitement ne pas avoir traité en détail la cybersécurité proprement dite ni les dépendances matérielles, qui font l’objet de travaux distincts.

Les six catégories de vulnérabilités sont les suivantes :

• les failles démocratiques à travers les ingérences et la désinformation. Les algorithmes de recommandation des plateformes privées sont pointés du doigt, dont celui de X au travers des travaux menés par Germain Gauthier, directeur de recherche au CNRS : jusqu’à 15 % des électeurs indépendants peuvent changer d’opinion après une exposition aux réseaux sociaux ;
• l’exploitation des failles techniques dans les administrations et les entreprises, et le torrent d’attaques cyber qui en découle, avec pour preuve les multiples fuites référencées ces dernières années ;
• la quantité croissante de données à stocker et à protéger, avec les trois thématiques liées : légalité des traitements opérés (RGPD), extraterritorialité du droit (tout particulièrement américain) et captation des données ;
• la primauté du profit sur les libertés individuelles, qui entraîne violation de la vie privée, exposition à des contenus nocifs et développement d’algorithmes addictifs ;
• le verrouillage et la dépendance des utilisateurs, pratique jugée comme étant « au cœur des stratégies des fournisseurs de logiciels » ;
• les vulnérabilités liées aux infrastructures et aux composants clés.

Où en sont les administrations françaises ?

C’est le chapitre le plus documenté du rapport. La méthodologie a reposé sur des questionnaires envoyés à l’ensemble des directions numériques ministérielles (annexe 2), complétés par des auditions des directeurs des systèmes d’information.

Il en est notamment ressorti que sur les 466 applications métiers recensées dans l’administration (liste non exhaustive), les deux tiers ont été développées spécifiquement pour les besoins associés, dont 57 % par des prestataires externes. L’analyse croisée par pays d’origine montre que les fournisseurs français dominent largement les applications les plus critiques : 69 % pour la catégorie 1 (atteinte à l’ordre public, sécurité, vie des personnes) et 83 % pour la catégorie 2 (interruption d’une mission de service public essentielle), soit respectivement 81 et 228 applications. Les États-Unis arrivant en deuxième position avec 7 et 12 applications respectivement.

WhatsApp travaille sur un système de sauvegarde en ligne des conversations sur ses propres serveurs, avec chiffrement de bout en bout. Et ce, aussi bien sur Android que sur iOS. Un moyen de libérer de l’espace dans Google Drive et iCloud, et d’imaginer des restaurations entre les deux plateformes.

Jusqu’à présent, la sauvegarde des conversations de WhatsApp se déroule soit dans Google Drive (sur Android), ou iCloud (sur iOS). Une solution simple, mais qui se heurte souvent aux limites de l’enveloppe de stockage des deux services : 15 Go pour le premier, 5 Go pour le second. Et cet espace est partagé avec d’autres données et documents.

Les utilisateurs de WhatsApp friands de partage de photos, de vidéos et de lourds fichiers frappent assez vite ce plafond de verre. Pour aller au-delà, il faut mettre la main à la poche : à partir d’1,99 euro par mois chez Google pour 100 Go, contre 0,99 euro pour 50 Go sur iCloud. WhatsApp travaille sur une solution maison : la sauvegarde des discussions sur ses propres serveurs, comme l’a repéré WABetaInfo en fouillant dans le code des bêtas de WhatsApp.

Le principe sur les deux plateformes est le même. L’application propose de sélectionner un fournisseur pour la sauvegarde : Google Drive ou iCloud en fonction de l’appareil, ainsi que son propre service de stockage. Tout cela peut encore évoluer, voire être abandonné : la fonction en est encore aux premières étapes de son développement et n’est pas proposée aux bêta-testeurs. Les premières traces de cette fonction remontent au mois d’avril sur Android, et tout récemment sur iOS.

Actuellement, WhatsApp envisagerait 2 Go de stockage de base, sans frais supplémentaires. Avec 3 milliards d’utilisateurs, la messagerie peut difficilement faire plus, mais là aussi les utilisateurs les plus gourmands risquent d’être rapidement pris au dépourvu. C’est pourquoi WhatsApp proposerait de gonfler l’enveloppe contre une petite contribution sonnante et trébuchante : 0,99 dollar pour 50 Go, comme chez Apple. Et on pourrait grimper jusqu’à 1 To. Bien sûr, les prix et l’offre peuvent encore évoluer.

On ne sait pas encore ce que WhatsApp fera des anciennes sauvegardes. Sur iOS, celles conservées dans iCloud pourront toujours être supprimées manuellement depuis les réglages. Si l’utilisateur décide de faire confiance aux serveurs de Meta (c’est un grand « si »), les sauvegardes seront chiffrées de bout en bout ; de fait, personne ne pourra y avoir accès, si ce n’est l’utilisateur. Autre utilité de cette fonction : les sauvegardes stockées chez WhatsApp ne seront pas verrouillées à une plateforme. De fait, cela pourrait grandement faciliter la restauration des conversations.

• WhatsApp fait le plein de nouveautés : stockage, comptes multiples, transferts, Meta AI…

WhatsApp travaille sur un système de sauvegarde en ligne des conversations sur ses propres serveurs, avec chiffrement de bout en bout. Et ce, aussi bien sur Android que sur iOS. Un moyen de libérer de l’espace dans Google Drive et iCloud, et d’imaginer des restaurations entre les deux plateformes.

Jusqu’à présent, la sauvegarde des conversations de WhatsApp se déroule soit dans Google Drive (sur Android), ou iCloud (sur iOS). Une solution simple, mais qui se heurte souvent aux limites de l’enveloppe de stockage des deux services : 15 Go pour le premier, 5 Go pour le second. Et cet espace est partagé avec d’autres données et documents.

Les utilisateurs de WhatsApp friands de partage de photos, de vidéos et de lourds fichiers frappent assez vite ce plafond de verre. Pour aller au-delà, il faut mettre la main à la poche : à partir d’1,99 euro par mois chez Google pour 100 Go, contre 0,99 euro pour 50 Go sur iCloud. WhatsApp travaille sur une solution maison : la sauvegarde des discussions sur ses propres serveurs, comme l’a repéré WABetaInfo en fouillant dans le code des bêtas de WhatsApp.

Le principe sur les deux plateformes est le même. L’application propose de sélectionner un fournisseur pour la sauvegarde : Google Drive ou iCloud en fonction de l’appareil, ainsi que son propre service de stockage. Tout cela peut encore évoluer, voire être abandonné : la fonction en est encore aux premières étapes de son développement et n’est pas proposée aux bêta-testeurs. Les premières traces de cette fonction remontent au mois d’avril sur Android, et tout récemment sur iOS.

Actuellement, WhatsApp envisagerait 2 Go de stockage de base, sans frais supplémentaires. Avec 3 milliards d’utilisateurs, la messagerie peut difficilement faire plus, mais là aussi les utilisateurs les plus gourmands risquent d’être rapidement pris au dépourvu. C’est pourquoi WhatsApp proposerait de gonfler l’enveloppe contre une petite contribution sonnante et trébuchante : 0,99 dollar pour 50 Go, comme chez Apple. Et on pourrait grimper jusqu’à 1 To. Bien sûr, les prix et l’offre peuvent encore évoluer.

On ne sait pas encore ce que WhatsApp fera des anciennes sauvegardes. Sur iOS, celles conservées dans iCloud pourront toujours être supprimées manuellement depuis les réglages. Si l’utilisateur décide de faire confiance aux serveurs de Meta (c’est un grand « si »), les sauvegardes seront chiffrées de bout en bout ; de fait, personne ne pourra y avoir accès, si ce n’est l’utilisateur. Autre utilité de cette fonction : les sauvegardes stockées chez WhatsApp ne seront pas verrouillées à une plateforme. De fait, cela pourrait grandement faciliter la restauration des conversations.

• WhatsApp fait le plein de nouveautés : stockage, comptes multiples, transferts, Meta AI…

La nouvelle version 1.3 de COSMIC Desktop vient de paraître. Cet environnement de bureau est pour rappel édité par l’entreprise System76, en plus de sa propre distribution Linux, Pop!_OS. D’abord réservé à cette dernière, COSMIC Desktop est devenu un projet indépendant, aussi open source et libre que le reste, développé intégralement en Rust et disponible sur d’autres systèmes. Fedora a par exemple son propre Spin.

Cette version 1.3 apporte surtout l’apparence « Frosted glass » aux éléments de l’interface. Les utilisateurs de Pop!_OS l’avaient eue il y a quelques jours, COSMIC Desktop 1.3 permet de l’activer sur toutes les autres distributions.

Le travail sur Frosted glass a duré plusieurs mois. Inspiré par le Liquid Glass, il fait davantage dans le verre givré/dépoli que dans le « verre liquide », avec un résultat plus sobre. Les réglages, désactivés par défaut, se trouvent dans Paramètres > Bureau. Sous le choix du type d’arrondi, une nouvelle entrée « Frosted glass » fait son apparition. Elle ouvre un panneau dans lequel on peut choisir les éléments sur lesquels on veut répercuter ce type d’affichage. On remarque d’ailleurs que tout est encore en anglais.

Le résultat final dépend largement du thème initialement choisi. Avec ceux par défaut pour le clair et le sombre, le verre givré apporte une touche de transparence, qui ne semble pas avoir les soucis de lisibilité qu’avait Liquid Glass dans la première proposition d’Apple (les versions 27 des systèmes travaillent d’ailleurs ce point). L’ajout de ces réglages reste optionnel et les personnes n’appréciant pas ce type d’affichage pourront passer leur chemin.

COSMIC Desktop 1.3 présente d’autres apports, comme l’affichage du GPU dédié dans le menu contextuel COSMIC, le support des fonds d’écran AVIF, le remplacement du backend personnalisé NetworkManager par nmrs (en Rust), un meilleur défilement pour la molette, ou encore des améliorations pour le nouveau COSMIC Monitor apparu dans la version 1.2 du Desktop, avec notamment le calcul de la consommation d’énergie pour les GPU AMD/Intel et la possibilité de suspendre les GPU NVIDIA.

La nouvelle version 1.3 de COSMIC Desktop vient de paraître. Cet environnement de bureau est pour rappel édité par l’entreprise System76, en plus de sa propre distribution Linux, Pop!_OS. D’abord réservé à cette dernière, COSMIC Desktop est devenu un projet indépendant, aussi open source et libre que le reste, développé intégralement en Rust et disponible sur d’autres systèmes. Fedora a par exemple son propre Spin.

Cette version 1.3 apporte surtout l’apparence « Frosted glass » aux éléments de l’interface. Les utilisateurs de Pop!_OS l’avaient eue il y a quelques jours, COSMIC Desktop 1.3 permet de l’activer sur toutes les autres distributions.

Le travail sur Frosted glass a duré plusieurs mois. Inspiré par le Liquid Glass, il fait davantage dans le verre givré/dépoli que dans le « verre liquide », avec un résultat plus sobre. Les réglages, désactivés par défaut, se trouvent dans Paramètres > Bureau. Sous le choix du type d’arrondi, une nouvelle entrée « Frosted glass » fait son apparition. Elle ouvre un panneau dans lequel on peut choisir les éléments sur lesquels on veut répercuter ce type d’affichage. On remarque d’ailleurs que tout est encore en anglais.

Le résultat final dépend largement du thème initialement choisi. Avec ceux par défaut pour le clair et le sombre, le verre givré apporte une touche de transparence, qui ne semble pas avoir les soucis de lisibilité qu’avait Liquid Glass dans la première proposition d’Apple (les versions 27 des systèmes travaillent d’ailleurs ce point). L’ajout de ces réglages reste optionnel et les personnes n’appréciant pas ce type d’affichage pourront passer leur chemin.

COSMIC Desktop 1.3 présente d’autres apports, comme l’affichage du GPU dédié dans le menu contextuel COSMIC, le support des fonds d’écran AVIF, le remplacement du backend personnalisé NetworkManager par nmrs (en Rust), un meilleur défilement pour la molette, ou encore des améliorations pour le nouveau COSMIC Monitor apparu dans la version 1.2 du Desktop, avec notamment le calcul de la consommation d’énergie pour les GPU AMD/Intel et la possibilité de suspendre les GPU NVIDIA.

Microsoft poursuit son entreprise de réhabilitation de Windows 11 avec une nouvelle fournée d’améliorations et d’optimisations pour des fonctions de base du système d’exploitation. La recherche en profite directement.

Qui n’a pas un jour pesté contre les résultats de la recherche de Windows 11 ? Cela fait des années que les utilisateurs s’en plaignent, et mieux vaut tard que jamais : Microsoft a entendu ce cri du cœur. Les cobayes de la branche expérimentale du programme Windows Insider ont désormais la possibilité d’installer plusieurs nouveautés visant à faire place nette dans cet endroit vital du système d’exploitation.

L’écran d’accueil de la recherche se montre ainsi bien moins chargé en informations inutiles. Les contenus recommandés ont fait leurs bagages ; la zone ne propose désormais plus que les derniers résultats. Cela parait presque un peu vide, mais qui s’en plaindra ?

Les résultats d’une recherche en local se veulent eux aussi plus clairs et espacés, tout en présentant davantage d’informations et, quand c’est possible, un aperçu du fichier. Chercher un paramètre de l’OS renvoie vers des résultats plus propres et surtout qui proposent les réglages les plus pertinents en premier.

Quant à la recherche en ligne, elle perd le contenu promotionnel, ce qui ne fera de peine à personne. Les résultats web affichent désormais « les réponses les plus pertinentes » en premier lieu, plutôt que des promos ou des produits liés.

Dans le même ordre d’idée, il est désormais possible de ne plus afficher de suggestions web ni du Microsoft Store ; deux options à trouver dans le panneau Confidentialité et sécurité. Un petit tour dans ces réglages ne sera pas de trop, sachant qu’elles sont actives par défaut. Fin mai, Microsoft avait inauguré un autre changement important dans la branche expérimentale de Windows : obliger l’OS à ne chercher des résultats que dans les contenus locaux.

• Windows 11 : la mise à jour 26H2 se dessine pour cet automne

L’éditeur ajoute au lot une priorisation des résultats locaux lorsqu’ils correspondent mieux à la recherche. Par conséquent, les apps, les paramètres et les fichiers apparaissent systématiquement avant les suggestions du web et du Store (si elles sont activées). Le moteur se veut également plus souple vis à vis des erreurs de frappe : « utlook » trouvera « Outlook », par exemple.

Toujours pour la recherche, Microsoft promet également une amélioration de la stabilité, une réduction des plantages et moins de problèmes de chargement. Toutes ces modifications accompagnent le chantier à ciel ouvert d’un Windows 11 qui lâche un peu l’ajout sans queue ni tête de fonctions IA pour privilégier les besoins des utilisateurs.

Depuis le début de l’année, l’éditeur a multiplié les petites et grandes attentions, à l’image de la barre des tâches qui peut s’épingler en haut de l’écran, du menu Démarrer nettement plus personnalisable, ou encore d’un plus grand contrôle sur Windows Update. On a l’impression que Microsoft découvre la Lune ici, mais ce dépoussiérage en règle pourrait réconcilier quelques fâchés avec Windows 11. La version 26H2, qui sera livrée cet automne, permettra au grand public de tester une bonne partie de ces nouveautés.

Microsoft poursuit son entreprise de réhabilitation de Windows 11 avec une nouvelle fournée d’améliorations et d’optimisations pour des fonctions de base du système d’exploitation. La recherche en profite directement.

Qui n’a pas un jour pesté contre les résultats de la recherche de Windows 11 ? Cela fait des années que les utilisateurs s’en plaignent, et mieux vaut tard que jamais : Microsoft a entendu ce cri du cœur. Les cobayes de la branche expérimentale du programme Windows Insider ont désormais la possibilité d’installer plusieurs nouveautés visant à faire place nette dans cet endroit vital du système d’exploitation.

L’écran d’accueil de la recherche se montre ainsi bien moins chargé en informations inutiles. Les contenus recommandés ont fait leurs bagages ; la zone ne propose désormais plus que les derniers résultats. Cela parait presque un peu vide, mais qui s’en plaindra ?

Les résultats d’une recherche en local se veulent eux aussi plus clairs et espacés, tout en présentant davantage d’informations et, quand c’est possible, un aperçu du fichier. Chercher un paramètre de l’OS renvoie vers des résultats plus propres et surtout qui proposent les réglages les plus pertinents en premier.

Quant à la recherche en ligne, elle perd le contenu promotionnel, ce qui ne fera de peine à personne. Les résultats web affichent désormais « les réponses les plus pertinentes » en premier lieu, plutôt que des promos ou des produits liés.

Dans le même ordre d’idée, il est désormais possible de ne plus afficher de suggestions web ni du Microsoft Store ; deux options à trouver dans le panneau Confidentialité et sécurité. Un petit tour dans ces réglages ne sera pas de trop, sachant qu’elles sont actives par défaut. Fin mai, Microsoft avait inauguré un autre changement important dans la branche expérimentale de Windows : obliger l’OS à ne chercher des résultats que dans les contenus locaux.

• Windows 11 : la mise à jour 26H2 se dessine pour cet automne

L’éditeur ajoute au lot une priorisation des résultats locaux lorsqu’ils correspondent mieux à la recherche. Par conséquent, les apps, les paramètres et les fichiers apparaissent systématiquement avant les suggestions du web et du Store (si elles sont activées). Le moteur se veut également plus souple vis à vis des erreurs de frappe : « utlook » trouvera « Outlook », par exemple.

Toujours pour la recherche, Microsoft promet également une amélioration de la stabilité, une réduction des plantages et moins de problèmes de chargement. Toutes ces modifications accompagnent le chantier à ciel ouvert d’un Windows 11 qui lâche un peu l’ajout sans queue ni tête de fonctions IA pour privilégier les besoins des utilisateurs.

Depuis le début de l’année, l’éditeur a multiplié les petites et grandes attentions, à l’image de la barre des tâches qui peut s’épingler en haut de l’écran, du menu Démarrer nettement plus personnalisable, ou encore d’un plus grand contrôle sur Windows Update. On a l’impression que Microsoft découvre la Lune ici, mais ce dépoussiérage en règle pourrait réconcilier quelques fâchés avec Windows 11. La version 26H2, qui sera livrée cet automne, permettra au grand public de tester une bonne partie de ces nouveautés.

Canicule dans les serveurs d'Apple

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.

• Aperçu de Siri AI sur iOS 27 : Apple a-t-elle sauvé le soldat Siri ?

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.

• Compatibilité matérielle : le grand écart des nouveaux OS 27 d’Apple

Canicule dans les serveurs d'Apple

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.

• Aperçu de Siri AI sur iOS 27 : Apple a-t-elle sauvé le soldat Siri ?

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.

• Compatibilité matérielle : le grand écart des nouveaux OS 27 d’Apple

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.

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.

• X11, Wayland : pourquoi la transition est-elle aussi longue ?

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.

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.

• X11, Wayland : pourquoi la transition est-elle aussi longue ?

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)

Ça change tout, mais ça ne change rien

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.

Ça change tout, mais ça ne change rien

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.

Des agents et de la rouille

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.

• Retour sur 10 ans de Rust, un langage devenu incontournable
• Sylvestre Ledru (Mozilla) : de Firefox au noyau Linux, la fulgurante ascension du Rust

Direction Rust !

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.

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.

Des agents et de la rouille

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.

• Retour sur 10 ans de Rust, un langage devenu incontournable
• Sylvestre Ledru (Mozilla) : de Firefox au noyau Linux, la fulgurante ascension du Rust

Direction Rust !

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.

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.

• Systèmes de fichiers : de HFS et ses évolutions à APFS chez Apple

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.

• Systèmes de fichiers : de HFS et ses évolutions à APFS chez Apple

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+.

Quand iOS ne répond plus

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.

Quand iOS ne répond plus

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 macOS dans le macOS dans le macOS

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.

• Apple veut de nouveau sauver le soldat Siri, cette fois avec l’aide de Google

Enfin un accès aux périphériques USB

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.