# 13. Nouveautés Linux — premier semestre 2026

Cette section rassemble les évolutions les plus significatives de
l'écosystème Linux vérifiées début 2026, chacune datée et sourcée au moment
de la rédaction — un instantané, pas une promesse de stabilité définitive
pour les éléments encore en développement actif.

## Rust dans le noyau : fin du statut expérimental

En décembre 2025, les mainteneurs du noyau ont acté que Rust n'est plus
considéré comme expérimental — il rejoint le C et l'assembleur comme
langage central du développement noyau. Conséquences concrètes déjà
observables début 2026 :

- Des pilotes, systèmes de fichiers et composants réseau écrits en Rust
  sont **en production**, notamment dans des pilotes Android — Google
  rapporte zéro bug de sécurité mémoire détecté en production sur le code
  Rust déployé à ce jour.
- Une proposition encore en développement, présentée à RustWeek 2026,
  viserait à éliminer jusqu'à **80 % des CVE** habituellement générées par
  le noyau — l'essentiel des failles noyau historiques provenant de
  corruptions mémoire, précisément la classe d'erreurs que le système de
  types de Rust rend impossible à la compilation.

## bcachefs : stable, mais sorti du noyau

Trajectoire notable et à double tranchant : le système de fichiers
**bcachefs** a atteint le statut stable (annoncé avec la version 1.38.6 de
ses outils, juin 2026) — mais a été **retiré de l'arbre source du noyau
mainline** à partir de la version 6.18, à la suite d'un désaccord entre son
auteur et les mainteneurs du sous-système VFS sur le rythme d'intégration
de correctifs hors cycle. bcachefs se distribue désormais comme **module
DKMS externe**, exactement sur le même modèle qu'OpenZFS (voir section 3)
— stable ne signifie donc plus, dans ce cas précis, « intégré au noyau
officiel ».

## io_uring : évolution continue de l'E/S asynchrone

`io_uring` (interface d'entrées-sorties asynchrones à faible surcoût,
basée sur deux anneaux mémoire partagés noyau/application) continue de
s'étendre rapidement :

- Depuis la 6.13 : redimensionnement d'anneau et régions d'attente
  enregistrables, réduisant le coût de destruction/recréation lors d'un
  changement de charge.
- La série 7.x introduit un mécanisme permettant de **remplacer**
  l'exécution standard de l'appel système `io_uring_enter()` par une
  boucle d'événements extensible, pilotable via BPF (nouveaux
  `io_uring struct_ops`) ou depuis l'intérieur même du noyau, ainsi qu'un
  support BTF pour l'introspection de types.
- Volet sécurité actif : `io_uring` a longtemps posé un problème de
  compatibilité avec le bac à sable **seccomp** (les appels passent par un
  petit nombre de points d'entrée génériques, rendant le filtrage par
  appel système classique inefficace) — un mécanisme de restriction dédié
  est en cours de développement pour combler cet écart.

## Cryptographie post-quantique : du noyau à l'écosystème

- **Dans le noyau** : des correctifs de démonstration pour **ML-KEM** et
  **X-Wing** (mécanisme hybride combinant X25519 classique et ML-KEM-768)
  ont été proposés en mai 2026 par un cryptographe du noyau — non encore
  intégrés officiellement, en attente d'un premier consommateur interne
  réel avant upstreaming.
- **Dans l'écosystème plus large, déjà concret** : OpenSSH 10.2p1 (livré
  par défaut sur certaines distributions récentes) active un échange de
  clés hybride **ML-KEM-768 par défaut** ; des distributions orientées
  conformité intègrent le support ML-KEM en mode FIPS pour OpenSSH ainsi
  que des mécanismes hybrides combinant ML-KEM et ECDH.
- ML-KEM est la norme NIST **FIPS 203**, dérivée de CRYSTALS-Kyber,
  garantissant une sécurité IND-CCA2 contre un adversaire disposant d'un
  calculateur quantique suffisamment puissant.

## Numérotation du noyau : la transition 6.x vers 7.x

Le noyau mainline est passé en série **7.x** courant 2026 (7.1.5 stable au
24 juillet 2026, 7.2 en release candidate lors de la rédaction) — un
changement de numérotation majeure sans rupture de compatibilité
particulière, dans la continuité du schéma de versionnage déjà en usage
depuis la transition 2.6 vers 3.0. Les branches **LTS** (support long terme)
restent actives en parallèle sur les séries antérieures (6.18, 6.12, 6.6,
6.1) : la plupart des systèmes en production tournent sur une LTS plutôt
que sur le mainline le plus récent — voir section 1 pour la distinction
pratique entre les deux.

*(Schéma disponible : `schema.svg`, dans ce dossier.)*