Linus Torvalds a lié la flambée de correctifs pour Linux 7.0 à l'AI et au risque de retard de sortie

Le 30 mars 2026, Linus Torvalds s'est plaint publiquement d'un flux inhabituellement important de correctifs pour Linux 7.0 RC6. Selon lui, une partie de cette augmentation pourrait être liée à l'utilisation massive d'outils d'IA, et la charge sur les mainteneurs a tellement augmenté qu'à ce moment-là, le risque d'un retard de la version stable était même en discussion.

Pourquoi Y a-t-il Plus de Correctifs

Le sixième candidat à la version signifie normalement que le noyau entre déjà dans une phase tranquille : les changements majeurs sont derrière, il ne reste que des corrections ponctuelles, des tests et du polissage. Dans le cas de Linux 7.0, le tableau s'est avéré différent. Torvalds a noté qu'à la fin mars, il avait reçu notablement plus de corrections que d'habitude à ce stade, et il ne s'agissait pas de quelques séries controversées, mais d'un large flux de petites améliorations en provenance de différentes parties de l'arborescence. Pour l'équipe de maintenance, cela signifie automatiquement plus d'examen manuel et plus de risques pour le calendrier de publication.

L'augmentation du nombre de corrections en elle-même ne signifie pas que la version est cassée. Au contraire, Torvalds a souligné séparément que la plupart des correctifs semblaient réels et utiles. Ce qui l'inquiétait, c'était autre chose : le volume. Quand ces changements deviennent trop nombreux, le coût de l'examen, de la discussion, de la re-vérification et de la prise de décision sur les délais augmente considérablement. Même les bons correctifs dans une telle situation commencent à ralentir la version, car les mainteneurs manquent de bande passante à l'étape finale avant la compilation stable.

Pourquoi l'IA a Émergé Ici

Torvalds a suggéré que l'augmentation pourrait être liée au fait que les outils d'IA sont devenus meilleurs pour trouver les cas limites et pour proposer rapidement de petites corrections. C'est un détail important : il n'a pas dit que le noyau avait été inondé de vrais déchets générés sans examen. Il s'agit plutôt d'une nouvelle mécanique de développement dans laquelle le coût de création d'un correctif baisse considérablement, ce qui signifie que plus de changements petits, mais formellement valides, entrent dans la file d'attente d'examen. C'est exactement cette asymétrie entre la génération et l'examen qui commence à nuire au processus en ce moment.

"Beaucoup de corrections plutôt triviales, mais réelles," c'est ainsi que

Torvalds a décrit la nature de cette vague.

Pour Linux, c'est un sujet sensible, car le goulot d'étranglement a toujours été non le code lui-même, mais l'attention humaine des mainteneurs. Si l'IA aide à trouver des bugs supplémentaires, la qualité du noyau à long terme pourrait augmenter, surtout dans les scénarios rares et mal couverts. Mais si elle crée simultanément un flux de micro-corrections qui est difficile à filtrer rapidement, l'examen devient un goulot d'étranglement. Et c'est ce qui semble le plus irriter le créateur de Linux : non la présence de l'IA en soi, mais la nouvelle charge opérationnelle pour les personnes prenant les décisions.

Ce Qui Change dans Linux 7.0

Sur le fond de la discussion sur le rôle de l'IA, la version 7.0 elle-même ne ressemblait pas à une révolution. Torvalds avait déjà dit auparavant qu'un nouveau numéro de version ne signifie pas un tournant architectural radical. Le corps principal des changements dans cette branche était assez banal : corrections de systèmes de fichiers, drivers et code d'infrastructure, sans une caractéristique dominante qui expliquerait tout le bruit autour de la version. C'est aussi important : plus la version est calme en elle-même, plus l'augmentation anormale des petites corrections paraît évidente à l'étape finale du cycle.

Parmi les domaines qui se sont particulièrement démarqués dans le flux de correctifs et de corrections, plusieurs zones habituelles pour le noyau ont été mentionnées. C'est pourquoi l'histoire ne ressemble pas à un accident dans un sous-système, mais à une charge distribuée sur tout le processus de maintenance, où chaque correction individuelle peut être petite, mais son volume total casse le rythme habituel du travail de l'équipe. C'est particulièrement visible à l'étape RC, quand les mainteneurs essaient normalement de ne laisser passer que les changements vraiment nécessaires.

• améliorations pour les systèmes de fichiers EXT4 et XFS
• corrections typiques des drivers GPU
• changements dans le sous-système réseau et RDMA
• mises à jour dans la pile audio et les outils utilitaires
• de nombreuses corrections ponctuelles pour divers cas limites

Un contexte séparé est aussi important ici. Auparavant, Torvalds avait déjà critiqué durement certaines séries de correctifs pour Linux 7.0, par exemple les changements autour du sous-système MMC, qu'il a appelés mal préparés. Dans ce contexte, sa réaction actuelle était même étonnamment calme : au lieu de critiquer la qualité, il a parlé précisément de l'ampleur du flux entrant. Cela rend l'histoire instructive — le problème avec l'IA dans le code ouvert porte de moins en moins sur le code factice, mais sur la surcharge du processus de maintenance et une baisse du ratio signal-bruit.

Ce Que Cela Signifie

L'histoire de Linux 7.0 montre comment l'IA change le développement de logiciels d'infrastructure : il est devenu plus facile de générer et de trouver des corrections, mais la bande passante d'examen n'a pas augmenté aussi rapidement. Pour le code ouvert, cela pourrait signifier une nouvelle norme, où la principale pénurie n'est pas le code, mais le temps des mainteneurs expérimentés. Si ce déséquilibre s'intensifie, la compétence la plus précieuse s'avérera être non pas écrire un autre correctif, mais filtrer rapidement, vérifier et prioriser ce qui mérite vraiment d'être inclus dans la version.