Linus Torvalds Says The Linux Kernel Is Not Anti-AI
Linus Torvalds a fermement réaffirmé que le noyau Linux n’est pas un projet anti-IA, en distinguant clairement l’utilisation d’outils d’analyse (comme Sashiko) de la génération de code non supervisée, tout en reconnaissant les craintes légitimes de la communauté.
SYNTHÈSE STRUCTURÉE
La position officielle de Linus Torvalds sur l’IA
Linus Torvalds a pris une position très claire dans le thread LKML : le noyau Linux n’est pas un projet anti-IA. Il déclare : « Linux is not one of those anti-AI projects, and if somebody has issues with that, they can do the open-source thing and fork it or just walk away. » Cette déclaration, faite en tant que BDFL (Benevolent Dictator for Life), met fin à toute ambiguïté. Torvalds considère l’IA comme un outil parmi d’autres, utile techniquement, et refuse de laisser des considérations idéologiques dicter la politique du projet.
Sashiko : un outil d’analyse de code, pas de génération
Le déclencheur de la discussion est Sashiko, un outil d’analyse de code pour le noyau Linux. Comme décrit sur son GitHub, « Sashiko is an agentic Linux kernel code review system » qui utilise des prompts spécifiques au noyau et un protocole spécial pour examiner les modifications proposées. Il peut ingérer des patches depuis les listes de diffusion ou un dépôt Git local. L’intervenant insiste sur le fait qu’il faut distinguer l’analyse de code (review) de la génération de code : « I do think it is important to discuss these two things separately because even people who are very anti-AI code generation aren’t necessarily against AI code review. »
Les recommandations de la Software Freedom Conservancy
Laurent Pinchart a cité les deux premières recommandations du document de la Software Freedom Conservancy sur l’utilisation des systèmes d’IA générative dans les projets FOSS. La première stipule que « the FOSS community should support not just tolerate those who outright reject LLM gen AI systems ». La seconde précise que « every FOSS contributor deserves self-determination regarding LLM gen AI » et que personne ne devrait être contraint d’utiliser ces systèmes. Ces recommandations visent à protéger les contributeurs qui refusent l’IA tout en accueillant ceux qui l’utilisent de manière transparente.
Le problème de l’attribution et de la responsabilité du code
Un point crucial soulevé par Ludpool (Red Hat) concerne la capacité à comprendre et à assumer le code généré par IA. Il demande : « At what point is vibe coding simply not realistic for a human to be able to claim accountability over what about agentically written code? » Si un contributeur ne peut pas expliquer ou modifier le code qu’il soumet, il ne peut pas en revendiquer la propriété. Or, actuellement, une IA ne peut pas assumer la responsabilité légale ou technique d’un patch. C’est un problème fondamental pour la maintenance à long terme.
La distinction entre génération et analyse : un enjeu de qualité
L’intervenant distingue nettement deux usages : la génération de code (où l’IA produit du code sans supervision humaine) et l’analyse de code (où l’IA aide à la relecture). Il note que « many of us have actually tried vibe coding and the result that we found is that we get dramatically more benefit a lot of the time from writing the code ourselves and relying on the LLM for analysis instead ». L’analyse assistée par IA est perçue comme moins problématique car elle laisse le contrôle au développeur humain, contrairement à la génération autonome qui pose des questions de qualité et de responsabilité.
La pression des entreprises et le risque de « slop »
Ludpool souligne que de nombreuses entreprises poussent leurs employés à utiliser l’IA, parfois sous la menace de licenciement, avec des attentes irréalistes de productivité 10x ou 100x. Il dénonce : « It is being used in a lot of workplaces as an excuse to throw any notion of actual review or code quality out the window. » Cette pression crée un environnement où la qualité du code se dégrade, produisant ce qu’on appelle du « slop » – du code généré sans véritable supervision humaine. L’intervenant ajoute que « the PR from a lot of companies that are pushing the AI future is frankly repulsive », ce qui alimente la méfiance envers ces outils.
Le problème des bugs réels et de la maintenance
Torvalds reconnaît que l’IA peut être « a somewhat painful tool both for maintainer workloads and just from a it keeps finding embarrassing bug standpoint », mais il insiste sur le fait que si l’IA trouve de vrais bugs, c’est bénéfique pour le projet. Il avertit : « If you’re not finding those bugs and these tools do exist, other people are going to find those bugs. » La solution n’est pas d’ignorer le problème, mais de faire en sorte que les outils d’IA aident les mainteneurs plutôt que de leur causer des difficultés supplémentaires.
Le risque juridique : copyright et licences
Un point rarement abordé mais crucial est l’impact de l’IA sur les licences de code. L’intervenant soulève la question : « If AI code generation means that code is now in the public domain, copyleft does not exist and what that means for code licenses. » Si le code généré par IA tombe dans le domaine public, les licences copyleft (comme la GPL) perdent leur sens. C’est une question juridique encore ouverte, mais qui pourrait avoir des conséquences majeures pour l’écosystème open source. L’intervenant recommande de « keep detailed and accurate records of their interaction and save those meta artifacts for posterity » pour se prémunir contre d’éventuels litiges.
La génération « boomer » et l’inévitabilité de l’IA
L’intervenant conclut sur une note philosophique : « We are likely the very last generation of people that even care about the discussion of whether or not AI is being used. » Il compare la situation à celle des « boomers » qui ont vu arriver Internet : les générations futures grandiront avec l’IA comme un outil naturel, et le débat actuel leur semblera étranger. Il admet avoir « lost all my cope » face à l’inévitabilité de l’IA, mais insiste sur l’importance de discuter des implications éthiques et pratiques tant qu’il est encore temps.
CONCEPTS CLÉS
- Sashiko : Outil d’analyse de code agentique pour le noyau Linux, utilisant des LLM pour la relecture de patches, sans génération de code.
- Vibe coding : Pratique consistant à laisser une IA générer du code de manière autonome, sans supervision humaine approfondie.
- Slop : Terme péjoratif désignant du code généré par IA de faible qualité, produit sans réelle validation humaine.
- Copyleft : Mécanisme de licence (ex. GPL) qui impose que les œuvres dérivées restent sous la même licence. Menacé si le code généré par IA tombe dans le domaine public.
- BDFL (Benevolent Dictator for Life) : Titre informel de Linus Torvalds, qui conserve l’autorité finale sur les décisions du noyau Linux.
CONCLUSION
Le message principal est que le noyau Linux, sous la direction de Linus Torvalds, adopte une position pragmatique et non idéologique vis-à-vis de l’IA : l’outil est jugé sur ses résultats techniques, pas sur des considérations morales. Cependant, cette position ne signifie pas un laisser-faire : la distinction entre analyse assistée (acceptable) et génération non supervisée (problématique) est cruciale. Pour les administrateurs système et contributeurs, la leçon est claire : il faut apprendre à utiliser ces outils de manière responsable, en gardant le contrôle humain, tout en étant conscients des risques juridiques (licences) et de la pression des entreprises. Comme le résume l’intervenant, « the solution is to make sure those LLM tools help maintainers instead of just causing them pain ».