L’intelligence artificielle continue de se faufiler dans les recoins les plus inattendus du développement logiciel. Le dernier exemple vient de Lorenzo Stoakes, ingénieur principal chez ARM et mainteneur du sous-système de gestion de la mémoire du noyau Linux, qui a présenté une série de 23 correctifs pour accélérer considérablement la compilation du noyau en s'appuyant sur un grand modèle de langage (LLM).
Comme détaillé dans le Liste de diffusion Linuxle résultat obtenu est saisissant. D'une part, nous avons des builds 36 % plus rapides avec tous les modules activés (allmodconfig), jusqu'à 70 % plus rapides dans les builds incrémentielles et 90 % plus rapides dans les builds « noop » (ceux dans lesquels il n'y a aucune modification à recompiler). Mais le plus intéressant, ce ne sont pas seulement les chiffres, mais aussi la manière dont ils ont été obtenus.
Le monothread est toujours le goulot d'étranglement
Le processus de compilation du noyau Linux rencontre plusieurs problèmes structurels depuis de nombreuses années. Mais l’un d’eux est un énorme goulot d’étranglement : plusieurs phases critiques s’exécutent sur un seul thread de processeur, ralentissant les performances globales même sur les machines dotées de dizaines de cœurs.
Stoakes a identifié que les temps d'arrêt dans ces sections sérialisées constituaient le principal obstacle à la réduction des temps de construction. Il s’agit d’un problème largement connu, mais que personne n’a essayé de résoudre en raison de sa complexité, Stoakes est le premier.
Les correctifs concernent plusieurs composants de l'infrastructure de construction : Kbuild (le système de construction de base), kallsyms (gestion des symboles du noyau), modpost (post-traitement des modules), objtool (validation d'objet), mksysmap (génération de cartes système) et le système de construction Rust. La proposition ne constitue donc pas un changement ponctuel, mais plutôt une réécriture transversale visant à paralléliser les tâches qui bloquaient auparavant le flux.
FreeBSD porte le logiciel ROCm d'AMD pour le HPC et l'IA sur les GPU
L'IA en tant que « détective » et non en tant que programmeur
Cela semble simple à faire, mais c’est un véritable casse-tête. Cependant, Stoakes n’a pas utilisé directement une IA qui résoudrait le problème comme par magie, mais a plutôt utilisé le modèle en deux phases. Tout d’abord, localiser les goulots d’étranglement en analysant le code et en créant des journaux, puis explorer les solutions possibles.
Stoakes lui-même le résume avec une franchise inhabituelle dans son message à la liste du noyau (LKML) :
Un LLM a été utilisé pour d’abord déterminer où se trouvaient les goulots d’étranglement, puis pour trouver comment les améliorer. Cela a généré beaucoup de code, pour la plupart horrible. J'en ai soigneusement audité et réécrit une grande partie, et j'ai fortement modifié les messages de validation, la lettre de motivation et les commentaires.
De plus, le modèle a également orchestré les versions de tests, le débogage et l'analyse, agissant presque comme un agent CI automatisé. Mais la validation finale – à la fois la correction du code et la vérification des noyaux résultants et des améliorations de performances – était entièrement manuelle.
Le label « Aidé par »
Pour démontrer l’utilisation de l’IA, tous les commits incluent une étiquette Assisté par. Ce détail répond à un débat ouvert au sein de la communauté du noyau sur la transparence dans l'utilisation des outils d'IA.
En janvier 2026, Linus Torvalds avait déjà pris part à la discussion sur la documentation politique pour les contributions assistées par l'IA, notant que « les gens qui utilisent AI slop ne documenteront pas leurs correctifs en tant que tels ». Stoakes, pour sa part, plaide depuis des mois pour la nécessité d'une politique d'adhésion claire de la part des responsables, arguant que la charge de la révision leur incombe et qu'ils devraient être en mesure de rejeter les correctifs générés sans véritable supervision humaine.
Sa position s'est reflétée dans le fil de discussion « AI slop » d'août 2026, où il a répondu à Jason Gunthorpe (NVIDIA) défendant l'utilisation responsable de l'IA. « avec laisse courte » et anticiper que la communauté devra évoluer vers un modèle de confiance dans lequel les nouveaux contributeurs gagnent en crédibilité avec de petits changements avant de proposer des correctifs plus importants.
5 distributions Linux ultralégères pour ressusciter votre ancien PC
L'histoire de Lorenzo Stoakes
Et peut-être que cette position est celle qui a le plus de sens, surtout compte tenu du profil de Stoakes lui-même. Lorenzo Stoakes n'est pas un amateur, il est co-responsable du sous-système de gestion de la mémoire (mm) du noyau Linux, responsable des domaines critiques tels que le mappage inverse de la mémoire, les Transparent Huge Pages (THP) et les API de mémoire du noyau. Il travaille dans le développement de systèmes depuis plus de 20 ans : Oracle, WorldQuant, Squarepoint Capital, Imagination Technologies, et depuis juillet 2026 chez ARM travaillant sur KVM et la mémoire centrale.
Il a pris la parole à la Linux Plumbers Conference et au prestigieux LSF/MM (Linux Storage, Filesystem, Memory Management & BPF), et est l'auteur d'un ouvrage de référence de 1 300 pages sur la gestion de la mémoire sous Linux (No Starch Press).
Un palmarès qui montre clairement que ses qualités techniques sont incontestables et donnent du poids à sa démarche. Après tout, Stoakes soutient que « L'IA comme outil d'exploration, jamais comme substitut au jugement technique. »
Quelle est la prochaine étape pour ces correctifs ?
La série est en cours de révision dans la liste du noyau. Il n'y a toujours aucune garantie que tout le monde passera au mainline, mais le précédent méthodologique est déjà là : un mainteneur expérimenté utilise l'IA pour accélérer la découverte des problèmes, rejette son code « horrible », réécrit ce qui est nécessaire, valide tout à la main et le documente de manière transparente.
Dans un écosystème où la confiance se gagne engagement par engagement, le cas de Stoakes offre un modèle sur la manière d'intégrer l'IA sans enfreindre les règles de vérification qui soutiennent le noyau depuis trois décennies.
Après tout, avec ces changements, la compilation Linux est devenue plus rapide, ce que la plupart des distributions apprécieront et que nous pourrions voir se répéter dans d'autres développements (par exemple gcc dont le boostrap peut prendre des heures sur certains matériels). Et c'est quelque chose que les développeurs peuvent applaudir, ou peut-être pas.
Voici Hegotá, la grande mise à jour d'Ethereum pour l'ère post-quantique
Voir l’article original en espagnol
