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.
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.
Comme toujours avec les versions LTS (Long Term Support) d’Ubuntu, la première mouture « .1 » est attendue. Ubuntu 26.04.1 vient ainsi d’être mise à disposition, simplifiant dans un premier temps les nouvelles installations du système.
Cette version ne comprend aucune nouveauté. Elle est là pour reprendre l’ensemble des correctifs (bugs généraux et sécurité) sortis depuis la publication d’Ubuntu 26.04 en avril dernier. Les images ISO proposées permettent l’installation d’un système à jour, avec moins de téléchargements lors de la première session. Pour les utilisateurs existants d’Ubuntu 26.04, il n’y a rien à faire.
Ces versions « .1 » sont cependant importantes pour la mouture LTS précédente. Canonical applique la même stratégie depuis longtemps : une LTS ne peut être mise à jour vers la suivante qu’une fois la version « .1 » de celle-ci disponible, qui débloque alors un chemin de migration. Un choix qui répond à des critères de fiabilité, ces versions permettant de gommer les erreurs de jeunesse. Un comportement déroutant de prime abord, car il s’écoule plusieurs mois entre l’arrivée d’une nouvelle LTS et la disponibilité de son chemin de migration.
Une partie des utilisateurs d’Ubuntu 24.04 attend donc la 26.04.1, mais il faudra être encore un peu patient. Oliver Reiche, développeur chez Canonical, a indiqué que même si la 26.04.1 était effectivement disponible, le chemin de migration avait du retard. Il faudra attendre quelques semaines de plus, la faute à des « régressions dans une version récente de rust-coreutils ».
Quand le chemin de migration sera disponible, le système signalera cette possibilité. Comme le rappelle OMGUbuntu, il est toujours possible de forcer le passage avec la commande « sudo do-release-upgrade -d », mais la procédure n’est pas recommandée pour des questions de fiabilité.
Comme toujours avec les versions LTS (Long Term Support) d’Ubuntu, la première mouture « .1 » est attendue. Ubuntu 26.04.1 vient ainsi d’être mise à disposition, simplifiant dans un premier temps les nouvelles installations du système.
Cette version ne comprend aucune nouveauté. Elle est là pour reprendre l’ensemble des correctifs (bugs généraux et sécurité) sortis depuis la publication d’Ubuntu 26.04 en avril dernier. Les images ISO proposées permettent l’installation d’un système à jour, avec moins de téléchargements lors de la première session. Pour les utilisateurs existants d’Ubuntu 26.04, il n’y a rien à faire.
Ces versions « .1 » sont cependant importantes pour la mouture LTS précédente. Canonical applique la même stratégie depuis longtemps : une LTS ne peut être mise à jour vers la suivante qu’une fois la version « .1 » de celle-ci disponible, qui débloque alors un chemin de migration. Un choix qui répond à des critères de fiabilité, ces versions permettant de gommer les erreurs de jeunesse. Un comportement déroutant de prime abord, car il s’écoule plusieurs mois entre l’arrivée d’une nouvelle LTS et la disponibilité de son chemin de migration.
Une partie des utilisateurs d’Ubuntu 24.04 attend donc la 26.04.1, mais il faudra être encore un peu patient. Oliver Reiche, développeur chez Canonical, a indiqué que même si la 26.04.1 était effectivement disponible, le chemin de migration avait du retard. Il faudra attendre quelques semaines de plus, la faute à des « régressions dans une version récente de rust-coreutils ».
Quand le chemin de migration sera disponible, le système signalera cette possibilité. Comme le rappelle OMGUbuntu, il est toujours possible de forcer le passage avec la commande « sudo do-release-upgrade -d », mais la procédure n’est pas recommandée pour des questions de fiabilité.
La communauté Debian devait voter sur la place que les grands modèles de langage (LLM) pouvaient tenir dans le développement de la distribution Linux. Parmi les axes proposés, elle a choisi un quasi-statu quo. La décision divise, ayant notamment provoqué le départ d’au moins un des développeurs.
Fin juillet, nous indiquions que la communauté Debian allait être amenée à se prononcer sur la place des LLM dans le développement de la distribution. Plusieurs propositions étaient mises en avant, de la plus radicale à la plus modérée. À l’époque où nous avions écrit ces lignes, on pouvait en lire quatre, mais la communauté a finalement dû voter parmi huit propositions.
Proposition A : interdiction pure et simple des LLM dans les contributions au projet
Proposition B : usage autorisé, mais avec un encadrement strict, avec garanties de licence et responsabilité totale des contributions
Proposition C : rejet des LLM autant que possible, affichage obligatoire des usages et interdiction des LLM pour les communications entre contributeurs
Proposition D : la plus pragmatique, avec acceptation des contributions par l’IA et responsabilité complète, en revanche pas d’IA distante pour les données sensibles
Proposition E : le statu quo, chacun étant responsable de ses contributions, peu importe l’outil
Proposition F : utilisation découragée des LLM quand c’est possible et mise en avant du travail humain, responsabilité complète des contributions, mais liberté pour les mainteneurs de refuser les contributions IA
Proposition G : usage contrôlé des LLM pour les tâches périphériques (réflexion, analyse, recherche, critique de code…), mais interdiction dans les contributions
Proposition H : l’impact environnemental des LLM est jugé rédhibitoire, leur utilisation doit être découragée autant que possible
Le choix de la communauté
Les participants se sont prononcés pour l’option E. De toutes celles mises en avant, la E est la plus consensuelle, car elle ne change presque rien à la situation qui existait avant.
Officiellement, la proposition E s’intitule « Usage responsable de l’IA générative ». On peut y lire notamment que Debian « n’encourage pas ni n’interdit l’utilisation d’outils d’IA générative dans le développement, la maintenance ou la documentation des logiciels, l’empaquetage, la documentation et les autres médias publiés dans le projet Debian ». Le texte reconnait que ces outils peuvent largement améliorer la productivité des contributeurs « s’ils sont utilisés de manière responsable ». Cela permettrait aux personnes de se libérer du temps pour des tâches plus intensives, notamment celles réclamant un jugement, une expertise ou une critique.
Techniquement, l’usage de l’IA ne change pas les exigences habituelles de qualité, d’exactitude et de maintenabilité. Toute personne soumettant un code, qu’il soit tout ou partiellement rédigé par une IA générative, est responsable de ce qu’elle propose. Elle doit être en mesure de comprendre, relire et tester ce code, dans l’idée de pouvoir expliquer ce qu’il fait avec précision. Tout envoi aveugle d’un contenu généré par IA est jugé incompatible avec les pratiques de Debian.
Dans la proposition, on peut lire qu’il est explicitement demandé aux personnes participantes de ne jamais envoyer d’informations personnelles à des services d’IA externes. Il peut aussi bien s’agir de données personnelles habituelles que de clés cryptographiques, communications privées, identifiants ou encore bugs de sécurité sous embargo.
Enfin, pour les opérations automatisées à grande échelle, comme la génération de nombreux rapports de bugs ou la modification en masse des paquets, un processus spécifique devra être mis en place.
« Les Contributeurs qui entendent effectuer des actions impactant tout le projet comme la soumission massive de bogues ou la soumission massive de correctifs, des modifications de code à grande échelle ou d’autres changements ou requêtes automatisés concernant de nombreux paquets ou de nombreux contributeurs, doivent d’abord lancer une discussion et rechercher un consensus à l’aide des canaux du projet avant d’agir. De tels projets automatisés doivent être validés par un humain qui demeure responsable de son comportement et du résultat », indique ainsi la proposition E.
En somme, Debian continue « de compter sur le jugement et la responsabilité de ses contributeurs individuels ». Point important : la mention de l’utilisation de l’IA dans un projet est recommandée, mais pas obligatoire.
Division et colère
La communauté a parlé. La proposition E ne change fondamentalement rien : chacun peut faire ce qu’il veut, tant que les pratiques habituelles de Debian sont respectées. La distribution s’appuie depuis longtemps sur la responsabilité individuelle et la relecture par les pairs. Pas question donc de changer de philosophie. Cependant, lorsque l’on parle de Debian, il n’est pas question d’une entité unique et mystique, mais bien d’un ensemble de personnes contribuant au projet. La consécration de ce quasi-statu quo n’est donc pas anodine.
Si la communauté a parlé, elle est également divisée, aussi bien chez les contributeurs que les utilisateurs. Sur X par exemple, la publication de la nouvelle sur le compte It’s FOSS montre des réactions très diverses, certains comprenant la position, mais la plupart affichent de la méfiance, voire de la déception. Même constant dans les commentaires de Phoronix.
Parmi les réactions négatives, l’une d’entre elles ressort particulièrement : celle d’Antoine le Gonidec, contributeur de longue date au projet Debian. Sur les huit propositions, il était parrain des options A, C, G et H. En somme, toutes celles cherchant à interdire ou limiter l’usage des IA. Face à la victoire de la proposition E, Antoine le Gonidec n’a pas caché sa colère. Sur la liste officielle de diffusion Debian, le développeur a pris une décision radicale :
« Je ne peux pas soutenir la décision actuelle de Debian concernant l’utilisation des LLM, et je ne suis plus prêt à être considéré comme faisant partie de Debian selon ces nouvelles règles. Prétendre avoir une « position neutre » face au fascisme n’est pas de la neutralité, c’est une collaboration active »
Il se retire donc du projet, expliquant que les LLM s’appuient en grande partie sur des entreprises « soutenues par des fascistes ». De toutes les propositions, la E était « la plus pro-LLM de toutes les options ». Il dit ne plus être intéressé par quoi que ce soit provenant de Debian, déclarant avec acidité qu’il peut être remplacé « par n’importe quelle IA agentique ». « Je pense n’avoir jamais autant été déçu par une communauté en qui j’avais confiance », affirme-t-il.
L’importance de Debian
Si ce vote était attendu, c’est que Debian est l’une des distributions Linux les plus importantes. En plus du système lui-même, connu pour sa fiabilité et sa rigueur, Debian sert de base à de nombreuses distributions, dont la plus connue est Ubuntu, celle-ci servant à son tour de socle à d’autres comme Linux Mint.
Comme l’indique It’s FOSS, plusieurs projets ont choisi des approches beaucoup plus radicales. OpenJDK par exemple, édité par Oracle, refuse toute contribution générée par IA. Même chose pour le compilateur GCC. D’autres ont choisi une approche plus souple, en particulier le noyau Linux. Au sujet des LLM, Linus Torvalds a adopté une approche pragmatique, estimant que l’aide procurée par l’IA ne peut plus être empêchée, mais que certaines situations sont problématiques, notamment l’automatisation des rapports des bugs (qu’il a fustigée).
La communauté Debian devait voter sur la place que les grands modèles de langage (LLM) pouvaient tenir dans le développement de la distribution Linux. Parmi les axes proposés, elle a choisi un quasi-statu quo. La décision divise, ayant notamment provoqué le départ d’au moins un des développeurs.
Fin juillet, nous indiquions que la communauté Debian allait être amenée à se prononcer sur la place des LLM dans le développement de la distribution. Plusieurs propositions étaient mises en avant, de la plus radicale à la plus modérée. À l’époque où nous avions écrit ces lignes, on pouvait en lire quatre, mais la communauté a finalement dû voter parmi huit propositions.
Proposition A : interdiction pure et simple des LLM dans les contributions au projet
Proposition B : usage autorisé, mais avec un encadrement strict, avec garanties de licence et responsabilité totale des contributions
Proposition C : rejet des LLM autant que possible, affichage obligatoire des usages et interdiction des LLM pour les communications entre contributeurs
Proposition D : la plus pragmatique, avec acceptation des contributions par l’IA et responsabilité complète, en revanche pas d’IA distante pour les données sensibles
Proposition E : le statu quo, chacun étant responsable de ses contributions, peu importe l’outil
Proposition F : utilisation découragée des LLM quand c’est possible et mise en avant du travail humain, responsabilité complète des contributions, mais liberté pour les mainteneurs de refuser les contributions IA
Proposition G : usage contrôlé des LLM pour les tâches périphériques (réflexion, analyse, recherche, critique de code…), mais interdiction dans les contributions
Proposition H : l’impact environnemental des LLM est jugé rédhibitoire, leur utilisation doit être découragée autant que possible
Le choix de la communauté
Les participants se sont prononcés pour l’option E. De toutes celles mises en avant, la E est la plus consensuelle, car elle ne change presque rien à la situation qui existait avant.
Officiellement, la proposition E s’intitule « Usage responsable de l’IA générative ». On peut y lire notamment que Debian « n’encourage pas ni n’interdit l’utilisation d’outils d’IA générative dans le développement, la maintenance ou la documentation des logiciels, l’empaquetage, la documentation et les autres médias publiés dans le projet Debian ». Le texte reconnait que ces outils peuvent largement améliorer la productivité des contributeurs « s’ils sont utilisés de manière responsable ». Cela permettrait aux personnes de se libérer du temps pour des tâches plus intensives, notamment celles réclamant un jugement, une expertise ou une critique.
Techniquement, l’usage de l’IA ne change pas les exigences habituelles de qualité, d’exactitude et de maintenabilité. Toute personne soumettant un code, qu’il soit tout ou partiellement rédigé par une IA générative, est responsable de ce qu’elle propose. Elle doit être en mesure de comprendre, relire et tester ce code, dans l’idée de pouvoir expliquer ce qu’il fait avec précision. Tout envoi aveugle d’un contenu généré par IA est jugé incompatible avec les pratiques de Debian.
Dans la proposition, on peut lire qu’il est explicitement demandé aux personnes participantes de ne jamais envoyer d’informations personnelles à des services d’IA externes. Il peut aussi bien s’agir de données personnelles habituelles que de clés cryptographiques, communications privées, identifiants ou encore bugs de sécurité sous embargo.
Enfin, pour les opérations automatisées à grande échelle, comme la génération de nombreux rapports de bugs ou la modification en masse des paquets, un processus spécifique devra être mis en place.
« Les Contributeurs qui entendent effectuer des actions impactant tout le projet comme la soumission massive de bogues ou la soumission massive de correctifs, des modifications de code à grande échelle ou d’autres changements ou requêtes automatisés concernant de nombreux paquets ou de nombreux contributeurs, doivent d’abord lancer une discussion et rechercher un consensus à l’aide des canaux du projet avant d’agir. De tels projets automatisés doivent être validés par un humain qui demeure responsable de son comportement et du résultat », indique ainsi la proposition E.
En somme, Debian continue « de compter sur le jugement et la responsabilité de ses contributeurs individuels ». Point important : la mention de l’utilisation de l’IA dans un projet est recommandée, mais pas obligatoire.
Division et colère
La communauté a parlé. La proposition E ne change fondamentalement rien : chacun peut faire ce qu’il veut, tant que les pratiques habituelles de Debian sont respectées. La distribution s’appuie depuis longtemps sur la responsabilité individuelle et la relecture par les pairs. Pas question donc de changer de philosophie. Cependant, lorsque l’on parle de Debian, il n’est pas question d’une entité unique et mystique, mais bien d’un ensemble de personnes contribuant au projet. La consécration de ce quasi-statu quo n’est donc pas anodine.
Si la communauté a parlé, elle est également divisée, aussi bien chez les contributeurs que les utilisateurs. Sur X par exemple, la publication de la nouvelle sur le compte It’s FOSS montre des réactions très diverses, certains comprenant la position, mais la plupart affichent de la méfiance, voire de la déception. Même constant dans les commentaires de Phoronix.
Parmi les réactions négatives, l’une d’entre elles ressort particulièrement : celle d’Antoine le Gonidec, contributeur de longue date au projet Debian. Sur les huit propositions, il était parrain des options A, C, G et H. En somme, toutes celles cherchant à interdire ou limiter l’usage des IA. Face à la victoire de la proposition E, Antoine le Gonidec n’a pas caché sa colère. Sur la liste officielle de diffusion Debian, le développeur a pris une décision radicale :
« Je ne peux pas soutenir la décision actuelle de Debian concernant l’utilisation des LLM, et je ne suis plus prêt à être considéré comme faisant partie de Debian selon ces nouvelles règles. Prétendre avoir une « position neutre » face au fascisme n’est pas de la neutralité, c’est une collaboration active »
Il se retire donc du projet, expliquant que les LLM s’appuient en grande partie sur des entreprises « soutenues par des fascistes ». De toutes les propositions, la E était « la plus pro-LLM de toutes les options ». Il dit ne plus être intéressé par quoi que ce soit provenant de Debian, déclarant avec acidité qu’il peut être remplacé « par n’importe quelle IA agentique ». « Je pense n’avoir jamais autant été déçu par une communauté en qui j’avais confiance », affirme-t-il.
L’importance de Debian
Si ce vote était attendu, c’est que Debian est l’une des distributions Linux les plus importantes. En plus du système lui-même, connu pour sa fiabilité et sa rigueur, Debian sert de base à de nombreuses distributions, dont la plus connue est Ubuntu, celle-ci servant à son tour de socle à d’autres comme Linux Mint.
Comme l’indique It’s FOSS, plusieurs projets ont choisi des approches beaucoup plus radicales. OpenJDK par exemple, édité par Oracle, refuse toute contribution générée par IA. Même chose pour le compilateur GCC. D’autres ont choisi une approche plus souple, en particulier le noyau Linux. Au sujet des LLM, Linus Torvalds a adopté une approche pragmatique, estimant que l’aide procurée par l’IA ne peut plus être empêchée, mais que certaines situations sont problématiques, notamment l’automatisation des rapports des bugs (qu’il a fustigée).
Connexion
