Vue normale

Reçu — 31 août 2026 Actualités numériques

Debian ne dit pas non à l’IA et divise la communauté

31 août 2026 à 15:43
Démocratie
Debian ne dit pas non à l’IA et divise la communauté

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

Debian ne dit pas non à l’IA et divise la communauté

31 août 2026 à 15:43
Démocratie
Debian ne dit pas non à l’IA et divise la communauté

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

GrapheneOS fustige la sécurité des Pixel 11

31 août 2026 à 10:05
Deux pas en avant, un gros pas en arrière
GrapheneOS fustige la sécurité des Pixel 11

Le système d’exploitation mobile GrapheneOS, connu pour ses positions franches sur la sécurité, fera très probablement l’impasse sur les Pixel 11. La faute, selon les développeurs, à un choix inopportun de Google : l’absence de prise en charge de la Memory Tagging Extension, une fonction de sécurité utilisée abondamment dans le système.

Le 29 août, la fondation GrapheneOS a annoncé sur X, Bluesky et Mastodon qu’elle avait en sa possession un portage partiel de son système sur les Pixel 11 de Google, les derniers smartphones de l’entreprise. La fondation explique que ce portage a été réalisé en une semaine, mais le travail s’était arrêté. Les développeurs ont indiqué être bloqués, faute de support de la Memory Tagging Extension, ou MTE.

Celle-ci est une fonction de marquage de la mémoire proposée par le jeu d’instructions ARM. Elle associe une étiquette aléatoire à chaque zone de mémoire allouée. Si un accès mémoire présente une étiquette qui ne correspond pas, le système détecte une violation. Dans ce cas, selon les choix faits dans le système, le processus est immédiatement interrompu. Cette fonction est utilisée pour bloquer les éventuelles attaques dirigées contre la mémoire, dans l’idée de renforcer l’intégrité du système.

Le cas des Pixel 11

Dans le cas de GrapheneOS, le système s’appuie lourdement sur la MTE. Une position très différente de Google. La firme a intégré la fonction dès la puce Tensor G3 du Pixel en octobre 2023, mais elle s’en sert peu. Sur les Pixel, la MTE n’est en effet utilisée que dans les fonctions de « protection avancée », optionnelles. Il s’agit pour rappel du fameux mode conseillé à certains profils spécifiques (activistes, personnalités politiques, journalistes, etc.) qui élève le niveau général de sécurité en réduisant la surface d’attaque, au prix de certaines fonctions. Ce mode est apparu dans Android 16 en réponse à Apple, qui avait dégainé la première dans ce domaine.

Dans GrapheneOS, l’emploi de la MTE est systémique, aussi bien dans le noyau que dans les processus. Apple possède ici aussi un équivalent, baptisé Memory Integrity Enforcement (MIE), mais l’ajout est plus récent (iPhone 17 et Mac équipés d’une puce M5 au moins). La fondation indique à ce sujet que le MIE d’Apple est une « implémentation de haute qualité de MTE », même si elle n’est pas utilisée par défaut par les applications installées par l’utilisateur, à moins qu’elles aient opté spécifiquement pour cette protection.

Le choix de Google interroge, d’autant que l’entreprise ne s’est pas exprimée publiquement sur le sujet. Les Pixel 11 ont pourtant plusieurs arguments sur la sécurité, dont la puce Titan M3 pour améliorer la protection contre l’extraction de données à l’état verrouillé avant premier déverrouillage. On y trouve aussi une vérification post-quantique du démarrage (basée sur ML-DSA) ou encore un remplacement du sous-système IMS Samsung Shannon par une implémentation AOSP (Android Open Source Project).


Il reste 55% 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.

❌