Les Acts restent

Le Data Act est désormais en application. Avec lui, l’Europe veut transformer la chaine de valeur des données, tout en les libérant. De grandes ambitions, alors que les données sont devenues extrêmement précieuses depuis l’explosion de l’IA. Pour les entreprises, cela doit signaler en outre une simplification dans la gestion de leurs informations entre les prestataires de cloud.

Le Data Act, voté en 2023, est entré en vigueur le 11 janvier 2024 et en application le 12 septembre. Il affiche plusieurs grands objectifs : veiller à ce que les appareils connectés en Union européenne puissent partager leurs données, offrir aux consommateurs plus de possibilités sur le choix des prestataires ou réparateurs en fonction de ces informations, permettre aux industries de récupérer les données présentes dans les équipements spécialisés, laisser les clients changer de fournisseur cloud plus facilement, et enfin interdire les contrats qui pourraient empêcher les partages de données. Pour les particuliers, il s’applique notamment à tout le secteur de l’IoT.

« Le règlement sur les données est conçu pour responsabiliser les utilisateurs, tant les consommateurs que les entreprises, en leur donnant un plus grand contrôle sur les données générées par leurs appareils connectés, tels que les voitures, les téléviseurs intelligents et les machines industrielles. Il jette les bases d’une économie européenne des données équitable, innovante et compétitive », indique la Commission européenne.

Jusqu’à présent, il a surtout été fait référence au Data Act pour sa capacité à chambouler le marché du cloud. Depuis son entrée en application, il est censé empêcher les grandes entreprises de pratiquer des tarifs de sortie des données (egress fees). La volonté de l’Union dans ce domaine est claire : empêcher la rétention des données. Le texte est cependant plus large et induit un changement de paradigme.

Toutes les données non personnelles

Le texte aborde de nombreux autres points et vient s’articuler avec le RGPD, qu’il complète en visant les données non personnelles. Il est possible que les deux règlements entrent en conflit sur des sujets spécifiques, auquel cas le RGPD l’emporte systématiquement, précisait déjà la Commission européenne dans une FAQ publiée en septembre 2024. De même, les autorités de protection des données (comme la CNIL en France) conservent leurs compétences et le Data Act ne remplace pas les législations sectorielles existantes.

Le texte ne vise pas l’intégralité des données. Dans le cadre des objets connectés, de l’industrie ou encore de l’agriculture, il concerne les informations brutes ou pré-traitées. Les données dérivées ou inférées (dans le cadre d’un traitement de type IA) ne sont pas incluses. De très nombreuses catégories de produits sont concernées, jusqu’à la domotique. L’électroménager dit « intelligent » dispose ainsi, par exemple, de données d’utilisation que les utilisateurs européens peuvent vouloir récupérer. Il y a deux conditions : que l’utilisateur dispose d’un droit stable sur le produit (propriétaire ou contractuel de location/bail) et que le produit soit commercialisé dans l’Union européenne.

Le Data Act précise également que ces données doivent être fournies dans un format structuré, couramment utilisé et lisible par machine, avec une qualité équivalente à celle utilisée par le détenteur pour ses propres besoins. La disponibilité en temps réel est requise lorsque cela est pertinent et techniquement réalisable.

Avant même qu’une telle opération prenne place, toutes les entreprises concernées doivent informer leurs clients que cette possibilité existe, et leurs modalités d’accès. Les entreprises peuvent refuser dans deux types de cas : quand la communication des données risque de compromettre la confidentialité des secrets commerciaux ou quand elle pourrait affecter la sécurité des produits. Dans ces cas, elles doivent contacter les autorités compétentes pour les informer, avant d’avertir les utilisateurs. Ces derniers peuvent contester ces conditions devant des tribunaux, les autorités compétentes ou des organismes de règlement des différends.

À noter que si le règlement s’applique à toutes les données non personnelles, certaines catégories spécifiques sont exclues. C’est notamment le cas des infrastructures (routes, aéroports, chemins de fer), des prototypes ainsi que des produits destinés au stockage et/ou au traitement des données.

Le cœur du Data Act

Sans agence, sans Looping

Au cours des derniers mois, la gestion des mises à jour de sécurité a évolué chez Google. Désormais, elle est basée sur une évaluation des risques, avec une priorité donnée aux failles présentant un risque accru. Pour le reste, la diffusion des correctifs adopte un rythme davantage trimestriel. Il semble que le changement ait été mis en place pour soulager les constructeurs.

Le changement a été révélé par Android Authority le 13 septembre et confirmé à demi-mot par Google. Nos confrères relèvent ainsi que le bulletin de juillet ne contenait aucune vulnérabilité corrigée, une rupture face aux 120 failles corrigées depuis le début de l’année. À l’inverse, le bulletin de septembre comportait des correctifs pour 119 failles à lui seul. Comment expliquer une telle différence ?

Une évaluation des risques

Google donne à présent la priorité aux failles comportant un risque élevé, qui ne tient pas uniquement compte de la criticité d’une vulnérabilité. L’entreprise ne détaille pas les critères d’évaluation, mais on peut supposer que le nombre de cibles potentielles et la facilité de mise en œuvre font partie des principaux, de même que l’existence d’une exploitation connue. Selon Android Authority, le mécanisme est nommé Risk-Based Update System, ou RBUS.

La règle est simple : si la faille présente un risque élevé, elle est publiée comme telle dans le bulletin mensuel, et si elle peut attendre, elle partira dans le bulletin trimestriel. Pour nos confrères, ce changement a été mis en place pour soulager les constructeurs intégrant Android dans leurs smartphones (OEM). Les failles à haut risque ont ainsi des chances accrues d’avoir un correctif rapidement diffusé, la diffusion des solutions étant parfois complexe à maintenir en fonction du nombre d’appareils concernés.

Toujours selon Android Authority, ce changement explique pourquoi le bulletin de juillet était vide : aucune faille à haut risque n’était répertoriée. Il explique aussi celui de septembre comptait autant de failles corrigées : elles avaient toutes été mises de côté pour le grand bulletin trimestriel.

Avantages et inconvénients

Bien que Google n’ait pas documenté ce changement, la société l’a confirmé à demi-mots à Android Authority :

« Les bulletins de sécurité Android et Pixel sont publiés tous les mois. Pour assurer la sécurité des utilisateurs, nous intégrons une sécurité puissante profondément ancrée dans les fondations d’Android. Android arrête la plupart des exploitations de vulnérabilité à la source grâce à un renforcement complet de la plate-forme, comme notre utilisation du langage Rust et des protections anti-exploitation avancées. Android et Pixel corrigent en permanence les failles de sécurité connues et donnent la priorité à la correction des vulnérabilités les plus risquées en premier »

Côté utilisateurs, rien ne change vraiment dans la plupart des cas. Les constructeurs décidant d’appliquer quand même les correctifs de sécurité tous les mois pourront continuer à le faire. Ceux souhaitant un rythme plus souple ne diffuseront alors des correctifs mensuels que si des failles à haut risque y sont présentes, et se contenteront d’une grosse mise à jour tous les trois mois dans le cas contraire.

Les avantages ne concernent a priori que les OEM, qui ont parfois du mal à tenir le rythme, selon les gammes commercialisées et le nombre de modifications faites sur la base d’Android. En leur offrant un nouveau cycle trimestriel, ils peuvent en théorie mieux préparer le terrain.

L’approche a également ses inconvénients. Retarder la publication des mises à jour peut laisser le temps à certaines failles d’être exploitées. Car les informations circulent : si des failles sont trouvées, les entreprises sont averties, de même que les équipes d’ingénieurs. Plus il y a de personnes au courant, plus le risque de fuite augmente, et avec lui la probabilité d’une exploitation.

Un système complexe

Le problème des mises à jour de sécurité sur Android est débattu depuis longtemps, avec toujours le même constat : les constructeurs doivent jouer le jeu. La pluralité des gammes et le nombre de modifications apportées à la base d’Android peuvent ralentir l’application des correctifs, car il faut mener suffisamment de tests pour s’assurer du bon fonctionnement. Plus il y a d’appareils dans les gammes, plus ce travail est conséquent.

Comme le rappelle d’ailleurs Android Authority, les entreprises ne jouent pas toutes le jeu de la même manière. Si l’on voit depuis deux ans des annonces très importantes sur la durée du support, notamment sur les Pixel et les Galaxy S de Samsung, un bon support est trop souvent dépendant de la gamme. De nombreux appareils d’entrée ou milieu de gamme ont un support limité de quelques années, les correctifs de sécurité n’arrivant pas tous les mois. C’est d’ailleurs ce qui a poussé l’Union européenne à imposer un nouveau minimum de cinq ans pour les mises à jour logiciels sur tous les nouveaux appareils.

• Smartphones, tablettes : l’étiquette énergie et l’écoconception entrent en application

Google connait bien le problème. Le projet Mainline (initié avec Android 10, mais arrivé concrètement dans les versions suivantes) a notamment été instauré pour augmenter le nombre de composants pouvant être mis à jour directement par Google Play. Mais de nombreux composants bas niveau ne peuvent être modifiés que par les constructeurs. Aussi, lorsque Google signale une faille et prépare une modification de code, celle-ci n’est pas publiée immédiatement dans AOSP (Android Open Source Project), pour que les modifications de code ne révèlent pas les détails de la brèche.

Le nouveau mécanisme ne remet pas en cause l’Android Security Bulletin mensuel. L’ASB dispose pour rappel de deux versions : une publique pour lister les failles corrigées, et une privée pour avertir les OEM un mois avant et leur laisser d’intégrer les correctifs. En revanche, certains bulletins seront parfois vides, qu’ils soient publics ou privés. Les bulletins complets seront désormais alignés sur le rythme trimestriel d’Android depuis sa dernière version 16.

Sans agence, sans Looping

Au cours des derniers mois, la gestion des mises à jour de sécurité a évolué chez Google. Désormais, elle est basée sur une évaluation des risques, avec une priorité donnée aux failles présentant un risque accru. Pour le reste, la diffusion des correctifs adopte un rythme davantage trimestriel. Il semble que le changement ait été mis en place pour soulager les constructeurs.

Le changement a été révélé par Android Authority le 13 septembre et confirmé à demi-mot par Google. Nos confrères relèvent ainsi que le bulletin de juillet ne contenait aucune vulnérabilité corrigée, une rupture face aux 120 failles corrigées depuis le début de l’année. À l’inverse, le bulletin de septembre comportait des correctifs pour 119 failles à lui seul. Comment expliquer une telle différence ?

Une évaluation des risques

Google donne à présent la priorité aux failles comportant un risque élevé, qui ne tient pas uniquement compte de la criticité d’une vulnérabilité. L’entreprise ne détaille pas les critères d’évaluation, mais on peut supposer que le nombre de cibles potentielles et la facilité de mise en œuvre font partie des principaux, de même que l’existence d’une exploitation connue. Selon Android Authority, le mécanisme est nommé Risk-Based Update System, ou RBUS.

La règle est simple : si la faille présente un risque élevé, elle est publiée comme telle dans le bulletin mensuel, et si elle peut attendre, elle partira dans le bulletin trimestriel. Pour nos confrères, ce changement a été mis en place pour soulager les constructeurs intégrant Android dans leurs smartphones (OEM). Les failles à haut risque ont ainsi des chances accrues d’avoir un correctif rapidement diffusé, la diffusion des solutions étant parfois complexe à maintenir en fonction du nombre d’appareils concernés.

Toujours selon Android Authority, ce changement explique pourquoi le bulletin de juillet était vide : aucune faille à haut risque n’était répertoriée. Il explique aussi celui de septembre comptait autant de failles corrigées : elles avaient toutes été mises de côté pour le grand bulletin trimestriel.

Avantages et inconvénients

Bien que Google n’ait pas documenté ce changement, la société l’a confirmé à demi-mots à Android Authority :

« Les bulletins de sécurité Android et Pixel sont publiés tous les mois. Pour assurer la sécurité des utilisateurs, nous intégrons une sécurité puissante profondément ancrée dans les fondations d’Android. Android arrête la plupart des exploitations de vulnérabilité à la source grâce à un renforcement complet de la plate-forme, comme notre utilisation du langage Rust et des protections anti-exploitation avancées. Android et Pixel corrigent en permanence les failles de sécurité connues et donnent la priorité à la correction des vulnérabilités les plus risquées en premier »

Côté utilisateurs, rien ne change vraiment dans la plupart des cas. Les constructeurs décidant d’appliquer quand même les correctifs de sécurité tous les mois pourront continuer à le faire. Ceux souhaitant un rythme plus souple ne diffuseront alors des correctifs mensuels que si des failles à haut risque y sont présentes, et se contenteront d’une grosse mise à jour tous les trois mois dans le cas contraire.

Les avantages ne concernent a priori que les OEM, qui ont parfois du mal à tenir le rythme, selon les gammes commercialisées et le nombre de modifications faites sur la base d’Android. En leur offrant un nouveau cycle trimestriel, ils peuvent en théorie mieux préparer le terrain.

L’approche a également ses inconvénients. Retarder la publication des mises à jour peut laisser le temps à certaines failles d’être exploitées. Car les informations circulent : si des failles sont trouvées, les entreprises sont averties, de même que les équipes d’ingénieurs. Plus il y a de personnes au courant, plus le risque de fuite augmente, et avec lui la probabilité d’une exploitation.

Un système complexe

Le problème des mises à jour de sécurité sur Android est débattu depuis longtemps, avec toujours le même constat : les constructeurs doivent jouer le jeu. La pluralité des gammes et le nombre de modifications apportées à la base d’Android peuvent ralentir l’application des correctifs, car il faut mener suffisamment de tests pour s’assurer du bon fonctionnement. Plus il y a d’appareils dans les gammes, plus ce travail est conséquent.

Comme le rappelle d’ailleurs Android Authority, les entreprises ne jouent pas toutes le jeu de la même manière. Si l’on voit depuis deux ans des annonces très importantes sur la durée du support, notamment sur les Pixel et les Galaxy S de Samsung, un bon support est trop souvent dépendant de la gamme. De nombreux appareils d’entrée ou milieu de gamme ont un support limité de quelques années, les correctifs de sécurité n’arrivant pas tous les mois. C’est d’ailleurs ce qui a poussé l’Union européenne à imposer un nouveau minimum de cinq ans pour les mises à jour logiciels sur tous les nouveaux appareils.

• Smartphones, tablettes : l’étiquette énergie et l’écoconception entrent en application

Google connait bien le problème. Le projet Mainline (initié avec Android 10, mais arrivé concrètement dans les versions suivantes) a notamment été instauré pour augmenter le nombre de composants pouvant être mis à jour directement par Google Play. Mais de nombreux composants bas niveau ne peuvent être modifiés que par les constructeurs. Aussi, lorsque Google signale une faille et prépare une modification de code, celle-ci n’est pas publiée immédiatement dans AOSP (Android Open Source Project), pour que les modifications de code ne révèlent pas les détails de la brèche.

Le nouveau mécanisme ne remet pas en cause l’Android Security Bulletin mensuel. L’ASB dispose pour rappel de deux versions : une publique pour lister les failles corrigées, et une privée pour avertir les OEM un mois avant et leur laisser d’intégrer les correctifs. En revanche, certains bulletins seront parfois vides, qu’ils soient publics ou privés. Les bulletins complets seront désormais alignés sur le rythme trimestriel d’Android depuis sa dernière version 16.

Apple a ouvert grand les vannes lundi pour les versions 26 de toutes ses plateformes. Dans le même temps, l’entreprise a lancé de nouvelles mises à jour intermédiaires pour les moutures précédentes.

iOS/iPadOS 18.7 et macOS 15.7 ont été mis à disposition en même temps que les versions majeures hier soir. Dans l’interface de mise à jour sur iOS, cette version apparaissait même avant la mouture 26. Elles ont été publiées pour colmater une série de failles de sécurité, dont on trouve la liste sur le site d’Apple. Les correctifs concernent des composants comme CoreAudio, le noyau, libc, MobileStorageMounter, Raccourcis ou encore WebKit.

Apple a également publié des mises à jour de sécurité pour des versions plus anciennes de ses systèmes. Pour iOS/iPadOS, on trouve ainsi les versions 15.8.5 et 16.7.12. Sur Mac, les machines sous Sonoma reçoivent la 14.8.

S’agissant de correctifs de sécurité, il est conseillé d’appliquer rapidement les mises à jour, qui réclament un redémarrage.

Apple a ouvert grand les vannes lundi pour les versions 26 de toutes ses plateformes. Dans le même temps, l’entreprise a lancé de nouvelles mises à jour intermédiaires pour les moutures précédentes.

iOS/iPadOS 18.7 et macOS 15.7 ont été mis à disposition en même temps que les versions majeures hier soir. Dans l’interface de mise à jour sur iOS, cette version apparaissait même avant la mouture 26. Elles ont été publiées pour colmater une série de failles de sécurité, dont on trouve la liste sur le site d’Apple. Les correctifs concernent des composants comme CoreAudio, le noyau, libc, MobileStorageMounter, Raccourcis ou encore WebKit.

Apple a également publié des mises à jour de sécurité pour des versions plus anciennes de ses systèmes. Pour iOS/iPadOS, on trouve ainsi les versions 15.8.5 et 16.7.12. Sur Mac, les machines sous Sonoma reçoivent la 14.8.

S’agissant de correctifs de sécurité, il est conseillé d’appliquer rapidement les mises à jour, qui réclament un redémarrage.

Comme prévu, Apple commence la diffusion des versions finales pour ses nouvelles plateformes. Elles sont toutes estampillées 26, afin d’harmoniser les numéros entre les systèmes, Apple prenant pour référence l’année à venir. iOS passe ainsi de la version 18 à la 26.

La nouveauté la plus visible et commune à toutes les plateformes est la nouvelle interface Liquid Glass, qui a fait couler beaucoup d’encre. Apple sort de sa période « flat » sobre pour tenter l’aventure du verre plus ou moins dépoli, avec de nombreux effets liés. Liquid Glass a été largement critiquée pendant la phase bêta pour des problèmes de lisibilité et d’accessibilité, mais elle semble là pour durer. On pourrait faire un parallèle avec iOS 7 et la première incarnation du flat design chez Apple, qui avait défrayé la chronique en son temps.

iOS 26 introduit notamment une nouvelle application Téléphone, qui permet de mieux gérer l’historique des appels. Elle peut regrouper les appels en absence et peut filtrer automatiquement tous ceux en provenance de numéros inconnus, avec plusieurs possibilités. On peut choisir par exemple de les envoyer directement sur le répondeur. Citons également l’alimentation adaptative, des informations beaucoup plus détaillées sur l’autonomie, les applications Aperçu et Jeux vidéo, de la personnalisation dans Messages, la traduction automatique des paroles dans Music, etc.

iPadOS 26 récupère ces apports et en ajoute d’autres. La nouvelle version est réellement majeure : toutes les applications peuvent passer sous forme de fenêtre via un glissement sur leur coin inférieur droit. On peut alors les déplacer librement, la contrôler via les trois boutons colorés typiques de macOS, utiliser la barre de menus, agencer les fenêtres via des options de tiling et profiter de la vue Exposé.

macOS 26, nommé Tahoe, reprend l’application Téléphone complète, en lieu et place de FaceTime. Surtout, Spotlight et Raccourcis font leur petite révolution. Le premier devient une palette complète de commandes, avec possibilité de créer des raccourcis personnalisés et de reprendre les actions suggérées par Apple Intelligence. Idem pour Raccourcis, qui peut maintenant agir sur un plus grand nombre d’objets. Toutes les actions liées au bouquet IA lui sont également accessibles. Par exemple, si Apple Intelligence détecte qu’une transcription a souvent lieu après avoir enregistré l’audio d’un cours, Raccourcis pourra suggérer une action pour enchainer automatiquement les actions, avec export et envoi du document sur une destination choisie.

Quant à watchOS et tvOS, leurs nouveautés sont plus discrètes. Pour la montre connectée, on peut noter Workout Buddy, censé encourager dans la pratique sportive, l’arrivée de Notes, des suggestions d’activités et de listes musicales ou encore une révision des notifications, qui se veulent moins intrusives.

Comme prévu, Apple commence la diffusion des versions finales pour ses nouvelles plateformes. Elles sont toutes estampillées 26, afin d’harmoniser les numéros entre les systèmes, Apple prenant pour référence l’année à venir. iOS passe ainsi de la version 18 à la 26.

La nouveauté la plus visible et commune à toutes les plateformes est la nouvelle interface Liquid Glass, qui a fait couler beaucoup d’encre. Apple sort de sa période « flat » sobre pour tenter l’aventure du verre plus ou moins dépoli, avec de nombreux effets liés. Liquid Glass a été largement critiquée pendant la phase bêta pour des problèmes de lisibilité et d’accessibilité, mais elle semble là pour durer. On pourrait faire un parallèle avec iOS 7 et la première incarnation du flat design chez Apple, qui avait défrayé la chronique en son temps.

iOS 26 introduit notamment une nouvelle application Téléphone, qui permet de mieux gérer l’historique des appels. Elle peut regrouper les appels en absence et peut filtrer automatiquement tous ceux en provenance de numéros inconnus, avec plusieurs possibilités. On peut choisir par exemple de les envoyer directement sur le répondeur. Citons également l’alimentation adaptative, des informations beaucoup plus détaillées sur l’autonomie, les applications Aperçu et Jeux vidéo, de la personnalisation dans Messages, la traduction automatique des paroles dans Music, etc.

iPadOS 26 récupère ces apports et en ajoute d’autres. La nouvelle version est réellement majeure : toutes les applications peuvent passer sous forme de fenêtre via un glissement sur leur coin inférieur droit. On peut alors les déplacer librement, la contrôler via les trois boutons colorés typiques de macOS, utiliser la barre de menus, agencer les fenêtres via des options de tiling et profiter de la vue Exposé.

macOS 26, nommé Tahoe, reprend l’application Téléphone complète, en lieu et place de FaceTime. Surtout, Spotlight et Raccourcis font leur petite révolution. Le premier devient une palette complète de commandes, avec possibilité de créer des raccourcis personnalisés et de reprendre les actions suggérées par Apple Intelligence. Idem pour Raccourcis, qui peut maintenant agir sur un plus grand nombre d’objets. Toutes les actions liées au bouquet IA lui sont également accessibles. Par exemple, si Apple Intelligence détecte qu’une transcription a souvent lieu après avoir enregistré l’audio d’un cours, Raccourcis pourra suggérer une action pour enchainer automatiquement les actions, avec export et envoi du document sur une destination choisie.

Quant à watchOS et tvOS, leurs nouveautés sont plus discrètes. Pour la montre connectée, on peut noter Workout Buddy, censé encourager dans la pratique sportive, l’arrivée de Notes, des suggestions d’activités et de listes musicales ou encore une révision des notifications, qui se veulent moins intrusives.

Linux Mint 22.2, alias Zara, est sortie il y a moins de deux semaines, apportant avec elle le support des empreintes digitales pour l’authentification, une meilleure prise en charge de libadwaita ainsi qu’une série d’améliorations visuelles.

• Linux Mint 22.2 supporte mieux libadwaita et les empreintes digitales

On sait désormais que la prochaine version, estampillée 22.3, est prévue pour décembre. L’annonce a été faite par Clément Lefebvre (créateur de Linux Mint et développeur principal) dans sa lettre mensuelle. La mouture proposera notamment le nouveau menu principal pour Cinnamon, comme nous l’indiquions en mars. On y trouvera également un nouvel applet d’état et le support de Wayland pour les dispositions de claviers et autres méthodes de saisie.

Pour une partie des utilisateurs, c’est surtout la Linux Mint Debian Edition 7 (LMDE 7) qui est attendue. La bêta est attendue avant la fin du mois et est donc imminente. Le système sera basé sur Debian 13 (« Trixie ») et représentera donc une vaste modernisation. L’équipe de développement lui ajoutera les dernières améliorations vues sur Linux Mint 22.2.

Cette Debian Edition 7 n’existera qu’en version amd64, l’équipe de Mint suivant la disparition du i386 sur Debian. Il faut également noter que si Mint reprend le socle Debian tel qu’il est actuellement, alors LMDE 7 sera fourni avec un noyau Linux 6.12 (LTS), soit une version moins récente que la 6.14 de Linux Mint 22.3.

Linux Mint 22.2, alias Zara, est sortie il y a moins de deux semaines, apportant avec elle le support des empreintes digitales pour l’authentification, une meilleure prise en charge de libadwaita ainsi qu’une série d’améliorations visuelles.

• Linux Mint 22.2 supporte mieux libadwaita et les empreintes digitales

On sait désormais que la prochaine version, estampillée 22.3, est prévue pour décembre. L’annonce a été faite par Clément Lefebvre (créateur de Linux Mint et développeur principal) dans sa lettre mensuelle. La mouture proposera notamment le nouveau menu principal pour Cinnamon, comme nous l’indiquions en mars. On y trouvera également un nouvel applet d’état et le support de Wayland pour les dispositions de claviers et autres méthodes de saisie.

Pour une partie des utilisateurs, c’est surtout la Linux Mint Debian Edition 7 (LMDE 7) qui est attendue. La bêta est attendue avant la fin du mois et est donc imminente. Le système sera basé sur Debian 13 (« Trixie ») et représentera donc une vaste modernisation. L’équipe de développement lui ajoutera les dernières améliorations vues sur Linux Mint 22.2.

Cette Debian Edition 7 n’existera qu’en version amd64, l’équipe de Mint suivant la disparition du i386 sur Debian. Il faut également noter que si Mint reprend le socle Debian tel qu’il est actuellement, alors LMDE 7 sera fourni avec un noyau Linux 6.12 (LTS), soit une version moins récente que la 6.14 de Linux Mint 22.3.

Interface chaise-clavier

Dans l’après-midi du 8 septembre, une attaque a eu lieu contre la chaine d’approvisionnement de plusieurs paquets NPM. Les dégâts ont été limités et tout est vite rentré dans l’ordre. Mais les conséquences auraient pu être bien pires, limitées uniquement par les compétences des pirates. L’affaire relance les débats autour de l’authentification et du contrôle de la provenance des modifications.

Elle est qualifiée désormais de plus grande attaque contre la chaine d’approvisionnement jamais enregistrée. Une telle attaque consiste pour rappel à viser la chaine menant à la production d’un logiciel ou d’un service. Si elle aboutit, un code se retrouve distribué ou mis à disposition des victimes, qui croient récupérer un logiciel, la dernière version d’un composant, etc. Elle permet d’arroser un nombre important de personnes, d’autant plus que le composant ou logiciel est populaire.

Dans l’après-midi du lundi 8 septembre, des pirates ont ainsi compromis le compte NPM (Node Packet Manager, gestionnaire de paquet par défaut pour Node.js) d’un développeur. La récupération des accès leur a permis d’infecter le code de 18 paquets : backslash, chalk-template, supports-hyperlinks, has-ansi, simple-swizzle, color-string, error-ex, color-name, is-arrayish, slice-ansi, color-convert, wrap-ansi, ansi-regex, supports-color, strip-ansi, chalk, debug, ansi-styles.

Certains sont téléchargés des centaines de millions de fois par semaine. Pourtant, tout a été réglé en deux heures environ et la casse a été limitée. Que s’est-il passé ?

L’ingénierie sociale, toujours elle

L’histoire commence avec une détection de l’entreprise belge Aikido. Elle est spécialisée dans la sécurité, et plus particulièrement dans la surveillance des mises à jour de code dans les principaux dépôts open source. Comme elle raconte dans un billet de blog, elle détecte le 8 septembre à 15h16 (heure de Paris) des modifications suspicieuses dans 18 paquets. Ils sont très populaires sur NPM : ensemble, ils cumulent deux milliards de téléchargements par semaine.

L’analyse du code révèle sa fonction : intercepter silencieusement l’activité crypto et web3 dans le navigateur, manipuler les interactions avec le portefeuille et rediriger les paiements vers des comptes contrôlés par les pirates. Le code malveillant peut détourner à la fois le trafic réseau et les API des applications, indique Aikido. « Ce qui le rend dangereux, c’est qu’il fonctionne à plusieurs niveaux : modifier le contenu affiché sur les sites Web, falsifier les appels API et manipuler ce que les applications des utilisateurs croient signer », ajoute l’entreprise.

La société belge indique avoir alors contacté le développeur concerné, Josh Junon, surnommé Qix. Celui-ci répond alors qu’il a découvert avoir été piraté. Comme il l’indique lui-même dans un message sur BlueSky deux heures plus tard, il dit avoir été victime d’un email qui l’invitait à réinitialiser ses codes d’authentification à deux facteurs (2FA). Le courrier semblait parfaitement légitime selon lui, avec un lien renvoyant vers une copie conforme de la page de connexion de NPM. Cette page interceptait les informations d’authentification et le jeton 2FA pour les envoyer aux pirates. Après quoi, ces derniers ont simplement modifié l’adresse de connexion utilisée pour se connecter à NPM.

Le 9 septembre, Josh Junon a publié un message d’excuses sur Hacker News, dans lequel il admet honteusement : « yep I got pwned ». Le même jour, jFrog indiquait de son côté que la campagne continuait et que de nouveaux paquets contaminés avaient été découverts, dont DuckDB. Toujours le 9 septembre, SlowMist avertissait que d’autres développeurs recevaient le même e-mail, signe que Josh Junon n’était pas un cas isolé.

Tout s’enchaine très vite

Une chaine d’approvisionnement contaminée sur des paquets aussi populaires aurait constitué une catastrophe pour de nombreux produits. Ces attaques sont notamment très efficaces contre des composants impliqués dans le web de manière générale. Or, avec la multiplication des applications web encapsulées, cela pouvait signifier une diffusion à très grande échelle du code vérolé. Pourtant, tout s’est achevé en quelques heures, sans grande casse.

Sur le blog de la Security Alliance, on peut lire dans le billet du 9 septembre une note ironisant sur les 5 cents d’ETH ou encore les 20 dollars d’un memecoin. Dans les heures qui ont suivi la compromission, seuls 588 dollars de transactions auraient été détectés. Ce qui fait dire à l’Alliance que le plus gros impact financier de l’attaque réside finalement dans « les milliers d’heures passées collectivement par les équipes d’ingénierie et de sécurité du monde entier à nettoyer les environnements compromis, et les millions de dollars de contrats de vente qui seront inévitablement signés à la suite de cette nouvelle étude de cas ».

Cité par Brian Krebs, le pentester Philippe Catureli, responsable sécurité chez Seralys, s’en étonne également : « Ce qui est fou, c’est qu’ils ont compromis des milliards de sites Web et d’applications juste pour cibler quelques crypto-monnaies. Il s’agissait d’une attaque de la chaîne d’approvisionnement, et cela aurait facilement pu être quelque chose de bien pire que la récolte de crypto-monnaies ».

Même son de cloche chez Florian Roth, chercheur en sécurité chez Nextron Systems : « Étant donné que la plupart des entreprises exécutent au moins une application React ou Angular, elles ont eu la possibilité d’exécuter du code sur des millions de systèmes dans des milliers d’organisations. Et ils l’ont utilisé pour lacher un voleur de cryptomonnaies obscurci de manière amateur, ont été attrapés par des règles élémentaires de détection, et le problème a été résolu après 2 heures ». Pas mieux du côté du chercheur Kevin Beaumont.

L’authentification des développeurs à nouveau en question

Dans son billet de blog, Aikido relève également le vaste danger évité de peu. De faibles conséquences qui ne semblent dues qu’au manque de compétences des pirates, en dépit de leur réussite sur la chaine d’approvisionnement.

Pour montrer à quel point ce type d’incident peut être grave, la société belge rappelle une autre compromission qui s’est déroulée fin août. Là aussi, un autre développeur NPM avait été visé, permettant la récupération de ses identifiants et l’insertion d’un code malveillant dans nx, une boite à outils pour le développement open source, totalisant six millions de téléchargements par semaine.

Le code malveillant avait servi à analyser l’ordinateur du développeur pour y récupérer des jetons d’authentification, ainsi que des clés SSH et API. Ces informations n’ont cependant pas été transmises aux pirates : elles ont été publiées dans un référentiel public créé pour l’occasion dans le compte GitHub du développeur, afin qu’elles soient visibles de tous et téléchargeables.

À Brian Krebs, Charlie Eriksen, chercheur chez Aikido, affirme que tous les paquets les plus populaires devraient exiger des attestations pour les modifications de code. De manière plus générale, il est d’avis que des plateformes comme GitHub et NPM devraient relever le niveau de sécurité, en s’assurant que les commits (une proposition de modification du code, pour schématiser) sont proposés par des personnes étant bien qui elles prétendent être.

S’il s’en est fallu de peu pour échapper à une catastrophe, les évènements ne semblent pas avoir surpris les chercheurs en sécurité, qui répètent les mêmes éléments depuis des années. Kevin Beaumont s’en moquait justement avec acidité, rappelant – encore une fois – que certaines des briques logicielles les plus utilisées ne sont gérées que par une poignée de personnes. Renvoyant une fois de plus au célèbre dessin de xkcd sur les dépendances.

Rappelons également que l’authentification à facteurs multiples, si elle apporte un gain majeur de protection, n’est pas absolue. En août 2022, Microsoft avait expliqué en détail par exemple comment un acteur malveillant avait mis en place toute une infrastructure pour récupérer des jetons d’authentification, via notamment des serveurs mimant un comportement légitime. Ce type d’attaque passe systématiquement par la compromission d’une personne, le plus souvent par un e-mail soigneusement préparé.

Interface chaise-clavier

Dans l’après-midi du 8 septembre, une attaque a eu lieu contre la chaine d’approvisionnement de plusieurs paquets NPM. Les dégâts ont été limités et tout est vite rentré dans l’ordre. Mais les conséquences auraient pu être bien pires, limitées uniquement par les compétences des pirates. L’affaire relance les débats autour de l’authentification et du contrôle de la provenance des modifications.

Elle est qualifiée désormais de plus grande attaque contre la chaine d’approvisionnement jamais enregistrée. Une telle attaque consiste pour rappel à viser la chaine menant à la production d’un logiciel ou d’un service. Si elle aboutit, un code se retrouve distribué ou mis à disposition des victimes, qui croient récupérer un logiciel, la dernière version d’un composant, etc. Elle permet d’arroser un nombre important de personnes, d’autant plus que le composant ou logiciel est populaire.

Dans l’après-midi du lundi 8 septembre, des pirates ont ainsi compromis le compte NPM (Node Packet Manager, gestionnaire de paquet par défaut pour Node.js) d’un développeur. La récupération des accès leur a permis d’infecter le code de 18 paquets : backslash, chalk-template, supports-hyperlinks, has-ansi, simple-swizzle, color-string, error-ex, color-name, is-arrayish, slice-ansi, color-convert, wrap-ansi, ansi-regex, supports-color, strip-ansi, chalk, debug, ansi-styles.

Certains sont téléchargés des centaines de millions de fois par semaine. Pourtant, tout a été réglé en deux heures environ et la casse a été limitée. Que s’est-il passé ?

L’ingénierie sociale, toujours elle

L’histoire commence avec une détection de l’entreprise belge Aikido. Elle est spécialisée dans la sécurité, et plus particulièrement dans la surveillance des mises à jour de code dans les principaux dépôts open source. Comme elle raconte dans un billet de blog, elle détecte le 8 septembre à 15h16 (heure de Paris) des modifications suspicieuses dans 18 paquets. Ils sont très populaires sur NPM : ensemble, ils cumulent deux milliards de téléchargements par semaine.

L’analyse du code révèle sa fonction : intercepter silencieusement l’activité crypto et web3 dans le navigateur, manipuler les interactions avec le portefeuille et rediriger les paiements vers des comptes contrôlés par les pirates. Le code malveillant peut détourner à la fois le trafic réseau et les API des applications, indique Aikido. « Ce qui le rend dangereux, c’est qu’il fonctionne à plusieurs niveaux : modifier le contenu affiché sur les sites Web, falsifier les appels API et manipuler ce que les applications des utilisateurs croient signer », ajoute l’entreprise.

La société belge indique avoir alors contacté le développeur concerné, Josh Junon, surnommé Qix. Celui-ci répond alors qu’il a découvert avoir été piraté. Comme il l’indique lui-même dans un message sur BlueSky deux heures plus tard, il dit avoir été victime d’un email qui l’invitait à réinitialiser ses codes d’authentification à deux facteurs (2FA). Le courrier semblait parfaitement légitime selon lui, avec un lien renvoyant vers une copie conforme de la page de connexion de NPM. Cette page interceptait les informations d’authentification et le jeton 2FA pour les envoyer aux pirates. Après quoi, ces derniers ont simplement modifié l’adresse de connexion utilisée pour se connecter à NPM.

Le 9 septembre, Josh Junon a publié un message d’excuses sur Hacker News, dans lequel il admet honteusement : « yep I got pwned ». Le même jour, jFrog indiquait de son côté que la campagne continuait et que de nouveaux paquets contaminés avaient été découverts, dont DuckDB. Toujours le 9 septembre, SlowMist avertissait que d’autres développeurs recevaient le même e-mail, signe que Josh Junon n’était pas un cas isolé.

Tout s’enchaine très vite

Une chaine d’approvisionnement contaminée sur des paquets aussi populaires aurait constitué une catastrophe pour de nombreux produits. Ces attaques sont notamment très efficaces contre des composants impliqués dans le web de manière générale. Or, avec la multiplication des applications web encapsulées, cela pouvait signifier une diffusion à très grande échelle du code vérolé. Pourtant, tout s’est achevé en quelques heures, sans grande casse.

Sur le blog de la Security Alliance, on peut lire dans le billet du 9 septembre une note ironisant sur les 5 cents d’ETH ou encore les 20 dollars d’un memecoin. Dans les heures qui ont suivi la compromission, seuls 588 dollars de transactions auraient été détectés. Ce qui fait dire à l’Alliance que le plus gros impact financier de l’attaque réside finalement dans « les milliers d’heures passées collectivement par les équipes d’ingénierie et de sécurité du monde entier à nettoyer les environnements compromis, et les millions de dollars de contrats de vente qui seront inévitablement signés à la suite de cette nouvelle étude de cas ».

Cité par Brian Krebs, le pentester Philippe Catureli, responsable sécurité chez Seralys, s’en étonne également : « Ce qui est fou, c’est qu’ils ont compromis des milliards de sites Web et d’applications juste pour cibler quelques crypto-monnaies. Il s’agissait d’une attaque de la chaîne d’approvisionnement, et cela aurait facilement pu être quelque chose de bien pire que la récolte de crypto-monnaies ».

Même son de cloche chez Florian Roth, chercheur en sécurité chez Nextron Systems : « Étant donné que la plupart des entreprises exécutent au moins une application React ou Angular, elles ont eu la possibilité d’exécuter du code sur des millions de systèmes dans des milliers d’organisations. Et ils l’ont utilisé pour lacher un voleur de cryptomonnaies obscurci de manière amateur, ont été attrapés par des règles élémentaires de détection, et le problème a été résolu après 2 heures ». Pas mieux du côté du chercheur Kevin Beaumont.

L’authentification des développeurs à nouveau en question

Dans son billet de blog, Aikido relève également le vaste danger évité de peu. De faibles conséquences qui ne semblent dues qu’au manque de compétences des pirates, en dépit de leur réussite sur la chaine d’approvisionnement.

Pour montrer à quel point ce type d’incident peut être grave, la société belge rappelle une autre compromission qui s’est déroulée fin août. Là aussi, un autre développeur NPM avait été visé, permettant la récupération de ses identifiants et l’insertion d’un code malveillant dans nx, une boite à outils pour le développement open source, totalisant six millions de téléchargements par semaine.

Le code malveillant avait servi à analyser l’ordinateur du développeur pour y récupérer des jetons d’authentification, ainsi que des clés SSH et API. Ces informations n’ont cependant pas été transmises aux pirates : elles ont été publiées dans un référentiel public créé pour l’occasion dans le compte GitHub du développeur, afin qu’elles soient visibles de tous et téléchargeables.

À Brian Krebs, Charlie Eriksen, chercheur chez Aikido, affirme que tous les paquets les plus populaires devraient exiger des attestations pour les modifications de code. De manière plus générale, il est d’avis que des plateformes comme GitHub et NPM devraient relever le niveau de sécurité, en s’assurant que les commits (une proposition de modification du code, pour schématiser) sont proposés par des personnes étant bien qui elles prétendent être.

S’il s’en est fallu de peu pour échapper à une catastrophe, les évènements ne semblent pas avoir surpris les chercheurs en sécurité, qui répètent les mêmes éléments depuis des années. Kevin Beaumont s’en moquait justement avec acidité, rappelant – encore une fois – que certaines des briques logicielles les plus utilisées ne sont gérées que par une poignée de personnes. Renvoyant une fois de plus au célèbre dessin de xkcd sur les dépendances.

Rappelons également que l’authentification à facteurs multiples, si elle apporte un gain majeur de protection, n’est pas absolue. En août 2022, Microsoft avait expliqué en détail par exemple comment un acteur malveillant avait mis en place toute une infrastructure pour récupérer des jetons d’authentification, via notamment des serveurs mimant un comportement légitime. Ce type d’attaque passe systématiquement par la compromission d’une personne, le plus souvent par un e-mail soigneusement préparé.

Papi en aura fait de la résistance

Dans le monde Linux, on entend parler des serveurs graphiques X11 et Wayland depuis longtemps. Mais de quoi s’agit-il exactement ? À quoi sert un serveur graphique ? Quelles sont les promesses de Wayland et pourquoi la migration prend autant de temps ? Nous vous proposons d’y voir plus clair.

Présentons les deux protagonistes de notre sujet. D’un côté, le X Window System. Sa première version date de 1984, en tant que projet développé au sein du MIT. Il a été essentiellement pensé à une époque où l’on trouvait des serveurs informatiques puissants et des clients légers, d’où son appellation de serveur, qui lui est resté.

On le connait mieux aujourd’hui sous son nom de X11. L’appellation vient de la onzième version de X, sortie en 1987. Ce fut la première révision à être considérée comme stable et pleinement opérationnelle. Et oui, techniquement, on utilise cette onzième version depuis 35 ans. Mais dans la pratique, les évolutions ont été continues.

De l’autre côté, on a Wayland. Beaucoup plus récent, le projet a été lancé en 2008 par Kristian Hogsberg, développeur chez Red Hat. Objectif, proposer un protocole moderne et gagnant sur toute la ligne : plus sécurisé, plus efficace et surtout plus simple. Une base neuve, capable d’exploiter beaucoup mieux le matériel qui avait largement évolué et de se débarrasser des vieilles assises de X11.

Qu’est-ce qu’un serveur graphique ?

Penchons-nous maintenant sur ce qu’est un serveur graphique (ou d’affichage), le rôle que tient ce composant et ses principaux attributs.

Commençons par le commencement. Sur un système de type Unix, dès que vous voyez quelque chose s’afficher à l’écran au sein d’une interface graphique, c’est que le serveur d’affichage est impliqué. Ce composant crucial est chargé de dessiner les fenêtres à l’écran et de gérer toutes les interactions qui s’y rapportent, ainsi que la composition de l’ensemble (assemblage des fenêtres). Il est une interface entre l’utilisateur, l’interface et le matériel lié. Il va d’ailleurs plus loin que le seul aspect graphique, puisqu’il s’occupe également des entrées de la souris et du clavier.

Ubuntu 25.10, attendue le mois prochain, devrait être une version plus riche en modifications techniques qu’habituellement. L’équipe de développement va ainsi procéder au remplacement d’initramfs-tools par Dracut pour son démarrage.

Pour l’utilisateur, il n’y aura aucun changement, pas même dans la vitesse de démarrage de la machine. L’arrivée de Dracut représente cependant une évolution technologique intéressante pour Ubuntu (il est déjà utilisé par Fedora).

De quoi parle-t-on ? Actuellement, quand un ordinateur sous Ubuntu démarre, ce n’est pas le système qui se charge en premier. La première étape est un mini-système qui se charge en mémoire vive. Nommé initramfs, il contient le strict nécessaire pour trouver le stockage, déchiffrer les disques si besoin et passer le relai au système de fichiers du « vrai » système. C’est donc un maillon essentiel de la chaine de démarrage.

Si Fedora est passée à Dracut et qu’Ubuntu s’apprête à faire de même, c’est qu’il apporte plus de souplesse dans cette étape. Là où initramfs est basé sur des scripts, Dracut est organisé en modules et propose une approche dynamique via udev, qui gère la détection matérielle dans Ubuntu. Cette organisation modulaire simplifie son développement et sa maintenance.

Dracut est aussi plus moderne, avec une prise en charge de technologies plus récentes, comme NVMe over Fabrics, indique OMGUbuntu. C’est en outre un choix cohérent pour les technologies déjà présentes dans Ubuntu. La distribution utilise par exemple systemd, dont se sert également Dracut, contrairement à initramfs.

Cette décision n’est pas arrivée subitement. Canonical réfléchit à la question depuis un bon moment et a posé la question du remplacement effectif dans une note du 7 février. Les questions de cohérence technique et de cout de maintenance étaient clairement mises en avant.

La bêta d’Ubuntu 25.10 est attendue pour le 18 septembre et sa version finale le 9 octobre.

Ubuntu 25.10, attendue le mois prochain, devrait être une version plus riche en modifications techniques qu’habituellement. L’équipe de développement va ainsi procéder au remplacement d’initramfs-tools par Dracut pour son démarrage.

Pour l’utilisateur, il n’y aura aucun changement, pas même dans la vitesse de démarrage de la machine. L’arrivée de Dracut représente cependant une évolution technologique intéressante pour Ubuntu (il est déjà utilisé par Fedora).

De quoi parle-t-on ? Actuellement, quand un ordinateur sous Ubuntu démarre, ce n’est pas le système qui se charge en premier. La première étape est un mini-système qui se charge en mémoire vive. Nommé initramfs, il contient le strict nécessaire pour trouver le stockage, déchiffrer les disques si besoin et passer le relai au système de fichiers du « vrai » système. C’est donc un maillon essentiel de la chaine de démarrage.

Si Fedora est passée à Dracut et qu’Ubuntu s’apprête à faire de même, c’est qu’il apporte plus de souplesse dans cette étape. Là où initramfs est basé sur des scripts, Dracut est organisé en modules et propose une approche dynamique via udev, qui gère la détection matérielle dans Ubuntu. Cette organisation modulaire simplifie son développement et sa maintenance.

Dracut est aussi plus moderne, avec une prise en charge de technologies plus récentes, comme NVMe over Fabrics, indique OMGUbuntu. C’est en outre un choix cohérent pour les technologies déjà présentes dans Ubuntu. La distribution utilise par exemple systemd, dont se sert également Dracut, contrairement à initramfs.

Cette décision n’est pas arrivée subitement. Canonical réfléchit à la question depuis un bon moment et a posé la question du remplacement effectif dans une note du 7 février. Les questions de cohérence technique et de cout de maintenance étaient clairement mises en avant.

La bêta d’Ubuntu 25.10 est attendue pour le 18 septembre et sa version finale le 9 octobre.

Docteur ? Radio ? Super ? Mamie ?

Nova Launcher est désormais orphelin, son fondateur et dernier développeur étant parti. Dans un billet, il explique que cette décision lui a été imposée. Le passage en open source semble pour l’instant compromis.

Dans le monde des launchers, Nova est probablement le plus connu. Existant depuis plus d’une décennie, à l’époque où Android en était à Ice Cream Sandwich, il a tout de suite brillé par ses performances et ses fonctions. Nova s’est largement enrichi avec le temps, inspirant d’autres launchers à son tour.

Il semble cependant que Nova soit orphelin. En 2022, le produit avait été racheté par la société de statistiques Branch, qui n’a jamais dit vraiment en quoi cet achat pouvait lui être profitable (une version Prime à 3,99 euros existe avec des fonctions supplémentaires). À ce moment, un petit groupe de développeurs travaillait sur Nova, dont Kevin Barry, fondateur et développeur principal du projet.

Dans un billet daté du 6 septembre, Kevin Barry a pourtant annoncé son départ. Il explique qu’il lui a été demandé d’arrêter tout développement sur Nova et qu’il a depuis quitté Branch. Le destin du launcher semblait déjà compromis, car Barry était le seul à travailler dessus depuis un an. Sur le Play Store, la dernière mise à jour date du 18 mai 2024.

La promesse de l’open source

Outre l’abandon probable du projet, la question de son ouverture à l’open source est un sujet central. Comme Kevin Barry le rappelle dans son billet, plusieurs annonces avaient été faites en ce sens. Il cite les propos d’Alex Austin, fondateur et alors CEO de Branch : « Si Kevin devait un jour partir, il est prévu que le code soit open source et mis entre les mains de la communauté ».

Mais comme le développeur l’explique : « Au cours des derniers mois, j’ai préparé la version Open Source de Nova Launcher. Ce travail comprenait le nettoyage de la base de code, l’examen des licences, la suppression ou le remplacement du code propriétaire et la coordination avec le service juridique pour assurer une publication correcte. […] Cependant, on m’a finalement demandé d’arrêter de travailler sur Nova Launcher et l’effort d’open source ».

Branch a peut-être d’autres projets pour Nova, mais l’entreprise n’a pour l’instant rien dit. Une pétition pour le basculement de Nova Launcher en open source a été publiée sur Change.org, mais à l’heure où nous écrivons ces lignes, elle n’a recueilli que 3 775 signatures.

Un ralentissement général ?

De manière plus générale, certains se posent la question : les launchers Android vont-ils disparaitre ? Windows Central, qui évoquait hier le cas de Nova, notait que le launcher de Microsoft (anciennement Arrow) était lui aussi presque à l’arrêt. Il a bien reçu une petite mise à jour en juillet, mais rien de significatif depuis longtemps. Le produit est pourtant très apprécié.

Certains launchers sont pourtant bel et bien vivants. Parmi les plus appréciés, on pourrait citer par exemple Niagara et Smart Launcher, tous deux mis à jour très récemment. Citons également Hyperion, spécialisé dans la personnalisation de l’interface avec de multiples thèmes, ou encore Olauncher qui, au contraire, joue la carte du minimalisme.

Docteur ? Radio ? Super ? Mamie ?

Nova Launcher est désormais orphelin, son fondateur et dernier développeur étant parti. Dans un billet, il explique que cette décision lui a été imposée. Le passage en open source semble pour l’instant compromis.

Dans le monde des launchers, Nova est probablement le plus connu. Existant depuis plus d’une décennie, à l’époque où Android en était à Ice Cream Sandwich, il a tout de suite brillé par ses performances et ses fonctions. Nova s’est largement enrichi avec le temps, inspirant d’autres launchers à son tour.

Il semble cependant que Nova soit orphelin. En 2022, le produit avait été racheté par la société de statistiques Branch, qui n’a jamais dit vraiment en quoi cet achat pouvait lui être profitable (une version Prime à 3,99 euros existe avec des fonctions supplémentaires). À ce moment, un petit groupe de développeurs travaillait sur Nova, dont Kevin Barry, fondateur et développeur principal du projet.

Dans un billet daté du 6 septembre, Kevin Barry a pourtant annoncé son départ. Il explique qu’il lui a été demandé d’arrêter tout développement sur Nova et qu’il a depuis quitté Branch. Le destin du launcher semblait déjà compromis, car Barry était le seul à travailler dessus depuis un an. Sur le Play Store, la dernière mise à jour date du 18 mai 2024.

La promesse de l’open source

Outre l’abandon probable du projet, la question de son ouverture à l’open source est un sujet central. Comme Kevin Barry le rappelle dans son billet, plusieurs annonces avaient été faites en ce sens. Il cite les propos d’Alex Austin, fondateur et alors CEO de Branch : « Si Kevin devait un jour partir, il est prévu que le code soit open source et mis entre les mains de la communauté ».

Mais comme le développeur l’explique : « Au cours des derniers mois, j’ai préparé la version Open Source de Nova Launcher. Ce travail comprenait le nettoyage de la base de code, l’examen des licences, la suppression ou le remplacement du code propriétaire et la coordination avec le service juridique pour assurer une publication correcte. […] Cependant, on m’a finalement demandé d’arrêter de travailler sur Nova Launcher et l’effort d’open source ».

Branch a peut-être d’autres projets pour Nova, mais l’entreprise n’a pour l’instant rien dit. Une pétition pour le basculement de Nova Launcher en open source a été publiée sur Change.org, mais à l’heure où nous écrivons ces lignes, elle n’a recueilli que 3 775 signatures.

Un ralentissement général ?

De manière plus générale, certains se posent la question : les launchers Android vont-ils disparaitre ? Windows Central, qui évoquait hier le cas de Nova, notait que le launcher de Microsoft (anciennement Arrow) était lui aussi presque à l’arrêt. Il a bien reçu une petite mise à jour en juillet, mais rien de significatif depuis longtemps. Le produit est pourtant très apprécié.

Certains launchers sont pourtant bel et bien vivants. Parmi les plus appréciés, on pourrait citer par exemple Niagara et Smart Launcher, tous deux mis à jour très récemment. Citons également Hyperion, spécialisé dans la personnalisation de l’interface avec de multiples thèmes, ou encore Olauncher qui, au contraire, joue la carte du minimalisme.

I, Robot

Dans un billet publié hier soir, Google a annoncé le lancement officiel de sa fonction de doublage automatique à destination des créateurs de contenus américains. Une seule option permet de traduire la vidéo en d’autres langues. Mais l’outil fait débat, tout comme son intégration côté internautes.

En test depuis deux ans, le doublage automatique est officiellement disponible depuis hier soir. La fonction concerne d’abord les créateurs de contenus aux États-Unis, avec traduction automatique et synthèse vocale pour permettre un accès plus large des vidéos. Il ne s’agit donc pas d’une nouveauté, car le test avait été élargi en décembre 2024, de nombreuses vidéos étant doublées par l’IA.

(Quelques) chiffres à l’appui

« Désormais, lorsqu’un créateur YouTube aux États-Unis publie une nouvelle vidéo, en quelques instants, un fan en Corée, un fan au Brésil et un fan en Inde peuvent tous la regarder dans leur langue maternelle », s’enthousiasme Google dans sa communication. Le projet pilote a même permis de sortir un chiffre : en moyenne, un quart des vues sur les vidéos proviennent de personnes ayant une autre langue. YouTube indique même tester actuellement des miniatures multilingues « auprès d’un groupe restreint de créateurs ».

Pour bien montrer le potentiel de sa technologie (puisée dans Gemini), Google évoque la chaine du cuisiner Jamie Oliver, qui faisait partie de la phase de test. Selon l’éditeur, les pistes audio multilingues automatiques ont permis de multiplier par 3 le nombre de vues. La société cite également les créateurs MrBeast et Mark Rober, à qui ces pistes ont permis l’arrivée de « millions de téléspectateurs supplémentaires ». pour le second, YouTube a enregistré une moyenne de 30 langues téléchargées par vidéo.

La promesse est donc simple : ouvrir grand les portes de la population mondiale en supprimant la barrière de la langue. Mais cette disponibilité ne se fait pas sans froncer quelques sourcils.

« Sans âme »

Sans surprise, tout le monde n’est pas satisfait de cette génération. Sur Reddit notamment, on trouve de très nombreux commentaires sur ce changement. De nombreux internautes pestent contre les doublages automatiques pour diverses raisons, dont l’une des principales est que les voix, particulièrement monocordes, sont « désincarnées » et « sans âme ». Certaines personnes la jugent même « insupportable ». L’émotion et l’intonation passent au second plan.

Parmi les critiques, on retrouve aussi les erreurs de traduction. Ces erreurs se retrouvent jusque dans les titres, un point faisant grimacer nombre de personnes. Le problème s’amplifie avec la spécificité du sujet. Il existait déjà avec les sous-titres automatisés et prend une nouvelle ampleur avec le doublage. Vous êtes fan de Tolkien et aimez écouter des vidéos explicatives sur certains aspects particuliers de son univers ? Le doublage va écorcher de nombreux noms. Ces erreurs de « compréhension » peuvent produire des contresens. En outre, la traduction des titres ne permet pas de se rendre compte que l’on est sur le point de lancer une vidéo dans une autre langue.

« Certains titres traduits automatiquement n’ont aucun sens et ils perdent souvent le sens voulu par le créateur. Ça arrive aussi dans les descriptions et les chapitres des vidéos. À un moment donné, YouTube a décidé d’activer une voix IA qui est juste insupportable à écouter. Elle n’utilise pas les intonations correctement et prononce les mots avec un dialecte bizarre qui n’est pas parlé dans ma région », dit un internaute sur Reddit.

Les problèmes soulignés sont en fait les mêmes que depuis des mois. Par exemple, le doublage automatique casse l’ambiance sonore. Si la vidéo contient des musiques ou des sons particuliers, ils sont supprimés pour ne laisser que la piste vocale.

C’est comme ça

Le point le plus agaçant souligné dans les commentaires est que ce comportement n’est pas une option : il est actif par défaut. Pour chaque vidéo, il faut se rendre dans le menu des pistes audio et remettre la langue d’origine. Le problème est aggravé par l’absence totale dans les paramètres d’un réglage pour désactiver le doublage automatique, obligeant à répéter la manipulation pour chaque vidéo en anglais que l’on regarde.

« Ma langue maternelle est aussi le portugais, mais j’ai dû changer la langue de ma chaîne YouTube en anglais parce que je regarde principalement des vidéos en anglais et je ne veux pas écouter une voix d’IA horrible. Mais je regarde aussi des vidéos dans d’autres langues et elles sont parfois doublées en anglais. Mon Dieu, je déteste ça. Donnez-nous au moins la possibilité de désactiver ça dans les paramètres, comme on peut le faire pour les sous-titres », indique un internaute.

Plusieurs notent que la vision de Google ne semble pas intégrer les personnes bilingues ou ayant au moins une pratique suffisante d’une langue pour pouvoir l’écouter dans de nombreux cas. Solution adoptée par certaines personnes : basculer YouTube en anglais pour que les vidéos concernées restent en version originale. Problème, écouter des vidéos dans d’autres langues activera alors le doublage automatique vers l’anglais.

Le choix des youtubers

Rappelons que le doublage automatique n’est pas imposé à l’intégralité des contenus en anglais. Le choix revient à la personne détentrice de la chaine, qui active donc ou pas cette fonction. Derrière l’aspect pratique, la fonction pose cependant de nombreuses questions.

Certains affirment par exemple avoir renoncé à certaines chaines qui l’avaient activé partout, y compris sur les titres, donnant parfois des résultats « déformés » assimilés à un manque de respect. Une perte d’authenticité culturelle et d’unicité qui semble viser de nouveau la quantité au détriment de la qualité.

Côté métiers, les questions sont nombreuses, même parmi les créateurs de contenus. En janvier dernier par exemple, Benjamin Brillaud, de la chaine Nota Bene, racontait dans une vidéo tout le mal qu’il pensait de l’outil : « Le rendu de l’épisode était catastrophique. Il n’y avait plus d’incarnation, la pertinence des traductions laissait à désirer… ».

La généralisation du doublage automatique pose en outre question pour les métiers concernés. En juillet 2024, Brigitte Lecordier (célèbre voix, entre autres, de Son Goku et Son Gohan) demandait au micro de BFMTV : « Il faut que l’on se demande quelle société on veut pour nos enfants. Est-ce qu’on veut une société gérée par des robots, où le soir, un robot va leur lire une histoire pour aller dormir, ou la voix d’un comédien qui va raconter des belles choses et nous émouvoir ? ». Cette question de l’émotion revient désormais constamment dans les critiques formulées contre le doublage automatique.

Tous les créateurs de contenus ne sont d’ailleurs pas intéressés. Dans les propres commentaires de la vidéo d’annonce publiée hier soir par YouTube, beaucoup demandent ainsi que l’on puisse importer facilement ses propres pistes de doublage, plutôt que de laisser faire l’IA. En attendant, les personnes allergiques à ce doublage peuvent utiliser certains outils, comme l’extension YouTube No Translation disponible sur Chrome ou Firefox.

• YouTube a fait des retouches automatiques de vidéos sans l’accord de leurs auteurs

I, Robot

Dans un billet publié hier soir, Google a annoncé le lancement officiel de sa fonction de doublage automatique à destination des créateurs de contenus américains. Une seule option permet de traduire la vidéo en d’autres langues. Mais l’outil fait débat, tout comme son intégration côté internautes.

En test depuis deux ans, le doublage automatique est officiellement disponible depuis hier soir. La fonction concerne d’abord les créateurs de contenus aux États-Unis, avec traduction automatique et synthèse vocale pour permettre un accès plus large des vidéos. Il ne s’agit donc pas d’une nouveauté, car le test avait été élargi en décembre 2024, de nombreuses vidéos étant doublées par l’IA.

(Quelques) chiffres à l’appui

« Désormais, lorsqu’un créateur YouTube aux États-Unis publie une nouvelle vidéo, en quelques instants, un fan en Corée, un fan au Brésil et un fan en Inde peuvent tous la regarder dans leur langue maternelle », s’enthousiasme Google dans sa communication. Le projet pilote a même permis de sortir un chiffre : en moyenne, un quart des vues sur les vidéos proviennent de personnes ayant une autre langue. YouTube indique même tester actuellement des miniatures multilingues « auprès d’un groupe restreint de créateurs ».

Pour bien montrer le potentiel de sa technologie (puisée dans Gemini), Google évoque la chaine du cuisiner Jamie Oliver, qui faisait partie de la phase de test. Selon l’éditeur, les pistes audio multilingues automatiques ont permis de multiplier par 3 le nombre de vues. La société cite également les créateurs MrBeast et Mark Rober, à qui ces pistes ont permis l’arrivée de « millions de téléspectateurs supplémentaires ». pour le second, YouTube a enregistré une moyenne de 30 langues téléchargées par vidéo.

La promesse est donc simple : ouvrir grand les portes de la population mondiale en supprimant la barrière de la langue. Mais cette disponibilité ne se fait pas sans froncer quelques sourcils.

« Sans âme »

Sans surprise, tout le monde n’est pas satisfait de cette génération. Sur Reddit notamment, on trouve de très nombreux commentaires sur ce changement. De nombreux internautes pestent contre les doublages automatiques pour diverses raisons, dont l’une des principales est que les voix, particulièrement monocordes, sont « désincarnées » et « sans âme ». Certaines personnes la jugent même « insupportable ». L’émotion et l’intonation passent au second plan.

Parmi les critiques, on retrouve aussi les erreurs de traduction. Ces erreurs se retrouvent jusque dans les titres, un point faisant grimacer nombre de personnes. Le problème s’amplifie avec la spécificité du sujet. Il existait déjà avec les sous-titres automatisés et prend une nouvelle ampleur avec le doublage. Vous êtes fan de Tolkien et aimez écouter des vidéos explicatives sur certains aspects particuliers de son univers ? Le doublage va écorcher de nombreux noms. Ces erreurs de « compréhension » peuvent produire des contresens. En outre, la traduction des titres ne permet pas de se rendre compte que l’on est sur le point de lancer une vidéo dans une autre langue.

« Certains titres traduits automatiquement n’ont aucun sens et ils perdent souvent le sens voulu par le créateur. Ça arrive aussi dans les descriptions et les chapitres des vidéos. À un moment donné, YouTube a décidé d’activer une voix IA qui est juste insupportable à écouter. Elle n’utilise pas les intonations correctement et prononce les mots avec un dialecte bizarre qui n’est pas parlé dans ma région », dit un internaute sur Reddit.

Les problèmes soulignés sont en fait les mêmes que depuis des mois. Par exemple, le doublage automatique casse l’ambiance sonore. Si la vidéo contient des musiques ou des sons particuliers, ils sont supprimés pour ne laisser que la piste vocale.

C’est comme ça

Le point le plus agaçant souligné dans les commentaires est que ce comportement n’est pas une option : il est actif par défaut. Pour chaque vidéo, il faut se rendre dans le menu des pistes audio et remettre la langue d’origine. Le problème est aggravé par l’absence totale dans les paramètres d’un réglage pour désactiver le doublage automatique, obligeant à répéter la manipulation pour chaque vidéo en anglais que l’on regarde.

« Ma langue maternelle est aussi le portugais, mais j’ai dû changer la langue de ma chaîne YouTube en anglais parce que je regarde principalement des vidéos en anglais et je ne veux pas écouter une voix d’IA horrible. Mais je regarde aussi des vidéos dans d’autres langues et elles sont parfois doublées en anglais. Mon Dieu, je déteste ça. Donnez-nous au moins la possibilité de désactiver ça dans les paramètres, comme on peut le faire pour les sous-titres », indique un internaute.

Plusieurs notent que la vision de Google ne semble pas intégrer les personnes bilingues ou ayant au moins une pratique suffisante d’une langue pour pouvoir l’écouter dans de nombreux cas. Solution adoptée par certaines personnes : basculer YouTube en anglais pour que les vidéos concernées restent en version originale. Problème, écouter des vidéos dans d’autres langues activera alors le doublage automatique vers l’anglais.

Le choix des youtubers

Rappelons que le doublage automatique n’est pas imposé à l’intégralité des contenus en anglais. Le choix revient à la personne détentrice de la chaine, qui active donc ou pas cette fonction. Derrière l’aspect pratique, la fonction pose cependant de nombreuses questions.

Certains affirment par exemple avoir renoncé à certaines chaines qui l’avaient activé partout, y compris sur les titres, donnant parfois des résultats « déformés » assimilés à un manque de respect. Une perte d’authenticité culturelle et d’unicité qui semble viser de nouveau la quantité au détriment de la qualité.

Côté métiers, les questions sont nombreuses, même parmi les créateurs de contenus. En janvier dernier par exemple, Benjamin Brillaud, de la chaine Nota Bene, racontait dans une vidéo tout le mal qu’il pensait de l’outil : « Le rendu de l’épisode était catastrophique. Il n’y avait plus d’incarnation, la pertinence des traductions laissait à désirer… ».

La généralisation du doublage automatique pose en outre question pour les métiers concernés. En juillet 2024, Brigitte Lecordier (célèbre voix, entre autres, de Son Goku et Son Gohan) demandait au micro de BFMTV : « Il faut que l’on se demande quelle société on veut pour nos enfants. Est-ce qu’on veut une société gérée par des robots, où le soir, un robot va leur lire une histoire pour aller dormir, ou la voix d’un comédien qui va raconter des belles choses et nous émouvoir ? ». Cette question de l’émotion revient désormais constamment dans les critiques formulées contre le doublage automatique.

Tous les créateurs de contenus ne sont d’ailleurs pas intéressés. Dans les propres commentaires de la vidéo d’annonce publiée hier soir par YouTube, beaucoup demandent ainsi que l’on puisse importer facilement ses propres pistes de doublage, plutôt que de laisser faire l’IA. En attendant, les personnes allergiques à ce doublage peuvent utiliser certains outils, comme l’extension YouTube No Translation disponible sur Chrome ou Firefox.

• YouTube a fait des retouches automatiques de vidéos sans l’accord de leurs auteurs

Comme nous l’indiquions hier, la mise à jour « majeure » 25H2 est disponible dans le canal Release Preview pour les personnes inscrites au programme Insider (depuis Windows Update). C’est l’équivalent d’une release candidate, donc d’une version finale, à moins que des bugs gênants soient trouvés durant cette dernière période avant diffusion.

• Windows 11 : la drôle de mise à jour annuelle 25H2

Microsoft avait promis que des images ISO seraient proposées pour tester plus facilement le système. Après un retard, elles ont finalement été publiées mercredi soir. On parle toujours bien d’une Release Preview, qui ne peut pour l’instant pas être considérée comme la version finale. Ces images sont proposées à des fins de tests, en simplifiant l’opération pour des installations natives ou en machines virtuelles.

Si ces images peuvent être utilisées telles quelles ou placées sur des clés USB via l’utilitaire de Microsoft, Rufus vient d’être lui aussi mis à jour. Dans une nouvelle version publiée hier soir, l’outil de préparation des clés USB annonce sa compatibilité avec la mise à jour 25H2 dans sa dernière révision 4.10 en bêta. Cette mouture ajoute d’ailleurs la prise en charge du thème sombre et corrige plusieurs bugs.

Comme nous l’indiquions hier, la mise à jour « majeure » 25H2 est disponible dans le canal Release Preview pour les personnes inscrites au programme Insider (depuis Windows Update). C’est l’équivalent d’une release candidate, donc d’une version finale, à moins que des bugs gênants soient trouvés durant cette dernière période avant diffusion.

• Windows 11 : la drôle de mise à jour annuelle 25H2

Microsoft avait promis que des images ISO seraient proposées pour tester plus facilement le système. Après un retard, elles ont finalement été publiées mercredi soir. On parle toujours bien d’une Release Preview, qui ne peut pour l’instant pas être considérée comme la version finale. Ces images sont proposées à des fins de tests, en simplifiant l’opération pour des installations natives ou en machines virtuelles.

Si ces images peuvent être utilisées telles quelles ou placées sur des clés USB via l’utilitaire de Microsoft, Rufus vient d’être lui aussi mis à jour. Dans une nouvelle version publiée hier soir, l’outil de préparation des clés USB annonce sa compatibilité avec la mise à jour 25H2 dans sa dernière révision 4.10 en bêta. Cette mouture ajoute d’ailleurs la prise en charge du thème sombre et corrige plusieurs bugs.