L’ANSSI a annoncé ce 7 septembre la mise en place d’un dispositif nommé REACTIV (REponse & ACTion Interministérielle face aux Violations de données). Créé à la demande du Premier ministre, il doit permettre la mobilisation immédiate des compétences et moyens de l’agence de sécurité pour les ministères touchés par des cyberattaques.
Selon l’annonce officielle, le nouveau mécanisme se traduit concrètement par une bascule des efforts opérationnels pour renforcer l’appui aux ministères sur deux volets : le traitement des compromissions de comptes utilisateurs et l’analyse des violations de données.
Surtout, REACTIV renforce l’autorité de l’agence sur deux points spécifiques. D’abord, la possibilité pour l’ANSSI d’imposer aux ministères des mesures immédiates de protection des données, à appliquer dans des délais contraints. Ensuite, la centralisation par l’agence de la communication technique de crise en cas d’attaque touchant des services de l’État.
Illustration : Flock
Ce renforcement « complète les mesures de la Feuille de route des efforts prioritaires en matière de sécurité numérique de l’État 2026 - 2027, dont le Premier ministre a demandé l’accélération de la mise en œuvre, afin de rehausser significativement et durablement le niveau de sécurité des réseaux ministériels », indique l’ANSSI.
Un tel mécanisme était-il nécessaire ? Probablement, car les faits plaident pour des capacités d’action supplémentaires. La mention par l’ANSSI de mesures immédiates « dans des délais contraints » semble le point essentiel de l’annonce. L’agence a toujours fonctionné jusqu’à présent sur un mode d’accompagnement et de conseil plutôt que d’injonction, ce qui change donc avec REACTIV. La question des moyens alloués à l’agence reste cependant entière, d’autant que les rôles de l’ANSSI vont se renforcer à l’aune des nouveaux textes européens sur la cybersécurité : NIS2, REC, DORA et le Cyber Resilience Act, que nous évoquions récemment.
Dans un billet dédié sur LinkedIn, Vincent Strubel, directeur de l’ANSSI, précise d’ailleurs que cet effort est « temporaire » et qu’il se fait « au détriment d’autres pans de la menace », que l’ANSSI ne perd « pas de vue pour autant ». REACTIV « n’évitera pas toutes les attaques, mais doit nous permettre d’être plus réactifs et plus directifs, pour au moins limiter la casse le temps que les mesures de long terme prennent effet, et de partager plus d’informations pour mieux comprendre », ajoute Vincent Strubel.
L’ANSSI a annoncé ce 7 septembre la mise en place d’un dispositif nommé REACTIV (REponse & ACTion Interministérielle face aux Violations de données). Créé à la demande du Premier ministre, il doit permettre la mobilisation immédiate des compétences et moyens de l’agence de sécurité pour les ministères touchés par des cyberattaques.
Selon l’annonce officielle, le nouveau mécanisme se traduit concrètement par une bascule des efforts opérationnels pour renforcer l’appui aux ministères sur deux volets : le traitement des compromissions de comptes utilisateurs et l’analyse des violations de données.
Surtout, REACTIV renforce l’autorité de l’agence sur deux points spécifiques. D’abord, la possibilité pour l’ANSSI d’imposer aux ministères des mesures immédiates de protection des données, à appliquer dans des délais contraints. Ensuite, la centralisation par l’agence de la communication technique de crise en cas d’attaque touchant des services de l’État.
Illustration : Flock
Ce renforcement « complète les mesures de la Feuille de route des efforts prioritaires en matière de sécurité numérique de l’État 2026 - 2027, dont le Premier ministre a demandé l’accélération de la mise en œuvre, afin de rehausser significativement et durablement le niveau de sécurité des réseaux ministériels », indique l’ANSSI.
Un tel mécanisme était-il nécessaire ? Probablement, car les faits plaident pour des capacités d’action supplémentaires. La mention par l’ANSSI de mesures immédiates « dans des délais contraints » semble le point essentiel de l’annonce. L’agence a toujours fonctionné jusqu’à présent sur un mode d’accompagnement et de conseil plutôt que d’injonction, ce qui change donc avec REACTIV. La question des moyens alloués à l’agence reste cependant entière, d’autant que les rôles de l’ANSSI vont se renforcer à l’aune des nouveaux textes européens sur la cybersécurité : NIS2, REC, DORA et le Cyber Resilience Act, que nous évoquions récemment.
Dans un billet dédié sur LinkedIn, Vincent Strubel, directeur de l’ANSSI, précise d’ailleurs que cet effort est « temporaire » et qu’il se fait « au détriment d’autres pans de la menace », que l’ANSSI ne perd « pas de vue pour autant ». REACTIV « n’évitera pas toutes les attaques, mais doit nous permettre d’être plus réactifs et plus directifs, pour au moins limiter la casse le temps que les mesures de long terme prennent effet, et de partager plus d’informations pour mieux comprendre », ajoute Vincent Strubel.
Le Cyber Resilience Act, un important règlement pour la cybersécurité en Europe, entrera dans une nouvelle phase le 11 septembre. À cette date, les fabricants auront l’obligation de signaler les failles activement exploitées et les incidents graves à l’ENISA, l’agence centrale européenne de cybersécurité.
Le règlement européen sur la résilience cyber, ou CRA (UE 2024/2847), est entré en vigueur le 10 décembre 2024. S’agissant d’un règlement, il s’applique à l’ensemble des pays membres de l’Union, sans distinction. Contrairement aux directives, il ne nécessite pas de transposition dans le droit national.
La pleine entrée en application est attendue pour décembre 2027. Les responsabilités seront alors nombreuses, ainsi que les entreprises concernées : toute structure commercialisant un produit qui intègre au moins un composant numérique y est soumise. Le CRA distingue trois niveaux de risque :
les produits « courants » (la grande majorité) relèvent d’une auto-évaluation du fabricant,
les produits « importants » (définis à l’annexe III) comprennent de nombreuses catégories – systèmes de gestion d’identité, les navigateurs, les gestionnaires de mots de passe, les antivirus, hyperviseurs ou encore les VPN – et nécessitent de passer par un organisme dédié,
les produits « critiques » (définis à l’annexe IV) comprennent les dispositifs matériels avec boitier de sécurité, les « passerelles pour compteur intelligent » et les systèmes de cartes à puce, qui nécessitent eux aussi un organisme dédié.
Avant d’entrer toutefois dans le cœur de ces obligations, la mise en application passe par une étape intermédiaire : le signalement des failles exploitées et des incidents graves.
L’obligation de faire remonter les informations
L’article 14 du règlement entre en application le 11 septembre 2026, donc dans quelques jours à peine. Il impose aux fabricants de produits comportant des éléments numériques de signaler deux types d’événements distincts : toute vulnérabilité activement exploitée affectant ces produits, et tout incident grave ayant un impact sur leur sécurité.
Plus précisément, le fabricant devra notifier l’ENISA dans les 24 heures suivant la découverte (elle est qualifiée de « précoce »). Un rapport complet devra être fourni dans les 72 heures, puis un rapport final dans les 14 jours. Ces délais sont les mêmes que pour la directive NIS2, afin d’harmoniser le cadre de la cybersécurité (nous y reviendrons). Ils sont également identiques pour les failles exploitées et les incidents graves.
L’ENISA a le rôle de guichet central. L’agence sera chargée de distribuer ensuite les informations aux CSIRT (Computer Security Incident Response Team) nationaux des pays membres de l’Union. En France, il s’agit du CERT-FR. Via ce dernier, l’ANSSI assure alors la réception, l’analyse et la coordination du traitement. Si le produit est commercialisé dans d’autres pays, le CERT-FR doit aussi diffuser les informations obtenues à ses homologues.
Si la pleine application du Cyber Resilience Act aura des conséquences majeures, l’obligation du 11 septembre n’en est pas moins cruciale. Et pour cause : non seulement l’obligation pèse sur de très nombreuses entreprises, mais elle est également rétroactive. Contrairement à d’autres cadres européens, comme l’obligation pour les smartphones d’avoir au moins cinq ans de mises à jour logicielles, le CRA s’applique rétroactivement à tous les produits commercialisés.
Il reste 73% de l'article à découvrir. Vous devez être abonné•e pour lire la suite de cet article. Déjà abonné•e ? Générez une clé RSS dans votre profil.
Cette distribution Linux se destine avant tout aux Mac équipés de puces Apple Silicon, que l’entreprise a inaugurées il y a six ans avec sa puce M1. Alors que les premières machines M6 sont depuis peu sur le marché, Asahi annonce la prise en charge des puces M3. Mais attention, il reste beaucoup de travail.
Asahi Linux vise à porter Linux sur les Mac équipés de puces Apple Silicon. Il s’agit d’un travail de titan, car l’architecture d’Apple n’est pas ouverte. Les développeurs procèdent donc par tâtonnement et rétro-ingénierie, sans aucune documentation technique pour les y aider. Apple n’a aucun intérêt en effet à documenter sa technologie, puisqu’elle est la seule à l’utiliser et qu’elle est consciente des très bonnes performances de ses puces, constituant un avantage concurrentiel certain.
Pour avancer, les développeurs doivent ainsi analyser les microprogrammes (firmwares), la mémoire et le comportement des composants (contrôleur d’affichage, processeur de sécurité, contrôleur mémoire unifiée, etc.). Il faut ensuite en déduire un fonctionnement reproductible pour l’intégrer dans un système d’exploitation libre. La distribution de référence est Fedora Asahi Remix, mais le travail effectué est notamment repris dans le noyau Linux.
Un gros pas vers les puces M3
Comme indiqué par Phoronix le 6 septembre, le support officiel des Mac équipés de puces Apple M3 (M3, M3 Pro, M3 Max) vient d’être intégré à l’installateur du projet. Seule exception, la version Ultra de la puce, que l’on peut retrouver dans le Mac Studio dans sa configuration maximale.
Le niveau de prise en charge est proche de celui déjà obtenu sur les puces M1 et M2 (et leurs variantes). Le support comprend notamment la webcam, les microphones intégrés, l’USB, le décodage vidéo matériel avec support de l’AV1, le Wi-Fi et le Bluetooth.
Attention cependant, car les mêmes limites initiales qu’avec les générations M1 et M2 recommencent, à cause de deux composants qui donnent du fil à retordre aux développeurs. D’abord, le contrôleur d’affichage (DCP, Display Controller Processor), un coprocesseur dédié et propriétaire introduit avec la puce A14 (iPhone 12). Son support n’est que très partiel, car il a fallu passer par un hyperviseur interceptant les appels entre macOS et la puce. En conséquence, la machine ne peut pas être mise en veille et le HDMI ne fonctionne pas.
De même, le support du GPU reste expérimental. Les performances sont donc très limitées et son utilisation consomme beaucoup plus d’énergie qu’elle ne le devrait. Lors de la conférence X.Org qui se tiendra du 28 au 30 septembre, une partie de l’équipe de développement viendra rendre compte des progrès accomplis sur ce point.
Un travail de longue haleine.
Dans le billet d’annonce sur le site officiel de la distribution, James Calligeros (l’un des développeurs d’Asahi) indique cependant que l’équipe aura davantage d’informations sur ces sujets dans les mois à venir. Comme avec les générations M1 et M2, il est très probable que les développeurs finiront par obtenir le support complet du GPU et du DCP. Sur les deux premières générations, GPU a atteint la conformité officielle (auprès du Khronos Group) pour OpenGL 4.6, OpenCL 3.0 et Vulkan 1.3 (ainsi qu’OpenGL ES 3.2)
Le travail reste cependant « ingrat », car il faut recommencer à chaque nouvelle génération de puces, à cause des changements d’architecture et autres améliorations apportées chaque année. Il en ira de même pour le support des puces M4.
En outre, il faut garder en tête que « pleinement fonctionnel » a une définition particulière dans le cadre d’Asahi. L’appellation indique surtout que toutes les fonctions de base sont supportées et que la machine a, dans l’ensemble, le comportement que l’on peut en attendre dans une utilisation quotidienne. Des fonctions restent indisponibles, comme le HDR ou certaines configurations Thunderbolt (pour les machines qui l’ont).
Une lente intégration dans le noyau Linux
Une partie du travail réalisé par les développeurs d’Asahi atterrit ensuite dans le noyau Linux lui-même. Le processus est bien sûr plus lent et sélectif, car seuls les composants jugés suffisamment matures sont intégrés. Ils sont alors soumis aux mainteneurs des sous-systèmes concernés (DRM pour l’affichage, IOMMU pour la gestion mémoire, etc.), selon le processus habituel de relecture par correctifs.
On retrouve ainsi des composants comme le pilote DCP de base, le contrôleur IOMMU pour la mémoire, le pilote SMC (contrôleur de gestion système) ou encore les contrôleurs GPIO. Le pilote graphique complet, en revanche, n’en fait pas partie. D’une part, il est nettement plus volumineux que les autres composants.
D’autre part, il est en grande partie écrit en Rust, ce qui avait soulevé des tensions sur les discussions d’intégration au noyau. Ces tensions avaient poussé Hector Martin, fondateur et responsable historique du projet, à démissionner de son rôle de mainteneur et de la direction. La décision était intervenue notamment à la suite de remontrances de Linus Torvalds. Ce dernier indiquait alors ne pas être contre Rust dans le noyau (le code Rust y est en augmentation depuis trois ans), mais il n’avait pas apprécié qu’Hector Martin passe par les réseaux sociaux pour tenter de convaincre la communauté.
Cette distribution Linux se destine avant tout aux Mac équipés de puces Apple Silicon, que l’entreprise a inaugurées il y a six ans avec sa puce M1. Alors que les premières machines M6 sont depuis peu sur le marché, Asahi annonce la prise en charge des puces M3. Mais attention, il reste beaucoup de travail.
Asahi Linux vise à porter Linux sur les Mac équipés de puces Apple Silicon. Il s’agit d’un travail de titan, car l’architecture d’Apple n’est pas ouverte. Les développeurs procèdent donc par tâtonnement et rétro-ingénierie, sans aucune documentation technique pour les y aider. Apple n’a aucun intérêt en effet à documenter sa technologie, puisqu’elle est la seule à l’utiliser et qu’elle est consciente des très bonnes performances de ses puces, constituant un avantage concurrentiel certain.
Pour avancer, les développeurs doivent ainsi analyser les microprogrammes (firmwares), la mémoire et le comportement des composants (contrôleur d’affichage, processeur de sécurité, contrôleur mémoire unifiée, etc.). Il faut ensuite en déduire un fonctionnement reproductible pour l’intégrer dans un système d’exploitation libre. La distribution de référence est Fedora Asahi Remix, mais le travail effectué est notamment repris dans le noyau Linux.
Un gros pas vers les puces M3
Comme indiqué par Phoronix le 6 septembre, le support officiel des Mac équipés de puces Apple M3 (M3, M3 Pro, M3 Max) vient d’être intégré à l’installateur du projet. Seule exception, la version Ultra de la puce, que l’on peut retrouver dans le Mac Studio dans sa configuration maximale.
Le niveau de prise en charge est proche de celui déjà obtenu sur les puces M1 et M2 (et leurs variantes). Le support comprend notamment la webcam, les microphones intégrés, l’USB, le décodage vidéo matériel avec support de l’AV1, le Wi-Fi et le Bluetooth.
Attention cependant, car les mêmes limites initiales qu’avec les générations M1 et M2 recommencent, à cause de deux composants qui donnent du fil à retordre aux développeurs. D’abord, le contrôleur d’affichage (DCP, Display Controller Processor), un coprocesseur dédié et propriétaire introduit avec la puce A14 (iPhone 12). Son support n’est que très partiel, car il a fallu passer par un hyperviseur interceptant les appels entre macOS et la puce. En conséquence, la machine ne peut pas être mise en veille et le HDMI ne fonctionne pas.
De même, le support du GPU reste expérimental. Les performances sont donc très limitées et son utilisation consomme beaucoup plus d’énergie qu’elle ne le devrait. Lors de la conférence X.Org qui se tiendra du 28 au 30 septembre, une partie de l’équipe de développement viendra rendre compte des progrès accomplis sur ce point.
Un travail de longue haleine.
Dans le billet d’annonce sur le site officiel de la distribution, James Calligeros (l’un des développeurs d’Asahi) indique cependant que l’équipe aura davantage d’informations sur ces sujets dans les mois à venir. Comme avec les générations M1 et M2, il est très probable que les développeurs finiront par obtenir le support complet du GPU et du DCP. Sur les deux premières générations, GPU a atteint la conformité officielle (auprès du Khronos Group) pour OpenGL 4.6, OpenCL 3.0 et Vulkan 1.3 (ainsi qu’OpenGL ES 3.2)
Le travail reste cependant « ingrat », car il faut recommencer à chaque nouvelle génération de puces, à cause des changements d’architecture et autres améliorations apportées chaque année. Il en ira de même pour le support des puces M4.
En outre, il faut garder en tête que « pleinement fonctionnel » a une définition particulière dans le cadre d’Asahi. L’appellation indique surtout que toutes les fonctions de base sont supportées et que la machine a, dans l’ensemble, le comportement que l’on peut en attendre dans une utilisation quotidienne. Des fonctions restent indisponibles, comme le HDR ou certaines configurations Thunderbolt (pour les machines qui l’ont).
Une lente intégration dans le noyau Linux
Une partie du travail réalisé par les développeurs d’Asahi atterrit ensuite dans le noyau Linux lui-même. Le processus est bien sûr plus lent et sélectif, car seuls les composants jugés suffisamment matures sont intégrés. Ils sont alors soumis aux mainteneurs des sous-systèmes concernés (DRM pour l’affichage, IOMMU pour la gestion mémoire, etc.), selon le processus habituel de relecture par correctifs.
On retrouve ainsi des composants comme le pilote DCP de base, le contrôleur IOMMU pour la mémoire, le pilote SMC (contrôleur de gestion système) ou encore les contrôleurs GPIO. Le pilote graphique complet, en revanche, n’en fait pas partie. D’une part, il est nettement plus volumineux que les autres composants.
D’autre part, il est en grande partie écrit en Rust, ce qui avait soulevé des tensions sur les discussions d’intégration au noyau. Ces tensions avaient poussé Hector Martin, fondateur et responsable historique du projet, à démissionner de son rôle de mainteneur et de la direction. La décision était intervenue notamment à la suite de remontrances de Linus Torvalds. Ce dernier indiquait alors ne pas être contre Rust dans le noyau (le code Rust y est en augmentation depuis trois ans), mais il n’avait pas apprécié qu’Hector Martin passe par les réseaux sociaux pour tenter de convaincre la communauté.
Sync-in est une solution d’hébergement et de synchronisation de fichiers libre et open source (licence AGPL 3). Après une version 2.4 en juin, la 2.5 vient de paraître, avec à son bord plusieurs nouveautés importantes.
Elle introduit d’abord un système de favoris, une vue dédiée dans laquelle on peut placer aussi bien des fichiers que des espaces collaboratifs et des partages. On y trouve également des filtres, options de tri, informations sur leur emplacement ainsi qu’un affichage en liste ou en galerie.
Sync-in 2.5 introduit aussi un panneau de sélection. Il s’ouvre automatiquement lorsqu’on clique sur l’icône d’un fichier, avec ou sans sélection multiple. Dans le panneau, on trouve des informations sur les éléments choisis, dont la taille totale et un accès aux fonctions disponibles.
L’activité récente a été unifiée : les fichiers et commentaires sont réunis dans la même chronologie, que l’on peut organiser par période, avec possibilité de filtrer par type d’activité. La nouvelle mouture améliore aussi les copies, déplacements et envois, avec un volet repensé et la possibilité d’ignorer les fichiers quand des conflits sont détectés. Citons en outre une amélioration générale de l’accessibilité, ainsi qu’une meilleure recherche en texte intégral.
La version 2.5 comporte en outre quelques changements importants liés à la sécurité. Le plus significatif est sans doute l’obligation par défaut d’avoir une adresse e-mail vérifiée lorsque l’on passe par un fournisseur OIDC (OpenID Connect). Si c’est impossible pour une raison ou une autre, la personne chargée de l’administration du serveur devra modifier la valeur de l’option auth.oidc.security.requireVerifiedEmail pour false.
Sync-in est une solution d’hébergement et de synchronisation de fichiers libre et open source (licence AGPL 3). Après une version 2.4 en juin, la 2.5 vient de paraître, avec à son bord plusieurs nouveautés importantes.
Elle introduit d’abord un système de favoris, une vue dédiée dans laquelle on peut placer aussi bien des fichiers que des espaces collaboratifs et des partages. On y trouve également des filtres, options de tri, informations sur leur emplacement ainsi qu’un affichage en liste ou en galerie.
Sync-in 2.5 introduit aussi un panneau de sélection. Il s’ouvre automatiquement lorsqu’on clique sur l’icône d’un fichier, avec ou sans sélection multiple. Dans le panneau, on trouve des informations sur les éléments choisis, dont la taille totale et un accès aux fonctions disponibles.
L’activité récente a été unifiée : les fichiers et commentaires sont réunis dans la même chronologie, que l’on peut organiser par période, avec possibilité de filtrer par type d’activité. La nouvelle mouture améliore aussi les copies, déplacements et envois, avec un volet repensé et la possibilité d’ignorer les fichiers quand des conflits sont détectés. Citons en outre une amélioration générale de l’accessibilité, ainsi qu’une meilleure recherche en texte intégral.
La version 2.5 comporte en outre quelques changements importants liés à la sécurité. Le plus significatif est sans doute l’obligation par défaut d’avoir une adresse e-mail vérifiée lorsque l’on passe par un fournisseur OIDC (OpenID Connect). Si c’est impossible pour une raison ou une autre, la personne chargée de l’administration du serveur devra modifier la valeur de l’option auth.oidc.security.requireVerifiedEmail pour false.
L’éditeur audio multiplateforme et open source Audacity était connu pour son interface très « old school ». Les développeurs ne voulaient manifestement plus de cette étiquette : la nouvelle version 4.0 modernise largement l’interface.
Dans Audacity 4.0, l’interface a été réécrite en Qt. Esthétiquement beaucoup plus actuelle, elle permet la réorganisation libre des panneaux et la création d’espaces de travail, qui enregistrent les dispositions personnalisées. Des thèmes clair, sombre et haut contraste apparaissent également. Signalons aussi un spectrogramme redessiné au rendu plus rapide et des effets retravaillés, sur le plan esthétique et des performances.
Outre le changement visuel, les nouveautés sont nombreuses. Par exemple, l’édition par clips a été repensée. On peut maintenant sélectionner directement les clips, en modifier plusieurs simultanément, les grouper ou encore les déplacer librement entre les pistes. Le découpage se veut plus intuitif en proposant son propre outil et des commandes dédiées. De même, la tête de lecture reste visible pendant la navigation et peut être déplacée pendant la lecture. Chaque en-tête dispose en outre de vumètres pour l’enregistrement et la lecture.
La nouvelle mouture améliore aussi sa gestion des périphériques système, leur actualisation et le mapping personnalisé des canaux. Les changements opérés au niveau du système se reflètent maintenant dans l’application. De plus, la version Windows supporte désormais le protocole ASIO (Audio Stream Input/Output), permettant à Audacity une communication plus directe avec la carte son, avec à la clé une amélioration de la latence et de la fiabilité.
Attention cependant, car toutes les fonctions d’Audacity 3 ne sont pas encore présentes dans la branche 4.X, dont les Time Tracks, les pistes MIDI/Note, le Mixer, le Macro Manager, VAMP/LADSPA ou encore Play-at-speed. Les développeurs promettent leur retour dans de prochaines versions, signe du chantier conséquent qu’a été cette version.
Elle s’accompagne d’ailleurs d’un nouveau format de fichier, logiquement nommé .aup4, pour prendre la relève des fichiers .aup3. Ces derniers peuvent être ouverts avec Audacity 4.0 et seront automatiquement convertis.
La nouvelle mouture peut être téléchargée depuis le site officiel. Des versions Windows, macOS et Linux sont comme d’habitude fournies. On remarque que l’application s’est dotée pour l’occasion d’une nouvelle icône, reprise désormais partout sur le site.
L’éditeur audio multiplateforme et open source Audacity était connu pour son interface très « old school ». Les développeurs ne voulaient manifestement plus de cette étiquette : la nouvelle version 4.0 modernise largement l’interface.
Dans Audacity 4.0, l’interface a été réécrite en Qt. Esthétiquement beaucoup plus actuelle, elle permet la réorganisation libre des panneaux et la création d’espaces de travail, qui enregistrent les dispositions personnalisées. Des thèmes clair, sombre et haut contraste apparaissent également. Signalons aussi un spectrogramme redessiné au rendu plus rapide et des effets retravaillés, sur le plan esthétique et des performances.
Outre le changement visuel, les nouveautés sont nombreuses. Par exemple, l’édition par clips a été repensée. On peut maintenant sélectionner directement les clips, en modifier plusieurs simultanément, les grouper ou encore les déplacer librement entre les pistes. Le découpage se veut plus intuitif en proposant son propre outil et des commandes dédiées. De même, la tête de lecture reste visible pendant la navigation et peut être déplacée pendant la lecture. Chaque en-tête dispose en outre de vumètres pour l’enregistrement et la lecture.
La nouvelle mouture améliore aussi sa gestion des périphériques système, leur actualisation et le mapping personnalisé des canaux. Les changements opérés au niveau du système se reflètent maintenant dans l’application. De plus, la version Windows supporte désormais le protocole ASIO (Audio Stream Input/Output), permettant à Audacity une communication plus directe avec la carte son, avec à la clé une amélioration de la latence et de la fiabilité.
Attention cependant, car toutes les fonctions d’Audacity 3 ne sont pas encore présentes dans la branche 4.X, dont les Time Tracks, les pistes MIDI/Note, le Mixer, le Macro Manager, VAMP/LADSPA ou encore Play-at-speed. Les développeurs promettent leur retour dans de prochaines versions, signe du chantier conséquent qu’a été cette version.
Elle s’accompagne d’ailleurs d’un nouveau format de fichier, logiquement nommé .aup4, pour prendre la relève des fichiers .aup3. Ces derniers peuvent être ouverts avec Audacity 4.0 et seront automatiquement convertis.
La nouvelle mouture peut être téléchargée depuis le site officiel. Des versions Windows, macOS et Linux sont comme d’habitude fournies. On remarque que l’application s’est dotée pour l’occasion d’une nouvelle icône, reprise désormais partout sur le site.
La distribution Linux Omarchy attire un nombre croissant de regards. Bâtie sur Arch Linux, elle se distingue notamment par un parti pris graphique tranché et une esthétique soignée, en plus d’être très orientée vers le développement agentique. En arrière-plan cependant, son créateur est contesté pour ses positions sociales tranchées, tout comme le financement de la fondation qui accompagne Omarchy.
Omarchy est une distribution Linux créée par le Danois David Heinemeier Hansson, le plus souvent surnommé « DHH ». Créateur du célèbre framework de développement Ruby on Rails, il est également le directeur technique de 37signals, l’éditeur de Basecamp et HEY). Nous reviendrons sur DHH plus loin.
L’objectif d’Omarchy est de transformer une installation Arch Linux vierge en un système entièrement configuré, moderne et esthétique, fondé sur le compositeur Wayland Hyprland. Le projet a un prédécesseur, Omakub, qui avait la même logique mais était basé sur Ubuntu. Cette distribution se réclame de la philosophie « omakase » : le système impose des choix tranchés et s’adresse surtout à des personnes « capables » de l’apprécier.
Concrètement, cette philosophie s’illustre par des choix très marqués sur les thèmes ou encore les applications embarquées (comme Neovim, Alacritty et Chromium), ainsi qu’une interface globalement pensée pour un pilotage au clavier plutôt qu’à la souris. Comme certaines autres distributions Linux, les mises à jour passent par un système de snapshots (instantanés) au lieu d’un gestionnaire plus classique de paquets.
De la technique et des agents
Omarchy se destine largement aux développeurs et utilisateurs techniques. Cette orientation se reflète dans le choix des applications embarquées et dans la configuration de l’environnement. Le choix d’Hyprland est par exemple marquant, car ce compositeur a été créé avec le « tiling » en tête, c’est-à-dire l’organisation automatique des fenêtres. Le clavier est alors utilisé pour passer de l’une à l’autre, changer leur taille ou encore les déplacer vers d’autres espaces de travail. Le tout s’accompagne de nombreux visuels appréciés aujourd’hui : animations, coins arrondis, ombres, etc.
Si Hyprland s’occupe des fenêtres et de leur gestion, les éléments graphiques sont construits avec Quickshell. Ce framework (cadriciel) permet de développer des éléments graphiques, en l’occurrence la barre de menu, les widgets, le menu de lancement, les notifications, l’écran de verrouillage, les contrôles audio et ainsi de suite. Omarchy a donc une identité visuelle forte, sans passer par KDE ou GNOME. La distribution se sert d’Hyprland et Quickshell pour aboutir au résultat voulu.
Source : Dashen Tech
Cette identité visuelle et ce maniement peuvent rebuter les nouveaux venus, mais ils peuvent s’apprendre, même pour les personnes n’ayant pas d’expérience de ce type d’interface. Omarchy affiche un positionnement différent de la plupart des distributions qui sont initialement « génériques » et doivent souvent être personnalisées pour correspondre aux usages. L’environnement d’Omarchy est pensé comme un tout, le système trahissant l’idée de ce que doit être un « bon environnement », avec les avantages et inconvénients que cela comporte. La distribution est d’ailleurs souvent qualifiée d’« opiniated », c’est-à-dire avec une position assumée.
« Moins de configuration et plus d’utilisation » pourrait être la devise d’Omarchy, mais une utilisation basée sur le clavier et le terminal.
Avec la version 4.0 du système, nommée Quatro, Omarchy a d’ailleurs fait un pas supplémentaire vers les développeurs. Le système se fait plus agentique, avec un shell de bureau réécrit en un seul processus, des mises à jour maintenant basées sur pacman et un agent maintenant aux premières loges, avec une place fixe. Il dispose d’un panneau de quota et intègre un diagnostic automatique des plantages, ainsi qu’une compétence (skill) dédiée pour reconfigurer la machine. On peut choisir parmi neuf agents par défaut, dont Claude, Codex, Gemini, Grok et Copilot (aucun n’est présélectionné). Il vous faut un module particulier sur le bureau ? Demandez à l’agent.
Une fondation, des millions de dollars
La sortie de Quatro le 14 aout a été suivie une semaine plus tard d’une annonce importante pour la distribution : le lancement de la fondation Omacom. Les fondations sont des outils courants dans le monde de l’open source, car elles permettent de gérer l’avenir d’un projet de manière collégiale ou non, ainsi que d’engranger des donations. En lançant la fondation, David Heinemeier Hansson a indiqué vouloir concrétiser cette fois la « prophétie de l’année de Linux ». Il estime que « toutes les pièces sont en place ».
Douze membres fondateurs sont nommés : Tobi Lütke (Shopify), Patrick Collison (Stripe), Michael Dell (Dell Technologies), Jack Dorsey (Block), Matthew Prince (Cloudflare), Brendan Iribe (Sesame, ancien cofondateur d’Oculus), Jason Fried (37signals), Drew Houston (Dropbox), Peter Steinberger (créateur de l’outil d’IA OpenClaw), Brian Armstrong (Coinbase), Yunjie Dai (TapTap) et DHH lui-même. Chaque membre a apporté un million de dollars sur la table.
La somme, déjà conséquente, a été encore augmentée par l’arrivée de plusieurs autres personnes, avec chacune 100 000 dollars : Ryan R. Hughes (Oodle), Ed Huang (PingCAP), Adrien Treccani (Metaco/Ripple) et Max Schoening (Notion). Deux entreprises, 1Password et 37signals, participent également en leur nom propre, avec un budget de 100 000 dollars par an pendant trois ans.
Depuis, les critiques fusent de toute part.
Un créateur très contesté
Si Omarchy semble actuellement la star des réseaux sociaux avec son esthétique et son environnement pensé pour les développeurs, les discussions autour de la distribution ne sont pas que techniques. La figure de DHH est très contestée.
En 2021, il s’était déjà illustré chez Basecamp, dont il était le créateur et patron. Il avait alors interdit toutes les discussions politiques et sociales au sein de l’entreprise, y compris sur les outils utilisés. À l’époque, cette seule mesure avait provoqué le départ d’environ un tiers des effectifs en quelques semaines, dont la responsable design et la responsable marketing. À l’extérieur, beaucoup s’étaient également dit déçus.
Il reste 59% de l'article à découvrir. Vous devez être abonné•e pour lire la suite de cet article. Déjà abonné•e ? Générez une clé RSS dans votre profil.
Vivaldi 8.2 vient tout juste de paraître. À son bord, plusieurs nouvelles fonctions, dont la simplification de la calculatrice, qui peut désormais s’utiliser directement dans la barre d’adresse.
Les opérations y sont réalisées en temps réel, un appui sur Entrée envoyant les informations dans le presse-papier. Vivaldi précise que ces entrées ne sont pas enregistrées, même pas dans l’historique. Pour les personnes qui préféraient réserver cette fonction aux commandes rapides, une option permet de désactiver la calculatrice dans la barre d’adresse.
Vivaldi 8.2 renforce également la découverte des PWA (Progressive Web Apps). Le changement consiste surtout en un bouton apparaissant à droite de la barre d’adresse quand une application web compatible est découverte, par exemple WhatsApp. Après un clic sur le bouton, un petit panneau apparait pour confirmer l’installation. Une PWA profite, pour rappel, de certains comportements intégrés du système utilisé. Sur Windows par exemple, on peut l’épingler à la barre des tâches et dans le menu Démarrer. Chaque application a ses propres réglages.
Si les notes de version sont plus courtes que d’habitude, elles se finissent sur une annonce importante : Vivaldi travaille sur une version entreprise. L’éditeur dit viser « les organisations de toutes tailles – des entreprises et institutions publiques aux écoles ». Il donne peu d’informations pour l’instant, évoquant simplement une gestion de la vie privée, le déploiement centralisé et les mises à jour, ainsi que des personnalisations pour les organisations.
L’arrivée de cette version pourrait être significative pour Vivaldi. Viser le marché des entreprises implique notamment un cycle dédié de parution des mises à jour, pour pouvoir corriger les bugs et failles de sécurité, sans toucher au cycle fonctionnel. C’est ce que fait par exemple la version ESR de Firefox. Chrome et Edge disposent eux aussi d’une telle version, mais sur un délai bien plus court de huit semaines, via le canal Extended Stable.
Vivaldi 8.2 vient tout juste de paraître. À son bord, plusieurs nouvelles fonctions, dont la simplification de la calculatrice, qui peut désormais s’utiliser directement dans la barre d’adresse.
Les opérations y sont réalisées en temps réel, un appui sur Entrée envoyant les informations dans le presse-papier. Vivaldi précise que ces entrées ne sont pas enregistrées, même pas dans l’historique. Pour les personnes qui préféraient réserver cette fonction aux commandes rapides, une option permet de désactiver la calculatrice dans la barre d’adresse.
Vivaldi 8.2 renforce également la découverte des PWA (Progressive Web Apps). Le changement consiste surtout en un bouton apparaissant à droite de la barre d’adresse quand une application web compatible est découverte, par exemple WhatsApp. Après un clic sur le bouton, un petit panneau apparait pour confirmer l’installation. Une PWA profite, pour rappel, de certains comportements intégrés du système utilisé. Sur Windows par exemple, on peut l’épingler à la barre des tâches et dans le menu Démarrer. Chaque application a ses propres réglages.
Si les notes de version sont plus courtes que d’habitude, elles se finissent sur une annonce importante : Vivaldi travaille sur une version entreprise. L’éditeur dit viser « les organisations de toutes tailles – des entreprises et institutions publiques aux écoles ». Il donne peu d’informations pour l’instant, évoquant simplement une gestion de la vie privée, le déploiement centralisé et les mises à jour, ainsi que des personnalisations pour les organisations.
L’arrivée de cette version pourrait être significative pour Vivaldi. Viser le marché des entreprises implique notamment un cycle dédié de parution des mises à jour, pour pouvoir corriger les bugs et failles de sécurité, sans toucher au cycle fonctionnel. C’est ce que fait par exemple la version ESR de Firefox. Chrome et Edge disposent eux aussi d’une telle version, mais sur un délai bien plus court de huit semaines, via le canal Extended Stable.
L’Organisation européenne pour la recherche nucléaire utilise Linux pour ses besoins depuis longtemps. Dès les années 1990, le CERN s’était créé sa propre distribution en se basant sur Red Hat. En 2004, il s’était associé au Fermilab pour créer Scientific Linux (également basée sur Red Hat), avant d’entamer en 2015 une migration vers CentOS. En 2022, après l’annonce – très mal reçue – de Red Hat sur la fin de CentOS au profit de CentOS Stream, le CERN avait décidé de migrer vers AlmaLinux, autre distribution compatible Red Hat.
Le laboratoire a cependant décidé de se détourner de Red Hat, comme le rapporte Phoronix, qui a assisté à la conférence MiniDebConf, à laquelle participait le CERN. Les ingénieurs avaient bien, dans un premier temps, considéré un passage vers CentOS Stream, mais l’obligation du niveau d’instructions -march=x86-64-v2 par défaut à la compilation a été perçue par le CERN comme une forme d’« obsolescence forcée » pour le matériel ancien.
Le niveau d’instruction est un découpage artificiel permettant de cibler un lot de fonctionnalités au sein du processeur. Le niveau v2 mentionné correspond à une bascule effectuée par Red Hat Enterprise Linux 9, ce qui impliquait notamment les instructions SSE 4.2. RHEL 10 a imposé le niveau v3, qui nécessitait par exemple les instructions AVX2, FMA ou encore VEX. Ce découpage, nommé ISA (Instruction Set Architecture), a été violemment critiqué par Linus Torvalds fin 2024. Il estimait notamment la classification « stupide », car elle donnait l’impression erronée que la progression des jeux d’instruction était linéaire.
Le CERN avait, quoi qu’il en soit, pris bonne note des changements imposés par Red Hat. Lors de la conférence, le laboratoire a donc annoncé qu’une transition étant en préparation : d’ici la fin de l’année, l’intégralité du parc informatique fonctionnera sous Debian 13. Au total, 2 200 ordinateurs industriels et systèmes embarqués, utilisés pour le contrôle des accélérateurs de particules, seront concernés. En revanche, les centres de données et l’informatique expérimentale restent pour l’instant sur RHEL ou AlmaLinux.
L’Organisation européenne pour la recherche nucléaire utilise Linux pour ses besoins depuis longtemps. Dès les années 1990, le CERN s’était créé sa propre distribution en se basant sur Red Hat. En 2004, il s’était associé au Fermilab pour créer Scientific Linux (également basée sur Red Hat), avant d’entamer en 2015 une migration vers CentOS. En 2022, après l’annonce – très mal reçue – de Red Hat sur la fin de CentOS au profit de CentOS Stream, le CERN avait décidé de migrer vers AlmaLinux, autre distribution compatible Red Hat.
Le laboratoire a cependant décidé de se détourner de Red Hat, comme le rapporte Phoronix, qui a assisté à la conférence MiniDebConf, à laquelle participait le CERN. Les ingénieurs avaient bien, dans un premier temps, considéré un passage vers CentOS Stream, mais l’obligation du niveau d’instructions -march=x86-64-v2 par défaut à la compilation a été perçue par le CERN comme une forme d’« obsolescence forcée » pour le matériel ancien.
Le niveau d’instruction est un découpage artificiel permettant de cibler un lot de fonctionnalités au sein du processeur. Le niveau v2 mentionné correspond à une bascule effectuée par Red Hat Enterprise Linux 9, ce qui impliquait notamment les instructions SSE 4.2. RHEL 10 a imposé le niveau v3, qui nécessitait par exemple les instructions AVX2, FMA ou encore VEX. Ce découpage, nommé ISA (Instruction Set Architecture), a été violemment critiqué par Linus Torvalds fin 2024. Il estimait notamment la classification « stupide », car elle donnait l’impression erronée que la progression des jeux d’instruction était linéaire.
Le CERN avait, quoi qu’il en soit, pris bonne note des changements imposés par Red Hat. Lors de la conférence, le laboratoire a donc annoncé qu’une transition étant en préparation : d’ici la fin de l’année, l’intégralité du parc informatique fonctionnera sous Debian 13. Au total, 2 200 ordinateurs industriels et systèmes embarqués, utilisés pour le contrôle des accélérateurs de particules, seront concernés. En revanche, les centres de données et l’informatique expérimentale restent pour l’instant sur RHEL ou AlmaLinux.
WinUI est désormais un projet entièrement hébergé dans un dépôt GitHub, les ingénieurs de Microsoft y travaillant directement. Les travaux devraient donc accélérer et les prétentions de l’entreprise sont nombreuses, mais elle a souvent agacé les développeurs avec sa feuille de route incohérente.
Fin août 2026, Microsoft a achevé la dernière phase d’un plan annoncé en juillet 2025 : faire du développement de WinUI un processus véritablement public sur GitHub. Ce kit de développement, qui se focalise sur les interfaces des applications pour Windows, est considéré désormais comme pleinement open source.
Ce n’est pas un changement de licence, car le dépôt est sous licence MIT depuis décembre 2018. Le vrai changement vient du développement quotidien, qui se déroule entièrement dans le dépôt. Jusqu’à présent, ce dernier était seulement un miroir de code déjà écrit en interne. Autrement dit, le dépôt était secondaire, dans la mesure où l’éditeur ne faisait qu’y reverser ce qu’il élaborait, sans vraiment tenir compte des contributions extérieures.
Les ingénieurs de Microsoft compilent, valident et testent dorénavant leurs modifications directement dans le dépôt public, avec la traçabilité associée. On peut cependant formuler deux réserves. D’une part, les pull requests fusionnées proviennent exclusivement des développeurs Microsoft pour l’instant, a priori dans l’idée de valider complètement le pipeline de production avant de l’ouvrir aux contributions externes. D’autre part, le compilateur XAML – essentiel pour WinUI – reste fermé. Lors de la conférence Build, Microsoft a indiqué qu’elle souhaitait d’abord en moderniser le code, avant de l’ouvrir à la communauté. Aucune date n’a été donnée.
Microsoft semble sérieuse, mais…
Cette bascule s’inscrit dans un contexte plus large. Microsoft a affirmé, lors de la conférence Build 2026, un engagement fort envers WinUI comme plateforme native de Windows 11, au point d’abandonner l’appellation « WinUI 3 » pour éviter de laisser croire à une future « rupture » technologique. Depuis plusieurs mois, à travers l’initiative « K2 » pour Windows 11, Microsoft insiste largement sur les performances et les interfaces natives sur son système. L’éditeur semble décidé à utiliser ses propres technologies, notamment pour le menu Démarrer, jusqu’ici développé avec React Native.
La question du sérieux de Microsoft reste toutefois débattue dans la communauté de développeurs, qui garde un souvenir circonspect de l’historique WinRT/UWP. Des éléments plaident en faveur d’une vraie volonté, dont le respect (globalement) du calendrier fixé et la traçabilité du travail des ingénieurs sur le dépôt. Microsoft sait en outre qu’elle est attendue au tournant. Mais l’historique de l’entreprise sur les interfaces ne plaide pas en sa faveur, après avoir réinventé plusieurs fois la roue ces quinze dernières années.
… de nombreuses promesses n’ont pas été tenues
Si Microsoft renforce son propre usage de WinUI, le framework devrait rapidement évoluer. Les reproches sont tenaces, notamment des performances pas à la hauteur des prétentions « natives », mais de gros travaux sont en cours. Beaucoup reprochent également à l’éditeur son manque de suivi entre UWP, WinUI 2 et 3, avec une absence notable de parité fonctionnelle. Un écosystème souvent jugé incohérent et fragmenté.
Les tickets se sont aussi accumulés depuis deux ans et WinUI traine un certain nombre de casseroles techniques. Par exemple, un bug connu depuis longtemps provoque un plantage des applications utilisant à la fois WinUI 3 et le trimming, qui doit réduire la taille des exécutables en supprimant le code non utilisé. La faute à un conflit avec le fonctionnement de XAML, qui s’appuie lourdement sur la réflexion à l’exécution (résolution de types par nom, liaison de données, convertisseurs, gestionnaires d’événements déclarés en XAML).
WinUI est désormais un projet entièrement hébergé dans un dépôt GitHub, les ingénieurs de Microsoft y travaillant directement. Les travaux devraient donc accélérer et les prétentions de l’entreprise sont nombreuses, mais elle a souvent agacé les développeurs avec sa feuille de route incohérente.
Fin août 2026, Microsoft a achevé la dernière phase d’un plan annoncé en juillet 2025 : faire du développement de WinUI un processus véritablement public sur GitHub. Ce kit de développement, qui se focalise sur les interfaces des applications pour Windows, est considéré désormais comme pleinement open source.
Ce n’est pas un changement de licence, car le dépôt est sous licence MIT depuis décembre 2018. Le vrai changement vient du développement quotidien, qui se déroule entièrement dans le dépôt. Jusqu’à présent, ce dernier était seulement un miroir de code déjà écrit en interne. Autrement dit, le dépôt était secondaire, dans la mesure où l’éditeur ne faisait qu’y reverser ce qu’il élaborait, sans vraiment tenir compte des contributions extérieures.
Les ingénieurs de Microsoft compilent, valident et testent dorénavant leurs modifications directement dans le dépôt public, avec la traçabilité associée. On peut cependant formuler deux réserves. D’une part, les pull requests fusionnées proviennent exclusivement des développeurs Microsoft pour l’instant, a priori dans l’idée de valider complètement le pipeline de production avant de l’ouvrir aux contributions externes. D’autre part, le compilateur XAML – essentiel pour WinUI – reste fermé. Lors de la conférence Build, Microsoft a indiqué qu’elle souhaitait d’abord en moderniser le code, avant de l’ouvrir à la communauté. Aucune date n’a été donnée.
Microsoft semble sérieuse, mais…
Cette bascule s’inscrit dans un contexte plus large. Microsoft a affirmé, lors de la conférence Build 2026, un engagement fort envers WinUI comme plateforme native de Windows 11, au point d’abandonner l’appellation « WinUI 3 » pour éviter de laisser croire à une future « rupture » technologique. Depuis plusieurs mois, à travers l’initiative « K2 » pour Windows 11, Microsoft insiste largement sur les performances et les interfaces natives sur son système. L’éditeur semble décidé à utiliser ses propres technologies, notamment pour le menu Démarrer, jusqu’ici développé avec React Native.
La question du sérieux de Microsoft reste toutefois débattue dans la communauté de développeurs, qui garde un souvenir circonspect de l’historique WinRT/UWP. Des éléments plaident en faveur d’une vraie volonté, dont le respect (globalement) du calendrier fixé et la traçabilité du travail des ingénieurs sur le dépôt. Microsoft sait en outre qu’elle est attendue au tournant. Mais l’historique de l’entreprise sur les interfaces ne plaide pas en sa faveur, après avoir réinventé plusieurs fois la roue ces quinze dernières années.
… de nombreuses promesses n’ont pas été tenues
Si Microsoft renforce son propre usage de WinUI, le framework devrait rapidement évoluer. Les reproches sont tenaces, notamment des performances pas à la hauteur des prétentions « natives », mais de gros travaux sont en cours. Beaucoup reprochent également à l’éditeur son manque de suivi entre UWP, WinUI 2 et 3, avec une absence notable de parité fonctionnelle. Un écosystème souvent jugé incohérent et fragmenté.
Les tickets se sont aussi accumulés depuis deux ans et WinUI traine un certain nombre de casseroles techniques. Par exemple, un bug connu depuis longtemps provoque un plantage des applications utilisant à la fois WinUI 3 et le trimming, qui doit réduire la taille des exécutables en supprimant le code non utilisé. La faute à un conflit avec le fonctionnement de XAML, qui s’appuie lourdement sur la réflexion à l’exécution (résolution de types par nom, liaison de données, convertisseurs, gestionnaires d’événements déclarés en XAML).
La publication de plusieurs rapports techniques sur l’incident ayant conduit des agents IA d’OpenAI à attaquer Hugging Face permet aujourd’hui de mieux comprendre ce qui s’est passé. La chronologie est surprenante et pointe vers de nombreuses défaillances internes, mais le marketing continue de battre son plein.
Le 22 juillet, on apprenait que l’attaque enregistrée par Hugging Face contre ses infrastructures provenait en réalité d’OpenAI. Celle-ci n’avait pas choisi de s’en prendre à l’hébergeur de modèles IA : la faute en revenait à des agents qui étaient sortis de leur cadre de test pour atteindre plus rapidement les objectifs qui leur avaient été fixés, en l’occurrence la résolution des épreuves posées par le benchmark de cybersécurité ExploitGym.
Le 26 août, deux rapports beaucoup plus complets sont cependant apparus. Le premier vient d’OpenAI (PDF) et est une analyse technique fouillée des évènements. L’autre (PDF) de l’organisme à but non lucratif METR (Model Evaluation and Threat Research), mandaté par OpenAI comme expert indépendant et assisté d’un chercheur de Redwood Research. La chronologie semble digne d’un scénario de science-fiction au premier abord.
Des signaux dès mai 2026
Les premiers couacs sont apparus environ deux mois avant l’attaque contre Hugging Face, selon le rapport technique d’OpenAI. Le 8 mai, un agent de l’entreprise s’est retrouvé bloqué sur une tâche rendue volontairement impossible : accéder à des liens vers Google Drive depuis un environnement dépourvu d’accès internet.
L’agent ne se démonte pas pour autant et cible Artifactory, le gestionnaire de paquets utilisé en interne par OpenAI pour donner à ses agents un accès contrôlé aux dépendances de développement. L’agent attaque le logiciel au moyen d’une faille SSRF (server-side request forgery), mais échoue dans sa mise en pratique. Le processus laisse une scorie : un fichier écrit par l’agent dans Artifactory.
Le 12 mai, toujours dans le cadre d’un test, un deuxième agent trouve le fichier et conclut qu’il peut laisser par ce biais des messages à l’attention d’autres agents qui seraient susceptibles de disposer des ressources manquantes. Le lendemain, un troisième agent – disposant cette fois d’un accès internet – trouve ces notes et commence à s’en servir. Dans les jours qui suivent, un nombre croissant d’agents se met à utiliser ces fichiers comme un « message board » pour échanger sur les problèmes à résoudre.
Le 26 mai, plusieurs agents utilisent une faille SSRF pour obtenir un accès internet, cette fois avec succès. Ils découvrent six jetons d’authentification Hugging Face (qui avaient été exposés publiquement) et les partagent sur Artifactory, au bénéfice des autres agents. Un dépôt est même créé sur Hugging Face, ainsi qu’une application de relais dans le service Space.
Cet incident a finalement été découvert par OpenAI, mais n’a pas été rapporté aux responsables de détection et réponse aux incidents. Dans son rapport, l’entreprise avoue un défaut de communication.
L’escalade vers Hugging Face
Un mois plus tard, le 26 juin, OpenAI lance un test sur plusieurs agents, dans l’objectif de leur faire obtenir le meilleur score au benchmark ExploitGym. Les conditions sont cette fois connues, car c’est le processus qui aboutira à l’attaque contre Hugging Face en juillet. Pour rappel, OpenAI testait à ce moment deux modèles : GPT-5.6 Sol (leur modèle commercial le plus avancé actuellement) et un modèle interne, sans nom officiel, mais que METR nomme HPIM (« highly-persistent internal model ») dans son rapport.
Entre le 26 juin et le 4 juillet, les actions s’enchainent. Les agents ont d’abord découvert une faille dans un point de terminaison d’Artifactory servant au rafraichissement des jetons d’authentification et s’en sont servi pour obtenir des droits administrateur. Ces derniers ont été utilisés pour installer des plug-ins dans Artifactory, avec à la clé des capacités persistantes d’exécution de commandes. Dans l’intervalle, une alerte remonte le 27 juin pour signaler un comportement imprévu, mais n’est pas jugée bloquante. L’activité est alors devenue assez intense sur le serveur pour provoquer l’indisponibilité d’Artifactory le 6 juillet, déclenchant en interne un incident de sécurité. OpenAI dit alors avoir coupé le service compromis, révoqué les accréditations des agents et reconstruit une nouvelle instance d’Artifactory le même jour, effaçant l’ensemble des messages échangés par les agents.
Il reste 74% de l'article à découvrir. Vous devez être abonné•e pour lire la suite de cet article. Déjà abonné•e ? Générez une clé RSS dans votre profil.
Apple a envoyé un e-mail aux développeurs tiers pour les avertir d’un changement : « Nous vous contactons pour vous informer que les apps universelles pour macOS proposées sur le Mac App Store et nécessitant macOS 13 ou une version ultérieure peuvent désormais abandonner la prise en charge des Mac à processeur Intel ».
Cette prise en charge était obligatoire pour toute application publiée sur le Mac App Store, mais ne l’était bien sûr pas pour celles distribuées autrement. Le passage à l’architecture Arm remontant aujourd’hui à six ans avec la puce M1, le signal est clair : il est temps de passer à autre chose.
Apple vante d’ailleurs les avantages d’un tel abandon. En ciblant uniquement « arm64 » dans les réglages de compilation de l’application, le développement n’en sera que plus simple. En outre, plus besoin de passer par des binaires universels embarquant toutes les données pour les deux architectures (x86_64 et arm64). L’application s’en retrouvera d’autant allégée. Reste une condition : elle doit viser macOS 13 au moins.
Il n’y a bien sûr pas d’obligation à suivre ce conseil, les développeurs pouvant toujours compiler pour Intel s’ils le souhaitent. Comme l’indiquent nos confrères de MacG, macOS 27 et son Xcode correspondant ne pourront s’installer que sur des Mac Apple Silicon, plantant un nouveau clou dans le cercueil. macOS 27, alias Golden Gate, sera également la dernière version à prendre en charge la couche d’émulation Rosetta 2. 2027 sonnera définitivement le glas de l’architecture Intel chez Apple.
Apple a envoyé un e-mail aux développeurs tiers pour les avertir d’un changement : « Nous vous contactons pour vous informer que les apps universelles pour macOS proposées sur le Mac App Store et nécessitant macOS 13 ou une version ultérieure peuvent désormais abandonner la prise en charge des Mac à processeur Intel ».
Cette prise en charge était obligatoire pour toute application publiée sur le Mac App Store, mais ne l’était bien sûr pas pour celles distribuées autrement. Le passage à l’architecture Arm remontant aujourd’hui à six ans avec la puce M1, le signal est clair : il est temps de passer à autre chose.
Apple vante d’ailleurs les avantages d’un tel abandon. En ciblant uniquement « arm64 » dans les réglages de compilation de l’application, le développement n’en sera que plus simple. En outre, plus besoin de passer par des binaires universels embarquant toutes les données pour les deux architectures (x86_64 et arm64). L’application s’en retrouvera d’autant allégée. Reste une condition : elle doit viser macOS 13 au moins.
Il n’y a bien sûr pas d’obligation à suivre ce conseil, les développeurs pouvant toujours compiler pour Intel s’ils le souhaitent. Comme l’indiquent nos confrères de MacG, macOS 27 et son Xcode correspondant ne pourront s’installer que sur des Mac Apple Silicon, plantant un nouveau clou dans le cercueil. macOS 27, alias Golden Gate, sera également la dernière version à prendre en charge la couche d’émulation Rosetta 2. 2027 sonnera définitivement le glas de l’architecture Intel chez Apple.
Mozilla vient de publier de nouvelles versions de son navigateur pour l’ensemble des plateformes. Certaines contiennent des nouveautés importantes, particulièrement sur ordinateur et iOS.
Nouvelle mouture pour le navigateur de Mozilla, avec comme principale nouveauté la disponibilité de la Smart Window pour l’ensemble des utilisateurs en France, au Canada et aux États-Unis. En français, elle prend d’ailleurs officiellement le nom de « Fenêtre intelligente ».
Cette fonction est toujours en bêta et reste optionnelle. On y accède par le bouton Firefox situé en haut à droite de la fenêtre, près du menu hamburger (trois traits). Son utilisation réclame un compte Firefox, ce mode de navigation permettant ensuite de résumer des pages, comparer plusieurs onglets, retrouver des informations dans des onglets ou l’historique, obtenir des recommandations et ainsi de suite. Une fois la fonction activée, on peut choisir de toujours lancer Firefox dans ce mode.
Notez que la prise en charge de l’historique ne se fait qu’au sein de cette fenêtre intelligente. En outre, les conversations et « souvenirs » sont stockés localement, mais les requêtes transitent par les serveurs de Mozilla puis éventuellement vers d’autres, selon le modèle utilisé. Par défaut, Mistral Small 4 est recommandé. On peut également choisir entre Gemini 3.1 Flash Lite, Qwen 3 235B ou un autre LLM, à condition de fournir le point de terminaison et la clé API (ou jeton d’authentification).
Firefox 155 améliore dans la foulée cette fonction. Mozilla ajoute par exemple sous la fenêtre de conversation des boutons pour retourner rapidement dans des recherches précédentes. Les recherches passant par Exa sont également décrites comme beaucoup plus rapides, et la fonction d’organisation intelligente des onglets se veut plus pertinente. Rappelons que Firefox propose un réglage pour désactiver toutes les fonctions IA.
Parmi les autres nouveautés, on peut citer un nouveau compteur de traqueurs bloqués apparaissant au début de la barre d’adresse. Les conteneurs, « apparus » avec Firefox 153, peuvent maintenant être réorganisés, l’ordre choisi apparaissant ensuite partout où cette liste est affichée. Firefox 155 corrige en outre de nombreux bugs, dont un gênant qui pouvait empêcher une machine sous Linux d’entrer en veille après une longue session de navigation. Enfin, la version colmate une trentaine de failles de sécurité, dont 13 de dangerosité élevée.
Firefox pour iOS a désormais son Ad Blocker
Aux côtés de cette version pour ordinateurs, Firefox pour iOS a lui aussi du neuf. Mozilla a annoncé très officiellement ce 1ᵉʳ septembre l’intégration d’un bloqueur de publicité, nommé Ad Blocker. Il est construit sur la base de l’API d’Apple pour bloquer les contenus et la liste de filtrage EasyList. Une technique qui n’est pas neuve, Vivaldi proposant une fonction équivalente.
Ce blocage publicitaire n’est pas activé par défaut. Il faut se rendre dans les réglages puis dans la partie Navigation. Dans son billet, Mozilla prévient que l’efficacité de sa fonction n’est pas garantie : « Le bloqueur de publicités ne bloquera pas toutes les annonces. Les publicités diffusées directement par le site que vous visitez et les annonces affichées dans les résultats de recherche apparaîtront toujours ». En outre, les raccourcis et autres contenus sponsorisés affichés par Firefox ne sont pas pris en charge, mais peuvent être désactivés via un réglage séparé.
Ce bloqueur de publicités est une fonction supplémentaire et peut donc fonctionner de concert avec la protection améliorée contre le suivi qui, elle, s’occupe de bloquer les traqueurs.
Mozilla en profite pour lancer une pique à Apple dans un billet séparé (en lien dans l’annonce) : il serait temps que l’entreprise propose une véritable architecture pour les extensions de navigateur. Safari en propose, mais leur récupération passe par l’App Store. Rien d’équivalent n’est prévu pour les autres, Mozilla fustigeant au passage (une nouvelle fois) l’obligation d’utiliser WebKit comme moteur de rendu. Sur Android, rien de tout cela : Firefox utilise son moteur Gecko et prend en charge les extensions depuis longtemps.
Connexion
