Le flux de correctifs de l’ère GenAI ébranle le modèle des distributions LTS

7 au 10 octobre 2026. La Linux Plumbers Conference se tient à Prague. Khem Raj, ingénieur chez Qualcomm, y remet en cause la pertinence des distributions LTS à l’ère de l’IA générative. 50 correctifs réseau détournés vers le prochain noyau en une seule semaine. Pourquoi c’est important : l’hypothèse qui justifie les LTS — un flux de correctifs lent, prévisible et entièrement revu par des humains — est en train de changer sous nos yeux.

L’IA inonde le noyau de correctifs

Le sous-système réseau du noyau Linux est le symptôme le plus visible du phénomène. La semaine du 6 octobre 2026, le lot de correctifs réseau destiné au noyau 7.3-rc7 a été soumis et fusionné, mais plus de 50 correctifs ont dû être détournés vers le cycle suivant, tant l’afflux était important. Phoronix décrit un sous-système « bombardé de correctifs et de rapports de bugs générés par l’IA ». Ce n’est pas une nouveauté isolée.

Le volume global explose. Le projet Sashiko de Google, couvert sur ETTAYEB le 9 octobre, relit à la chaîne 191 000 patches du noyau. Greg Kroah-Hartman, mainteneur du noyau stable, a de son côté démonté 79 prétendues failles « découvertes » par des modèles de langage qui n’étaient que des hallucinations — un travail de tri qui ne produit aucune valeur mais consomme du temps de revue.

Le résultat est mécanique : le temps humain de revue devient la ressource rare, alors que le nombre de patches candidats explose. C’est exactement le point d’entrée du débat de Prague.

L’argument de Khem Raj

La position défendue par Khem Raj tient en une idée simple. Une distribution LTS promet de ne pas bouger — mais dans un noyau où le flux de correctifs est continu et partiellement alimenté par des machines, cette promesse a un coût croissant. Chaque correctif stable doit être backporté vers cinq branches LTS simultanément (6.12, 6.6, 6.1, 5.15 et 5.10, toutes encore vivantes au 11 octobre 2026 selon kernel.org). Chaque backport exige une revue, une adaptation au contexte, un test — du travail qui se multiplie à mesure que le flux amont grossit.

Une distribution rolling release, elle, reste collée à mainline. Le mainteneur applique les correctifs une fois, au fil de l’eau, sans avoir à rejouer la compatibilité avec une version vieille de trois ans. Quand l’essentiel de la valeur d’un correctif est d’arriver vite — correctifs matériels pour de nouveaux GPU, nouveaux SoC embarqués, contournements d’errata comme celui de l’erratum AMD TLBI #1718 ajouté au noyau 7.3-rc7 le 11 octobre — la distance au mainline devient un handicap, pas une protection.

Pourquoi le modèle LTS tenait jusqu’ici

Le modèle LTS n’est pas né d’un caprice. Il repose sur trois promesses concrètes, qui ont longtemps été vraies. Stabilité d’API : un noyau gelé signifie que les pilotes et modules compilés continuent de charger sans recompilation pendant des années — critique pour les constructeurs de cartes embarquées. Traçabilité réglementaire : dans l’industrie, l’aéronautique ou la santé, chaque changement doit être justifié, audité, et un backport ciblé est plus facile à documenter qu’un glissement continu. Assurance anti-régression : un patch qui a mûri plusieurs semaines dans mainline avant d’être backporté est statistiquement moins risqué qu’un patch appliqué le jour de sa fusion.

La limite est connue : un LTS ne protège pas contre le flux de correctifs, il le décale et le duplique. Tant que le flux était humain et modéré, la duplication restait absorbable. Le débat de Prague pose la question du point de bascule.

Ce que l’IA change réellement

Il faut distinguer deux choses que le débat mélange souvent. D’un côté, l’IA produit du bruit : des rapports de bugs inventés et des patches de qualité douteuse qui augmentent la charge de tri, pour un bénéfice nul. De l’autre, elle accélère aussi la production de vrai travail : des correctifs de pilotes générés puis validés, des outils de revue comme Sashiko qui absorbent une partie du volume. Les deux phénomènes vont dans le même sens — plus de patches à backporter — mais ils n’appellent pas la même réponse.

Le bruit plaide pour concentrer la revue humaine sur mainline, là où elle a le plus d’effet de levier, plutôt que de la diluer sur cinq branches gelées. Le vrai travail plaide pour que les utilisateurs qui en dépendent — pilotes récents, support matériel, correctifs de sécurité — puissent en bénéficier sans attendre la prochaine fenêtre de backport. Dans les deux cas, la logique du rolling release sort renforcée.

Reste l’objection du risque. Un rolling release expose à davantage de changements non testés par la masse. La parade historique est le canari : déployer d’abord sur un sous-ensemble, mesurer, puis généraliser. C’est une discipline que les équipes de SRE maîtrisent déjà, mais que beaucoup de parcs LTS ont justement choisi d’éviter en gelant leurs versions.

Verdict

Si vous opérez un parc hétérogène de postes de travail, de nœuds GPU ou de cartes embarquées récentes, le calcul a changé : rester sur un LTS vieux de plusieurs années vous coupe des correctifs matériels et des contournements d’errata qui arrivent chaque semaine dans mainline, sans vous épargner le flux de correctifs stable — il vous arrive simplement plus tard et en cinq exemplaires. Une base rolling ou une stable à fenêtre courte (7.x), avec un canari de déploiement, est désormais plus proche du rythme réel du noyau.

Si vous opérez une flotte certifiée, réglementée ou à API gelée (industrie, médical, embarqué à cycle long), le LTS garde son sens : la promesse d’un socle auditable n’est pas remplacée par la vélocité. Mais traitez-le comme un choix de gouvernance, pas comme une garantie de « moins de changements ». Le flux de correctifs ne diminue pas à l’ère de l’IA — il se duplique sur vos branches gelées, et c’est vous qui en absorbez le coût de revue.

Références

• Phoronix — Rolling Release Distros Superior To LTS Distros In The Patch-Heavy GenAI Era?
• Phoronix — Linux Networking Diverts 50+ Fixes To Next Kernel, Still Bombarded With AI Fueled Churn
• kernel.org — The Linux Kernel Archives (branches stable et longterm)
• Phoronix — Linux Landing Kernel Workaround For AMD TLBI Erratum #1718