Contributeur chevronné au noyau Linux depuis 2014, ingénieur chez Arm et auteur de l’ouvrage de référence The Linux Memory Manager, Lorenzo Stoakes vient de pousser un coup de gueule retentissant au sein de la communauté libre. Mardi 10 novembre 2026, le développeur a soumis une série de quatre patchs sur la liste de diffusion officielle (LKML) pour acter son retrait immédiat de plusieurs fonctions névralgiques de relecture de code, directement asphyxié par la déferlante de contributions générées par intelligence artificielle.
💡 En résumé : l’exaspération au cœur du noyau Linux
- Retrait ciblé : Lorenzo Stoakes abandonne ses rôles de relecteur sur le cœur de la gestion mémoire (MM), la récupération mémoire (reclaim), les composants Rust associés et les sections diverses.
- Saturation par l’IA : le développeur estime que l’AI slop (code généré automatiquement sans rigueur) représente désormais la moitié ou plus des séries de correctifs qu’il doit inspecter.
- Maintien de ses responsabilités centrales : l’ingénieur d’Arm conserve ses fonctions de mainteneur principal (notamment autour de KVM) et confie le suivi des Transparent Huge Pages (THP) à Zi Yan.
Un goulet d’étranglement humain face aux machines
Dans son message adressé aux figures tutélaires du projet — dont Andrew Morton, David Hildenbrand et les responsables de Rust for Linux —, Lorenzo Stoakes ne mâche pas ses mots : « Vu le débit actuel de séries de patchs générées par l’IA qui arrivent dans le noyau, je n’ai malheureusement plus la bande passante nécessaire pour assurer des relectures de manière générale, hormis dans les domaines dont je suis mainteneur. » En clair, le tri manuel des propositions soumises par des tiers lui prend tellement de temps qu’il menace son propre travail d’ingénierie.
Le développement du noyau Linux repose sur une pyramide de confiance stricte : n’importe qui peut proposer une modification, mais une poignée d’experts humains doit en vérifier chaque ligne avant intégration. Ce modèle artisanal se heurte de plein fouet à la démocratisation des assistants de programmation. Alors qu’il ne croisait ces soumissions douteuses que de manière sporadique quelques mois plus tôt, le développeur décrit une escalade hebdomadaire, puis quotidienne, jusqu’à submerger sa file d’attente.
« Vu le débit actuel de séries de patchs générées par l’IA qui arrivent dans le noyau, je n’ai malheureusement plus la bande passante nécessaire pour assurer des relectures de manière générale, hormis dans les domaines dont je suis mainteneur. »
Le dilemme de Linus Torvalds et l’absence de marquage obligatoire
Cette décision a immédiatement suscité une vague de soutien parmi les vétérans du sous-système mémoire, dont Mike Rapoport et David Hildenbrand, plusieurs confirmant que la charge de travail actuelle n’est plus tenable. Lorenzo Stoakes avait déjà tiré la sonnette d’alarme en juillet dernier, résumant le péril qui guette les grands projets libres : « Ce qui tue le projet, ce sont 1 000 contributions bâclées dont 2 ou 3 personnes doivent s’occuper. »
La crise met en lumière une faille dans la gouvernance actuelle du projet. Tandis que Linus Torvalds affiche une posture globalement ouverte envers l’usage d’outils d’IA pour assister les développeurs, les règles de soumission du noyau n’imposent aucun marquage explicite signalant qu’un correctif a été généré ou assisté par un modèle de langage. Les relecteurs bénévoles ou salariés se retrouvent ainsi contraints d’auditer à l’aveugle des séries de code en apparence propres, mais truffées d’hallucinations subtiles ou de régressions critiques — un coût caché qui pousse aujourd’hui les meilleurs spécialistes à fermer la porte.
🌐 L’actualité de l’open source et des technologies éthiques dans votre flux
🐘 Fediverse / Mastodon : suivez notre profil officiel @ depuis votre application ou votre instance favorite.
🦋 Bluesky (AT Protocol) : retrouvez nos actualités condensées et abonnez-vous à @goodtech.info.
