Il y a une question qu'on me pose à chaque fois que je dépanne un serveur chez un client : « ça vaut vraiment le coup de changer de version, ou c'est encore du chamboulement pour rien ? » La semaine dernière encore, sur une machine de production qui tournait depuis onze mois sans redémarrage, j'ai répondu la même chose qu'il y a deux ans. Sauf que cette fois, j'ai eu tort.
Parce que les nouvelles fonctionnalités des systèmes d'exploitation Linux ont changé de nature. Pendant longtemps, une montée de version apportait surtout des pilotes en plus et deux ou trois correctifs. Aujourd'hui, ce qui bouge touche au cœur de la machine : la façon dont le noyau décide qui travaille, quand, et sur quel cœur. Et ça, vous le sentez sur un poste de travail comme sur un parc de serveurs.
Points clés à retenir
- La planification sensible au cache redistribue le travail entre les cœurs selon les données déjà présentes en mémoire : c'est le gain le plus tangible des noyaux récents sur les charges de compilation et de bases de données.
- Les grandes distributions ont divergé sur le rythme : RHEL mise sur des cycles longs et un noyau figé, Azure Linux et Fedora sur des versions quasi trimestrielles.
- Le passage à dnf5 change concrètement les temps de résolution de dépendances, pas seulement la ligne de commande.
- Les failles récentes touchent surtout des composants optionnels (KVM, cifs-utils) : la mitigation passe d'abord par la désactivation du module concerné, pas par une réinstallation complète.
- Le vrai coût d'une migration, ce n'est presque jamais le noyau. C'est la pile logicielle autour.
Ce qui change vraiment avec les nouvelles fonctionnalités Linux
Prenons un cas précis, parce que les annonces de versions sont toujours plus flatteuses que la réalité du terrain. Je gérais une ferme de compilation pour un éditeur de logiciels : six machines identiques, même matériel, même charge, seule la version du noyau différait. Objectif : recompiler un gros projet C++.
Le noyau le plus récent a réduit le temps total d'un peu moins de 9 %. Pas de quoi sauter au plafond, me direz-vous. Sauf que la variance entre les runs a chuté bien plus que la moyenne. Avant, un build durait entre 14 et 23 minutes selon l'humeur du système. Après, entre 16 et 18.
C'est ça, le vrai apport. Pas la vitesse moyenne. La régularité.
La planification sensible au cache, expliquée simplement
Le principe tient en une phrase : au lieu de répartir les tâches selon la charge des cœurs, l'ordonnanceur regarde où sont déjà les données dans le cache. Si une tâche a besoin de données présentes dans le cache L3 d'un cœur donné, autant l'y envoyer plutôt que de la déplacer vers un cœur « plus libre ». Le déplacement coûte plus cher que l'attente.
En pratique, ça veut dire que deux processus qui travaillent sur les mêmes structures mémoire ont intérêt à rester voisins. Le noyau fait ce calcul en continu, plusieurs milliers de fois par seconde.
Sur une machine de bureau, vous ne verrez presque rien. Sur un serveur de base de données, c'est une autre histoire. Sur une machine virtuelle mal configurée, ça peut même dégrader les choses, parce que l'ordonnanceur voit des cœurs qui n'en sont pas vraiment. Franchement, c'est le point que personne ne mentionne dans les notes de version.
Le piège des benchmarks de no-version
Avouons-le : les tableaux comparatifs qui circulent sur les forums comparent presque toujours des configurations qui n'ont rien à voir. Machine A avec un SSD NVMe, machine B avec un disque SATA, et hop, on conclut que le nouveau noyau est 30 % plus rapide. Ça ne veut rien dire.
Ce que j'ai mesuré, sur du matériel strictement identique :
- Charge web statique (nginx, fichiers de quelques kilo-octets) : gain quasi nul, les caches disque dominent tout.
- Compilation parallèle : gain visible, autour de 5 à 9 % selon la taille du projet.
- Base de données en lecture intensive : gain modeste, mais latence p99 nettement plus stable — c'est ce qui compte en production.
- Machine virtuelle avec CPU épinglé : parfois régression. À tester au cas par cas.
Vous remarquerez qu'aucun de ces chiffres ne ressemble à ceux des annonces. C'est normal. Vos charges de travail ne sont pas celles des gens qui écrivent les notes de version.
La guerre des distributions : ce que chacune fait vraiment
Il y a quelques années, je pensais qu'on pouvait classer les distributions en deux familles, et que ça suffisait. Erreur. Ce qui compte aujourd'hui, c'est le rythme de livraison et la tolérance au changement.
| Distribution | Rythme des nouveautés | Gestionnaire de paquets | Cycle de support | Public visé |
|---|---|---|---|---|
| RHEL | Noyau figé, rétroportage | dnf / yum | Long, mesuré en années | Entreprises, serveurs critiques |
| Fedora | Environ tous les six mois | dnf5 à partir des versions récentes | Court | Poste de travail, testeurs |
| Ubuntu LTS | Tous les deux ans, mises à jour intermédiaires | apt | Long, avec extensions payantes | Serveur et bureau, large mix |
| Azure Linux | Quasi trimestriel | dnf5, bibliothèques récentes | Lié au cloud | Charges hébergées chez Microsoft |
| Rocky Linux | Aligné sur RHEL | dnf | Long | Contournement de la licence RHEL |
| Amazon Linux | Annuel environ | dnf | Cinq ans par version, dépôt verrouillé | Charges AWS |
Ce tableau dit une chose simple : vous ne choisissez pas une distribution pour ses fonctionnalités, vous la choisissez pour son rythme. Une PME qui migre tous les deux ans n'a rien à faire d'une distribution qui change tous les six mois. Sauf qu'elle veut quand même bénéficier des gains de performance. Et là commence la vraie négociation interne.
RHEL, le noyau figé et ses conséquences
La stratégie de Red Hat est cohérente et je la respecte : vous livrez un noyau stable et vous rétroportez les correctifs et certaines optimisations à l'intérieur. Résultat, un serveur que vous installez aujourd'hui continuera de fonctionner dans cinq ans sans surprise majeure.
Le revers, c'est que vous n'aurez pas la dernière version de l'ordonnanceur. Vous aurez une version proche, corrigée pour les cas connus. Pour une application critique, c'est un excellent compromis. Pour un poste de développement où l'on veut profiter des gains mémoire, c'est frustrant.
Ubuntu et l'écosystème de bureau
Sur Ubuntu, la donne est différente. Les versions intermédiaires embarquent des noyaux beaucoup plus récents, et j'ai constaté sur ma propre machine de développement que les temps de compilation avaient chuté de manière perceptible après une simple mise à jour de noyau, sans rien changer d'autre.
Ce qui m'a le plus surpris, ces derniers mois, c'est la vitesse à laquelle dnf5 a changé mon rapport à la ligne de commande côté Fedora. La résolution de dépendances, qui prenait autrefois plusieurs secondes sur un dépôt froid, tombe maintenant sous la seconde. Un détail ? Non : un dnf upgrade sur une machine de test me prend maintenant moins de temps que le café que je vais chercher pendant qu'il tourne. C'est bête, mais c'est exactement le genre de gain qui change une habitude.
Et la sécurité, dans tout ça ?
Les failles récentes qui ont circulé dans les listes de diffusion ont un point commun : elles touchent presque toutes des composants que la majorité des installations n'utilisent pas activement. KVM quand vous ne faites pas de virtualisation. cifs-utils quand vous ne montez pas de partage Windows.
Ça ne veut pas dire qu'il faut ignorer les alertes. Ça veut dire qu'il faut arrêter de réinstaller des serveurs entiers pour une faille dans un module que vous n'avez jamais chargé.
Comment se protéger concrètement
- Vérifiez d'abord si le module concerné est chargé. Une simple commande de listage suffit dans la plupart des cas :
lsmod. - Si vous ne l'utilisez pas, désactivez-le par une règle de blocage dans la configuration du noyau plutôt que de courir après un correctif.
- Appliquez les mises à jour de sécurité de votre distribution, mais lisez les notes : toutes ne vous concernent pas.
- Sur les noyaux personnalisés, gardez une trace de ce que vous avez compilé. J'ai perdu une journée entière à chercher pourquoi une machine refusait de démarrer, alors que j'avais simplement oublié d'inclure un pilote de stockage.
Erreur classique : appliquer un correctif noyau sans redémarrer. Le module reste chargé en mémoire jusqu'au reboot, et vous croyez être protégé alors que vous ne l'êtes pas.
Spoiler : la plupart des incidents de sécurité que j'ai vécus chez des clients ne venaient pas d'une faille exotique. Ils venaient d'un serveur jamais redémarré depuis des mois, avec un correctif appliqué et inactif.
Faut-il vraiment mettre à jour en 2026 ?
Ma réponse, et j'assume d'être un peu tranchant : oui, mais pas pour les raisons qu'on vous vend.
Ne migrez pas pour gagner 8 % de performance sur une compilation. Migrez parce que votre distribution actuelle approche de la fin de son support, et qu'à partir de ce moment-là, vous n'avez plus de correctifs de sécurité. Le reste, c'est du confort.
Ce qui m'agace profondément, c'est que la communication autour des versions récentes met en avant des fonctionnalités spectaculaires, alors que le vrai argument est presque administratif : combien de temps encore votre système recevra-t-il des correctifs ?
Le test à faire avant toute migration
Avant de toucher à quoi que ce soit, prenez une copie de votre machine et lancez vos charges réelles dessus. Pas un test de disque dur. Votre application, votre base, vos scripts. J'ai vu des migrations parfaites sur le papier échouer parce qu'une bibliothèque mineure n'avait pas été reconstruite pour la nouvelle version.
Comptez une semaine pour un serveur, deux pour un parc hétérogène. C'est du temps perdu, oui. C'est aussi le prix de la tranquillité les trois années suivantes.
Ce que je retiens après toutes ces migrations
Les nouveautés des noyaux Linux sont réelles, mesurables, et souvent décevantes par rapport aux annonces. Mais la vraie transformation de ces dernières années n'est pas là. Elle est dans la professionnalisation de la maintenance : des cycles annoncés, des dépôts verrouillés, des outils qui préviennent au lieu de casser.
On est passé d'un monde où l'on bricolait des serveurs à un monde où l'on choisit un rythme et où l'on s'y tient.
Alors, la prochaine fois qu'on vous annonce un gain de 30 %, posez une seule question : « sur quelle charge, et avec quelle version du reste de la pile ? » Si la réponse est floue, vous savez ce qu'il vous reste à faire. Tester vous-même, sur vos données, avec vos contraintes. C'est moins rapide. C'est la seule façon de savoir.
