Discussion :

[Stéphane le calme]

L'IA s'immisce dans le noyau Linux : innovation nécessaire ou bombe à retardement pour l’écosystème numérique mondial ?
Certaines voix s'élèvent pour demander une politique officielle d’urgence

L’intelligence artificielle s’immisce dans tous les recoins de l’informatique : assistants virtuels, génération de code, détection de menaces, automatisation de la maintenance logicielle… Désormais, même le noyau Linux, considéré comme l’une des pièces de code les plus critiques au monde, est concerné. Mais cette intrusion soulève des interrogations fondamentales : faut-il encadrer l’usage de l’IA avant qu’elle ne fragilise le socle de notre infrastructure numérique ?

Pour comprendre l’importance du sujet, rappelons que le noyau Linux est le cœur du système d’exploitation Linux, chargé de gérer la mémoire, les processus, les pilotes matériels et la sécurité. Ce noyau équipe non seulement des millions de serveurs, mais aussi Android, les routeurs, les objets connectés, les supercalculateurs et une bonne partie du cloud mondial. Sa stabilité et sa sécurité sont donc cruciales : une faille dans Linux peut affecter la planète entière.

L’arrivée discrète de l’IA via AUTOSEL

Depuis des années, le processus de stabilisation du noyau Linux repose sur des mainteneurs expérimentés qui décident quels correctifs appliquer aux branches dites stables. Pour les aider, un outil baptisé AUTOSEL a été développé. Sa mission : sélectionner automatiquement des correctifs pertinents en se basant sur des modèles statistiques.

Dans un discours prononcé lors du sommet Open Source Summit 2025 en Amérique du Nord, Sasha Levin, hacker du noyau Linux et ingénieur émérite chez Nvidia, a cité l'exemple d'un petit correctif en amont apporté à git-resolve dans le noyau Linux 6.16. Cet outil résout les problèmes liés aux identifiants de commit incomplets ou incorrects, un problème mineur mais gênant pour les principaux responsables de la maintenance. Levin a utilisé l'IA pour écrire l'intégralité de la routine : « La seule chose que j'ai faite, c'est de revoir le code et de le tester pour m'assurer qu'il fonctionnait. »

Cependant, il a averti : « C'est un excellent exemple de ce que font actuellement les LLM. Vous leur confiez une petite tâche bien définie, et ils s'en chargent. Et vous remarquez que ce patch n'est pas du genre "Hé, LLM, va m'écrire un pilote pour mon nouveau matériel". Au contraire, il est très spécifique : "convertis ce hachage particulier pour utiliser notre API standard". »

Levin a déclaré qu'un autre avantage de l'IA est que « pour ceux d'entre nous qui ne sont pas de langue maternelle anglaise, elle aide également à rédiger un bon message de commit. C'est un problème courant dans le monde du noyau, où il est parfois plus difficile de rédiger le message de commit que d'écrire le changement de code, et cela aide vraiment à surmonter les barrières linguistiques. »

Pour l'avenir, Levin a suggéré que les LLM pourraient être formés pour devenir de bons assistants des mainteneurs Linux : « Nous pouvons enseigner à l'IA les modèles spécifiques au noyau. Nous montrons des exemples tirés de notre base de code pour expliquer comment les choses sont faites. Cela signifie également qu'en l'ancrant dans notre base de code du noyau, nous pouvons faire en sorte que l'IA explique chaque décision et nous pouvons la retracer à partir d'exemples historiques. »

En outre, il a déclaré que les LLM peuvent être connectés directement à l'arborescence Git du noyau Linux, de sorte que « l'IA peut aller de l'avant et essayer d'apprendre des choses sur le dépôt Git toute seule ».

L'IA pour les ingénieurs noyau : intervention de Sacha Levin

C'est là qu'intervient la dernière version de l'outil AUTOSEL du noyau Linux

Mais récemment, AUTOSEL a évolué. Il s’appuie désormais sur des techniques d’IA avancées, notamment les embeddings, qui permettent d’analyser le sens du code et des commentaires. L’idée est séduisante : accélérer la sélection de correctifs en laissant l’IA repérer ceux qui semblent les plus utiles et les plus sûrs.

Bonjour à tous,

Je suis heureux d'annoncer la sortie d'AUTOSEL, une refonte complète de l'outil de sélection de correctifs pour noyau stable que Julia Lawall et moi-même avions présenté en 2018. Contrairement à la version précédente qui s'appuyait sur des statistiques lexicales et des techniques de réseaux neuronaux plus anciennes, AUTOSEL exploite des modèles de langages modernes à grande échelle et la technologie d'intégration pour fournir des recommandations nettement plus précises.

Qu'est-ce qu'AUTOSEL ?

AUTOSEL analyse automatiquement les commits du noyau Linux afin de déterminer s'ils doivent être rétroportés vers les arborescences de noyau stables. Il examine les messages de commit, les modifications de code et les modèles de rétroportage historiques afin de formuler des recommandations intelligentes.

Il s'agit d'une réécriture complète de l'outil original[1], avec plusieurs améliorations majeures :

1. Utilisation de grands modèles linguistiques (modèles Claude, OpenAI, NVIDIA) pour la compréhension sémantique.
2. Mise en œuvre d'une récupération de commits similaires basée sur l'intégration pour un meilleur contexte.
3. Fourniture d'explications détaillées pour chaque recommandation.
4. Prise en charge du traitement par lots pour une analyse efficace de plusieurs commits.

Caractéristiques principales

• Prise en charge de plusieurs fournisseurs LLM (Claude, OpenAI, NVIDIA).
• Embeddings autonomes utilisant Candle.
• Accélération CUDA optionnelle pour une analyse plus rapide.
• Explications détaillées des décisions de rétroportage.
• Couverture de test et validation étendues.

Problème : cette nouvelle étape change radicalement la nature du processus. L’IA ne se contente plus de trier, elle influence directement les décisions techniques qui touchent au cœur même du système Linux.

Les avantages mis en avant

La dernière version de l'outil AUTOSEL pour le noyau Linux, basé sur l'IA, analyse donc automatiquement les commits du noyau Linux afin de déterminer s'ils doivent être rétroportés vers des arborescences de noyau stables. L'outil examine les messages de commit, les modifications de code et les modèles historiques de rétroportage afin de formuler des recommandations intelligentes.

James Bottomley, responsable senior de la maintenance du noyau Linux et ingénieur émérite chez IBM Research, a expliqué pourquoi cette approche constitue une bonne utilisation de l'IA dans un message publié sur la liste de diffusion Linux Kernel Mailing List : « Si vous y réfléchissez bien, l'historique git contient le chemin d'accès exact entre l'endroit où le correctif a été appliqué et l'endroit où vous souhaitez l'appliquer. Il s'agit d'un ensemble de données fini avec lequel les LLM peuvent être formés pour fonctionner correctement. »

Il a poursuivi : « Les humains ne regardent pas le chemin du patch (ou utilisent quelque chose de général comme un scan de plage). L'IA peut être suffisamment patiente pour tout passer en revue. »

De plus, AUTOSEL est désormais utilisé pour repérer les modifications de code qui corrigent les failles de sécurité CVE (Common Vulnerabilities and Exposures) de Linux. Étant donné que dans Linux, presque tous les bogues peuvent constituer une faille de sécurité, le suivi de ces commits peut être un travail fastidieux. Pour suivre ces commits, les responsables de la maintenance du noyau utilisaient de nombreux « scripts Bash hacky ». Aujourd'hui, les LLM utilisent la génération augmentée par récupération (RAG) pour récupérer les dépôts Git et la documentation du noyau, apprendre l'historique des correctifs et réduire les hallucinations.

Avant de pointer les dangers, il faut reconnaître les bénéfices potentiels :

• Gain de temps pour les mainteneurs : avec des milliers de correctifs proposés chaque mois, une aide automatisée permet de réduire la charge de travail.
• Capacité d’analyse élargie : l’IA peut repérer des motifs ou des similarités dans le code que l’œil humain manquerait.
• Ouverture à de nouveaux contributeurs : des développeurs moins expérimentés peuvent s’appuyer sur l’IA pour proposer des correctifs valides.
• Réduction des oublis : certains correctifs importants passent parfois entre les mailles du filet humain. Une IA peut aider à éviter cela.

En théorie, tout cela semble bénéfique. Mais en pratique, les inquiétudes s’accumulent.

Les inquiétudes : code fragile, surcharge humaine et opacité

Du code qui « a l’air correct »… mais ne l’est pas forcément

Les modèles d’IA sont experts pour produire du code qui semble logique et bien formaté. Mais ce vernis cache souvent des erreurs subtiles, difficiles à détecter en revue. Dans un environnement aussi sensible que le noyau Linux, une petite erreur peut avoir des conséquences colossales, allant du bogue à la faille de sécurité exploitable.

La surcharge des mainteneurs

Si l’IA permet de générer ou de recommander des correctifs plus rapidement, cela signifie aussi que le volume global augmente. Résultat : les mainteneurs doivent passer plus de temps à examiner des propositions, dont certaines sont de mauvaise qualité (AI slop). Autrement dit, l’IA risque de transformer un problème de rareté (pas assez d’yeux humains) en problème d’abondance toxique (trop de propositions inutiles).

Le manque de compréhension humaine

Un point crucial : dans l’open source, l’auteur d’un correctif doit être capable d’expliquer pourquoi il a écrit ce code. Or, si un développeur se contente de soumettre ce que ChatGPT ou un modèle similaire lui a fourni, il n’a parfois aucune idée de la logique sous-jacente. Cela remet en cause un principe de base de la communauté Linux : la transparence et la responsabilité de chaque contribution.

Sécurité : un nouveau talon d’Achille

Des études récentes montrent que le code généré par IA comporte davantage de vulnérabilités que celui écrit par des humains, en raison d’un raisonnement parfois superficiel. Intégrer de tels correctifs sans garde-fous reviendrait à ouvrir une porte dérobée potentielle dans l’un des systèmes les plus utilisés au monde.

Vers une politique officielle de l’IA dans Linux

Face à ces risques, plusieurs voix dans la communauté appellent à la mise en place d’une politique claire et officielle concernant l’usage de l’IA.
Parmi les pistes évoquées :

• Étiquetage obligatoire : tout correctif assisté ou généré par IA doit être signalé comme tel.
• Revue renforcée : ces correctifs doivent passer par un processus de vérification plus strict, avec davantage de tests automatisés.
• Quota ou filtrage : limiter les soumissions pour éviter la saturation par du « bruit » généré par IA.
• Responsabilisation : l’auteur doit rester capable d’expliquer la logique du correctif, même s’il s’est appuyé sur une machine.

Ces mesures ne visent pas à bannir l’IA, mais à l’encadrer intelligemment, pour protéger l’intégrité du noyau.

Jiří Kosina, développeur Linux en chef chez SUSE, a proposé sur la liste de diffusion LKML que les développeurs du noyau s'accordent sur une méthode permettant d'indiquer quel LLM a généré quel code et qui est responsable de ce correctif.

Les responsables de la maintenance s'accordent à dire que Linux a besoin d'une politique officielle pour traiter ces questions. Steven Rostedt, développeur senior du noyau Linux et ingénieur logiciel chez Google, travaille actuellement sur la première ébauche d'un document officiel relatif à la politique du noyau en matière d'IA. Cette ébauche sera présentée lors de la Linux Plumbers Conference qui se tiendra plus tard cette année.

Outre la capacité ou non d'une IA à écrire du code, cette transition comporte un autre aspect : le statut des droits d'auteur du code produit par l'IA. Comme l'a déclaré Levin dans une proposition, « Le noyau Linux est sous licence GPL-2.0 avec une exception pour les appels système. Les agents de codage DOIVENT respecter cette règle de licence sans exception. Tout code fourni doit être compatible avec cette licence. » C'est beaucoup plus facile à dire qu'à faire, car le statut des droits d'auteur du code dérivé de l'IA reste une question ouverte.

Nous sommes déjà confrontés à ce genre de « dérapage » aujourd'hui, où l'IA a rendu extrêmement facile pour les personnes qui n'y connaissent rien de soumettre des correctifs AI slop aux développeurs. C'est le cas par exemple au sein du projet cURL, Daniel Stenberg l'a expliqué lors d'une Keynote au FrOSCon 2025 du 16 août 2025

Conclusion : innover sans perdre la confiance

Le débat ne se limite pas au noyau Linux. Il s’inscrit dans une discussion plus large sur la place de l’IA dans le développement logiciel. Faut-il considérer l’IA comme un simple assistant, un outil de productivité, ou lui confier de véritables responsabilités ? Comment assurer la traçabilité, la qualité et la sécurité ?

Ces interrogations sont valables pour toutes les communautés open source, mais aussi pour les entreprises qui intègrent du code généré par IA dans leurs produits.

L’arrivée de l’IA dans le noyau Linux illustre bien le dilemme actuel de l’informatique : comment profiter de la puissance des machines sans sacrifier la rigueur humaine ? Il ne fait aucun doute que l’IA va jouer un rôle croissant dans le développement logiciel. Mais dans un projet aussi critique que Linux, la confiance, la transparence et la sécurité doivent primer.

Une politique officielle claire, combinant innovation et prudence, sera la clé pour que le noyau Linux reste ce qu’il a toujours été : un socle fiable et universel, au service du numérique mondial.

Sources : AUTOSEL : Classificateur stable de rétroportage du noyau Linux moderne alimenté par l'IA, une nouvelle version d'AUTOSEL, Sasha Levin, James Bottomley, AI slop attacks on the curl project, vidéos dans le texte

Et vous ?

Pour ou contre l'utilisation d'outils IA dans cet écosystème ? Dans quelle mesure ?

L'essence même du développement open source est la collaboration humaine. Les discussions, les relectures de code et les débats passionnés font avancer le projet. Si l'IA devient un acteur majeur dans la génération de code, ne risquons-nous pas de perdre cet esprit communautaire ?

Comment s'assurer que l'IA reste un outil d'assistance et non un substitut qui isole les développeurs et réduit la richesse des interactions humaines ? Accepteriez-vous de faire tourner vos serveurs de production sur un noyau ayant intégré du code généré ou recommandé par une IA ?

Faut-il instaurer un label obligatoire (« assisté par IA ») pour tout correctif soumis dans Linux et autres projets open source ?

Devrait-on créer une politique universelle pour encadrer l’IA dans le développement open source, ou laisser chaque projet décider de ses règles ?

Voir aussi :

La Fondation Linux lance le projet "Protocole Agent2Agent" afin de permettre une communication sécurisée et intelligente entre les agents d'IA

Fatigue des Mainteneurs dans le Noyau Linux et rôle de l'IA dans le développement open source, une vision partagée par Linus Torvalds au sommet Open Source de la Fondation Linux

[floyer]

Ici, l'IA a vocation à sélectionner le code qui doit être rétroporté... l'IA ne produit aucun code. ET ce sont des recommandations. L'humain reste dans la boucle. (ET c'est à lui de vérifier des effets de bord au cas où le commit proposé dépend d'un autre sans que cela soit documenté).

Cela me semble un bon usage de l'IA.

[Stéphane le calme]

Linus Torvalds refuse de transformer la documentation du kernel en champ de bataille idéologique « anti-IA » :
arrêtez de faire toute une histoire de « l'IA slop » dans la documentation du noyau ; vous ne changerez l’avis de personne

Lorsque Linus Torvalds intervient publiquement, ce n’est jamais anodin. Le créateur du Linux kernel n’a jamais cultivé le consensus mou, et son dernier coup de gueule contre ce qu’il appelle implicitement la croisade anti-« AI slop » dans la documentation du noyau s’inscrit dans une longue tradition de franc-parler brutal mais cohérent. Le message est clair : faire de la croisade idéologique contre les contenus générés par IA un sujet central dans la documentation du kernel est, selon lui, une perte de temps. Pire, cela détourne l’attention de ce qui compte réellement dans un projet logiciel critique : la qualité technique, la vérifiabilité et la responsabilité humaine.

L'IA est arrivée discrètement dans le noyau Linux via l'outil AUTOSEL.

En fait, depuis des années, le processus de stabilisation du noyau Linux repose sur des mainteneurs expérimentés qui décident quels correctifs appliquer aux branches dites stables. Pour les aider, un outil baptisé AUTOSEL a été développé. Sa mission : sélectionner automatiquement des correctifs pertinents en se basant sur des modèles statistiques.

Dans un discours prononcé lors du sommet Open Source Summit 2025 en Amérique du Nord, Sasha Levin, hacker du noyau Linux et ingénieur émérite chez Nvidia, a cité l'exemple d'un petit correctif en amont apporté à git-resolve dans le noyau Linux 6.16. Cet outil résout les problèmes liés aux identifiants de commit incomplets ou incorrects, un problème mineur mais gênant pour les principaux responsables de la maintenance. Levin a utilisé l'IA pour écrire l'intégralité de la routine : « La seule chose que j'ai faite, c'est de revoir le code et de le tester pour m'assurer qu'il fonctionnait. »

Mais récemment, AUTOSEL a évolué. Il s’appuie désormais sur des techniques d’IA avancées, notamment les embeddings, qui permettent d’analyser le sens du code et des commentaires. L’idée est séduisante : accélérer la sélection de correctifs en laissant l’IA repérer ceux qui semblent les plus utiles et les plus sûrs.

L'IA pour les ingénieurs noyau : intervention de Sacha Levin

Le fond du message : la technique avant la morale

Linus Torvalds répondait à un message du développeur de noyau Lorenzo Stokes, affilié à Oracle, qui semble prudemment anti-LLM : « Considérer les LLM comme "un outil parmi d'autres" revient à dire que le noyau est immunisé contre cela. Ce qui me semble être une position ridicule. » Pour mettre les propos de Stokes dans le contexte, il faut savoir qu'il répondait à un e-mail de Dave Hansen. Rappelons qu'une équipe travaille actuellement à l'élaboration d'un ensemble de directives claires et sans ambiguïté concernant les contributions au noyau assistées par des bots LLM.

Il faut reconnaître que c'est une question urgente. Les gens utilisent déjà des assistants de codage LLM pour travailler sur le code du noyau : par exemple, l'année dernière, Dmitry Brant, développeur chez Wikimedia, a publié un article sur son blog intitulé « Utiliser Claude Code pour moderniser un pilote de noyau vieux de 25 ans ».

Torvalds a répondu en ces termes à Stokes :

« Non. C'est votre position qui est ridicule.

« Il est inutile de parler d'AI slop. C'est tout simplement stupide.

« Pourquoi ? Parce que les adeptes de l'AI slop ne vont pas documenter leurs correctifs en tant que tels. C'est une évidence tellement flagrante que je ne comprends pas pourquoi quelqu'un évoque l'AI slop.

« Alors arrêtez cette idiotie.

« La documentation est destinée aux acteurs honnêtes, et prétendre le contraire n'est qu'une posture inutile.

« Comme je l'ai dit en privé ailleurs, je ne veux pas que la documentation sur le développement du noyau soit une déclaration d'IA. Nous avons suffisamment de personnes des deux côtés, entre ceux qui pensent que « le ciel va nous tomber sur la tête » et ceux qui pensent que « cela va révolutionner l'ingénierie logicielle ». Je ne veux pas que la documentation sur le développement du noyau prenne parti pour l'un ou l'autre camp.

« C'est pourquoi je tiens absolument à ce que ce soit une déclaration « juste un outil ».

« Et le problème de l'IA ne sera PAS résolu par la documentation, et quiconque pense le contraire est soit naïf, soit veut « faire une déclaration ».

« Aucune de ces deux raisons n'est valable pour la documentation. »

Il semble que ce que Torvalds remet en cause, ce n’est pas l’existence de contenus médiocres (AI slop) produits par des modèles de langage. Il ne nie pas non plus que l’IA puisse générer du texte approximatif, imprécis ou tout simplement faux. Son point de friction est ailleurs. Pour lui, transformer la documentation du noyau Linux en tribune morale contre l’IA relève d’un contresens. La documentation n’est pas un manifeste politique, encore moins un espace de pédagogie militante. Elle est un outil de travail destiné à des développeurs qui savent déjà faire la part des choses.

Dans la vision de Torvalds, un document technique doit être jugé sur ce qu’il contient, pas sur la manière dont il a été produit. Si un texte est exact, maintenable et compréhensible, son origine importe peu. À l’inverse, un texte erroné reste erroné, qu’il ait été écrit par un humain fatigué à trois heures du matin ou par un LLM particulièrement confiant.

« Vous ne changerez l’avis de personne » : une critique de l’activisme symbolique

Torvalds a fait plusieurs commentaires sur le codage assisté par LLM-bot à plusieurs reprises ces dernières années. En 2024, il a déclaré : « L’intelligence artificielle c’est 90 % de marketing et 10 % de réalité » après avoir dit « Je ne veux pas participer au battage médiatique. Attendons 10 ans et voyons ce qu’il en est avant de faire toutes ces déclarations. »

Un an plus tard, il a déclaré qu'il était d'accord avec le vibe coding tant qu'il n'était pas utilisé pour quelque chose d'important, ce qui était un peu inattendu. Tout en reconnaissant la complexité du noyau Linux (environ 40 millions de lignes de code), Linus Torvalds considère que les outils d'intelligence artificielle peuvent contribuer à réduire les obstacles à l'entrée pour les nouveaux contributeurs en simplifiant l'apprentissage et la compréhension des processus du noyau. Il conseille néanmoins aux nouveaux programmeurs de commencer par des projets plus modestes avant de s'attaquer au développement du noyau.

Linus Torvalds voit l'intelligence artificielle comme un outil de vérification ou d'organisation, mais pas comme un outil pour le processus créatif (la programmation). Par analogie pour le créateur de Linux, l'IA est à la programmation ce que l'Autotune est à la musique. Si on met l’Autotune à contribution pour permettre à des personnes sans talent de chanter, l’on n’obtient qu'une musique de mauvaise qualité. Le vrai talent n'a pas besoin d'Autotune pour le processus créatif. Seuls les producteurs paresseux en ont besoin.

Cette fois-ci, s'il fallait résumer l’essentiel de sa position, nous pourrions dire ceci : faire de l’IA un problème moral dans les documents du kernel ne changera l’avis de personne. Pour un public de développeurs systèmes, déjà exposés aux limites réelles des outils d’IA, ces avertissements relèvent de l’évidence. Pour les autres, ils sont tout simplement ignorés.

Cette critique vise une forme d’activisme symbolique de plus en plus fréquente dans les projets open source. À défaut de pouvoir contrôler réellement les usages, certains tentent de les encadrer par des messages d’avertissement, des clauses morales ou des rappels éthiques omniprésents. Torvalds balaie cette approche d’un revers de main : elle donne bonne conscience, mais n’améliore ni le code ni la documentation.

Une vision pragmatique de l’IA dans le développement logiciel

Ce positionnement s’inscrit dans une vision très pragmatique du rôle de l’IA dans le développement. Pour Torvalds, les outils d’assistance, qu’ils soient basés sur l’IA ou non, sont des amplificateurs. Ils amplifient les compétences comme les erreurs. Le véritable problème n’est donc pas l’outil, mais la dilution de la responsabilité individuelle.

Dans un projet comme le noyau Linux, chaque ligne acceptée engage la responsabilité d’un mainteneur humain. C’est cette chaîne de responsabilité qui garantit la qualité du projet, pas l’interdiction ou la stigmatisation d’un outil. Introduire l’IA comme bouc émissaire revient, selon cette logique, à masquer les vrais enjeux : revues de code rigoureuses, tests, traçabilité des changements et exigence technique constante.

La documentation du kernel, un espace sous tension

La polémique révèle aussi une tension plus large autour de la documentation technique. Longtemps négligée, parfois mal aimée, la documentation est aujourd’hui au cœur des débats parce qu’elle est devenue un point d’entrée privilégié pour les outils d’IA générative. Certains craignent qu’elle ne devienne un gisement de textes recyclés, approximatifs ou redondants.

Torvalds rappelle implicitement que la documentation du kernel n’a jamais été parfaite. Elle a toujours été hétérogène, parfois austère, souvent écrite par des développeurs pour des développeurs. Chercher à la « purifier » au nom d’un combat contre l’IA revient à projeter sur le kernel des débats qui dépassent largement son périmètre.

Open source et IA : un conflit de valeurs mal posé

Derrière cette prise de position se cache un malaise plus profond dans l’écosystème open source. L’IA générative remet en question des notions centrales comme l’attribution, la contribution et la reconnaissance du travail humain. Certains projets réagissent par le rejet, d’autres par la régulation morale. Torvalds, fidèle à lui-même, choisit une troisième voie : l’indifférence fonctionnelle.

Pour lui, l’open source ne se définit pas par l’intention morale des contributeurs, mais par des processus concrets : licences, revues, gouvernance et qualité du résultat final. Tant que ces piliers tiennent, le reste relève du bruit de fond.

Une position inconfortable mais cohérente

La sortie de Torvalds peut choquer dans un contexte où la critique de l’IA est devenue presque réflexe. Pourtant, elle est parfaitement cohérente avec sa trajectoire. Depuis trente ans, il défend une vision du logiciel où les débats idéologiques n’ont de valeur que s’ils se traduisent par des améliorations tangibles.

En refusant de transformer la documentation du kernel en champ de bataille contre « l'AI slop », Torvalds rappelle une règle simple mais souvent oubliée : dans les systèmes critiques, la morale ne remplace ni l’ingénierie ni la responsabilité. Le reste, qu’on le veuille ou non, n’est que du texte.

Source : Lorenzo Stokes,

Et vous ?

Que pensez-vous des propos et de la position de Linus Torvalds ?

La documentation technique doit-elle rester strictement utilitaire ou peut-elle, à un moment donné, intégrer des positions de principe sur les outils utilisés pour la produire ?

L’IA générative pose-t-elle un problème réellement nouveau pour la qualité de la documentation, ou ne fait-elle qu’exposer des faiblesses déjà anciennes dans les processus de relecture et de maintenance ?

En insistant sur la responsabilité humaine, Torvalds ne minimise-t-il pas le risque d’une normalisation progressive de contenus médiocres, plus difficiles à détecter lorsqu’ils sont bien rédigés mais techniquement faux ?

L’activisme symbolique observé dans certains projets open source est-il une dérive idéologique ou une tentative maladroite de reprendre le contrôle face à des outils devenus omniprésents ?

Enfin, le cas du noyau Linux est-il un modèle exportable, ou une exception liée à sa gouvernance très centralisée et à son niveau d’exigence hors norme ?