Redox OS bannit les LLMs, Debian tergiverse : l'open source n'a pas de réponse unifiée à la déferlante du code
Redox OS bannit les LLMs, Debian tergiverse : l'open source n'a pas de réponse unifiée à la déferlante du code automatisé,
le code écrit par une IA doit-il avoir sa place dans les logiciels libres ?
La question n'est plus théorique. Alors que les LLMs inondent les forges logicielles de contributions automatisées, les projets libres sont contraints de définir leur politique, souvent dans l'urgence et la division. Redox OS a tranché avec intransigeance, Debian a préféré esquiver. Deux réponses opposées à une même crise qui interroge l'identité même du logiciel libre.
En mars 2026, le projet Redox OS, système d'exploitation expérimental écrit en Rust, fondé sur une architecture microkernel, a mis à jour son fichier CONTRIBUTING.md avec une formulation sans ambiguïté : le projet n'accepte aucune contribution générée par des LLMs. La politique n'est pas ouverte à discussion. Tout contenu clairement labellisé comme généré par LLM (issues, merge requests, descriptions incluses) sera immédiatement fermé. Toute tentative de contournement entraînera un bannissement du projet.
La brutalité du ton n'est pas fortuite. Elle signale une posture défensive face à ce que les mainteneurs perçoivent comme une menace existentielle à la qualité et à l'intégrité du code. Redox, projet ambitieux qui vise à proposer une alternative aux noyaux monolithiques comme Linux, est écrit en Rust, un langage relativement bien représenté dans les données d'entraînement des grands modèles. Le risque de contamination par du code LLM n'est donc pas hypothétique.
La décision a instantanément enflammé Hacker News. Pour plusieurs commentateurs, l'enjeu réel n'est pas tant l'opinion que l'on a de l'IA, mais le fardeau croissant qui pèse sur les mainteneurs de projets open source. Par le passé, le code lui-même constituait une forme de preuve d'effort : soumettre une pull request exigeait un investissement minimum, ce qui permettait d'écarter d'un coup d'œil les contributions de faible qualité. Ce n'est plus le cas : les LLMs peuvent générer des PRs qui paraissent superficiellement correctes, sans que l'on puisse le détecter sans une revue approfondie.
Redox n'est pas seul à adopter cette ligne dure. Le projet Zig a mis en place une politique similaire d'interdiction stricte des LLMs et de l'IA. Ces deux projets systems, soucieux de la rigueur formelle du code bas niveau, partagent une même conviction : la qualité ne se délègue pas à une machine stochastique.
L'insoluble problème de l'applicabilité
La politique de Redox soulève immédiatement une objection pratique : comment l'appliquer ? La formulation même de la règle, qui vise le contenu « clairement labellisé » comme généré par LLM, revient implicitement à admettre qu'on ne peut pas empêcher les soumissions LLM, on interdit simplement à quiconque de les signaler explicitement comme telles. Le paradoxe est vertigineux : la politique punit la transparence.
Les discussions sur Hacker News ont mis en lumière les limites pratiques de l'approche. Un contributeur résume la situation avec une lucidité grinçante : si quelqu'un soumet du code LLM de qualité, que le mainteneur ne peut distinguer d'une contribution humaine, et que le contributeur est prêt à en expliquer le fonctionnement, la règle n'a aucun effet. À l'inverse, elle pénalise les utilisateurs honnêtes qui déclarent leur usage. Pour certains, le « don't ask, don't tell » constitue la seule position raisonnable : si personne ne peut dire que le code vient d'un LLM et que le contributeur en revendique la paternité, c'est une affaire de conscience personnelle.
D'autres voix, moins cyniques, voient dans cette interdiction un filtre pragmatique plutôt qu'une barrière étanche. Elle agirait comme un premier filtre pour éliminer les PRs les moins sérieuses, en attendant que les modèles économiques de la contribution open source s'adaptent, notamment via l'émergence de politiques de rejet par défaut et de systèmes de validation préalable des contributeurs
La question du droit d'auteur ajoute une couche de complexité. Si les outputs de LLMs sont considérés comme des œuvres dérivées des données d'entraînement, accepter du code LLM pourrait exposer un projet à des violations de licence, y compris de la GPL. Pour certains, il vaut mieux interdire certaines contributions maintenant et assouplir la position plus tard, quand la situation juridique sera clarifiée.
Debian : l'art de ne pas décider
À l'autre bout du spectre, Debian, l'une des distributions Linux les plus influentes, dont la gouvernance repose sur un processus de vote formalisé appelé General Resolution (GR), a traversé en février-mars 2026 un débat houleux qui a accouché d'une souris.
C'est Lucas Nussbaum qui a ouvert les hostilités en proposant une résolution générale encadrant les contributions IA. Sa proposition aurait autorisé les contributions générées en tout ou partie par des LLMs, sous plusieurs conditions : déclaration explicite si une part significative n'a pas fait l'objet de modification manuelle, étiquetage avec un tag lisible par machine comme « [AI-Generated] », compréhension complète de la soumission par le contributeur (qui s'engage sur la qualité technique, la sécurité, la conformité aux licences et l'utilité) et interdiction d'utiliser des outils génératifs sur des informations non publiques ou sensibles, comme les listes de diffusion privées ou les rapports de sécurité sous embargo.
Mais avant même d'atteindre le stade du vote, la proposition a été torpillée par une querelle terminologique. Russ Allbery a demandé davantage de précision dans les descriptions des technologies visées, estimant que le terme « IA » est devenu si vague et mal défini qu'il pourrait englober chaque objet physique de l'univers. Si un projet doit établir une politique, il faut définir précisément l'objet de cette politique. LLM a une signification plus ou moins définie ; « IA » signifie simplement ce que l'auteur d'un message veut qu'il signifie.
Le débat s'est ensuite élargi à des questions fondamentales sur la nature de l'open source. Simon Richter a soulevé le problème de l'intégration des nouveaux contributeurs : un agent IA peut effectuer des tâches basiques sous supervision, mais il n'apprend rien de l'échange. Les ressources du projet consacrées à guider cet outil ne génèrent aucun transfert de connaissance durable. Accepter des contributions LLM drive-by (contributions ponctuelles sans investissement dans le projet sur la durée ; l'agent dépose son code et repart, sans suivi, sans discussion, sans engagement) est néfaste parce que c'est une occasion manquée d'intégrer un nouveau contributeur : dans le meilleur des cas, un problème trivial est résolu sans qu'un nouveau contributeur soit formé ; dans le pire, le nouveau contributeur ne fait que servir d'intermédiaire entre un LLM et le mainteneur.
Ted Ts'o, une figure historique du noyau Linux, a contre-attaqué en retournant l'argument : rejeter des contributeurs susceptibles d'utiliser l'IA comme indignes de contribuer à Debian serait encore plus contre-productif.
Face à la cacophonie, Nussbaum a finalement conclu que tant que les discussions restaient calmes et productives, le projet pouvait continuer à explorer le sujet au fil des échanges sur les listes de diffusion, sans formaliser de GR. Si une résolution générale devait quand même être soumise au vote, l'option gagnante serait probablement très nuancée, autorisant l'IA tout en l'assortissant d'un ensemble de garde-fous.
La question de fond : à quoi sert une PR humaine ?
Derrière le débat technique se profile une interrogation philosophique plus profonde sur la valeur du travail de programmation.
Russ Allbery a pris une position contre-intuitive sur la qualité du code généré par LLM : il est courant d'objecter à ce code pour des raisons de qualité, mais cet argument ne tient pas. Les humains sont capables de produire du meilleur code que les LLMs, mais ils sont aussi capables d'en produire de pire. Écrire du code sans valeur ne requiert aucune créativité ; écrire du très mauvais code demande une ingéniosité toute humaine.
Sur Hacker News, un commentateur a formulé ce que beaucoup pensent tout bas : nous nous dirigeons vers une situation où les mainteneurs utilisent eux-mêmes des LLMs parce qu'ils sont réellement utiles dans de nombreux cas, tout en les interdisant aux contributeurs, faute de pouvoir évaluer la qualité du pilotage que le contributeur en a fait. L'asymétrie est troublante.
D'autres ont proposé une reformulation radicale du modèle contributif : si les agents écrivent la majeure partie du code de toute façon, pourquoi ne pas accepter des « dons de puissance de calcul » plutôt que du code ? Les mainteneurs, qui connaissent la base de code, pourraient formuler leurs propres prompts et piloter leurs propres agents avec une bien meilleure maîtrise du contexte qu'un contributeur extérieur. Cette vision marque un tournant conceptuel : la contribution ne serait plus un acte de codage, mais un acte de spécification.
La question de la reproductibilité, chère à la culture GNU/Linux, est aussi mise à mal. Si un contributeur produit du code LLM, la « forme préférée pour la modification » au sens de la GPL serait le prompt et les autres matériaux fournis au modèle, non le code source généré. Mais cette réponse est insatisfaisante : les outputs des LLMs ne sont pas déterministes, et les fournisseurs retirent régulièrement leurs modèles. Un utilisateur peut avoir conservé son prompt, mais le même outil pourrait générer un résultat très différent ultérieurement.
Vers une balkanisation de l'open source ?
La divergence entre Redox et Debian illustre une fracture qui pourrait, à terme, segmenter profondément l'écosystème du logiciel libre. D'un côté, des projets qui adoptent des politiques strictes au nom de l'intégrité du code, du droit d'auteur et de la philosophie contributive. De l'autre, des distributions et frameworks pragmatiques qui cherchent à encadrer sans interdire, reconnaissant l'impossibilité pratique d'un contrôle total.
Pour certains mainteneurs, la trajectoire semble inéluctable : on se dirigerait vers des modèles de confiance, où les contributions extérieures ne sont acceptées qu'après approbation préalable du contributeur. Ce serait la fin de la pull request anonyme, ou du moins de sa présomption de bonne foi. Il est par ailleurs probable que de nombreux projets sur lesquels Redox s'appuie en amont contiennent déjà du code LLM, à leur insu. L'étanchéité absolue est une illusion dans un écosystème aussi interconnecté que celui du logiciel libre.
Ce qui est certain, c'est que la crise de gouvernance générée par les LLMs est en train de forcer l'open source à se poser des questions qu'il n'avait jamais eu à poser : qui est l'auteur d'un code ? Quelle est la valeur de l'effort humain ? Et à qui appartient, in fine, un logiciel libre ?
Sources : LWN, GitLab
Et vous ?
Une politique « no-LLM » est-elle, par construction, une politique de la transparence perverse, en pénalisant ceux qui déclarent leur usage tout en étant inopérante contre ceux qui dissimulent ?
Répondre avec citation
Envoyé par Stéphane le calme
). Je pense qu'on peut lui trouver des avantages, du genre augmenter les chances de déceler des lacunes dans la réflexion menée, amenant une revue plus rigoureuse. Mais le surcoût systématique poussera naturellement les gens à établir des critères ne dépendant que du résultat pour gagner du temps.
Partager