Linux 7.4-rc1 signe la plus grosse fenêtre de fusion de l’histoire du noyau, portée par l’IA

1er novembre 2026. Linus Torvalds publie Linux 7.4-rc1 et qualifie la fenêtre de fusion qui s’achève de « BIG merge window ». 1er novembre 2026. Elle frôle les 20 000 commits, contre 15 000 en moyenne. Phoronix la classe déjà comme la plus grosse de l’histoire du noyau, et l’arbre source approche les 42 millions de lignes. Pourquoi c’est important : l’explication avancée par Torvalds n’est pas le matériel, mais l’IA.

Une fenêtre de fusion record, gonflée par l’IA

Le chiffre est sans ambiguïté. Dans son traditionnel state of the kernel, Linus Torvalds annonce une fenêtre de fusion de « presque 20 000 commits », là où les cycles récents tournent autour de 15 000. Un tiers de la masse vient d’un seul sous-système : les register offsets et bit masks du pilote graphique AMDGPU, ces définitions de registres que l’on régénère en masse quand une génération de GPU arrive.

Mais ce n’est pas le matériel qui explique l’écart. Torvalds écrit noir sur blanc : « I think the reason is the by now obvious one » — la raison, c’est l’IA. « I’m *much* happier with the flood of AI triggered work going into the merge window than it showing up mainly as extra fixes during the -rc period. » Autrement dit : il préfère voir les correctifs générés par l’IA arriver tôt, dans la fenêtre de fusion, plutôt que de subir un déversement de rustines pendant la phase de stabilisation.

Cette préférence n’est pas anodine. La phase -rc qui suit la fenêtre de fusion est censée stabiliser le noyau, pas absorber du nouveau code. Quand les correctifs IA arrivent en -rc, ils compliquent le tri entre régression et amélioration. Quand ils arrivent avant, ils bénéficient du temps de maturation complet du cycle.

# Vérifier le cycle en cours depuis une distribution grand public
uname -r                # noyau en cours d'exécution
cat /proc/version       # version et compilateur du noyau actif

« Un modèle plus sain » : l’IA entre dans le développement normal

Torvalds formule explicitement le basculement. Il espère que le nombre inhabituel de commits « is a sign that the AI fixes are becoming more part of the ‘normal development’ than a flood of fixes that go into the whole stabilization phase ». Sa conclusion tient en une formule : « I think that’s a much healthier model. »

C’est un changement de ton par rapport aux cycles précédents. Pendant des mois, le débat au sein du noyau portait sur la qualité des correctifs générés par les grands modèles de langage : des hallucinations dans les noms de fonctions, des rustines syntaxiquement valides mais sémantiquement fausses, des CVE inventées. Le verdict de Torvalds ne nie pas ces problèmes — il les relocalise.

Il nuance d’ailleurs aussitôt son enthousiasme. Le cycle est « Large, and full of fixes for issues found by AI (and more and more the patches have been suggested by AI too, although they often get rewritten) ». La parenthèse compte : les correctifs « often get rewritten ». L’IA trouve et suggère ; l’humain réécrit avant d’intégrer. C’est la frontière exacte entre l’outil et le mainteneur.

Le mainteneur ajoute une seconde explication, indépendante de l’IA : beaucoup anticipent que 7.4 sera le prochain noyau LTS, « which is another independent reason why some releases tend larger than others ». Un cycle pressenti comme LTS attire mécaniquement plus de contributions, car il vivra plus longtemps dans les parcs de production.

Ce que 7.4 embarque concrètement

Au-delà du débat sur l’IA, le contenu de Linux 7.4 est dense. Phoronix en a dressé l’inventaire avant même la sortie du rc1.

Côté AMD, le pilote AMDGPU active HDMI 2.1 par défaut, avec VRR et ALLM ; AMD PerfOpt améliore les performances IA/LLM des iGPU ; les préparatifs Zen 6 continuent, avec l’isolation BTB CTX. Le NPU du Ryzen AI Max 400 est enfin reconnu.

Côté Apple et Google, on note les premiers device trees pour l’Apple M4 et l’A18 Pro, et la prise en charge du Tensor G5 des Pixel 10. Qualcomm apporte le support de plusieurs portables Snapdragon X2.

Côté fichiers et virtualisation : EXT4 gagne un chemin d’E/S buffered via iomap, FUSE gère les large folios, Intel introduit un garde-fou contre les dénis de service dans les VM TDX, et Microsoft contribue un pilote IOMMU paravirtualisé pour Hyper-V. Le pilote Google C Binder disparaît au profit de sa réécriture en Rust.

Un épisode illustre à lui seul l’ambivalence de l’IA. Une nouvelle taint du noyau, destinée à réduire le bruit des correctifs IA, a été revert quelques jours plus tard pour cause de « crazy beast ». Le correctif de l’IA sur l’IA n’a pas tenu : la boucle est bouclée.

D’où viennent ces correctifs « trouvés par l’IA »

« Correctifs IA » recouvre plusieurs flux distincts, rarement distingués dans le débat public. Le plus ancien est l’analyse statique automatisée : Coccinelle, Sparse ou Smatch signalent depuis des années des motifs suspects dans le code du noyau. Ce qui change, c’est qu’un LLM transforme désormais un rapport d’analyse en première version de rustine, que le mainteneur retravaille avant intégration.

Le fuzzing joue le rôle central. Syzkaller et ses pairs génèrent des milliers de plantages ; chaque crash peut devenir un correctif candidat. L’IA intervient en aval, pour proposer le squelette du correctif à partir de la trace, et en amont, pour suggérer des tests de régression sur le sous-système touché.

La nuance de Torvalds — « they often get rewritten » — se joue précisément ici. L’IA produit un point de départ plausible, rarement le correctif final. Le travail humain ne disparaît pas : il se déplace, de la recherche du bug vers la vérification et la réécriture de la proposition.

Ce pipeline explique aussi le volume. Quand un seul sous-système — les registres AMDGPU — peut générer un tiers des commits d’une fenêtre de fusion, c’est que la génération mécanique de définitions est devenue routinière, et que l’IA s’y insère sans friction.

L’ombre du LTS et le calendrier

Si 7.4 devient bien LTS, les entreprises l’exploiteront pendant des années. Le cycle de test prend alors une importance particulière : un noyau LTS doit rester stable longtemps après sa sortie.

Le calendrier reste classique. La fenêtre de fusion s’est fermée le 1er novembre 2026 avec le rc1. Suivront plusieurs rc pendant six à huit semaines, puis la version stable est attendue « right around the end of December », selon Phoronix. La sortie d’un LTS en fin d’année tomberait au bon moment pour les distributions qui calent leurs versions longues sur l’automne.

Pour un SRE ou un RSSI, la leçon est double. D’abord, la masse de code IA ne va pas se tarir : elle est en train de se normaliser dans le flux du noyau. Ensuite, le contrôle humain reste le verrou — Torvalds lui-même insiste sur la réécriture systématique. Ne partez pas du principe qu’un correctif « suggéré par l’IA » est vérifié : il l’est, justement, par un humain, et c’est ce qui le rend intégrable.

Verdict. Si vous suivez un noyau mainline, testez 7.4-rc1 sur du matériel de labo, pas en production : le volume de code est inédit. Si vous êtes en parc stable, ne bougez pas avant la version finale de décembre 2026 — et si 7.4 est confirmé LTS, planifiez sa montée de version comme un jalon de maintenance, pas comme une routine.

Références

• Linus Torvalds — State of the kernel du 1er novembre 2026 (LKML)
• The Register — Linus Torvalds says Linux kernel is out of ‘stabilization phase’ and using ‘much healthier model’ for AI contributions
• Phoronix — Linux 7.4 Features Very Exciting With Radeon HDMI 2.1 By Default, AMD PerfOpt, Apple M4
• Phoronix — Linux 7.4 Merge Window Saw Nearly 20k Commits, Source Tree Approaching 42 Million Lines