Microsoft reconnaît officiellement que la mise à jour de sécurité KB5089549 pour Windows 11 peut échouer à l’installation avec l’erreur 0x800f0922 sur certains PC.
Le problème touche principalement Windows 11 25H2 après le Patch Tuesday de mai 2026 et semble lié aux nouvelles mises à jour du Secure Boot 2023 intégrées dans cette cumulative.
L’erreur 0x800f0922 revient encore sur Windows Update
L’erreur 0x800f0922 n’est pas nouvelle sous Windows Update. Elle apparaît généralement lorsque Windows rencontre un problème pendant :
Avec KB5089549, Microsoft confirme que certains systèmes peuvent :
échouer pendant l’installation
annuler la mise à jour
revenir automatiquement à la version précédente
afficher 0x800f0922 dans l’historique Windows Update
Dans certains cas, plusieurs redémarrages successifs peuvent également survenir avant l’échec final.
Le problème semble lié au Secure Boot 2023
Cette mise à jour contient notamment les nouveaux certificats Secure Boot 2023 qui remplacent progressivement les anciens certificats UEFI de 2011 arrivant à expiration en juin 2026.
Or, la mise à jour de ces composants sensibles du démarrage Windows nécessite :
des modifications UEFI
des mises à jour de certificats
des opérations sur la partition EFI
des vérifications TPM/Secure Boot
Sur certaines configurations, ces opérations échoueraient pendant la phase d’installation.
Microsoft précise que le problème touche principalement les systèmes utilisant certaines configurations TPM ou Secure Boot spécifiques.
Techniquement, pourquoi l’erreur 0x800f0922 se produit ?
Avec KB5089549, Microsoft déploie notamment les nouveaux certificats Secure Boot 2023 ainsi que des modifications des fichiers de boot. Or, ces opérations nécessitent d’écrire de nouveaux fichiers dans la partition EFI.
Le souci est que beaucoup de PC disposent d’une partition EFI très petite :
100 Mo
260 Mo
parfois moins sur certaines anciennes installations OEM
Et cette partition contient déjà :
les fichiers de boot Windows
les certificats Secure Boot
les fichiers BitLocker
des composants OEM
parfois plusieurs anciens chargeurs EFI
Microsoft explique que les systèmes disposant de 10 Mo ou moins d’espace libre dans l’ESP sont particulièrement touchés.
Pendant l’installation :
Windows télécharge la cumulative
prépare les nouveaux fichiers de boot
commence la phase de redémarrage
tente de mettre à jour les composants EFI/Secure Boot
Dans les journaux, plusieurs erreurs reviennent fréquemment :
SpaceCheck: Insufficient free space
ServicingBootFiles failed. Error = 0x70
SpaceCheck: <value> used by third-party/OEM files outside of Microsoft boot directories
Le dernier message est particulièrement intéressant car il montre que certains constructeurs OEM ajoutent leurs propres fichiers EFI dans la partition système, réduisant encore davantage l’espace disponible.
Cela explique aussi pourquoi le problème est difficile à corriger globalement :
chaque constructeur utilise un firmware différent
les tailles de partition EFI varient énormément
certains OEM ajoutent beaucoup de composants personnalisés
certaines anciennes installations Windows ont des partitions EFI sous-dimensionnées
Microsoft recommande actuellement d’utiliser un Known Issue Rollback (KIR) côté entreprise afin de désactiver temporairement le changement responsable du problème.
KB5089549 avait déjà corrigé les problèmes BitLocker
Le contexte est un peu ironique car KB5089549 corrige justement un autre problème important introduit par les précédentes mises à jour Windows 11.
Les mises à jour KB5083769 et KB5082052 provoquaient chez certains utilisateurs des écrans de récupération BitLocker après installation des updates mensuels.
Microsoft avait alors expliqué que :
certains profils PCR7/TPM
certaines configurations Secure Boot
et certaines chaînes de démarrage UEFI
entraient en conflit avec les nouvelles mises à jour de sécurité du démarrage Windows.
KB5089549 était censée corriger définitivement ces problèmes BitLocker sur Windows 11 25H2.
Mais visiblement, la mise à jour introduit maintenant de nouveaux soucis d’installation chez certains utilisateurs.
Microsoft travaille sur un correctif
Pour le moment, Microsoft n’a pas publié de solution définitive.
La firme indique enquêter sur :
les échecs 0x800f0922
les problèmes de boot liés au Secure Boot 2023
certaines incompatibilités TPM/UEFI
Un futur correctif devrait être publié dans une prochaine cumulative ou via Known Issue Rollback (KIR).
En attendant, Microsoft recommande surtout :
de laisser plusieurs tentatives d’installation
de vérifier que le BIOS/UEFI est à jour
de ne pas désactiver Secure Boot
d’éviter les modifications manuelles de la partition EFI
Pourquoi cette transition Secure Boot devient compliquée
Depuis plusieurs mois, Microsoft déploie progressivement une énorme transition de sécurité autour du démarrage Windows :
nouveaux certificats Secure Boot 2023
remplacement des certificats 2011
nouvelles chaînes de confiance UEFI
renforcement TPM
nouvelles politiques de démarrage sécurisé
Le problème est que Windows doit rester compatible avec :
des millions de PC
des BIOS OEM très différents
des firmwares parfois anciens
des configurations TPM variées
Résultat : la moindre modification du processus de boot peut provoquer :
Si vous tournez sur un Windows 11 à jour, sachez qu'il existe une faille qui permet à un programme local spécialement conçu de grimper tranquillou jusqu'au compte SYSTEM. Pour rappel, c'est le compte tout-puissant de la machine, c'est à dire celui qui passe même au-dessus de l'administrateur ! Et cette faille elle s'appelle MiniPlasma, et elle vient d'être balancée en public sur GitHub par un chercheur planqué derrière le pseudo Nightmare-Eclipse.
Et le plus gênaaaaant dans l'histoire, c'est que Microsoft était censé avoir bouché ce trou depuis 2020, dans cette
CVE-2020-17103
, après un signalement de James Forshaw, le chercheur du Project Zero de Google.
Le bug vit sa life dans cldflt.sys, le pilote Cloud Files de Windows. Ce truc c'est un composant système livré d'office avec l'OS, qui est principalement utilisé par OneDrive mais aussi par d'autres stockages cloud. Et bien sûr, il reste présent sur la machine même si vous ne touchez jamais à OneDrive.
Du coup, en passant par une API non documentée baptisée CfAbortHydration, l'exploit crée des clés de registre là où il ne devrait pas, et s'en sert pour détourner un chemin d'exécution privilégié, ce qui finit par lui ouvrir les droits SYSTEM.
Le code de démo est dispo sur le
dépôt GitHub du projet
, écrit en C#, et il lance directement un cmd.exe en SYSTEM quand ça fonctionne. Parce que oui, ça ne marche pas à tous les coups puisque c'est une race condition. Le taux de réussite varie donc d'une machine à l'autre.
Le PoC en action : à gauche, un compte « user » standard lance l'exploit (« Exploit succeeded ») et à droite, le shell obtenu où whoami renvoie nt authoritysystem.
Maintenant, le truc qui fait vraiment mal au cul, c'est que la fameuse faille patchée par Microsoft est donc toujours vulnérable 6 ans après sa détection. Personne ne vérifie chez krosoft ??? C'est dingue !
Selon le chercheur, c'est exactement la même faiblesse qu'à l'époque. Reste à savoir pourquoi ça leur a échappé. Le patch n'a peut-être jamais corrigé la racine du problème, ou il a sauté quelque part en cours de route, j'en sais rien... Faudra analyser le code de Windows et de ses MAJ au fil du temps pour comprendre où ça a merdé.
Du coup, votre machine peut avoir avalé tous les Patch Tuesday et rester quand même exposée à une élévation de privilèges locale dès qu'un attaquant (ou un malware) arrive à exécuter du code dessus.
Nightmare-Eclipse n'en est d'ailleurs pas à son coup d'essai puisque le chercheur enchaîne les divulgations publiques de 0-days Windows depuis quelques semaines, du contournement BitLocker au déni de service sur Defender en passant par plusieurs élévations de privilèges, toujours avec le PoC qui va bien et zéro divulgation coordonnée.
Et y'a pas de "on prévient Microsoft et on attend gentiment 90 jours" ici. Il balance tout car il est a ras-le-bol de la lenteur de Microsoft. C'est violent, dangereux et clairement discutable côté éthique, mais ça met une grosse pression pour corriger au plus vite. Maintenant pour nous tous, ça signifie surtout qu'un PoC public et fonctionnel, ce sont des malwares qui vont vite l'intégrer.
Côté protection, il n'y a pas de correctif officiel ni la moindre déclaration de Microsoft et ucune mitigation validée par l'éditeur non plus. Puis pour un particulier, pas de moyen simple de savoir après coup si la machine a été touchée.
La bonne nouvelle (relative c'est vraie), c'est que l'attaque est purement locale, donc il faut déjà pouvoir exécuter du code sur l'ordi pour en profiter. Votre vraie défense, c'est donc votre hygiène tech habituelle, à savoir ne pas lancer le premier binaire douteux venu, se méfier des cracks et autres pièces jointes, et côté admins, une surveillance EDR des élévations de privilèges inattendues vaut mieux qu'une règle maison non testée.
Après plusieurs incidents liés aux pilotes distribués par Windows Update, Microsoft annonce une nouvelle fonctionnalité baptisée Cloud-Initiated Driver Recovery (CIDR). L’objectif est simple : permettre à Windows 11 de revenir automatiquement à un pilote stable lorsqu’une mise à jour provoque des plantages ou des dysfonctionnements matériels.
Cette annonce intervient alors que Microsoft reconnaît également un autre problème : Windows 11 remplace parfois des pilotes graphiques récents par des versions plus anciennes via Windows Update.
Microsoft veut éviter les catastrophes de pilotes via Windows Update
Les pilotes restent l’une des principales causes de crashs, BSOD et problèmes matériels sous Windows. Lorsqu’un pilote défectueux est publié via Windows Update, les conséquences peuvent être importantes :
Jusqu’à présent, la correction dépendait souvent :
d’un nouveau pilote publié par le constructeur
d’une désinstallation manuelle
d’un rollback local effectué par l’utilisateur
Avec Cloud-Initiated Driver Recovery, Microsoft pourra désormais déclencher à distance un retour automatique vers un pilote stable directement via Windows Update.
Le système fonctionne côté cloud depuis l’infrastructure Windows Update.
Lorsqu’un pilote est détecté comme problématique pendant les validations qualité ou après des signalements massifs :
Microsoft identifie le pilote défectueux
crée une demande de récupération
pousse automatiquement un rollback vers les PC concernés
Windows remplacera alors le pilote problématique par :
une ancienne version stable
ou un pilote approuvé compatible
Le tout sans intervention utilisateur ni action du constructeur OEM.
Microsoft précise également que cette récupération utilisera l’infrastructure Windows Update existante. Aucun nouvel agent ou logiciel supplémentaire ne sera nécessaire.
Une réponse aux nombreux problèmes de pilotes récents
Cette évolution n’arrive pas par hasard.
Depuis plusieurs années, Microsoft multiplie les problèmes liés aux pilotes distribués automatiquement :
pilotes Intel instables
conflits Wi-Fi/Bluetooth
BSOD après Patch Tuesday
pilotes GPU remplacés
incompatibilités OEM
Plus récemment, Microsoft a reconnu que Windows 11 pouvait remplacer des pilotes graphiques installés manuellement par des versions plus anciennes provenant de Windows Update.
Windows 11 downgrade parfois les pilotes graphiques
Le problème concerne surtout les pilotes GPU :
NVIDIA
AMD
Intel Arc
Des utilisateurs installent un pilote récent depuis le site du fabricant, mais Windows Update peut ensuite réinstaller automatiquement une version OEM plus ancienne.
Cela provoque parfois :
perte de performances
disparition de fonctionnalités
incompatibilités
bugs graphiques
régressions de jeux
Le phénomène existe depuis longtemps, mais Microsoft admet désormais officiellement le problème.
Cependant, Windows Update détecte ensuite qu’un autre pilote provenant de son catalogue OEM — ici la version 32.0.101.7085 — est considéré comme « mieux adapté » au matériel selon son système de ciblage matériel CHID.
Windows remplace alors automatiquement le pilote installé manuellement par cette autre version lors d’une mise à jour de pilotes.
L’utilisateur pense donc que son pilote n’a pas été correctement mis à jour et réinstalle à nouveau la version proposée par DriversCloud. Quelques jours plus tard, Windows Update effectue une nouvelle rétrogradation, créant ainsi une boucle de mises à jour entre deux versions différentes du pilote graphique.
Ce comportement illustre précisément le problème reconnu récemment par Microsoft concernant les downgrades automatiques de pilotes graphiques via Windows Update.
Microsoft prépare une correction pour le ciblage des pilotes
Microsoft explique que le problème vient notamment du système de ciblage matériel des pilotes Windows Update (CHID).
Le système actuel peut considérer qu’un pilote OEM plus ancien est “mieux adapté” qu’une version plus récente installée manuellement.
Pour corriger cela, Microsoft prépare un nouveau modèle de ciblage plus précis afin d’éviter les downgrades involontaires. Un pilote récent installé manuellement devrait donc être moins facilement remplacé à l’avenir.
Le déploiement progressif des nouvelles règles est prévu entre 2026 et 2027.
Windows Update devient de plus en plus autonome
Avec Cloud-Initiated Driver Recovery, Microsoft poursuit l’évolution de Windows Update vers un système capable de gérer lui-même une partie des problèmes logiciels et matériels. L’objectif est de limiter les situations où un pilote défectueux peut rendre un PC instable pendant plusieurs jours en attendant une intervention manuelle.
Windows 11 intègre déjà de nombreux mécanismes automatiques de réparation, de rollback et de vérification de compatibilité. Désormais, Microsoft veut également pouvoir réagir rapidement côté cloud lorsqu’un pilote problématique est détecté à grande échelle.
Cette approche s’inscrit dans une évolution plus large de Windows Update, qui devient progressivement une plateforme centralisée de maintenance capable de corriger certains problèmes sans action de l’utilisateur ou du constructeur.
Sous Windows et Linux, les SSD, disques durs et périphériques USB utilisent un cache disque afin d’améliorer les performances des lectures et écritures.
Le cache d’écriture permet notamment d’accélérer les copies de fichiers, mais peut aussi provoquer des pertes de données ou des corruptions de fichiers en cas de coupure électrique ou de débranchement USB brutal.
Dans ce guide, vous apprendrez comment fonctionne le cache disque et le cache d’écriture sous Windows et Linux, leurs avantages, leurs risques et comment éviter les corruptions disque.
Les données sont temporairement stockées en mémoire RAM
Le cache d’écriture accélère les copies de fichiers
Une coupure électrique ou un retrait USB brutal peut provoquer une corruption de données
Sous Windows, le mode “Suppression rapide” limite les risques sur les clés USB
Le cache disque est utile, mais nécessite d’utiliser correctement l’éjection sécurisée USB.
Qu’est-ce que le cache disque
Le cache disque est une mémoire temporaire utilisée par le système d’exploitation ou le périphérique de stockage afin d’accélérer les lectures et écritures sur un disque dur, un SSD ou une clé USB.
Lorsqu’un fichier est lu ou écrit :
Les données peuvent être temporairement stockées en mémoire
Puis écrites plus tard sur le disque physique
Ou conservées afin d’accélérer les accès suivants
Le cache disque permet ainsi :
D’améliorer les performances
Réduire les accès physiques au disque
Accélérer les copies de fichiers
Limiter les temps d’attente
Le tableau ci-dessous résume les principaux types de cache disque.
Type de cache
Fonction
Cache en lecture
Accélère l’ouverture des fichiers fréquemment utilisés
Cache en écriture
Stocke temporairement les écritures avant transfert sur le disque
Cache matériel du disque
Mémoire intégrée au SSD ou disque dur
Cache système Windows/Linux
Cache géré par le système d’exploitation
Sous Windows et Linux, le cache disque est utilisé :
Sur les SSD
Les disques durs HDD
Les clés USB
Les disques externes
Même si le cache améliore les performances, il peut aussi provoquer :
Une perte de données
Une corruption du système de fichiers
Des erreurs disque
si le périphérique est débranché brutalement avant la fin des écritures.
À quoi sert le cache disque ?
Le cache disque permet d’améliorer les performances des périphériques de stockage en réduisant les accès directs au disque dur, SSD ou périphérique USB.
Sans cache disque :
Chaque lecture ou écriture serait effectuée directement sur le support physique
Les performances seraient beaucoup plus faibles
Les temps d’accès augmenteraient fortement
Le cache disque sert principalement à :
Accélérer les lectures de fichiers
Améliorer les vitesses d’écriture
Réduire les accès physiques au disque
Limiter les temps d’attente
Optimiser les performances du système
Le tableau ci-dessous résume les principaux avantages du cache disque.
Les données peuvent être d’abord écrites dans le cache RAM
Puis transférées ensuite sur le disque physique
C’est pour cette raison qu’un périphérique USB peut sembler avoir terminé une copie alors que certaines écritures sont encore en attente en arrière-plan.
Comment fonctionne le cache disque sous Windows et Linux ?
Le cache disque fonctionne comme une mémoire tampon entre le système d’exploitation et le périphérique de stockage.
Au lieu d’écrire ou lire directement chaque donnée sur le disque physique :
Windows ou Linux stocke temporairement les données dans le cache
Puis les transfère ensuite vers le SSD, disque dur ou périphérique USB
Cela permet :
D’accélérer les accès disque
Réduire les temps de latence
Limiter les accès physiques au disque
Améliorer les performances générales
Le cache disque peut fonctionner :
En lecture
En écriture
Ou les deux
Cache en lecture
Le cache en lecture conserve temporairement les fichiers ou données récemment utilisés afin d’accélérer les accès suivants.
Par exemple :
Lorsqu’un programme ou fichier est ouvert plusieurs fois
Les données peuvent être relues directement depuis le cache RAM
Sans accéder de nouveau au disque physique
Cela améliore :
Les temps de chargement
La réactivité du système
Les performances des applications
Cache en écriture
Le cache en écriture stocke temporairement les données avant leur écriture réelle sur le disque.
Par exemple :
Lors d’une copie de fichiers
Windows écrit d’abord les données en mémoire
Puis les transfère ensuite vers le périphérique de stockage
Cette méthode permet :
D’accélérer les copies
Réduire les accès disque
Améliorer les performances USB et SSD
Tant que les données restent dans le cache :
Elles ne sont pas encore totalement enregistrées sur le disque
Une coupure électrique ou un débranchement USB peut provoquer une corruption de fichiers
Différence entre write-back et write-through
Le tableau ci-dessous résume les deux principales stratégies de cache d’écriture.
Mode de cache
Fonctionnement
Write-back
Les données sont d’abord écrites dans le cache puis plus tard sur le disque
Write-through
Les données sont écrites immédiatement sur le disque physique
Le mode write-back :
Offre de meilleures performances
Mais augmente les risques de perte de données
Le mode write-through :
Est plus sécurisé
Mais légèrement moins performant
Sous Windows, les stratégies :
Suppression rapide
et Meilleures performances
utilisent justement ces mécanismes de cache disque.
Différence entre cache disque et mémoire RAM
Le cache disque et la mémoire RAM sont liés, mais ils ne jouent pas exactement le même rôle sous Windows ou Linux.
La mémoire RAM sert à stocker temporairement :
Les programmes en cours d’exécution
Les données utilisées par le système
Les applications ouvertes
Le cache disque, lui, utilise souvent une partie de la RAM afin d’accélérer les accès au disque dur, SSD ou périphérique USB.
Le tableau ci-dessous résume les principales différences.
Élément
Rôle
Mémoire RAM
Stocker temporairement les programmes et données en cours d’utilisation
Cache disque
Accélérer les lectures et écritures disque
Cache en lecture
Conserver les fichiers récemment utilisés
Cache en écriture
Stocker temporairement les écritures avant transfert sur le disque
Par exemple :
Lors d’une copie de fichiers
Windows peut d’abord écrire les données dans le cache RAM
Puis transférer les données ensuite sur le disque physique
C’est pour cette raison :
Qu’un transfert peut sembler terminé alors que le disque travaille encore
Ou qu’un périphérique USB peut rester actif après une copie
La mémoire RAM est volatile : Son contenu disparaît après un redémarrage ou une coupure électrique
C’est pourquoi :
Une coupure brutale
Ou un débranchement USB pendant une écriture
peut provoquer :
Une perte de données
Une corruption du système de fichiers
Des erreurs disque.
Cache disque sur SSD, HDD et périphériques USB
Le cache disque est utilisé sur la plupart des périphériques de stockage :
Disques durs HDD
SSD
Clés USB
Disques externes USB
Mais son fonctionnement et son importance peuvent varier selon le type de support utilisé.
Le tableau ci-dessous résume les principales différences.
Périphérique
Utilisation du cache disque
Disque dur HDD
Très utilisé pour réduire les accès mécaniques
SSD
Utilisé pour améliorer les performances d’écriture
Clé USB
Cache souvent limité mais toujours présent
Disque externe USB
Dépend des paramètres Windows et du périphérique
Cache des disques durs HDD
Les disques durs mécaniques utilisent fortement le cache disque afin de :
Réduire les mouvements de la tête de lecture
Accélérer les accès aux fichiers
Améliorer les performances générales
Les HDD possèdent aussi :
Un cache matériel intégré
Généralement de quelques Mo à plusieurs centaines de Mo
Cache des SSD
Les SSD utilisent également le cache disque, mais de manière différente.
Le cache permet notamment :
D’accélérer les écritures
Réduire l’usure des cellules mémoire
Optimiser les performances du SSD
Certains SSD utilisent aussi :
Un cache DRAM
Ou un cache SLC
afin d’améliorer les vitesses de transfert.
Cache des clés USB et disques externes
Sous Windows, les clés USB et disques externes utilisent souvent :
Le cache système Windows
Les stratégies :
Suppression rapide
Meilleures performances
Avec :
Suppression rapide
Windows limite fortement le cache d’écriture
Meilleures performances
Les performances sont meilleures
Mais l’éjection sécurisée devient fortement recommandée
Débrancher brutalement un périphérique USB pendant une écriture peut provoquer :
Une corruption de fichiers
Une perte de données
Des erreurs du système de fichiers
Pourquoi le cache disque peut provoquer une perte de données
Le cache disque améliore les performances des SSD, disques durs et périphériques USB, mais il peut aussi provoquer une perte de données lorsque les écritures ne sont pas encore totalement enregistrées sur le disque physique.
Avec le cache en écriture :
Les données sont d’abord stockées temporairement en mémoire
Puis écrites ensuite sur le disque
Tant que cette écriture n’est pas terminée :
Les fichiers ne sont pas encore totalement sauvegardés
Une interruption peut corrompre les données
Le tableau ci-dessous présente les situations les plus fréquentes.
Situation
Risque
Débranchement brutal d’une clé USB
Corruption de fichiers
Coupure électrique
Perte des données en cache
Crash Windows ou Linux
Système de fichiers corrompu
Redémarrage forcé du PC
Écritures interrompues
Déconnexion d’un disque externe pendant une copie
Fichiers incomplets
Cache write-back actif
Risque accru de perte de données
Les symptômes les plus fréquents sont :
Fichiers corrompus
Erreurs NTFS ou EXT4
Messages CHKDSK ou fsck
Partition inaccessible
Clé USB non reconnue
Linux ou Windows qui refuse de démarrer
Risques avec les périphériques USB
Les clés USB et disques externes sont particulièrement sensibles :
Lors des copies de fichiers importantes
Avec le mode Meilleures performances
Si le périphérique est retiré sans éjection sécurisée
Même si Windows 11/10 utilise souvent : Suppression rapide
il reste conseillé :
D’attendre la fin des copies
D’éviter les débranchements brutaux
D’utiliser l’éjection sécurisée pour les disques externes importants
Limiter les risques de corruption disque
Pour éviter les pertes de données :
Utilisez l’éjection sécurisée USB
Évitez les coupures électriques
Utilisez un onduleur sur PC fixe
Sauvegardez régulièrement les fichiers importants
Vérifiez l’état de santé du disque
Les systèmes d’exploitations fournissent des utilitaires de réparation du système de fichiers :
Comme Windows, Linux utilise un cache disque afin d’améliorer les performances des SSD, disques durs et périphériques USB.
Sous Linux :
Les lectures et écritures disque peuvent être temporairement stockées en mémoire RAM
Puis transférées ensuite vers le disque physique
Le cache disque Linux permet notamment :
D’accélérer les accès aux fichiers
Réduire les accès physiques au disque
Améliorer les performances du système
Optimiser les écritures SSD et HDD
Le tableau ci-dessous résume les principaux mécanismes utilisés sous Linux.
Fonction Linux
Rôle
Page Cache
Cache des fichiers et données utilisés récemment
Buffer Cache
Cache des opérations disque bas niveau
Write-back cache
Écritures différées vers le disque
Sync
Force l’écriture immédiate des données sur le disque
Écritures différées sous Linux
Sous Linux, les écritures ne sont pas toujours immédiatement enregistrées sur le disque. Lors d’une copie de fichiers, les données peuvent rester temporairement en mémoire avant d’être écrites sur le disque physique.
C’est pour cette raison qu’un périphérique USB peut continuer à travailler après la fin apparente d’une copie et qu’un débranchement brutal peut provoquer une corruption du système de fichiers EXT4.
Vider le cache disque Linux
Linux permet de forcer l’écriture des données en attente avec :
sync
Cette commande demande au système :
D’écrire immédiatement les données du cache vers le disque
Elle peut être utile :
Avant de retirer une clé USB
Après une copie importante
Lors d’un dépannage Linux
Risques de corruption sous Linux
Comme sous Windows, une coupure électrique, un crash système ou un débranchement USB brutal peuvent provoquer une corruption du système de fichiers EXT4, une perte de données ou encore des erreurs disque sous Linux.
Comment vérifier ou modifier le cache disque sous Windows
Windows 11/10 permet de modifier la stratégie de cache d’écriture des SSD, disques durs et périphériques USB depuis le Gestionnaire de périphériques.
Dans la majorité des cas, il n’est pas recommandé de désactiver complètement le cache disque, car celui-ci améliore fortement les performances des SSD, disques durs et périphériques USB.
Le cache disque permet notamment :
D’accélérer les copies de fichiers
Réduire les accès physiques au disque
Améliorer les performances générales du système
Toutefois, dans certaines situations, réduire ou désactiver le cache d’écriture peut être utile :
Pour limiter les risques de corruption USB
Sur certains périphériques externes instables
En cas de problèmes d’éjection USB
Lors de coupures électriques fréquentes
Le tableau ci-dessous résume les avantages et inconvénients.
Configuration
Avantages
Inconvénients
Cache disque activé
Meilleures performances
Risque de perte de données en cas de coupure
Cache disque réduit
Plus sûr pour les périphériques USB
Performances légèrement inférieures
Meilleures performances
Copies plus rapides
Éjection sécurisée fortement recommandée
Suppression rapide
Retrait USB simplifié
Débits parfois plus faibles
Le cache disque est-il dangereux ?
Non, le cache disque améliore fortement les performances des SSD, HDD et clés USB. Les risques apparaissent surtout lors :
d’une coupure électrique
d’un retrait USB brutal
d’un crash système
Sous Windows 11/10, le mode Suppression rapide est souvent activé par défaut sur les périphériques USB, ce qui limite déjà fortement les risques de corruption lors du retrait d’une clé USB ou d’un disque externe.
Dans la majorité des cas, il est préférable de conserver le cache disque activé et d’utiliser correctement l’éjection sécurisée USB afin de profiter de meilleures performances tout en limitant les risques de perte de données.
Désactiver totalement le cache disque peut parfois :
Réduire fortement les performances
Augmenter les temps de copie
Ralentir certains SSD ou disques externes
Bonnes pratiques pour éviter les corruptions disque
Une corruption du système de fichiers peut provoquer :
Underscore revient sur une époque où les interfaces graphiques existaient péniblement. PDF est arrivé dans un contexte ou PostScript n'était pas adapté à un affichage multimachine. C'est dans ce contexte que l'entreprise Adobe a lancé le projet Camelot.
Depuis les années 90 le format Portable Document Format continue de perdurer. Avec le temps le format est nativement supporté dans la plupart des OS et navigateurs : il n'est plus nécessaire de passer à la caisse pour lire un PDF ni pour le construire. Windows propose nativement une imprimante virtuelle PDF, qui rappelle le lien qu'à ce format avec le monde de l'impression.
Guillaume Ayoub revient sur toute l'histoire de PDF :
PDF a fonctionné parce qu'il permet un affichage identique indépendamment de la machine, l'OS et la version du lecteur dans lequel s'ouvre le fichier. On ne peut pas en dire autant du format d'un fichier WORD qui évolue au fil des versions...
Le format PDF reste le format de fichier le plus populaire aujourd'hui, grâce à la gratuité d'Acrobat Reader (puis Adobe Reader). Les failles de sécurité autour du PDF sont nombreuses, cela reste un vecteur important de garder un logiciel à jour, notamment parce qu'il est possible d'exécuter des scripts (javascript) dans un PDF.
Ce vendredi dans De Quoi Je Me Mail, nous commentons l'actu avec Olivier Frigara fondateur du podcast "On refait le Mac" et Gonzague Dambricourt blogueur et entrepreneur.
Sommaire :
- Faut-il craquer pour l'iPhone 16e ? - On vous liste les bons et mauvais points
- Les échecs de la tech : Humane AI Pin, vélo Angell... #dqjmm
Lionel Costa, responsable du Labo Fnac, nous conseille sur l’achat d’enceintes actives stéréo. Quelles sont les spécificités du produit ? Les meilleurs modèles ? Comment choisir ?
Je viens de pousser en prod une fonctionnalité sur laquelle je bosse depuis quelques temps et comme je suis content du résultat, c'est le moment de partager ça avec vous.
En haut à gauche du site, juste à côté de l'icône qui change le thème, vous trouverez un petit bouton "abc" qui jusqu'à présent ne servait qu'à appliquer
une police spéciale dyslexique
à mon contenu. Mais j'ai amélioré un peu tout ça pour que maintenant niveau "Confort de lecture" vous soyez refait !
En cliquant donc sur cette icône, s'ouvre un petit panneau de config avec dedans de quoi configurer votre expérience de lecture aux petits oignons. Police adaptée pour la dyslexie, espacement variable, fond couleur crème, mode audio TTS, lignes colorées pour guider l'œil...etc tout ça sans dépendre d'un service tiers.
Ensuite, vos réglages sont conservés dans le localStorage de votre navigateur pour les retrouver à chaque visite et il y a un petit lien en bas de la fenêtre pour réinitialiser tout ça.
Maintenant, l'histoire derrière cette feature, parce qu'elle est intéressante. À la base j'étais parti pour recoder un équivalent du "
Bionic Reading
", vous savez ce truc à la mode qui met en gras le début de chaque mot pour soi-disant accélérer la lecture. J'avais déjà bien avancé quand je suis tombé sur une
étude scientifique de 2024
qui démontait complètement le concept. En gros, les chercheurs ont mesuré que cela ne produisait aucun effet positif sur la vitesse de lecture ni sur la compréhension. Que dalle...
Du coup, pivot complet... J'ai tout repris pour bâtir un système basé sur ce qui marche vraiment, avec un principe simple : Chaque option du panneau affiche un badge "Sci ✓" si elle est soutenue par la recherche, ou "Pref" si c'est une préférence subjective documentée. Comme ça vous savez sur quoi vous cliquez et on évite le marketing déguisé en science.
Côté polices donc, vous avez 4 choix. La police par défaut du site,
Lexend
qui est une "variable font" développée par la Dr. Bonnie Shaver-Troup avec des résultats publiés montrant une amélioration significative de la fluidité de lecture,
Atkinson Hyperlegible
créée par le Braille Institute spécifiquement pour les personnes malvoyantes, et enfin OpenDyslexic que j'avais déjà. Pour cette dernière, je l'ai mise avec un badge "Pref" parce que la communauté dyslexique l'apprécie mais les études sont moins solides scientifiquement.
Les sliders d'espacement permettent également de jouer sur trois axes : espace entre les lettres, hauteur de ligne, largeur de la colonne de texte. Tout est calibré pour être utile sans casser le rendu. Vous pouvez aussi activer un fond crème qui utilise la couleur Solarized base3 (c'est #FDF6E3, reconnue dans la communauté des dev pour son confort de lecture sur une longue durée), et le texte non-justifié qui évite les "rivières" blanches entre mots qui posent problème notamment aux dyslexiques.
Pour le guide visuel, je vous ai mis 2 options. "Lignes colorées" qui applique un gradient cosinus caractère par caractère sur chaque ligne, avec une palette noir-bleu-noir-rouge qui alterne et permet à l'œil de suivre naturellement la progression du texte.
Et ce que j'ai appelé Saccade que j'ai gardé en option, marqué d'un badge orange "Pref ⚠" parce que la science dit que ça sert pas à grand chose, mais que si vous aimez visuellement, bah au moins c'est dispo !
Et puis il y a le mode audio (TTS) qui dépend de la qualité des voix installées sur votre système. Y'a pas d'IA là dedans, donc ça peut donner une lecture robotique sur certains OS. Une fois activé, ça apparaît en haut des articles avec une estimation de durée. Ça utilise la Web Speech API native de votre navigateur, donc zéro service externe une fois encore et ça respecte la voix système que vous avez configurée.
À ma connaissance, je suis le seul à proposer ce niveau de personnalisation pour l'accessibilité. N'oubliez pas qu'au delà de la démarche, l'accessibilité numérique est devenu une obligation légale en Europe avec l'
European Accessibility Act
qui s'applique depuis juin 2025 (Qui en a entendu parlé ? Pas grand monde je pense).
En tout cas, si je peux me permettre ce luxe de bosser sur des trucs qui ne rapportent pas un kopeck mais qui rendent le site plus agréable et plus accessible, c'est uniquement grâce à
mes Patreons
.
Y'a des gens trop habitués à Linux, qui tapent htop par réflexe alors que sous Windows, la commande ne fait rien. Pour que ça fonctionne, faut installer WSL, configurer un sous-système Linux entier, et tout ça juste pour surveiller quelques processus... C'est un peu overkill comme on dit.
Mais heureusement, pstop arrive pour corriger ça !
Pstop est un moniteur système TUI pour Windows PowerShell, écrit en Rust, qui pèse ~1 Mo et qui tourne nativement sur Windows 10 et 11 sans aucune dépendance !
L'interface s'organise en quatre onglets : l'onglet principal avec CPU, mémoire et liste des processus, puis des onglets dédiés aux I/O disque, au réseau et au GPU. Le CPU y est affiché par cœur avec un code couleur pour distinguer le temps user, système et virtuel ce qui est très pratique je trouve pour repérer d'un coup d'œil si c'est votre code ou le kernel qui vous pompe les ressources.
Le réseau s'adapte en auto-scaling à la bande passante utilisée, et la liste des processus peut s'afficher en arborescence pour voir les relations parent/enfant. Par contre, l'onglet GPU sera vide si vous n'avez pas de GPU dédié.
Côté navigation, y'a F3 pour chercher, F4 pour filtrer, F2 pour changer de thème, F9 ou k pour tuer un processus....etc. Bref, les raccourcis F1-F10 suivent la convention htop, donc si vous avez la mémoire musculaire d'htop sous Linux, vous retrouverez vos marques immédiatement. Bon après, les vim keys sont disponibles aussi en option si vous êtes des geudins.
Pour l'installer :
# Via winget (le plus simple)
winget install marlocarlo.pstop
# Via cargo
cargo install pstop
Le projet est développé par le même dev derrière
psmux, le tmux natif pour Windows
que j'avais déjà couvert ici. Finalement, on dirait bien qu'il a décidé de rééquiper le terminal Windows en profondeur, et franchement c'est une bonne nouvelle pour tous ceux qui bossent sous PowerShell !
Par contre, pstop est Windows-only, x86_64 uniquement pour l'instant (pas d'ARM) et si vous cherchez un outil cross-platform pour Linux ou macOS,
btop++
reste bien sûr l'option de référence.
C'est sous licence MIT, en open source sur
GitHub
!
A malicious Hugging Face repository managed to take a spot in the platform's trending list by impersonating OpenAI's Privacy Filter open-weight model to deliver a Rust-based information stealer to Windows users.
The project, named Open-OSS/privacy-filter, masqueraded as its legitimate counterpart released by OpenAI late last month (openai/privacy-filter), including copying the entire description
Vous avez confiance dans le nom qui est affiché à côté d'un commit GitHub ?
Bah vous pouvez arrêter tout de suite car le chercheur Shani Lavi a documenté il y a quelques années ce que les devs Git sérieux savent depuis longtemps : N'importe qui peut publier un commit avec n'importe quelle identité, et bien sûr, on peut systématiquement compter sur GitHub pour lier ce commit au profil correspondant sans broncher.
Allez, petite démonstration récente... Sur le repo
no-as-a-service
, il y a par exemple un commit signé "torvalds" qui ajoute un témoignage humoristique de Linus Torvalds dans le README. L'avatar de Linus s'affiche, et GitHub considère ça comme un commit parfaitement valide. Sauf que Linus n'a évidemment jamais touché ce projet humoristique qui est une petite API qui sort des excuses créatives pour dire "non".
Et ce qui est fou, c'est que vous pouvez faire pareil en dix secondes, et c'est ce qu'on va faire ensemble. Mais avant...
Pourquoi Git laisse passer ça
Git, à la base, c'est un système distribué. Quand vous faites un commit, votre client local prend alors deux infos dans votre config : user.name et user.email. Ces deux champs sont libres, et jamais validés côté client. Vous pouvez donc écrire ce que vous voulez dedans, et Git s'en fiche.
Côté GitHub, l'attribution se fait par l'email. Le service regarde alors l'email présent dans les métadonnées du commit, le compare aux emails enregistrés sur les comptes, et affiche le profil + l'avatar Gravatar correspondant. En fait, il n'y a aucune vérification que la personne qui a poussé le commit possède réellement cette adresse email.
Du coup, n'importe qui qui connaît votre email public (et il est public si vous avez déjà commit en clair sur un repo) peut publier des commits avec votre identité affichée.
Étape 1 : Reproduire le spoofing (à but pédagogique évidemment)
Avant de paniquer, faisons l'exercice nous-mêmes pour bien comprendre. Dans un repo de test que vous contrôlez :
# 1. Visualiser un commit cible pour récupérer name + email
git log --format='%an <%ae>' | head -3
# 2. Reconfigurer Git avec une fausse identité
git config --global --replace-all user.name "Linus Torvalds"
git config --global --replace-all user.email "[email protected]"
# 3. Vérifier la config
git config --global --list | grep user
# 4. Faire un commit normal
echo "Hello from Linus" >> README.md
git add README.md
git commit -m "Important kernel fix"
# 5. Pousser sur votre repo
git push origin main
Allez voir le commit sur GitHub. Vous verrez l'avatar de Linus, son nom cliquable qui mène vers son profil, et surtout aucun avertissement. Pas de mot de passe demandé ni de token compromis... non, non, non, c'est juste une config locale modifiée.
Et si quelqu'un fait un fork de votre repo, ou si un mainteneur peu attentif valide un PR sur cette base, l'illusion est complète.
Étape 2 : Repérer un commit douteux
Pour ça, le badge Verified reste l'indicateur le plus utile. À côté du SHA d'un commit, GitHub affiche surtout une étiquette verte "Verified" si le commit est cryptographiquement signé avec une clé GPG ou SSH enregistrée sur le compte de l'auteur. Sinon, y'a rien du tout (par défaut). Attention quand même, l'absence de badge ne veut pas dire qu'un commit est malveillant mais juste qu'on ne peut pas garantir qui l'a écrit.
Par exemple, si vous regardez le commit e6b4218 sur no-as-a-service, vous remarquerez l'absence totale de badge. C'est le signal mais il faut encore savoir le chercher car par défaut, GitHub n'affiche AUCUN avertissement pour les commits non signés. C'est surtout ça le problème...
Étape 3 : Signer vos commits avec SSH
Alors pour vous protéger de ça, ça commence chez vous. Plus simple que GPG, la signature SSH utilise une clé que vous avez probablement déjà. Générez une clé Ed25519 si ce n'est pas fait :
Dernière étape, ajoutez votre clé publique sur GitHub dans Settings → SSH and GPG keys (1), mais cette fois en sélectionnant le type Signing Key (pas Authentication Key, c'est différent) (2). Vos prochains commits afficheront le badge "Verified" en vert.
Si vous préférez GPG, le principe est identique avec gpg.format gpg et une clé GPG. Pour le détail GPG complet, j'avais déjà couvert le sujet dans
le tuto sur Thunderbird et GPG
.
Étape 4 : Activer Vigilant Mode
Là, on passe à l'offensive. Vigilant Mode (3) force GitHub à afficher un statut sur tous vos commits. Les signés deviennent "Verified", les non signés deviennent "Unverified" en gros et bien visible. Plus de zone grise comme ça.
Direction même endroit dans Settings → SSH and GPG keys → Vigilant mode → Flag unsigned commits as unverified. Cochez la case. À partir de là, n'importe quel commit que GitHub vous attribue (via votre email vérifié) sans signature sera affiché comme "Unverified", ce qui rend le spoofing beaucoup plus difficile à dissimuler. Petite limite par contre, ça ne protège que votre propre identité et pas celle des contributeurs qui n'ont pas activé le mode.
La position de GitHub (et pourquoi je trouve ça discutable)
GitHub considère ce comportement comme un non-bug. Sur leur page bug bounty, l'usurpation par email Git est explicitement listée comme ineligible. Leur argument c'est que ça ne donne pas accès aux repos ni de privilèges supplémentaires, donc ce n'est pas une faille au sens strict.
Sauf que dans la vraie vie, l'identité affichée influence les décisions. Par exemple, un mainteneur qui voit un PR signé d'un contributeur connu va l'examiner avec moins de paranoïa, un journaliste qui couvre un scandale va citer "le commit de tel développeur" sans vérifier la signature, et combiné à d'autres vecteurs, ça peut devenir redoutable ! Je pense surtout aux
attaques supply chain récentes type Shai-Hulud
où une fois le code piégé, l'attribution Git aide à le faire passer pour légitime.
Bref, dire "ce n'est pas un bug" parce qu'il faut un autre vecteur derrière, c'est un peu facile, je trouve. Voilà, donc ne comptez pas sur Github pour vous défendre et signez vos commits, activez Vigilant Mode, et apprenez à vos collègues et amis dev à vérifier le badge "Verified" avant de merger quoi que ce soit en venant d'un inconnu... même si c'est ce bon cher Linus qui propose de réécrire le kernel en Rust avec systemd intégré ^^.
Le chercheur en sécu Hyunwoo Kim vient de lâcher dans la nature Dirty Frag, un nouvel exploit kernel Linux qui enchaîne 2 vulnérabilités pour obtenir un accès root sur n'importe quelle distro majeure, avec un taux de réussite proche de 100%.
L'embargo devait tenir encore quelques semaines. Il n'a pas tenu.
Et problème (et c'est pour ça que je vous en parle) c'est que ça marche du feu de dieu, et que personne n'a encore de patch disponible !! Alerte rouge donc !!
La lignée "Dirty" a donc maintenant quatre membres.
Dirty COW
en 2016, avec ses 9 ans de présence silencieuse dans le kernel avant d'être découvert, Dirty Pipe en 2022,
Copy Fail
dont je vous parlais il y a tout juste 8 jours, découvert par une IA. Et maintenant Dirty Frag, qui s'appuie sur le même principe que Copy Fail tout en contournant sa mitigation connue.
Alors comment ça marche ?
Le concept du truc c'est l'abus d'un mécanisme tout à fait légitime du kernel Linux : splice(). Cette fonction permet de faire circuler des données entre deux descripteurs de fichiers sans les copier en mémoire. C'est très utile, très performant, mais dans certaines configurations, c'est surtout très catastrophique.
Dirty Frag exploite les modules réseau d'IPsec (ESP) et du protocole RxRPC, ainsi quand un attaquant utilise splice() pour faire passer une page du cache mémoire (disons, /usr/bin/su) dans un buffer réseau, le kernel effectue son chiffrement directement sur cette page en RAM et sans faire de copie.
Résultat, les premiers octets de /usr/bin/su en mémoire sont remplacés par du code malveillant qui ouvre un shell root. Un simple appel à su ensuite, et l'attaquant est root.
Deux CVE sont impliqués dans la chaîne. CVE-2026-43284 qui concerne les modules esp4 et esp6 et qui a été patchée depuis hier et CVE-2026-43500 qui concerne rxrpc et pour celle-ci, y'a aucun patch actuellement à l'heure où j'écris ces lignes.
Le fait de chainer les 2 exploits permet à chacun de combler les angles morts de l'autre. C'est un peu technique mais en gros, la variante ESP requiert les droits de créer un namespace utilisateur, ce qu'Ubuntu peut bloquer via AppArmor. Alors que de son côté, la variante RxRPC ne nécessite pas ce privilège, mais le module rxrpc.ko n'est chargé par défaut que sur... Ubuntu. Du coup, une fois combinés, ils couvrent toutes les distros majeures sans exception.
Hyunwoo Kim a reporté la faille aux mainteneurs des distribs le 30 avril dernier, avec un accord de divulgation coordonnée via [email protected]. Mais un tiers extérieur (appelons le "connard" ^^) a brisé l'embargo hier, d'où la publication immédiate du PoC, avec l'accord des maintainers, pour éviter qu'un exploit silencieux circule sans que personne soit prévenu.
Les versions testées et confirmées vulnérables sont donc Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, Fedora 44.
En gros, si vous avez un kernel compilé depuis début 2017, vous êtes dans le scope.
Tester avec Lima sur macOS
Si vous voulez reproduire ça dans un environnement contrôlé, l'idée c'est de lancer une Ubuntu 24.04 avec le kernel non patché et de faire comme ceci :
Et si tout se passe bien, vous obtenez alors un shell root sans faire paniquer le kernel comme chez moi ici :
Après le test, le page cache est contaminé donc avant de faire quoi que ce soit d'autre, faut le nettoyer. :
echo 3 > /proc/sys/vm/drop_caches
Ou plus simple, redémarrez la machine car la modification est uniquement en RAM, donc un reboot permet de repartir de zéro.
Alors que faire ?
Hé bien, comme aucun patch n'est disponible pour la plupart des distros à l'heure où j'écris ces lignes, vous pouvez vous mettre en boule et pleurer. Sauf si vous êtes sous AlmaLinux car eux ont déjà poussé des kernels corrigés. Après vous pouvez aussi sécher vos larmes si vous êtes sur une autre distro, et suivre cette remédiation qui vous prendra trente secondes :
Cette commande fait trois choses : elle blackliste les modules vulnérables pour qu'ils ne se rechargent pas au prochain boot, elle les décharge s'ils sont actifs, et elle nettoie le page cache au cas où il serait déjà corrompu.
Après c'est tranquille à faire car esp4, esp6 et rxrpc ne sont pas des modules que la plupart des machines desktop utilisent au quotidien. Les désactiver n'a donc aucun impact visible sur 99% des setups. Mais un serveur qui fait du VPN IPsec en mode transport ESP, lui, sera affecté...
En tout cas, surveillez ça de près car une fois que votre distro sortira le patch, faudra mettre à jour et rebooter.
On se retrouve pour le débriefing complet de ce CKOIKIDI #101 du 6 mai 2026, vu que vous aimez ce petit compte rendu.
J'ai préparé ma veille moi-même car, pour l'anecdote, Gemini a complètement déliré en me racontant n'importe quoi sur les versions logicielles. Voici les actus qu'on a abordées qui ont attirés mon attention.
1. Ubuntu 26.04 LTS "Resolute Raccoon"
La grosse nouvelle de ce mois d'avril est la sortie, le 23 avril, de la version 26.04 LTS, baptisée Resolute Raccoon.
C'est une version à long terme supportée pendant 5 ans, mais vous pouvez monter jusqu'à 12 ans de support avec Ubuntu Pro, qui est gratuit pour les particuliers, jusqu'à 5 machines.
On y retrouve Gnome 50, ce qui signifie qu'on passe en 100 % Wayland par défaut, sans session X11 possible. Le système embarque le noyau Linux 7.0 et, pour la sécurité, propose le chiffrement complet du disque via la puce TPM, rendant le déverrouillage transparent au boot comme Windows 11.
Autre changement profond : les outils de base (ls, cd, sudo) sont désormais écrits en Rust ! (Pour ceux qui viennent de la précédente LTS, on a toutes les évolutions des versions intermédiaires.
Je continue de conseiller Ubuntu aux débutants car elle gère parfaitement le Secure Boot, les pilotes Nvidia signés et les codecs dès l'installation. Concernant les Snaps, j'arrête de râler car ils ont fait des progrès fulgurants : même sur une machine avec seulement 4 Go de RAM, Firefox se lance désormais sans aucune lenteur ! Ils ont l'avantage de présenter des mises à jour pour les applis graphiques (LibreOffice) ce qui permet de garder une base stable du système avec des logiciels qui évoluent.
2. Fedora Linux 44
On enchaîne avec Fedora 44, sortie le 28 avril, qui propose une expérience Gnome 50 très pure, sans les extensions ajoutées par Ubuntu. L'édition KDE Plasma 6.6 est particulièrement soignée avec l'arrivée du Plasma Login Manager (PLM) qui remplace l'historique SDDM pour une meilleure intégration Wayland sans oublier l'assistant de premier démarrage. Pour les gamers, le module noyau NTSync est activé par défaut, ce qui booste les performances des jeux Windows lancés via Steam ou Wine. Fedora reste fidèle à sa réputation de vitrine technologique, bien que livrée avec le noyau 6.19, le 7.0 arrivera d'ici quelques jours dans les dépôts
Vous le savez, je suis contributeur du projet et j'utilise cette version 44 sur ma propre machine depuis février. Un bémol cependant : Fedora consomme souvent deux fois plus de RAM qu'Ubuntu sur une installation fraîche, et je continue de forcer le système en EXT4 car je trouve le BTRFS par défaut encore un peu lent sur les SSD surtout d'entrée de gamme !
3. Linux Mint : Ralentissement du développement
Les nouvelles du blog officiel de Linux Mint nous apprennent que le développement ralentit pour se concentrer sur des chantiers de fond très lourds. La prochaine version majeure, Mint 23, n'arrivera qu'à Noël 2026, car l'équipe doit unifier l'installeur "Live Installer" avec celui de la version Debian. Ils travaillent aussi d'arrache-pied sur le support de Wayland pour Cinnamon, mais ce ne sera probablement pas stable avant la version 24 en 2028. En attendant, ils proposent des images ISO HWE (Hardware Enablement) pour permettre l'installation sur du matériel récent avec des noyaux plus frais comme le 6.17
Vous le savez, j'ai un énorme coup de cœur pour la version LMDE (Linux Mint Debian Edition) car les mises à jour de Cinnamon y arrivent en continu, un peu comme une rolling release, ce qui est à l'étude pour la Linux Mint classique avec la suggestion de mettre les mises à jour au fil de l'eau des outils et de l'environnement de bureau, au lieu de faire des versions intermédiaires (comme la 22.1 22.2 22.3 etc.). Je pense d'ailleurs que les changements imposés par Ubuntu (comme le passage à Rust pour les utilitaires de base) agacent tellement l'équipe de Mint qu'ils finiront par abandonner la base Ubuntu pour ne garder que Debian.
. 4. Alma Linux 9.8 et migration vers la version 10 x86_64_v2
La version 9.8 Beta d'Alma Linux est sortie, apportant Python 3.14 et des mises à jour pour MariaDB 10.8 et PostgreSQL 18 en tant que module. L'info importante aussi est la mise à jour de l'outil Elevate, qui permet désormais de migrer d'Alma 9 vers la version 10 tout en restant sur l'architecture x86_64_v2. C'est une décision majeure car Red Hat Enterprise Linux 10 impose l'architecture v3, ce qui peut rendre obsolètes des serveurs plus anciens. Alma Linux a même recompilé une partie du dépôt EPEL pour garantir la compatibilité avec ces processeurs v2.
En tant que contributeur, je salue cette démarche exemplaire contre l'obsolescence programmée des serveurs. Offrir un support jusqu'en 2035 sur du matériel ancien, c'est la preuve qu'Alma Linux est la distribution la plus pragmatique pour les entreprises aujourd'hui, tout en ayant un support de 10 ans.
5. Ubuntu et sa stratégie sur l'IA
Canonical a profité du lancement de la 26.04 pour clarifier sa position sur l'intelligence artificielle ! Leur stratégie repose sur une approche mesurée, privilégiant des modèles ouverts et des outils open source plutôt que des API fermées. Ils distinguent les fonctions "implicites" (comme la synthèse vocale sous le capot) des fonctions "explicites" centrées sur l'utilisateur. Le point important à retenir est que l'inférence se fera localement sur la machine, garantissant la confidentialité des données.
Je suis quand même en partie rassuré de voir qu'ils ne cèdent pas à la mode de la "cloudification" totale de l'IA. J'apprécie aussi que dans l'annonce Canonical évalue ses ingénieurs sur la qualité de leur code et non sur la quantité d'IA qu'ils ont utilisée pour le produire. Donc on peut espérer que l'IA sera utilisée un outil, comme l'a été le moteur de recherche il y a 20 ans !
6. Microsoft libère le code de 86-DOS 1.0 !
Pour le 45e anniversaire de 86-DOS 1.0, Microsoft a publié le code source original sous licence MIT sur GitHub https://github.com/DOS-History/Paterson-Listings .Ce corpus inclut les sources du noyau, les instantanés de développement de PC DOS 1.0 et des utilitaires comme CHKDSK. C'est un véritable travail d'archéologie numérique qui a été mené par des historiens pour scanner et retranscrire ces listings en assembleur. Cette démarche fait suite à l'ouverture de MS-DOS 4.0 et du Basic 6502 l'année dernière.
Même si je ne suis pas développeur assembleur, je trouve que c'est un geste formidable pour la préservation de l'histoire de l'informatique. C'est une plongée fascinante dans le passé qui montre que même les géants comme Microsoft commencent à jouer le jeu de l'ouverture pour le patrimoine numérique !
7. Kdenlive 26.04
Première version de 2026 de Kdenlive est arrivé avec un nombre record de nouveaux contributeurs ! Parmi les nouveautés, on trouve la duplication de la sortie moniteur vers un écran secondaire externe, très pratique pour le montage collaboratif. Les transitions bénéficient maintenant d'une prévisualisation animée dans la liste des effets avant même de les appliquer. Les boîtes de réglages acceptent désormais les expressions mathématiques (on peut taper "1920/2" au lieu de calculer soi-même). Enfin, l'accélération ou le ralentissement de plusieurs clips simultanément est désormais possible !
C'est mon outil de montage vidéo quasi quotidien, toutes mes vidéos YouTube sont montées avec Kdenlive depuis des années. Même si l'interface peut sembler intimidante au début, c'est pour moi le meilleur logiciel de montage libre, et je continue de l'utiliser en anglais pour mieux suivre les tutos sur le net !
8. Firefox 150 : Des nouveautés en pagaille
Firefox 150 améliore la fonctionnalité SplitView, permettant de mettre deux onglets côte à côte dans la même fenêtre. On peut désormais partager plusieurs URL simultanément et l'éditeur de PDF intégré permet de réorganiser les pages. Mozilla lance également son propre dépôt RPM officiel pour faciliter l'installation sur Fedora, RHEL ou Mageia qui pour cette dernière utilise par défaut la version ESR. Le VPN gratuit (limité à 50 Go) est désormais étendu aux utilisateurs canadiens, après la France et l'Allemagne notamment.
L'arrivée du dépôt RPM est une décision stratégique géniale, surtout pour RHEL 10 qui ne propose plus Firefox par défaut. Concernant le SplitView, Firefox rattrape son retard sur Vivaldi, même si je reste sur Vivaldi pour ma part car il permet de juxtaposer jusqu'à quatre onglets, ce qui est indispensable pour gérer mes différents chats en live par exemple !
9. Scaleway remporte l’hébergement des données de santé
Après sept ans de polémiques, le Health Data Hub (renommé PDS pour Plateforme des données de santé) quitte Microsoft Azure pour l'hébergeur français Scaleway. Ce choix fait suite à un appel d'offres rigoureux de l'UGAP, impliquant la Dinum et le ministère de la Santé avec plus de 350 critères techniques. C'est une étape importante pour sortir ces données sensibles de la juridiction du Cloud Act américain.
On prouve enfin qu'on peut confier nos données les plus précieuses à des acteurs locaux comme la société de Xavier Niel. A titre perso, j'avais trouvé leurs tarifs un peu chers (par rapport à IONOS qui héberge aussi en France le site Linuxtricks), je ne sais pas ce qu'il en est pour l'offre des données de santé, vis à vis de Microsoft, mais la souveraineté à un côut, et c'est une bonne chose que ça reste en France.
10. La FRANCE fournira un cloud souverain à l'UE
Un consortium français composé d'OVHcloud, Clever Cloud et Luxembourgeois pour Deep a remporté un marché de 180 millions d'euros pour fournir des services cloud à l'Union Européenne. OVH gère la capacité de déploiement, Clever Cloud apporte les outils d'architecture hybride et Deep s'occupe de la cybersécurité. L'objectif de la Commission Européenne est de renforcer sa résilience en évitant la dépendance aux acteurs uniques américains. C'est une étape symbolique forte puisque 80 % du marché numérique européen est actuellement capté par les États-Unis
On arrête de dire que la France est nulle en informatique ; on est sur le devant de la scène avec des solutions robustes et crédibles face aux GAFAM !
11. Faille de sécu Linux copy.fail (CVE-2026-31431)
Une vulnérabilité critique nommée Copy.fail a été découverte, permettant à n'importe quel utilisateur local de devenir root instantanément. Cette faille, présente dans le noyau depuis 2017, a touché des millions de serveurs avant d'être corrigée en urgence début mai. J'ai publié une vidéo et surtout un long article technique détaillé car je n'ai trouvé aucun contenu sérieux en français sur le sujet. https://www.linuxtricks.fr/news/10-logiciels-libres/600-copy-fail-cve-2026-31431-synthese-technique-sur-cette-faille-linux/
J'ai passé mon dimanche à étudier cette faille au lieu de faire ma déclaration d'impôts, mais ça en valait la peine tant le sujet est passionnant !
Merci à toutes et à tous d'avoir suivi ce 101e épisode !
On se retrouve le 3 juin pour le prochain live actu.
Connexion
Le cache disque améliore les performances
Une coupure électrique ou un retrait USB brutal peut provoquer une corruption de données
Il est important de s’assurer que vos disques n’ont pas de défaillance matériel via 
