Le noyau Linux rejette les patches IA dans staging, sauf les vrais correctifs de sécurité
Greg Kroah-Hartman annonce que le sous-système staging du noyau Linux rejette désormais tous les patches générés par LLM, avec une seule exception: les correctifs de sécurité réels testés sur le matériel visé. Une ligne rouge qui protège l'école du noyau.
4 août 2026. Greg Kroah-Hartman, mainteneur du sous-système staging et numéro deux du noyau Linux, a annoncé une nouvelle politique: tous les patches générés par LLM pour drivers/staging/ sont désormais automatiquement rejetés. Une seule exception: les correctifs de sécurité réels, à condition que le contributeur ait testé le patch sur le matériel physique et documenté la procédure. La raison est aussi simple que brutale: les LLM produisent un tiers de résultats faux ou dangereux, et staging est une école, pas une poubelle à correctifs automatiques.
Staging, l’école du noyau
Pour comprendre la décision, il faut comprendre ce qu’est staging. Le répertoire drivers/staging/ du noyau Linux contient des pilotes de qualité insuffisante pour le noyau principal — code mal écrit, APIs mal utilisées, normes de style non respectées. Il existe pour une raison précise: former les nouveaux développeurs.
Greg KH l’écrit noir sur blanc dans son annonce: « drivers/staging/ existe PRINCIPALEMENT comme un endroit où les nouveaux développeurs du noyau peuvent apprendre à s’impliquer dans le développement. Il contient des tas de fruits à portée de main — nettoyages de code, changements d’API — parfaits pour apprendre le processus dans un environnement sûr. »
La contrepartie, c’est que le code dans staging est volontairement laissé en mauvais état. Charger un pilote staging déclenche le flag TAINT_CRAP dans le noyau — un avertissement explicite que ce code n’est pas prêt pour la production. Si les mainteneurs voulaient nettoyer staging, ils pourraient le faire demain avec des outils automatisés. Ils ne le font pas parce que staging n’est pas un problème à résoudre — c’est un terrain d’entraînement à préserver.
Cette philosophie s’inscrit dans une tradition de mentorat qui remonte aux débuts du noyau. Linus Torvalds lui-même a été formé par la communauté Minix dans les années 1990. Le noyau Linux n’existerait pas sans ce modèle de transmission — un nouveau développeur soumet un patch maladroit, un mainteneur le corrige en expliquant pourquoi, le développeur apprend, et le cycle continue. Les patches LLM court-circuitent ce cycle: ils produisent un résultat syntaxiquement correct sans que personne n’apprenne rien.
L’assaut des LLM
Le problème, c’est que les modèles de langage excellent à repérer les fruits à portée de main. Un LLM peut générer en quelques secondes un patch qui corrige les violations de style ou remplace une API dépréciée dans un pilote staging. Des dizaines, des centaines de contributeurs — souvent des étudiants ou des développeurs juniors cherchant leur première contribution au noyau — ont commencé à soumettre ces patches.
« L’assaut récent de patches noyau générés par LLM pour drivers/staging/ » est la formulation exacte de Greg KH. Le volume est tel qu’il noie les contributions humaines légitimes et détruit la raison d’être du sous-système.
Et Greg KH prévient: « Il est TRÈS évident quand des patches sont générés par LLM — ne croyez pas que ne pas divulguer leur utilisation vous permettra de vous en sortir. Le but est d’apprendre, pas d’essayer de tromper un mainteneur. Si quelqu’un est déterminé à nous avoir délibérément trompés, considérez ceci comme votre avertissement. »
La menace n’est pas voilée. Les mainteneurs du noyau ont l’habitude de bannir les contributeurs de mauvaise foi — et ils savent reconnaître un patch LLM.
L’exception: les vrais correctifs de sécurité
La politique n’est pas un rejet total. Greg KH reconnaît que les LLM sont « très bons pour trouver des problèmes de sécurité suspects dans le code du noyau ». L’outil a de la valeur — mais il n’est pas fiable.
« Même avec les meilleurs outils actuels et de prochaine génération, au moins un tiers des résultats qu’ils génèrent sont complètement faux ou dangereux », écrit-il. Le chiffre est important: ce n’est pas une estimation au doigt mouillé, c’est un retour d’expérience du mainteneur qui lit chaque patch.
Pour soumettre un correctif de sécurité trouvé par LLM dans staging, le contributeur doit:
- Avoir testé le patch sur le matériel réel du pilote
- Décrire la procédure de test dans le message de commit
- Être prêt à défendre sa soumission et prouver qu’elle corrige un bug qu’un utilisateur peut réellement rencontrer
Cette exigence de test sur matériel physique est délibérément élevée. Elle filtre mécaniquement les contributions automatiques — un LLM ne peut pas brancher un périphérique PCI et vérifier que le pilote fonctionne après le patch. Elle garantit aussi que le contributeur a compris ce qu’il faisait. C’est exactement l’objectif de staging.
Le parallèle Schneier
Greg KH conclut son annonce en citant un essai de Bruce Schneier: les LLM sont en train de devenir un « outil raisonnable pour faire du gros œuvre », mais ce gros œuvre ne devrait être réalisé que par « ceux qui ont déjà correctement formé leurs compétences pour savoir quel type de travail peut être fait, et de quelle manière ».
La métaphore est parlante. Un marteau-piqueur est un excellent outil — entre les mains d’un ouvrier qui sait où frapper. Entre les mains de quelqu’un qui n’a jamais tenu un marteau, il défonce le mur porteur. Les LLM et le noyau Linux, c’est la même chose.
Ce que ça change pour le noyau
La décision de Greg KH ne concerne techniquement que drivers/staging/. Les autres sous-systèmes — réseau, mémoire, systèmes de fichiers — ne sont pas couverts par cette politique. Linus Torvalds a d’ailleurs réaffirmé que le noyau « n’est pas anti-IA » et que les LLM sont des outils comme les autres.
Mais le signal est fort. Le mainteneur de staging, qui est aussi le bras droit de Linus, trace une ligne claire: l’automatisation ne remplace pas l’apprentissage. Si d’autres sous-systèmes suivent — et c’est probable, vu la culture de révision par les pairs du noyau — la contribution IA au noyau Linux sera progressivement cantonnée aux tâches où elle apporte une valeur réelle sans contourner le processus humain.
C’est une position nuancée, technique et parfaitement alignée avec la philosophie du noyau: les outils sont les bienvenus, les raccourcis non.
Verdict
La position de Greg KH est juste, et elle devrait faire école au-delà du noyau Linux:
Si vous contribuez à un projet open source avec l’aide d’un LLM, posez-vous trois questions avant de soumettre:
- Ai-je compris ce que le LLM a produit, ou ai-je juste copié-collé?
- Ai-je testé le changement dans des conditions réelles?
- Est-ce que ma contribution apprend quelque chose au projet — ou est-ce que je remplis un quota?
La réponse à la troisième question est celle qui distingue un développeur d’un script.
Pour les mainteneurs de projets open source, le précédent staging est une référence: vous avez le droit de refuser les contributions LLM non vérifiées. Vous avez même le devoir de le faire si elles menacent la qualité ou la fonction pédagogique de votre projet.
Pour les organisations qui font tourner Linux en production, cette politique n’affecte pas les noyaux que vous déployez — les pilotes staging sont déjà marqués TAINT_CRAP. Mais si vos équipes contribuent au noyau, le message est clair: un patch LLM non vérifié et non testé sera rejeté. La barre est haute, et c’est exactement ce qui fait la qualité du noyau depuis 34 ans.