Linux 7.3 sort avec un record de 18 765 commits et 807 nouveaux contributeurs
Le 18 octobre 2026, Linus Torvalds publie le noyau Linux 7.3, une version record avec 18 765 commits de 3 021 développeurs, dont 807 primo-contributeurs, et des nouveautés sur les systèmes de fichiers, l’ordonnanceur et BPF. Avant de mettre à jour vos serveurs de production, lisez ce qui a réellement changé et ce qui peut attendre la 7.4.
18 octobre 2026. Linus Torvalds publie le noyau Linux 7.3. 18 765. Le nombre de commits non-merge intégrés, un record. 807. Le nombre de développeurs qui signent leur première contribution au noyau. Pourquoi c’est important : la 7.3 n’apporte pas un changement phare mais une largeur inédite — systèmes de fichiers, ordonnanceur, BPF, appels système — qui concerne à la fois les serveurs, les postes et l’embarqué.
Une version record sur tous les fronts
Le chiffre le plus frappant de ce cycle est démographique. Linux 7.3 totalise 18 765 commits non-merge, écrits par 3 021 développeurs, dont 807 primo-contributeurs. Aucune version antérieure n’avait mobilisé autant de monde ni intégré autant de changements sur une seule fenêtre de fusion. C’est la confirmation chiffrée d’une tendance observée depuis plusieurs années : le noyau reste l’un des projets logiciels les plus actifs au monde, et son vivier de nouveaux contributeurs continue de s’élargir.
Torvalds a lui-même annoncé la sortie avec le ton détaché qui le caractérise. « C’est dimanche après-midi, et cette semaine j’ai réussi à garder la tête froide assez longtemps pour suivre le jour de la semaine, donc la sortie n’est pas retardée au hasard », écrit-il. Il prévient surtout que la fenêtre de fusion de la 7.4 s’ouvre le 19 octobre, mais qu’il est en vacances en famille : il passera la matinée « sur un bateau et sous l’eau » et ne fusionnera que l’après-midi. Le calendrier des premières semaines de la 7.4 sera donc un peu décalé.
Ce qui entre réellement dans le noyau
Derrière le record comptable, la 7.3 livre des changements répartis sur plusieurs sous-systèmes. Trois méritent l’attention d’un opérateur :
- Systèmes de fichiers. Un nouveau système, failfs, échoue volontairement toutes les opérations — un outil de test, pas un système de production. ntfs3 gagne le support des flux de données alternatifs, et le serveur SMB reçoit une longue liste d’améliorations.
- Ordonnancement. Le group scheduling vise de meilleures performances sur les grandes machines, et la fonctionnalité de sous-ordonnanceur sched_ext est désormais complète : elle permet de charger des politiques d’ordonnancement en BPF et de les mettre à jour sans redémarrer.
- Infrastructure. binfmt_misc gagne des extensions notables, le nouvel appel système fchroot() arrive, les programmes BPF disposent de données globales par CPU, et les machines virtuelles profitent d’un suivi de working set.
Deux ajouts illustrent la direction générale. fchroot() étend la logique de chroot à un descripteur de fichier, ce qui ouvre des usages en conteneurisation et en isolation fine. Le working-set tracking pour les machines virtuelles, lui, s’inscrit dans la longue marche de KVM vers une meilleure gestion mémoire des invités. Aucun de ces éléments n’est spectaculaire isolément ; leur somme fait de la 7.3 une version qui touche à presque tout le noyau.
failfs, ou l’art de tester l’échec
failfs vaut une parenthèse. Le principe est contre-intuitif : un système de fichiers dont chaque opération échoue. Son intérêt n’est pas la production, mais le test de robustesse — vérifier que les applications gèrent correctement les erreurs d’écriture, les ENOSPC, les EIO et les échecs d’allocation. C’est une brique d’ingénierie de fiabilité que les équipes qui développent des logiciels de stockage ou des bases de données attendaient de longue date.
L’arrivée de failfs dans le noyau principal signale aussi une normalisation : plutôt qu’un module hors-arbre maintenu par une poignée de personnes, l’outil est désormais disponible partout, documenté dans les kernel docs et versionné avec le reste. Pour les équipes d’infrastructure, c’est une raison de plus d’intégrer des scénarios de panne injectée dans leurs pipelines de validation.
Ce que ça change pour vous
La question pratique est celle du calendrier de mise à jour. La 7.3 est une version stable au sens strict : elle termine un cycle normal de candidats et n’est pas une LTS. La politique de maintenance s’applique donc comme pour les autres versions majeures récentes — des correctifs jusqu’à la sortie de la suivante, puis une bascule vers la prochaine version stable.
Pour un serveur de production qui tourne déjà sur une branche LTS, rien ne presse : restez sur votre branche maintenue et laissez la 7.3 mûrir quelques semaines. Pour un poste de travail ou un environnement de test sous distribution rolling — Arch, Fedora Rawhide ou assimilé — la 7.3 arrivera par le flux habituel de mise à jour. Pour les équipes noyau et les fournisseurs de distributions, l’enjeu est déjà ailleurs : la fenêtre de fusion de la 7.4 est ouverte, et c’est là que se jouent les prochaines fonctionnalités.
Le point de vigilance concerne les pilotes hors-arbre et les modules tiers : chaque version majeure change les API internes, et les modules compilés pour la 7.2 devront souvent être reconstruits. Vérifiez que vos modules sensibles — GPU, réseau, stockage — sont compatibles avant de basculer. Enfin, la largeur même du cycle complique le travail de backport : attendez-vous à ce que les correctifs de la 7.3.x soient triés plus finement que d’habitude par les mainteneurs de distributions.
Pour un premier déploiement, la méthode recommandée reste la même que pour toute version majeure : basculez d’abord une machine non critique, laissez tourner quelques jours sous charge réelle, puis étendez. La 7.3 n’a pas de correctif urgent à appliquer dans l’heure, mais elle n’en reste pas moins une version majeure — et une version majeure se teste, elle ne se déploie pas en aveugle.
La Rust for Linux continue en coulisses
Le record de contributeurs cache une autre trajectoire, plus lente mais tout aussi structurante : la montée en puissance de Rust dans le noyau. À la conférence Kangrejos 2026, Gary Guo a présenté une solution au problème des structures auto-référentes — ces objets qui se référencent eux-mêmes et que Rust ne peut pas modéliser proprement sans code unsafe. S’appuyant sur la crate pin_init, ses changements pourraient supprimer l’essentiel du code unsafe lié aux durées de vie dans le pilote Nova — le pilote GPU en Rust — puis, à terme, dans d’autres composants.
Pourquoi ça compte dans une note sur la 7.3 : la 7.4 et les versions suivantes ne se joueront pas seulement sur les systèmes de fichiers ou l’ordonnanceur, mais sur la capacité du noyau à accueillir du code Rust sûr à plus grande échelle. Le chantier est structurel : chaque abstraction qui permet de « posséder » un objet alloué en C depuis du Rust — le trait Ownable présenté à la même conférence — réduit la friction qui freine encore les pilotes écrits dans un langage à mémoire sûre. Ce n’est pas un changement visible dans le diff de la 7.3, mais c’est celui qui conditionne le noyau de 2027.
Verdict
Si vous administrez des serveurs LTS, ne bougez pas : la 7.3 est une étape, pas une urgence, et votre branche maintenue reste le bon choix. Si vous êtes sur une distribution rolling ou si vous testez du matériel récent, prenez la 7.3 dès qu’elle arrive : la largeur des correctifs et le support matériel élargi en font une mise à jour saine. Dans tous les cas, retenez le signal de fond : un noyau qui attire 807 nouveaux contributeurs en un seul cycle n’est pas un projet en déclin — c’est un projet qui accélère, et la 7.4 se prépare déjà.