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...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
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.
