Microsoft prépare un changement important pour la sécurité de Windows 11. À partir du Patch Tuesday d’octobre 2026, l’entreprise commencera à activer automatiquement l’intégrité de la mémoire sur les PC compatibles où cette protection est encore désactivée.

Cette fonction, aussi appelée HVCI (Hypervisor-Protected Code Integrity), existe depuis plusieurs années. Elle utilise la sécurité basée sur la virtualisation (VBS) pour mieux protéger le noyau de Windows contre les pilotes malveillants ou vulnérables.

Jusqu’ici, l’intégrité de la mémoire était surtout activée par défaut sur les installations propres de Windows 11 et certains PC compatibles. Microsoft veut désormais combler l’écart avec les machines mises à niveau au fil des années, où la protection peut être restée désactivée.

Qu’est-ce que l’intégrité de la mémoire ?

L’intégrité de la mémoire est une fonction de sécurité de Windows basée sur la virtualisation.

Elle utilise l’hyperviseur de Windows pour créer un environnement isolé du reste du système. Cet environnement sert notamment à vérifier le code exécuté en mode noyau avant que Windows ne l’autorise à fonctionner.

Le principe est particulièrement important pour les pilotes, car ceux-ci disposent de privilèges très élevés.

Un pilote malveillant ou compromis peut potentiellement :

• modifier le noyau Windows ;
• contourner certaines protections de sécurité ;
• lire ou écrire dans des zones sensibles de la mémoire ;
• faciliter l’installation d’un rootkit ;
• permettre une élévation de privilèges.

Avec HVCI, Windows effectue les contrôles d’intégrité du code dans un environnement isolé protégé par l’hyperviseur.

Microsoft précise également que les pages mémoire du noyau ne peuvent devenir exécutables qu’après validation et que les pages exécutables ne peuvent pas être rendues accessibles en écriture.

À lire :

Quelle différence entre VBS et l’intégrité de la mémoire ?

Les deux termes sont souvent confondus.

VBS, pour Virtualization-Based Security, correspond à l’infrastructure générale de sécurité basée sur la virtualisation.

L’intégrité de la mémoire est l’une des fonctions qui s’appuie sur VBS.
On peut résumer le fonctionnement ainsi :

VBS peut également servir à d’autres protections de Windows.

Microsoft va étendre l’activation aux PC déjà installés

Jusqu’à présent, Microsoft activait automatiquement l’intégrité de la mémoire essentiellement sur les installations propres de Windows 11 remplissant les critères matériels nécessaires.

La documentation Microsoft précise même que la logique actuelle d’activation automatique ne s’applique pas aux mises à niveau d’appareils existants.

C’est précisément ce que Microsoft s’apprête à faire évoluer.

Selon WindowsLatest, le changement commencera avec la mise à jour de sécurité prévue pour le 13 octobre 2026.

Microsoft pourra alors activer automatiquement la protection sur certains PC éligibles où elle était restée désactivée après plusieurs années de mises à niveau de Windows.

Quels PC pourront recevoir l’activation automatique ?

Microsoft ne compte pas activer HVCI aveuglément sur toutes les machines.

Les critères matériels utilisés actuellement pour l’activation automatique donnent une bonne idée des PC concernés.

Microsoft indique notamment :

• processeur Intel de 8e génération ou plus récent ;
• processeur AMD basé sur Zen 2 ou plus récent ;
• Qualcomm Snapdragon 8180 ou plus récent ;
• au moins 8 Go de RAM sur les systèmes x64 ;
• SSD d’au moins 64 Go ;
• virtualisation matérielle activée dans l’UEFI/BIOS ;
• pilotes compatibles avec l’intégrité de la mémoire.

Les PC Secured-core sont quant à eux déjà livrés avec cette protection activée par défaut.

Microsoft vérifiera la compatibilité avant l’activation

Le point important est que Windows ne devrait pas simplement basculer l’interrupteur sur tous les PC correspondant à une liste de processeurs.

Selon WindowsLatest, Microsoft prévoit une évaluation de compatibilité préalable.

Windows vérifiera notamment si les pilotes actuellement installés sont compatibles avec l’intégrité de la mémoire.

Cette précaution est nécessaire, car les pilotes anciens constituent historiquement l’une des principales causes de problèmes avec HVCI.

Pourquoi certains pilotes peuvent poser problème

L’intégrité de la mémoire impose des règles plus strictes au code qui s’exécute dans le noyau.

Certains pilotes anciens ont été développés à une époque où ces restrictions n’existaient pas.

Ils peuvent par exemple effectuer des opérations mémoire que HVCI refuse désormais.
Dans ce cas, Windows peut bloquer le chargement du pilote.

Cela peut provoquer :

• un périphérique qui ne fonctionne plus ;
• un logiciel matériel qui perd certaines fonctions ;
• un utilitaire constructeur qui cesse de démarrer ;
• plus rarement, un problème au démarrage de Windows.

On peut alors aussi un message du type :

Impossible de charger un pilote sur cet appareil.
Pilote : XXXXXXX.sys
Un paramètre de sécurité détecte qu’il s’agit d’un pilote vulnérable et empêche le chargement.
Vous devez régler vos paramètres pour charger ce pilote.

Le guide :

Microsoft avertit officiellement que certaines applications et certains pilotes peuvent être incompatibles avec l’intégrité de la mémoire et que, dans de rares cas, cela peut même provoquer un écran bleu au démarrage.

Windows dispose toutefois d’un mécanisme de sécurité contre les échecs de démarrage

Microsoft a prévu un mécanisme destiné à éviter qu’un PC devienne inutilisable après l’activation automatique.

Lorsqu’elle est configurée avec les paramètres appropriés, l’intégrité de la mémoire peut être désactivée automatiquement si Windows détecte plusieurs échecs de démarrage consécutifs.

L’objectif est notamment de gérer le cas où HVCI empêcherait le chargement d’un pilote indispensable au démarrage du système.

Microsoft utilise pour cela plusieurs valeurs du Registre, notamment :

WasEnabledBy
EnabledBootId

associées à :

HKLM\System\CurrentControlSet\Control\DeviceGuard\
Scenarios\HypervisorEnforcedCodeIntegrity

Cette protection automatique n’est cependant active que pendant une période limitée après l’activation initiale.

Windows respectera les désactivations volontaires

Le changement ne signifie pas que Microsoft réactivera HVCI contre la volonté explicite de l’utilisateur ou de l’administrateur.

Selon WindowsLatest, si l’intégrité de la mémoire a été désactivée volontairement via :

• une stratégie de groupe ;
• Microsoft Intune ;
• une configuration du Registre ;

Windows Update doit respecter ce choix.

Microsoft indique d’ailleurs dans sa documentation que les utilisateurs et les administrateurs conservent le contrôle final sur l’activation de l’intégrité de la mémoire.

Windows 11/10 : désactiver l’isolation du noyau (intégrité de la mémoire) si elle ralentit le PC

Comment vérifier si l’intégrité de la mémoire est déjà activée

Vous pouvez facilement vérifier son état depuis Sécurité Windows.

• Ouvrez : Sécurité Windows > Sécurité de l’appareil > Détails de l’isolation du noyau
• Vous trouverez alors l’option : Intégrité de la mémoire qui indique si la protection est activée ou désactivée.

À partir de Windows 11 22H2, Sécurité Windows affiche également un avertissement lorsque cette protection est désactivée.

Comment identifier un pilote incompatible

Si un périphérique ou une application commence à dysfonctionner après l’activation de l’intégrité de la mémoire, il faut vérifier en priorité les pilotes.

Windows peut enregistrer les conflits dans l’Observateur d’événements.

WindowsLatest indique notamment de regarder dans : Journaux des applications et des services > Microsoft > Windows > CodeIntegrity > Operational
Les événements liés aux pilotes incompatibles peuvent notamment être associés à l’ID d’événement 3087.

Sécurité Windows peut également signaler directement certains pilotes incompatibles dans la page Isolation du noyau.

Pourquoi Microsoft active cette protection maintenant

La décision s’inscrit dans une stratégie plus large visant à renforcer la sécurité du noyau Windows.

Les attaques utilisant des pilotes vulnérables mais signés restent une méthode courante pour tenter d’obtenir un accès privilégié au noyau.

Cette technique est souvent appelée : BYOVD — Bring Your Own Vulnerable Driver

L’attaquant exploite alors un pilote légitime contenant une vulnérabilité afin de contourner certaines protections du système.

L’intégrité de la mémoire ne résout pas toutes les attaques de ce type, mais elle rend l’exploitation de certaines classes de vulnérabilités noyau beaucoup plus difficile.

WindowsLatest souligne également que les outils d’analyse assistés par intelligence artificielle permettent désormais de rechercher beaucoup plus rapidement des vulnérabilités complexes dans les composants bas niveau de Windows.

Faut-il désactiver l’intégrité de la mémoire ?

Dans la majorité des cas, non.

Si votre PC fonctionne normalement avec HVCI activé, il n’y a pas de raison particulière de le désactiver.

La protection apporte une couche supplémentaire contre les attaques visant le noyau et les pilotes.

Le principal motif de désactivation reste un problème de compatibilité avec un pilote ancien ou un logiciel spécifique.

Dans ce cas, il est préférable de rechercher d’abord :

• une mise à jour du pilote ;
• une nouvelle version du logiciel ;
• un pilote fourni directement par le constructeur ;
• une alternative au logiciel problématique.

La désactivation de l’intégrité de la mémoire devrait plutôt être considérée comme une solution temporaire de dépannage.

Qu’en est-il des performances ?

L’intégrité de la mémoire utilise la virtualisation matérielle et ajoute des contrôles supplémentaires lors de l’exécution de code en mode noyau.

Elle peut donc avoir un certain coût en performances selon le matériel et les charges de travail.

Sur les processeurs récents, Microsoft a cependant progressivement optimisé VBS et HVCI afin de limiter cet impact.
C’est aussi l’une des raisons pour lesquelles Microsoft applique des critères matériels avant l’activation automatique.

Sur une machine récente et compatible, l’impact est généralement beaucoup moins important que sur les premières générations de processeurs ayant pris en charge ces mécanismes.

Il ne faut toutefois pas présenter HVCI comme ayant strictement zéro impact sur les performances dans tous les scénarios.

Les anciens PC ne devraient pas être forcés

Si un PC ne respecte pas les critères techniques ou possède des pilotes connus comme incompatibles, Microsoft ne devrait pas activer automatiquement la protection.

Cela concerne notamment une partie des anciennes machines passées à Windows 11 par mise à niveau ou installées sur du matériel qui ne correspond pas aux critères d’activation automatique.

La stratégie ressemble donc davantage à « activer HVCI automatiquement lorsque Microsoft estime que le PC peut le supporter sans risque important » qu’à « forcer HVCI sur tous les PC Windows 11« .

Un changement relativement discret, mais important pour la sécurité

Pour de nombreux utilisateurs, le changement devrait passer totalement inaperçu.

Aucune nouvelle application ne sera installée et aucune nouvelle interface majeure n’apparaîtra.
Mais au niveau de la sécurité du système, le changement est significatif.

Microsoft cherche à faire en sorte qu’une protection qui existe déjà depuis plusieurs années soit réellement utilisée sur davantage de PC compatibles, notamment ceux ayant été continuellement mis à niveau plutôt que réinstallés proprement.

Conclusion

À partir d’octobre 2026, Microsoft commencera donc à activer automatiquement l’intégrité de la mémoire sur certains PC Windows 11 compatibles où elle était encore désactivée.

La fonction s’appuie sur VBS et HVCI pour isoler les contrôles d’intégrité du code et mieux protéger le noyau contre les pilotes malveillants ou vulnérables.

Microsoft ne devrait toutefois pas imposer aveuglément cette protection.

Windows vérifiera la compatibilité du matériel et des pilotes avant l’activation, et les configurations où HVCI a été volontairement désactivé devraient conserver ce choix.

Pour la majorité des utilisateurs disposant d’un PC récent, il est préférable de conserver l’intégrité de la mémoire activée.

En cas de problème après son activation, la priorité doit être de rechercher le pilote incompatible plutôt que de désactiver définitivement cette couche de sécurité.

L’article Windows 11 va activer automatiquement l’intégrité de la mémoire à partir d’octobre 2026 est apparu en premier sur malekal.com.

Trouver les causes des lenteurs d’un PC sous Windows 11 ou Windows 10 n’est pas forcément simple. Le problème peut être logiciel, avec trop de programmes au démarrage, de nombreux processus en arrière-plan ou des applications inutiles, mais aussi matériel, par exemple un disque dur ou SSD défaillant, une surchauffe ou une configuration trop limitée pour l’usage demandé.

Il n’est donc pas toujours évident de savoir par où commencer, ni de distinguer un PC simplement peu puissant d’un ordinateur réellement ralenti par un problème.

Heureusement, AnalysePC peut vous aider à orienter le diagnostic. L’outil croise plusieurs informations : état matériel, SMART des disques, températures, performances CPU/GPU/RAM/stockage, charge logicielle, nombre de processus, services, programmes au démarrage et temps de démarrage de Windows.

Il tient également compte du profil d’utilisation du PC afin de déterminer si la configuration est adaptée à de la bureautique, du multimédia, du gaming ou des usages plus exigeants.

Dans ce guide, vous allez voir comment utiliser AnalysePC pour identifier les causes probables des lenteurs, repérer un problème matériel prioritaire, vérifier si la configuration est suffisamment performante, détecter une surcharge logicielle et suivre les recommandations proposées pour améliorer la réactivité de Windows.

Lancer une analyse des performances avec AnalysePC

Voici comment effectuer l’analyse :

• Téléchargez MOC depuis ce lien :

• Décompressez-le dans le répertoire de votre choix
• Double-cliquez sur Launch-MOC
• Puis acceptez l’exécution en administrateur
• Dans le menu de MOC, appuyez sur 2 pour lancer l’analyse
• Cette analyse collecte différents éléments sur la configuration et l’état du système, puis les met en relation avec les résultats du StressTest afin d’obtenir une vue plus précise des performances réelles de la machine.
• Une fois l’Analyse 2 terminée, le rapport s’ouvre automatiquement sur votre navigateur internet

Vérifier les scores de santé et d’optimisation du PC

Avant d’analyser en détail les performances du processeur, de la mémoire ou du stockage, commencez par regarder les scores généraux affichés en haut du rapport AnalysePC.

Ils donnent une première indication sur la nature du problème :

• Optimisation : reflète surtout les éléments logiciels susceptibles d’alourdir Windows, comme les processus en arrière-plan, les programmes au démarrage ou certains réglages ;
• Santé matérielle : permet de repérer plus rapidement un problème matériel, par exemple un état SMART dégradé, des températures anormales ou d’autres indicateurs de fiabilité ;
• Stabilité : renseigne sur les problèmes pouvant affecter le bon fonctionnement général du système ;
• Sécurité : concerne l’état de la protection et les principaux réglages de sécurité. Il n’explique pas directement les lenteurs, mais il participe à l’évaluation générale du PC.

Le score global synthétise ces différents éléments, mais il ne faut pas se limiter à cette seule valeur. Ce sont surtout les sous-scores qui permettent de savoir vers quelle piste orienter le diagnostic.

Par exemple, un PC peut avoir une bonne optimisation mais une santé matérielle très faible. Dans ce cas, les lenteurs sont probablement davantage liées à un problème matériel qu’à un excès de logiciels ou de programmes au démarrage.

À l’inverse, un PC peut présenter une très bonne santé matérielle mais un score d’optimisation faible. Il faut alors examiner en priorité les processus, les programmes de démarrage, les services ou les logiciels qui consomment inutilement des ressources.

Cette première lecture permet donc de distinguer rapidement deux grandes familles de causes :

• problème matériel : disque, SSD, températures, fiabilité du matériel ;
• problème logiciel ou d’optimisation : trop de programmes, trop de processus, démarrage chargé ou configuration Windows peu optimale.

Une fois cette orientation obtenue, vous pouvez approfondir le diagnostic dans les sections suivantes, en commençant notamment par l’état SMART du disque ou SSD si la santé matérielle est dégradée.

Vérifier les problèmes matériels prioritaires

Vérifier l’état SMART du disque dur ou du SSD

Les informations SMART permettent de repérer des anomalies liées au support de stockage : erreurs de communication, secteurs réalloués, commandes expirées, usure du SSD ou autres indicateurs de fiabilité.

Dans AnalysePC, une défaillance importante peut déjà apparaître dans la section Problèmes à traiter sous la forme d’une alerte prioritaire, par exemple « Défaillance critique du disque physique ». Dans ce cas, il faut traiter ce problème avant de chercher à optimiser Windows ou à désactiver des programmes au démarrage.

La priorité est alors de :

• sauvegarder immédiatement les données importantes ;
• éviter les opérations inutiles sur le disque concerné ;
• consulter le détail SMART pour identifier l’anomalie ;
• prévoir le remplacement du support si la dégradation est confirmée.

Pour afficher les détails, ouvrez la section Matériel > État SMART des disques afin de connaître précisément le support concerné et les attributs problématiques.
AnalysePC affiche ensuite le détail de chaque disque avec plusieurs informations utiles : état global, température, durée de fonctionnement, éventuelles erreurs SMART et observations associées.

Il peut aussi arriver que Windows considère un disque comme Bon, alors que smartctl détecte malgré tout un attribut problématique. C’est justement l’intérêt de croiser plusieurs sources avant de conclure que le stockage est sain.

L’impact dépend également du rôle du disque concerné.

• Si le disque système C: est en défaillance, les conséquences peuvent toucher l’ensemble de Windows : temps de démarrage très longs, blocages, ouverture lente des applications, accès disque permanent ou ralentissements généraux.
• Si le problème concerne un disque secondaire, Windows peut rester relativement fluide, mais les fichiers, jeux ou applications installés sur ce disque peuvent devenir très lents à charger ou provoquer des blocages.

Il ne faut donc pas ignorer une alerte SMART, même si elle ne concerne pas le disque système.

Vérifier les températures et une éventuelle surchauffe

Si AnalysePC ne signale pas de problème SMART critique, vérifiez ensuite si les lenteurs peuvent être liées à une surchauffe du processeur ou de la carte graphique.

• Pour cela, ouvrez l’onglet Stress test, puis la section Températures et refroidissement.

AnalysePC y affiche notamment :

• la température maximale du CPU et du GPU ;
• le Hot Spot de la carte graphique lorsqu’il est disponible ;
• la charge moyenne pendant le test ;
• l’évolution des fréquences sous charge ;
• la vitesse de montée en température ;
• la capacité du système à refroidir les composants après le test ;
• d’éventuels indices de limitation thermique ou de baisse de fréquence.

La capture ci-dessus montre par exemple un processeur ayant atteint 92 °C sous forte charge. AnalysePC signale alors une température CPU élevée et une baisse de fréquence sous charge, ce qui mérite une vérification prioritaire.

Une température importante ne signifie toutefois pas automatiquement que le PC souffre d’un problème de refroidissement. Il faut également prendre en compte la charge appliquée, la stabilité des fréquences, la température maximale prévue par le constructeur et le comportement du composant pendant la phase de refroidissement.

L’interprétation détaillée de ces courbes demande donc un minimum de connaissances matérielles. AnalysePC fournit des indications pour orienter le diagnostic, mais évitez de conclure à une surchauffe uniquement à partir d’une température maximale isolée.

En revanche, si plusieurs indices concordent — température élevée, baisse de fréquence, throttling, refroidissement insuffisant — la perte de performances peut expliquer des ralentissements, des chutes de FPS ou des performances qui diminuent après quelques minutes d’utilisation intensive.

Dans ce cas, commencez par vérifier :

• l’accumulation de poussière dans le PC ;
• le fonctionnement des ventilateurs ;
• les entrées et sorties d’air du boîtier ;
• le système de refroidissement du processeur ;
• la pâte thermique sur une machine ancienne ;
• les aérations d’un ordinateur portable.

Pour aller plus loin :

Si les températures et les fréquences restent normales sous charge, vous pouvez alors poursuivre le diagnostic vers les capacités matérielles de la configuration et la charge logicielle de Windows.

Consulter l’onglet Performances d’AnalysePC

Une fois les éventuels problèmes matériels prioritaires vérifiés, ouvrez l’onglet Performances d’AnalysePC.

Cette partie du rapport sert à déterminer si les lenteurs viennent plutôt :

• des capacités matérielles du PC ;
• d’une charge logicielle trop importante ;
• ou d’un déséquilibre entre les différents composants.

AnalysePC croise notamment les performances du processeur, de la carte graphique, de la mémoire RAM et du stockage avec la charge réelle de Windows : nombre de processus, services, programmes au démarrage, mémoire utilisée et temps de démarrage.

La carte Analyse globale résume ensuite la situation avec plusieurs indicateurs :

• le niveau de performance du CPU, du GPU, de la RAM et du stockage ;
• les éventuelles limites détectées ;
• la charge logicielle par rapport à la puissance du PC ;
• les usages considérés comme adaptés ou à limiter ;
• les recommandations pour conserver une machine réactive.

Les performances de certains composants peuvent être affichées sous forme de percentiles. Par exemple, un résultat au 13e percentile signifie que le composant se situe dans le bas des performances mesurées parmi les machines comparables. Un percentile faible ne signifie toutefois pas automatiquement qu’un composant est défaillant ou responsable des lenteurs : il doit toujours être interprété avec les autres indicateurs du rapport.

AnalysePC adapte également ses seuils à la puissance de la machine. Une petite configuration n’est donc pas évaluée de la même manière qu’un PC haut de gamme.

C’est cette lecture globale qui permet ensuite de déterminer si le PC est plutôt adapté à un usage léger, à un usage courant, ou s’il dispose d’une configuration performante et polyvalente.

Vérifier si Windows est trop chargé

Même avec une configuration matérielle correcte, Windows peut devenir moins réactif si trop de programmes, de services ou de processus fonctionnent en même temps.

Dans l’onglet Performances, AnalysePC affiche une vue globale de la charge logicielle du système. Cette analyse tient compte notamment :

• du nombre de processus actifs ;
• du nombre de services ;
• des programmes lancés au démarrage ;
• de la mémoire RAM utilisée ;
• du nombre de pilotes chargés ;
• du temps de démarrage de Windows.

L’un des points importants est qu’AnalysePC adapte ses seuils à la puissance de la machine. Un même nombre de processus ne sera donc pas interprété de la même manière sur un petit PC bureautique et sur une configuration équipée d’un processeur beaucoup plus puissant.

Par exemple, 180 processus peuvent représenter une charge importante sur une machine peu performante, alors qu’un PC plus puissant peut supporter plus de 200 processus sans montrer de ralentissement particulier.

AnalysePC compare également certaines valeurs avec celles observées sur d’autres PC analysés. Vous pouvez ainsi voir si le nombre de processus, de services ou le temps de démarrage se situe au-dessus ou en dessous de la médiane.

Il faut surtout regarder si plusieurs indicateurs vont dans la même direction.

Par exemple :

• beaucoup de processus + mémoire fortement utilisée ;
• nombreux services automatiques + démarrage lent ;
• plusieurs programmes au démarrage + temps de démarrage élevé ;
• configuration modeste + charge logicielle importante.

Dans ces situations, les lenteurs peuvent venir moins du matériel lui-même que de la charge imposée à Windows.

À l’inverse, un nombre élevé de processus n’est pas automatiquement un problème. Sur une configuration performante avec beaucoup de RAM et un processeur puissant, cette charge peut rester parfaitement acceptable.

Si AnalysePC indique Charge logicielle élevée au regard des capacités du PC ou Charge logicielle à surveiller, consultez ensuite les recommandations proposées dans la partie optimisation afin d’identifier les programmes ou éléments de démarrage qui peuvent être allégés.

Cette étape permet donc de faire la différence entre un PC réellement limité par son matériel et une machine suffisamment puissante mais trop chargée par les logiciels exécutés sous Windows.

Vérifier si la configuration du PC est adaptée à votre usage

Un point important est que les seuils sont adaptés à la puissance du PC. AnalysePC ne juge donc pas de la même façon une petite configuration et une machine puissante.

Il faut surtout regarder :

• le niveau général indiqué en haut de la carte ;
• les éventuelles limites matérielles mises en évidence ;
• la charge logicielle par rapport aux capacités de la machine ;
• les usages considérés comme adaptés ou à limiter ;
• les recommandations proposées pour conserver un PC réactif.

Usage léger à modéré conseillé

Lorsque AnalysePC indique Usage léger à modéré conseillé, cela signifie généralement que la configuration dispose de peu de marge pour le multitâche ou les applications lourdes.

Ce profil peut par exemple correspondre à un processeur avec peu de cœurs, une quantité de RAM limitée ou un stockage qui manque de réactivité.

Le PC reste tout à fait utilisable pour :

• la navigation web ;
• les mails ;
• la bureautique ;
• la lecture vidéo et le streaming ;
• quelques applications légères.

En revanche, il vaut mieux éviter de lancer trop de programmes simultanément.

Sur ce type de machine, il est également important de ne pas alourdir inutilement le navigateur avec de nombreuses extensions, des dizaines d’onglets ouverts en permanence ou plusieurs applications web lourdes.

Si AnalysePC signale en parallèle une charge logicielle élevée au regard des capacités du PC, réduire le nombre de programmes en arrière-plan peut améliorer sensiblement la réactivité sans changer de matériel.

Pour upgrader votre PC, consultez ce guide :

Quelques limites à prendre en compte

Le profil Quelques limites à prendre en compte correspond à une configuration globalement utilisable, mais dont un ou plusieurs composants peuvent limiter certains usages.

Par exemple, un CPU à 4 cœurs peut être suffisant pour la plupart des tâches courantes, tandis qu’un GPU situé dans un percentile faible peut devenir pénalisant pour :

• les jeux récents ;
• la 3D ;
• le montage vidéo ;
• certaines applications graphiques lourdes.

Le PC peut donc rester confortable pour la bureautique, la navigation et le multimédia, tout en montrant ses limites dès que la charge devient plus importante.

Dans ce cas, il faut surtout regarder quel composant ressort comme le plus faible, sans pour autant conclure automatiquement qu’il est responsable des lenteurs.

AnalysePC cherche justement à distinguer une simple limite théorique d’un véritable goulot d’étranglement confirmé par plusieurs indicateurs.

Configuration adaptée à un usage courant

Lorsque la carte indique Configuration adaptée à un usage courant, le matériel est généralement suffisamment équilibré pour la majorité des usages classiques.

Cela correspond notamment à :

• la navigation web et la bureautique ;
• le multitâche courant ;
• le multimédia ;
• la visioconférence ;
• les applications graphiques adaptées au GPU installé.

Le processeur, la mémoire et le stockage ne présentent alors pas de faiblesse majeure.

Cependant, AnalysePC peut encore signaler une charge logicielle élevée. Par exemple, un PC matériellement correct peut devenir moins réactif avec un nombre très élevé de processus, de services ou de programmes lancés au démarrage.

Dans ce cas, les lenteurs ne viennent pas forcément du matériel lui-même, mais plutôt de la manière dont Windows est chargé.

C’est justement ce qui rend cette carte utile : elle permet de faire la différence entre configuration suffisante et Windows trop encombré.

Configuration performante et polyvalente

Le profil Configuration performante et polyvalente indique qu’AnalysePC détecte une bonne réserve de puissance sur les principaux composants.

Le CPU, le GPU, la mémoire et le stockage se situent alors généralement dans des percentiles élevés et permettent des usages plus exigeants :

• multitâche soutenu ;
• applications lourdes ;
• création de contenu ;
• traitements graphiques ;
• jeux adaptés au GPU installé ;
• machines virtuelles ou autres tâches gourmandes.

Une telle configuration ne devrait normalement pas devenir lente lors d’un usage classique.

Cela ne signifie toutefois pas que le PC ne peut jamais rencontrer de problème de performances.

Même une machine puissante peut être ralentie par :

• un très grand nombre de processus ;
• des services inutiles ;
• trop de programmes au démarrage ;
• un logiciel particulièrement gourmand ;
• un problème de pilote ou de température ;
• un stockage défaillant.

C’est pourquoi AnalysePC affiche également la charge logicielle réelle de Windows, même sur les configurations performantes.

Si la configuration est puissante mais que le PC reste lent, il faut donc orienter la suite du diagnostic vers les programmes au démarrage, les processus, les services et les logiciels installés, plutôt que vers une mise à niveau matérielle.

Croiser les différents indicateurs pour identifier la cause des lenteurs

Une fois les principales sections du rapport AnalysePC examinées, il faut éviter de tirer une conclusion à partir d’un seul indicateur. Un percentile faible, un nombre élevé de processus ou une température importante ne suffit pas toujours à expliquer à lui seul les lenteurs observées.

L’intérêt d’AnalysePC est justement de croiser l’état matériel, les performances mesurées, la puissance de la configuration et la charge logicielle réelle de Windows.

Le tableau suivant permet de résumer les situations les plus courantes :

Indicateurs observés	Cause la plus probable	Priorité
Santé matérielle faible + alerte SMART critique	Disque dur ou SSD défaillant	Sauvegarder les données et traiter le problème matériel en priorité
Températures élevées + baisse de fréquence sous charge	Surchauffe ou throttling thermique	Vérifier le refroidissement
Configuration faible + charge logicielle élevée	PC trop limité pour la charge actuelle	Alléger Windows et limiter le multitâche
Configuration correcte + nombreux processus/services + démarrage lent	Surcharge logicielle	Vérifier démarrage, services et logiciels installés
Stockage faible + démarrage très lent	Stockage peu performant et/ou trop de programmes au démarrage	Examiner les deux pistes
GPU faible + usage bureautique	Pas nécessairement un problème	Ne pas surinterpréter la faiblesse du GPU
RAM suffisante + utilisation mémoire élevée	Applications gourmandes ou trop nombreuses	Identifier les logiciels qui utilisent la mémoire
Configuration performante + matériel sain + charge logicielle normale	Cause non évidente dans la carte Performances	Chercher une application, un pilote ou un problème ponctuel

Par exemple, un PC équipé d’un processeur et de suffisamment de RAM peut sembler correctement dimensionné, mais devenir lent si AnalysePC relève en parallèle plus de 300 processus, de nombreux services et un temps de démarrage supérieur à 100 secondes. Dans ce cas, le matériel n’est probablement pas la cause principale : il faut plutôt examiner la charge logicielle.

À l’inverse, sur une petite configuration avec peu de cœurs, peu de mémoire et des performances situées dans les percentiles les plus faibles, quelques dizaines de processus supplémentaires peuvent déjà avoir un impact sensible. AnalysePC adapte justement ses seuils à la puissance de la machine afin de ne pas juger de la même manière un petit PC bureautique et une configuration haut de gamme.

Enfin, certaines limites doivent toujours être interprétées en fonction de l’usage. Une carte graphique peu performante n’est pas forcément un problème sur un PC destiné à la bureautique, alors qu’elle le devient rapidement pour le jeu ou la 3D.

L’objectif est donc de rechercher plusieurs indices qui vont dans la même direction avant de conclure. Cela permet d’éviter les optimisations inutiles et de concentrer les actions sur la cause la plus vraisemblable des lenteurs.

Que faire une fois la cause identifiée ?

Une fois la cause probable des lenteurs identifiée, il n’est pas nécessaire de modifier Windows au hasard. AnalysePC fournit déjà plusieurs propositions d’optimisation adaptées aux problèmes détectés.

Commencez par revenir dans l’onglet Performances et consultez les recommandations affichées dans les différentes cartes.

Selon le diagnostic, AnalysePC peut par exemple proposer de :

• désinstaller des logiciels inutiles, facultatifs ou redondants ;
• examiner les logiciels considérés comme peu utiles ou déconseillés ;
• alléger les programmes et tâches lancés au démarrage ;
• réduire le nombre d’applications exécutées en arrière-plan ;
• conserver uniquement les navigateurs réellement utilisés ;
• vérifier les services ou programmes qui contribuent à un démarrage très lent ;
• traiter en priorité un problème matériel signalé dans le rapport.

AnalysePC peut aussi regrouper les logiciels installés par catégorie et signaler les fonctions présentes plusieurs fois. Par exemple, plusieurs navigateurs, outils de compression, lecteurs PDF ou services de synchronisation peuvent être installés alors qu’un seul ou deux sont réellement utilisés.

La carte Alléger Windows et le démarrage fournit notamment un score d’optimisation et indique les logiciels ou éléments de démarrage qui peuvent être examinés. Certaines recommandations disposent également d’un bouton Voir le guide afin d’accéder directement à la procédure correspondante.

Le guide à consulter :

Cela ne signifie pas qu’il faut systématiquement désinstaller tous les logiciels en double. L’objectif est plutôt de se demander si chacun d’eux est réellement nécessaire et s’il contribue inutilement à la charge logicielle du PC.

Si le rapport indique au contraire que la configuration matérielle est trop limitée pour l’usage souhaité, les optimisations logicielles auront forcément leurs limites. Il faudra alors soit réduire le nombre d’applications utilisées simultanément, soit envisager une évolution matérielle adaptée.

Enfin, si AnalysePC détecte un problème SMART ou une surchauffe, traitez d’abord cette anomalie avant de chercher à gagner quelques secondes au démarrage ou à supprimer des programmes.

Pour les méthodes générales permettant d’optimiser ou dépanner un ordinateur lent, vous pouvez ensuite consulter le guide complet :

L’article Diagnostiquer les lenteurs de son PC avec AnalysePC sous Windows 11/10 est apparu en premier sur malekal.com.

Lorsque Windows utilise une grande quantité de mémoire RAM, le Gestionnaire des tâches ne permet pas toujours de comprendre où se trouve réellement la mémoire utilisée. Une partie peut être occupée par les applications, mais aussi par le cache de fichiers, le noyau, les pilotes, les pools mémoire ou encore les pages placées en attente par Windows.

RAMMap est un outil gratuit de Microsoft Sysinternals conçu pour examiner en détail la répartition de la mémoire physique sous Windows. Il permet de distinguer les pages Active, Standby ou Modified, d’examiner la mémoire associée aux processus et aux fichiers, mais aussi d’observer les allocations du noyau et des pilotes.

RAMMap devient particulièrement utile lorsque la RAM semble fortement utilisée sans qu’aucun processus ne permette d’expliquer clairement cette consommation. Il peut également aider à orienter la recherche d’une fuite mémoire ou à comprendre le fonctionnement du cache de Windows.

Dans ce guide, découvrez comment utiliser RAMMap pour comprendre et examiner la mémoire RAM de Windows, interpréter ses principaux onglets et repérer une consommation mémoire qui mérite d’être approfondie.

Qu’est-ce que RAMMap ?

RAMMap est un utilitaire gratuit de la suite Microsoft Sysinternals qui permet d’examiner en détail comment Windows utilise la mémoire RAM physique.

Le Gestionnaire des tâches indique la quantité de mémoire utilisée, disponible ou mise en cache. RAMMap va beaucoup plus loin en montrant à quoi correspondent réellement les pages présentes en mémoire : processus, cache de fichiers, noyau Windows, pilotes, tables de pages ou encore mémoire en attente.

Il permet notamment de répondre à des questions comme :

• Pourquoi une grande quantité de RAM est-elle utilisée alors qu’aucune application ne semble particulièrement gourmande ?
• Quelle quantité de mémoire se trouve dans le cache de Windows ?
• Quelle part de la RAM est Active, Standby, Modified ou libre ?
• Quels processus ou fichiers occupent la mémoire physique ?
• La consommation provient-elle plutôt des applications, du noyau, des pilotes ou du cache ?

RAMMap analyse la mémoire physique de Windows

La particularité de RAMMap est de fournir une vue globale de la mémoire physique, et pas seulement une liste des processus.

Windows utilise en effet la RAM pour de nombreux éléments qui ne sont pas toujours clairement attribuables à une application dans le Gestionnaire des tâches. Une quantité importante de mémoire peut par exemple correspondre à des fichiers mis en cache ou à des pages placées dans la liste Standby (En attente) et rapidement récupérables si un programme en a besoin.

RAMMap présente ces informations dans plusieurs onglets spécialisés comme Use Counts, Processes, Priority Summary, Physical Pages, Physical Ranges, File Summary et File Details.

Il devient ainsi particulièrement utile lorsqu’une consommation mémoire paraît difficile à expliquer avec les outils classiques.

RAMMap est donc surtout adapté pour répondre à la question :

« Comment la mémoire physique de mon PC est-elle réellement répartie ? »

Pour examiner en profondeur la mémoire virtuelle et les allocations d’un processus particulier, Microsoft propose un autre outil Sysinternals complémentaire : VMMap.

Que permet de voir RAMMap dans la mémoire de Windows ?

RAMMap permet de visualiser comment la mémoire physique est réellement répartie entre les différents composants de Windows. Contrairement au Gestionnaire des tâches, qui fournit surtout une vue synthétique, RAMMap détaille l’utilisation de chaque groupe de pages mémoire.

Il permet notamment d’examiner :

• la mémoire utilisée par les processus et applications ;
• la mémoire occupée par le noyau Windows et les pilotes ;
• les pools paginé et non paginé ;
• les fichiers et données conservés dans le cache mémoire ;
• les pages appartenant aux listes Active, Standby, Modified, Free et Zeroed ;
• les fichiers dont le contenu est actuellement présent en RAM ;
• la répartition des pages selon leur priorité ;
• l’organisation des différentes zones de la mémoire physique.

Comprendre où est passée la RAM

RAMMap est particulièrement utile lorsque la quantité de RAM utilisée semble beaucoup plus importante que celle consommée par les applications visibles dans le Gestionnaire des tâches.

Par exemple, Windows peut afficher 12 Go utilisés sur 16 Go, alors que les principaux processus n’en représentent que quelques gigaoctets. Le reste peut correspondre au cache de fichiers, au noyau, aux pilotes, aux tables de pages ou à d’autres allocations système.

RAMMap permet justement d’identifier quelle catégorie explique cette différence. Une quantité importante de mémoire Standby, par exemple, correspond généralement à des données conservées en cache mais récupérables si les applications ont besoin de davantage de RAM.

Les différents onglets permettent ensuite d’approfondir l’analyse : Use Counts pour obtenir une vue globale, Processes pour les processus et File Summary / File Details pour les fichiers présents en mémoire.

RAMMap permet ainsi de déterminer si une forte utilisation correspond à une réelle pression mémoire ou simplement au fonctionnement normal de Windows et de son cache.

Télécharger et lancer RAMMap

RAMMap est un utilitaire gratuit proposé par Microsoft Sysinternals. Il ne nécessite pas d’installation et peut être exécuté directement après avoir téléchargé et extrait son archive ZIP.

Pour utiliser RAMMap :

• Téléchargez RAMMap :

• Décompressez l’archive RAMMap.zip dans le dossier de votre choix.
• Exécutez RAMMap.exe.
• Acceptez le contrôle de compte utilisateur (UAC) si Windows demande l’autorisation d’exécuter le programme avec les privilèges administrateur.

L’interface s’ouvre alors directement sur l’onglet Use Counts, qui fournit une première vue d’ensemble de la répartition de la mémoire physique.

Aucune installation ni configuration particulière n’est nécessaire. Vous pouvez immédiatement naviguer entre les différents onglets Use Counts, Processes, Priority Summary, Physical Pages, Physical Ranges, File Summary et File Details pour examiner la mémoire sous différents angles.

Pour obtenir des informations représentatives, il est préférable de lancer RAMMap pendant que le problème de mémoire est présent. Si vous cherchez par exemple à comprendre pourquoi 90 % de la RAM est utilisée, évitez de redémarrer Windows juste avant l’analyse : le redémarrage peut faire disparaître temporairement la situation que vous souhaitez examiner.

Une fois l’analyse terminée, il suffit de fermer RAMMap. L’utilisation normale de l’outil pour consulter les informations ne modifie pas la configuration de Windows. Certaines commandes du menu Empty agissent en revanche sur les listes mémoire ; nous verrons plus loin dans quelles situations les utiliser.

Comprendre l’onglet Use Counts

L’onglet Use Counts est la vue principale de RAMMap. Il permet de comprendre rapidement à quoi sert la mémoire physique du PC en croisant deux informations : le type d’utilisation de la mémoire et l’état actuel des pages.

Les lignes correspondent aux différentes catégories d’utilisation de la RAM, tandis que les colonnes indiquent si les pages sont Active, Standby, Modified, Transition, etc. La colonne Total permet de connaître la quantité totale associée à chaque catégorie.

Parmi les principales lignes affichées, vous pouvez rencontrer :

• Process Private : mémoire privée associée aux processus.
• Mapped File : pages provenant de fichiers mappés en mémoire, notamment utilisées par le cache de fichiers.
• Shareable : mémoire pouvant être partagée entre plusieurs processus.
• Paged Pool : pool mémoire du noyau pouvant être paginé.
• Nonpaged Pool : mémoire du noyau devant rester en RAM.
• Session Private : mémoire privée associée aux sessions Windows.
• Metafile : données utilisées par le cache des métadonnées du système de fichiers.
• Page Table : mémoire utilisée pour les tables de pages qui assurent la correspondance entre mémoire virtuelle et mémoire physique.
• Driver Locked : pages verrouillées en mémoire, notamment par certains pilotes.
• Large Page : allocations utilisant les grandes pages mémoire.

Comment interpréter Use Counts ?

Il ne faut pas rechercher une valeur particulière qui serait systématiquement « normale ». La répartition dépend de la quantité de RAM installée, des applications ouvertes et de l’activité de Windows.

L’intérêt de Use Counts est surtout de repérer quelle catégorie explique une consommation importante.

Par exemple :

• Process Private élevé → examinez les processus et applications.
• Mapped File élevé → une partie importante de la mémoire est liée aux fichiers mappés et au cache.
• Nonpaged Pool anormalement élevé ou qui augmente continuellement → recherchez éventuellement un problème de pilote ou une fuite mémoire du noyau.
• Page Table élevé → une quantité importante de mémoire est utilisée pour gérer les espaces d’adressage virtuels ; il faut l’interpréter avec le nombre et le comportement des processus présents.

Il faut également regarder les colonnes. Une quantité importante dans Standby n’a pas la même signification qu’une quantité équivalente dans Active : les pages Standby peuvent être récupérées par Windows lorsque davantage de mémoire est nécessaire.

L’onglet Use Counts constitue donc généralement le meilleur point de départ dans RAMMap. Une fois la catégorie responsable identifiée, les autres onglets permettent d’approfondir l’analyse et de déterminer quels processus, fichiers ou composants utilisent cette mémoire.

Comprendre les états Active, Standby, Modified, Free et Zeroed

RAMMap classe les pages mémoire selon leur état. Cette information permet de distinguer la mémoire réellement utilisée de celle que Windows peut récupérer ou réaffecter.

Les principaux états sont :

• Active : pages actuellement utilisées par Windows, les applications ou les pilotes.
• Standby : pages contenant encore des données utiles, mais récupérables rapidement si davantage de mémoire est nécessaire.
• Modified : pages modifiées qui doivent généralement être écrites avant de pouvoir être réutilisées.
• Free : pages qui ne sont actuellement attribuées à aucun usage actif.
• Zeroed : pages disponibles, déjà remises à zéro et prêtes à être attribuées.

Une quantité importante de mémoire Standby n’indique donc pas nécessairement un manque de RAM. Windows utilise notamment ces pages comme cache et peut les réaffecter en fonction des besoins.

Dans RAMMap, ces états doivent être croisés avec les catégories de l’onglet Use Counts afin de comprendre quel type de mémoire est utilisé et dans quel état se trouvent les pages correspondantes.

Pour comprendre en détail le fonctionnement des états mémoire, du cache et de la mémoire disponible : Comment mesurer et analyser l’utilisation de la mémoire RAM sous Windows 11/10

Examiner la mémoire utilisée par les processus

L’onglet Processes de RAMMap permet d’examiner la mémoire physique associée aux différents processus en cours d’exécution. Il complète l’onglet Use Counts en permettant de déterminer quelles applications contribuent à l’utilisation de la RAM.

Chaque ligne correspond à un processus et présente notamment son PID (identifiant du processus) ainsi que la répartition de ses pages mémoire selon leur état.

Vous pouvez ainsi observer :

• Total : quantité totale de mémoire physique associée au processus.
• Active : pages actuellement actives dans le jeu de travail du processus.
• Standby : pages associées au processus qui se trouvent désormais dans la liste Standby.
• Modified : pages modifiées qui doivent être écrites avant de pouvoir être réutilisées.
• Page Table : mémoire utilisée par les tables de pages nécessaires à la gestion de l’espace d’adressage du processus.

Identifier les processus qui occupent le plus de RAM

Cliquez sur les en-têtes de colonnes pour trier les processus. La colonne Total donne une première indication des processus auxquels une quantité importante de mémoire physique est associée.

Il est toutefois important de ne pas interpréter cette valeur comme la simple « consommation RAM » affichée dans le Gestionnaire des tâches. RAMMap s’intéresse ici aux pages physiques et à leur état, et une partie peut notamment se trouver en Standby.

L’onglet Processes est particulièrement utile lorsque Process Private apparaît élevé dans Use Counts. Vous pouvez alors rechercher quels processus expliquent cette consommation et vérifier si quelques applications concentrent une part importante de la mémoire.

Analyser le cache de fichiers avec File Summary et File Details

RAMMap permet aussi d’examiner la mémoire utilisée par le cache de fichiers de Windows. Pour cela, deux onglets sont particulièrement utiles : File Summary et File Details.

L’onglet File Summary regroupe les fichiers dont des pages sont actuellement présentes en mémoire. Il permet de repérer rapidement quels fichiers occupent une part importante de la RAM et de distinguer ce qui relève réellement des applications de ce qui correspond au cache de Windows.

Vous pouvez notamment y voir, pour chaque fichier, la quantité totale de mémoire associée ainsi que la part présente dans différents états comme Active ou Standby.

File Summary : repérer les fichiers qui occupent le cache

L’intérêt principal de File Summary est de répondre à une question simple :

Quels fichiers expliquent une partie importante de la mémoire mise en cache ?

Vous pouvez trier les colonnes pour identifier les fichiers les plus présents en mémoire. Il peut s’agir de fichiers système, de bibliothèques DLL, de fichiers exécutables ou de données récemment utilisées par des applications.

Une présence importante dans le cache n’est pas forcément problématique. Si une grande partie de cette mémoire se trouve en Standby, Windows peut la récupérer rapidement lorsqu’un programme a besoin de davantage de RAM.

File Details : examiner le cache fichier par fichier

L’onglet File Details permet d’aller plus loin en affichant le détail des fichiers mappés ou mis en cache en mémoire.

Il est particulièrement utile lorsque Mapped File apparaît élevé dans l’onglet Use Counts et que vous voulez savoir quels fichiers en sont responsables.

Vous pouvez alors rechercher un fichier précis et examiner sa présence dans la mémoire physique.

Quand ces onglets sont-ils utiles ?

File Summary et File Details sont surtout utiles lorsque la RAM paraît très utilisée mais qu’aucun processus ne semble expliquer la consommation. Ils permettent de vérifier si une part importante de la mémoire correspond simplement à des fichiers mis en cache par Windows.

Dans ce cas, il ne faut pas forcément chercher à « libérer » cette mémoire : tant qu’elle est majoritairement récupérable, elle participe au fonctionnement normal du cache et peut améliorer les performances en évitant de relire certaines données depuis le stockage.

Comprendre la mémoire du noyau, des pilotes et des pools

Toute la mémoire utilisée par Windows n’est pas directement attribuée aux applications. Le noyau de Windows, les pilotes et certains composants système utilisent également une partie de la RAM pour fonctionner.

Dans RAMMap, cette consommation apparaît notamment à travers plusieurs catégories de l’onglet Use Counts, comme Paged Pool, Nonpaged Pool, Driver Locked ou encore certaines allocations liées aux tables de pages.

Pool paginé et pool non paginé

• Le pool paginé (Paged Pool) contient des données utilisées par le noyau et les pilotes qui peuvent, lorsque Windows le permet, être transférées hors de la RAM physique vers le fichier d’échange.
• Le pool non paginé (Nonpaged Pool) contient au contraire des données qui doivent rester présentes en mémoire physique tant qu’elles sont utilisées.

Il est donc parfaitement normal que ces deux catégories occupent une certaine quantité de RAM.

Quand faut-il s’en préoccuper ?

Ce qui devient intéressant, c’est surtout l’évolution de ces valeurs dans le temps.

Par exemple, si le Nonpaged Pool augmente continuellement pendant plusieurs heures ou plusieurs jours, alors que les applications visibles restent stables, cela peut orienter le diagnostic vers un pilote ou un composant du noyau qui ne libère pas correctement sa mémoire.

Même logique pour le Paged Pool : une croissance anormale et persistante peut signaler un problème côté noyau ou pilote.

La mémoire verrouillée par les pilotes

La catégorie Driver Locked correspond à des pages physiques verrouillées en mémoire, notamment par certains pilotes ou mécanismes bas niveau.

Une petite quantité n’est pas forcément anormale. En revanche, si cette catégorie devient très importante ou augmente continuellement, elle peut constituer une piste à examiner.

Comment approfondir ?

RAMMap permet surtout de constater quelle catégorie système utilise la mémoire. Pour identifier précisément le pilote responsable d’une fuite dans un pool mémoire, il faut généralement aller plus loin avec un outil comme PoolMon, qui permet d’examiner les allocations par pool tags.

On peut donc retenir :

• Process Private élevé → chercher du côté des applications
• Paged Pool / Nonpaged Pool élevés → chercher du côté du noyau et des pilotes
• Driver Locked élevé → examiner les pilotes ou composants bas niveau

RAMMap est particulièrement utile ici lorsque le Gestionnaire des tâches montre une forte utilisation de la RAM sans qu’aucun processus utilisateur ne semble en être responsable.

Examiner les pages physiques avec Physical Pages et Physical Ranges

Les onglets Physical Pages et Physical Ranges proposent une vue très technique de l’organisation de la mémoire physique. Ils sont surtout destinés à approfondir une analyse, tandis que Use Counts, Processes et File Summary suffisent généralement pour rechercher l’origine d’une forte utilisation de RAM.

Physical Pages : examiner les pages présentes en RAM

L’onglet Physical Pages affiche les pages de la mémoire physique avec leur adresse et leur utilisation. Il permet ainsi de déterminer si une page est associée à un processus, un fichier mappé, au noyau ou à une autre catégorie mémoire.

Il fournit donc une vue beaucoup plus fine que Use Counts :

• Use Counts → combien de mémoire chaque catégorie utilise
• Physical Pages → quelles pages physiques correspondent à ces utilisations

Pour un diagnostic courant, il est rarement nécessaire d’aller jusqu’à ce niveau de détail.

Physical Ranges : visualiser les plages de mémoire physique

L’onglet Physical Ranges affiche les différentes plages d’adresses physiques détectées sur le PC. Certaines zones peuvent être réservées au matériel ou utilisées pour le mappage de périphériques.

Cette vue peut notamment aider à comprendre pourquoi la quantité de RAM utilisable par Windows est légèrement inférieure à la quantité installée, par exemple lorsqu’une partie de la mémoire est réservée au matériel.

Ces deux onglets sont donc surtout utiles pour une analyse avancée de l’organisation de la mémoire physique. Pour rechercher simplement ce qui occupe la RAM, commencez plutôt par Use Counts, puis utilisez Processes ou File Summary selon la catégorie identifiée.

Utiliser Priority Summary pour comprendre les priorités mémoire

L’onglet Priority Summary montre comment Windows répartit les pages mémoire selon leur niveau de priorité. Ces priorités l’aident notamment à déterminer quelles pages conserver en RAM et lesquelles peuvent être récupérées plus facilement lorsque la pression mémoire augmente.

RAMMap présente leur répartition entre différents états, notamment Active, Standby et Modified. Les pages de priorité élevée ont davantage de chances d’être conservées en mémoire lorsqu’elles restent utiles, tandis que les pages Standby de faible priorité peuvent être réaffectées plus facilement.

Cet onglet permet ainsi de comprendre que la liste Standby n’est pas uniforme : Windows attribue également des priorités aux données qu’elle contient.

En pratique, Priority Summary est rarement indispensable pour diagnostiquer une forte utilisation de RAM. Les onglets Use Counts, Processes et File Summary sont généralement plus utiles pour identifier l’origine de la consommation. Priority Summary sert surtout à approfondir le fonctionnement de la mémoire Standby et la manière dont Windows arbitre entre les pages récupérables.

Une quantité importante de mémoire Standby, même visible dans cet onglet, n’indique donc pas nécessairement un problème : cette mémoire reste en grande partie récupérable en fonction des besoins du système.

Comment repérer une consommation de RAM anormale avec RAMMap ?

RAMMap permet surtout de déterminer quelle catégorie de mémoire explique une consommation élevée, puis d’orienter le diagnostic vers les processus, le cache, le noyau ou les pilotes.

Il n’existe pas de valeur unique à partir de laquelle une consommation devient forcément anormale. Il faut surtout observer la répartition de la mémoire et son évolution dans le temps.

Commencez par l’onglet Use Counts et recherchez les catégories qui occupent une quantité importante de RAM. Les principales pistes sont généralement :

• Process Private élevé : la consommation provient surtout des applications.
• Mapped File élevé : une grande partie de la mémoire est liée aux fichiers mappés et au cache.
• Paged Pool ou Nonpaged Pool élevés : le noyau ou un pilote peut être en cause.
• Driver Locked élevé : certaines pages sont verrouillées en mémoire par des pilotes ou composants bas niveau.
• Standby très important : souvent normal, car cette mémoire reste récupérable par Windows.

Rechercher une évolution anormale

Une valeur élevée à un instant donné n’est pas forcément problématique. En revanche, une catégorie qui augmente continuellement sans revenir à un niveau normal mérite davantage d’attention.

Par exemple :

Process Private : 4 Go → 6 Go → 9 Go → 12 Go

ou :

Nonpaged Pool : 500 Mo → 1 Go → 2 Go → 4 Go

peuvent indiquer respectivement une consommation excessive d’un processus ou un problème côté pilote/noyau.

Dans ce cas, laissez RAMMap ouvert ou réalisez plusieurs relevés à différents moments afin de vérifier si la hausse est continue.

Croiser les onglets pour trouver l’origine

Une fois la catégorie suspecte identifiée, utilisez les autres onglets :

• Process Private élevé → Processes
• Mapped File élevé → File Summary / File Details
• Paged Pool ou Nonpaged Pool élevés → Use Counts, puis éventuellement PoolMon
• Standby élevé → Priority Summary et états mémoire

Cette méthode permet de passer progressivement d’une vue globale à une analyse plus ciblée.

Quand faut-il réellement s’inquiéter ?

La consommation devient surtout préoccupante lorsqu’elle s’accompagne de plusieurs symptômes :

• mémoire disponible très faible
• augmentation continue d’une catégorie
• ralentissements ou forte utilisation du fichier d’échange
• consommation qui ne redescend pas après la fin d’une tâche
• aucun processus évident dans le Gestionnaire des tâches malgré une RAM presque saturée

RAMMap est donc particulièrement utile pour répondre à cette question :

« Quelle partie de Windows ou des applications explique réellement cette consommation mémoire ? »

Il permet ensuite de choisir l’outil approprié pour approfondir : Process Explorer ou VMMap pour un processus, PoolMon pour les pools mémoire, ou PerfMon pour suivre l’évolution sur une période plus longue.

Peut-on vider la mémoire Standby avec RAMMap ?

Oui. RAMMap permet de vider manuellement la liste Standby grâce aux commandes du menu Empty.

La liste Standby contient des pages qui ne sont plus activement utilisées mais dont Windows conserve encore le contenu en mémoire afin de pouvoir les réutiliser rapidement. Cette mémoire reste récupérable automatiquement si une application a besoin de davantage de RAM.

Pour vider cette mémoire dans RAMMap :

• Ouvrez RAMMap avec les droits administrateur.
• Cliquez sur le menu Empty.
• Sélectionnez Empty Standby List.

La quantité de mémoire Standby diminue alors immédiatement et la mémoire libre augmente.

Faut-il le faire régulièrement ?

En règle générale, non.

Windows gère automatiquement la liste Standby et réattribue ces pages lorsqu’un programme réclame davantage de mémoire. Une liste Standby importante n’indique donc pas forcément un problème.

Vider cette mémoire peut même être contre-productif : les données qui étaient encore présentes en RAM devront parfois être relues depuis le SSD si elles sont de nouveau nécessaires.

Dans quels cas cela peut-il être utile ?

La fonction Empty Standby List est surtout intéressante pour des besoins de test et de diagnostic.

Par exemple, elle peut servir à :

• vérifier si un comportement change lorsque le cache Standby est supprimé ;
• comparer les performances avec ou sans données déjà présentes en mémoire ;
• reproduire plus facilement certains scénarios de test ;
• confirmer qu’une grande quantité de mémoire affichée comme occupée correspond en réalité à de la mémoire récupérable.

Il faut donc voir cette fonction comme un outil de diagnostic, et non comme une méthode d’optimisation permanente.

Si la RAM reste réellement saturée après avoir vidé la liste Standby, il faut plutôt rechercher une consommation anormale dans les processus, le noyau, les pools mémoire ou les pilotes.

Quand utiliser les commandes Empty de RAMMap ?

Le menu Empty de RAMMap permet de vider manuellement certaines listes ou zones mémoire gérées par Windows. Ces commandes peuvent être utiles pour des besoins de test, de diagnostic ou de comparaison, mais elles ne doivent pas être utilisées comme méthode régulière d’optimisation.

Selon la version de RAMMap, le menu peut notamment proposer :

• Empty Working Sets : réduit le jeu de travail des processus afin de récupérer une partie des pages actuellement résidentes en RAM.
• Empty System Working Set : vide une partie du jeu de travail utilisé par le système.
• Empty Modified Page List : force le traitement des pages modifiées afin qu’elles puissent être réutilisées.
• Empty Standby List : vide l’ensemble de la liste Standby.
• Empty Priority 0 Standby List : vide uniquement les pages Standby de priorité 0, les moins prioritaires.

Dans quels cas les utiliser ?

Ces commandes sont surtout intéressantes lorsque vous cherchez à observer le comportement de Windows avant et après la suppression d’un type de mémoire.

Par exemple, vous pouvez vider la liste Standby pour vérifier si une forte consommation apparente provient essentiellement du cache. De même, réduire les Working Sets peut aider à observer la différence entre mémoire résidente et mémoire réellement engagée par les processus.

Elles peuvent aussi être utiles dans des scénarios de test, par exemple pour reproduire un démarrage « à froid » d’une application ou mesurer ses performances sans bénéficier de données déjà présentes en cache.

Pourquoi éviter de les utiliser en permanence ?

Forcer Windows à vider ses listes mémoire peut donner l’impression de « récupérer » beaucoup de RAM, mais cela ne signifie pas que le système était réellement à court de mémoire.

En pratique, Windows gère déjà automatiquement ces zones selon la pression mémoire. Vider les Working Sets ou la liste Standby peut simplement obliger le système à recharger plus tard des données depuis le SSD, ce qui peut dégrader temporairement les performances.

Il faut donc considérer le menu Empty comme une fonction de diagnostic avancé, et non comme un bouton de nettoyage.

En résumé :

• Empty Standby List → utile pour tester le cache
• Empty Working Sets → utile pour observer la mémoire résidente
• Empty Modified Page List → utile dans des scénarios de diagnostic spécifiques
• Usage régulier pour “libérer la RAM” → déconseillé

Si l’utilisation mémoire reste anormalement élevée après ces tests, mieux vaut poursuivre l’analyse avec les onglets de RAMMap ou avec Process Explorer, VMMap, PoolMon ou PerfMon selon la catégorie concernée.

RAMMap est-il utile pour détecter une fuite mémoire ?

Oui, mais RAMMap sert surtout à repérer quelle catégorie de mémoire augmente anormalement et à orienter le diagnostic. Il ne permet pas toujours d’identifier directement le programme, le pilote ou l’allocation responsable d’une fuite.

L’onglet Use Counts fournit les premières indications :

• Process Private augmente continuellement → la fuite peut provenir d’une application.
• Paged Pool ou Nonpaged Pool augmente → recherchez plutôt du côté du noyau ou d’un pilote.
• Driver Locked augmente fortement → un pilote ou un composant bas niveau peut être impliqué.
• Mapped File augmente → la hausse peut provenir du cache ou de fichiers mappés et ne constitue pas nécessairement une fuite.

Ce qui compte surtout est l’évolution dans le temps. Une valeur élevée à un instant donné n’est pas suffisante : une fuite se caractérise plutôt par une consommation qui augmente progressivement sans revenir à son niveau habituel.

RAMMap permet donc de répondre à une première question :

« La fuite semble-t-elle provenir d’un processus, du noyau, d’un pilote ou d’une autre catégorie mémoire ? »

Il faut ensuite utiliser un outil plus spécialisé pour approfondir : Process Explorer ou VMMap pour un processus, PoolMon pour les pools du noyau et les pilotes, ou PerfMon pour suivre une consommation qui évolue pendant plusieurs heures ou plusieurs jours.

RAMMap est donc avant tout un outil d’orientation pour rechercher une fuite mémoire, plutôt qu’un outil capable d’en identifier à lui seul la cause précise.

RAMMap, Process Explorer ou VMMap : quel outil choisir ?

RAMMap, Process Explorer et VMMap sont trois outils Microsoft Sysinternals complémentaires, mais ils ne répondent pas au même besoin.

Outil	À utiliser pour
RAMMap	Comprendre comment la mémoire physique est répartie dans Windows
Process Explorer	Identifier et suivre la consommation mémoire d’un processus
VMMap	Examiner en détail les allocations mémoire d’un processus

Si Windows utilise beaucoup de RAM sans qu’aucun processus ne semble clairement responsable, commencez par RAMMap. Il permet de déterminer si la consommation provient plutôt des processus, du cache, des fichiers mappés, du noyau ou des pilotes.

Si un processus précis paraît gourmand ou augmente progressivement, Process Explorer est plus adapté pour suivre des indicateurs comme le Working Set ou les Private Bytes.

Enfin, utilisez VMMap lorsque vous voulez comprendre plus finement comment ce processus utilise sa mémoire : Heap, Stack, Private Data, Mapped File, etc.

On peut donc retenir :

• RAMMap → vue globale de la mémoire
• Process Explorer → suivi d’un processus
• VMMap → analyse détaillée des allocations d’un processus

Les limites de RAMMap

RAMMap est très utile pour comprendre comment la mémoire physique est répartie dans Windows, mais il ne permet pas toujours d’identifier directement la cause précise d’une consommation anormale.

Il peut par exemple montrer qu’un Process Private, un Nonpaged Pool ou une autre catégorie augmente fortement, sans forcément indiquer quel code, quel pilote ou quelle allocation est responsable. Dans ce cas, il faut compléter l’analyse avec un outil plus spécialisé.

RAMMap fournit également surtout un instantané de la mémoire à un moment donné. Pour suivre une consommation qui augmente pendant plusieurs heures ou plusieurs jours, PerfMon est généralement plus adapté.

Enfin, certaines valeurs peuvent être difficiles à interpréter sans connaître le fonctionnement de la mémoire Windows. Une quantité importante de mémoire Standby ou de cache n’est pas forcément anormale.

RAMMap doit donc surtout être considéré comme un outil permettant de repérer où se trouve la mémoire et d’orienter le diagnostic, plutôt que comme une solution capable d’identifier à elle seule l’origine de chaque fuite ou anomalie.

L’article RAMMap : comprendre et examiner la mémoire RAM de Windows est apparu en premier sur malekal.com.

Restic est un logiciel de sauvegarde gratuit et open source qui permet de protéger ses fichiers sous Windows, Linux et macOS. Il se distingue par son fonctionnement en ligne de commande, son chiffrement intégré, la déduplication des données et la gestion des sauvegardes sous forme de snapshots.

Avec Restic, vous pouvez sauvegarder des dossiers vers un disque local, un disque externe, un NAS, un serveur distant ou encore un stockage cloud via rclone. Les sauvegardes suivantes ne recopient pas inutilement les données déjà présentes, ce qui permet de réduire l’espace utilisé et d’accélérer les opérations.

L’outil permet également de restaurer une sauvegarde complète ou seulement certains fichiers, d’exclure des dossiers, de gérer une politique de rétention avec forget et prune, de vérifier l’intégrité du repository et d’automatiser les sauvegardes avec PowerShell, cron ou systemd.

Dans ce tutoriel, vous allez voir comment installer Restic, créer un repository, sauvegarder et restaurer vos fichiers, gérer les snapshots, supprimer les anciennes sauvegardes, vérifier leur intégrité et automatiser les sauvegardes.

Restic est particulièrement adapté si vous recherchez une solution de sauvegarde légère, chiffrée et scriptable, sans dépendre d’une interface graphique.

Qu’est-ce que Restic ?

Restic est un logiciel de sauvegarde en ligne de commande, gratuit et open source, conçu pour créer des sauvegardes rapides, chiffrées et dédupliquées.

Il fonctionne sous Windows, Linux, macOS et d’autres systèmes, et permet de sauvegarder des fichiers vers différents types de destinations : un disque local, un disque USB, un NAS, un serveur distant ou certains stockages cloud.

Restic repose sur deux notions principales :

• le repository : l’emplacement dans lequel les données de sauvegarde sont stockées ;
• le snapshot : une photographie de l’état des fichiers au moment d’une sauvegarde.

À chaque nouvelle sauvegarde, Restic ne recopie pas inutilement toutes les données déjà présentes. Il réutilise les blocs déjà sauvegardés et n’ajoute que les nouvelles données ou celles qui ont été modifiées. Cela permet de réduire l’espace disque utilisé et d’accélérer les sauvegardes suivantes.

Les données enregistrées dans le dépôt sont également chiffrées. Le contenu des fichiers, leurs noms et les métadonnées sont protégés par le mot de passe du repository.

Restic permet notamment de :

• sauvegarder un ou plusieurs dossiers ;
• conserver plusieurs versions grâce aux snapshots ;
• restaurer une sauvegarde complète ou seulement certains fichiers ;
• exclure des fichiers ou dossiers ;
• vérifier l’intégrité du repository ;
• supprimer automatiquement les anciennes sauvegardes ;
• automatiser les sauvegardes avec le Planificateur de tâches de Windows, cron ou systemd ;
• utiliser un stockage local ou distant.

Restic est donc particulièrement adapté si vous recherchez une solution de sauvegarde légère, fiable et scriptable, sans dépendre d’une interface graphique.

Son principal inconvénient est justement son fonctionnement en ligne de commande : il faut se familiariser avec quelques commandes pour créer le dépôt, lancer les sauvegardes et effectuer les restaurations. Une fois cette logique comprise, son utilisation reste toutefois assez simple.

Installer Restic sur Windows et Linux

Restic est disponible sous Windows et Linux. Il s’agit d’un programme en ligne de commande : une fois installé, vous l’utilisez depuis PowerShell, l’Invite de commandes ou un terminal Linux.

Installer Restic sous Windows

Sous Windows, Restic est disponible sous la forme d’un exécutable autonome. Il n’est donc pas nécessaire de passer par un programme d’installation classique.

Téléchargez la dernière version stable de Restic depuis la page officielle :

Choisissez l’archive correspondant à votre architecture, généralement Windows AMD64 pour un PC Windows 64 bits.

Après le téléchargement :

• décompressez l’archive ;
• renommez éventuellement le fichier en restic.exe ;
• placez-le dans un dossier dédié, par exemple C:\Program Files\Restic\ ;
• ajoutez ce dossier à la variable d’environnement PATH afin de pouvoir lancer Restic depuis n’importe quel terminal.

Vous pouvez ensuite vérifier que Restic fonctionne avec :

restic version

La version installée doit alors s’afficher.

Si vous ne souhaitez pas modifier le PATH, ouvrez PowerShell directement dans le dossier de Restic puis utilisez :

.\restic.exe version

Installer Restic sous Linux

Sous Linux, Restic est disponible dans les dépôts de nombreuses distributions.

Sur Debian, Ubuntu et dérivées :

sudo apt update
sudo apt install restic

Sur Fedora :

sudo dnf install restic

Sur Arch Linux et dérivées :

sudo pacman -S restic

Une fois l’installation terminée, vérifiez la version :

restic version

Vous pouvez aussi télécharger directement le binaire depuis le site officiel de Restic si vous souhaitez disposer d’une version plus récente que celle fournie par les dépôts de votre distribution.

Après l’installation, Restic est prêt à être utilisé. L’étape suivante consiste à créer un repository, c’est-à-dire l’emplacement dans lequel seront stockées les sauvegardes.

Créer un dépôt de sauvegarde Restic

Avant de pouvoir sauvegarder des fichiers avec Restic, il faut créer un dépôt, appelé repository. Il s’agit de l’emplacement dans lequel Restic va stocker les données, les métadonnées et les différents snapshots de sauvegarde.

Le dépôt peut se trouver sur un disque local, un disque USB, un NAS, un serveur distant ou un stockage cloud. Pour commencer simplement, vous pouvez créer un dépôt sur un autre disque.

• Sous Windows, par exemple :

restic init --repo D:\Sauvegardes\Restic

• Sous Linux :

restic init --repo /mnt/sauvegardes/restic

Lors de l’initialisation, Restic vous demande de définir un mot de passe. Celui-ci sert à chiffrer le contenu du dépôt.

• Choisissez un mot de passe solide et conservez-le précieusement. Sans ce mot de passe, il ne sera pas possible d’accéder aux sauvegardes ni de restaurer les fichiers.
• Le mot de passe ne peut pas être récupéré par Restic : conservez-en une copie dans un gestionnaire de mots de passe ou un emplacement sécurisé.
• Une fois le dépôt créé, Restic affiche un message confirmant son initialisation.
• Vous pouvez ensuite vérifier que le dépôt est accessible avec :

restic -r D:\Sauvegardes\Restic snapshots

• ou sous Linux :

restic -r /mnt/sauvegardes/restic snapshots

Comme aucune sauvegarde n’a encore été effectuée, la liste des snapshots sera vide.

À partir de ce moment, le repository est prêt à recevoir les premières sauvegardes. Lors des commandes suivantes, l’option -r ou --repo permet d’indiquer à Restic quel dépôt utiliser.

Sauvegarder un dossier avec Restic

Une fois le repository créé, vous pouvez lancer votre première sauvegarde avec la commande backup.

• Sous Windows, par exemple pour sauvegarder le dossier Documents :

restic -r D:\Sauvegardes\Restic backup C:\Users\VotreNom\Documents

• Sous Linux :

restic -r /mnt/sauvegardes/restic backup /home/votre_nom/Documents

Restic demande alors le mot de passe du repository, analyse les fichiers puis enregistre les données dans le dépôt.

À la fin de l’opération, un résumé indique notamment :

• le nombre de fichiers analysés ;
• le volume de données ajouté ;
• la quantité réellement stockée après déduplication ;
• la durée de la sauvegarde ;
• l’identifiant du nouveau snapshot.

Lors des sauvegardes suivantes, Restic ne recopie pas inutilement les données déjà présentes dans le repository. Il détecte les nouveaux fichiers et les blocs modifiés, ce qui réduit le temps de sauvegarde et l’espace utilisé.

Vous pouvez également sauvegarder plusieurs dossiers dans une seule commande :

restic -r D:\Sauvegardes\Restic backup C:\Users\VotreNom\Documents C:\Users\VotreNom\Pictures

Sous Linux :

restic -r /mnt/sauvegardes/restic backup /home/votre_nom/Documents /home/votre_nom/Images

Il est aussi possible de sauvegarder un dossier complet contenant plusieurs sous-dossiers. Restic parcourt automatiquement son contenu de manière récursive.

Par exemple :

restic -r D:\Sauvegardes\Restic backup C:\Users\VotreNom

Cette commande sauvegarde tout le profil utilisateur, sauf les éléments éventuellement exclus avec des options spécifiques.

Sauvegarder sans saisir le mot de passe à chaque fois

Vous pouvez aussi faire en sorte d’éviter de devoir saisir le mot de passe à chaque commande.
Voici deux méthodes différentes pour y parvenir.

Avec une variable

Pour éviter de saisir le chemin du repository à chaque commande, vous pouvez définir la variable d’environnement RESTIC_REPOSITORY.

Sous Linux :

export RESTIC_PASSWORD_FILE="/root/.restic-password"

Sous PowerShell :

$env:RESTIC_REPOSITORY="D:\Sauvegardes\Restic"

Vous pouvez ensuite lancer simplement :

restic backup C:\Users\VotreNom\Documents

Restic utilise alors automatiquement le repository défini dans la variable d’environnement.

Avec un fichier

Vous pouvez aussi stocker le mot de passe dans un fichier sur une seule ligne.
Par exemple C:\Restic\password.txt ou /root/.restic-password.

Sous Windows :

restic -r D:\Sauvegardes\Restic `
  --password-file C:\Restic\password.txt `
  backup C:\Users\VotreNom\Documents

Sous Linux :

restic -r /mnt/sauvegardes/restic \
  --password-file /root/.restic-password \
  backup /home/votre_nom/Documents

Lister les sauvegardes et snapshots

Restic conserve chaque sauvegarde sous la forme d’un snapshot. Un snapshot représente l’état des fichiers au moment où la commande backup a été exécutée.

Pour afficher la liste des sauvegardes disponibles, utilisez :

restic -r D:\Sauvegardes\Restic snapshots

Sous Linux :

restic -r /mnt/sauvegardes/restic snapshots

Restic affiche alors un tableau contenant notamment :

• l’identifiant du snapshot ;
• la date et l’heure de la sauvegarde ;
• le nom de l’ordinateur ;
• l’utilisateur ;
• les chemins sauvegardés.

L’identifiant du snapshot est particulièrement utile pour effectuer une restauration précise.

Par exemple, si Restic affiche un snapshot avec l’identifiant :

4f3a9c2b

Vous pourrez ensuite l’utiliser dans une commande de restauration.

Il est aussi possible d’afficher les informations détaillées d’un snapshot avec :

restic -r D:\Sauvegardes\Restic stats 4f3a9c2b

Pour afficher le contenu d’un snapshot sans restaurer les fichiers, utilisez :

restic -r D:\Sauvegardes\Restic ls 4f3a9c2b

Vous pouvez également utiliser le mot-clé latest pour cibler automatiquement la sauvegarde la plus récente :

restic -r D:\Sauvegardes\Restic ls latest

Cela évite d’avoir à recopier l’identifiant du dernier snapshot.

Enfin, si vous avez défini la variable RESTIC_REPOSITORY, la commande peut être simplifiée :

restic snapshots

Cette liste des snapshots permet de vérifier que les sauvegardes sont bien présentes et de choisir celle à utiliser pour restaurer des fichiers.

Restaurer des fichiers avec Restic

Restic permet de restaurer une sauvegarde complète ou seulement certains fichiers à partir d’un snapshot existant.

Pour restaurer le dernier snapshot disponible vers un dossier spécifique sous Windows :

restic -r D:\Sauvegardes\Restic restore latest --target C:\Restauration

Sous Linux :

restic -r /mnt/sauvegardes/restic restore latest --target /tmp/restauration

Restic recrée alors l’arborescence de la sauvegarde dans le dossier indiqué par --target.

Si vous souhaitez restaurer un snapshot précis, utilisez son identifiant :

restic -r D:\Sauvegardes\Restic restore 4f3a9c2b --target C:\Restauration

Vous pouvez retrouver les identifiants disponibles avec :

restic -r D:\Sauvegardes\Restic snapshots

Pour restaurer uniquement certains fichiers ou dossiers, utilisez l’option --include.

Par exemple :

restic -r D:\Sauvegardes\Restic restore latest --target C:\Restauration --include "/C/Users/VotreNom/Documents"

Vous pouvez également exclure certains éléments avec --exclude.

Par exemple :

restic -r D:\Sauvegardes\Restic restore latest --target C:\Restauration --exclude "*.tmp"

Avant de restaurer, il peut être utile d’afficher le contenu du snapshot :

restic -r D:\Sauvegardes\Restic ls latest

Cela permet de vérifier les chemins présents dans la sauvegarde et d’éviter de restaurer des données inutiles.

Une fois la restauration terminée, contrôlez le contenu du dossier cible avant de remplacer d’éventuels fichiers existants sur le système.

Pour une restauration importante, il est préférable de restaurer d’abord vers un dossier temporaire, puis de recopier manuellement les fichiers souhaités à leur emplacement d’origine. Cela limite le risque d’écraser par erreur une version plus récente d’un fichier.

Exclure des fichiers et dossiers de la sauvegarde

Lors d’une sauvegarde, il peut être utile d’exclure certains fichiers inutiles, temporaires ou volumineux afin de réduire la taille du repository et d’accélérer l’opération.

Restic propose pour cela l’option --exclude.

Par exemple, pour exclure tous les fichiers temporaires :

restic -r D:\Sauvegardes\Restic backup C:\Users\VotreNom --exclude "*.tmp"

Vous pouvez également exclure un dossier précis :

restic -r D:\Sauvegardes\Restic backup C:\Users\VotreNom --exclude "C:\Users\VotreNom\Downloads"

Plusieurs exclusions peuvent être ajoutées dans la même commande :

restic -r D:\Sauvegardes\Restic backup C:\Users\VotreNom `
  --exclude "*.tmp" `
  --exclude "*.log" `
  --exclude "C:\Users\VotreNom\Downloads"

Sous Linux, le principe est identique :

restic -r /mnt/sauvegardes/restic backup /home/votre_nom \
  --exclude "*.tmp" \
  --exclude "/home/votre_nom/Téléchargements"

Pour un grand nombre de règles, il est plus pratique d’utiliser un fichier d’exclusion.

Créez par exemple un fichier excludes.txt contenant :

*.tmp
*.log
Thumbs.db
C:\Users\VotreNom\Downloads
C:\Users\VotreNom\AppData\Local\Temp

Puis indiquez ce fichier à Restic :

restic -r D:\Sauvegardes\Restic backup C:\Users\VotreNom --exclude-file C:\Restic\excludes.txt

Cette méthode est particulièrement utile pour automatiser les sauvegardes, car vous pouvez modifier les règles d’exclusion sans avoir à réécrire toute la commande.

Avant d’exclure un dossier, vérifiez toutefois qu’il ne contient pas de données importantes. Une exclusion mal définie peut empêcher certains fichiers d’être présents dans les snapshots suivants.

Supprimer les anciennes sauvegardes avec forget et prune

Au fil du temps, Restic peut conserver de nombreux snapshots. Pour éviter que le repository ne grossisse indéfiniment, vous pouvez supprimer les anciennes sauvegardes selon une politique de rétention.

Restic utilise principalement deux commandes pour cela :

• forget : supprime les références aux snapshots devenus inutiles ;
• prune : supprime réellement du repository les données qui ne sont plus utilisées par aucun snapshot.

Il est donc important de comprendre que forget seul ne libère pas forcément immédiatement tout l’espace disque.

Pour afficher d’abord les snapshots disponibles :

restic -r D:\Sauvegardes\Restic snapshots

Vous pouvez ensuite supprimer un snapshot précis avec son identifiant :

restic -r D:\Sauvegardes\Restic forget 4f3a9c2b

Pour appliquer une politique de rétention automatique, utilisez les options --keep-*.

Par exemple, pour conserver :

• les 7 dernières sauvegardes quotidiennes ;
• les 4 dernières sauvegardes hebdomadaires ;
• les 6 dernières sauvegardes mensuelles ;

utilisez :

restic -r D:\Sauvegardes\Restic forget `
  --keep-daily 7 `
  --keep-weekly 4 `
  --keep-monthly 6

Sous Linux :

restic -r /mnt/sauvegardes/restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6

Cette commande supprime les snapshots qui ne correspondent plus aux règles de conservation, mais les blocs de données devenus inutiles peuvent encore rester dans le repository.

Pour réellement récupérer l’espace disque, lancez ensuite :

restic -r D:\Sauvegardes\Restic prune

Il est également possible d’effectuer les deux opérations en une seule commande :

restic -r D:\Sauvegardes\Restic forget `
  --keep-daily 7 `
  --keep-weekly 4 `
  --keep-monthly 6 `
  --prune

Cette méthode est particulièrement pratique dans un script de sauvegarde automatisé.

Avant de supprimer des snapshots, vérifiez toutefois que votre politique de rétention correspond bien à vos besoins. Une sauvegarde supprimée avec forget puis nettoyée avec prune ne pourra plus être restaurée.

Il est donc recommandé de commencer avec une rétention prudente, puis d’ajuster les valeurs en fonction de l’espace disponible et de la fréquence de vos sauvegardes.

Vérifier l’intégrité des sauvegardes avec restic check

Il est important de vérifier régulièrement que le repository Restic ne contient pas d’erreur et que les sauvegardes restent exploitables.

Pour cela, Restic propose la commande check.

Sous Windows :

restic -r D:\Sauvegardes\Restic check

Sous Linux :

restic -r /mnt/sauvegardes/restic check

Cette commande vérifie la structure du repository, les index, les snapshots et les références entre les différents objets stockés.

Si tout est correct, Restic termine l’analyse sans signaler d’erreur.

Pour effectuer une vérification plus poussée des données enregistrées, vous pouvez utiliser :

restic -r D:\Sauvegardes\Restic check --read-data

Cette option demande à Restic de lire les données présentes dans le repository afin de vérifier leur intégrité.

Attention toutefois : sur un repository volumineux, --read-data peut être beaucoup plus long qu’un simple check, car l’ensemble des données doit être parcouru.

Il est également possible de limiter la vérification à une partie des données, par exemple :

restic -r D:\Sauvegardes\Restic check --read-data-subset=10%

Cette méthode permet d’effectuer régulièrement un contrôle partiel sans relire tout le repository à chaque fois.

Dans une stratégie de sauvegarde sérieuse, vous pouvez par exemple :

• lancer restic check régulièrement ;
• effectuer ponctuellement un contrôle avec --read-data ;
• tester de temps en temps une restauration réelle de quelques fichiers.

En effet, une sauvegarde n’est réellement fiable que si elle peut être restaurée correctement. Vérifier le repository est donc utile, mais il est également recommandé de tester périodiquement une restauration vers un dossier temporaire.

Sauvegarder vers un disque externe, un NAS ou un serveur distant

Restic peut enregistrer ses sauvegardes sur différents types de destinations. Le repository n’a pas besoin de se trouver sur le disque principal du PC : il peut être stocké sur un disque USB, un NAS ou un serveur distant.

Sauvegarder sur un disque externe

Pour un disque USB ou un second disque interne, il suffit d’utiliser son chemin comme repository.

Sous Windows :

restic -r E:\ResticBackup backup C:\Users\VotreNom\Documents

Sous Linux :

restic -r /media/sauvegarde/restic backup /home/votre_nom/Documents

Cette solution est simple à mettre en place et convient bien pour conserver une copie hors du disque système.

Pour une meilleure protection contre les ransomwares ou une panne matérielle, évitez toutefois de laisser le disque externe connecté en permanence.

Sauvegarder sur un NAS

Si le NAS expose un partage réseau SMB ou NFS monté dans Windows ou Linux, Restic peut l’utiliser comme un dossier classique.

Sous Windows, avec un partage réseau monté sur Z: :

restic -r Z:\ResticBackup backup C:\Users\VotreNom\Documents

Vous pouvez aussi utiliser un chemin UNC :

restic -r \\NAS\Sauvegardes\Restic backup C:\Users\VotreNom\Documents

Sous Linux, si le partage du NAS est monté dans /mnt/nas :

restic -r /mnt/nas/restic backup /home/votre_nom/Documents

Le principe reste identique : le repository doit d’abord être créé avec restic init, puis vous pouvez utiliser la commande backup.

Sauvegarder sur un serveur distant avec SFTP

Restic prend également en charge les repositories accessibles en SFTP.

Par exemple :

restic -r sftp:utilisateur@serveur:/srv/restic backup /home/votre_nom/Documents

Sous Windows, le principe est identique depuis PowerShell si l’accès SSH au serveur est correctement configuré :

restic -r sftp:utilisateur@serveur:/srv/restic backup C:\Users\VotreNom\Documents

L’authentification peut s’effectuer avec un mot de passe SSH ou, de préférence, avec une clé SSH.

Avant la première sauvegarde, initialisez le repository distant :

restic -r sftp:utilisateur@serveur:/srv/restic init

Restic chiffre les données avant leur envoi. Le serveur distant stocke donc le contenu chiffré du repository.

Utiliser un stockage distant avec rclone

Restic peut aussi s’appuyer sur rclone pour accéder à de nombreux services de stockage cloud ou protocoles distants.

Après avoir configuré une destination dans rclone, vous pouvez par exemple utiliser :

restic -r rclone:remote:ResticBackup backup /home/votre_nom/Documents

Sous Windows :

restic -r rclone:remote:ResticBackup backup C:\Users\VotreNom\Documents

Cette méthode permet notamment d’utiliser les nombreux fournisseurs compatibles avec rclone sans que Restic ait besoin de gérer directement chacun d’eux.

Quelle destination choisir ?

Pour une sauvegarde locale simple, un disque externe est souvent suffisant. Un NAS est plus pratique pour automatiser les sauvegardes de plusieurs machines, tandis qu’un serveur distant ou un stockage cloud permet de conserver une copie hors du domicile ou de l’entreprise.

Pour une meilleure protection des données, l’idéal reste de disposer d’au moins une copie de sauvegarde stockée sur un support ou un emplacement différent du PC sauvegardé.

Automatiser les sauvegardes Restic

Restic se prête très bien à l’automatisation. Une fois la commande de sauvegarde définie, vous pouvez la lancer régulièrement avec le Planificateur de tâches de Windows, cron sous Linux ou un service systemd.

L’objectif est généralement d’exécuter automatiquement une commande de ce type :

restic -r D:\Sauvegardes\Restic backup C:\Users\VotreNom\Documents

Le principal point à gérer est le mot de passe du repository. Pour éviter une saisie manuelle à chaque exécution, vous pouvez utiliser un fichier contenant le mot de passe.

Par exemple :

C:\Restic\password.txt

Puis lancer Restic avec :

restic -r D:\Sauvegardes\Restic --password-file C:\Restic\password.txt backup C:\Users\VotreNom\Documents

Protégez soigneusement ce fichier, car toute personne pouvant le lire pourra ouvrir le repository.

Automatiser Restic sous Windows

Le plus pratique consiste à créer un script PowerShell, par exemple :

$repo = "D:\Sauvegardes\Restic"
$password = "C:\Restic\password.txt"
$source = "C:\Users\VotreNom\Documents"

restic -r $repo --password-file $password backup $source

Enregistrez-le par exemple sous :

C:\Restic\backup-restic.ps1

Vous pouvez ensuite créer une tâche planifiée :

• ouvrez le Planificateur de tâches ;
• cliquez sur Créer une tâche ;
• choisissez un déclencheur, par exemple tous les jours à 20 h ;
• dans Actions, ajoutez le programme powershell.exe ;
• utilisez comme argument :

-ExecutionPolicy Bypass -File "C:\Restic\backup-restic.ps1"

La sauvegarde sera alors exécutée automatiquement selon la fréquence choisie.

Ajouter une politique de rétention

Vous pouvez également nettoyer automatiquement les anciens snapshots après la sauvegarde.

Par exemple :

$repo = "D:\Sauvegardes\Restic"
$password = "C:\Restic\password.txt"
$source = "C:\Users\VotreNom\Documents"

restic -r $repo --password-file $password backup $source

restic -r $repo --password-file $password forget `
  --keep-daily 7 `
  --keep-weekly 4 `
  --keep-monthly 6 `
  --prune

Cette configuration conserve plusieurs générations de sauvegardes tout en évitant que le repository ne grossisse indéfiniment.

Automatiser Restic sous Linux avec cron

Sous Linux, vous pouvez créer un script :

#!/bin/bash

export RESTIC_REPOSITORY="/mnt/sauvegardes/restic"
export RESTIC_PASSWORD_FILE="/root/.restic-password"

restic backup /home/votre_nom/Documents
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Rendez-le exécutable :

chmod +x /usr/local/bin/backup-restic.sh

Puis ouvrez la crontab :

crontab -e

Par exemple, pour lancer la sauvegarde chaque jour à 2 h :

0 2 * * * /usr/local/bin/backup-restic.sh

Conserver un journal des sauvegardes

Pour une tâche automatisée, il est conseillé de conserver les sorties de Restic afin de pouvoir vérifier qu’une sauvegarde s’est bien déroulée.

Sous Windows :

restic -r $repo --password-file $password backup $source *>> C:\Restic\restic.log

Sous Linux :

restic backup /home/votre_nom/Documents >> /var/log/restic.log 2>&1

Vous pourrez ainsi consulter le journal en cas d’échec ou vérifier la date de la dernière sauvegarde réussie.

Enfin, même avec une automatisation parfaitement configurée, contrôlez régulièrement la présence des snapshots avec restic snapshots et testez ponctuellement une restauration. Une tâche qui s’exécute automatiquement ne garantit pas à elle seule que les sauvegardes sont réellement exploitables.

Quelques commandes Restic utiles

Restic propose de nombreuses commandes pour gérer les sauvegardes, consulter les snapshots, restaurer des fichiers ou entretenir le repository. Voici les principales à connaître.

Afficher la version installée :

restic version

Créer un nouveau repository :

restic -r /chemin/du/repository init

Sauvegarder un dossier :

restic -r /chemin/du/repository backup /chemin/a/sauvegarder

Afficher les snapshots disponibles :

restic -r /chemin/du/repository snapshots

Afficher le contenu du dernier snapshot :

restic -r /chemin/du/repository ls latest

Afficher des statistiques sur un snapshot :

restic -r /chemin/du/repository stats latest

Restaurer le dernier snapshot :

restic -r /chemin/du/repository restore latest --target /chemin/restauration

Restaurer un snapshot précis :

restic -r /chemin/du/repository restore ID_DU_SNAPSHOT --target /chemin/restauration

Sauvegarder en excluant certains fichiers :

restic -r /chemin/du/repository backup /chemin/a/sauvegarder --exclude "*.tmp"

Utiliser un fichier d’exclusions :

restic -r /chemin/du/repository backup /chemin/a/sauvegarder --exclude-file excludes.txt

Supprimer un ancien snapshot :

restic -r /chemin/du/repository forget ID_DU_SNAPSHOT

Appliquer une politique de rétention :

restic -r /chemin/du/repository forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6

Supprimer les données devenues inutiles dans le repository :

restic -r /chemin/du/repository prune

Appliquer la rétention et nettoyer le repository en une seule commande :

restic -r /chemin/du/repository forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6 \
  --prune

Vérifier la structure et l’intégrité du repository :

restic -r /chemin/du/repository check

Effectuer une vérification complète des données :

restic -r /chemin/du/repository check --read-data

Vérifier seulement une partie des données :

restic -r /chemin/du/repository check --read-data-subset=10%

Enfin, si vous avez défini la variable RESTIC_REPOSITORY, vous pouvez simplifier les commandes et omettre l’option -r :

restic snapshots
restic backup /chemin/a/sauvegarder
restic check

Ces commandes couvrent l’essentiel des opérations courantes avec Restic : création du dépôt, sauvegarde, restauration, gestion des snapshots et vérification des données.

Restic : avantages et limites

Restic est une solution de sauvegarde particulièrement intéressante si vous recherchez un outil léger, fiable, chiffré et facilement automatisable.

Ses principaux avantages sont :

• le chiffrement intégré : les sauvegardes sont protégées avant leur stockage ;
• la déduplication : les blocs déjà présents dans le repository ne sont pas recopiés inutilement ;
• les snapshots : il est possible de conserver plusieurs états successifs des fichiers ;
• la compatibilité multiplateforme : Restic fonctionne sous Windows, Linux et macOS ;
• le support de nombreuses destinations : disque local, disque USB, NAS, serveur SFTP ou stockage distant via rclone ;
• la simplicité de l’automatisation : les commandes peuvent facilement être intégrées à PowerShell, cron ou systemd ;
• la vérification d’intégrité : la commande restic check permet de contrôler régulièrement l’état du repository ;
• la restauration sélective : il est possible de restaurer un snapshot complet ou seulement certains fichiers.

Restic présente toutefois quelques limites.

La principale est son fonctionnement essentiellement en ligne de commande. Pour un utilisateur habitué aux logiciels de sauvegarde avec interface graphique, la prise en main peut demander un petit temps d’adaptation.

La gestion du mot de passe du repository demande également de la rigueur. Si vous perdez ce mot de passe, les données chiffrées ne pourront plus être restaurées.

Les opérations d’entretien comme forget, prune ou check --read-data peuvent aussi devenir longues sur de gros repositories, en particulier lorsque le stockage est distant ou relativement lent.

Enfin, Restic sauvegarde avant tout des fichiers et dossiers. Ce n’est pas un logiciel d’image système complet destiné à restaurer Windows entier, les partitions, le secteur de démarrage et toutes les applications après une panne de disque.
Il ne remplace donc pas une image système si votre objectif est de restaurer Windows, les partitions et le démarrage après une panne complète du disque
 À lire :

Restic convient donc très bien pour :

• sauvegarder régulièrement ses documents et données personnelles ;
• conserver plusieurs versions de fichiers ;
• envoyer des sauvegardes chiffrées vers un NAS ou un serveur distant ;
• automatiser une stratégie de sauvegarde avec des scripts.

En revanche, si votre objectif est de pouvoir restaurer intégralement un PC après une panne du disque système, il est préférable de compléter Restic avec une sauvegarde d’image système.

Restic est donc particulièrement adapté aux utilisateurs qui recherchent une solution de sauvegarde sobre, sécurisée et scriptable, à condition d’être à l’aise avec quelques commandes.

L’article Restic : sauvegarder et restaurer ses fichiers sous Windows et Linux est apparu en premier sur malekal.com.

Windows 11 26H2 est la prochaine mise à jour de fonctionnalités de Windows 11. Microsoft a commencé à la proposer dans le canal Release Preview du programme Windows Insider, dernière étape de test avant sa diffusion au grand public.

Cette version permet donc de découvrir et tester Windows 11 26H2 avant sa sortie officielle, avec un niveau de maturité plus élevé que les builds distribuées dans les canaux Dev ou Beta.

Il est actuellement possible d’installer Windows 11 26H2 en rejoignant le canal Release Preview, ou de récupérer une image ISO à partir des fichiers Microsoft avec UUP Dump afin d’effectuer une mise à niveau ou une installation propre.

Dans ce tutoriel, vous allez voir comment télécharger et installer Windows 11 26H2, créer une image ISO, effectuer une mise à niveau ou une installation propre et vérifier que la nouvelle version est correctement installée.

Lorsque Microsoft publiera officiellement Windows 11 26H2, ce guide sera complété avec les méthodes grand public : Windows Update, package d’activation, Assistant d’installation et ISO officiel Microsoft.

Méthode 1 : installer Windows 11 26H2 avec Windows Update (Release Preview)

Windows 11 26H2 est désormais disponible dans le canal Release Preview du programme Windows Insider. Si votre PC respecte les exigences matérielles de Windows 11, vous pouvez installer cette version directement depuis Windows Update, sans télécharger d’image ISO. Microsoft propose actuellement 26H2 via une installation volontaire depuis Windows Update.

Rejoindre le canal Release Preview

Si votre PC n’est pas encore inscrit au programme Windows Insider :

• ouvrez Paramètres ;
• rendez-vous dans Windows Update > Programme Windows Insider ;
• cliquez sur Prise en main ;
• associez le compte Microsoft utilisé pour le programme Windows Insider ;
• sélectionnez le canal Release Preview ;
• acceptez les conditions proposées ;
• redémarrez le PC lorsque Windows vous le demande.

Le canal Release Preview est généralement le plus approprié pour tester une prochaine version de Windows proche de sa sortie publique.

Installer Windows 11 26H2

Une fois le PC inscrit dans le canal Release Preview :

• ouvrez Paramètres > Windows Update ;
• cliquez sur Rechercher des mises à jour ;
• Windows 11, version 26H2 doit apparaître lorsqu’elle est disponible pour votre appareil ;
• cliquez sur Télécharger et installer ;
• laissez Windows télécharger et préparer la mise à niveau ;
• redémarrez le PC lorsque cela est demandé.

Microsoft indique que Windows 11 26H2 est actuellement proposé aux Insiders Release Preview via cette méthode dite « seeker » : la mise à jour n’est pas installée automatiquement, l’utilisateur choisit explicitement de la télécharger et de l’installer.

L’installation conserve normalement vos fichiers personnels, applications et paramètres, comme lors d’une mise à niveau classique de Windows 11.

Après le redémarrage, le PC fonctionne sous Windows 11 26H2 et continuera de recevoir les mises à jour cumulatives habituelles via Windows Update.

Méthode 2 : télécharger et installer Windows 11 26H2 avec une ISO

À l’heure actuelle, Microsoft ne propose pas encore d’ISO officielle de Windows 11 26H2 destinée au grand public. En revanche, Windows 11 26H2 est disponible dans le canal Release Preview du programme Windows Insider.

Si vous souhaitez disposer d’une image ISO pour effectuer une mise à niveau, une installation propre ou tester Windows 11 26H2 dans une machine virtuelle, vous pouvez utiliser UUP Dump. Ce service permet de récupérer les fichiers de mise à jour publiés par Microsoft puis de générer automatiquement une image ISO exploitable.

UUP Dump constitue donc pour l’instant la méthode la plus pratique pour obtenir une ISO de Windows 11 26H2 Release Preview avant la publication des images officielles par Microsoft.

Télécharger l’ISO Windows 11 26H2 avec UUP Dump

• Cliquez sur ce lien :

• Sélectionnez la version correspondant à votre langue et à votre architecture (généralement x64)
• Choisissez l’édition souhaitée (Famille, Professionnel, etc.)
• Sélectionnez l’option permettant de télécharger et convertir les fichiers en ISO
• Téléchargez l’archive générée par UUP Dump

Le guide complet :

Créer l’image ISO Windows 11 26H2

Une fois le téléchargement terminé :

• Décompressez l’archive téléchargée
• Ouvrez le dossier extrait
• Exécutez le script uup_download_windows.cmd
• Patientez pendant le téléchargement des fichiers Microsoft
• Attendez la génération automatique de l’image ISO. Selon votre connexion Internet et les performances du PC, l’opération peut prendre plusieurs dizaines de minutes.
• Le message finished vous indique lorsque l’opération est terminée

À la fin du processus, l’image ISO Windows 11 26H2 est créée dans le dossier de travail et peut être utilisée pour une mise à niveau ou une installation propre de Windows.

• Faites un clic droit sur le fichier ISO puis Monter

Installer Windows 11 26H2

Une fois l’image ISO téléchargée et la clé USB créée, vous pouvez installer Windows 11 26H2 Insider sur votre ordinateur. Deux méthodes sont possibles : effectuer une mise à niveau afin de conserver vos applications et vos fichiers, ou réaliser une installation propre pour repartir sur un système neuf.

Les précautions avant d’installer une version Insider

Les versions Insider Preview permettent de tester les futures fonctionnalités de Windows avant leur sortie officielle. Toutefois, elles peuvent contenir des bugs, des problèmes de stabilité ou des incompatibilités avec certains logiciels et pilotes.

Avant d’installer Windows 11 26H2 Insider, il est recommandé de :

• Sauvegarder vos données importantes
• Vérifier la compatibilité de votre PC avec Windows 11
• Installer la version sur un PC secondaire ou une machine virtuelle lorsque cela est possible
• Prévoir une solution de retour vers une version stable de Windows

Pour connaître l’ensemble des vérifications et préparatifs recommandés avant une installation ou une mise à niveau de Windows 11, consultez ce guide :

Le guide complet :

Si vous recherchez avant tout la stabilité et la fiabilité, il est préférable d’attendre la version finale de Windows 11 26H2 qui sera distribuée via Windows Update après sa publication officielle par Microsoft.

Installer Windows 11 26H2 par mise à niveau

La mise à niveau permet de conserver vos applications, paramètres et fichiers personnels tout en passant à la version 26H2.

Pour cela :

• Montez l’image ISO de Windows 11 26H2 en effectuant un double-clic dessus
• Ouvrez le lecteur virtuel créé dans l’Explorateur de fichiers
• Lancez le programme Setup.exe
• Cliquez sur Suivant
• Acceptez les conditions d’utilisation
• Vérifiez que l’option Conserver les fichiers personnels et les applications est sélectionnée
• Lancez l’installation

L’ordinateur redémarre plusieurs fois pendant la procédure. Une fois l’opération terminée, vous retrouvez votre environnement habituel sous Windows 11 26H2.

Effectuer une installation propre de Windows 11 26H2

Une installation propre efface complètement le contenu de la partition système afin d’installer une nouvelle copie de Windows. Cette méthode permet de repartir sur une base saine mais nécessite de réinstaller les applications après l’installation.

Pour effectuer une installation propre :

• Démarrez le PC sur la clé USB d’installation
• Sélectionnez la langue et les paramètres régionaux
• Cliquez sur Installer maintenant
• Saisissez votre clé produit ou cliquez sur Je n’ai pas de clé de produit
• Choisissez l’édition de Windows 11 à installer
• Sélectionnez Installation personnalisée
• Choisissez la partition système
• Poursuivez l’installation

Après plusieurs redémarrages, l’assistant de configuration de Windows vous permet de créer votre compte utilisateur et de finaliser l’installation.

Le guide :

Vérifier que Windows 11 26H2 est correctement installé

Une fois l’installation terminée, il est conseillé de vérifier que la bonne version de Windows est installée.

Pour cela :

• Appuyez sur Windows + R
• Saisissez winver
• Validez avec Entrée

La fenêtre d’informations doit afficher Windows 11 version 26H2 ainsi que le numéro de build correspondant à la version Insider installée.

Les autres méthodes dans ce tutoriel :

Revenir à une version stable de Windows

Si vous rencontrez des problèmes de stabilité ou de compatibilité avec une build Insider, il peut être nécessaire de revenir à une version stable de Windows 11.

Selon la méthode utilisée pour l’installation et le délai écoulé depuis la mise à niveau, vous pouvez restaurer la version précédente ou réinstaller une version stable à partir d’une image ISO officielle.

Comment installer Windows 11 26H2 après sa sortie officielle

Lorsque Microsoft publiera la version finale de Windows 11 26H2, plusieurs méthodes permettront d’installer la mise à jour sur un PC compatible.

Vous pourrez notamment :

• Installer Windows 11 26H2 via Windows Update
• Utiliser l’Assistant d’installation de Windows 11
• Télécharger l’ISO officielle de Windows 11 26H2
• Effectuer une mise à niveau ou une installation propre

Cette section sera mise à jour lors de la disponibilité générale de Windows 11 26H2 avec les procédures détaillées et les liens de téléchargement officiels.

L’article Windows 11 26H2 : télécharger et installer la mise à jour est apparu en premier sur malekal.com.

Microsoft déploie la mise à jour facultative KB5120998 pour Windows 11 24H2 et 25H2. Il s’agit de l’une des mises à jour Preview les plus riches de ces derniers mois, avec plusieurs changements très attendus concernant la barre des tâches, le menu Démarrer et Windows Search.

Mais quelques heures seulement après sa disponibilité, les premiers retours font état de problèmes gênants : fond d’écran remplacé par un arrière-plan noir, curseur de souris modifié ou impossible à personnaliser, et quelques autres comportements anormaux.

Comme KB5120998 est une mise à jour facultative, il peut donc être judicieux d’attendre avant de l’installer.

KB5120998 pour Windows 11 24H2 et 25H2

Microsoft a publié KB5120998 le 27 août 2026 comme mise à jour cumulative facultative de prévisualisation.

Elle fait passer :

• Windows 11 24H2 à la build 26100.9278 ;
• Windows 11 25H2 à la build 26200.9278.

Elle est proposée depuis :

• Paramètres > Windows Update
• puis Rechercher des mises à jour.

Comme il s’agit d’une mise à jour Preview, son installation n’est normalement pas obligatoire. Toutefois, elle peut être récupérée automatiquement si vous avez activé l’option : Recevez les dernières mises à jour dès qu’elles sont disponibles

Les correctifs et fonctionnalités de KB5120998 devraient ensuite être intégrés à une future mise à jour cumulative obligatoire.

Une des mises à jour les plus importantes de l’année pour l’interface

KB5120998 contient plusieurs fonctionnalités qui étaient jusqu’ici testées dans les versions Insider de Windows 11.

La plus visible concerne la barre des tâches.

Microsoft permet enfin de choisir son emplacement sur l’écran :

• en bas ;
• en haut ;
• à gauche ;
• à droite.

Cette possibilité existait sous Windows 10 mais avait disparu lors du lancement de Windows 11.

Le réglage se trouve dans :

Paramètres > Personnalisation > Barre des tâches > Comportements de la barre des tâches

Une nouvelle option Position de la barre des tâches permet alors de choisir son emplacement.

La barre des tâches peut également devenir réellement plus petite

Windows 11 disposait déjà d’options permettant de réduire certains éléments ou boutons, mais la hauteur de la barre des tâches restait largement inchangée.

KB5120998 introduit une véritable barre des tâches compacte, plus proche du fonctionnement proposé autrefois par Windows 10.

L’objectif est notamment d’occuper moins de place sur les petits écrans et d’afficher davantage d’applications simultanément.

Microsoft continue donc de réintroduire progressivement des possibilités de personnalisation qui avaient disparu lors de la transition vers Windows 11.

Le menu Démarrer devient redimensionnable

Autre changement attendu : le menu Démarrer peut désormais être affiché dans différentes tailles.

• Dans : Paramètres > Personnalisation > Démarrer
• Windows permet notamment de choisir un affichage plus petit ou plus grand.

Jusqu’ici, les dimensions du menu étaient principalement déterminées par Windows selon la résolution et la mise à l’échelle de l’écran.

Cette nouveauté devrait être particulièrement appréciable sur les ordinateurs portables, où le nouveau menu Démarrer pouvait occuper une partie importante de l’écran.

Il devient possible de masquer davantage de sections du menu Démarrer

Microsoft donne également plus de contrôle sur le contenu affiché.

Selon les fonctionnalités disponibles sur votre appareil, vous pourrez notamment masquer certaines sections comme :

• les applications épinglées ;
• les éléments récents ou recommandés ;
• la liste des applications ;
• le nom et l’image du compte utilisateur.

Il devient ainsi possible d’obtenir un menu Démarrer beaucoup plus minimaliste.

Microsoft a par ailleurs dissocié certains paramètres du menu Démarrer des autres fonctions de Windows.

Auparavant, désactiver les recommandations ou éléments récents pouvait aussi avoir un impact sur certaines fonctions de l’Explorateur de fichiers ou les listes de raccourcis de la barre des tâches.

Ce comportement est désormais mieux séparé.

Windows Search peut enfin fonctionner sans Bing

C’est probablement l’une des nouveautés les plus intéressantes de KB5120998.

Windows 11 permet désormais de désactiver les résultats Web provenant de Bing dans Windows Search.

Il est également possible de supprimer les suggestions provenant du Microsoft Store.

Une fois ces options désactivées, la recherche Windows peut donc se concentrer essentiellement sur les contenus locaux :

• applications ;
• fichiers ;
• photos ;
• paramètres Windows.

Les réglages se trouvent dans :

Paramètres > Confidentialité et sécurité > Recherche

Cette évolution est notable car Microsoft a longtemps imposé très fortement Bing dans la recherche Windows.

Elle arrive d’ailleurs au moment où l’entreprise développe parallèlement son application Paramètres de recherche recommandés Microsoft, destinée à proposer Bing comme moteur de recherche dans Chrome, Firefox ou Brave.

La stratégie de Microsoft autour de Bing reste donc assez particulière : davantage de contrôle dans Windows d’un côté, mais toujours beaucoup d’efforts pour promouvoir son moteur de recherche de l’autre.

La recherche Windows devient aussi plus claire

Microsoft ne se contente pas d’ajouter des interrupteurs pour Bing.

La présentation des résultats évolue également afin de mieux identifier leur provenance.

Windows doit notamment mieux différencier :

• les résultats locaux ;
• les applications ;
• les paramètres ;
• les contenus Web ;
• les suggestions du Microsoft Store.

Microsoft affirme également avoir amélioré la pertinence générale de la recherche.

Certaines fonctions restent toutefois soumises à un déploiement progressif.

De nombreuses fonctionnalités arrivent progressivement

C’est un point important avec KB5120998.

Même après avoir installé la mise à jour, vous ne verrez pas nécessairement immédiatement toutes les nouvelles options.

Microsoft utilise une nouvelle fois son système de Controlled Feature Rollout (CFR).

Le code correspondant aux nouvelles fonctionnalités peut donc être présent sur votre PC, mais Microsoft active les nouveautés par vagues.

Deux ordinateurs disposant exactement de la même version de Windows et de la même KB peuvent ainsi afficher des options différentes pendant plusieurs jours ou semaines.

Il ne faut donc pas considérer l’absence de la nouvelle position de la barre des tâches ou du menu Démarrer redimensionnable comme un échec de l’installation.

WMIC disparaît définitivement

KB5120998 accompagne également la dernière étape de la suppression de WMIC.

À partir d’août 2026, Windows 11 24H2 et 25H2 n’incluent plus l’utilitaire :

wmic.exe

et celui-ci n’est plus disponible sous forme de fonctionnalité à la demande (Feature on Demand).

Il ne pourra donc plus être simplement réinstallé depuis les fonctionnalités facultatives de Windows.

Attention toutefois : WMI lui-même n’est pas supprimé.

Seule l’ancienne interface en ligne de commande WMIC disparaît.

Pour les scripts modernes, Microsoft recommande notamment PowerShell et :

Get-CimInstance

 À lire :

D’autres améliorations sont également intégrées

Les notes de Microsoft associées à KB5120998 mentionnent également des changements ou correctifs concernant plusieurs composants du système.

On trouve notamment des améliorations autour de :

• l’Explorateur de fichiers ;
• la saisie et les périphériques d’entrée ;
• Windows Update ;
• le Gestionnaire des tâches ;
• les graphismes ;
• le pavé tactile ;
• Narrateur ;
• l’IME japonais ;
• la recherche Outlook ;
• certains mécanismes de sécurité et d’administration.

Microsoft poursuit également le déploiement de changements plus techniques, notamment autour de la cryptographie post-quantique et de certains mécanismes d’isolation.

Toutes ces nouveautés n’arrivent cependant pas nécessairement simultanément sur tous les PC.

Le téléchargement hors ligne peut approcher les 5 Go

KB5120998 est également disponible dans le Microsoft Update Catalog pour une installation manuelle avec un fichier .msu.

Les packages complets sont particulièrement volumineux.

• Pour les systèmes x64, le Catalogue Microsoft affiche environ 4,96 Go.
• Pour les systèmes ARM64, la taille est d’environ 4,80 Go.

Cela ne signifie pas que Windows Update téléchargera nécessairement autant de données.

Windows Update utilise des mécanismes différentiels et ne récupère que les composants réellement nécessaires au système.

L’installation via le Catalogue Microsoft est donc surtout utile lorsqu’une mise à jour échoue via Windows Update ou pour certains scénarios de déploiement hors ligne.

Mais KB5120998 provoque déjà des problèmes chez certains utilisateurs

Quelques heures après le déploiement de la mise à jour, de nombreux utilisateurs ont signalé des comportements anormaux.

Les deux problèmes les plus fréquemment rapportés concernent : le curseur de la souris et le fond d’écran.

Plusieurs témoignages convergent vers le même comportement après installation de la build 26200.9278 ou 26100.9278.

Le curseur de la souris peut être remplacé par un ancien style

Certains utilisateurs indiquent que KB5120998 remplace leur curseur habituel par un curseur blanc plus grand au style ancien.

Dans certains cas, le curseur rappelle visuellement celui des anciennes versions de Windows.

Plus problématique : les réglages permettant normalement de changer le style, la couleur ou parfois la taille du pointeur ne semblent plus fonctionner correctement.

Des utilisateurs indiquent avoir essayé :

• de redémarrer Windows ;
• de relancer l’Explorateur ;
• de modifier les paramètres d’accessibilité ;
• de sélectionner un autre thème de pointeur dans le Panneau de configuration.

Le curseur normal reste néanmoins affiché.

Un détail intéressant ressort également de certains témoignages : le problème toucherait surtout le pointeur dans son état normal, tandis que les curseurs d’attente ou d’activité peuvent momentanément reprendre une apparence différente.

Notificacions Microsoft Defender Antivirus est désactivé

Un autre bug constaté sous Windows, mais apparemment sans lien avec une mise à jour du système d’exploitation, concerne Microsoft Defender. Après la mise à jour de la solution de sécurité, plusieurs utilisateurs reçoivent des notifications indiquant que « Microsoft Defender Antivirus est désactivé », alors qu’il est bien actif.

Bien que cela puisse paraître un bug mineur, Microsoft indique qu‘il se produit après chaque redémarrage de Windows pour certains utilisateurs et que les notifications arrivent même si elles ont été désactivées, ce qui est particulièrement gênant.
Ce problème semble affecter toutes les versions prises en charge des éditions client et serveur de Windows 10 et Windows 11. Microsoft précise qu’une enquête est en cours et que de plus amples informations seront communiquées dès que possible.

Le fond d’écran peut devenir complètement noir

Autre problème largement signalé : après l’installation de KB5120998, le papier peint du Bureau disparaît et est remplacé par un fond noir uni.

Le problème semble plus facile à contourner que celui du pointeur.

• Dans plusieurs cas, il suffit de sélectionner à nouveau son image depuis : Paramètres > Personnalisation > Arrière-plan
• pour restaurer le fond d’écran.

Cependant, certains utilisateurs indiquent que le problème peut réapparaître après une déconnexion ou un redémarrage.

Les témoignages ne concernent pas tous les PC.

De nombreux utilisateurs ont installé KB5120998 sans rencontrer ces problèmes.

D’autres problèmes sont rapportés, mais avec moins de certitude

Quelques utilisateurs mentionnent également :

• des problèmes de son ;
• une webcam ne fonctionnant plus ;
• des anomalies d’affichage avec certains navigateurs ;
• des erreurs d’installation telles que 0x800f0922 ;
• des problèmes avec DISM.

Ces retours sont actuellement beaucoup moins nombreux.

Il serait donc prématuré de considérer tous ces comportements comme des bugs généralisés directement causés par KB5120998.

Les problèmes du curseur et du fond d’écran noir sont en revanche rapportés par suffisamment d’utilisateurs indépendants pour mériter une attention particulière.

Microsoft n’a pas encore reconnu officiellement ces bugs

Au moment de la rédaction de cet article, Microsoft n’a pas encore ajouté les problèmes de curseur et de fond d’écran aux problèmes connus officiels de Windows 11 24H2 ou 25H2.

Il faut donc encore rester prudent sur leur ampleur exacte.

Les rapports montrent néanmoins une corrélation forte avec KB5120998 : plusieurs utilisateurs expliquent que les problèmes apparaissent immédiatement après son installation et disparaissent après son retrait.

Cela ne signifie pas pour autant que tous les PC sont concernés.

Désinstaller KB5120998 permet de corriger le problème chez plusieurs utilisateurs

Pour les personnes affectées par le curseur impossible à personnaliser, plusieurs témoignages indiquent que désinstaller KB5120998 restaure immédiatement le comportement normal.

• Vous pouvez procéder depuis : Paramètres > Windows Update > Historique des mises à jour > Désinstaller des mises à jour
• Repérez ensuite : KB5120998
• puis choisissez de la désinstaller.

Un redémarrage est nécessaire.

Plus de détails :

Comme il s’agit d’une mise à jour facultative non liée à la sécurité, sa désinstallation ne retire pas les correctifs de sécurité du Patch Tuesday du 11 août.

C’est une différence importante avec KB5121003, qui contenait notamment les correctifs de sécurité du mois.

Faut-il installer KB5120998 ?

Pour le moment, je conseillerais de ne pas se précipiter.

KB5120998 contient des nouveautés réellement intéressantes, en particulier :

• la barre des tâches déplaçable ;
• la barre des tâches plus compacte ;
• le menu Démarrer redimensionnable ;
• la possibilité de masquer davantage de sections ;
• la recherche Windows débarrassée de Bing et des résultats du Microsoft Store.

Mais cette mise à jour est précisément une Preview facultative.

Sa fonction est aussi de permettre à Microsoft d’exposer les changements à davantage d’utilisateurs avant leur intégration dans une mise à jour mensuelle obligatoire.

Compte tenu des problèmes de curseur et de fond d’écran déjà observés, il n’y a actuellement aucun avantage essentiel à l’installer immédiatement sur un PC de production.

Vous pouvez parfaitement attendre la prochaine mise à jour cumulative, en espérant que Microsoft corrige ces régressions d’ici là.

Et si vous voulez absolument tester les nouveautés ?

Si vous souhaitez malgré tout tester la barre des tâches déplaçable ou le nouveau menu Démarrer, assurez-vous au minimum d’avoir :

• sauvegardé vos travaux ;
• créé éventuellement un point de restauration ;
• vérifié que vous savez désinstaller une mise à jour Windows ;
• conservé en tête que toutes les nouveautés sont en déploiement progressif.

Il est également inutile d’installer manuellement le package .msu de près de 5 Go simplement pour tenter d’obtenir plus rapidement les fonctionnalités.

Le déploiement CFR est indépendant de la présence du package lui-même.

Conclusion

KB5120998 est probablement l’une des mises à jour Windows 11 les plus intéressantes de 2026 en matière de personnalisation.

Microsoft réintroduit enfin la possibilité de déplacer la barre des tâches, permet de réduire réellement sa taille, donne davantage de contrôle sur le menu Démarrer et autorise désormais la désactivation de Bing dans Windows Search.

Mais le lancement est déjà entaché de plusieurs bugs.

Des utilisateurs de Windows 11 24H2 et 25H2 rapportent notamment un curseur de souris bloqué sur un ancien style blanc et surdimensionné, ainsi qu’un fond d’écran remplacé par du noir.

Comme KB5120998 est facultative et ne contient pas les correctifs de sécurité du mois, attendre quelques jours avant de l’installer paraît actuellement être le choix le plus prudent.

Les utilisateurs déjà touchés peuvent quant à eux envisager sa désinstallation, qui semble restaurer le curseur et l’arrière-plan dans les cas rapportés.

L’article Windows 11 KB5120998 : grosse mise à jour Preview avec barre des tâches déplaçable, menu Démarrer personnalisable… mais déjà des bugs est apparu en premier sur malekal.com.

Microsoft développe une nouvelle application Windows baptisée Microsoft Recommended Search Settings, ou Paramètres de recherche recommandés Microsoft en français.

Son rôle est simple : proposer à l’utilisateur de remplacer son moteur de recherche actuel par Microsoft Bing dans plusieurs navigateurs installés sur le PC, notamment Google Chrome, Mozilla Firefox et Brave.

L’outil peut également modifier la page d’accueil et la page Nouvel onglet afin d’afficher Bing et les contenus Microsoft associés.

Face aux critiques provoquées par sa découverte, Microsoft assure toutefois que cette application est entièrement facultative et qu’elle ne sera pas installée automatiquement avec Windows 11 ou Microsoft Edge.

Une application dédiée à la promotion de Bing

L’application a été découverte et testée par WindowsLatest.

L’exécutable porte le nom MicrosoftSettings.exe et pèse environ 22,2 Mo.

Contrairement à ce que son nom pourrait laisser penser, il ne s’agit pas de l’application Paramètres de Windows.

Microsoft Recommended Search Settings est un programme distinct dont la fonction principale consiste à proposer l’utilisation de Bing comme moteur de recherche par défaut.

Lors de son lancement, l’utilisateur est accueilli par un écran proposant d’appliquer les paramètres de recherche recommandés par Microsoft.

L’option permettant de passer à Bing est activée dans l’interface, mais l’utilisateur doit accepter explicitement l’opération avant que les modifications soient effectuées.

L’application ajoute une entrée « Microsoft Recommended Search Settings » au démarrage de Windows

C:\Users\maill\AppData\Local\Temp\msrdfe6abc09-2f83-4e8f-8e92-6264e64ed53c\MSRecommendationDaemon.exe

Enfin, celle-ci peut être désinstallée facilement.

Chrome, Firefox et Brave peuvent être modifiés

L’application ne se limite pas à Microsoft Edge.

WindowsLatest a testé le programme avec Google Chrome et Brave.

Après validation par l’utilisateur, Microsoft Recommended Search Settings ajoute une extension appelée :

Microsoft Bing Homepage & Search

Cette extension peut notamment modifier :

• le moteur de recherche par défaut ;
• la page d’accueil ;
• la page de démarrage ;
• la page Nouvel onglet.

Dans Chrome, le navigateur affiche également ses propres avertissements indiquant qu’une extension vient de changer les paramètres de recherche.

Brave, qui repose lui aussi sur Chromium, peut être traité de manière similaire.

Mozilla Firefox fait également partie des navigateurs visés par Microsoft.

Microsoft affirme que rien n’est imposé

C’est le point que Microsoft a tenu à clarifier.

Interrogé par WindowsLatest, un porte-parole de l’entreprise indique que l’application est facultative et doit être installée volontairement.

Microsoft précise également qu’elle :

• n’est pas distribuée par Windows ;
• n’est pas installée par Microsoft Edge ;
• ne modifie pas les réglages sans consentement ;
• permet de revenir aux paramètres précédents à tout moment.

Microsoft indique donc qu’il ne s’agit pas d’un mécanisme caché destiné à remplacer Google ou Brave Search à l’insu de l’utilisateur.

Chrome tente même de restaurer Google

Le test réalisé par WindowsLatest montre une situation assez inhabituelle.

Après l’installation de l’extension Microsoft, Chrome détecte que son moteur de recherche a été remplacé par Bing et propose à l’utilisateur de revenir à Google Search.

Microsoft affiche alors à son tour une fenêtre encourageant l’utilisateur à conserver Bing.

Cela donne donc une sorte de bataille d’interfaces :

Microsoft propose Bing → Chrome propose de revenir à Google → Microsoft recommande de conserver Bing.

Cette mécanique illustre l’importance stratégique des moteurs de recherche pour les éditeurs de navigateurs et de systèmes d’exploitation.

Microsoft Rewards apparaît également à la fin de l’installation

Une fois la configuration terminée, l’application ouvre également une page liée à Microsoft Rewards.

Ce programme permet de gagner des points en utilisant certains services Microsoft, notamment Bing.

Microsoft combine donc ici plusieurs leviers pour encourager l’utilisateur à adopter son moteur de recherche :

Bing + extension navigateur + page d’accueil + Microsoft Rewards.

Ce choix n’est pas forcément surprenant : les moteurs de recherche représentent un marché considérable, notamment en raison des revenus publicitaires générés par les recherches Web.

Microsoft utilise déjà ce type de campagne dans Edge

Ce genre d’incitation n’est pas complètement nouveau.

Microsoft dispose déjà d’une stratégie Edge appelée DefaultBrowserSettingsCampaignEnabled, traduite par :

Activer les campagnes de paramètres de navigateur par défaut.

Lorsque cette politique est active, Edge peut proposer à l’utilisateur de :

• définir Microsoft Edge comme navigateur par défaut ;
• utiliser Microsoft Bing comme moteur de recherche par défaut.

Microsoft précise toutefois que les paramètres ne sont modifiés que si l’utilisateur accepte la proposition.

La nouvelle application va plus loin puisqu’elle cible également les navigateurs concurrents installés sur le PC.

Est-ce que cette application existe aussi en Europe ?

C’est actuellement la grande inconnue.

WindowsLatest a pu installer et tester l’application depuis les serveurs de téléchargement de Microsoft, mais Microsoft n’a pas encore précisé dans quels pays ou marchés elle sera proposée.

Je n’ai trouvé aucune documentation Microsoft indiquant que Microsoft Recommended Search Settings serait :

• réservée aux États-Unis ;
• disponible mondialement ;
• ou spécifiquement bloquée en Europe.

Il serait donc prématuré d’affirmer que les utilisateurs européens ne la verront jamais.

En revanche, le contexte réglementaire européen est particulier.

Pourquoi Microsoft pourrait être plus prudent en Europe

Dans l’Espace économique européen, Microsoft doit composer avec un cadre réglementaire beaucoup plus strict, notamment le Digital Markets Act (DMA). Ce règlement vise entre autres à éviter que les grandes plateformes favorisent excessivement leurs propres services au détriment du choix de l’utilisateur.

Microsoft a déjà dû adapter Windows dans ce sens. Dans l’EEE, Windows Search peut désormais faire appel à des fournisseurs de recherche web tiers, alors qu’en dehors de cette zone Bing reste beaucoup plus profondément intégré. L’entreprise a également commencé à donner davantage de contrôle sur certains éléments liés à la recherche dans Windows.

C’est ce qui rend l’arrivée de Paramètres de recherche recommandés Microsoft assez paradoxale.

D’un côté, Microsoft ouvre progressivement Windows à davantage de choix, en particulier en Europe. De l’autre, l’entreprise propose un utilitaire spécifiquement conçu pour remplacer le moteur de recherche de Chrome, Firefox ou Brave par Bing, modifier la page d’accueil et la page Nouvel onglet, puis promouvoir Microsoft Rewards.

Ces deux démarches ne sont pas réellement contradictoires sur le plan juridique. Microsoft présente son utilitaire comme facultatif et exige une action de l’utilisateur avant d’appliquer les changements. Il ne s’agit donc pas, en l’état, d’un remplacement silencieux imposé directement par Windows.

Mais du point de vue de l’utilisateur, la stratégie peut sembler difficile à suivre : Microsoft donne davantage de liberté dans Windows tout en développant parallèlement de nouveaux moyens de pousser Bing dans les navigateurs concurrents.

Le contexte européen pourrait donc inciter Microsoft à être plus prudent sur la manière de distribuer ou de promouvoir cet outil. Une installation automatique, un choix difficile à refuser ou une modification insuffisamment explicite des paramètres d’un navigateur concurrent attirerait probablement davantage l’attention des autorités européennes.

À ce stade, rien ne permet toutefois d’affirmer que l’application est interdite en Europe ou qu’elle y sera bloquée. Microsoft n’a pas encore précisé si son déploiement variera selon les régions.

L’outil serait-il interdit en Europe ?

Pas nécessairement.

Il faut distinguer plusieurs situations.

Une application optionnelle qui propose clairement « Utiliser Bing comme moteur de recherche ? » et qui ne procède au changement qu’après consentement de l’utilisateur n’est pas automatiquement contraire au droit européen.

Le problème réglementaire serait davantage susceptible de se poser si Microsoft :

• installait automatiquement l’application ;
• rendait l’option Bing difficile à refuser ;
• modifiait les paramètres d’un navigateur concurrent sans consentement réel ;
• ou utilisait Windows pour favoriser Bing d’une façon considérée comme déloyale.

Microsoft insiste justement sur le fait que l’application n’est pas distribuée avec Windows ou Edge et requiert le consentement de l’utilisateur. Cette formulation n’est probablement pas anodine compte tenu de l’attention réglementaire portée aux paramètres par défaut.

Il serait toutefois spéculatif d’affirmer que Microsoft a conçu ce fonctionnement spécifiquement pour éviter une sanction européenne.

Microsoft a déjà dû adapter Windows en Europe

Le sujet est d’autant plus sensible que Microsoft a déjà apporté plusieurs modifications à Windows pour répondre aux exigences européennes.

La Commission européenne indique qu’à la suite de discussions réglementaires, Microsoft a notamment facilité la définition et l’utilisation effective d’un navigateur Web par défaut sur Windows.

Le système Windows est donc déjà différent dans certains domaines selon que l’utilisateur se trouve ou non dans l’EEE.

Cela rend plausible un comportement différent de Microsoft Recommended Search Settings selon les régions.

Mais, à ce stade, aucune différence géographique concernant cette nouvelle application n’a été confirmée.

Google utilise lui aussi des techniques similaires

WindowsLatest rappelle également que Microsoft n’est pas seul à tenter d’orienter les utilisateurs vers ses propres produits.

Google affiche régulièrement des messages invitant les utilisateurs :

• à installer Chrome ;
• à définir Chrome comme navigateur par défaut ;
• à conserver Google comme moteur de recherche.

Chrome a d’ailleurs immédiatement réagi lors du test de l’application Microsoft en proposant de rétablir Google Search.

La concurrence autour des moteurs de recherche et des navigateurs repose donc largement sur ce type de sollicitations.

La différence notable ici est que Microsoft a développé une application Windows indépendante dédiée à cette tâche, capable d’agir sur plusieurs navigateurs concurrents.

Faut-il s’inquiéter de Microsoft Recommended Search Settings ?

Pour le moment, pas particulièrement.

Microsoft affirme que le logiciel :

• n’est pas préinstallé ;
• ne sera pas installé par Windows Update ;
• n’est pas injecté par Edge ;
• nécessite une installation volontaire ;
• demande le consentement avant de modifier les paramètres.

Il ne s’agit donc pas actuellement d’une nouvelle fonctionnalité automatique de Windows 11.

La principale interrogation concerne plutôt la manière dont Microsoft compte proposer cette application aux utilisateurs.

Le logiciel n’est actuellement pas disponible de manière classique dans le Microsoft Store et Microsoft n’a pas précisé comment les utilisateurs seront amenés à le découvrir.

Ce point sera particulièrement intéressant à surveiller.

Conclusion

Microsoft a donc développé Microsoft Recommended Search Settings, une application Windows destinée à promouvoir Bing dans les principaux navigateurs concurrents.

Une fois installée et acceptée, elle peut modifier le moteur de recherche, la page d’accueil et la page Nouvel onglet de Chrome, Firefox et Brave grâce à une extension Microsoft.

Face aux critiques, Microsoft affirme cependant que tout est facultatif et qu’aucun paramètre n’est modifié sans consentement.

La situation européenne reste pour l’instant incertaine.

Aucune information ne permet d’affirmer que l’application est réservée aux États-Unis ou bloquée en Europe. Mais le Digital Markets Act impose à Microsoft davantage de contraintes concernant le choix des navigateurs et moteurs de recherche dans l’EEE, ce qui pourrait pousser l’entreprise à adopter une approche différente ou plus prudente sur le marché européen.

Il faudra surtout surveiller comment Microsoft compte distribuer et promouvoir cette application, car c’est probablement là que se situera l’enjeu réglementaire principal.

L’article Microsoft Teste un outil Windows 11 pour remplacer Google par Bing dans Chrome, Firefox et Brave est apparu en premier sur malekal.com.

Microsoft poursuit le nettoyage des anciens composants de Windows 11. À partir de la mise à jour Preview d’août 2026, WMIC disparaît de Windows 11 24H2 et 25H2.

L’ancien utilitaire wmic.exe, utilisé pendant des années pour interroger et administrer Windows depuis l’invite de commandes, ne sera plus seulement désactivé : il sera désormais supprimé du système et ne pourra plus être réinstallé comme fonctionnalité facultative.

Cette suppression concerne uniquement WMIC, l’interface historique en ligne de commande. La technologie Windows Management Instrumentation (WMI), sur laquelle reposent encore de nombreux outils d’administration et scripts PowerShell, reste quant à elle pleinement prise en charge.

WMIC disparaît avec la mise à jour Preview d’août 2026

Microsoft a confirmé ce changement dans les notes de publication des builds Release Preview 26100.9267 pour Windows 11 24H2 et 26200.9267 pour Windows 11 25H2.

À compter d’août 2026, ces versions de Windows 11 n’incluent plus l’utilitaire Windows Management Instrumentation Command-line (WMIC).

Le changement doit être intégré à la mise à jour facultative Preview d’août 2026, avant d’être repris dans une future mise à jour cumulative obligatoire.

Concrètement, après installation de cette évolution, cette commande :

wmic

ne fonctionnera plus.

Les scripts anciens contenant par exemple :

wmic cpu get name

ou :

wmic diskdrive get model,size

devront être adaptés.

Certaines commandes WMIC avaient déjà été désactivées dans Windows 11, vous pouvez alors rencontrer le message d’erreur suivant :

ERREUR : Description = Erreur non spécifiée

Une disparition annoncée depuis plusieurs années

La suppression de WMIC est loin d’être une surprise.

Microsoft organise son retrait depuis près de dix ans.

La chronologie est la suivante :

• 2016 : WMIC est déclaré obsolète dans Windows Server 2012 ;
• 2021 : Microsoft déprécie WMIC dans Windows 10 21H2 ;
• 2022 : sous Windows 11 22H2, WMIC devient une Feature on Demand (FoD), mais reste préinstallé et activé par défaut ;
• 2024 : WMIC est désactivé par défaut sur Windows 11 23H2 et 24H2, mais peut encore être ajouté manuellement ;
• 2025 : lors du passage à Windows 11 25H2, WMIC est supprimé s’il était installé, tout en restant réinstallable comme fonctionnalité facultative ;
• 2026 : Microsoft retire complètement WMIC de Windows 11. Il n’est désormais plus disponible comme Feature on Demand.

Windows 11 26H1 est également concerné par cette suppression.

Le changement prévu pour 24H2 et 25H2 constitue donc la dernière étape d’un processus commencé plusieurs années auparavant.

WMIC et WMI ne sont pas la même chose

Cette distinction est essentielle.

WMI n’est pas supprimé de Windows.

WMI, pour Windows Management Instrumentation, est une infrastructure de gestion permettant à Windows, aux applications et aux administrateurs d’interroger de nombreuses informations sur le système :

• processeur ;
• mémoire ;
• disques ;
• services ;
• processus ;
• matériel ;
• système d’exploitation ;
• réseau ;
• événements et paramètres système.

WMIC, pour sa part, n’était qu’une interface en ligne de commande permettant d’accéder à WMI.

On peut donc représenter le fonctionnement ainsi :

WMIC.exe   ↓WMI   ↓Windows

Microsoft retire uniquement la première couche.

Les applications utilisant directement les API WMI, PowerShell ou CIM ne sont donc pas concernées par la disparition de wmic.exe.

Pourquoi Microsoft supprime WMIC ?

WMIC est un composant ancien, basé sur une méthode d’administration qui n’est plus recommandée par Microsoft.

L’utilitaire date d’une époque où l’administration Windows reposait largement sur l’invite de commandes et les scripts batch.

Depuis, Microsoft privilégie notamment :

• Windows PowerShell ;
• les cmdlets CIM ;
• les API modernes de gestion Windows.

PowerShell permet notamment d’obtenir des données structurées sous forme d’objets, alors que WMIC renvoie principalement du texte qu’il faut ensuite analyser dans les scripts.

Microsoft recommande depuis plusieurs années PowerShell pour remplacer WMIC.

Comment remplacer les commandes WMIC ?

La plupart des commandes WMIC courantes possèdent un équivalent PowerShell.

Par exemple, cette ancienne commande :

wmic cpu get name

peut être remplacée par :

Get-CimInstanceWin32_Processor|Select-ObjectName

Pour obtenir les informations des disques :

wmic diskdrive get model,size

devient :

Get-CimInstanceWin32_DiskDrive|Select-ObjectModel, Size

Pour afficher le système d’exploitation :

wmic os get caption,version

on peut utiliser :

Get-CimInstanceWin32_OperatingSystem|Select-ObjectCaption, Version

Et pour obtenir le numéro de série du PC :

wmic bios get serialnumber

l’équivalent est :

Get-CimInstanceWin32_BIOS|Select-ObjectSerialNumber

Dans la majorité des cas, Get-CimInstance est le remplaçant naturel de WMIC.

Get-CimInstance plutôt que Get-WmiObject

Il existe également une ancienne cmdlet PowerShell :

Get-WmiObject

Elle permet elle aussi d’interroger WMI.

Mais pour les nouveaux scripts, il vaut mieux privilégier :

Get-CimInstance

Les cmdlets CIM utilisent une infrastructure plus récente et constituent aujourd’hui la méthode recommandée.

Un script encore basé sur Get-WmiObject n’est donc pas nécessairement cassé par la disparition de WMIC, mais sa modernisation vers les cmdlets CIM peut être pertinente.

Quels utilisateurs seront réellement concernés ?

Pour la majorité des utilisateurs de Windows 11, la disparition de WMIC sera totalement transparente.

Peu d’utilisateurs saisissent encore directement des commandes wmic.

Le principal risque concerne plutôt :

• les anciens scripts .bat et .cmd ;
• certains scripts d’administration ;
• des outils de diagnostic anciens ;
• des programmes qui exécutent directement wmic.exe ;
• des procédures techniques publiées il y a plusieurs années.

Un logiciel qui tente de lancer :

C:\Windows\System32\wbem\WMIC.exe

pour récupérer des informations système pourra donc cesser de fonctionner correctement.

Les développeurs et administrateurs ont intérêt à rechercher dès maintenant les appels à wmic dans leurs scripts.

Windows 11 25H2 avait déjà commencé à retirer WMIC

Windows 11 25H2 avait constitué une étape intermédiaire.

Lors de l’installation de cette mise à jour de fonctionnalités, WMIC était désinstallé s’il était présent.
Microsoft permettait néanmoins encore de le réinstaller avec les fonctionnalités facultatives ou avec DISM.

L’entreprise déconseillait déjà cette opération, puisqu’elle annonçait une suppression définitive à venir.
Avec la modification d’août 2026, cette possibilité disparaît à son tour.

WMIC ne pourra plus être réinstallé

C’est probablement le changement le plus important par rapport aux étapes précédentes.

Jusqu’ici, lorsqu’un ancien script nécessitait WMIC, il restait possible d’ajouter le composant comme Feature on Demand.

Après son retrait complet, ce ne sera plus le cas.

Microsoft indique explicitement que WMIC n’est plus disponible sous forme de Feature on Demand.

• Il ne faudra donc pas compter sur : Paramètres > Système > Fonctionnalités facultatives
• ou sur DISM pour le restaurer durablement.

La solution consiste désormais à adapter les scripts et les logiciels qui en dépendent.

Une nouvelle étape dans le nettoyage des composants hérités de Windows

WMIC rejoint une liste grandissante de technologies historiques progressivement retirées de Windows.

Microsoft a notamment supprimé ou entrepris de supprimer plusieurs composants anciens, dont Windows PowerShell 2.0.

L’objectif est à la fois de réduire la surface de maintenance du système et d’encourager l’utilisation d’interfaces plus modernes et mieux prises en charge.

Dans le cas de WMIC, Microsoft a laissé une période de transition particulièrement longue : l’outil avait été officiellement déprécié dès l’époque de Windows 10.

Sa disparition définitive de Windows 11 24H2 et 25H2 marque donc surtout la fin d’une migration engagée depuis plusieurs années.

Que faut-il faire ?

Si vous n’utilisez jamais la commande wmic, vous n’avez rien à faire.

En revanche, si vous administrez des PC ou conservez d’anciens scripts, recherchez les occurrences de :

wmic.exe

et remplacez-les par des commandes PowerShell modernes, généralement basées sur :

Get-CimInstance

Il est particulièrement important de vérifier les scripts batch automatisés : ils peuvent continuer à fonctionner pendant des années sans intervention humaine et devenir subitement défaillants lorsque wmic.exe disparaît.

Conclusion

Microsoft va donc supprimer définitivement WMIC de Windows 11 24H2 et 25H2 à partir des mises à jour d’août 2026.

Cette évolution clôt un processus de dépréciation commencé plusieurs années auparavant.

Pour la plupart des utilisateurs, elle passera inaperçue. En revanche, les administrateurs, développeurs et utilisateurs de vieux scripts doivent vérifier qu’ils ne dépendent plus directement de wmic.exe.

Et surtout, cette suppression ne signifie pas la disparition de WMI : Windows Management Instrumentation reste pris en charge. Seul son ancien client en ligne de commande WMIC tire sa révérence.

L’article Microsoft supprime définitivement WMIC de Windows 11 24H2 et 25H2 est apparu en premier sur malekal.com.

Microsoft apporte de nouvelles précisions sur les problèmes de jeux apparus après l’installation de KB5121003, la mise à jour du Patch Tuesday d’août 2026 pour Windows 11.

L’entreprise confirme désormais que les plantages, blocages et redémarrages observés sur certains PC sont liés à des périphériques ou composants internes équipés d’un éclairage RGB. Ces appareils peuvent installer des pilotes ou composants portant des noms proches de inpoutx64, déjà identifié quelques jours plus tôt par Embark Studios comme étant au cœur des plantages.

Les jeux cités par Microsoft sont notamment ARC Raiders, MARVEL Tōkon: Fighting Souls et THE FINALS. Les symptômes comprennent des blocages, des fermetures brutales, des erreurs EXCEPTION_ACCESS_VIOLATION et, dans certains cas, un redémarrage inattendu du PC.

Lire l’actualité :

Microsoft reconnaît officiellement le problème

Jusqu’ici, Microsoft indiquait seulement enquêter sur les problèmes rencontrés après la mise à jour KB5121003.

La situation a évolué : le problème figure désormais officiellement dans le tableau de bord Windows Release Health pour Windows 11 24H2 et 25H2.

Microsoft indique que les investigations en cours montrent un lien avec des périphériques externes ou des composants internes disposant de fonctions d’éclairage RGB.

Ces appareils peuvent installer des pilotes ou composants système portant des noms similaires à inpoutx64. Lorsqu’un de ces pilotes est présent, le lancement de certains jeux peut déclencher le dysfonctionnement.

Le RGB lui-même n’est pas vraiment responsable

Il faut toutefois éviter un raccourci.

Ce n’est pas l’éclairage RGB en lui-même qui fait planter les jeux.

Le problème vient plutôt des logiciels et pilotes utilisés pour contrôler ces périphériques.

Les logiciels RGB ont souvent besoin d’accéder directement à certains composants matériels afin de contrôler :

• les LED ;
• les ventilateurs ;
• les capteurs ;
• les tensions ;
• certaines fonctions de la carte mère ;
• différents périphériques USB ou internes.

Pour cela, certains fabricants utilisent des pilotes fonctionnant à un niveau très privilégié dans Windows.

C’est précisément le cas de composants de type inpoutx64, qui peuvent accéder directement aux ports d’entrée/sortie du matériel.

La mise à jour KB5121003 semble avoir modifié un comportement du noyau Windows qui entre désormais en conflit avec certains de ces pilotes.

inpoutx64.sys confirmé une nouvelle fois

Le nom inpoutx64.sys n’est pas nouveau dans cette affaire.

Quelques jours après le déploiement du Patch Tuesday d’août, Embark Studios avait déjà identifié ce fichier comme responsable de plantages touchant certains joueurs de THE FINALS et ARC Raiders.

Le studio indiquait alors qu’un changement apporté avec KB5121003 avait provoqué une incompatibilité avec ce pilote.

Embark avait également publié une solution temporaire consistant à arrêter le service inpoutx64, à le supprimer puis à retirer le fichier inpoutx64.sys du dossier des pilotes Windows.

La nouvelle communication de Microsoft confirme donc en grande partie cette analyse, tout en élargissant le problème aux périphériques et composants RGB susceptibles d’installer ce type de pilote.

Quels périphériques peuvent être concernés ?

Microsoft ne publie pas de liste précise de marques ou de modèles concernés.

Le problème peut potentiellement toucher différents types de matériels disposant d’un éclairage RGB, notamment :

• claviers ;
• souris ;
• casques ;
• boîtiers ;
• ventilateurs ;
• systèmes de refroidissement ;
• cartes mères ;
• contrôleurs RGB ;
• périphériques gaming.

Ce sont surtout les logiciels de contrôle associés qui doivent être examinés.

Un utilisateur peut donc rencontrer le problème sans même savoir qu’un pilote comme inpoutx64.sys a été installé sur sa machine.

Le pilote peut avoir été ajouté automatiquement avec un utilitaire constructeur destiné à gérer l’éclairage, les ventilateurs ou d’autres fonctions matérielles.

Pourquoi un logiciel RGB utilise-t-il un pilote noyau ?

Cela peut paraître surprenant qu’un simple logiciel d’éclairage dispose d’un pilote fonctionnant dans le noyau Windows.

La raison est essentiellement matérielle.

Pour modifier directement certaines LED, lire des capteurs ou communiquer avec des contrôleurs intégrés à la carte mère, une application peut avoir besoin d’un accès de bas niveau au matériel.

Une application Windows classique s’exécute en mode utilisateur, où ses permissions sont volontairement limitées.

Un pilote noyau peut, en revanche, communiquer directement avec le matériel.

Cette architecture offre davantage de possibilités, mais elle augmente aussi les risques.

Si un pilote fonctionne mal ou devient incompatible avec une nouvelle version de Windows, les conséquences peuvent aller bien au-delà du logiciel RGB lui-même :

• plantage d’une application ;
• corruption mémoire ;
• instabilité du système ;
• écran bleu ;
• redémarrage du PC.

C’est précisément le type de situation rencontré ici.

Pourquoi les jeux déclenchent-ils le problème ?

C’est encore l’une des questions auxquelles Microsoft tente de répondre.

Le pilote peut être présent en permanence sur le PC sans provoquer de symptôme particulier.

Le problème apparaît ensuite lorsque certains jeux sont lancés.

Microsoft explique travailler à comprendre précisément la relation entre les composants RGB et les jeux concernés.

Une hypothèse plausible est qu’un jeu ou son système anti-triche sollicite certaines fonctions du noyau qui entrent alors en conflit avec le pilote RGB.

Les anti-triches modernes utilisent souvent eux aussi des composants fonctionnant dans le noyau afin de détecter les modifications mémoire, les injections de code ou les pilotes suspects.

La combinaison :

jeu + anti-triche + pilote RGB + modification du noyau apportée par KB5121003

peut ainsi créer une incompatibilité qui n’apparaît pas dans un usage classique de Windows.

Microsoft n’a toutefois pas encore publié de détails techniques permettant de confirmer précisément ce mécanisme.

Quels jeux sont concernés ?

Microsoft cite actuellement trois titres :

• ARC Raiders ;
• MARVEL Tōkon: Fighting Souls ;
• THE FINALS.

Sur les systèmes affectés, les symptômes peuvent inclure :

• le jeu qui ne répond plus ;
• une fermeture sans message ;
• une erreur EXCEPTION_ACCESS_VIOLATION ;
• un redémarrage inattendu du PC.

Cela ne signifie pas que seuls ces trois jeux peuvent être touchés.

Ils correspondent simplement aux cas suffisamment documentés pour être cités par Microsoft à ce stade.

Windows 11 24H2 et 25H2 sont concernés

Le problème affecte :

• Windows 11 24H2 ;
• Windows 11 25H2.

Il est apparu après l’installation des mises à jour publiées à partir du 11 août 2026, notamment KB5121003.

Windows Server n’est pas concerné.

Le problème reste cependant limité aux machines où les composants ou pilotes incompatibles sont présents.

La majorité des PC ayant installé KB5121003 ne rencontrent donc aucun problème.

Microsoft propose désormais sa propre solution temporaire

Dans notre précédent article, Embark recommandait de supprimer complètement le service et le fichier inpoutx64.sys.

Microsoft propose désormais une méthode moins radicale : désactiver temporairement le pilote depuis le Registre Windows.

La procédure officielle est la suivante.

• Sur votre clavier, appuyez sur les touches + R
• Puis saisissez regedit et OK. Plus de détails :
  comment accéder au registre Windows
• Rendez-vous ensuite dans :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\inpoutx64

• Repérez la valeur :

Start

• Double-cliquez dessus puis définissez la valeur sur : 4
• Redémarrez ensuite l’ordinateur.
• La valeur 4 indique à Windows de désactiver le démarrage du pilote.

Microsoft recommande auparavant de sauvegarder le Registre ou de créer un point de restauration.

Désactiver le pilote peut supprimer certaines fonctions RGB

Cette solution a toutefois une contrepartie.

Si inpoutx64 est utilisé par le logiciel contrôlant votre éclairage RGB, sa désactivation peut empêcher certaines fonctions de fonctionner correctement.

Vous pouvez par exemple perdre :

• le contrôle des couleurs ;
• certains effets lumineux ;
• la gestion de ventilateurs ;
• la lecture de certains capteurs ;
• certaines fonctions proposées par l’utilitaire constructeur.

Microsoft précise que si cela se produit, il est possible de restaurer la précédente valeur du Registre afin de réactiver le pilote.

La solution doit donc être utilisée principalement par les joueurs réellement concernés par les plantages.

Faut-il toujours supprimer inpoutx64.sys ?

Pas forcément.

La procédure proposée par Embark reste efficace selon le studio : arrêter le service, supprimer son enregistrement puis supprimer physiquement le fichier permet de résoudre les plantages de THE FINALS.

Mais maintenant que Microsoft propose officiellement de désactiver le pilote, cette méthode est préférable dans un premier temps.

Elle présente plusieurs avantages :

• elle ne supprime aucun fichier ;
• elle est facilement réversible ;
• elle permet de confirmer que le pilote est bien responsable ;
• elle évite de casser définitivement le logiciel qui l’utilise.

La suppression complète du pilote peut rester une solution si celui-ci appartient à un logiciel inutile ou obsolète.

Mettre à jour le logiciel RGB peut aussi résoudre le problème

Avant de modifier le Registre, il est également recommandé de vérifier si une nouvelle version du logiciel RGB est disponible.

Le fabricant peut publier une mise à jour contenant :

• un pilote plus récent ;
• une version compatible avec KB5121003 ;
• un autre mécanisme d’accès au matériel.

Dans ce cas, la mise à jour du logiciel constitue une solution plus propre que la désactivation du pilote.

Vous pouvez donc vérifier les mises à jour de logiciels comme ceux utilisés pour gérer :

• les périphériques gaming ;
• les cartes mères ;
• les ventilateurs ;
• les systèmes RGB.

Si vous n’utilisez plus l’utilitaire ayant installé le pilote, sa désinstallation peut également être envisagée.

Il ne faut toujours pas désinstaller KB5121003 sans raison

Même si KB5121003 est à l’origine de l’apparition du problème, sa désinstallation n’est pas la solution à privilégier.

Cette mise à jour correspond au Patch Tuesday d’août 2026 et contient de nombreux correctifs de sécurité importants.

Microsoft a corrigé environ 400 vulnérabilités, dont plusieurs zero-day.

Retirer la mise à jour permet éventuellement de contourner le problème, mais expose à nouveau Windows aux vulnérabilités corrigées.

Il est donc préférable de :

• mettre à jour les logiciels RGB ;
• identifier la présence de inpoutx64 ;
• désactiver temporairement le pilote ;
• attendre un correctif Microsoft ou constructeur.

La désinstallation de KB5121003 ne devrait être utilisée qu’en dernier recours.

A lire :

Microsoft poursuit encore son enquête

Le problème n’est pas encore considéré comme définitivement résolu.

Microsoft indique continuer à analyser la relation entre :

• les périphériques RGB ;
• leurs pilotes ;
• inpoutx64 ;
• les jeux concernés.

L’entreprise publiera de nouvelles informations lorsque cette relation sera mieux comprise.

Cela signifie qu’un futur correctif Windows pourrait encore être nécessaire.

Les fabricants de périphériques peuvent également devoir mettre à jour leurs propres pilotes.

Un problème qui illustre les risques des pilotes noyau

Cet incident dépasse finalement largement la simple question des lumières RGB.

Il illustre une nouvelle fois le problème posé par la multiplication des pilotes tiers fonctionnant dans le noyau Windows.

Un logiciel destiné à modifier la couleur d’un clavier ou d’un ventilateur peut installer un composant bénéficiant de privilèges extrêmement importants.

Ce composant devient alors partie intégrante de la stabilité du système.

Lorsqu’une mise à jour Windows modifie le fonctionnement du noyau, un ancien pilote peut soudainement devenir incompatible et provoquer des plantages dans des applications qui, en apparence, n’ont aucun rapport avec lui.

C’est également l’une des raisons pour lesquelles Microsoft cherche aujourd’hui à améliorer la qualité des pilotes Windows et à déplacer davantage de composants vers le mode utilisateur lorsque l’accès au noyau n’est pas indispensable.

Conclusion

Microsoft confirme désormais que les plantages de jeux apparus après KB5121003 sont liés, sur certaines configurations, aux périphériques ou composants RGB et aux pilotes qu’ils installent.

Le fichier inpoutx64.sys, déjà identifié par Embark Studios, reste au centre des investigations.

Le problème affecte notamment ARC Raiders, THE FINALS et MARVEL Tōkon: Fighting Souls sous Windows 11 24H2 et 25H2, avec des symptômes pouvant aller d’un simple blocage du jeu jusqu’au redémarrage complet du PC.

En attendant une correction définitive, Microsoft recommande désormais de désactiver temporairement le pilote inpoutx64 depuis le Registre.

Il est néanmoins préférable de commencer par mettre à jour les logiciels de contrôle RGB et de ne modifier le pilote que si votre PC rencontre réellement ces problèmes.

Cette affaire montre surtout qu’un simple logiciel destiné à gérer l’éclairage d’un périphérique peut dépendre d’un pilote noyau suffisamment privilégié pour perturber la stabilité de Windows après une mise à jour.

L’article Windows 11 : Microsoft relie les plantages de jeux de KB5121003 aux périphériques RGB est apparu en premier sur malekal.com.

Windows 11 et Windows 10 intègrent le Moniteur de ressources et de performances, un outil capable d’effectuer automatiquement un diagnostic rapide du PC. La commande perfmon /report lance une collecte prédéfinie puis génère un Rapport de diagnostics du système regroupant les principales informations sur le fonctionnement de Windows.

Le rapport examine notamment le processeur, la mémoire RAM, le stockage, le réseau, les pilotes, les périphériques et les services, puis signale les éventuels avertissements ou anomalies détectés pendant la collecte.

Cette fonction ne doit pas être confondue avec l’Analyseur de performances (PerfMon) classique. Celui-ci permet de choisir précisément les compteurs à surveiller et de les enregistrer dans le temps, tandis que perfmon /report réalise un diagnostic automatique avec des contrôles prédéfinis par Windows.

Dans ce guide, découvrez comment utiliser perfmon /report sous Windows 11/10, générer un rapport avec le Moniteur de ressources et de performances, interpréter les résultats et connaître les limites de ce diagnostic.

Qu’est-ce que perfmon /report ?

La commande perfmon /report permet de lancer automatiquement un diagnostic du système Windows et de générer un rapport sur le fonctionnement et les performances du PC.

Contrairement à l’Analyseur de performances classique, où vous devez choisir vous-même les compteurs à surveiller, perfmon /report utilise un ensemble de contrôles prédéfinis par Windows. Il constitue donc une méthode plus simple pour obtenir rapidement un premier état du système.

L’intérêt de perfmon /report est donc de ne pas avoir à déterminer au préalable quels compteurs PerfMon surveiller. Windows effectue une collecte prédéfinie puis organise les résultats dans un rapport plus facile à parcourir.

Il faut toutefois distinguer les deux usages :

• Analyseur de performances (PerfMon) → surveiller et enregistrer précisément des compteurs choisis par l’utilisateur
• perfmon /report → effectuer un diagnostic prédéfini et générer automatiquement un rapport

Le rapport ne remplace donc pas une analyse approfondie lorsqu’un problème est intermittent ou complexe, mais il constitue un bon premier diagnostic intégré à Windows, sans installer de logiciel supplémentaire.

Comment générer un rapport de diagnostic système

PerfMon permet de générer automatiquement un rapport de diagnostic des performances de Windows. Cette fonction est pratique pour obtenir rapidement un état du système sans avoir à ajouter et surveiller manuellement de nombreux compteurs.

Pour lancer le diagnostic :

• Appuyez sur Windows + R pour ouvrir Exécuter.
• Saisissez la commande suivante :

perfmon /report

• Validez par Entrée.
• Windows collecte les informations du système pendant environ une minute.
• Une fois la collecte terminée, le Rapport de diagnostics du système s’affiche.

Le rapport regroupe différentes informations concernant notamment le processeur, la mémoire, les disques, le réseau, les pilotes et les services Windows. Il peut également signaler certaines erreurs ou situations nécessitant une vérification.

Alternative possible en ligne de commandes :

Comment interpréter les avertissements et résultats

Le diagnostic du système permet de vérifier certains composants de Windows et quelques composants matériels.
Il permet donc d’avoir une vue générale de Windows et de détecter des anomalies ou problèmes.

Dans le rapport de diagnostic du système, on obtient les catégories suivantes :

• Rapports du diagnostics du système : il s’agit des informations sur le diagnostic avec le délai de l’analyse et informations de version de Windows.
• Résultats du diagnostic.
  • Avertissements : dans le cas où Windows a détecté des anomalies.
  • Vérification système de base : divers éléments de Windows sont vérifiés.
• Configuration du logiciel : on retrouve des informations logiciels tels que les informations du centre de sécurité de Windows avec l’antivirus par défaut, pare-feu de Windows, Windows Update. Enfin on trouve aussi les programmes au démarrage de Windows.
• Configuration matérielle : ce sont les informations matérielles comme le BIOS de l’ordinateur, informations SMART du disque dur et autres éléments.
• Processeur : l’utilisation processeur par divers applications et les services windows en cours de fonctionnement
• Disque : information sur l’utilisation disque avec les processus qui effectuent le plus d’entrée/sortie sur le disque
• Statistique de rapport : Information générale sur Windows et l’ordinateur.

Ci-dessous, les catégories du rapport d’un diagnostic système

Et le rapport d’un diagnostic de performance moins complet.

Les divers tests comme le centre de sécurité, le disque dur avec les remontés SMART pour vérifier si le disque a des problèmes matériels. Plus d’informations : comment vérifier la santé des disques dur
Si des problèmes sont détectés, les pastilles passent en rouge sinon elles resteront vertes.

Les vérifications systèmes de bases.

Les informations logicielles avec les programmes au démarrage.

Les fichiers qui sollicitent le plus le disque dur.

Limites du rapport de diagnostic

Le rapport généré par perfmon /report fournit un état rapide du système, mais il ne constitue pas un diagnostic complet du PC. Il repose sur une collecte relativement courte et sur des contrôles prédéfinis par Windows.

Il présente donc plusieurs limites :

• Il analyse principalement ce qui se produit pendant la période de collecte. Un ralentissement ou une anomalie intermittente peut passer inaperçu.
• Les contrôles et compteurs sont prédéfinis : vous ne choisissez pas précisément les données à surveiller.
• Un avertissement indique une piste à examiner, mais ne désigne pas nécessairement la cause du problème rencontré.
• Le rapport ne remplace pas les outils spécialisés pour vérifier précisément la santé d’un SSD, tester la mémoire RAM ou rechercher une instabilité matérielle.
• Il est moins adapté à l’analyse d’un problème qui apparaît uniquement en jeu ou sous forte charge.
• Il offre moins de possibilités qu’une collecte PerfMon personnalisée pour suivre l’évolution d’une ressource pendant plusieurs minutes ou plusieurs heures.

Ainsi, un rapport sans erreur ne signifie pas forcément que le PC ne présente aucun problème.

Pour un ralentissement intermittent, utilisez plutôt l’Analyseur de performances (PerfMon) et ses ensembles de collecteurs afin d’enregistrer les compteurs dans le temps.

Si vous souhaitez obtenir un diagnostic plus large de Windows, des pilotes et du matériel, AnalysePC peut également compléter le rapport. Pour les problèmes qui apparaissent principalement lorsque le PC est fortement sollicité, un stress test sera plus pertinent.

Obtenir un diagnostic plus complet avec AnalysePC

PerfMon est très puissant, mais son utilisation nécessite de savoir quels compteurs surveiller et comment interpréter les valeurs obtenues. Si vous ne connaissez pas encore l’origine d’un ralentissement, d’un freeze ou d’un comportement anormal, AnalysePC permet de commencer par un diagnostic beaucoup plus global.

AnalysePC collecte et analyse automatiquement de nombreuses informations concernant notamment :

• Le processeur, la mémoire RAM, la carte graphique et le stockage.
• Les températures et différents indicateurs matériels.
• Les pilotes et périphériques.
• Le démarrage et le fonctionnement de Windows.
• Les événements et erreurs système.
• Les performances et certaines anomalies détectées.
• Les latences DPC/ISR et les pilotes associés.
• La configuration réseau.

Les résultats sont regroupés dans un rapport qui fait ressortir les anomalies et points à examiner en priorité, avec des explications et des recommandations.

L’intérêt est donc différent de PerfMon. AnalysePC aide d’abord à répondre à la question « où semble se situer le problème ? », tandis que PerfMon devient particulièrement utile lorsqu’une piste a été identifiée et que vous souhaitez surveiller précisément une ressource ou son évolution dans le temps.

Par exemple, si AnalysePC fait ressortir une anomalie liée au stockage, vous pouvez ensuite utiliser PerfMon pour suivre les temps de réponse et la file d’attente du disque pendant que vous reproduisez les ralentissements.

Les deux outils sont ainsi complémentaires :

• AnalysePC → identifier les pistes et anomalies
• PerfMon → mesurer précisément leur comportement dans le temps

Le guide complet :

Tester les performances et la stabilité sous charge avec StressTest Malekal

PerfMon permet d’observer les ressources du PC pendant son utilisation, mais certains problèmes n’apparaissent que lorsque le matériel est fortement sollicité. C’est notamment le cas des surchauffes, du thermal throttling, de certaines instabilités ou de baisses de performances en jeu.

StressTest Malekal répond à ce besoin en exécutant différents scénarios de charge et en surveillant simultanément le comportement du matériel.

Le test permet notamment d’examiner :

• La stabilité du CPU, du GPU et de la mémoire RAM.
• Les températures pendant la charge.
• Les fréquences de fonctionnement.
• Les performances obtenues pendant les différentes phases.
• Les éventuels signes de thermal throttling.
• Le comportement du stockage.
• Les latences DPC/ISR sous charge et les pilotes associés.
• Les erreurs ou anomalies rencontrées pendant les tests.

L’intérêt est de pouvoir comparer le comportement du PC au repos et lorsqu’il est sollicité. Une configuration peut sembler parfaitement normale pendant une utilisation légère puis présenter une chute de fréquence, une température excessive ou des pics DPC/ISR lorsque le CPU ou le GPU travaille intensément.

StressTest Malekal est donc particulièrement adapté aux problèmes qui apparaissent pendant les jeux, les calculs lourds ou les applications exigeantes : freezes, micro-saccades, plantages, pertes de performances ou grésillements audio.

Il complète ainsi PerfMon plutôt qu’il ne le remplace :

• PerfMon → surveiller précisément des compteurs et leur évolution dans le temps
• StressTest Malekal → provoquer une charge contrôlée et vérifier comment le PC réagit

Le tutoriel complet :

L’article Moniteur de ressources et de performances : générer un rapport avec PerfMon /report est apparu en premier sur malekal.com.

Votre clavier fonctionne, mais certaines touches écrivent de mauvaises lettres, des chiffres ou des caractères différents de ceux attendus ? Le problème ne vient pas nécessairement du clavier lui-même. Une mauvaise disposition AZERTY/QWERTY, Verr Num, une touche de modification bloquée, un remappage ou un logiciel qui intercepte les frappes peuvent modifier la saisie sous Windows.

Le comportement observé donne souvent un premier indice : A qui écrit Q oriente vers une mauvaise disposition de clavier, certaines lettres transformées en chiffres vers le pavé numérique d’un PC portable, tandis qu’une seule touche incorrecte peut provenir d’un remappage ou d’un problème matériel.

Des symptômes plus particuliers, comme un accent circonflexe ou un tréma saisi en double (^^ ou ¨¨), peuvent également être provoqués par un logiciel de macros ou de remappage et, dans certains cas, par un programme malveillant.

Dans ce guide, découvrez comment diagnostiquer un clavier qui écrit de mauvaises lettres ou caractères sous Windows 11/10, vérifier sa disposition et ses réglages, détecter un remappage ou un logiciel perturbateur et déterminer si le problème est logiciel ou matériel.

Vérifier la langue et la disposition du clavier

Lorsque le clavier fonctionne mais que les lettres ou caractères saisis ne correspondent pas aux touches, commencez par vérifier la langue et la disposition sélectionnées dans Windows.

Une mauvaise disposition peut par exemple provoquer :

• la touche A qui écrit Q ;
• la touche Z qui écrit W ;
• des chiffres ou signes de ponctuation différents de ceux indiqués sur les touches ;
• des caractères spéciaux placés à des emplacements inhabituels.

Sous Windows 11 et Windows 10, utilisez :

Windows + Espace

pour afficher les langues et dispositions installées et sélectionner celle correspondant à votre clavier, par exemple Français – AZERTY.

Vous pouvez également vérifier l’indicateur FRA, ENG, etc. présent dans la barre des tâches.

Si l’ensemble du clavier est passé d’AZERTY à QWERTY, consultez :

Le guide complet :

Pour ajouter, supprimer ou configurer plus précisément une langue ou une disposition :

Le tutoriel :

Si la bonne disposition est déjà sélectionnée mais que certaines touches continuent de produire de mauvais caractères, le problème se situe probablement ailleurs. Poursuivez alors avec les vérifications suivantes.

Vérifier Verr Num et le pavé numérique

Si certaines lettres produisent des chiffres au lieu des caractères attendus, vérifiez l’état de la touche Verr Num (Num Lock).

Ce problème concerne surtout certains PC portables dépourvus de pavé numérique séparé. Une partie des touches du clavier peut alors servir de pavé numérique lorsque Verr Num est activé. Des lettres comme U, I, O, J, K, L ou M peuvent par exemple produire des chiffres selon le modèle de PC.

Appuyez sur la touche Verr Num, Num Lock ou NumLk pour désactiver cette fonction, puis testez à nouveau les touches concernées.

Sur certains ordinateurs portables, la touche doit être utilisée avec Fn, par exemple :

Fn + Verr Num

La combinaison exacte dépend toutefois du fabricant et du modèle du clavier.

Si vous ne trouvez pas la touche Verr Num, vous pouvez également ouvrir le clavier visuel de Windows avec :

Windows + Ctrl + O

et vérifier l’état de Verr Num depuis celui-ci.

Si les lettres produisent toujours des chiffres alors que Verr Num est désactivé, le problème peut provenir d’un remappage des touches ou d’un autre réglage du clavier.

Vérifier les touches Maj, AltGr, Fn et Verr Maj

Si le clavier fonctionne mais produit de mauvais caractères, des majuscules inattendues ou des symboles différents, vérifiez également les touches de modification du clavier.

Une touche Maj (Shift), AltGr ou Fn bloquée ou considérée comme maintenue peut modifier le caractère généré par les autres touches.

Vérifier Maj et Verr Maj

La touche Verr Maj (Caps Lock) permet de verrouiller la saisie des lettres en majuscules. Si toutes les lettres apparaissent en majuscules, appuyez sur Verr Maj pour désactiver cette fonction.

Si le comportement est plus inhabituel — caractères spéciaux à la place des chiffres, majuscules qui apparaissent de manière intermittente — vérifiez également que l’une des touches Maj n’est pas physiquement bloquée.

Appuyez plusieurs fois sur les touches Maj gauche et droite puis testez à nouveau le clavier.

Vérifier la touche AltGr

Sur un clavier AZERTY, AltGr permet notamment de saisir certains caractères spéciaux comme @, €, {, } ou \.

Si AltGr reste bloquée ou si Windows la considère comme enfoncée, certaines touches peuvent donc produire des caractères complètement différents de ceux attendus.

Appuyez plusieurs fois sur AltGr puis relâchez-la avant de refaire un test dans le Bloc-notes.

Vérifier la touche Fn

Sur les PC portables, la touche Fn permet d’accéder aux fonctions secondaires du clavier : luminosité, volume, pavé numérique intégré, touches multimédias, etc.

Selon le constructeur, un Fn Lock peut également maintenir ces fonctions secondaires actives.

Si les touches F1 à F12, le pavé numérique intégré ou certaines autres touches ont changé de comportement, vérifiez donc Fn et Fn Lock. La combinaison permettant d’activer ou désactiver ce verrouillage varie selon le modèle du PC.

Si le problème persiste, le clavier visuel de Windows peut aider à déterminer si une touche de modification reste considérée comme active alors que vous ne l’utilisez pas.

Tester avec le clavier visuel de Windows

Le clavier visuel de Windows peut aider à déterminer si le problème vient du clavier physique ou de la configuration de Windows. Il affiche à l’écran la disposition actuellement utilisée et permet de saisir des caractères avec la souris.

Pour l’ouvrir, utilisez le raccourci :

Windows + Ctrl + O

Vous pouvez également rechercher Clavier visuel depuis le menu Démarrer.

Comparez ensuite les touches affichées à l’écran avec celles de votre clavier physique. Le clavier visuel permet notamment de vérifier :

• Si Windows utilise bien une disposition AZERTY ou QWERTY.
• Si une touche comme Maj, Ctrl, Alt ou AltGr semble rester active.
• Si le caractère obtenu avec le clavier visuel est différent de celui produit par la même touche du clavier physique.

Par exemple, si une lettre s’affiche correctement lorsque vous cliquez sur le clavier visuel mais produit systématiquement un autre caractère avec le clavier physique, la piste d’un problème de clavier, de remappage ou d’un logiciel interceptant les frappes devient plus intéressante.

À l’inverse, si le clavier physique et le clavier visuel produisent tous les deux les mêmes mauvais caractères, vérifiez davantage la langue, la disposition et les paramètres de saisie de Windows.

Pour connaître les autres méthodes permettant d’activer et d’utiliser cet outil :

Le tutoriel à suivre :

Vérifier si les mauvaises touches apparaissent dans toutes les applications

Si le clavier produit de mauvais caractères, vérifiez si le problème se manifeste dans toutes les applications ou seulement dans un logiciel particulier. Cela permet de déterminer si la cause se situe au niveau de Windows ou de l’application utilisée.

Commencez par ouvrir le Bloc-notes et saisissez quelques lettres, chiffres et caractères spéciaux. Effectuez ensuite le même test dans une autre application, par exemple votre navigateur internet.

Si les mauvaises touches apparaissent partout, recherchez plutôt un problème global : disposition du clavier incorrecte, remappage des touches, logiciel qui intercepte les frappes ou problème matériel.

À l’inverse, si le clavier fonctionne normalement dans le Bloc-notes mais produit de mauvais caractères uniquement dans une application, vérifiez les paramètres de celle-ci. Certains logiciels peuvent utiliser leurs propres raccourcis clavier, macros ou méthodes de saisie.

Vous pouvez également fermer complètement l’application concernée puis la relancer afin de vérifier si le problème persiste.

Ce test simple permet donc d’orienter rapidement le diagnostic :

plusieurs applications concernées → Windows, clavier ou logiciel système
une seule application concernée → configuration, raccourci ou extension propre à cette application

Si le problème touche toutes les applications alors que la langue et la disposition sont correctes, vérifiez ensuite si certaines touches ont été remappées.

Vérifier si les touches ont été remappées

Si une touche produit systématiquement une autre lettre, un autre caractère ou déclenche une fonction inattendue, vérifiez qu’elle n’a pas été remappée par Windows ou par un logiciel.

Le remappage permet de modifier le comportement d’une touche. Par exemple :

Caps Lock → Ctrl
A → B
F1 → lancer une application

Cette modification peut avoir été configurée volontairement puis oubliée, ou provenir d’un logiciel installé sur le PC.

Vérifier les logiciels de remappage et de macros

Recherchez notamment les applications capables de modifier les touches ou d’intercepter les frappes, comme :

• PowerToys Keyboard Manager.
• AutoHotkey et ses scripts.
• Les logiciels fournis avec certains claviers gaming.
• Les utilitaires de macros ou de raccourcis clavier.
• Les logiciels constructeur permettant de personnaliser les touches.

Fermez temporairement ces applications ou désactivez les profils et macros personnalisés, puis testez à nouveau le clavier dans le Bloc-notes.

Si le problème disparaît, réactivez les fonctions une par une afin d’identifier le réglage responsable.

Vérifier un remappage permanent des touches

Certains outils peuvent également enregistrer un remappage directement dans la configuration de Windows. Celui-ci peut alors continuer à s’appliquer après un redémarrage et sans que le logiciel ayant servi à le créer soit ouvert.

Si vous avez déjà utilisé un utilitaire pour réaffecter les touches du clavier, vérifiez les modifications configurées et restaurez les touches concernées à leur comportement d’origine.

Pour connaître les différentes méthodes permettant de remapper une touche et, inversement, supprimer une réaffectation existante :

Le tutoriel :

Si aucun remappage n’est configuré mais que plusieurs touches continuent à produire des caractères incorrects, vous pouvez également tenter de réinitialiser les paramètres du clavier.

Réinitialiser les paramètres du clavier

Si la langue et la disposition sont correctes mais que le clavier continue à produire de mauvaises lettres ou des caractères inattendus, vous pouvez tenter de réinitialiser sa configuration.

Cette opération est particulièrement utile si vous avez modifié plusieurs paramètres sans savoir lequel est responsable du problème, ou si le comportement du clavier a changé après l’installation d’un logiciel ou d’un pilote.

La réinitialisation peut notamment consister à :

• Vérifier et restaurer la langue et la disposition de clavier par défaut.
• Supprimer les dispositions inutiles puis ajouter à nouveau celle correspondant au clavier.
• Désactiver certains paramètres d’accessibilité susceptibles de modifier la saisie.
• Réinstaller le périphérique clavier depuis le Gestionnaire de périphériques.
• Supprimer les éventuels réglages ou remappages qui modifient le comportement des touches.

Après la réinitialisation, redémarrez Windows puis testez à nouveau le clavier dans le Bloc-notes.

Comme ces différentes opérations sont détaillées dans un guide dédié, inutile de les reproduire toutes ici :

Les solutions dans ce tutoriel :

Si le problème persiste après la réinitialisation, vérifiez ensuite si un logiciel ou un programme malveillant intercepte les frappes du clavier, notamment lorsque certains caractères comme les accents se comportent de manière anormale.

Double accent circonflexe ^^ ou tréma ¨¨ : vérifier les logiciels et malwares

Un symptôme assez particulier peut se produire lorsque vous appuyez une seule fois sur la touche de l’accent circonflexe ^ ou du tréma ¨ : au lieu d’attendre la lettre suivante pour saisir ê, â ou ë, Windows affiche immédiatement deux caractères :

^^
¨¨

Ce comportement n’est pas forcément lié à la disposition AZERTY ou à une touche physiquement défectueuse. Il peut être provoqué par un logiciel qui intercepte ou modifie les frappes du clavier.

Vérifier les logiciels de macros et de remappage

Commencez par fermer temporairement les programmes capables de modifier le fonctionnement du clavier : logiciels de macros, outils de remappage, utilitaires pour claviers gaming, scripts AutoHotkey ou applications utilisant un second clavier comme périphérique de commandes.

Testez ensuite la touche ^ dans le Bloc-notes.

Si le problème disparaît après la fermeture d’un de ces programmes, vérifiez sa configuration, ses macros et les touches qu’il intercepte.

Rechercher également un malware

Le phénomène du double accent circonflexe a également été observé avec certains programmes malveillants qui interceptent les frappes clavier.

Si le problème est apparu soudainement, se produit dans toutes les applications et qu’aucun logiciel de remappage ne l’explique, effectuez une analyse antivirus complète du PC.

Soyez particulièrement attentif si d’autres comportements suspects sont apparus en même temps : processus inconnus, ralentissements inhabituels, programmes installés sans votre accord ou alertes de sécurité.

Le double ^^ ne prouve toutefois pas à lui seul la présence d’un malware. Un logiciel légitime interceptant le clavier peut provoquer exactement le même symptôme.

Le guide à suivre :

L’ordre de vérification recommandé est donc :

logiciels de macros/remappage → programmes en arrière-plan → analyse antivirus

Si aucune application ou menace n’est détectée et que les caractères restent doublés, poursuivez le diagnostic en testant un autre clavier ou le clavier en dehors de Windows.

Tester le clavier hors de Windows

Si le clavier continue à produire de mauvaises lettres ou des caractères incorrects, un test en dehors de Windows permet de déterminer si le problème vient du système ou du clavier lui-même.

Commencez par redémarrer le PC et accédez au BIOS/UEFI. Vérifiez si les touches de navigation, les flèches et les touches disponibles dans l’interface répondent normalement.

Vous pouvez également démarrer le PC depuis un Live USB Linux, par exemple Ubuntu, puis ouvrir un éditeur de texte et tester les touches concernées.

L’interprétation est assez simple :

Résultat	Piste à privilégier
Le clavier fonctionne normalement hors de Windows	Pilote, réglage, remappage ou logiciel Windows
Les mêmes touches produisent toujours un mauvais comportement	Clavier ou problème matériel à suspecter
Un autre clavier fonctionne correctement sur le même PC	Premier clavier probablement en cause
Plusieurs claviers présentent le problème uniquement sous Windows	Configuration ou logiciel Windows à vérifier

Attention toutefois à sélectionner la même disposition de clavier dans le Live USB. Un Ubuntu configuré en QWERTY alors que vous utilisez un clavier physique AZERTY produira évidemment des caractères différents sans qu’il existe de panne matérielle.

Si le problème semble matériel, testez également le clavier sur un autre ordinateur lorsque cela est possible.

Pour effectuer un diagnostic plus complet lorsque le clavier ne répond plus correctement :

Le tutoriel :

Une touche écrit toujours le mauvais caractère : que faire ?

Si une touche produit toujours un caractère différent de celui attendu alors que la langue et la disposition du clavier sont correctes, il faut déterminer si le problème vient de Windows, d’un logiciel ou du clavier lui-même.

Commencez par tester la touche dans plusieurs applications, par exemple le Bloc-notes et votre navigateur. Vérifiez également son comportement avec le clavier visuel de Windows.

Selon le résultat, vous pouvez orienter le diagnostic :

Symptôme	Piste à vérifier
A écrit Q, Z écrit W	Mauvaise disposition AZERTY/QWERTY
Certaines lettres écrivent des chiffres	Verr Num ou pavé numérique intégré
Une touche produit toujours un autre caractère	Remappage ou logiciel de macros
^ produit ^^ ou ¨ produit ¨¨	Logiciel interceptant le clavier ou malware à rechercher
Mauvais caractère dans une seule application	Configuration, raccourci ou extension de l’application
Problème dans toutes les applications mais pas hors de Windows	Pilote, réglage ou logiciel Windows
Même problème sous Windows et hors de Windows	Clavier ou panne matérielle à suspecter
Un autre clavier fonctionne normalement	Premier clavier probablement en cause

Si le problème est apparu après avoir modifié plusieurs réglages, commencez par réinitialiser les paramètres du clavier. Vérifiez également les logiciels de remappage, de macros et les utilitaires fournis avec le clavier.

Enfin, si la même touche présente le même comportement dans le BIOS/UEFI, depuis un Live USB ou sur un autre PC, la piste matérielle devient nettement plus probable. Une touche ou le circuit du clavier peut être défectueux et nécessiter un nettoyage, une réparation ou le remplacement du clavier.

À l’inverse, si le clavier fonctionne parfaitement hors de Windows, poursuivez les recherches du côté des pilotes, logiciels et paramètres de saisie de Windows.

L’article Clavier qui écrit les mauvaises lettres ou caractères sous Windows 11/10 : les solutions est apparu en premier sur malekal.com.

Quelques jours après son déploiement, la mise à jour KB5121003 du Patch Tuesday d’août 2026 commence à poser problème sur certaines configurations Windows 11.

Des joueurs signalent des plantages de jeux, parfois accompagnés de redémarrages du PC, tandis que d’autres utilisateurs évoquent des écrans noirs, des problèmes de HDR ou des baisses inexpliquées de fréquence de rafraîchissement.

Les premiers éléments pointent vers une incompatibilité entre KB5121003 et le pilote tiers inpoutx64.sys, utilisé par certains logiciels matériels et utilitaires fonctionnant à bas niveau dans Windows. Le studio Embark, à l’origine d’ARC Raiders et The Finals, a confirmé que la mise à jour Windows pouvait provoquer ces plantages et travaille sur une solution durable.

KB5121003 est la mise à jour du Patch Tuesday d’août 2026

Microsoft a publié KB5121003 le 11 août 2026 dans le cadre de son Patch Tuesday mensuel.

Cette mise à jour obligatoire apporte les correctifs de sécurité du mois, avec plus de 400 vulnérabilités corrigées, dont trois zero-day.

Elle apporte également plusieurs améliorations fonctionnelles à Windows 11, notamment pour les performances des applications, Windows Search, l’Explorateur de fichiers, Voice Access et le pavé tactile.

Après installation, Windows 11 passe sur les builds suivantes :

• Windows 11 25H2 : build 26200.9168 ;
• Windows 11 24H2 : build 26100.9168.

Il s’agit d’une mise à jour cumulative de sécurité : contrairement aux mises à jour Preview de fin de mois, elle est automatiquement téléchargée et installée via Windows Update.

ARC Raiders et The Finals peuvent planter

Les premiers signalements importants concernent les jeux développés par Embark Studios, notamment ARC Raiders et The Finals.

Des joueurs expliquent que leurs jeux fonctionnaient normalement avant l’installation de KB5121003, puis ont commencé à planter régulièrement après la mise à jour.

Les erreurs observées varient selon les configurations.

Parmi les messages signalés figurent notamment :

Hang detected on GameThread

ou encore :

EXCEPTION_ACCESS_VIOLATION

Certains joueurs rapportent également que Windows peut redémarrer brutalement après le plantage du jeu.

Embark a confirmé avoir identifié un nouveau crash apparu avec KB5121003 et indique travailler sur une correction.

Le pilote inpoutx64.sys semble être au cœur du problème

Les investigations menées par Embark et plusieurs utilisateurs pointent vers inpoutx64.sys.

Il s’agit d’un pilote tiers fonctionnant au niveau du noyau de Windows. Il permet à certaines applications d’accéder directement aux ports d’entrée/sortie du matériel.

Ce type de pilote peut être utilisé par différents logiciels destinés à :

• surveiller le matériel ;
• contrôler certains périphériques ;
• accéder à des capteurs ;
• modifier certains réglages matériels à bas niveau.

Après l’installation de KB5121003, Windows semble avoir modifié un comportement qui rend certaines versions de inpoutx64.sys incompatibles.

Embark indique directement que le plantage est lié à ce fichier.

À ce stade, on ne sait toutefois pas précisément quelle modification apportée par Microsoft provoque cette incompatibilité.

Le pilote peut avoir été installé par un autre logiciel

Un point important est que l’utilisateur n’a pas nécessairement installé lui-même inpoutx64.sys.

Le pilote peut être déployé par un autre logiciel.

Un joueur ayant analysé ses propres plantages a par exemple découvert que inpoutx64.sys avait été installé par un outil de mise à jour Razer.

Cela explique pourquoi deux PC utilisant la même version de Windows et le même jeu peuvent avoir un comportement totalement différent.

Le problème ne semble donc pas concerner tous les utilisateurs de KB5121003, mais principalement les machines sur lesquelles ce pilote ou un logiciel dépendant de celui-ci est présent.

Comment savoir si inpoutx64.sys est présent sur votre PC ?

Vous pouvez commencer par vérifier si le fichier existe dans le dossier des pilotes Windows.

• Ouvrez l’Explorateur de fichiers puis rendez-vous dans :

C:\Windows\System32\drivers

Recherchez ensuite :

inpoutx64.sys

Sa présence ne signifie pas nécessairement que votre PC rencontrera un problème, mais elle peut être un indice si vos jeux ont commencé à planter immédiatement après l’installation de KB5121003.

Vous pouvez également vérifier la présence du service depuis une Invite de commandes en administrateur :

sc query inpoutx64

Si Windows indique qu’un service correspondant existe, le pilote est enregistré sur le système.

Embark propose une solution temporaire

En attendant une correction définitive, Embark propose de supprimer le pilote inpoutx64.sys lorsqu’il est responsable des plantages.

Ouvrez tout d’abord le menu Démarrer, recherchez Invite de commandes, puis cliquez avec le bouton droit dessus et choisissez Exécuter en tant qu’administrateur.

Exécutez ensuite :

sc stop inpoutx64

Cette commande arrête le service.

Puis saisissez :

sc delete inpoutx64

Cette seconde commande supprime l’enregistrement du service dans Windows.

Rendez-vous enfin dans :

C:\Windows\System32\drivers

puis supprimez le fichier :

inpoutx64.sys

Embark indique que cette procédure permet aux utilisateurs concernés de relancer normalement leurs jeux.

Attention avant de supprimer le pilote

Cette procédure ne doit toutefois pas être appliquée systématiquement à tous les PC.

inpoutx64.sys peut être utilisé par un logiciel ou un périphérique particulier. Le supprimer peut donc empêcher l’application qui l’a installé de fonctionner correctement.

Avant de retirer le pilote, il est préférable de :

• identifier le logiciel qui l’a installé ;
• mettre à jour ce logiciel si une nouvelle version est disponible ;
• créer un point de restauration ;
• n’utiliser la procédure d’Embark que si vous êtes réellement concerné par les plantages.

Si vous n’utilisez pas ARC Raiders, The Finals ou un autre jeu affecté et que votre PC fonctionne correctement, il n’y a aucune raison de supprimer préventivement ce pilote.

Désactiver le pilote peut parfois suffire

Certains utilisateurs rapportent qu’il n’est pas nécessaire de supprimer immédiatement le fichier.

Le simple fait de désactiver le service inpoutx64 puis de redémarrer Windows aurait suffi à supprimer les plantages sur certaines machines.

Cette solution présente l’avantage d’être plus facile à annuler qu’une suppression complète.

Il reste néanmoins préférable de suivre les recommandations du développeur du jeu ou du fabricant du logiciel ayant installé le pilote.

Désinstaller KB5121003 corrige également les plantages chez certains utilisateurs

Plusieurs joueurs rapportent également que la désinstallation de KB5121003 fait immédiatement disparaître les plantages.

Pour désinstaller la mise à jour :

• Ouvrez Paramètres.
• Rendez-vous dans Windows Update.
• Cliquez sur Historique des mises à jour.
• Ouvrez Désinstaller des mises à jour.
• Repérez KB5121003.
• Cliquez sur Désinstaller.
• Redémarrez le PC.

Le tutoriel :

Cette méthode peut être utile pour confirmer que la mise à jour est bien à l’origine du problème.

Elle doit toutefois rester une solution temporaire.

KB5121003 contient les correctifs de sécurité du Patch Tuesday d’août 2026, dont une correction pour une zero-day déjà exploitée dans des attaques. Désinstaller durablement la mise à jour expose donc le PC à des vulnérabilités corrigées depuis.

Si la suppression de inpoutx64.sys suffit à résoudre le problème, cette approche est généralement préférable à la désinstallation complète de la mise à jour de sécurité.

Des problèmes avec certains logiciels anti-triche

WindowsLatest a également reçu des signalements concernant des logiciels anti-triche qui planteraient après l’installation de KB5121003.

Cela n’est pas particulièrement surprenant d’un point de vue technique.

Les systèmes anti-triche modernes utilisent souvent des pilotes fonctionnant au niveau du noyau Windows afin de détecter les manipulations de mémoire, les injections de code ou les pilotes suspects.

Une modification de Windows affectant les pilotes noyau peut donc entraîner des incompatibilités avec certains de ces composants.

Il n’est toutefois pas encore possible d’affirmer que tous ces plantages partagent exactement la même origine que le problème inpoutx64.sys.

D’autres jeux pourraient être concernés

ARC Raiders et The Finals ne semblent pas être les seuls jeux affectés.

Des utilisateurs signalent également des plantages avec Marvel Tōkon: Fighting Souls après l’installation de la mise à jour d’août.

À ce stade, le nombre exact de jeux et de configurations concernés reste inconnu.

Il faut donc éviter de conclure que KB5121003 provoque globalement des problèmes avec les jeux sous Windows 11.

Les témoignages semblent plutôt indiquer des incompatibilités avec certains pilotes ou composants installés sur des configurations particulières.

Écrans noirs, HDR et fréquence de rafraîchissement

D’autres problèmes graphiques commencent également à être signalés après l’installation de KB5121003.

Certains utilisateurs évoquent :

• des écrans noirs ;
• une fréquence de rafraîchissement qui chute sans raison apparente ;
• un comportement incorrect du HDR ;
• différents problèmes d’affichage.

Ces signalements sont encore trop récents pour établir avec certitude un lien direct avec KB5121003.

Contrairement au cas d’ARC Raiders et inpoutx64.sys, aucun éditeur ou fabricant n’a pour l’instant confirmé précisément l’origine de ces problèmes graphiques.

Il faudra donc attendre davantage de retours avant de savoir s’il s’agit d’une seconde régression de la mise à jour ou de problèmes isolés.

Les redémarrages pendant l’installation sont un autre problème

Il ne faut pas non plus confondre les redémarrages observés pendant les plantages de jeux avec ceux pouvant avoir lieu pendant l’installation de KB5121003.

La mise à jour d’août participe également au déploiement des nouveaux certificats Secure Boot 2023.

Selon certaines configurations, leur installation peut nécessiter plusieurs redémarrages successifs du PC.

Ces redémarrages pendant Windows Update sont donc différents d’un PC qui redémarre brutalement lorsqu’un jeu plante.

Microsoft ne reconnaît pas encore officiellement le problème

Au 16 août 2026, Microsoft n’a pas encore ajouté les plantages de jeux liés à KB5121003 à la liste officielle des problèmes connus.

Les notes de publication indiquent toujours que Microsoft n’a connaissance d’aucun problème majeur avec cette mise à jour.

La page Windows Release Health ne répertorie pas non plus, à ce stade, cette incompatibilité parmi les problèmes officiellement confirmés par Microsoft.

La situation est néanmoins différente d’une simple série de témoignages sur les forums puisque Embark Studios a confirmé le lien entre les plantages rencontrés par certains joueurs et KB5121003.

Microsoft pourrait donc communiquer prochainement sur le sujet ou déployer une correction via Windows Update.

Faut-il désinstaller KB5121003 ?

Pour la majorité des utilisateurs, non.

KB5121003 reste une mise à jour de sécurité importante et aucun problème généralisé n’a été identifié sur l’ensemble des PC Windows 11.

Si votre ordinateur fonctionne normalement après son installation, il n’y a aucune raison de la supprimer.

En revanche, si un jeu a commencé à planter immédiatement après la mise à jour :

• vérifiez la présence de inpoutx64.sys ;
• mettez à jour les logiciels et pilotes matériels susceptibles de l’utiliser ;
• appliquez le contournement proposé par Embark si vous utilisez un jeu concerné ;
• testez éventuellement la désinstallation de KB5121003 pour confirmer le diagnostic.

L’objectif est d’éviter de supprimer une importante mise à jour de sécurité lorsque le problème peut être corrigé en retirant uniquement le composant incompatible.

Un nouveau rappel de la fragilité des pilotes noyau

Cet incident illustre une nouvelle fois les risques associés aux pilotes fonctionnant dans le noyau Windows.

Un pilote comme inpoutx64.sys bénéficie d’un accès très privilégié au système. Une modification interne de Windows peut donc provoquer des conséquences beaucoup plus importantes qu’avec une application classique exécutée en espace utilisateur.

Cela rejoint directement les efforts récents de Microsoft autour de sa Driver Quality Initiative, qui vise notamment à améliorer la qualité des pilotes Windows et à réduire le nombre de composants tiers fonctionnant inutilement dans le noyau.

Les problèmes rencontrés après KB5121003 montrent également pourquoi Microsoft souhaite progressivement déplacer davantage de fonctions vers l’espace utilisateur lorsqu’un accès direct au noyau n’est pas indispensable.

Conclusion

Le Patch Tuesday d’août 2026 ne se déroule finalement pas sans accroc.

La mise à jour KB5121003 provoque des plantages sur certains jeux, notamment ARC Raiders et The Finals, et le studio Embark a identifié une incompatibilité avec le pilote noyau inpoutx64.sys.

La bonne nouvelle est qu’un contournement existe déjà : arrêter et supprimer ce pilote permet aux utilisateurs concernés de retrouver un fonctionnement normal.

D’autres signalements concernant des logiciels anti-triche, des écrans noirs, le HDR ou la fréquence de rafraîchissement sont également apparus, mais leur lien avec KB5121003 reste encore à confirmer.

Pour l’instant, il n’est donc pas conseillé de désinstaller préventivement la mise à jour. Les utilisateurs qui ne rencontrent aucun problème doivent la conserver afin de bénéficier des nombreux correctifs de sécurité du Patch Tuesday d’août.

Microsoft n’a pas encore officiellement reconnu cette régression, mais compte tenu de la confirmation apportée par Embark Studios, une clarification ou un correctif devrait probablement suivre si l’incompatibilité touche un nombre significatif de machines.

L’article Windows 11 KB5121003 provoque des plantages de jeux et d’autres problèmes sur certains PC est apparu en premier sur malekal.com.

Au démarrage de Linux, le noyau doit pouvoir identifier et monter la partition racine / pour accéder aux fichiers nécessaires au fonctionnement du système. Lorsque cette étape échoue, le démarrage peut s’interrompre sur un Kernel Panic accompagné du message :

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(...)

Cette erreur peut apparaître après une mise à jour du noyau, une modification des partitions ou de GRUB, mais aussi à cause d’un initramfs endommagé, d’un UUID incorrect, d’un pilote de stockage manquant, d’un système de fichiers corrompu ou d’un SSD/disque défaillant.

Il n’est généralement pas nécessaire de réinstaller Linux. En identifiant à quelle étape l’accès à la partition racine échoue, il est souvent possible de réparer le démarrage depuis GRUB, le mode de récupération ou un Live USB Linux.

Dans ce guide, découvrez les causes de l’erreur « VFS: Unable to mount root fs » et les solutions pour démarrer sur un ancien noyau, vérifier la partition racine et son UUID, reconstruire l’initramfs, réparer le système de fichiers et retrouver un Linux fonctionnel.

Qu’est-ce que l’erreur « VFS: Unable to mount root fs » ?

L’erreur « VFS: Unable to mount root fs » est un Kernel Panic qui se produit pendant le démarrage de Linux lorsque le noyau ne parvient pas à accéder ou à monter le système de fichiers racine.

Le message se présente généralement sous une forme proche de :

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Le système de fichiers racine, représenté par /, contient les fichiers indispensables au fonctionnement de Linux. Si le noyau ne parvient pas à le monter, il ne peut pas poursuivre normalement la séquence de démarrage et déclenche alors un Kernel Panic.

Le problème peut apparaître très tôt au démarrage, parfois juste après une mise à jour du noyau, une modification des partitions ou une opération ayant affecté l’initramfs ou le stockage.

Que signifie VFS ?

VFS (Virtual File System) est la couche du noyau Linux qui fournit une interface commune aux différents systèmes de fichiers, tels que ext4, XFS ou Btrfs.

Lorsque le message indique :

VFS: Unable to mount root fs

cela signifie donc que le noyau n’a pas réussi à monter le système de fichiers devant devenir la racine /.

Cela ne signifie pas nécessairement que le système de fichiers lui-même est endommagé. Le noyau peut tout simplement ne pas parvenir à trouver le périphérique qui le contient ou ne pas disposer du pilote nécessaire pour y accéder.

Que signifie « unknown-block » ?

La fin du message fournit également un indice important :

unknown-block(0,0)

Les deux nombres correspondent à des identifiants utilisés par Linux pour représenter le périphérique de stockage.

Lorsque le message indique unknown-block(0,0), le noyau ne parvient généralement pas à identifier correctement le périphérique contenant la partition racine. Il faut alors rechercher en priorité un problème concernant l’initramfs, le paramètre root=, l’UUID de la partition ou le pilote du contrôleur de stockage.

Dans d’autres situations, vous pouvez rencontrer par exemple :

unknown-block(8,1)

Le noyau a alors identifié un périphérique bloc précis, ce qui peut davantage orienter les recherches vers la partition, le système de fichiers ou son accessibilité.

Le contenu exact de unknown-block(...) constitue donc un indice de diagnostic, mais ne permet pas à lui seul de déterminer la cause.

Quelles sont les causes de « Unable to mount root fs » ?

L’erreur « VFS: Unable to mount root fs » signifie que le noyau Linux n’arrive pas à monter la partition racine /. Plusieurs problèmes peuvent interrompre la chaîne de démarrage entre GRUB, le noyau, l’initramfs et le périphérique de stockage.

Le message unknown-block(...) ainsi que les erreurs affichées juste avant le Kernel Panic peuvent fournir de précieux indices.

Cause	Exemple	Indices possibles
Initramfs endommagé ou incomplet	Mise à jour interrompue, mauvaise génération de l’image	Erreur apparue après une mise à jour du noyau
Nouveau noyau défectueux ou incompatible	Régression du kernel, module incompatible	Ancien noyau fonctionnel depuis GRUB
Mauvaise partition racine	Paramètre root= incorrect	UUID ou périphérique différent de la partition réelle
UUID incorrect	Partition recréée, clonée ou modifiée	UUID de GRUB/fstab différent de celui retourné par blkid
Pilote de stockage absent	NVMe, SATA, RAID ou contrôleur non disponible dans l’initramfs	Souvent unknown-block(0,0)
Système de fichiers endommagé	Corruption ext4, XFS, Btrfs…	Erreurs de système de fichiers avant le panic
SSD ou disque défaillant	Erreurs de lecture ou contrôleur instable	I/O error, erreurs NVMe/SATA
Configuration GRUB incorrecte	Mauvaise entrée ou paramètres du noyau erronés	Mauvais root=, problème après modification de GRUB

Démarrer Linux avec un ancien noyau

Si l’erreur « VFS: Unable to mount root fs » est apparue juste après une mise à jour du noyau Linux, commencez par essayer de démarrer avec la version précédente du kernel.

Linux conserve généralement plusieurs noyaux installés. Il est donc possible de sélectionner un ancien kernel depuis GRUB sans désinstaller immédiatement la nouvelle version.

Sélectionner un ancien noyau depuis GRUB

Redémarrez le PC et affichez le menu GRUB. Selon la distribution et la configuration, vous devrez éventuellement maintenir la touche Maj (Shift) ou appuyer plusieurs fois sur Échap (Esc) pendant le démarrage.

Ensuite :

• Sélectionnez Options avancées pour Ubuntu, ou l’entrée équivalente de votre distribution.
• GRUB affiche les différentes versions du noyau disponibles.
• Sélectionnez une version antérieure du noyau, sans choisir le mode Recovery dans un premier temps.
• Démarrez Linux normalement.

Si le système démarre correctement, vérifiez le noyau actuellement utilisé avec :

uname -r

Vous pouvez également afficher les noyaux présents dans /boot :

ls -lh /boot

Si l’ancien noyau fonctionne

Si Linux démarre avec le kernel précédent mais affiche « Unable to mount root fs » avec la version la plus récente, cela constitue un indice important.

Le problème peut notamment concerner :

• L’initramfs associé au nouveau noyau.
• Un pilote ou module de stockage absent de cet initramfs.
• Un module DKMS qui n’a pas été correctement reconstruit.
• Une régression ou une incompatibilité avec le nouveau kernel.

Dans ce cas, évitez de supprimer immédiatement l’ancien noyau fonctionnel : il constitue une solution de secours pendant le diagnostic.

Vous pouvez ensuite tenter de reconstruire l’initramfs du noyau problématique et mettre à jour la configuration de GRUB.

Si aucun ancien noyau ne démarre

Si plusieurs versions du noyau provoquent la même erreur, la piste d’une simple régression du kernel devient moins probable.

Il faut alors vérifier en priorité la partition racine, son UUID, l’initramfs, le système de fichiers et le périphérique de stockage.

Si Linux ne démarre avec aucun noyau disponible, utilisez le mode de récupération ou un Live USB Linux afin d’accéder au système et d’effectuer les réparations.

Le démarrage avec un ancien noyau constitue donc surtout un test de diagnostic rapide : si l’ancien kernel fonctionne, concentrez les recherches sur ce qui a changé avec la nouvelle version plutôt que de modifier immédiatement les partitions ou le système de fichiers.

Démarrer en mode de récupération

Si Linux ne démarre toujours pas normalement, le mode de récupération (Recovery Mode) permet d’accéder à plusieurs outils de dépannage sans charger complètement le système.

Il est particulièrement utile avec l’erreur « VFS: Unable to mount root fs », car il peut permettre d’obtenir un shell administrateur et d’effectuer certaines réparations sur le système de fichiers, l’initramfs ou la configuration du démarrage.

Depuis GRUB, ouvrez généralement Options avancées, puis sélectionnez une entrée du noyau comportant la mention Recovery Mode.

Selon la distribution et la situation, vous pourrez notamment :

• Accéder à un shell root.
• Vérifier ou réparer le système de fichiers.
• Reconstruire l’initramfs.
• Corriger une mise à jour de paquets interrompue.
• Vérifier les partitions et leurs UUID.
• Mettre à jour la configuration de GRUB.
• Examiner les journaux et messages d’erreur.

Si plusieurs noyaux sont proposés, vous pouvez également essayer le mode de récupération d’un ancien kernel lorsque l’erreur est apparue après une mise à jour.

Pour accéder au mode Recovery et connaître les différents outils disponibles, suivez le guide correspondant à votre distribution :

Le guide complet :

Si le mode de récupération ne démarre pas non plus ou provoque le même Kernel Panic, utilisez plutôt un Live USB Linux. Celui-ci permettra d’accéder aux partitions depuis un système indépendant afin de vérifier le stockage, réparer le système de fichiers ou reconstruire l’initramfs.

Vérifier la partition racine et son UUID

L’erreur « VFS: Unable to mount root fs » peut apparaître lorsque le noyau Linux cherche la partition racine / au mauvais emplacement. Cela peut notamment se produire après un clonage de disque, une modification du partitionnement, une restauration ou un changement incorrect de la configuration de démarrage.

L’objectif est donc de vérifier que la partition existe toujours et que son UUID correspond à celui utilisé par Linux et GRUB.

Identifier la partition racine

Depuis le mode de récupération ou un Live USB Linux, affichez les partitions et leurs systèmes de fichiers :

lsblk -f

Vous pouvez compléter avec :

sudo blkid

Repérez la partition contenant votre installation Linux, par exemple :

/dev/nvme0n1p2

ou :

/dev/sda2

Notez son UUID, par exemple :

UUID="a1b2c3d4-e5f6-7890-abcd-123456789abc"

Plus de détails

Comparer l’UUID avec /etc/fstab

Depuis un Live USB, montez la partition racine, en adaptant le périphérique à votre configuration :

sudo mount /dev/nvme0n1p2 /mnt

Puis consultez :

cat /mnt/etc/fstab

Repérez la ligne correspondant à / :

UUID=a1b2c3d4-e5f6-7890-abcd-123456789abc  /  ext4  defaults  0  1

L’UUID doit correspondre à celui obtenu avec lsblk -f ou blkid.

Si les valeurs sont différentes, Linux peut essayer de monter une ancienne partition ou un système de fichiers dont l’identifiant a changé.

Ne modifiez toutefois pas /etc/fstab avant d’avoir identifié avec certitude la partition racine.

Vérifier le paramètre root= de GRUB

GRUB indique également au noyau où se trouve la partition racine grâce au paramètre root=.

Si Linux démarre avec un ancien noyau, affichez les paramètres utilisés :

cat /proc/cmdline

Vous pouvez notamment obtenir :

root=UUID=a1b2c3d4-e5f6-7890-abcd-123456789abc

Vérifiez là encore que cet UUID correspond à celui de la véritable partition racine.

Si Linux ne démarre plus, sélectionnez son entrée dans GRUB puis appuyez sur e. Recherchez la ligne commençant par linux et vérifiez la valeur :

root=UUID=...

Vous pouvez temporairement remplacer un UUID incorrect par le bon afin de tester le démarrage. Cette modification n’est valable que pour cette tentative et ne change pas définitivement la configuration de GRUB.

Si Linux démarre après cette correction, vous avez probablement identifié la cause du problème.

Corriger définitivement l’UUID

Une fois Linux démarré, corrigez si nécessaire l’UUID incorrect dans /etc/fstab ou la configuration concernée, puis régénérez GRUB.

Sur Ubuntu et Debian :

sudo update-grub

Si la partition racine, son UUID et le paramètre root= sont déjà corrects mais que le Kernel Panic affiche toujours unknown-block(0,0), le problème vient probablement d’une autre étape du démarrage.

Il faut alors vérifier en priorité l’initramfs et les pilotes nécessaires pour accéder au périphérique de stockage.

Reconstruire l’initramfs

L’initramfs est chargé très tôt pendant le démarrage de Linux. Il contient notamment les modules et outils nécessaires pour détecter le périphérique de stockage et accéder à la partition racine /.

S’il est endommagé, incomplet ou ne contient plus un pilote nécessaire, le noyau peut ne pas parvenir à monter la partition racine et afficher l’erreur « VFS: Unable to mount root fs ». Cette situation peut notamment survenir après une mise à jour du noyau ou d’un pilote.

Reconstruire l’initramfs sur Ubuntu et Debian

Si vous pouvez démarrer avec un ancien noyau ou depuis le mode de récupération, reconstruisez les images initramfs avec :

sudo update-initramfs -u -k all

Pour reconstruire uniquement celle du noyau actuellement utilisé :

sudo update-initramfs -u -k "$(uname -r)"

Mettez ensuite à jour GRUB :

sudo update-grub

Puis redémarrez le PC et essayez à nouveau le noyau qui provoquait l’erreur.

Reconstruire l’initramfs sur Fedora et RHEL

Fedora, RHEL et plusieurs distributions dérivées utilisent généralement dracut.

Pour reconstruire l’initramfs du noyau en cours :

sudo dracut --force

Si plusieurs noyaux sont installés, vérifiez leurs versions :

ls /lib/modules/

Lorsque vous devez réparer un noyau différent de celui actuellement démarré, veillez à reconstruire l’image correspondant à la bonne version du kernel.

Vérifier que l’initramfs existe

Vous pouvez contrôler les images présentes dans /boot :

ls -lh /boot

Selon la distribution, vous devez notamment retrouver des fichiers de type :

vmlinuz-...
initrd.img-...

ou :

initramfs-....img

Vérifiez qu’une image initramfs existe bien pour le noyau que vous essayez de démarrer. Un nouveau kernel accompagné d’un initramfs absent ou mal généré peut expliquer pourquoi l’ancien noyau fonctionne alors que le nouveau provoque le Kernel Panic.

Si Linux ne démarre plus du tout

Si aucun noyau ou mode de récupération ne permet de démarrer, utilisez un Live USB Linux. Vous pourrez monter l’installation existante, entrer dans le système avec chroot, puis reconstruire l’initramfs et mettre à jour GRUB.

Le guide complet :

Le principe est alors : Live USB → monter Linux → chroot → reconstruire l’initramfs → mettre à jour GRUB

Inutile de détailler ici toute la procédure chroot, puisqu’elle est déjà expliquée dans le guide dédié.

Si l’erreur persiste

Si l’initramfs a été correctement reconstruit mais que le noyau affiche toujours unknown-block(0,0), vérifiez ensuite que l’image contient bien les pilotes nécessaires au contrôleur de stockage.

Si le SSD ou le disque est détecté mais que la partition racine ne peut toujours pas être montée, recherchez plutôt un système de fichiers endommagé ou un problème avec le périphérique de stockage.

Vérifier et réparer le système de fichiers

Si le noyau détecte correctement la partition racine mais n’arrive pas à monter son système de fichiers, une corruption de celui-ci peut provoquer l’erreur « VFS: Unable to mount root fs ».

Ce problème peut notamment apparaître après un arrêt brutal du PC, une coupure de courant, un plantage pendant une écriture ou des erreurs provenant du SSD ou du disque dur.

Recherchez dans les messages précédant le Kernel Panic des indications comme :

EXT4-fs error
Buffer I/O error
I/O error
BTRFS error
XFS
Superblock

Vérifier le système de fichiers avec fsck

Sous Linux, la commande fsck permet de vérifier et, selon le système de fichiers, de réparer les erreurs détectées. fsck sert en réalité d’interface aux outils adaptés au type de système de fichiers concerné.

Commencez par identifier la partition et son système de fichiers :

lsblk -f

Par exemple, si la partition racine utilise ext4 et correspond à /dev/nvme0n1p2, vous pouvez effectuer sa vérification depuis un Live USB ou un environnement de récupération, une fois la partition démontée :

sudo fsck /dev/nvme0n1p2

Selon les erreurs rencontrées, l’outil peut proposer de réparer les incohérences détectées.

Pour connaître les différentes options et méthodes de réparation, consultez notre guide complet :

Le guide complet :

Enfin notez que vous pouvez effectuer un fsck depuis les options de récupération :

Attention au type de système de fichiers

Tous les systèmes de fichiers ne se réparent pas de la même manière. Pour XFS, par exemple, fsck.xfs ne réalise pas directement la réparation : l’outil dédié est xfs_repair.

Btrfs utilise également ses propres outils de vérification et de réparation ; fsck.btrfs n’effectue pas une vérification classique.

Il est donc important d’identifier le système de fichiers avec lsblk -f avant de lancer une réparation.

Si les erreurs réapparaissent après avoir réparé le système de fichiers, ne vous contentez pas de relancer régulièrement fsck. Des corruptions répétées peuvent être le symptôme d’un SSD ou disque défaillant, d’erreurs d’entrée/sortie ou d’une autre instabilité matérielle.

Dans ce cas, l’étape suivante consiste à vérifier l’état du périphérique de stockage.

Vérifier le SSD ou le disque dur

Si l’erreur « VFS: Unable to mount root fs » s’accompagne d’erreurs d’entrée/sortie ou si le système de fichiers se corrompt régulièrement, vérifiez également l’état du SSD ou du disque dur.

Un périphérique de stockage défaillant peut empêcher le noyau de lire correctement la partition racine. Dans ce cas, reconstruire l’initramfs ou réparer le système de fichiers peut ne résoudre le problème que temporairement.

Rechercher les erreurs de stockage

Depuis le mode de récupération ou un Live USB, consultez les messages du noyau :

dmesg -T | grep -Ei "error|fail|i/o|nvme|ata|sata"

Vous pouvez également utiliser :

journalctl -k | grep -Ei "error|fail|i/o|nvme|ata|sata"

Recherchez notamment des messages tels que :

I/O error
Buffer I/O error
critical medium error
nvme
ata error
reset
timeout

Des erreurs répétées de lecture, des timeouts ou des réinitialisations du contrôleur de stockage constituent des indices importants.

Le guide complet :

Identifier le disque concerné

Affichez les périphériques de stockage avec :

lsblk -o NAME,MODEL,SIZE,FSTYPE,MOUNTPOINTS

lsblk permet d’obtenir les informations sur les périphériques bloc détectés par Linux.

Repérez le SSD ou disque contenant la partition racine avant de poursuivre les vérifications.

Vérifier les données SMART

Les SSD et disques compatibles exposent généralement des informations S.M.A.R.T. permettant de surveiller leur état de santé, les erreurs enregistrées et différents indicateurs d’usure. Sous Linux, ces données peuvent notamment être interrogées avec smartctl, fourni par smartmontools.

Comme tu as déjà un guide complet consacré à cette vérification, je ne détaillerais pas ici toutes les commandes et attributs SMART :

Le tutoriel à suivre :

L’objectif est notamment de rechercher des erreurs matérielles, des secteurs problématiques, une usure anormale du SSD ou des erreurs enregistrées par le contrôleur.

Si le stockage présente des signes de défaillance, sauvegardez vos données importantes avant d’effectuer des réparations répétées du système de fichiers.

À l’inverse, si le disque est en bon état, que la partition est correctement détectée et que son système de fichiers ne présente pas d’erreur, revenez plutôt aux pistes liées à l’initramfs, aux pilotes de stockage ou à la configuration du démarrage.

Vérifier les pilotes de stockage dans l’initramfs

Pour monter la partition racine /, le noyau doit pouvoir détecter le SSD ou le disque dès les premières étapes du démarrage. Les pilotes nécessaires au contrôleur de stockage doivent donc être disponibles dans l’initramfs.

Si un module NVMe, SATA, RAID ou correspondant à un contrôleur particulier est absent, Linux peut ne pas détecter le périphérique contenant la partition racine et afficher notamment :

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Cette piste est particulièrement intéressante lorsque le problème apparaît après une mise à jour du noyau, une reconstruction de l’initramfs ou une modification de la configuration du stockage.

Identifier le pilote de stockage utilisé

Si vous pouvez démarrer avec un ancien noyau fonctionnel, identifiez le contrôleur de stockage et le pilote utilisé :

lspci -k | grep -A3 -Ei "sata|raid|storage|non-volatile|nvme"

Vous pouvez également rechercher les principaux modules de stockage chargés :

lsmod | grep -Ei "nvme|ahci|ata|scsi|raid"

Selon le matériel, vous pouvez par exemple rencontrer nvme, nvme_core, ahci ou libahci. Le module réellement nécessaire dépend toutefois du contrôleur présent sur le PC.

Vérifier que le module est présent dans l’initramfs

Sur Ubuntu et Debian, affichez d’abord les images disponibles :

ls -lh /boot/initrd.img-*

Puis recherchez le pilote dans l’initramfs correspondant au noyau qui ne démarre pas. Par exemple pour NVMe :

lsinitramfs /boot/initrd.img-<version-du-noyau> | grep -i nvme

ou pour AHCI :

lsinitramfs /boot/initrd.img-<version-du-noyau> | grep -i ahci

Sur une distribution utilisant dracut, utilisez plutôt lsinitrd :

lsinitrd /boot/initramfs-<version-du-noyau>.img | grep -Ei "nvme|ahci"

Si l’ancien noyau démarre correctement, comparer son initramfs avec celui du nouveau kernel peut aider à repérer un module absent dans l’image problématique.

Que faire si le pilote est absent ?

Si vous avez identifié avec certitude un module indispensable absent de l’initramfs, commencez par reconstruire l’image comme expliqué dans la section précédente.

Sur Ubuntu/Debian :

sudo update-initramfs -u -k all
sudo update-grub

Si le module reste absent, il est possible de forcer son inclusion dans l’initramfs. Cette opération dépend toutefois de la distribution et ne doit être effectuée qu’après avoir identifié précisément le pilote nécessaire.

Cas des volumes RAID, LVM ou chiffrés

La détection du disque ne suffit pas toujours. Si la partition racine se trouve sur LVM, un RAID ou un volume chiffré, l’initramfs doit également disposer des composants nécessaires pour assembler ou déverrouiller le volume avant de pouvoir monter /.

Ainsi, si le SSD apparaît correctement depuis un Live USB mais que Linux affiche toujours unknown-block au démarrage, vérifiez la configuration de l’initramfs et la manière dont la partition racine est construite.

Si les pilotes nécessaires sont bien présents, poursuivez plutôt le diagnostic du côté de l’UUID, de GRUB, du système de fichiers ou du stockage lui-même.

Réparer depuis un Live USB Linux

Si Linux ne démarre avec aucun noyau disponible ni en mode de récupération, utilisez un Live USB Linux. Celui-ci permet d’accéder au système installé depuis un environnement indépendant afin d’effectuer les réparations.

Commencez par identifier et monter la partition racine comme expliqué dans la section « Vérifier la partition racine et son UUID ». Profitez également du Live USB pour sauvegarder vos fichiers importants si vous suspectez une corruption du système de fichiers ou un problème de stockage.

Une fois la partition montée, vous pouvez utiliser chroot afin d’exécuter les commandes dans l’environnement du Linux installé.

Réparer l’installation avec chroot

Pour reconstruire l’initramfs ou corriger la configuration de démarrage, vous pouvez ensuite utiliser chroot afin d’exécuter les commandes dans l’environnement du Linux installé.

Cette opération nécessite notamment de monter certains systèmes virtuels et, selon la configuration, les partitions /boot et EFI. La procédure étant identique à celle utilisée pour réparer GRUB depuis un Live USB, suivez le guide dédié :

Le guide complet :

mkdir -p /tmp/chroot
sudo mount -t ext4 /dev/sda2 /tmp/chroot
sudo mount --bind /proc /tmp/chroot/proc
sudo mount --bind /dev /tmp/chroot/dev
sudo mount --bind /sys /tmp/chroot/sys
sudo chroot /tmp/chroot/

Une fois dans le chroot, sur Ubuntu ou Debian, reconstruisez l’initramfs :

update-initramfs -u -k all

Puis régénérez la configuration de GRUB :

update-grub

Sur Fedora, RHEL ou une distribution utilisant dracut, reconstruisez l’initramfs avec l’outil correspondant à votre distribution.

Quittez ensuite le chroot, démontez proprement les partitions puis redémarrez le PC sans le Live USB.

Si l’erreur « VFS: Unable to mount root fs » persiste malgré un UUID correct et un initramfs reconstruit, poursuivez les vérifications du côté des pilotes de stockage, du système de fichiers et de l’état du SSD ou du disque dur.

Que faire si l’erreur persiste ?

Si Linux affiche toujours « VFS: Unable to mount root fs » après les vérifications précédentes, évitez de multiplier les modifications au hasard. À ce stade, il faut déterminer précisément à quelle étape l’accès à la partition racine échoue.

Vérifiez en priorité les points suivants :

• Essayez un ancien noyau Linux depuis GRUB.
• Vérifiez que la partition racine est bien détectée avec lsblk -f et blkid.
• Comparez son UUID avec celui utilisé dans /etc/fstab et le paramètre root= de GRUB.
• Reconstruisez l’initramfs et vérifiez qu’il contient les pilotes de stockage nécessaires.
• Contrôlez et réparez le système de fichiers si des erreurs sont détectées.
• Vérifiez l’état de santé du SSD ou du disque dur.
• Recherchez les messages I/O error, nvme, ata, EXT4-fs error ou similaires avant le Kernel Panic.
• Utilisez un Live USB Linux lorsque le système installé ne permet plus d’effectuer ces opérations.

Le message unknown-block(...) peut également aider à orienter les recherches. Un unknown-block(0,0) suggère notamment que le noyau ne parvient pas à identifier correctement le périphérique racine, ce qui renforce les pistes liées à l’initramfs, au paramètre root= ou au pilote de stockage.

À l’inverse, si le périphérique est identifié mais que son système de fichiers ne peut pas être monté, concentrez davantage les vérifications sur la partition, le système de fichiers et l’état du stockage.

Sauvegarder les données avant d’aller plus loin

Si le SSD ou le disque présente des erreurs ou si le système de fichiers se corrompt régulièrement, sauvegardez vos fichiers importants avant de poursuivre les réparations.

Un Live USB permet généralement d’accéder à la partition Linux et de copier les données vers un autre support, à condition que le stockage reste suffisamment fonctionnel.

Évitez notamment d’enchaîner les réparations du système de fichiers sur un disque présentant des erreurs matérielles : la priorité devient alors la récupération des données et le remplacement du périphérique défaillant.

Le guide complet :

Réinstaller Linux en dernier recours

Une réinstallation peut être envisagée si le stockage est sain mais que le système reste impossible à démarrer malgré :

UUID correct → système de fichiers sain → initramfs reconstruit → pilotes présents → GRUB corrigé.

Elle doit toutefois rester une solution de dernier recours. L’erreur « Unable to mount root fs » possède souvent une cause précise qu’il est possible de corriger sans réinstaller complètement Linux.

Si le problème s’accompagne d’autres Kernel Panic, de blocages ou d’erreurs matérielles sans rapport apparent, élargissez également le diagnostic au reste du PC.

Le guide complet :

L’article Kernel Panic « VFS: Unable to mount root fs » sous Linux : les solutions est apparu en premier sur malekal.com.

Un Kernel Panic est l’une des erreurs les plus critiques que peut rencontrer un système Linux. Il se produit lorsque le noyau détecte une situation suffisamment grave pour qu’il ne puisse plus continuer à fonctionner normalement. Le système peut alors se figer complètement, afficher une série de messages techniques ou redémarrer automatiquement.

Les causes sont nombreuses : pilote ou module noyau défectueux, mise à jour du kernel, mémoire RAM instable, problème CPU, carte graphique, SSD ou disque défaillant, système de fichiers corrompu ou erreur lors du démarrage.

Identifier l’origine d’un Kernel Panic nécessite donc d’examiner les messages du noyau et les événements ayant précédé le plantage. Des outils comme journalctl, dmesg, lsmod ou kdump permettent de récupérer des informations précieuses et d’orienter le diagnostic vers un problème logiciel ou matériel.

Dans ce guide, découvrez comment diagnostiquer un Kernel Panic sous Linux, récupérer et analyser les journaux, identifier un pilote ou module responsable, vérifier le matériel et réparer un système qui ne démarre plus après le plantage.

Qu’est-ce qu’un Kernel Panic sous Linux ?

Un Kernel Panic est une erreur critique du noyau Linux qui se produit lorsque celui-ci rencontre une situation suffisamment grave pour qu’il ne puisse plus continuer à fonctionner normalement.

Le noyau (kernel) constitue le cœur du système Linux. Il assure notamment la communication avec le matériel, la gestion de la mémoire, des processus, des pilotes et des systèmes de fichiers. Lorsqu’une erreur irrécupérable survient à ce niveau, poursuivre l’exécution pourrait provoquer une corruption des données ou aggraver le problème. Le noyau peut alors déclencher volontairement un panic et arrêter le système.

Selon la configuration de Linux, le PC peut alors :

• Se figer complètement avec un message d’erreur à l’écran.
• Afficher une série d’informations techniques et une Call Trace.
• Redémarrer automatiquement après quelques secondes.
• Rester bloqué jusqu’à un redémarrage manuel.

Un Kernel Panic est donc différent du simple plantage d’une application. Si Firefox, un jeu ou un autre programme se ferme brutalement, le noyau Linux continue généralement de fonctionner. Lors d’un Kernel Panic, c’est au contraire le fonctionnement du système lui-même qui est compromis.

Kernel Panic, Kernel Oops ou blocage : quelles différences ?

Tous les problèmes graves de Linux ne correspondent pas nécessairement à un Kernel Panic.

Un Kernel Oops indique qu’une erreur a été détectée dans le noyau. Linux enregistre des informations techniques sur l’incident et peut parfois continuer à fonctionner, même si le système peut ensuite devenir instable.

Un Kernel Panic est plus grave : le noyau considère qu’il n’est plus possible de poursuivre l’exécution de manière sûre.

Enfin, un freeze ou blocage de Linux peut avoir de nombreuses autres origines : pilote graphique bloqué, manque de mémoire, problème matériel, stockage défaillant ou processus qui monopolise certaines ressources. Un écran figé ne signifie donc pas automatiquement qu’un Kernel Panic s’est produit.

Les messages affichés à l’écran ou enregistrés dans les journaux sont essentiels pour faire la différence. Des termes comme Kernel panic, Oops, BUG, Call Trace ou le nom d’un module noyau constituent alors des indices importants.

Dans la suite de ce guide, nous allons voir quelles sont les principales causes d’un Kernel Panic et comment récupérer ces informations afin d’identifier son origine.

Quelles sont les causes d’un Kernel Panic ?

Un Kernel Panic peut avoir une origine logicielle ou matérielle. Un pilote défectueux, un problème de mémoire RAM, une erreur de stockage ou encore une mise à jour du noyau peuvent provoquer une erreur suffisamment grave pour empêcher Linux de continuer à fonctionner normalement.

Voici les causes les plus courantes :

Cause	Exemples	Indices possibles
Pilote ou module noyau	Pilote graphique, Wi-Fi, stockage, module tiers	Nom d’un module dans la Call Trace, panic après une mise à jour
Mémoire RAM instable	Barrette défectueuse, XMP/EXPO instable, timings incorrects	Erreurs aléatoires, panic différents, corruption mémoire
Processeur instable	Overclocking, undervolting, température excessive	Plantages sous forte charge, erreurs matérielles
Carte graphique / pilote GPU	Pilote NVIDIA/AMD, module noyau graphique	Écran noir, blocage graphique, module GPU cité dans les journaux
SSD ou disque dur	Erreurs d’E/S, SSD défaillant, contrôleur de stockage	I/O error, erreurs NVMe/SATA, système de fichiers inaccessible
Système de fichiers	Corruption ext4, Btrfs, XFS…	Erreurs de montage, corruption ou erreurs de lecture
Noyau Linux	Régression ou bug après une mise à jour	Problème apparu avec une nouvelle version du kernel
Initramfs / démarrage	Image initramfs endommagée, pilote de stockage manquant	Kernel Panic principalement au démarrage
Matériel ou firmware	BIOS/UEFI, carte mère, alimentation, périphérique PCIe	Erreurs matérielles, comportement instable ou aléatoire

Pilote ou module du noyau défectueux

Les pilotes et modules du noyau sont une cause importante de Kernel Panic puisqu’ils s’exécutent directement dans l’espace noyau.

Un problème peut apparaître après la mise à jour d’un pilote graphique, l’installation d’un module tiers ou le passage à une nouvelle version du noyau Linux. Les pilotes NVIDIA, les modules DKMS ou certains pilotes de périphériques constituent par exemple des éléments à vérifier lorsqu’un Kernel Panic apparaît après une modification du système.

Le nom du module impliqué peut parfois apparaître dans la Call Trace ou dans les messages enregistrés avant le plantage.

Problème matériel ou instabilité du PC

Un Kernel Panic peut également être la conséquence d’une instabilité matérielle. La mémoire RAM est notamment à surveiller : une barrette défectueuse ou des paramètres XMP/EXPO trop agressifs peuvent provoquer des corruptions mémoire qui finissent par faire planter le noyau.

Le processeur peut également devenir instable à cause d’un overclocking, d’un undervolting trop important ou, dans certains cas, de températures excessives.

Si les Kernel Panic sont aléatoires, impliquent des modules différents ou apparaissent principalement sous forte charge, il est pertinent d’élargir le diagnostic au matériel.

Les guides complets :

Stockage et système de fichiers

Un SSD ou un disque dur défaillant peut provoquer des erreurs d’entrée/sortie (I/O) qui empêchent le noyau d’accéder correctement aux données nécessaires au fonctionnement du système.

Une corruption du système de fichiers peut également entraîner des problèmes graves, notamment lorsque la partition système devient inaccessible.

Des messages contenant I/O error, EXT4-fs error, BTRFS error, nvme ou encore des erreurs SATA constituent alors des pistes à examiner.

Mise à jour ou régression du noyau Linux

Enfin, un Kernel Panic peut apparaître après une mise à jour du noyau. Une nouvelle version peut introduire une régression ou révéler une incompatibilité avec un pilote ou un périphérique particulier.

Un indice particulièrement intéressant est donc la date d’apparition du problème. Si Linux fonctionnait normalement avant une mise à jour du kernel et que les Kernel Panic ont commencé immédiatement après, démarrer temporairement sur l’ancien noyau depuis GRUB constitue un excellent test.

L’identification de la cause repose toutefois rarement sur le seul message « Kernel Panic ». Il faut récupérer les journaux du noyau et les informations affichées au moment du plantage pour déterminer quel pilote, composant ou sous-système est réellement impliqué.

Comment récupérer les informations après un Kernel Panic ?

Pour déterminer l’origine d’un Kernel Panic, il faut récupérer les messages enregistrés par le noyau avant le plantage. Ils peuvent contenir le nom d’un pilote ou d’un module, une erreur mémoire, une erreur d’entrée/sortie ou encore une Call Trace permettant d’orienter le diagnostic.

Lorsque Linux a redémarré, journalctl est généralement le premier outil à utiliser.

Consulter les messages du noyau du démarrage précédent

Sur une distribution utilisant systemd, exécutez :

journalctl -k -b -1

L’option -k limite l’affichage aux messages du noyau, tandis que -b -1 demande les journaux correspondant au démarrage précédent.

Vous pouvez également afficher uniquement les erreurs :

journalctl -k -b -1 -p err

Recherchez notamment des termes comme :

panic
Oops
BUG
Call Trace
segfault
I/O error
MCE
EDAC
nvme
ext4
btrfs

Il est souvent utile d’examiner également les dernières lignes précédant le plantage, car l’erreur ayant déclenché le Kernel Panic peut apparaître avant le message final.

Voir aussi ce guide :

Vérifier les démarrages disponibles

Pour connaître les journaux de démarrage encore disponibles :

journalctl --list-boots

Vous obtenez une liste permettant d’identifier le démarrage actuel (0) et les précédents (-1, -2, etc.).

Vous pouvez ensuite consulter un démarrage particulier, par exemple :

journalctl -k -b -2

Cette méthode est particulièrement pratique lorsque le PC a déjà été redémarré plusieurs fois depuis le Kernel Panic.

Consulter les messages avec dmesg

La commande dmesg affiche les messages du tampon du noyau :

dmesg -T

Vous pouvez filtrer les erreurs avec, par exemple :

dmesg -T | grep -Ei "error|fail|panic|oops|bug|mce|edac|nvme|i/o"

dmesg est surtout utile pour examiner le démarrage et la session en cours. Après un redémarrage consécutif à un Kernel Panic, journalctl -k -b -1 est généralement plus intéressant pour retrouver les événements du système précédent.

Que faire si le journal du démarrage précédent est vide ?

Les journaux ne sont pas toujours conservés après un redémarrage. Vous pouvez vérifier si les anciens boots sont disponibles avec :

journalctl --list-boots

Si seul le démarrage actuel apparaît, la journalisation persistante n’est probablement pas disponible ou les anciens journaux ont déjà été supprimés.

Dans ce cas, il peut être nécessaire de configurer la conservation persistante du journal systemd avant de reproduire le problème.

Il faut également garder à l’esprit qu’un Kernel Panic particulièrement brutal peut empêcher Linux d’écrire les derniers messages sur le disque. Le journal peut alors s’interrompre juste avant l’information la plus intéressante.

Pour les plantages difficiles à reproduire ou lorsque les journaux classiques ne suffisent pas, des mécanismes plus avancés comme kdump permettent de conserver un vidage mémoire du noyau afin d’effectuer une analyse plus approfondie.

Une fois les messages récupérés, l’étape suivante consiste à identifier les lignes réellement importantes dans le Kernel Panic et à interpréter la Call Trace.

Vérifier si un pilote ou module noyau est responsable

Les pilotes et modules du noyau sont une cause fréquente de Kernel Panic, car ils s’exécutent directement dans l’espace noyau. Un module défectueux, incompatible avec une nouvelle version du kernel ou mal compilé peut provoquer une erreur critique du système.

La première étape consiste à rechercher si un nom de module revient dans les journaux ou dans la Call Trace du Kernel Panic.

Vous pouvez par exemple filtrer les messages du démarrage précédent avec :

journalctl -k -b -1 | grep -Ei "module|driver|oops|bug|call trace|taint"

Si un nom de module apparaît régulièrement juste avant le plantage, notez-le pour poursuivre les vérifications.

Lister les modules noyau chargés

La commande suivante affiche les modules actuellement chargés :

lsmod

Vous pouvez rechercher un module précis avec :

lsmod | grep nom_module

Pour obtenir davantage d’informations :

modinfo nom_module

modinfo peut notamment afficher :

• Le chemin du module.
• Sa version.
• Son auteur.
• Les dépendances.
• Les paramètres disponibles.
• La version du noyau pour laquelle il a été compilé selon le module.

Ces informations sont utiles lorsqu’un pilote tiers ou un module DKMS est suspecté.

Vérifier les modules DKMS

Certains pilotes tiers sont reconstruits automatiquement à chaque mise à jour du noyau grâce à DKMS, notamment certains pilotes graphiques ou pilotes matériels additionnels.

Pour afficher les modules DKMS installés :

dkms status

Si un Kernel Panic apparaît juste après une mise à jour du noyau, vérifiez que les modules nécessaires ont bien été recompilés pour la nouvelle version et qu’aucune erreur DKMS n’est présente.

Vous pouvez aussi comparer la version du noyau actuellement utilisée :

uname -r

avec les informations retournées par modinfo.

Rechercher les erreurs liées à un pilote précis

Si vous connaissez le nom du module suspect, filtrez directement les journaux :

journalctl -k -b -1 | grep -i nom_module

ou, pour la session en cours :

dmesg -T | grep -i nom_module

Recherchez notamment des messages indiquant :

• Une erreur d’initialisation.
• Un timeout.
• Une erreur PCIe.
• Un crash ou un BUG.
• Une erreur de mémoire.
• Un module marqué comme tainted.
• Un échec de chargement du firmware.

Désactiver temporairement un module pour confirmer le diagnostic

Si un module non essentiel semble responsable, vous pouvez tenter de le désactiver temporairement afin de vérifier si les Kernel Panic disparaissent.

Pour retirer un module chargé :

sudo modprobe -r nom_module

Cette commande ne fonctionne que si le module n’est pas utilisé par un périphérique ou un autre module.

Pour empêcher son chargement au prochain démarrage, il est également possible de le placer temporairement dans une blacklist modprobe. Cette méthode doit toutefois être utilisée avec prudence : bloquer un pilote graphique, réseau ou de stockage indispensable peut empêcher le système de fonctionner correctement.

L’objectif n’est donc pas de désactiver au hasard les modules présents dans la Call Trace, mais de vérifier si le même pilote revient systématiquement dans plusieurs Kernel Panic.

Le tutoriel :

Vérifier les changements récents

Si le problème est apparu récemment, demandez-vous ce qui a changé juste avant :

• Mise à jour du noyau Linux.
• Mise à jour du pilote NVIDIA ou AMD.
• Installation d’un nouveau module DKMS.
• Mise à jour du BIOS/UEFI.
• Ajout d’un périphérique PCIe, USB ou de stockage.
• Modification d’un paramètre du kernel ou du démarrage.

Lorsqu’un Kernel Panic apparaît juste après une mise à jour du noyau, un test très efficace consiste à redémarrer sur l’ancienne version du kernel depuis GRUB. Si les plantages disparaissent, cela renforce fortement l’hypothèse d’une régression du noyau ou d’une incompatibilité avec un pilote/module.

Enfin, gardez à l’esprit qu’un module cité dans une Call Trace n’est pas automatiquement le responsable. Une corruption mémoire ou une instabilité matérielle peut provoquer le crash d’un pilote parfaitement sain. Il faut donc toujours croiser cette piste avec les autres symptômes et les tests matériels.

Analyser un Kernel Panic avec kdump

Lorsque les journaux journalctl et dmesg ne permettent pas d’identifier l’origine d’un Kernel Panic, les utilisateurs avancés et administrateurs système peuvent utiliser kdump pour effectuer une analyse plus approfondie.

Kdump utilise kexec pour démarrer un second noyau, appelé noyau de capture, après le plantage. Une partie de la mémoire est réservée à l’avance afin que ce noyau puisse récupérer l’état mémoire du système qui vient de planter et l’enregistrer dans un fichier vmcore.

Le principe est le suivant : Kernel Panic → noyau de capture → création du vmcore → analyse du crash

Le fichier vmcore peut ensuite être analysé avec des outils spécialisés comme crash, en utilisant les symboles de débogage correspondant au noyau ayant planté. Cette analyse permet notamment d’examiner les messages du noyau, la pile d’appels, les processus et les modules présents au moment du crash.

La mise en place et surtout l’analyse d’un vmcore restent toutefois des opérations techniques destinées principalement aux administrateurs système et au débogage du noyau. Pour un PC personnel, commencez par journalctl, les messages du noyau, la vérification des pilotes/modules et le diagnostic matériel.

Pour configurer kdump ou analyser un crash en profondeur, consultez la documentation officielle : Documentation officielle de kdump — Linux Kernel

Pour l’analyse d’un vmcore avec l’utilitaire crash, la documentation Red Hat fournit également une procédure détaillée : Analyser un core dump avec crash — Red Hat

Que faire si Linux ne démarre plus après un Kernel Panic ?

Si Linux ne démarre plus après un Kernel Panic, le problème peut venir du noyau récemment installé, d’un pilote/module incompatible, de l’initramfs, du système de fichiers ou d’un problème matériel.

L’objectif est d’abord de retrouver un système démarrable, puis d’analyser ce qui a changé juste avant l’apparition du problème.

Démarrer sur un ancien noyau depuis GRUB

Si les Kernel Panic ont commencé après une mise à jour du noyau, essayez en priorité de démarrer sur une version précédente.

Depuis le menu GRUB :

• Ouvrez Options avancées pour Ubuntu/Debian ou l’entrée équivalente de votre distribution.
• Sélectionnez un ancien noyau Linux.
• Démarrez normalement.

Si le système démarre correctement avec l’ancien kernel, cela oriente fortement vers une régression du noyau ou un problème de pilote/module compatible uniquement avec certaines versions.

Vous pouvez vérifier la version utilisée avec :

uname -r

Utiliser le mode de récupération

Si un ancien noyau ne suffit pas, essayez le mode Recovery / dépannage proposé dans GRUB.

Selon la distribution, ce mode permet notamment de :

• Ouvrir un shell root.
• Vérifier le système de fichiers.
• Réparer certains paquets.
• Recréer l’initramfs.
• Désactiver temporairement un pilote ou module problématique.

Il peut être utile lorsque le Kernel Panic survient très tôt pendant le démarrage.

Vérifier ou reconstruire l’initramfs

Un initramfs endommagé ou incomplet peut empêcher le noyau de charger les pilotes nécessaires au démarrage, notamment ceux liés au stockage.

Sur Debian/Ubuntu, vous pouvez reconstruire l’initramfs avec :

sudo update-initramfs -u -k all

Puis mettre à jour GRUB :

sudo update-grub

Sur d’autres distributions, la commande peut différer, par exemple avec dracut.

Démarrer depuis un Live USB

Si aucun noyau installé ne permet de démarrer, utilisez un Live USB Linux.

Depuis le système Live, vous pouvez :

• Accéder aux fichiers importants et effectuer une sauvegarde.
• Monter la partition Linux.
• Vérifier le système de fichiers.
• Examiner les journaux présents sur le disque.
• Réparer le chargeur d’amorçage.
• Réinstaller un noyau ou reconstruire l’initramfs.

C’est également une bonne méthode pour déterminer si le problème vient du système installé ou d’une panne matérielle plus générale.

Vérifier le système de fichiers et le stockage

Si le Kernel Panic est associé à des erreurs de lecture, de montage ou d’entrée/sortie, vérifiez le stockage avant d’insister sur les réparations logicielles.

Vous pouvez rechercher des erreurs dans les journaux avec des termes comme :

I/O error
EXT4-fs error
BTRFS error
nvme
ata
Buffer I/O error

Un système de fichiers endommagé peut parfois être réparé avec fsck, à condition de ne pas lancer la vérification sur une partition montée en écriture.

Profitez également du Live USB pour vérifier l’état SMART du SSD ou du disque si une défaillance matérielle est suspectée.

Le guide :

Désactiver temporairement un module problématique

Si les journaux ou la Call Trace pointent régulièrement vers un module noyau précis, il peut être utile de désactiver temporairement ce module afin de vérifier si Linux démarre à nouveau.

Cette opération est surtout pertinente pour les pilotes graphiques, Wi-Fi ou modules tiers. Évitez toutefois de blacklister au hasard un pilote lié au stockage ou à un composant indispensable au démarrage.

En dernier recours : sauvegarder puis réparer ou réinstaller

Si Linux reste impossible à démarrer malgré un ancien noyau, la reconstruction de l’initramfs et la vérification du stockage, sauvegardez d’abord vos données depuis un Live USB.

Vous pourrez ensuite tenter une réparation plus complète du système ou, si la corruption est importante, procéder à une réinstallation.

Avant d’en arriver là, vérifiez cependant que le problème n’est pas matériel. Des Kernel Panic répétés avec des messages différents peuvent être provoqués par une RAM instable, un SSD défaillant, un CPU instable ou un autre composant matériel.

Le guide complet :

Les messages de Kernel Panic les plus courants

Kernel panic – not syncing: VFS: Unable to mount root fs

C’est le cas incontournable. Le noyau a démarré, mais n’arrive pas à monter le système de fichiers racine (/). Les pistes typiques sont :

• initramfs absent, endommagé ou incorrect ;
• pilote du contrôleur de stockage ou du système de fichiers absent de l’initramfs ;
• mauvais paramètre root= transmis au noyau ;
• UUID de partition incorrect ;
• problème après une mise à jour du noyau ;
• système de fichiers endommagé ;
• SSD/disque ou contrôleur de stockage défaillant.

Le guide dédié :

Le guide Kernel Panic pourrait n’en donner qu’une explication de 200 mots + lien vers ce futur guide.

Kernel panic – not syncing: Attempted to kill init!

Le message Kernel panic - not syncing: Attempted to kill init! apparaît lorsque le processus init, généralement le processus PID 1, s’arrête ou rencontre une erreur qui l’empêche de poursuivre son fonctionnement.

Ce processus joue un rôle essentiel : il constitue le premier processus lancé en espace utilisateur et permet ensuite d’initialiser le reste du système. S’il disparaît, Linux ne peut normalement plus poursuivre son fonctionnement et déclenche un Kernel Panic.

Cette erreur peut notamment être liée à :

• Un initramfs endommagé ou incomplet.
• Un problème avec systemd ou le programme utilisé comme init.
• Une corruption du système de fichiers racine.
• Des bibliothèques ou fichiers système manquants ou corrompus.
• Une mise à jour interrompue ou défectueuse.
• Une erreur de mémoire ou une instabilité matérielle provoquant le crash du processus init.

Si le problème apparaît au démarrage, essayez d’abord de lancer un ancien noyau depuis GRUB ou le mode de récupération. Vous pouvez ensuite vérifier le système de fichiers, reconstruire l’initramfs et contrôler les fichiers système.

Il est également important d’examiner les lignes affichées juste avant Attempted to kill init! : ce message indique la conséquence finale du problème, mais pas nécessairement sa cause initiale.

Kernel panic – not syncing: Fatal exception

Le message Kernel panic - not syncing: Fatal exception indique qu’une exception suffisamment grave s’est produite dans le noyau pour empêcher Linux de poursuivre son fonctionnement en toute sécurité.

Contrairement à une erreur très spécifique comme VFS: Unable to mount root fs, le message Fatal exception ne permet généralement pas à lui seul d’identifier la cause.

Il faut donc examiner les informations qui le précèdent, notamment :

• La Call Trace.
• Le nom d’un pilote ou module noyau.
• Les éventuels messages Oops ou BUG.
• Le processus et le CPU concernés.
• Les erreurs mémoire ou matérielles précédant le panic.
• Les modules éventuellement indiqués comme chargés ou impliqués.

Une Fatal exception peut notamment provenir d’un bug du noyau, d’un pilote défectueux, d’un module tiers ou d’une corruption mémoire provoquée par une instabilité matérielle.

Après le redémarrage, consultez en priorité les messages du noyau du démarrage précédent :

journalctl -k -b -1

Si plusieurs Kernel Panic présentent des Call Trace différentes et impliquent des modules sans rapport entre eux, élargissez également les vérifications à la RAM, au processeur et au matériel.

Kernel Panic après une mise à jour du noyau

Si les Kernel Panic commencent immédiatement après une mise à jour du noyau Linux, la nouvelle version du kernel constitue une piste importante.

Le problème ne vient toutefois pas nécessairement du noyau lui-même. Une mise à jour peut également révéler une incompatibilité avec un pilote, un module DKMS, l’initramfs ou un périphérique matériel.

Le test le plus simple consiste à redémarrer le PC et à sélectionner l’ancienne version du noyau depuis les options avancées de GRUB.

Si Linux fonctionne normalement avec l’ancien kernel, vérifiez ensuite :

• Les éventuelles erreurs connues avec la nouvelle version du noyau.
• Les modules DKMS avec dkms status.
• Les pilotes graphiques ou autres pilotes tiers récemment mis à jour.
• La bonne génération de l’initramfs.
• Les journaux du démarrage ayant échoué.
• Les paramètres du noyau éventuellement modifiés.

Vous pouvez connaître le noyau actuellement utilisé avec :

uname -r

et afficher les noyaux disponibles dans /boot :

ls -lh /boot

Si l’ancien noyau fonctionne correctement, conservez-le temporairement comme solution de secours plutôt que de supprimer immédiatement les autres versions. Cela permet de continuer à utiliser Linux pendant que vous recherchez s’il s’agit d’une régression du kernel ou d’une incompatibilité avec un module.

L’article Kernel Panic sous Linux : causes, diagnostic et solutions est apparu en premier sur malekal.com.

VLC Media Player est réputé pour sa légèreté et sa capacité à lire pratiquement n’importe quel format audio ou vidéo. Pourtant, certains utilisateurs de Windows 11 signalent depuis plusieurs versions des ralentissements au démarrage, des saccades ou des comportements anormaux qui ne se reproduisent pas nécessairement sous Windows 10 ou Linux.

Dans un nouvel échange rapporté par WindowsLatest, VideoLAN rejette l’idée selon laquelle VLC serait simplement devenu trop lourd ou mal optimisé. Le projet pointe plutôt du doigt plusieurs changements et problèmes propres à Windows 11, tout en profitant de l’occasion pour rappeler les contraintes très différentes qui existent entre un projet open source multiplateforme et une application développée directement par Microsoft.

La polémique intervient alors que Microsoft tente justement de moderniser Windows 11 et ses applications avec davantage de composants natifs, notamment WinUI, tout en promettant de réduire la consommation de mémoire et les lenteurs de son interface.

Des ralentissements de VLC déjà signalés sous Windows 11

Les problèmes de performances de VLC sous Windows 11 ne sont pas nouveaux.

Des rapports publiés sur le système de suivi de VideoLAN font état depuis plusieurs années de lancements anormalement longs. Un utilisateur signalait ainsi dès 2022 que la première ouverture de VLC après le démarrage de Windows 11 pouvait prendre plus d’une minute, alors que les autres applications démarraient normalement.

Plus récemment, des utilisateurs de VLC 3.0.23 ont également observé un délai d’une dizaine de secondes lors du premier lancement, avant que les ouvertures suivantes ne redeviennent instantanées.

D’autres problèmes sont beaucoup plus spécifiques à Windows 11.

Par exemple, un bug affectant VLC 3.0.21 et 3.0.23 provoque un blocage lorsque l’utilisateur tente de modifier le type de fichier depuis la fenêtre « Ajouter un fichier » de la liste de lecture. Le problème a été reproduit sous Windows 11 25H2, alors que le même scénario fonctionne correctement sous Windows 10.

Ces éléments ne suffisent pas à démontrer qu’un seul bug Windows explique tous les ralentissements de VLC, mais ils montrent que certaines régressions sont bien liées à l’environnement Windows 11 plutôt qu’au lecteur multimédia seul.

Quelles sont les solutions ?

Tentez de regénérer le cache VLC peut résoudre les lenteurs d’ouverture du lecteur.
Pour cela :

• Accédez au dossier : C:\Program Files (x86)\VideoLAN\VLC
• Double-cliquez sur vlc-cache-gen.exe

• Puis relancez VLC pour vérifier si son ouverture est plus rapide

Windows 11 24H2 pose aussi des problèmes avec certaines configurations GPU

Un autre exemple particulièrement intéressant concerne les ordinateurs utilisant plusieurs cartes graphiques.

Un rapport publié dans le bug tracker de VLC décrit des pertes massives d’images sous Windows 11 24H2 lorsqu’un système utilise simultanément un GPU intégré AMD et une carte graphique NVIDIA dédiée.

Dans ce scénario, VLC peut tomber temporairement à environ 12 images par seconde lorsqu’il est affiché sur un écran connecté au GPU intégré.

Le problème :

• apparaît après le passage à Windows 11 24H2 ;
• ne se produisait pas sur la version précédente de Windows ;
• disparaît lorsque VLC est affiché sur un écran connecté directement au GPU dédié ;
• ne semble pas lié à une saturation du CPU, du GPU ou du stockage.

Le développeur à l’origine du rapport soupçonne une interaction complexe avec le compositeur graphique de Windows, notamment lorsque plusieurs GPU provenant de constructeurs différents sont utilisés.

Cela illustre bien la difficulté pour un logiciel comme VLC : le lecteur peut être correctement optimisé, mais dépend malgré tout d’une longue chaîne comprenant Windows, Direct3D, le compositeur graphique et les pilotes GPU.

VLC reste pourtant nettement plus léger que le nouveau Media Player de Microsoft

La critique est d’autant plus intéressante que les propres applications multimédias de Microsoft ne sont pas particulièrement exemplaires en matière de performances.

WindowsLatest avait précédemment comparé le nouveau Lecteur multimédia de Windows 11 avec VLC et l’ancien Lecteur Windows Media.

Dans ce test, VLC et l’ancien lecteur de Microsoft ouvraient une vidéo quasiment immédiatement, alors que le nouveau Media Player nécessitait plusieurs secondes.

La différence était également importante au niveau de la mémoire :

• nouveau Media Player : environ 377 Mo de RAM au repos ;
• ancien Lecteur Windows Media : environ 103 Mo.

Cette comparaison ne constitue évidemment pas un benchmark universel, mais elle montre que l’équation « application moderne = application plus rapide » est loin d’être automatique.

Microsoft a d’ailleurs reconnu travailler sur la consommation de mémoire et les performances de WinUI, son framework moderne destiné à devenir progressivement la base de nombreuses interfaces de Windows 11.

Microsoft veut justement rendre Windows 11 plus natif

Cette discussion arrive à un moment intéressant pour Windows.

Microsoft a récemment annoncé vouloir réduire l’usage de composants Web dans l’interface de Windows 11 au profit de technologies plus natives. L’objectif est notamment de réduire :

• la consommation de mémoire ;
• les temps de démarrage ;
• l’activité CPU ;
• les animations saccadées.

WinUI 3 doit jouer un rôle central dans cette transformation.

Microsoft prévoit notamment de moderniser progressivement plusieurs éléments historiques de Windows avec ce framework, mais l’entreprise travaille parallèlement à optimiser WinUI avant de généraliser son utilisation.

Le paradoxe est donc assez visible : Microsoft encourage les développeurs à créer des applications Windows modernes et natives, alors que certaines applications historiques comme VLC restent parfois plus rapides avec une architecture beaucoup plus ancienne.

Pourquoi VLC ne peut pas être comparé directement à une application Microsoft

Il faut également tenir compte d’une différence fondamentale.

Le nouveau Media Player de Microsoft est conçu spécifiquement pour Windows.

VLC, lui, est un projet multiplateforme qui doit fonctionner sur un très grand nombre de systèmes et d’architectures.

VideoLAN maintient VLC pour :

• Windows ;
• Linux ;
• macOS ;
• Android ;
• iOS ;
• différentes architectures ARM et x86 ;
• plusieurs générations de systèmes d’exploitation.

VLC 3 continue même de prendre en charge certaines anciennes versions de Windows, tandis que VLC 4 suit une autre trajectoire de compatibilité. Le projet VideoLAN travaille actuellement à faire cohabiter ces branches et à gérer leur mise à jour selon la version de Windows utilisée.

Cette compatibilité impose nécessairement davantage de couches d’abstraction et limite la possibilité d’utiliser exclusivement les toutes dernières API de Windows.

Microsoft, à l’inverse, contrôle à la fois le système d’exploitation, ses API, son framework graphique et ses propres applications.

Comparer uniquement les temps de lancement sans tenir compte de cette différence serait donc assez réducteur.

VLC garde aussi un avantage important : les codecs

VLC conserve également un avantage considérable sur le lecteur de Microsoft : sa compatibilité avec les formats multimédias.

Le logiciel peut lire une très grande variété de codecs sans demander l’installation de packs supplémentaires.

Le cas du HEVC/H.265 est particulièrement parlant.

Le nouveau Media Player de Windows peut nécessiter l’installation de l’extension HEVC disponible dans le Microsoft Store, alors que VLC prend directement en charge ce format.

Windows 11 24H2 a également supprimé de son installation standard le codec AC-3 (Dolby Digital). Les applications disposant de leurs propres décodeurs, comme VLC, continuent toutefois de lire ces contenus indépendamment des codecs fournis par Windows.

Cette indépendance vis-à-vis des codecs du système constitue depuis longtemps l’un des principaux atouts de VLC.

Un logiciel signé et rapide ne dépend pas uniquement de son propre code

Le débat met surtout en lumière un point souvent oublié lorsqu’on analyse les performances d’une application.

Lorsqu’un logiciel tourne sous Windows, son comportement dépend également :

• du planificateur CPU ;
• du système graphique ;
• des pilotes GPU ;
• des API Direct3D ;
• de la gestion de l’énergie ;
• de l’Explorateur de fichiers ;
• des boîtes de dialogue système ;
• des mécanismes de sécurité ;
• du compositeur de fenêtres.

Une régression dans l’une de ces couches peut donc rendre une application plus lente sans que son propre code ait changé.

Les problèmes observés avec VLC sous Windows 11 24H2 sur les configurations multi-GPU constituent un bon exemple : le même logiciel fonctionne normalement sur certaines configurations et devient saccadé lorsqu’il utilise une combinaison particulière de GPU et de sorties vidéo.

Cela ne signifie pas que VLC n’a jamais de problèmes

Il serait néanmoins excessif d’attribuer toutes les difficultés de VLC à Windows 11.

Le bug tracker du projet contient également des problèmes qui proviennent clairement de VLC ou de ses interactions avec certains pilotes.

VLC 3.0.22, par exemple, a rencontré des écrans noirs et des plantages avec certaines fonctions NVIDIA RTX Video HDR et RTX Video Super Resolution après une mise à jour des pilotes NVIDIA.

Des ralentissements ont aussi été rapportés lors de la lecture de certains contenus HEVC 12 bits ou AV1 très haute définition.

La réalité est donc plus nuancée : les performances d’un lecteur multimédia moderne dépendent à la fois du logiciel, de Windows et des pilotes graphiques.

VLC 4 doit moderniser profondément le lecteur

VideoLAN travaille parallèlement sur VLC 4.0, qui doit constituer la plus importante évolution du lecteur depuis de nombreuses années.

Jean-Baptiste Kempf décrit cette version comme la plus grosse refonte de VLC depuis environ vingt ans. Elle doit notamment proposer :

• une nouvelle interface ;
• de nouvelles capacités HDR ;
• une lecture sans interruption entre les morceaux ;
• de nouvelles fonctions audio et vidéo ;
• des améliorations importantes du moteur multimédia.

Le défi sera donc de moderniser fortement l’interface tout en conservant l’une des caractéristiques qui ont fait le succès de VLC : sa légèreté.

C’est précisément le problème auquel Microsoft est également confronté avec Windows 11. Moderniser l’interface sans augmenter la consommation de RAM ou dégrader la réactivité s’avère beaucoup plus complexe qu’un simple changement esthétique.

Microsoft et VideoLAN ont finalement le même problème

Derrière les critiques, Microsoft et VideoLAN travaillent en réalité sur un problème très similaire.

Microsoft tente de remplacer progressivement plusieurs composants historiques de Windows par une interface plus moderne basée sur WinUI, tout en réduisant la consommation de ressources.

VideoLAN prépare de son côté VLC 4.0, avec une refonte complète de l’interface sans vouloir sacrifier les performances et la compatibilité.

Dans les deux cas, les développeurs doivent composer avec plusieurs décennies d’héritage logiciel.

La différence est que Microsoft contrôle Windows de bout en bout, alors que VLC doit s’adapter aux décisions prises par Microsoft, Apple, Google, les fabricants de GPU et de nombreux autres acteurs.

Conclusion

Les critiques de VideoLAN envers Windows 11 rappellent qu’il est parfois trop simple d’accuser une application lorsqu’elle devient subitement plus lente après une mise à jour du système.

Plusieurs rapports montrent que VLC rencontre effectivement des problèmes spécifiques à Windows 11, notamment des lancements anormalement longs, des dysfonctionnements liés aux boîtes de dialogue système et des saccades sur certaines configurations multi-GPU apparues avec Windows 11 24H2.

Cela ne signifie pas pour autant que VLC est exempt de bugs. Mais le logiciel reste généralement très léger face à certaines applications modernes de Windows, tout en offrant une compatibilité multimédia nettement plus large.

Cette controverse illustre finalement un problème plus général de Windows 11 : Microsoft cherche encore le bon équilibre entre modernisation, performances et compatibilité. Et lorsqu’un logiciel multiplateforme comme VLC doit s’adapter à ces changements, les régressions peuvent rapidement devenir visibles pour des millions d’utilisateurs.

L’article VLC accuse Windows 11 d’être à l’origine de ses ralentissements et défend le modèle open source face à Microsoft est apparu en premier sur malekal.com.

Les écrans bleus de Windows, aussi appelés BSOD, peuvent être difficiles à diagnostiquer car le code d’arrêt affiché ne suffit pas toujours à identifier la cause réelle du plantage. Windows enregistre cependant des informations techniques dans des fichiers minidump (.dmp) qui permettent d’aller plus loin dans l’analyse.

Dans ce guide, nous allons voir comment analyser un écran bleu sur Windows 11 ou Windows 10, interpréter le code d’arrêt, identifier un pilote ou un composant suspect et exploiter les minidumps avec AnalysePC, WhoCrashed, BlueScreenView ou WinDbg.

Qu’est-ce qu’un écran bleu (BSOD) et un code d’arrêt ?

Un écran bleu, aussi appelé BSOD (Blue Screen of Death), apparaît lorsque Windows rencontre une erreur critique qu’il ne peut pas récupérer normalement. Le système interrompt alors son fonctionnement afin d’éviter une corruption plus importante et redémarre généralement le PC.

L’écran affiche un code d’arrêt (Stop Code), par exemple VIDEO_TDR_FAILURE, DRIVER_POWER_STATE_FAILURE ou MEMORY_MANAGEMENT. Ce code donne une première indication sur la nature du problème, mais il ne suffit pas toujours à identifier précisément sa cause.

Windows enregistre généralement des informations supplémentaires dans un fichier minidump (.dmp). Son analyse permet de rechercher le pilote, le composant matériel ou le contexte logiciel impliqué dans le plantage.

Le guide complet :

Où Windows enregistre les informations sur les écrans bleus ?

Windows enregistre les informations liées aux écrans bleus dans des fichiers de vidage mémoire (dump). Selon la configuration du système, il peut s’agir d’un minidump léger ou d’un fichier de vidage plus complet.

Les minidumps sont généralement stockés dans :

C:\Windows\Minidump

Un fichier de vidage mémoire plus complet peut également être créé dans :

C:\Windows\MEMORY.DMP

Ces fichiers contiennent notamment le code d’arrêt, le contexte du plantage et des informations sur les pilotes chargés au moment du BSOD. Ce sont eux qu’utilisent les outils comme AnalysePC, WhoCrashed, BlueScreenView ou WinDbg pour rechercher la cause du crash.

Pour vérifier ou modifier le type de fichier de vidage créé par Windows, vous pouvez suivre ce guide :

Analyser automatiquement les écrans bleus avec AnalysePC

AnalysePC permet d’analyser automatiquement les fichiers minidump enregistrés par Windows après un écran bleu. L’outil récupère le code d’arrêt, recherche les pilotes présents dans le dump et croise ces informations avec la configuration et l’historique du PC.

Pour chaque BSOD, AnalysePC peut notamment afficher :

• le code d’arrêt détecté ;
• la piste technique la plus probable, par exemple un pilote comme nvlddmkm.sys ;
• un niveau de confiance selon la qualité des indices présents dans le dump ;
• les pilotes et versions actuellement installés ;
• les modifications de pilotes ou mises à jour intervenues avant ou après le plantage ;
• un plan d’action avec les vérifications et solutions recommandées.

L’intérêt est de ne pas se limiter au nom d’un fichier trouvé dans le minidump. AnalysePC replace le crash dans son contexte afin de déterminer si le pilote constitue réellement une piste crédible ou seulement un élément présent au moment du plantage.

Pour lancer une analyse et découvrir le fonctionnement complet de l’outil, consultez le tutoriel dédié :

Comprendre le code d’arrêt détecté

AnalysePC commence par identifier le code d’arrêt enregistré dans le fichier minidump. Il peut s’agir par exemple de VIDEO_TDR_FAILURE, DRIVER_POWER_STATE_FAILURE, MEMORY_MANAGEMENT ou encore WHEA_UNCORRECTABLE_ERROR.

Le rapport indique ensuite la signification générale du code et la famille de problèmes à laquelle il correspond. Cela permet de savoir rapidement si la piste s’oriente plutôt vers un pilote, la carte graphique, la mémoire, le stockage ou un problème matériel.

Lorsque plusieurs fichiers minidump sont disponibles, AnalysePC peut également comparer les différents BSOD afin de voir si le même code d’arrêt ou la même famille d’erreurs revient régulièrement.

Identifier le pilote ou composant suspect

Le minidump peut contenir le nom d’un pilote ou d’un module présent au moment du plantage. AnalysePC tente de transformer cette information technique en une piste plus compréhensible.

Par exemple, un fichier comme nvlddmkm.sys peut être rapproché du pilote graphique NVIDIA actuellement installé. Le rapport affiche alors le composant concerné, la version du pilote et les éléments qui renforcent ou affaiblissent cette hypothèse.

AnalysePC attribue aussi un niveau de confiance à la piste proposée. C’est important, car la présence d’un pilote dans un dump ne signifie pas automatiquement qu’il est responsable du BSOD. Le véritable problème peut provenir du matériel, d’un autre pilote ou d’une corruption survenue plus tôt.

Exploiter la chronologie des pilotes et mises à jour

AnalysePC ne se contente pas de lire le contenu du minidump. Il rapproche également le plantage de l’historique des pilotes et des mises à jour Windows disponible dans le rapport.

Cela permet notamment de repérer :

• une mise à jour de pilote installée peu avant les premiers BSOD ;
• un changement de version après un plantage ;
• plusieurs modifications successives d’un même pilote ;
• une mise à jour Windows proche de la période d’apparition des problèmes.

La chronologie aide ainsi à déterminer si un changement récent constitue une piste crédible. À l’inverse, si un pilote a été mis à jour après les plantages et qu’aucun nouvel incident n’est apparu, AnalysePC peut également signaler que le problème a peut-être déjà été corrigé.

Suivre les solutions proposées par AnalysePC

À partir du code d’arrêt, des pilotes détectés et des autres éléments du rapport, AnalysePC propose un plan de résolution adapté à la piste retenue.

Selon le problème, les recommandations peuvent par exemple consister à mettre à jour ou réinstaller proprement un pilote, revenir à une version précédente, vérifier Windows Update, contrôler les températures ou effectuer des tests matériels.

Lorsque les données ne permettent pas d’identifier une cause suffisamment fiable, le rapport le précise et propose des vérifications complémentaires plutôt que de désigner arbitrairement un responsable.

Cette dernière partie permet donc de passer directement de l’analyse du BSOD aux actions à effectuer pour confirmer la cause et tenter de corriger le problème.

Analyser un écran bleu avec WhoCrashed

WhoCrashed est un outil spécialisé dans l’analyse des fichiers minidump générés après un écran bleu. Il examine les informations enregistrées par Windows et tente d’identifier le code d’arrêt, le pilote éventuellement impliqué et la nature probable du plantage.

Son principal intérêt est sa simplicité : il fournit un rapport lisible sans nécessiter de manipuler directement les fichiers .dmp ou d’utiliser WinDbg. Il peut ainsi constituer une bonne première étape pour comprendre l’origine d’un BSOD.

L’identification d’un pilote dans WhoCrashed doit toutefois rester une piste de diagnostic. Un fichier mentionné dans le dump n’est pas nécessairement la cause réelle du problème.

Pour apprendre à utiliser l’outil et interpréter ses résultats, consultez le guide dédié :

Analyser les fichiers minidump avec BlueScreenView

BlueScreenView est un utilitaire qui analyse les fichiers minidump créés par Windows après un écran bleu. Il permet de retrouver rapidement les différents BSOD enregistrés sur le PC et d’afficher, pour chacun d’eux, le code d’arrêt, la date du plantage ainsi que les pilotes ou modules présents dans le dump.

L’outil est particulièrement pratique pour comparer plusieurs écrans bleus et repérer si le même pilote revient régulièrement. Il propose une vue plus technique que WhoCrashed, tout en restant beaucoup plus simple à utiliser que WinDbg.

Comme pour les autres outils d’analyse de minidumps, un pilote mis en évidence par BlueScreenView doit être considéré comme une piste et non comme une preuve certaine de sa responsabilité.

Pour apprendre à utiliser BlueScreenView et interpréter les informations affichées, consultez le tutoriel dédié :

Analyser un BSOD avec WinDbg

WinDbg est l’outil de débogage de Microsoft destiné à l’analyse avancée des fichiers de vidage mémoire. Il permet d’examiner en détail un minidump ou un fichier MEMORY.DMP afin d’obtenir le code d’arrêt, la pile d’appels, les modules chargés et les pilotes potentiellement impliqués dans le plantage.

Il est plus technique que WhoCrashed ou BlueScreenView, mais fournit aussi davantage d’informations. La commande !analyze -v permet notamment d’obtenir une première analyse détaillée du crash et d’identifier les éléments les plus pertinents à examiner.

WinDbg est surtout utile lorsqu’un BSOD reste difficile à expliquer ou lorsque les outils plus simples ne permettent pas d’identifier clairement la cause.

Pour apprendre à ouvrir un fichier de vidage et interpréter les informations retournées par WinDbg, consultez le tutoriel dédié :

Le tutoriel :

Comment interpréter le pilote indiqué dans le minidump ?

Lors de l’analyse d’un écran bleu, le minidump peut faire apparaître le nom d’un pilote ou d’un module, par exemple nvlddmkm.sys, rtkvhd64.sys ou encore ntoskrnl.exe. Il faut toutefois éviter de considérer automatiquement ce fichier comme la cause certaine du BSOD.

Le pilote affiché peut être directement responsable du plantage, mais il peut aussi simplement avoir été actif au moment de l’erreur. Un problème matériel, une corruption mémoire ou un autre pilote peut avoir provoqué l’instabilité avant que le fichier signalé ne soit impliqué.

Il est donc préférable de croiser plusieurs éléments : le code d’arrêt, le pilote cité, sa version, les autres minidumps disponibles et les changements récents de pilotes ou de Windows.

Si le même pilote revient dans plusieurs BSOD avec des codes cohérents, la piste devient plus crédible. À l’inverse, si les fichiers incriminés changent constamment, il peut être nécessaire d’élargir le diagnostic à la mémoire, au matériel ou à la stabilité générale du système.

C’est notamment l’intérêt d’AnalysePC, qui ne se limite pas au nom du pilote extrait du dump et tente de le replacer dans le contexte global du PC.

Les codes d’arrêt Windows les plus courants

Chaque écran bleu est associé à un code d’arrêt (Stop Code) qui donne une première indication sur la nature du problème rencontré par Windows. Certains concernent plutôt les pilotes, d’autres la mémoire, le stockage, la carte graphique ou encore une erreur matérielle.

Parmi les codes fréquemment rencontrés, on peut citer VIDEO_TDR_FAILURE, DRIVER_POWER_STATE_FAILURE, MEMORY_MANAGEMENT, CRITICAL_PROCESS_DIED ou WHEA_UNCORRECTABLE_ERROR.

Le code d’arrêt constitue toutefois seulement un point de départ : il faut généralement le croiser avec le contenu du minidump et les autres informations du PC pour identifier la cause réelle.

Pour connaître la signification des principaux codes et les solutions associées, consultez le guide dédié aux codes d’arrêt et erreurs BSOD de Windows.

Pour les connaître, suivez ce guide :

Que faire si la cause des écrans bleus reste inconnue ?

Lorsque plusieurs écrans bleus affichent des codes d’arrêt ou des pilotes différents, il ne faut pas forcément chercher une cause indépendante pour chaque BSOD. Une instabilité plus générale peut provoquer des plantages variés : mémoire défectueuse, surchauffe, alimentation, pilote instable ou autre problème matériel.

Dans ce cas, il est préférable d’élargir le diagnostic du PC plutôt que de se limiter à l’analyse d’un seul minidump. Vous pouvez notamment :

• effectuer un diagnostic complet du PC afin de rechercher des anomalies matérielles, logicielles et système ;
• lancer un StressTest Malekal pour vérifier la stabilité du processeur, de la carte graphique, de la mémoire et surveiller les températures sous charge ;
• demander de l’aide sur le forum Malekal en fournissant le rapport AnalysePC afin qu’il puisse être examiné dans son ensemble.

Les guides :

Cette approche est particulièrement utile lorsque les BSOD semblent aléatoires ou que le pilote indiqué change d’un plantage à l’autre. Dans ce cas, le problème peut se situer en amont du composant mentionné dans le minidump.

Cas particulier : des codes d’arrêt différents à chaque BSOD

Si l’analyse des minidumps ne permet pas d’identifier clairement l’origine des écrans bleus, il faut poursuivre avec des vérifications plus larges.

Commencez par contrôler les pilotes, les mises à jour de Windows, l’état du stockage et la mémoire. Un test mémoire approfondi peut être utile si les codes d’arrêt sont variés ou évoquent une corruption de données.

Il est également recommandé de surveiller les températures du processeur et de la carte graphique et, si nécessaire, d’effectuer un StressTest afin de vérifier si les plantages apparaissent sous charge.

Si aucune piste ne se dégage malgré ces contrôles, vous pouvez publier le rapport AnalysePC et les informations sur les BSOD sur le forum Malekal afin d’obtenir une analyse plus approfondie du problème.

Que faire après avoir identifié la cause du BSOD ?

Une fois le code d’arrêt identifié et les informations du minidump analysées, il devient généralement plus simple de rechercher la cause du BSOD et d’appliquer les solutions adaptées.

Selon le diagnostic, il peut être nécessaire de mettre à jour ou réinstaller un pilote, vérifier la mémoire RAM, contrôler le SSD, annuler une mise à jour récente ou rechercher une instabilité matérielle.

Pour poursuivre le dépannage, utilisez notre guide général consacré à la résolution des écrans bleus. Il regroupe les principales vérifications et solutions à appliquer lorsqu’un PC rencontre des BSOD sous Windows 11 ou Windows 10.

Suivre ce tutoriel :

L’article Comment diagnostiquer un écran bleu (BSOD) et trouver la cause sur Windows 11/10 est apparu en premier sur malekal.com.

Des chercheurs en sécurité ont dévoilé une nouvelle famille d’attaques baptisée Plug and Pwn, capable d’exploiter le mécanisme Plug and Play de Windows pour installer automatiquement des composants vulnérables et obtenir les privilèges SYSTEM.

L’attaque repose sur un principe particulièrement intéressant : au lieu d’exploiter directement Windows, les chercheurs émulent de faux périphériques USB afin de pousser le système à télécharger et installer des logiciels ou pilotes de constructeurs pourtant signés et légitimes. Certains de ces composants contiennent ensuite des faiblesses permettant une élévation de privilèges.

Présentée lors de la DEF CON 34 par les chercheurs Alejandro Hernando et Borja Martínez, cette technique peut, dans certains scénarios, fonctionner sans clic, sans utilisateur connecté et même à distance via le protocole RDP.

Plug and Play, un mécanisme pratique qui travaille avec des privilèges élevés

Lorsqu’un périphérique USB est connecté à un PC, Windows tente automatiquement de l’identifier.

Le système recherche ensuite un pilote adapté et peut également télécharger depuis Windows Update des composants supplémentaires fournis par le constructeur.

Cette installation peut inclure :

• des pilotes ;
• des services ;
• des programmes d’assistance ;
• des exécutables ;
• des « co-installers » utilisés par certains fabricants.

Le problème est que cette procédure s’exécute avec les privilèges NT AUTHORITY\SYSTEM, c’est-à-dire avec des droits supérieurs à ceux d’un administrateur classique, sans nécessairement afficher de demande UAC.

Les chercheurs se sont donc demandé ce qui se passerait s’il était possible de contrôler précisément l’identité du périphérique que Windows pense avoir détecté.

Un faux périphérique USB peut tromper Windows

Pour leurs démonstrations, les chercheurs ont utilisé le framework FaceDancer associé à du matériel comme Cynthion et GreatFET.

FaceDancer permet d’émuler un périphérique USB et de définir artificiellement ses caractéristiques : identifiant matériel, classe de périphérique, interfaces ou encore points de terminaison.

Du point de vue de Windows, le périphérique émulé ressemble alors à un véritable appareil connecté au port USB. Le système tente donc de rechercher le pilote et les logiciels associés comme s’il s’agissait du matériel original.

Les chercheurs peuvent même modifier l’identité du périphérique en cours d’attaque, en le faisant disparaître puis réapparaître comme un autre matériel.

Cette possibilité leur permet de chaîner plusieurs composants vulnérables provenant de fabricants différents.

Une attaque sans clic sur un Windows 11 entièrement à jour

La démonstration la plus impressionnante combine des composants liés à Sierra Wireless et Sony FeliCa.

Dans un premier temps, le faux périphérique se présente comme un appareil Sierra Wireless. Windows installe alors automatiquement le logiciel correspondant.

Les chercheurs exploitent une faiblesse de ce composant pour modifier les paramètres DNS de la machine.

Le périphérique change ensuite d’identité pour se faire passer pour un appareil Sony FeliCa.

Windows télécharge alors un autre logiciel constructeur. Celui-ci récupère certains fichiers via une connexion non chiffrée.

Comme les attaquants ont auparavant pris le contrôle de la résolution DNS, ils peuvent rediriger ces téléchargements vers leur propre serveur et faire déposer un fichier malveillant avec les privilèges SYSTEM.

Enfin, le périphérique se présente de nouveau comme l’appareil Sierra Wireless afin de provoquer le chargement du fichier malveillant.

Le résultat est l’ouverture d’un reverse shell avec les privilèges SYSTEM.

D’après les chercheurs, cette chaîne d’attaque fonctionne contre un Windows 11 entièrement mis à jour, sans utilisateur connecté, et nécessite environ cinq minutes.

Pas besoin d’une clé USB classique

Il ne faut pas imaginer cette attaque comme une simple clé USB malveillante du type BadUSB.

Les chercheurs ont besoin de pouvoir émuler précisément différents périphériques USB et leurs identifiants matériels.

Le matériel utilisé pour leurs démonstrations est néanmoins suffisamment compact pour être transporté facilement. Selon Alejandro Hernando, un Raspberry Pi configuré en mode USB Gadget pourrait théoriquement également être utilisé pour ce type d’attaque.

En revanche, le Flipper Zero ne permet pas actuellement d’exécuter directement cette technique, car son mode BadUSB est principalement destiné à l’émulation de périphériques HID comme un clavier et ne dispose pas du support nécessaire pour FaceDancer.

NoPlug & Pwn : l’attaque peut aussi fonctionner à distance via RDP

Encore plus surprenant, les chercheurs ont développé une variante baptisée NoPlug & Pwn, qui ne nécessite même plus de périphérique USB physiquement connecté au PC ciblé.

Cette technique exploite la redirection des périphériques USB via le Bureau à distance (RDP).

Cette fonction permet normalement à un périphérique branché sur le PC local d’être rendu disponible à l’intérieur d’une session distante.

Les chercheurs ont créé un client RDP capable d’envoyer directement de faux descripteurs USB.

Le serveur Windows distant croit alors qu’un véritable périphérique vient d’être connecté et déclenche le mécanisme Plug and Play habituel.

Dans leur démonstration, ils ont émulé une caméra Intel RealSense.

Windows Update récupère le package associé, qui contient un co-installer vulnérable à un détournement de DLL. Les chercheurs exploitent ensuite cette faiblesse pour obtenir les privilèges SYSTEM sur la machine distante.

Cette variante nécessite toutefois que la redirection USB via RDP soit activée. Elle pourrait notamment concerner certains environnements de bureaux virtuels où cette fonctionnalité est couramment utilisée.

Ce n’est pas une nouvelle idée, mais l’attaque va beaucoup plus loin

Le principe rappelle une vulnérabilité médiatisée en 2021 avec Razer Synapse.

À l’époque, le simple branchement d’une souris ou d’un clavier Razer pouvait pousser Windows à télécharger automatiquement l’installateur Synapse avec les privilèges SYSTEM.

Une faiblesse de cet installateur permettait alors de lancer PowerShell depuis l’interface d’installation et d’hériter des mêmes privilèges élevés.

Les chercheurs à l’origine de Plug and Pwn expliquent toutefois avoir adopté une approche plus générale.

Plutôt que de cibler uniquement la vulnérabilité d’un installateur particulier, ils se sont intéressés à toute la chaîne d’installation automatique des périphériques Windows.

Le problème devient alors beaucoup plus large : Windows peut automatiquement installer des composants de nombreux constructeurs différents, et il suffit qu’un de ces éléments comporte une faiblesse exploitable pour qu’il puisse entrer dans une chaîne d’attaque.

Pourquoi des pilotes signés peuvent-ils être dangereux ?

Un pilote ou un logiciel signé n’est pas nécessairement exempt de vulnérabilités.

La signature permet principalement de vérifier l’origine du fichier et de s’assurer qu’il n’a pas été modifié depuis sa publication.

Elle ne garantit pas que son code est parfaitement sécurisé.

Plug and Pwn exploite précisément cette différence : Windows fait confiance à des packages légitimes et signés, mais certains de leurs composants peuvent contenir des vulnérabilités anciennes ou des comportements dangereux.

Les attaquants ne cherchent donc pas nécessairement à faire installer un pilote malveillant inconnu.

Ils poussent Windows à installer des logiciels légitimes mais vulnérables, puis exploitent ces vulnérabilités pour obtenir davantage de privilèges.

A lire :

Désactiver les co-installers peut limiter certaines attaques

Une première mesure de protection consiste à désactiver l’exécution des co-installers lors de l’installation des périphériques.

Cela peut être réalisé avec la valeur de Registre :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Device Installer

puis en créant une valeur DWORD :

DisableCoInstallers = 1

D’après les chercheurs, cette configuration bloque certaines des chaînes d’attaque présentées, notamment celles exploitant Sony FeliCa ou Intel RealSense.

Cette mesure ne supprime toutefois pas complètement la surface d’attaque.

Windows continue notamment :

• d’énumérer les périphériques Plug and Play ;
• de rechercher les pilotes dans Windows Update ;
• d’interpréter les fichiers INF ;
• d’installer certains services déclarés par ces fichiers.

Les entreprises peuvent durcir davantage l’installation des périphériques

Sur les postes sensibles, les chercheurs recommandent de combiner plusieurs protections.

Les administrateurs peuvent notamment :

• désactiver les co-installers ;
• appliquer des restrictions d’installation des périphériques ;
• autoriser uniquement certains identifiants matériels ;
• désactiver la redirection Plug and Play dans les environnements RDP ou VDI lorsqu’elle n’est pas nécessaire.

Cette dernière protection est particulièrement importante contre la variante NoPlug & Pwn.

La stratégie RDP correspondante peut notamment être contrôlée à travers le paramètre lié à fDisablePNPRedir.

Tous les scénarios ne sont pas considérés comme de nouvelles vulnérabilités

Les chercheurs n’ont pas signalé chacune de leurs chaînes d’exploitation comme une nouvelle faille indépendante auprès des différents constructeurs.

La raison est importante : Plug and Pwn repose souvent sur la combinaison de plusieurs comportements légitimes et de vulnérabilités existantes.

Une fonctionnalité prise isolément n’est donc pas nécessairement vulnérable.

C’est l’enchaînement qui devient dangereux : faux périphérique → détection Plug and Play → téléchargement automatique → installation avec les droits SYSTEM → exploitation d’un composant vulnérable

Cette approche illustre parfaitement la notion de chaîne d’exploitation, où plusieurs faiblesses relativement limitées permettent ensemble d’obtenir un résultat beaucoup plus grave.

Une attaque surtout préoccupante pour les environnements sensibles

Pour un particulier, Plug and Pwn reste une attaque relativement sophistiquée.

La version physique nécessite qu’un attaquant puisse connecter un dispositif spécialisé au PC, tandis que la variante distante dépend de la présence d’un accès RDP et de la redirection des périphériques.

Le risque est donc surtout important dans les entreprises, les infrastructures sensibles, les postes partagés et les environnements de bureaux virtuels.

Mais ces recherches mettent en évidence un problème plus général : le simple fait de brancher un périphérique peut déclencher l’exécution automatique de composants tiers avec des privilèges extrêmement élevés.

Cette confiance accordée au processus d’installation des pilotes constitue une surface d’attaque difficile à éliminer complètement.

Conclusion

Plug and Pwn ne repose pas sur une unique faille spectaculaire de Windows, mais sur l’exploitation d’un mécanisme profondément intégré au système : l’installation automatique des périphériques.

En imitant des appareils légitimes, les chercheurs ont réussi à pousser Windows 11 à télécharger des packages signés de constructeurs, puis à combiner leurs faiblesses pour obtenir les privilèges SYSTEM.

Le fait qu’une variante puisse également fonctionner à travers RDP sans connecter physiquement de périphérique montre que le problème dépasse largement la simple menace des clés USB inconnues.

Ces travaux rappellent surtout qu’un pilote signé ou un logiciel distribué par Windows Update n’est pas nécessairement sans risque. La sécurité dépend également de la qualité des composants fournis par les fabricants et de la façon dont Windows les installe avec des privilèges élevés.

Pour les environnements sensibles, restreindre l’installation des périphériques, désactiver les co-installers inutiles et limiter la redirection USB via RDP constituent donc des mesures de durcissement pertinentes.

L’article Plug and Pwn : de faux périphériques USB peuvent donner les droits SYSTEM sous Windows est apparu en premier sur malekal.com.

Microsoft a introduit dans Windows 11 un nouveau profil à faible latence, appelé Low Latency Profile (LLP) en anglais, afin d’améliorer la réactivité du système lors de certaines interactions courtes.

Son principe est de permettre au processeur d’augmenter rapidement ses performances lorsqu’une action nécessite une réponse immédiate, par exemple lors de l’ouverture du menu Démarrer, de la recherche Windows, de certains éléments de l’interface ou du lancement d’applications, puis de revenir à un fonctionnement normal une fois l’opération terminée.

L’objectif n’est donc pas de maintenir le CPU à pleine puissance en permanence, mais de rendre Windows 11 plus réactif au bon moment, tout en limitant l’impact sur la consommation, la batterie et les températures.

Dans ce guide, découvrez comment fonctionne le profil à faible latence de Windows 11, dans quelles situations il intervient, quels gains de réactivité attendre, son impact sur les jeux et l’autonomie, comment savoir s’il est actif et quelles solutions appliquer en cas de problème.

Qu’est-ce que le profil à faible latence de Windows 11 ?

Le profil à faible latence, appelé Low Latency Profile (LLP) en anglais, est une optimisation introduite dans Windows 11 pour améliorer la réactivité du système lors de certaines interactions courtes. Son déploiement a commencé avec les mises à jour de Windows 11 de juin 2026.

Son principe est assez simple : lorsqu’une action nécessitant une réponse rapide est détectée, Windows peut augmenter temporairement la fréquence du processeur afin d’exécuter cette tâche plus rapidement.

Le profil peut notamment intervenir lors de certaines actions comme :

• L’ouverture du menu Démarrer.
• L’utilisation de la recherche Windows.
• L’affichage du Centre de notifications/actions.
• L’ouverture de certains menus et éléments de l’interface.
• Le lancement d’applications, selon les améliorations progressivement déployées par Microsoft.

Comme l’illustre le schéma ci-dessus, cette augmentation des performances est ponctuelle. Le processeur peut fonctionner à une fréquence élevée pendant environ une à trois secondes, puis Windows revient à son fonctionnement normal lorsque le besoin de réactivité disparaît.

Le but n’est donc pas d’augmenter en permanence les performances du processeur, mais de rendre Windows plus réactif au moment précis où l’utilisateur effectue une action.

Un mécanisme progressivement étendu aux applications

Les premières améliorations ont surtout concerné les éléments essentiels de l’interface de Windows, comme Démarrer, la recherche et le Centre de notifications/actions. Microsoft étend également ce mécanisme au lancement des applications, afin qu’elles puissent profiter de la même accélération ponctuelle du processeur.

Le profil à faible latence n’est donc pas réservé aux applications Microsoft. Les informations disponibles indiquent que les applications Windows traditionnelles tierces peuvent également en bénéficier lors de leur lancement.
C’est notamment le cas depuis le KB5121003.

En revanche, il ne faut pas le considérer comme un mode destiné aux charges longues et intensives telles qu’un rendu vidéo, un benchmark ou un jeu fonctionnant pendant plusieurs heures. Son intérêt se situe principalement dans les courtes périodes où Windows doit répondre immédiatement à une action de l’utilisateur.

C’est cette succession de petites accélérations qui doit rendre l’utilisation quotidienne de Windows 11 plus fluide, sans maintenir inutilement le processeur à une fréquence élevée lorsque le PC est au repos ou qu’aucune interaction ne le nécessite.

Quels gains de réactivité peut-on attendre ?

Le profil à faible latence vise principalement à réduire le délai entre une action de l’utilisateur et la réponse de Windows 11. Il ne rend donc pas le processeur intrinsèquement plus rapide : il permet surtout à Windows d’exploiter plus rapidement les performances disponibles lors de courtes interactions.

Les premiers tests rapportés avec cette fonctionnalité montrent des gains pouvant atteindre :

• Jusqu’à 40 % de réduction du temps de lancement de certaines applications.
• Jusqu’à 70 % d’amélioration sur certaines interactions avec l’interface de Windows, notamment l’ouverture du menu Démarrer ou de menus contextuels.

Ces chiffres correspondent toutefois aux meilleurs résultats observés et ne signifient pas que Windows 11 devient globalement 40 ou 70 % plus rapide. Le gain dépend du processeur, de la configuration du PC, de l’application utilisée et surtout du temps que le CPU représentait initialement dans l’opération.

Des gains surtout visibles sur les PC les moins réactifs

Sur un PC récent et puissant, une application ou le menu Démarrer peuvent déjà s’ouvrir très rapidement. Gagner quelques dizaines de millisecondes peut alors être difficile à percevoir.

L’amélioration peut être plus sensible sur un ordinateur portable ou un PC moins performant, notamment lorsque le processeur fonctionne habituellement à une fréquence réduite pour limiter sa consommation. Le profil à faible latence lui permet alors d’augmenter plus rapidement sa fréquence lorsqu’une interaction utilisateur le nécessite.

L’objectif est donc avant tout d’améliorer la sensation de réactivité : menus qui apparaissent plus rapidement, applications qui commencent leur lancement plus tôt et interface qui répond plus immédiatement aux actions de l’utilisateur.

Le profil à faible latence améliore-t-il les performances dans les jeux ?

Malgré son nom, le profil à faible latence de Windows 11 n’est pas une optimisation spécifiquement destinée aux jeux vidéo. Son objectif principal est d’améliorer la réactivité de Windows lors d’actions courtes, comme l’ouverture d’une application, du menu Démarrer, de la recherche ou de certains éléments de l’interface.

Le mécanisme augmente temporairement les performances du processeur lorsqu’une tâche sensible à la latence est détectée, puis revient à un fonctionnement normal après quelques secondes. Il n’est donc pas conçu pour maintenir des fréquences CPU plus élevées pendant toute une session de jeu. Les informations disponibles actuellement n’indiquent pas de gain direct attendu sur les FPS.

Ne pas confondre avec la latence dans les jeux

Le terme « faible latence » peut prêter à confusion. Dans le cas du profil à faible latence, il s’agit principalement de réduire le temps de réponse de Windows pour certaines interactions.

Ce n’est pas la même chose que la latence d’entrée (input lag) d’un jeu, qui correspond au délai entre une action effectuée avec la souris, le clavier ou la manette et son résultat visible à l’écran.

Le profil à faible latence ne doit donc pas être confondu avec :

• NVIDIA Reflex et les technologies équivalentes destinées à réduire la latence de la chaîne de rendu.
• Les réglages de faible latence proposés par certains pilotes graphiques.
• Le Mode Jeu de Windows.
• Les optimisations graphiques de Windows 11.
• La fréquence de rafraîchissement variable (VRR).
• Le ping ou la latence d’une connexion réseau.

Windows 11 dispose d’ailleurs d’une fonction distincte appelée Optimisations pour les jeux fenêtrés, qui peut réduire la latence des images de certains jeux DirectX 10 et DirectX 11 fonctionnant en mode fenêtré ou sans bordure.

Le guide complet :

Un bénéfice possible autour du lancement du jeu

Le profil à faible latence peut néanmoins améliorer la réactivité avant le jeu. Le lancement du jeu ou de son launcher peut bénéficier de l’accélération temporaire du processeur, comme n’importe quelle autre application compatible avec ce mécanisme.

Une fois le jeu lancé et le CPU/GPU sollicités en continu, le profil à faible latence n’a plus le même objectif. Il ne faut donc pas attendre de cette fonction une augmentation significative des FPS, une réduction du ping ou une diminution directe de l’input lag.

Pour les joueurs, le profil à faible latence doit ainsi être considéré avant tout comme une amélioration de la réactivité générale de Windows 11, et non comme une nouvelle optimisation des performances gaming.

Quel impact sur la consommation, la batterie et les températures ?

Le profil à faible latence augmente temporairement les performances du processeur lorsqu’une interaction nécessitant une réponse rapide est détectée. Cette montée en fréquence entraîne logiquement une augmentation ponctuelle de la consommation électrique et de la chaleur produite par le CPU.

Toutefois, contrairement à un mode de performances élevées utilisé en permanence, cette sollicitation ne dure généralement que quelques secondes. Une fois l’opération terminée, le processeur peut revenir à un état de fonctionnement plus économe. Le principe est justement d’obtenir davantage de performances au moment où elles sont utiles sans maintenir continuellement le CPU à une fréquence élevée.

Quel impact sur l’autonomie d’un PC portable ?

Sur batterie, ces accélérations peuvent entraîner une légère augmentation de la consommation. L’impact réel sur l’autonomie dépend toutefois de la fréquence à laquelle le mécanisme est sollicité, du processeur et de la gestion énergétique définie par le constructeur du PC.

Windows dispose par ailleurs de paramètres de gestion du processeur qui tiennent compte à la fois des besoins de performances et de l’efficacité énergétique lors des opérations sensibles à la latence. Microsoft documente notamment LatencyHintEpp, qui définit la préférence entre performances et économie d’énergie lorsqu’un indicateur de sensibilité à la latence est détecté.

Le profil à faible latence ne doit donc pas être assimilé à un mode qui maintient constamment le processeur à sa fréquence maximale.

Le tutoriel :

Les températures vont-elles augmenter ?

Une augmentation momentanée de la fréquence CPU peut également provoquer une petite hausse ponctuelle de la température, notamment lors du lancement d’une application.

En pratique, ces phases étant très courtes, elles ne sont pas comparables à une charge prolongée comme un jeu, un encodage vidéo ou un stress test. Le système de refroidissement et les mécanismes de gestion thermique du PC continuent par ailleurs de limiter les performances lorsque cela est nécessaire pour maintenir le matériel dans ses conditions normales de fonctionnement.

Il ne faut donc pas s’attendre à une hausse importante et permanente des températures simplement parce que le profil à faible latence est utilisé. Son principe repose justement sur des accélérations brèves du processeur, suivies d’un retour à son fonctionnement normal.

Les guides complets :

Profil à faible latence ou mode Performances élevées : quelles différences ?

Le profil à faible latence et le mode Performances élevées agissent tous les deux sur la gestion des performances du processeur, mais leur fonctionnement et leur objectif sont différents.

Le profil à faible latence est un profil de gestion du processeur activé automatiquement dans certaines situations, notamment pendant le démarrage et le lancement des applications. Windows dispose de plusieurs profils de ce type — par défaut, faible consommation, mode jeu, faible latence, etc. — afin d’adapter la gestion du CPU au scénario en cours.

Le mode Performances élevées, en revanche, est un mode d’alimentation général. Il modifie durablement la politique énergétique de Windows afin de privilégier davantage les performances au détriment de la consommation électrique.

Profil à faible latence	Performances élevées
Activé automatiquement par Windows	Sélectionné comme mode ou plan d’alimentation
Utilisé pour certaines tâches sensibles à la latence	S’applique de manière beaucoup plus générale au fonctionnement du PC
Agit pendant de courtes périodes	Reste actif tant que le mode d’alimentation est utilisé
Cherche à améliorer la réactivité	Privilégie globalement les performances
Conserve une logique d’économie d’énergie hors des périodes concernées	Peut augmenter davantage la consommation énergétique
Ne constitue pas un nouveau mode d’alimentation visible	Fait partie des réglages d’alimentation de Windows

A lire :

Une accélération ciblée plutôt qu’un mode permanent

Lorsqu’un indicateur de sensibilité à la latence est détecté, Windows peut demander au moteur de gestion des performances du processeur d’augmenter temporairement son niveau de performances. Il peut également adapter la préférence entre performances et efficacité énergétique ou maintenir davantage de cœurs disponibles selon la configuration.

Le principe peut être résumé ainsi :

Profil à faible latence : Interaction → besoin de réactivité → performances CPU augmentées → tâche terminée → retour au fonctionnement normal.

Performances élevées : Mode activé → politique énergétique orientée performances → fonctionnement maintenu jusqu’au changement de mode.

Cette différence permet au profil à faible latence d’améliorer la sensation de réactivité sans imposer en permanence une politique énergétique agressive.

Les deux mécanismes peuvent coexister

Il ne faut donc pas considérer le profil à faible latence comme le remplaçant du mode Performances élevées. Ils interviennent à des niveaux différents de la gestion énergétique de Windows.

Le profil à faible latence répond à un besoin ponctuel de réactivité, tandis que le mode Performances élevées convient davantage lorsqu’on souhaite privilégier globalement les performances du PC pendant une période prolongée.

Pour la plupart des utilisateurs, il n’est donc pas nécessaire d’activer le mode Performances élevées simplement pour profiter du profil à faible latence : Windows gère automatiquement ce dernier lorsqu’un scénario compatible est détecté.

Comment obtenir le profil à faible latence sur Windows 11 ?

Le profil à faible latence est distribué automatiquement par Windows Update. Il n’existe donc pas de programme particulier à télécharger ni de nouveau mode d’alimentation à installer manuellement.

Microsoft a commencé son déploiement sur Windows 11 24H2 et 25H2 avec les mises à jour de 2026. La mise à jour cumulative KB5094126 du 9 juin 2026, pour les builds 26100.8655 et 26200.8655, concerne justement Windows 11 24H2 et 25H2.
Le Patch Tuesday d’Août 2026 (KB5121003) étend ce mécanisme aux applications).

Pour disposer des dernières améliorations :

• Ouvrez les Paramètres de Windows 11.
• Accédez à Windows Update.
• Cliquez sur Rechercher des mises à jour.
• Installez les mises à jour disponibles.
• Redémarrez le PC lorsque Windows le demande.

Vous pouvez vérifier votre version de Windows avec la commande :

winver

Le tutoriel :

Un déploiement progressif

Installer la dernière mise à jour de Windows 11 ne signifie pas nécessairement que le profil à faible latence sera immédiatement actif sur votre PC.

Microsoft utilise un déploiement progressif (Controlled Feature Rollout). Une fonctionnalité peut donc être présente dans les fichiers de Windows mais rester désactivée jusqu’à ce que Microsoft l’active sur votre appareil. Le déploiement de LLP avec les améliorations de lancement des applications a justement été présenté comme progressif.

Deux PC équipés de la même version et de la même mise à jour de Windows 11 peuvent donc temporairement ne pas bénéficier de la fonctionnalité au même moment.

Il n’y a normalement aucune notification indiquant que le profil à faible latence vient d’être activé, puisqu’il s’agit d’une optimisation transparente de Windows.

Faut-il forcer son activation ?

Des outils comme ViVeTool permettent techniquement de modifier certains identifiants de fonctionnalités internes de Windows et ont été utilisés pour forcer l’activation de LLP avant la fin de son déploiement.

Je déconseille toutefois cette méthode pour un PC utilisé normalement. Si Microsoft effectue un déploiement progressif, c’est notamment pour pouvoir surveiller le comportement de la fonctionnalité sur différentes configurations avant de l’étendre à davantage de machines.

Le plus simple est donc de maintenir Windows 11 à jour et de laisser Windows Update activer automatiquement le profil à faible latence lorsqu’il devient disponible pour votre PC.

La difficulté est alors de savoir si cette optimisation est déjà active, puisqu’aucun interrupteur n’est affiché dans les Paramètres. La section suivante explique comment tenter de le vérifier.

Comment savoir si le profil à faible latence est actif ?

Le profil à faible latence fonctionne de manière transparente en arrière-plan. Windows 11 n’affiche actuellement ni interrupteur dans les Paramètres, ni notification, ni indicateur permettant de confirmer directement son activation.

La méthode la plus simple consiste donc à observer le comportement de la fréquence du processeur lorsqu’une action susceptible de déclencher le profil est effectuée.

Vérifier avec le Gestionnaire des tâches

Vous pouvez effectuer un premier test avec le Gestionnaire des tâches :

• Ouvrez le gestionnaire de tâches par un clic droit sur le menu Démarrer ou utilisez le raccourci clavier + X
• Puis Gestionnaire des tâches. Vous pouvez aussi utiliser le raccourci clavier CTRL+MAJ+ESC[/su_rclavier
• Cliquez sur Performances.
• Sélectionnez Processeur.
• Laissez le PC au repos quelques instants afin que la fréquence CPU redescende.
• Ouvrez ensuite plusieurs fois le menu Démarrer, la recherche Windows ou le Centre de notifications/actions.
• Observez la valeur Vitesse du processeur.

Lorsque le profil à faible latence intervient, le processeur peut effectuer une montée très rapide en fréquence, puis revenir presque immédiatement à une fréquence plus faible lorsque l’interaction est terminée.

Le Gestionnaire des tâches n’est toutefois pas idéal pour observer un phénomène aussi court. Son taux de rafraîchissement peut faire manquer une augmentation de fréquence qui ne dure qu’une à trois secondes.

Vérifier plus précisément avec HWiNFO

Pour une observation plus précise, vous pouvez utiliser HWiNFO et ses capteurs.

Laissez d’abord Windows au repos pendant une ou deux minutes, puis surveillez les fréquences des cœurs du processeur pendant que vous ouvrez successivement :

• Le menu Démarrer.
• La recherche Windows.
• Le Centre de notifications/actions.
• Éventuellement une application lorsque le déploiement du profil pour le lancement des applications est actif sur votre PC.

Vous devez rechercher une augmentation brève et nette des fréquences CPU au moment exact de l’interaction, suivie d’un retour rapide vers les fréquences de repos. C’est le comportement caractéristique recherché pour vérifier le fonctionnement du profil à faible latence.

Le guide complet :

L’absence de pic ne prouve pas que le profil est désactivé

Cette méthode reste une vérification indirecte. Une absence de variation évidente ne permet pas à elle seule d’affirmer que le profil à faible latence est désactivé.

Sur un PC configuré en mode Performances élevées, par exemple, le processeur peut déjà fonctionner à une fréquence importante. Le changement sera alors beaucoup moins visible. De même, les mécanismes de boost, le type de processeur et la gestion énergétique du constructeur influencent fortement les fréquences observées.

Enfin, Microsoft déploie progressivement certaines améliorations du profil. Deux PC disposant de la même version de Windows 11 peuvent donc temporairement présenter un comportement différent.

En pratique, si Windows 11 est à jour et que vous observez des pics courts de fréquence CPU précisément lors de l’ouverture des éléments de l’interface concernés, c’est un bon indice que le profil à faible latence fonctionne sur votre PC.

Peut-on activer ou désactiver le profil à faible latence ?

Le profil à faible latence est conçu comme une fonction automatique de Windows 11. Microsoft ne propose actuellement aucun interrupteur dans les Paramètres permettant de l’activer ou de le désactiver manuellement.

Une fois la fonctionnalité déployée sur votre PC par Windows Update, Windows décide automatiquement quand utiliser ce profil selon les opérations sensibles à la latence. Les paramètres sous-jacents de gestion du processeur, comme PerfLatencyHint, existent bien dans Windows, mais ils sont masqués et destinés à la gestion interne de l’alimentation, plutôt qu’à une configuration classique par l’utilisateur.

Il n’est donc normalement pas nécessaire de modifier le Registre, les options d’alimentation ou les paramètres du processeur pour profiter du profil à faible latence.

Forcer l’activation ou la désactivation avec ViVeTool

Pendant le déploiement progressif de la fonctionnalité, il est toutefois possible de modifier son état avec ViVeTool, un outil tiers permettant de gérer certaines fonctionnalités expérimentales ou progressivement déployées de Windows 11.

L’identifiant actuellement associé au profil à faible latence est :

58989092

Pour forcer son activation :

vivetool /enable /id:58989092

• Puis redémarrez Windows.

Pour le désactiver :

vivetool /disable /id:58989092

Redémarrez également le PC après la modification. Cet identifiant et ces commandes sont actuellement utilisés pour le déploiement 2026 du profil à faible latence.

Pour plus de détails, suivez ce tutoriel :

Faut-il utiliser ViVeTool ?

Dans la majorité des cas, non. Il est préférable de laisser Windows Update gérer automatiquement l’activation du profil à faible latence.

Un déploiement progressif permet notamment à Microsoft de contrôler l’arrivée d’une fonctionnalité sur différentes configurations. Forcer son activation peut donc exposer votre PC à un comportement qui n’a pas encore été généralisé à votre configuration.

ViVeTool peut toutefois être utile pour effectuer des tests ou revenir temporairement en arrière lorsqu’un problème apparaît précisément après l’activation du profil. Des utilisateurs ont par exemple signalé avoir désactivé l’identifiant 58989092 pour vérifier si LLP était à l’origine d’un problème, mais ces témoignages ne permettent pas de conclure à un problème généralisé de la fonctionnalité.

Enfin, les identifiants internes utilisés par Windows peuvent évoluer au fil des mises à jour. Avant d’utiliser ViVeTool, vérifiez donc que l’identifiant indiqué correspond toujours à votre version actuelle de Windows 11.

Pour une utilisation normale, la meilleure solution reste de maintenir Windows 11 à jour et de laisser le profil à faible latence fonctionner automatiquement en arrière-plan.

Que faire en cas de problème avec le profil à faible latence ?

Le profil à faible latence fonctionne normalement de manière transparente et ne nécessite aucune intervention. Toutefois, si vous constatez des ralentissements, une fréquence CPU anormalement élevée, une consommation excessive ou un comportement inhabituel apparu après une mise à jour de Windows 11, vous pouvez effectuer quelques vérifications.

À ce jour, Microsoft ne signale pas dans les problèmes connus de la mise à jour KB5094126 de dysfonctionnement généralisé directement attribué au profil à faible latence. Des utilisateurs ont néanmoins rapporté certains comportements anormaux après son déploiement ; ces témoignages ne suffisent pas à établir que LLP en est systématiquement responsable.

Commencez par :

• Installer les dernières mises à jour de Windows 11, car les mises à jour cumulatives suivantes peuvent corriger des problèmes apparus dans les versions précédentes.
• Mettre à jour les pilotes du chipset et du processeur depuis le fabricant du PC ou de la carte mère.
• Vérifier si une mise à jour du BIOS/UEFI est disponible.
• Revenir temporairement au mode d’alimentation Équilibré si vous utilisez Performances élevées ou un profil constructeur particulièrement agressif.
• Surveiller la charge, les fréquences et les températures CPU avec le Gestionnaire des tâches ou HWiNFO afin de vérifier si le processeur revient correctement à un état de faible consommation après une interaction.

Le comportement attendu est une montée en fréquence très courte, généralement de quelques secondes, suivie d’un retour à un fonctionnement normal. Un processeur qui reste continuellement à une fréquence élevée ne correspond donc pas au principe normal du profil à faible latence.

Désactiver temporairement le profil pour effectuer un test

Si le problème est apparu précisément après l’arrivée du profil à faible latence, une méthode de diagnostic consiste à le désactiver temporairement, puis à comparer le comportement du PC.

Avec ViVeTool, lorsque l’identifiant 58989092 correspond bien à la fonctionnalité sur votre version de Windows, vous pouvez utiliser :

vivetool /disable /id:58989092

Redémarrez ensuite Windows et vérifiez si le problème disparaît. Des utilisateurs ont utilisé cette méthode comme test après KB5094126, mais il s’agit d’un contournement non officiel et non d’un correctif recommandé par Microsoft.

Si le problème persiste avec le profil désactivé, il est probablement nécessaire de rechercher une autre cause : pilote, mise à jour Windows, logiciel tiers, gestion de l’alimentation ou problème matériel.

Si, au contraire, le problème disparaît systématiquement lorsque le profil est désactivé et réapparaît lorsqu’il est réactivé, cette comparaison constitue un indice beaucoup plus solide d’un lien avec la fonctionnalité. Dans ce cas, vous pouvez laisser le profil désactivé temporairement et attendre une prochaine mise à jour de Windows 11.

Conclusion

Le profil à faible latence de Windows 11 est avant tout une optimisation de la réactivité plutôt qu’un nouveau mode destiné à augmenter les performances générales du PC. Windows l’utilise ponctuellement lorsqu’une action nécessite une réponse rapide, puis laisse le processeur revenir à son fonctionnement habituel une fois l’opération terminée.

Son intérêt est donc surtout perceptible lors du lancement d’applications et de certaines interactions avec l’interface de Windows 11. Il ne faut pas en attendre une augmentation importante des FPS, une réduction du ping ou une accélération des tâches longues et intensives.

Pour la plupart des utilisateurs, il n’y a d’ailleurs rien à configurer : le profil est distribué progressivement par Windows Update et fonctionne automatiquement. Les utilisateurs avancés peuvent néanmoins surveiller les variations de fréquence du processeur avec le Gestionnaire des tâches ou HWiNFO, voire utiliser ViVeTool pour effectuer des tests lorsque cela est nécessaire.

Vérifier le comportement et les performances de son PC

Si vous souhaitez aller plus loin et vérifier comment votre processeur et les autres composants se comportent lorsqu’ils sont réellement sollicités, vous pouvez utiliser StressTest Malekal.

Le service effectue différents scénarios de charge sous Windows 11/10 et analyse notamment les fréquences CPU/GPU, les températures, le refroidissement, les performances, les limitations thermiques et les éventuelles erreurs matérielles WHEA.

Cela permet par exemple de déterminer si le processeur maintient correctement ses fréquences sous charge, si les températures restent maîtrisées ou si une limitation thermique ou énergétique réduit les performances du PC.

Le guide d’utilisation :

L’article Profil à faible latence de Windows 11 : fonctionnement et performances est apparu en premier sur malekal.com.

Pour analyser votre PC sous Windows 11 ou Windows 10, le système et sa configuration matérielle, vous pouvez utiliser AnalysePC. Ce service permet de générer un diagnostic complet afin de détecter les problèmes liés au système, au démarrage, aux pilotes, aux services, aux disques ou encore aux performances.
AnalysePC : analyser son PC Windows et détecter les problèmes automatiquement.

Mais certaines anomalies n’apparaissent que lorsque le matériel est fortement sollicité. Un processeur peut fonctionner normalement au repos puis surchauffer ou réduire ses fréquences sous charge. De même, une carte graphique peut devenir instable, le refroidissement peut montrer ses limites ou des erreurs matérielles peuvent apparaître pendant un effort prolongé.

C’est pour compléter ce diagnostic que StressTest Malekal permet de vérifier la santé et le comportement d’un PC sous Windows 11 ou Windows 10 lorsqu’il est soumis à une forte charge. Les tests sont exécutés avec Malekal Optimisation Center (MOC), qui sollicite les différents composants et collecte leurs mesures. StressTest Malekal analyse ensuite les résultats afin de présenter les températures, fréquences, performances, graphiques, scores et éventuelles anomalies détectées.

Dans ce guide, découvrez comment utiliser StressTest Malekal sous Windows 11 et Windows 10 et interpréter les résultats concernant le CPU, le GPU, le refroidissement, la mémoire RAM, le stockage, le thermal throttling et les erreurs WHEA.

Qu’est-ce que StressTest Malekal ?

StressTest Malekal est un service gratuit qui permet de tester le comportement, les performances et la stabilité du matériel de votre PC en Windows 11/10 lorsqu’il est soumis à différentes charges de travail.

Contrairement à un simple benchmark qui fournit principalement un score de performances, StressTest Malekal cherche à déterminer comment les composants se comportent pendant l’effort. Le service analyse notamment l’évolution de la charge, des températures et des fréquences afin de détecter une surchauffe, une baisse anormale des performances ou un problème de stabilité.

Le test s’appuie sur Malekal Optimisation Center (MOC) pour solliciter et collecter les mesures du PC. Une fois les tests terminés, les données sont envoyées vers StressTest Malekal afin de générer un rapport détaillé et plus facile à interpréter.

L’analyse porte notamment sur :

Élément testé	Ce que StressTest Malekal vérifie
Processeur (CPU)	Charge, fréquences, températures et maintien des performances pendant l’effort
Carte graphique (GPU)	Charge GPU, températures, fréquences et comportement sous forte sollicitation
Mémoire RAM	Performances mémoire et débits obtenus pendant le benchmark
SSD / stockage	Performances du périphérique de stockage pendant les tests
Refroidissement	Montée en température, températures maximales et comportement lors de la récupération
Thermal throttling	Recherche d’une réduction des fréquences provoquée notamment par une température trop élevée
Stabilité	Recherche d’anomalies apparaissant pendant les différentes phases de charge
Erreurs WHEA	Détection d’erreurs matérielles signalées par Windows pendant les tests

StressTest Malekal ne se contente donc pas de répondre à la question « mon PC est-il rapide ? ». L’objectif est également de déterminer s’il maintient correctement ses performances sous charge, si son refroidissement est suffisant et si des anomalies apparaissent lorsque le CPU, le GPU ou les autres composants sont sollicités.

L’intérêt est surtout de croiser plusieurs mesures. Une température élevée n’est par exemple pas nécessairement problématique si le processeur conserve ses fréquences et reste sous ses limites thermiques. À l’inverse, une baisse importante des fréquences lorsque la température augmente peut révéler une limitation thermique ou énergétique.

Il peut notamment être utile après le montage d’un nouveau PC, une modification du refroidissement, un changement de composant ou lorsqu’un ordinateur présente des plantages, des baisses de performances, des températures élevées ou une instabilité sous forte charge.

Pour en savoir plus sur le fonctionnement général des stress tests et les autres outils disponibles :

Pour tout comprendre, lisez :

Comment tester son PC avec StressTest Malekal

Pour utiliser StressTest Malekal, les tests sont exécutés directement sur votre ordinateur avec Malekal Optimisation Center (MOC). Le logiciel sollicite successivement les différents composants du PC, collecte les mesures nécessaires puis génère un rapport qui peut être envoyé vers StressTest Malekal pour être analysé.

Avant de commencer, fermez de préférence les applications gourmandes et enregistrez vos documents ouverts. Pendant le test, le processeur et la carte graphique peuvent être fortement sollicités et les ventilateurs peuvent accélérer : ce comportement est normal.

Pour tester votre PC :

• Téléchargez Malekal Optimisation Center (MOC) depuis ce lien :
• Décompressez l’utilitaire dans un répertoire de votre choix
• Fermez toutes les applications gourmandes suceptibles de fausser le stress test (navigateur internet, etc)
• Faites un clic droit sur Lancer-MOC puis exécuter en tant qu’administrateur
• Choisissez entre les options suivantes :
  • 3 Stress Test Court
  • 4 Stress Test Long

• Laissez le test se dérouler jusqu’à son terme sans utiliser intensivement l’ordinateur.
• MOC exécute successivement les différentes phases de test et collecte notamment la charge, les températures et les fréquences du CPU et du GPU.
• Les tests de performances de la mémoire RAM et du stockage sont également exécutés.
• À la fin du test, MOC génère le rapport contenant les mesures collectées.
• Envoyez le rapport vers AnalysePC lorsque le logiciel vous le propose.
• Une adresse Web est alors générée afin de consulter l’analyse complète de votre PC.

Pendant les tests, il est normal que les températures augmentent et que les ventilateurs tournent plus rapidement. Le but est précisément d’observer comment le refroidissement et les composants réagissent lorsque le PC est fortement sollicité.

StressTest Malekal ne s’intéresse pas uniquement aux valeurs obtenues à la fin du test. Les mesures sont collectées pendant les différentes phases afin d’étudier l’évolution des températures, des fréquences et de la charge. Cela permet notamment de détecter une perte de performances sous charge ou un éventuel thermal throttling.

Si une phase ne peut pas être exécutée ou s’interrompt prématurément, les autres tests peuvent continuer lorsque cela est possible. Le rapport indique alors quelles analyses ont été terminées, partielles, échouées ou ignorées, afin de ne pas présenter un résultat incomplet comme un test réussi.

Une fois le rapport envoyé, vous pouvez consulter les scores, températures, graphiques et problèmes détectés. Les sections suivantes expliquent comment lire ces résultats et déterminer si votre PC présente un comportement normal.

Comprendre le résumé du test

Une fois le rapport envoyé, StressTest Malekal affiche un résumé général du comportement de votre PC pendant les tests. Cette première vue permet de repérer rapidement les composants qui fonctionnent normalement et ceux qui nécessitent une analyse plus approfondie.

La navigation dans le rapport et le site est extrêmement simple. Vous pouvez asser d’une section du rapport à une autre grâce au menu de droite.

Le résumé regroupe les principaux résultats obtenus pendant les différentes phases : CPU, GPU, mémoire, stockage, températures et stabilité. Il indique également si certains tests n’ont pas pu être exécutés complètement.

L’objectif n’est pas seulement de fournir une note globale. StressTest Malekal croise plusieurs mesures afin de déterminer si les performances obtenues sont cohérentes avec les températures et le comportement du matériel sous charge.

Vous pouvez notamment retrouver :

• L’état général du test et les éventuelles anomalies détectées.
• Les résultats concernant le processeur et la carte graphique.
• Les températures relevées pendant les phases de charge.
• Les performances de la mémoire RAM et du stockage.
• Les éventuels signes de thermal throttling ou de limitation des performances.
• Les erreurs matérielles WHEA détectées pendant la période du test.
• Les tests qui ont été terminés, partiels, échoués ou ignorés.

Tout ceci se retrouve dans le début du rapport dans la partie Benchmars et comparaisons où vous trouverez un score de CPU, GPU, Mémoire pour évaluer les performances de votre PC.

Ne pas se fier uniquement aux scores

Un score élevé ne signifie pas nécessairement que le PC est parfaitement stable.

Par exemple, un processeur peut obtenir de bonnes performances tout en atteignant une température excessive, ou commencer à réduire ses fréquences lorsque la charge se prolonge. De même, un PC peut terminer le stress test sans planter mais générer des erreurs WHEA, ce qui peut révéler une instabilité matérielle.

À l’inverse, une température relativement élevée n’est pas forcément anormale si le composant reste dans ses limites de fonctionnement et maintient correctement ses fréquences et ses performances.

Toutefois, Stress test Malekal fournit une analyse de la santé matérielle observée durant la monté à charge de votre PC.
Le résumé doit donc être considéré comme un premier niveau de diagnostic. Lorsqu’une anomalie est signalée, consultez les analyses détaillées et les graphiques correspondants afin de comprendre ce qui s’est produit pendant la charge.

Les sections suivantes permettent notamment d’examiner plus précisément les températures et le refroidissement, le comportement du CPU et du GPU, les performances de la mémoire et du stockage ainsi que les éventuelles erreurs de stabilité.

Analyser les températures et le refroidissement

Les températures sont l’un des principaux indicateurs suivis par StressTest Malekal. Le rapport permet d’observer comment le CPU et le GPU montent en température pendant les différentes phases de charge, puis comment le système de refroidissement réagit lorsque la sollicitation diminue.

L’intérêt n’est donc pas uniquement de connaître la température maximale atteinte. StressTest met en relation températures, charge, fréquences et évolution dans le temps afin d’évaluer le comportement thermique du PC.

Ne pas regarder uniquement la température maximale

Un processeur ou un GPU moderne peut atteindre ponctuellement une température élevée sans présenter de problème particulier. La valeur maximale doit toujours être replacée dans le contexte du test.

Un comportement normal peut par exemple suivre cette évolution :

Charge ↑ → température ↑ → stabilisation → fréquences maintenues.

Le composant chauffe, mais le refroidissement parvient à atteindre un équilibre et les performances restent stables.

À l’inverse, une température qui atteint rapidement une valeur très élevée accompagnée d’une baisse des fréquences peut indiquer que le composant commence à limiter ses performances pour réduire la chaleur produite.

C’est pourquoi StressTest Malekal analyse les températures conjointement avec les autres mesures plutôt que de considérer qu’une valeur élevée signifie automatiquement une surchauffe.

Vérifier l’efficacité du refroidissement

Les graphiques permettent également d’observer si le système de refroidissement parvient à stabiliser les températures pendant une charge prolongée.

Une température qui augmente puis forme progressivement un plateau indique généralement que la chaleur produite et celle évacuée par le refroidissement atteignent un équilibre.

La phase de récupération est tout aussi intéressante. Lorsque la charge CPU ou GPU s’arrête, la température doit progressivement redescendre. Cela permet d’évaluer la capacité du ventirad, du watercooling ou du système de refroidissement d’un ordinateur portable à évacuer la chaleur accumulée pendant le test.

Si les températures restent excessivement élevées, augmentent continuellement ou redescendent difficilement après la charge, vérifiez notamment l’encrassement des radiateurs, la circulation de l’air, le montage du système de refroidissement et la pâte thermique.

Observer la ventilation

Lorsque les capteurs correspondants sont disponibles, le rapport peut également fournir des informations sur la vitesse des ventilateurs. Ces données apportent un contexte supplémentaire à l’évolution des températures.

Pendant une forte charge, il est normal que la ventilation augmente progressivement afin d’évacuer davantage de chaleur. À la fin de la charge, les ventilateurs doivent généralement ralentir à mesure que les températures diminuent.

L’absence d’une valeur de ventilation ne signifie toutefois pas qu’un ventilateur ne fonctionne pas : toutes les cartes mères, cartes graphiques et tous les PC portables n’exposent pas leurs capteurs de ventilation de la même manière à Windows.

L’analyse thermique de StressTest Malekal permet ainsi d’observer l’ensemble du comportement du refroidissement : montée en température, stabilisation sous charge, réaction de la ventilation et récupération après l’effort. Ces informations pourront ensuite être croisées avec les fréquences du CPU et du GPU pour déterminer si la chaleur entraîne réellement une perte de performances.

Analyser la charge et le comportement du processeur

La partie CPU de StressTest Malekal permet d’observer comment le processeur réagit lorsqu’il est sollicité. Le rapport ne se limite pas à la température ou à un score de performances : il analyse également la charge CPU, l’utilisation des différents cœurs logiques et l’évolution des fréquences pendant le test.

Ces informations permettent notamment de vérifier si le processeur est correctement sollicité et s’il parvient à maintenir ses performances lorsque la charge se prolonge.

Vérifier la charge CPU et l’utilisation des cœurs

Pendant une phase destinée à solliciter fortement le processeur, son utilisation doit augmenter de manière cohérente avec le scénario exécuté.

StressTest Malekal permet d’observer cette charge dans le temps afin de repérer, par exemple, une sollicitation qui s’interrompt brutalement ou un processeur qui n’atteint pas le niveau de charge attendu.

Il faut toutefois tenir compte du type de test exécuté. Tous les scénarios n’ont pas pour objectif d’utiliser 100 % du processeur : certains peuvent solliciter seulement une partie des ressources afin d’étudier le comportement du PC dans différentes conditions.

Il est donc préférable d’interpréter la charge en fonction de la phase ou du scénario en cours, plutôt que de considérer qu’un CPU qui n’est pas constamment à 100 % présente forcément un problème.

Processeur d’ordinateur : fonctionnement, caractéristiques et technologies essentielles

Comparer le comportement des cœurs logiques

Le rapport permet également d’examiner l’utilisation des différents cœurs logiques du processeur.

Cette vue est intéressante car une utilisation CPU globale peut masquer une répartition très différente de la charge entre les cœurs. Selon le scénario, certains peuvent être fortement sollicités tandis que d’autres restent beaucoup moins utilisés.

Cela permet notamment de distinguer :

• Une charge répartie sur l’ensemble des cœurs logiques.
• Une charge principalement concentrée sur quelques cœurs.
• Un scénario volontairement mono-cœur ou faiblement parallélisé.
• Une répartition inhabituelle de la charge qui mérite d’être rapprochée du scénario exécuté.

Une différence d’utilisation entre les cœurs n’est donc pas automatiquement anormale. Elle peut simplement refléter la manière dont le test ou l’application répartit son travail entre les threads.

Vérifier si les fréquences restent stables

StressTest Malekal suit également l’évolution des fréquences du processeur pendant les différentes phases.

Au début d’une forte charge, le CPU peut augmenter rapidement sa fréquence grâce à ses mécanismes de boost. Lorsque la température et la consommation augmentent, la fréquence peut ensuite se stabiliser à une valeur plus basse.

Un comportement de ce type est généralement normal :

Charge élevée → boost initial → température en hausse → fréquence qui se stabilise.

Il ne faut donc pas comparer en permanence la fréquence observée avec la fréquence maximale annoncée par le constructeur. Celle-ci correspond souvent à des conditions particulières et n’est pas nécessairement maintenue sur tous les cœurs pendant une charge prolongée.

Repérer une baisse anormale des fréquences et des performances

Les processeurs modernes ajustent continuellement leurs fréquences selon plusieurs paramètres :

• La charge appliquée.
• Le nombre de cœurs sollicités.
• La température.
• La consommation électrique.
• Les limites de puissance.
• Le profil énergétique et les paramètres du BIOS/UEFI.

L’analyse dans le temps permet enfin de détecter un processeur qui fournit de bonnes performances au début du test mais ne parvient pas à les maintenir lorsque la sollicitation se prolonge.

Par exemple :

Charge CPU élevée → température qui augmente → fréquence stable
indique généralement un comportement satisfaisant.

À l’inverse :

Charge CPU élevée → température proche de la limite → fréquence qui chute progressivement
peut révéler une limitation thermique.

StressTest Malekal permet ainsi de croiser charge globale, utilisation des cœurs logiques, fréquences et températures pour comprendre le comportement réel du processeur, plutôt que de tirer une conclusion à partir d’une seule valeur.

Analyser le comportement de la carte graphique

La partie GPU de StressTest Malekal permet d’observer comment la carte graphique réagit pendant les phases qui la sollicitent. Le rapport met en relation la charge GPU, les fréquences, les températures et les performances afin de vérifier si la carte graphique reste stable et maintient correctement son niveau de performances.

Cette analyse est particulièrement utile pour détecter un GPU qui fonctionne normalement au repos mais présente une anomalie lorsqu’il est fortement sollicité, par exemple pendant un jeu ou une application 3D.

Vérifier la charge et les fréquences du GPU

Pendant une phase de stress graphique, l’utilisation du GPU doit augmenter conformément au scénario exécuté.

StressTest Malekal permet de suivre cette charge dans le temps et de la comparer à l’évolution des fréquences et de la température.

Un comportement normal peut par exemple prendre cette forme :

Charge GPU élevée → température qui augmente → température qui se stabilise → fréquence relativement stable.

Comme pour le processeur, il ne faut toutefois pas attendre une fréquence parfaitement constante. Les cartes graphiques modernes ajustent continuellement leur fréquence selon la charge, la température, la consommation et les limites de puissance.

Vérifier si le GPU maintient ses performances

L’un des points importants est de déterminer si la carte graphique conserve ses performances lorsque la charge se prolonge.

Un GPU peut atteindre une fréquence élevée au début du test puis se stabiliser légèrement plus bas lorsque sa température augmente. Ce comportement est généralement normal.

En revanche, une diminution importante et progressive de la fréquence alors que la charge reste élevée mérite davantage d’attention, particulièrement si elle accompagne une température proche de la limite du GPU.

Les graphiques permettent alors de distinguer plus facilement une variation normale des mécanismes de boost d’une véritable limitation thermique ou énergétique.

Rechercher une instabilité de la carte graphique

Une instabilité du GPU peut également se manifester pendant le stress test par une interruption de la charge ou un comportement inhabituel des mesures.

Selon le problème rencontré, vous pouvez notamment observer :

• Une chute brutale de la charge GPU pendant la phase de test.
• Une baisse anormale des fréquences.
• Une température excessive.
• Une interruption ou un échec du test GPU.
• Une réinitialisation du pilote graphique.
• Un écran noir ou une perte temporaire de l’affichage.
• Des artefacts graphiques.
• Des erreurs matérielles remontées par Windows.

Ces symptômes ne signifient pas nécessairement que la carte graphique elle-même est défectueuse. Ils peuvent également provenir du pilote graphique, de l’alimentation, du refroidissement, de la mémoire vidéo ou d’un problème de stabilité du système.

L’intérêt de StressTest Malekal est donc de replacer ces anomalies dans le contexte du test : à quel moment elles apparaissent, quelle était la charge du GPU, quelle température avait été atteinte et comment les fréquences évoluaient à cet instant.

Le guide complet :

Comprendre les scénarios de charge

StressTest Malekal ne sollicite pas uniquement le CPU ou le GPU à leur maximum. Le rapport distingue plusieurs scénarios de charge afin d’observer comment le PC réagit dans différentes conditions d’utilisation.

Cette approche est importante, car un ordinateur peut se comporter correctement lorsqu’un seul composant est sollicité et montrer ses limites lorsque plusieurs ressources sont utilisées simultanément.

Comparer le comportement selon la charge

Les scénarios permettent notamment d’observer les variations de charge, températures, fréquences et consommation selon les différentes phases du test.

Ils permettent de répondre à plusieurs questions :

• Le processeur conserve-t-il ses fréquences lorsqu’il est fortement sollicité ?
• Le GPU reste-t-il stable pendant une charge graphique prolongée ?
• Les températures restent-elles maîtrisées lorsque plusieurs composants produisent de la chaleur ?
• Les performances diminuent-elles lorsqu’une charge devient plus importante ?
• Le refroidissement parvient-il à évacuer correctement la chaleur produite ?

Le rapport permet ainsi de comparer le comportement du matériel d’un scénario à l’autre plutôt que de se baser sur une seule mesure.

Pourquoi tester CPU et GPU simultanément ?

Une charge combinée CPU + GPU est particulièrement intéressante.

Lorsqu’ils fonctionnent simultanément, les deux composants augmentent la consommation électrique et la quantité de chaleur produite. Le système de refroidissement et l’alimentation sont alors davantage sollicités qu’avec un test CPU ou GPU effectué séparément.

Cette situation peut révéler un problème qui n’apparaît pas lors des tests individuels : températures plus élevées, fréquences qui diminuent, instabilité ou limitation de puissance.

C’est particulièrement pertinent sur un ordinateur portable, où le CPU et le GPU partagent souvent une partie des capacités de refroidissement et de l’enveloppe énergétique disponible. Une forte sollicitation du GPU peut alors modifier les performances que le processeur est capable de maintenir, et inversement.

Les différences entre scénarios ne sont pas forcément anormales

Il est normal que les fréquences, températures et performances varient selon le scénario exécuté.

Par exemple, un processeur peut maintenir une fréquence plus élevée lorsqu’il est sollicité seul que lorsque CPU et GPU travaillent simultanément. Cela ne signifie pas automatiquement qu’il existe un problème : le PC doit répartir ses ressources thermiques et énergétiques différemment.

L’intérêt de StressTest Malekal est justement de comparer ces situations et de rechercher un comportement réellement anormal : chute importante des performances, température excessive, throttling, interruption d’une phase ou apparition d’erreurs matérielles.

Les scénarios de charge permettent ainsi de vérifier non seulement la stabilité de chaque composant séparément, mais aussi le comportement du PC dans son ensemble lorsqu’il doit gérer plusieurs contraintes simultanément.

Vérifier l’alimentation, les tensions et la ventilation

StressTest Malekal peut également exploiter les capteurs matériels disponibles pour compléter l’analyse du comportement du PC. Selon la carte mère et les composants détectés, le rapport peut fournir des informations sur les tensions, la puissance électrique et la vitesse des ventilateurs.

Ces données sont particulièrement intéressantes pendant les scénarios de forte charge, notamment lorsque CPU et GPU sont sollicités simultanément.

Surveiller les tensions et la puissance

Lorsque les capteurs correspondants sont disponibles, StressTest Malekal permet d’observer l’évolution de certaines tensions et valeurs de puissance pendant le test.

L’objectif est surtout de rechercher des variations qui coïncident avec une anomalie : chute de fréquence, interruption du test, instabilité ou comportement inhabituel sous forte charge.

Les valeurs doivent toutefois être interprétées avec prudence. Les tensions remontées par logiciel proviennent des capteurs de la carte mère ou des composants et leur précision varie selon le matériel.

StressTest Malekal ne peut donc pas certifier à lui seul qu’une alimentation ATX est défectueuse ou parfaitement fonctionnelle. Un diagnostic précis de l’alimentation peut nécessiter des mesures ou des tests matériels spécifiques.

Observer le comportement des ventilateurs

Lorsque leur vitesse est accessible, le rapport permet également de suivre les ventilateurs du CPU, du GPU ou du boîtier.

Pendant une forte charge, un comportement attendu est généralement :

Température ↑ → ventilation ↑ → température qui se stabilise.

Puis, lors de la récupération :

Charge ↓ → température ↓ → ventilation ↓.

Ces informations permettent de vérifier si la ventilation réagit correctement à l’augmentation de la température.

Une température qui augmente fortement alors que la vitesse d’un ventilateur reste anormalement faible peut mériter une vérification. À l’inverse, des ventilateurs fonctionnant constamment à vitesse élevée peuvent simplement refléter une courbe de ventilation agressive définie dans le BIOS/UEFI ou le logiciel du constructeur.

Tous les capteurs ne sont pas toujours disponibles

L’absence d’une tension, d’une puissance ou d’une vitesse de ventilateur dans le rapport ne signifie pas que le composant ne fonctionne pas.

Les informations accessibles dépendent fortement :

• De la carte mère.
• Du processeur et de la carte graphique.
• Des contrôleurs de capteurs utilisés.
• Du BIOS/UEFI.
• Des informations que le matériel expose à Windows.

Il est donc normal qu’un rapport StressTest contienne davantage de données de capteurs sur certaines configurations que sur d’autres.

Ces mesures doivent surtout être croisées avec les scénarios de charge, les températures et les fréquences. Elles apportent un contexte supplémentaire pour comprendre pourquoi un PC chauffe, réduit ses performances ou devient instable lorsqu’il est fortement sollicité.

Comprendre les phases et graphiques du test

Les graphiques de StressTest Malekal permettent de suivre l’évolution du matériel pendant toute la durée du test. Leur principal intérêt est de replacer chaque mesure dans son contexte : une température, une fréquence ou une charge n’a pas la même signification selon la phase en cours.

Selon la configuration du PC et les tests disponibles, le rapport peut distinguer plusieurs phases :

• Repos / référence : comportement du PC avant la sollicitation.
• Charge CPU : sollicitation du processeur.
• Charge GPU : sollicitation de la carte graphique.
• Mémoire : test des performances de la RAM.
• Stockage : test des performances du SSD ou du disque.
• Récupération : retour à un fonctionnement normal après la charge.

Lire plusieurs courbes au même moment

Pour interpréter correctement un graphique, il faut surtout comparer les mesures au même instant.

Lors d’une phase CPU, par exemple, observez simultanément la charge, la température et la fréquence du processeur. Pour le GPU, appliquez la même méthode avec sa charge, sa température et ses fréquences.

Cette lecture permet notamment de repérer :

• Une fréquence qui chute alors que la charge reste élevée.
• Une température qui atteint sa limite pendant une phase précise.
• Une chute brutale de la charge CPU ou GPU.
• Une anomalie qui apparaît uniquement lors d’un scénario particulier.
• Le moment exact où les performances commencent à diminuer.

Les graphiques permettent donc de répondre à une question essentielle : que faisait le PC au moment où l’anomalie est apparue ?

Replacer les valeurs dans leur contexte

Une température maximale de 90 °C ou une baisse ponctuelle de fréquence, prise isolément, apporte peu d’informations. Le graphique permet de savoir à quel moment cette valeur a été atteinte, sous quelle charge et pendant quel scénario.

C’est cette corrélation entre les différentes courbes et les phases du test qui permet à StressTest Malekal de distinguer plus facilement un comportement normal d’une anomalie apparaissant sous charge.

Les explications détaillées sur les températures, le refroidissement, les fréquences CPU/GPU et le thermal throttling sont présentées dans les sections dédiées de ce guide..

Détecter le thermal throttling et les pertes de performances

Le thermal throttling est un mécanisme de protection qui réduit automatiquement les performances d’un processeur ou d’une carte graphique lorsque sa température devient trop élevée. Le composant diminue alors notamment ses fréquences et sa consommation afin de produire moins de chaleur et de rester dans ses limites de fonctionnement.

StressTest Malekal cherche à détecter ce phénomène en analysant simultanément la charge, les températures et l’évolution des fréquences du CPU et du GPU pendant les différentes phases du test.

Un comportement caractéristique peut être :

Charge élevée → température proche de la limite → baisse des fréquences → performances réduites.

Le PC peut donc terminer le test sans planter tout en présentant une perte de performances sous charge.

Température élevée ne signifie pas forcément throttling

Il est important de distinguer une température élevée d’un véritable thermal throttling.

Un processeur peut fonctionner à une température importante tout en maintenant correctement ses fréquences. Dans ce cas, le refroidissement est fortement sollicité, mais cela ne signifie pas nécessairement que les performances sont réduites.

À l’inverse, si les graphiques montrent que la fréquence diminue lorsque la température atteint sa limite alors que la charge reste élevée, une limitation thermique devient beaucoup plus probable.

StressTest Malekal permet justement de croiser ces différentes mesures plutôt que de considérer uniquement la température maximale.

Toutes les baisses de fréquence ne sont pas thermiques

Une diminution des fréquences pendant le test peut également provenir d’autres limitations :

• Limite de puissance ou de consommation du CPU ou du GPU.
• Profil d’alimentation de Windows.
• Paramètres du BIOS/UEFI.
• Limites définies par le constructeur, notamment sur les ordinateurs portables.
• Fonctionnement normal des mécanismes de boost.
• Partage des limites thermiques et énergétiques entre CPU et GPU sur certains portables.

Il faut donc examiner le moment où la baisse intervient et les autres mesures enregistrées au même instant avant de conclure à une surchauffe.

Que faire en cas de limitation thermique ?

Si StressTest Malekal détecte une perte de performances associée à des températures excessives, vérifiez en priorité le système de refroidissement : poussière, ventilation du boîtier, fonctionnement des ventilateurs, radiateur, pâte thermique ou montage du ventirad/watercooling.

Sur un ordinateur portable, vérifiez également que les entrées et sorties d’air ne sont pas obstruées et effectuez les tests sur une surface dure et plane.

Après correction, vous pouvez relancer le test et comparer les résultats. Une température plus basse associée à des fréquences mieux maintenues indique que l’amélioration du refroidissement a effectivement réduit la limitation des performances.

Vérifier les performances de la mémoire RAM

StressTest Malekal intègre également un benchmark de la mémoire RAM afin de mesurer ses performances et de détecter des résultats anormalement faibles.

Contrairement aux phases CPU et GPU, ce test n’a pas pour objectif principal de faire monter la température du matériel. Il permet surtout d’évaluer la vitesse à laquelle le processeur et la mémoire peuvent transférer les données.

Le rapport présente notamment les débits mémoire obtenus pendant le benchmark et permet de vérifier si les performances sont cohérentes avec la configuration du PC.

Pourquoi les performances de la RAM peuvent-elles être faibles ?

Des performances mémoire inférieures à celles attendues peuvent avoir plusieurs causes :

• RAM fonctionnant à une fréquence inférieure à celle prévue.
• Profil XMP ou EXPO non activé dans le BIOS/UEFI.
• Barrettes installées dans une configuration ne permettant pas le Dual Channel.
• Mélange de barrettes ayant des caractéristiques différentes.
• Paramètres mémoire ou BIOS/UEFI incorrects.
• Limitation liée au processeur ou au contrôleur mémoire.
• Activité importante d’autres applications pendant le benchmark.

Il faut toutefois éviter de comparer directement deux PC uniquement à partir du débit mémoire. Les résultats dépendent notamment du processeur, du contrôleur mémoire, du type de RAM, de sa fréquence, de ses timings et du nombre de canaux utilisés.

Un benchmark mémoire ne teste pas la fiabilité de la RAM

De bonnes performances mémoire ne signifient pas nécessairement que la RAM est parfaitement stable.

Le benchmark de StressTest Malekal mesure principalement les performances de la mémoire. Pour rechercher des cellules mémoire défectueuses ou une instabilité de la RAM, il faut utiliser un outil spécialisé tel que MemTest86+.

Ainsi, si votre PC présente des plantages aléatoires, des écrans bleus, des erreurs mémoire ou des corruptions de données, complétez le diagnostic par un véritable test de la RAM.

Le test mémoire intégré vérifie l’intégrité de données écrites et relues pendant que Windows fonctionne, tandis que la surveillance WHEA recherche les erreurs matérielles signalées par la plateforme. Il ne remplace pas MemTest86+, plus approfondi pour tester la RAM elle-même, mais peut révéler des instabilités qui n’apparaissent que lorsque le processeur, le contrôleur mémoire, le GPU, l’alimentation et le refroidissement sont simultanément sollicités.

Le guide complet :

Vérifier les performances du SSD ou du disque

StressTest Malekal teste également le périphérique de stockage afin de mesurer ses performances et de détecter des résultats anormalement faibles.

Le rapport permet notamment de vérifier les débits en lecture et en écriture et de déterminer si le SSD ou le disque présente des performances cohérentes avec son type : disque dur, SSD SATA ou SSD NVMe.

Des performances faibles peuvent avoir différentes causes : SSD presque plein, activité importante en arrière-plan, limitation de l’interface SATA/PCIe, température élevée ou simplement caractéristiques du modèle utilisé.

Attention toutefois : ce benchmark mesure principalement les performances du stockage et non son état de santé. Pour rechercher une usure, des erreurs ou une défaillance du SSD/disque, consultez les données SMART.

Les guides pour aller plus loin :

Détecter les erreurs matérielles WHEA

StressTest Malekal recherche également les erreurs WHEA (Windows Hardware Error Architecture) enregistrées par Windows pendant les tests. Elles peuvent signaler une anomalie concernant notamment le processeur, la mémoire RAM, le bus PCIe, la carte graphique ou le stockage.

Cette vérification est importante car un PC peut terminer le stress test sans planter tout en générant des erreurs matérielles. StressTest Malekal les prend donc en compte dans l’évaluation de la stabilité et les met en relation avec les différentes phases de charge.

Une erreur WHEA isolée ne permet pas forcément d’identifier immédiatement le composant responsable. En revanche, des erreurs répétées ou apparaissant pendant une phase précise du test méritent un diagnostic plus approfondi.

Erreurs WHEA sous Windows : causes, diagnostic et solutions : lien vers le guide dédié.

Comprendre les scores et les recommandations

À la fin des tests, StressTest Malekal synthétise les différentes mesures sous forme de scores et d’analyses afin de faciliter l’interprétation du rapport. L’objectif est de repérer rapidement les composants qui se comportent normalement et ceux qui nécessitent une vérification plus approfondie.

Les scores peuvent notamment tenir compte des performances obtenues, des températures, du comportement sous charge et des éventuelles anomalies détectées pendant le test.

Il est important de ne pas considérer uniquement la note finale. Un PC peut obtenir de bonnes performances tout en présentant, par exemple, une température excessive, une baisse de fréquence sous charge ou des erreurs WHEA.

StressTest Malekal accompagne donc les résultats de recommandations et d’explications lorsque certaines valeurs paraissent anormales. Elles peuvent orienter vers une vérification du refroidissement, des performances du stockage, de la mémoire ou vers un diagnostic matériel plus approfondi.

Les scores doivent ainsi être utilisés comme un résumé du test, tandis que les graphiques et analyses détaillées permettent de comprendre pourquoi un composant obtient un résultat plus faible ou pourquoi une anomalie a été signalée.

Partager son rapport StressTest Malekal

StressTest Malekal, OCCT ou UserDiag : lequel utiliser ?

StressTest Malekal, OCCT et UserDiag permettent tous de solliciter le matériel d’un PC, mais ils ne répondent pas exactement au même besoin.

StressTest Malekal met surtout l’accent sur l’analyse automatique du comportement du PC. Les mesures collectées pendant les différentes phases sont utilisées pour examiner les températures, les fréquences, le refroidissement, les performances et la stabilité, puis présenter les résultats dans un rapport plus facile à interpréter.

OCCT est davantage adapté aux utilisateurs qui souhaitent configurer précisément leurs stress tests et solliciter individuellement le CPU, le GPU, la mémoire ou l’alimentation. Il offre davantage de contrôle sur les tests, mais demande aussi de savoir interpréter les résultats obtenus.

UserDiag est plutôt orienté vers le diagnostic matériel général du PC. Il permet de récupérer la configuration de l’ordinateur et d’effectuer différents tests afin de rechercher un problème matériel.

Outil	À privilégier pour
StressTest Malekal	Tester le PC et obtenir une analyse automatique des températures, performances et du comportement sous charge
OCCT	Effectuer des stress tests avancés et configurables sur des composants précis
UserDiag	Réaliser un diagnostic matériel général et obtenir les caractéristiques du PC

Ces outils sont donc davantage complémentaires que concurrents. Si vous souhaitez simplement vérifier comment votre PC se comporte sous charge sans avoir à interpréter manuellement toutes les mesures, StressTest Malekal est particulièrement adapté. Pour effectuer des tests plus poussés ou reproduire une charge précise, OCCT offre davantage de possibilités.

Les guides complets :

Aller plus loin avec une analyse complète de Windows

StressTest Malekal se concentre principalement sur le comportement du matériel lorsqu’il est sollicité : températures, fréquences CPU/GPU, performances, refroidissement, throttling, stabilité et éventuelles erreurs matérielles.

Pour rechercher plutôt les problèmes liés à Windows et à sa configuration, vous pouvez compléter ce diagnostic avec AnalysePC. Le service examine de nombreux éléments du système afin de détecter les anomalies pouvant provoquer des lenteurs, des erreurs ou un mauvais fonctionnement du PC.

AnalysePC permet notamment de vérifier :

• Le démarrage de Windows et les programmes qui se lancent automatiquement.
• Les processus et services Windows.
• Les pilotes et périphériques.
• Les erreurs système et événements importants.
• Windows Update et les échecs de mise à jour.
• La configuration matérielle et les disques.
• Les paramètres pouvant affecter les performances de Windows.
• Les problèmes détectés et les actions recommandées.

Les deux services sont donc complémentaires : StressTest Malekal vérifie surtout comment le matériel se comporte sous charge, tandis qu’AnalysePC recherche les problèmes présents dans Windows et sa configuration.

Pour le découvrir et apprendre à l’utiliser, suivez ce lien :

Enfin les conseils au quotidien :

L’article StressTest Malekal : vérifier la santé et le comportement de son PC est apparu en premier sur malekal.com.