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.
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.
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.
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 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.
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.
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
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 :
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 :
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.
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.
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.
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.
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.
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.
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 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 :
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.
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.
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.
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.
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.
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.
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.
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 :
Microsoft déploie son Patch Tuesday d’août 2026 avec une importante série de mises à jour de sécurité pour Windows et ses différents produits.
Au total, Microsoft corrige environ 400 vulnérabilités, dont 42 classées critiques et 3 failles zero-day. L’une d’elles était déjà activement exploitée dans des attaques avant la publication des correctifs.
Sous Windows 11 24H2 et 25H2, la mise à jour KB5121003 apporte également de nombreuses améliorations fonctionnelles : lancement plus rapide de certaines applications, recherche Windows plus tolérante aux fautes de frappe, améliorations de l’Explorateur de fichiers, nouveau comportement du pavé tactile et évolutions de Voice Access.
Windows 10 reçoit de son côté la mise à jour KB5120249, essentiellement consacrée à la sécurité, à l’Historique des fichiers et au déploiement des nouveaux certificats Secure Boot.
Windows 11 KB5121003 : les builds 26100.9165 et 26200.9165
Pour Windows 11 24H2 et 25H2, Microsoft distribue la mise à jour cumulative obligatoire KB5121003.
Après installation :
Windows 11 25H2 passe en Build 26200.9165 ;
Windows 11 24H2 passe en Build 26100.9165.
La mise à jour est automatiquement proposée par Windows Update, puisqu’elle contient les correctifs de sécurité du Patch Tuesday.
Microsoft propose également les installateurs autonomes .msu dans le Catalogue Microsoft Update.
Les applications peuvent démarrer plus rapidement
L’une des nouveautés les plus intéressantes concerne le Profil à faible latence (Low Latency Profile).
Cette technologie avait commencé à être déployée sur certains composants de Windows, notamment le menu Démarrer, le Centre de notifications, les Paramètres rapides et les menus contextuels.
Son objectif est d’améliorer la réactivité en demandant au processeur d’augmenter rapidement sa fréquence lorsqu’une action nécessitant davantage de ressources est détectée.
Avec KB5121003, Microsoft étend progressivement ce mécanisme aux applications.
Sur les configurations les moins puissantes, notamment celles équipées de processeurs modestes ou de seulement 8 Go de RAM, certaines applications peuvent ainsi démarrer plus rapidement.
Il ne s’agit pas d’une augmentation permanente de la fréquence du processeur : le boost ne dure que quelques secondes afin d’améliorer la réactivité au moment où elle est nécessaire.
Le déploiement reste progressif. Tous les utilisateurs ne verront donc pas immédiatement cette amélioration après l’installation du Patch Tuesday.
Windows Search gère enfin mieux les fautes de frappe
Microsoft améliore également sensiblement Windows Search.
Jusqu’ici, une simple faute dans le nom d’une application pouvait suffire à empêcher la recherche locale de trouver le bon résultat, tandis que Bing comprenait souvent mieux la requête.
KB5121003 améliore la tolérance aux :
fautes de frappe ;
lettres manquantes ;
caractères supplémentaires ;
noms d’applications incomplets.
Par exemple, Windows Search peut désormais retrouver Outlook même si l’utilisateur saisit une variante mal orthographiée du nom de l’application.
Les recherches de paramètres Windows sont également mieux classées afin d’éviter que des résultats Bing prennent inutilement le dessus sur un réglage local recherché par l’utilisateur.
L’Explorateur de fichiers affiche enfin les bonnes unités
L’Explorateur de fichiers reçoit lui aussi plusieurs changements.
Dans l’affichage Détails, Windows affichait jusqu’à présent toutes les tailles en kilo-octets, même pour des fichiers de plusieurs gigaoctets.
Ainsi, une image ISO de plusieurs Go pouvait apparaître sous la forme de plusieurs millions de Ko.
Avec KB5121003, l’Explorateur choisit désormais automatiquement une unité plus adaptée :
Ko pour les petits fichiers ;
Mo pour les fichiers intermédiaires ;
Go pour les fichiers volumineux.
Cette modification améliore nettement la lisibilité de la colonne Taille.
Comme plusieurs autres nouveautés de cette mise à jour, son déploiement est progressif.
Navigation et onglets améliorés dans l’Explorateur
Microsoft améliore également la barre d’adresse de l’Explorateur de fichiers, qui devrait réagir plus rapidement lorsqu’on navigue entre plusieurs chemins précédemment utilisés.
Autre changement pratique : un clic avec le bouton central de la souris sur un dossier permet désormais de l’ouvrir directement dans un nouvel onglet, comme dans un navigateur Web.
Microsoft corrige aussi :
un flash gris pouvant apparaître lors du chargement de l’Explorateur ;
des miniatures de mauvaise qualité dans la section Recommandé ;
plusieurs problèmes de fiabilité d’explorer.exe.
Prise en charge ESS dans Windows Hello
Dans cette mise à jour, Microsoft ajoute la prise en charge de la fonctionnalité « Sécurité de connexion améliorée » (ESS) de Windows Hello pour les capteurs d’empreintes digitales externes.
En bref, la fonctionnalité Windows Hello standard crypte les données de connexion. Cependant, la prise en charge de la sécurité améliorée va plus loin en isolant le processus biométrique dans un espace mémoire sécurisé, distinct du système d’exploitation.
Cette option est accessible via Paramètres > Comptes > Options de connexion.
Vue des tâches, bureaux virtuels et listes de raccourcis plus fluides
Des améliorations sont également apportées à plusieurs éléments de l’interface.
La gestion des fichiers récents et des listes de raccourcis devient plus fiable lorsque vous effectuez un clic droit sur une application dans la barre des tâches.
La Vue des tâches et la navigation entre plusieurs bureaux virtuels devraient également être plus fluides, avec moins de ralentissements et de saccades.
Microsoft améliore parallèlement la fiabilité du menu Démarrer et de la barre des tâches pendant le démarrage de Windows.
Accès vocal gagne une isolation de la voix
La fonction Accès vocal bénéficie d’un nouveau mécanisme de filtrage du microphone.
Trois modes sont proposés :
Isolation de la voix, qui réduit le bruit ambiant et tente de ne conserver que la voix de l’utilisateur ;
Suppression du bruit de fond, qui filtre le bruit mais laisse les autres voix audibles ;
Aucun filtre, qui utilise directement le signal du microphone.
Cette évolution doit rendre les commandes vocales plus fiables dans les environnements bruyants ou lorsque plusieurs personnes parlent à proximité.
De nouveaux réglages pour le pavé tactile
Les utilisateurs équipés d’un pavé tactile de précision disposent également de nouveaux paramètres.
Microsoft introduit notamment un défilement accéléré, qui augmente la vitesse lorsqu’un même geste est répété rapidement.
Windows permet désormais également de régler séparément :
la vitesse du défilement ;
la vitesse du zoom.
Ces réglages devraient surtout être utiles aux utilisateurs passant régulièrement d’un portable à un autre et souhaitant retrouver un comportement similaire du pavé tactile.
Windows Hello et écran de verrouillage
Microsoft améliore aussi Windows Hello Enhanced Sign-in Security (ESS) sur les appareils compatibles.
La mise à jour corrige notamment un problème pouvant rendre Windows Hello lent lorsque le système utilisait beaucoup de mémoire.
L’écran de verrouillage reçoit lui aussi plusieurs ajustements de performances.
Pour les nouveaux utilisateurs, Microsoft simplifie par ailleurs les Widgets affichés sur l’écran de verrouillage : seule la météo est désormais activée par défaut.
Des Widgets moins visibles
Les badges de Widgets affichés dans la barre des tâches n’utilisent plus systématiquement une couleur rouge.
Ils reprennent désormais la couleur d’accentuation de Windows, ce qui doit les rendre moins intrusifs visuellement.
Sur l’écran de verrouillage, l’expérience devrait désormais être moins distrayante, car, par défaut, les utilisateurs ne verront plus que le widget Météo.
Microsoft poursuit ainsi la simplification progressive du panneau Widgets entamée au cours des précédentes mises à jour.
Le composant de génération d’images IA devient désinstallable
Sur les Copilot+ PC, Microsoft permet désormais de supprimer le composant Image Generation AI.
Cette évolution s’inscrit dans la stratégie récente de Microsoft visant à rendre certains composants d’intelligence artificielle plus modulaires et à permettre leur suppression lorsqu’ils ne sont pas utilisés.
Plusieurs petites corrections bienvenues
KB5121003 contient également de nombreuses corrections plus discrètes.
Microsoft corrige notamment :
des préférences du menu Démarrer qui pouvaient disparaître après un redémarrage ;
la taille du pointeur de souris qui pouvait être réinitialisée ;
certains paramètres d’alimentation qui n’étaient pas correctement conservés ;
la gestion du seuil d’activation de l’économiseur d’énergie ;
l’impact de certaines recherches Windows Update sur les performances du système..
Microsoft poursuit le remplacement des certificats Secure Boot
La mise à jour Windows 10 améliore également le ciblage des appareils devant recevoir automatiquement les nouveaux certificats Secure Boot.
Microsoft poursuit depuis plusieurs mois le remplacement progressif des anciens certificats Secure Boot arrivant à expiration en 2026.
La société précise que le déploiement continuera au travers de Windows Update sur les appareils compatibles et les PC professionnels non gérés.
Cette opération est progressive : tous les ordinateurs ne reçoivent donc pas les nouveaux certificats au même moment.
400 vulnérabilités corrigées en août 2026
Ce Patch Tuesday reste particulièrement volumineux, même s’il demeure en dessous du record du mois de juillet, où Microsoft avait corrigé 570 vulnérabilités.
Les quelque 400 failles corrigées en août se répartissent approximativement ainsi :
176 vulnérabilités d’élévation de privilèges ;
110 vulnérabilités permettant l’exécution de code à distance ;
86 divulgations d’informations ;
21 vulnérabilités d’usurpation d’identité ;
12 dénis de service ;
11 contournements de fonctions de sécurité.
Microsoft classe par ailleurs 42 vulnérabilités comme critiques, dont 37 permettent potentiellement l’exécution de code à distance et cinq une élévation de privilèges.
Le chiffre de 400 ne comprend pas certaines failles corrigées plus tôt dans le mois dans Azure, Microsoft Teams, Entra, Office, Power Apps ou encore Mariner.
Trois zero-day, dont une exploitée par le groupe Lazarus
Trois vulnérabilités zero-day retiennent particulièrement l’attention ce mois-ci.
L’une était déjà activement exploitée avant la publication du correctif, tandis que les deux autres avaient été rendues publiques.
CVE-2026-68820 : une élévation de privilèges déjà exploitée
La faille la plus préoccupante est CVE-2026-68820, qui affecte le pilote Windows Ancillary Function Driver for WinSock, également connu sous le nom AFD.sys.
Cette vulnérabilité de type « use-after-free » peut permettre à un attaquant déjà authentifié sur la machine d’exécuter une application spécialement conçue afin d’obtenir les privilèges SYSTEM, le niveau de privilège le plus élevé sous Windows. Aucune interaction de l’utilisateur n’est nécessaire.
Selon Check Point, cette zero-day a été exploitée par le groupe nord-coréen Lazarus afin de déployer une nouvelle version de son rootkit en mode noyau FudModule.
Cette vulnérabilité est donc particulièrement importante, car elle permet à un attaquant ayant déjà obtenu un premier accès à un PC de prendre ensuite le contrôle complet du système.
CVE-2026-62832 : Microsoft corrige enfin LegacyHive
Le Patch Tuesday d’août corrige également CVE-2026-62832, une vulnérabilité affectant le Windows User Profile Service.
Les caractéristiques techniques correspondent à la faille LegacyHive, rendue publique en juillet et dont nous avions déjà parlé.
Cette vulnérabilité permet à un utilisateur disposant de droits limités et des identifiants d’un autre compte local de charger la ruche du Registre d’un autre utilisateur.
Un attaquant peut ainsi accéder ou modifier certaines données et, dans certaines conditions, obtenir des privilèges administrateur sans interaction supplémentaire de la victime.
Jusqu’ici, aucun correctif Microsoft officiel n’était disponible et 0patch proposait un micropatch temporaire.
La publication de KB5121003 et des autres mises à jour d’août rend donc cette protection non officielle inutile sur les systèmes correctement mis à jour.
CVE-2026-72971 : une faille dans Windows Container Isolation
La troisième zero-day, CVE-2026-72971, affecte le pilote Windows Container Isolation FS Filter Driver (unionfs.sys).
Cette vulnérabilité avait déjà été rendue publique avant la publication du Patch Tuesday. Elle permet à un attaquant déjà authentifié localement d’exploiter un problème de résolution de liens dans le pilote unionfs.sys afin d’altérer des données.
Elle concerne notamment les mécanismes utilisés par Windows pour isoler certains systèmes de fichiers dans les environnements conteneurisés.
Aucun problème majeur signalé pour le moment
Au moment de la publication, Microsoft et les premières observations rapportées par WindowsLatest ne font état d’aucun problème majeur généralisé lié à KB5121003.
Même constat pour KB5120249 sous Windows 10, pour laquelle aucun nouveau problème connu important n’est signalé à ce stade.
Il faudra néanmoins attendre quelques jours pour disposer d’un recul suffisant sur plusieurs millions de configurations différentes.
Conclusion
Le Patch Tuesday d’août 2026 est à nouveau particulièrement chargé.
Microsoft corrige environ 400 vulnérabilités, dont trois zero-day. La plus importante, CVE-2026-68820, était déjà utilisée par le groupe Lazarus pour obtenir les privilèges SYSTEM et déployer un rootkit en mode noyau.
La mise à jour clôt également le dossier LegacyHive, divulgué en juillet et désormais officiellement corrigé par Microsoft.
Sous Windows 11, KB5121003 ne se limite pas à la sécurité. Elle poursuit l’évolution progressive du système avec un Explorateur de fichiers plus pratique, une recherche locale plus tolérante aux erreurs, des améliorations de performances, un pavé tactile plus configurable et plusieurs optimisations de fiabilité.
Windows 10 entre quant à lui définitivement dans une logique de maintenance : KB5120249 apporte essentiellement des correctifs de sécurité, une correction de l’Historique des fichiers et la poursuite du renouvellement des certificats Secure Boot.
Les fichiers ZIP, RAR et 7z permettent de regrouper et de compresser des données afin de faciliter leur stockage ou leur transfert. Dans la majorité des cas, leur extraction se déroule sans difficulté. Toutefois, il arrive que Windows ou un logiciel de décompression affiche un message d’erreur et refuse d’ouvrir l’archive.
Vous pouvez par exemple rencontrer les erreurs « Windows ne peut pas effectuer l’extraction », « Le dossier compressé est invalide », Erreur CRC, Data Error dans 7-Zip, fichier corrompu dans WinRAR ou encore une erreur 0x80070570. Ces messages peuvent être provoqués par une archive corrompue, un téléchargement incomplet, un logiciel de décompression incompatible ou encore un problème de disque.
Dans ce guide, vous découvrirez les causes les plus fréquentes des erreurs de décompression, les vérifications à effectuer pour identifier leur origine et les solutions adaptées selon le message affiché par Windows, 7-Zip, WinRAR ou un autre logiciel de décompression.
Pourquoi une archive ne s’extrait pas ?
Lorsqu’une archive ZIP, RAR ou 7z refuse de s’extraire, le problème ne provient pas forcément du logiciel de décompression. L’erreur peut être liée à une archive corrompue, à un téléchargement incomplet, à un manque d’espace disque ou encore à un problème de stockage sur votre ordinateur.
Le tableau ci-dessous présente les causes les plus fréquentes.
Cause
Quand se produit-elle ?
Que faire ?
Archive corrompue
L’extraction échoue immédiatement ou affiche une erreur CRC.
Télécharger de nouveau l’archive ou demander une copie valide.
Téléchargement incomplet
La taille du fichier est inférieure à celle annoncée ou le téléchargement a été interrompu.
Retélécharger complètement l’archive.
Logiciel de décompression incompatible
L’Explorateur Windows ne parvient pas à ouvrir l’archive ou ne prend pas en charge son format.
Essayer avec 7-Zip, WinRAR ou PeaZip.
Nom ou chemin de fichier trop long
L’extraction échoue sur certains fichiers uniquement.
Extraire l’archive dans un dossier proche de la racine (par exemple C:\Temp).
Manque d’espace disque
L’extraction s’interrompt en cours de copie.
Libérer de l’espace sur le disque de destination.
Archive protégée par mot de passe
Le logiciel demande un mot de passe ou signale une erreur de déchiffrement.
Vérifier que le mot de passe est correct.
Erreur du disque ou de la clé USB
Plusieurs fichiers sont illisibles ou d’autres erreurs apparaissent (CRC, 0x80070570, erreur d’entrée/sortie).
Vérifier l’état du disque et le système de fichiers.
Antivirus ou logiciel de sécurité
L’extraction se bloque ou certains fichiers sont mis en quarantaine.
Désactiver temporairement l’analyse en temps réel si le fichier provient d’une source fiable.
Conseil : si plusieurs archives téléchargées depuis des sources différentes refusent de s’extraire, le problème provient probablement de votre ordinateur (logiciel de décompression, disque, antivirus ou système de fichiers) plutôt que des archives elles-mêmes.
Vérifier si l’archive est corrompue
L’une des causes les plus fréquentes d’un échec d’extraction est une archive corrompue. Cela peut se produire après un téléchargement interrompu, une copie incomplète ou un problème sur le support de stockage.
L’archive est endommagée ou fichier corrompu dans WinRAR ;
extraction qui s’interrompt toujours sur le même fichier.
Le logiciel 7-Zip permet de vérifier très facilement l’intégrité d’un fichier ZIP : clic droit sur le fichier puis 7-Zip > contrôler archives
Avant de conclure que l’archive est défectueuse, effectuez les vérifications suivantes.
Vérification
Pourquoi ?
Comparer la taille du fichier avec celle indiquée sur le site de téléchargement
Permet de détecter un téléchargement incomplet.
Télécharger de nouveau l’archive
Corrige la plupart des archives corrompues pendant le téléchargement.
Essayer d’ouvrir l’archive avec un autre logiciel (7-Zip, WinRAR, PeaZip)
Vérifie si le problème provient du logiciel utilisé.
Tester l’archive sur un autre ordinateur
Permet de déterminer si le problème vient de l’archive ou de votre PC.
Vérifier le disque de stockage
Une erreur du disque peut corrompre les fichiers téléchargés ou copiés.
Si plusieurs téléchargements du même fichier produisent exactement la même erreur, il est possible que l’archive mise à disposition par son auteur soit elle-même endommagée.
Si l’erreur mentionne un CRC, une erreur d’entrée/sortie (E/S) ou le code 0x80070570, vérifiez également l’état de santé de votre disque dur ou SSD, car le problème peut provenir du support de stockage plutôt que de l’archive elle-même.
L’outil intégré à Windows prend uniquement en charge les archives ZIP et peut parfois rencontrer des difficultés avec certaines archives volumineuses, protégées par mot de passe ou utilisant des méthodes de compression récentes.
Si l’extraction échoue avec l’Explorateur de fichiers, essayez d’ouvrir l’archive avec un autre logiciel. Celui-ci affichera souvent un message d’erreur plus précis, ce qui facilite le diagnostic.
Les archives ZIP, 7z et la détection des erreurs CRC ou Data Error.
WinRAR
Les archives RAR, ZIP et les archives multi-volumes.
PeaZip
La prise en charge de nombreux formats d’archives avec une interface simple.
Si plusieurs logiciels affichent la même erreur, il est très probable que l’archive soit réellement corrompue ou incomplète.
En revanche, si un logiciel parvient à extraire l’archive alors qu’un autre échoue, le problème provient généralement du logiciel de décompression utilisé et non de l’archive elle-même.
Conseil : si l’Explorateur Windows affiche le message « Windows ne peut pas effectuer l’extraction », essayez d’abord 7-Zip. Il est souvent plus tolérant avec certaines archives ZIP et fournit des messages d’erreur beaucoup plus explicites.
Vérifier le disque
Si l’archive est stockée sur un disque dur, un SSD ou une clé USB présentant des erreurs, l’extraction peut échouer même si le fichier est intact. Une erreur de lecture ou d’écriture suffit à rendre certains fichiers de l’archive inaccessibles.
Les symptômes suivants peuvent indiquer un problème de stockage :
Symptôme
Cause possible
Plusieurs archives refusent de s’extraire
Erreur du système de fichiers ou problème du disque.
Erreur CRC, 0x80070570 ou Erreur d’entrée/sortie (E/S)
Secteurs défectueux ou support de stockage défaillant.
L’extraction s’interrompt toujours au même endroit
Conseil : si plusieurs fichiers téléchargés deviennent corrompus ou si les erreurs d’extraction sont accompagnées d’erreurs CRC, 0x80070570 ou d’erreurs d’entrée/sortie, le problème provient souvent du support de stockage plutôt que de l’archive elle-même.
Retélécharger le fichier ZIP ou restaurer le depuis une sauvegarde
Une autre source de l’erreur des dossiers compressés Windows est que le fichier ZIP est partiellement téléchargé. Comme le fichier n’est pas entier, il est donc corrompu. Dans le cas la meilleur solution consiste à télécharger à nouveau le fichier. Si le fichier ZIP provient d’une copie de fichiers (disque dur externe, partage réseau), comparez les tailles de fichiers pour s’assurer que le fichier est entièrement copier. Vous pouvez aussi comparer l’empreinte du fichier pour vous assurer que le téléchargement n’est pas corrompu.
Une fois le fichier ZIP récupéré, tentez de le décompresser pour vérifier si l’erreur « Windows ne peut pas effectuer l’extraction » est corrigée.
Réparer un fichier ZIP corrompu ou endommagé
Enfin, si après avoir suivi toutes ces conseils, vous n’avez pu résoudre l’erreur « Windows ne peut pas effectuer l’extraction« » est corrigée« , il est probable que le fichier ZIP soit endommagé. Vous pouvez tenter de le réparer en suivant ce tutoriel :
Le message affiché par Windows, 7-Zip ou WinRAR permet souvent d’identifier rapidement l’origine du problème. Le tableau ci-dessous vous oriente vers le guide le plus adapté.
Problème de lecture/écriture sur le disque ou la clé USB
Erreur d’entrée/sortie (E/S) : causes et solutions
Conseil : si plusieurs logiciels de décompression affichent le même message d’erreur, le problème provient généralement de l’archive ou du support de stockage, et non du logiciel utilisé.
Le problème de compatibilité entre Windows 11 et certains pilotes Intel était beaucoup plus large que prévu.
Dell a finalement confirmé qu’environ 245 modèles de PC ont été concernés par les dysfonctionnements apparus après les mises à jour Windows 11 de juin et juillet 2026. Les symptômes pouvaient aller d’une forte baisse de performances à une surchauffe, une consommation excessive de batterie et même des arrêts inattendus du système.
La bonne nouvelle est que le problème est désormais corrigé grâce à la mise à jour hors cycle KB5121767, publiée par Microsoft le 18 juillet 2026. Les PC concernés doivent toutefois disposer d’une build suffisamment récente pour être définitivement à l’abri.
Un problème apparu avec les mises à jour de juin 2026
Les premiers symptômes sont apparus après l’installation de la mise à jour facultative KB5095093, publiée le 23 juin 2026.
À l’époque, certains propriétaires de PC Dell et Alienware avaient commencé à signaler des problèmes de performances, une hausse des températures ou un comportement anormal du système.
La situation s’est aggravée avec le Patch Tuesday du 14 juillet et la mise à jour obligatoire KB5101650. Microsoft a alors bloqué temporairement son déploiement sur certains PC Dell après avoir identifié une incompatibilité susceptible de provoquer des problèmes sérieux de performances et de gestion énergétique.
Le pilote Intel Innovation Platform Framework au cœur du problème
L’origine du dysfonctionnement se trouve dans une incompatibilité entre le pilote Intel Innovation Platform Framework (IPF) Processor Participant et une nouvelle interface de Windows appelée Windows USB-C Connection Manager.
Le pilote Intel IPF joue un rôle beaucoup plus important qu’un simple pilote de périphérique.
Selon Dell, il prend notamment en charge Intel Dynamic Tuning Technology (DTT), utilisé pour gérer la consommation électrique, les performances, la température du processeur et le fonctionnement des ventilateurs. Il prend aussi en charge Intel Context Sensing Technology, notamment certaines fonctions de détection de présence.
Lorsqu’une mise à jour Windows perturbe son fonctionnement, les conséquences peuvent donc être importantes : le PC peut mal gérer ses limites de puissance, son refroidissement ou ses fréquences de fonctionnement.
Quels problèmes pouvaient apparaître ?
Microsoft indique que les appareils concernés pouvaient subir des modifications anormales des performances, de la consommation électrique ou du comportement général du système.
Dell et Windows Latest ont rapporté plusieurs symptômes possibles :
fortes baisses de performances ;
augmentation anormale de la température ;
consommation excessive de la batterie ;
fonctionnement incorrect de la gestion énergétique ;
arrêts inattendus du PC.
Dans certains cas, le système pouvait ainsi devenir difficilement utilisable, notamment lorsque la gestion thermique et énergétique ne fonctionnait plus correctement.
Finalement, près de 245 modèles Dell sont concernés
Lors de la découverte initiale du problème, seule une petite dizaine de modèles avaient été publiquement identifiés.
Cette première liste comprenait notamment les Dell Pro Max, plusieurs Precision et les XPS 17 9720 et 9730.
Dell a désormais communiqué une liste beaucoup plus large : environ 245 modèles répartis dans presque toutes ses gammes.
On retrouve notamment :
environ 20 modèles Alienware ;
une trentaine d’Inspiron ;
environ 35 Latitude ;
une vingtaine d’OptiPlex ;
près de 30 Precision ;
une quinzaine de Vostro ;
environ 16 XPS ;
plusieurs Dell Pro, Dell Pro Max et Dell Pro Precision ;
différents PC de bureau, mini-PC, All-in-One et modèles Rugged.
Autrement dit, le problème ne concernait pas uniquement quelques stations de travail professionnelles récentes. Des ordinateurs grand public, professionnels et gaming pouvaient également être touchés.
Alienware également concerné
La présence d’Alienware dans la liste est particulièrement notable.
Les PC gaming reposent fortement sur les mécanismes de gestion dynamique des fréquences, des températures et de la puissance. Un dysfonctionnement du pilote Intel IPF peut donc avoir un impact direct sur leurs performances et leur refroidissement.
Dell recense environ une vingtaine de modèles dans les gammes Area-51, Aurora, m-series et x-series parmi les appareils potentiellement concernés.
Microsoft a publié KB5121767 en urgence
Microsoft a corrigé le problème le 18 juillet avec la mise à jour hors cycle KB5121767 pour Windows 11 24H2 et 25H2.
Cette mise à jour cumulative contient un correctif spécifique destiné aux appareils équipés du pilote Intel IPF et concernés par cette incompatibilité. Microsoft précise qu’elle est principalement recommandée pour les appareils affectés et qu’aucune action n’est nécessaire sur les autres PC.
Après installation :
Windows 11 25H2 passe en Build 26200.8894 ;
Windows 11 24H2 passe en Build 26100.8894.
Dell recommande désormais d’utiliser ces builds ou une version plus récente.
Comment vérifier si votre PC est corrigé ?
Si vous utilisez un PC Dell et avez rencontré des problèmes de performances, de température ou d’autonomie depuis les mises à jour de juin ou juillet, commencez par vérifier votre version de Windows.
Ouvrez : Paramètres > Système > Informations système puis consultez la rubrique consacrée aux spécifications de Windows.
Votre PC devrait utiliser au minimum :
26200.8894 sous Windows 11 25H2 ;
26100.8894 sous Windows 11 24H2.
Une build plus récente contient également le correctif.
Vous pouvez aussi lancer Windows Update afin d’installer les dernières mises à jour disponibles.
Faut-il encore installer KB5121767 aujourd’hui ?
Pas nécessairement.
KB5121767 était surtout une mise à jour d’urgence permettant de corriger immédiatement le problème sans attendre le cycle mensuel suivant. Microsoft indique qu’elle n’est recommandée que pour les appareils concernés.
Si votre PC possède déjà une build supérieure à 26200.8894 ou 26100.8894, le correctif est normalement déjà intégré à votre version de Windows.
Il est donc préférable de vérifier votre numéro de build plutôt que de chercher à installer manuellement KB5121767.
Un nouvel exemple des problèmes de compatibilité entre Windows et les pilotes
Cet incident montre une nouvelle fois à quel point les pilotes jouent un rôle critique dans la stabilité d’un système moderne.
Une modification relativement ciblée dans Windows, ici autour de la gestion USB-C, peut entrer en conflit avec un composant utilisé pour la gestion thermique et énergétique du PC.
Microsoft a d’ailleurs reconnu ce problème plus général de qualité des pilotes et travaille avec les constructeurs dans le cadre de sa Driver Quality Initiative. L’objectif est notamment d’améliorer les tests, de limiter les pilotes susceptibles d’interagir de manière problématique avec le noyau et de retirer de Windows Update les pilotes anciens ou devenus incompatibles.
Cela rejoint directement la stratégie récemment présentée par Microsoft pour améliorer la fiabilité de Windows et réduire les problèmes liés aux pilotes tiers.
Dell ou Microsoft : qui est responsable ?
Dell attribue clairement l’apparition du problème aux récentes mises à jour Windows, qui ont introduit l’interface Windows USB-C Connection Manager incompatible avec le pilote Intel IPF utilisé sur ses machines.
Il serait toutefois réducteur de résumer l’incident à une simple faute de Microsoft.
Le problème se situe précisément à l’intersection entre Windows, le pilote Intel et l’intégration réalisée par Dell. Une modification du système d’exploitation peut révéler une incompatibilité qui n’avait pas été détectée lors des phases de validation entre Microsoft, Intel et le constructeur.
C’est précisément ce type de scénario que Microsoft cherche désormais à éviter en renforçant les tests et les critères de validation des pilotes.
Le problème est désormais considéré comme résolu
Pour les utilisateurs, l’essentiel est que le correctif est disponible depuis plusieurs semaines.
Les ordinateurs Dell qui reçoivent normalement les mises à jour Windows devraient désormais utiliser une build contenant la correction.
Si votre PC Dell continue malgré tout à présenter une surchauffe inhabituelle, une baisse soudaine de performances ou des arrêts après les mises à jour de juin ou juillet 2026, il est conseillé de :
installer toutes les mises à jour Windows disponibles ;
mettre à jour les pilotes Intel et le BIOS depuis le support Dell ;
vérifier que Windows utilise au minimum la build 26200.8894 ou 26100.8894 ;
contrôler dans le Gestionnaire de périphériques qu’aucune erreur n’est présente sur les composants Intel IPF.
Conclusion
Ce qui semblait initialement être un problème limité à quelques PC Dell s’est finalement révélé beaucoup plus vaste.
Avec environ 245 modèles concernés, des gammes Inspiron et XPS aux Latitude, Precision, OptiPlex et Alienware, cette incompatibilité entre Windows 11 et le pilote Intel IPF constitue l’un des incidents de compatibilité les plus significatifs de ces dernières mises à jour.
Le problème est heureusement corrigé depuis la publication de KB5121767. Il souligne toutefois la difficulté de faire évoluer Windows tout en maintenant la compatibilité avec des milliers de combinaisons de pilotes, de firmwares et de matériels.
Il illustre aussi pourquoi Microsoft met aujourd’hui davantage l’accent sur la qualité des pilotes et sur la coopération avec les constructeurs : une simple incompatibilité peut avoir des conséquences très concrètes sur les performances, la consommation et même la température d’un PC.
Sur les distributions Linux modernes utilisant systemd, les services système sont principalement administrés avec la commande systemctl. Serveur Web Nginx ou Apache, PHP-FPM, SSH, MariaDB/MySQL ou encore services réseau : lorsqu’un service ne démarre plus, s’arrête brutalement ou passe dans l’état failed, systemctl permet d’effectuer les premières vérifications.
Pour trouver pourquoi un service Linux est en échec, il faut généralement compléter le diagnostic avec journalctl, qui permet de consulter ses journaux et de retrouver les erreurs de configuration, problèmes de permissions, dépendances manquantes, ports déjà utilisés, timeouts ou crashs d’application.
Dans ce guide, découvrez comment vérifier et dépanner un service sous Linux avec systemctl et journalctl : lister les services, identifier ceux en échec, consulter leur état et leurs logs, démarrer ou redémarrer un service, vérifier ses dépendances et son fichier unit systemd, puis résoudre les erreurs empêchant son démarrage.
Sur la plupart des distributions Linux récentes, les services sont gérés par systemd. La commande systemctl permet de les lister, vérifier leur état, les démarrer ou les arrêter et diagnostiquer les services qui rencontrent des erreurs.
Pour afficher les services actuellement chargés par systemd, utilisez :
systemctl list-units --type=service
La commande affiche notamment le nom du service, son état de chargement et son état d’exécution.
Colonne
Description
UNIT
Nom de l’unité systemd, par exemple nginx.service ou ssh.service
LOAD
Indique si le fichier de configuration du service a été correctement chargé
ACTIVE
État général du service : active, inactive, failed, etc.
SUB
État plus précis du service : running, exited, dead, failed, etc.
DESCRIPTION
Description du service
Par défaut, list-units affiche principalement les unités actuellement chargées. Pour afficher tous les services installés, y compris ceux qui ne sont pas actuellement actifs, utilisez plutôt :
systemctl list-unit-files --type=service
Cette commande permet également de connaître leur configuration au démarrage, avec des états tels que enabled, disabled, static ou masked.
Pour afficher uniquement les services actuellement actifs :
Enfin, si votre objectif est de rechercher directement les services rencontrant un problème, inutile de parcourir toute la liste. systemctl dispose d’une commande dédiée permettant d’afficher uniquement les unités en échec :
systemctl --failed
C’est cette commande qu’il est recommandé d’utiliser en premier lorsqu’un service ne fonctionne plus ou après un problème système.
Lorsqu’une application ne fonctionne plus ou qu’un serveur présente un dysfonctionnement, commencez par vérifier si systemd a détecté des services en échec.
La commande suivante affiche toutes les unités actuellement dans l’état failed :
systemctl --failed
Vous pouvez obtenir par exemple :
UNIT LOAD ACTIVE SUB DESCRIPTION
php8.4-fpm.service loaded failed failed The PHP 8.4 FastCGI Process Manager
Les colonnes ACTIVE et SUB indiquent ici que le service a échoué. Cela signifie que systemd a tenté de le démarrer ou de le maintenir en fonctionnement, mais qu’une erreur l’en a empêché.
Pour limiter la recherche aux services :
systemctl --failed --type=service
Vérifier un service en particulier
Si vous connaissez le nom du service en panne, affichez directement son état avec :
systemctl status nom-du-service
Par exemple :
systemctl status php8.4-fpm
ou :
systemctl status nginx
La sortie de systemctl status fournit plusieurs informations importantes :
Loaded : indique si l’unité systemd a été correctement chargée.
Active : indique si le service est actif, arrêté ou en échec.
Main PID : PID du processus principal lorsqu’il fonctionne.
Result : raison générale de l’échec.
Process / ExecStart : commande ayant été exécutée par systemd.
Les derniers messages du journal associés au service.
Vous pouvez par exemple rencontrer :
Active: failed (Result: exit-code)
Cela indique que le programme lancé par systemd s’est terminé avec un code de retour indiquant une erreur. Il faut alors rechercher le message qui explique pourquoi le programme s’est arrêté.
Comprendre l’état Active
Le champ Active permet de connaître rapidement la situation du service.
État
Signification
active (running)
Le service fonctionne normalement
active (exited)
La commande du service s’est terminée correctement, mais aucun processus ne reste actif. Cela peut être normal pour certains services
inactive (dead)
Le service n’est actuellement pas démarré
failed
Le service a tenté de fonctionner mais a rencontré une erreur
activating
Le service est en cours de démarrage
deactivating
Le service est en cours d’arrêt
Un état active (exited) n’est donc pas nécessairement une erreur. Certains services de type oneshot exécutent une tâche puis se terminent normalement.
Repérer le code d’erreur
Lorsqu’un service échoue, recherchez particulièrement les lignes Result, code et status.
Par exemple :
Active: failed (Result: exit-code)
puis :
code=exited, status=1/FAILURE
Cela signifie que le programme a été lancé mais s’est terminé avec un code d’erreur.
Vous pouvez également rencontrer :
Result: timeout : le service n’a pas terminé son démarrage ou son arrêt dans le délai prévu.
Result: signal : le processus a été terminé par un signal.
Result: core-dump : le processus a planté et généré un core dump.
Result: exit-code : le programme s’est terminé avec un code d’erreur.
Result: watchdog : le service n’a pas répondu au mécanisme watchdog dans le délai prévu.
Les dernières lignes affichées par systemctl status donnent souvent une première indication sur l’origine du problème. Toutefois, elles ne représentent qu’une partie des journaux.
Pour obtenir l’historique complet et déterminer pourquoi le service a échoué, l’étape suivante consiste à consulter ses logs avec journalctl -u.
Consulter les services qui ont échoué après le démarrage
Après un redémarrage, il peut être utile d’exécuter :
systemctl --failed
Un service secondaire en échec n’indique pas nécessairement un problème grave. En revanche, si un composant essentiel comme SSH, Nginx, Apache, PHP-FPM, MariaDB/MySQL ou un service réseau apparaît dans cette liste, son échec peut expliquer directement le dysfonctionnement rencontré.
Ne redémarrez pas systématiquement le service immédiatement. Commencez plutôt par consulter son état et ses journaux, afin de conserver les informations permettant d’identifier la cause de l’échec.
La prochaine étape consiste donc à utiliser systemctl status, puis journalctl -u pour déterminer précisément pourquoi le service ne démarre plus.
Consulter les logs d’un service
La commande journalctl permet de consulter les journaux enregistrés par systemd pour un service particulier. C’est l’une des commandes les plus importantes pour comprendre pourquoi un service ne démarre pas, s’arrête brutalement ou rencontre des erreurs.
Pour afficher les journaux d’un service, utilisez l’option -u suivie du nom de l’unité :
sudo journalctl -u nom-du-service
Par exemple, pour Nginx :
sudo journalctl -u nginx
Ou pour PHP-FPM :
sudo journalctl -u php8.4-fpm
Afficher les derniers événements
Lorsque le journal contient beaucoup d’entrées, utilisez l’option -e pour vous positionner directement à la fin :
sudo journalctl -u nginx -e
Vous pouvez également afficher uniquement les dernières lignes :
sudo journalctl -u nginx -n 50
Cela permet de retrouver rapidement les événements enregistrés juste avant l’arrêt ou l’échec du service.
Cette méthode est particulièrement utile lorsque vous connaissez approximativement l’heure à laquelle le service est tombé en panne.
Suivre les logs en temps réel
Pour afficher les nouveaux événements au fur et à mesure qu’ils sont générés, utilisez l’option -f :
sudo journalctl -u nginx -f
Laissez cette commande ouverte puis, dans un autre terminal, redémarrez le service ou reproduisez le problème. Vous pourrez ainsi observer immédiatement les erreurs générées.
Utilisez Ctrl + C pour arrêter le suivi.
Rechercher les erreurs importantes
Portez notamment attention aux messages contenant :
failed ou failure : échec d’une opération.
permission denied : problème de permissions.
address already in use : un autre processus utilise déjà le port nécessaire.
out of memory ou killed process : manque de mémoire.
segfault ou core dumped : plantage du programme.
timeout : délai d’attente dépassé.
dependency failed : une dépendance nécessaire au service est en échec.
configuration error ou syntax error : erreur dans un fichier de configuration.
Il est également important de vérifier les logs propres à l’application. journalctl peut indiquer qu’un service a échoué sans contenir tous les détails. Nginx, Apache, PHP-FPM, MariaDB ou d’autres applications peuvent écrire des informations supplémentaires dans leurs propres fichiers sous /var/log/.
Après avoir identifié le message d’erreur, évitez de redémarrer le service en boucle. Vérifiez d’abord sa configuration, ses permissions, ses ports et ses dépendances afin de corriger la cause réelle de l’échec.
Activer ou désactiver un service au démarrage
Par défaut, tous les services Linux ne sont pas automatiquement lancés au démarrage du système. Avec systemd, la commande systemctl permet de vérifier si un service est configuré pour démarrer automatiquement, puis d’activer ou de désactiver ce comportement.
Pour vérifier l’état d’un service au démarrage :
systemctl is-enabled nom-du-service
Par exemple :
systemctl is-enabled nginx
La commande peut notamment retourner :
enabled : le service est activé au démarrage.
disabled : le service existe mais n’est pas activé automatiquement.
static : le service ne peut pas être activé directement et est généralement lancé comme dépendance d’une autre unité.
masked : le service est complètement bloqué et ne peut pas être démarré normalement.
Activer un service au démarrage
Pour configurer un service afin qu’il démarre automatiquement avec Linux :
sudo systemctl enable nom-du-service
Par exemple :
sudo systemctl enable nginx
La commande enablen’a pas pour rôle de démarrer immédiatement le service. Elle configure systemd afin qu’il soit lancé automatiquement lors des prochains démarrages.
Si vous souhaitez à la fois activer et démarrer immédiatement le service :
sudo systemctl enable --now nginx
Vous pouvez ensuite vérifier son état :
systemctl status nginx
Désactiver un service au démarrage
Pour empêcher le démarrage automatique d’un service :
sudo systemctl disable nom-du-service
Par exemple :
sudo systemctl disable nginx
Le service ne sera plus lancé automatiquement au prochain démarrage, mais il n’est pas arrêté immédiatement.
Pour le désactiver et l’arrêter dans la même opération :
sudo systemctl disable --now nginx
Ne pas confondre disable et mask
La commande disable empêche simplement le démarrage automatique. Le service peut toujours être lancé manuellement avec :
sudo systemctl start nginx
À l’inverse, mask bloque complètement son démarrage :
sudo systemctl mask nom-du-service
Une tentative de démarrage retourne alors une erreur indiquant que l’unité est masked.
Pour lever ce blocage :
sudo systemctl unmask nom-du-service
Utilisez mask avec prudence, car un autre service peut dépendre de l’unité que vous bloquez. Pour un simple dépannage ou pour empêcher un service de démarrer avec Linux, disable est généralement suffisant.
Vérifier pourquoi un service ne démarre pas
Lorsqu’un service refuse de démarrer, évitez de le relancer plusieurs fois sans examiner la cause de l’échec. systemctl et journalctl permettent généralement d’obtenir les premières informations nécessaires au diagnostic.
Commencez par afficher l’état du service :
systemctl status nom-du-service
Par exemple :
systemctl status nginx
Examinez particulièrement les lignes Active, Result, ExecStart et les derniers messages affichés. Un état tel que :
Active: failed (Result: exit-code)
indique que le programme a bien été lancé par systemd, mais qu’il s’est terminé avec une erreur.
Consultez ensuite les journaux complets du service :
sudo journalctl -u nom-du-service -e
Pour afficher les événements du démarrage actuel :
sudo journalctl -u nom-du-service -b
Les messages d’erreur permettent généralement de déterminer dans quelle direction poursuivre le diagnostic.
Message ou symptôme
Cause probable
Vérification
Permission denied
Droits incorrects sur un fichier, répertoire ou socket
Vérifier le propriétaire et les permissions avec ls -l ou namei -l
Address already in use
Le port utilisé par le service est déjà occupé
Identifier le processus avec ss -lntup
No such file or directory
Fichier de configuration, exécutable ou autre fichier nécessaire absent
Vérifier les chemins indiqués dans les logs
Configuration error / Syntax error
Erreur dans un fichier de configuration
Utiliser l’outil de validation fourni par l’application
Dependency failed
Un service ou une unité nécessaire est en échec
Examiner les dépendances avec systemctl list-dependencies
Failed with result ‘exit-code’
Le programme s’est terminé avec un code d’erreur
Examiner systemctl status et journalctl -u
Failed with result ‘timeout’
Le service n’a pas démarré dans le délai prévu
Rechercher un blocage, une dépendance ou une ressource inaccessible
Start request repeated too quickly
Le service plante immédiatement et systemd a cessé de tenter de le redémarrer
Corriger l’erreur initiale puis utiliser systemctl reset-failed
Out of memory / Killed process
Processus arrêté à cause d’un manque de mémoire
Vérifier la RAM, le swap et l’OOM Killer
Segmentation fault / core dumped
Le programme a planté
Examiner les journaux et utiliser coredumpctl
Vérifier si un port est déjà utilisé
Pour un serveur Web, une base de données, SSH ou tout autre service réseau, vérifiez que le port nécessaire n’est pas déjà occupé :
sudo ss -lntup
Par exemple, pour rechercher le processus utilisant le port 80 :
sudo ss -lntp | grep ':80 '
Si un autre programme écoute déjà sur ce port, le nouveau service peut échouer avec une erreur Address already in use.
Vérifier les permissions
Une erreur Permission denied peut provenir des droits d’un fichier de configuration, d’un répertoire, d’un certificat, d’un socket ou d’un fichier de log.
Commencez par vérifier les permissions :
ls -l /chemin/vers/fichier
Pour contrôler également les permissions de chaque répertoire constituant le chemin :
namei -l /chemin/vers/fichier
Cette dernière commande est particulièrement pratique lorsqu’un service possède les droits sur le fichier lui-même mais ne peut pas traverser l’un des répertoires parents.
Rechercher un manque de mémoire ou un crash
Si le processus disparaît immédiatement, recherchez une intervention de l’OOM Killer :
En présence d’un segfault ou d’un core dump, vérifiez également :
coredumpctl list
Puis affichez les informations du crash concerné avec :
coredumpctl info
Enfin, lorsqu’un service refuse de démarrer après une modification de sa configuration, vérifiez toujours la syntaxe avant de le redémarrer. De nombreux logiciels fournissent leur propre commande de validation, ce qui permet souvent d’identifier immédiatement la ligne ou le fichier responsable de l’erreur.
Vérifier la configuration avant de redémarrer un service
Lorsqu’un service ne fonctionne plus après la modification d’un fichier de configuration, vérifiez sa syntaxe avant de le redémarrer. De nombreux logiciels Linux disposent d’une commande permettant de valider leur configuration sans interrompre le service actuellement en cours d’exécution.
Cette précaution est particulièrement importante sur un serveur distant : une simple erreur de syntaxe dans Nginx, Apache ou SSH peut empêcher le service de redémarrer et rendre le serveur ou un site inaccessible.
Voici quelques commandes courantes :
Service
Commande de vérification
Nginx
sudo nginx -t
Apache (Debian/Ubuntu)
sudo apache2ctl configtest
Apache (RHEL/Fedora)
sudo httpd -t
PHP-FPM
sudo php-fpm -t ou la commande correspondant à la version installée
OpenSSH
sudo sshd -t
Postfix
sudo postfix check
Samba
sudo testparm
Par exemple, après avoir modifié la configuration de Nginx :
sudo nginx -t
Si la configuration est correcte, vous obtenez notamment :
syntax is ok
test is successful
Vous pouvez alors recharger la configuration sans interrompre les connexions existantes :
sudo systemctl reload nginx
Si le test retourne une erreur, ne redémarrez pas le service immédiatement. Le message indique généralement le fichier et parfois la ligne contenant l’erreur. Corrigez-la, puis relancez le test.
Pour SSH, cette précaution est encore plus importante lorsque vous administrez un serveur à distance. Après avoir modifié sshd_config, vérifiez la configuration avec :
sudo sshd -t
Si aucune erreur n’est affichée, la syntaxe est valide. Gardez toutefois votre session SSH actuelle ouverte jusqu’à ce que vous ayez confirmé qu’une nouvelle connexion fonctionne correctement.
Enfin, lorsque le logiciel le permet, préférez systemctl reload à restart pour une simple modification de configuration. reload demande au service de relire sa configuration sans l’arrêter complètement, tandis que restart provoque un arrêt puis un nouveau démarrage du service.
Réinitialiser l’état failed d’un service
Lorsqu’un service échoue à plusieurs reprises, systemd peut conserver son état failed, même après avoir corrigé la cause du problème. Dans certains cas, systemd peut également cesser temporairement de tenter de démarrer le service lorsque celui-ci plante plusieurs fois en peu de temps.
Vous pouvez vérifier les services actuellement en échec avec :
systemctl --failed
Après avoir identifié et corrigé la cause du problème, réinitialisez l’état d’échec du service avec :
sudo systemctl reset-failed nom-du-service
Par exemple, pour Nginx :
sudo systemctl reset-failed nginx
Vous pouvez ensuite tenter de démarrer à nouveau le service :
sudo systemctl start nginx
Puis vérifiez son état :
systemctl status nginx
La commande reset-failed ne répare pas le service. Elle efface simplement l’état failed enregistré par systemd ainsi que certains compteurs associés aux échecs de démarrage. Il faut donc toujours corriger l’erreur initiale avant de l’utiliser.
Cette commande est notamment utile lorsque vous rencontrez un message de ce type :
Start request repeated too quickly
ou :
Failed with result 'start-limit-hit'
Cela signifie généralement que le service a échoué plusieurs fois dans un intervalle court et que systemd a atteint sa limite de tentatives de démarrage.
Dans ce cas :
Consultez d’abord les erreurs avec systemctl status nom-du-service.
Examinez les journaux avec journalctl -u nom-du-service.
Corrigez la configuration, les permissions ou le problème ayant provoqué les échecs.
Exécutez systemctl reset-failed nom-du-service.
Tentez à nouveau de démarrer le service.
Pour réinitialiser l’état failed de toutes les unités systemd en échec, vous pouvez utiliser :
sudo systemctl reset-failed
Cette dernière commande doit surtout être utilisée après avoir vérifié les unités concernées : effacer leur état failed sans comprendre pourquoi elles ont échoué peut masquer temporairement des problèmes qui nécessitent encore une intervention.
Vérifier les dépendances d’un service
Un service Linux peut refuser de démarrer alors que sa propre configuration est correcte parce qu’une unité dont il dépend est arrêtée ou en échec. Avec systemd, ces dépendances peuvent concerner un autre service, un point de montage, un socket, un périphérique ou une cible (target).
Pour afficher les dépendances d’un service, utilisez :
systemctl list-dependencies nom-du-service
Par exemple :
systemctl list-dependencies nginx
La commande affiche l’arborescence des unités nécessaires ou associées au fonctionnement du service.
Pour afficher également les dépendances qui ne sont pas actuellement actives :
systemctl list-dependencies --all nginx
Si une unité apparaît en échec, vérifiez son état :
systemctl status nom-de-unite
Puis consultez ses journaux :
sudo journalctl -u nom-de-unite -e
Rechercher les dépendances inverses
Il peut également être utile de déterminer quels services dépendent d’une unité donnée. Utilisez pour cela :
Cela permet d’identifier les unités susceptibles d’être affectées si MariaDB est arrêté ou en échec.
Comprendre les relations entre les unités
Pour obtenir des informations plus précises sur les dépendances déclarées par un service :
systemctl show nom-du-service
Vous pouvez notamment rechercher les propriétés :
Requires : unités nécessaires au fonctionnement du service.
Wants : dépendances souhaitées mais généralement moins strictes.
After et Before : ordre de démarrage entre les unités.
BindsTo : dépendance forte à une autre unité.
PartOf : lie certaines opérations, comme l’arrêt ou le redémarrage, à une autre unité.
Par exemple :
systemctl show nginx -p Requires -p Wants -p After
Si systemctl status affiche un message tel que Dependency failed for…, ne cherchez donc pas uniquement une erreur dans le service concerné. Identifiez d’abord l’unité en échec dont il dépend, puis corrigez celle-ci avant de tenter un nouveau démarrage.
Vérifier le fichier unit systemd
Chaque service géré par systemd repose sur un fichier unit (.service) qui décrit notamment la commande à exécuter, l’utilisateur utilisé, les dépendances, les conditions de redémarrage et l’ordre de lancement.
Lorsqu’un service ne démarre plus ou se comporte de manière inattendue, il peut être utile de vérifier le fichier unit réellement utilisé par systemd, notamment si celui-ci a été personnalisé.
Pour afficher la définition complète d’un service :
systemctl cat nom-du-service
Par exemple :
systemctl cat nginx
Cette commande est préférable à l’ouverture directe d’un fichier dans /etc/systemd/system/ ou /usr/lib/systemd/system/, car elle affiche la configuration réellement assemblée par systemd, y compris les éventuels fichiers de surcharge (drop-ins).
Vous pouvez notamment y retrouver les sections suivantes :
Section / directive
Rôle
[Unit]
Informations générales et dépendances du service
After= / Before=
Ordre de démarrage par rapport aux autres unités
Requires= / Wants=
Dépendances du service
[Service]
Paramètres d’exécution du service
ExecStart=
Commande utilisée pour démarrer le service
ExecReload=
Commande utilisée lors d’un rechargement
User= / Group=
Utilisateur et groupe sous lesquels le service s’exécute
Restart=
Comportement à adopter lorsque le processus s’arrête
WorkingDirectory=
Répertoire de travail du processus
Environment=
Variables d’environnement fournies au service
[Install]
Définit notamment comment le service est activé au démarrage
Identifier l’emplacement du fichier unit
Pour connaître précisément le fichier chargé par systemd :
systemctl show nom-du-service -p FragmentPath
Par exemple :
systemctl show nginx -p FragmentPath
Vous pouvez également afficher les éventuels fichiers de surcharge :
systemctl show nginx -p DropInPaths
Les fichiers unit fournis par les paquets sont généralement stockés dans des répertoires comme /usr/lib/systemd/system/ ou /lib/systemd/system/, tandis que les personnalisations administrateur sont généralement placées dans /etc/systemd/system/.
Vérifier les personnalisations d’un service
Un service peut fonctionner avec son fichier unit d’origine mais également avec un ou plusieurs drop-ins qui remplacent certaines directives.
La commande :
systemctl cat nom-du-service
permet de visualiser ces différentes sources dans un même affichage.
C’est particulièrement utile lorsqu’un service fonctionne différemment de sa configuration par défaut après une ancienne modification, une migration ou l’ajout d’une personnalisation systemd.
Pour modifier proprement les paramètres d’un service sans éditer directement le fichier fourni par le paquet, utilisez :
sudo systemctl edit nom-du-service
systemd crée alors une surcharge dans /etc/systemd/system/ qui ne sera pas écrasée lors d’une mise à jour du paquet.
Après toute modification d’un fichier unit ou d’un drop-in, il est nécessaire de demander à systemd de recharger ses fichiers de configuration avec systemctl daemon-reload avant de redémarrer le service.
Recharger systemd après modification d’un service
Lorsque vous modifiez un fichier unit systemd (.service) ou un fichier de surcharge (drop-in), systemd ne prend pas automatiquement en compte les changements. Il faut lui demander de relire les fichiers unit avant de redémarrer le service concerné.
Pour cela, exécutez :
sudo systemctl daemon-reload
Cette commande recharge la configuration de systemd et prend notamment en compte les modifications effectuées dans :
/etc/systemd/system/
/usr/lib/systemd/system/
/lib/systemd/system/
Les fichiers de surcharge créés avec systemctl edit
Après le rechargement, redémarrez le service concerné :
sudo systemctl restart nom-du-service
Puis vérifiez son état :
systemctl status nom-du-service
Par exemple, après avoir modifié une surcharge pour Nginx :
sudo systemctl daemon-reload
sudo systemctl restart nginx
systemctl status nginx
Ne pas confondre daemon-reload, reload et restart
Ces trois commandes ont des fonctions différentes :
Commande
Action
systemctl daemon-reload
Demande à systemd de relire les fichiers unit et leurs surcharges
systemctl reload service
Demande au service lui-même de relire sa configuration, sans l’arrêter lorsque celui-ci prend en charge cette opération
En revanche, si vous avez uniquement modifié le fichier de configuration de l’application, par exemple nginx.conf, un daemon-reload n’est généralement pas nécessaire. Après avoir vérifié la syntaxe, vous pouvez simplement recharger Nginx :
sudo nginx -t
sudo systemctl reload nginx
Retenez donc que daemon-reload concerne la configuration de systemd, tandis que reload concerne la configuration du service ou de l’application.
Tableau des commandes systemctl pour dépanner un service
Le tableau suivant récapitule les principales commandes systemctl à connaître pour vérifier, diagnostiquer et réparer un service géré par systemd.
Commande
Description
systemctl list-units --type=service
Lister les services actuellement chargés
systemctl list-unit-files --type=service
Lister tous les fichiers de services installés et leur état d’activation
systemctl --failed
Afficher les unités actuellement en échec
systemctl status service
Afficher l’état détaillé d’un service et ses derniers messages
systemctl is-active service
Vérifier rapidement si un service est actif
systemctl is-enabled service
Vérifier si un service est activé au démarrage
systemctl start service
Démarrer un service
systemctl stop service
Arrêter un service
systemctl restart service
Arrêter puis redémarrer un service
systemctl reload service
Recharger la configuration d’un service sans l’arrêter, lorsque cette fonction est prise en charge
systemctl enable service
Activer le démarrage automatique d’un service
systemctl enable --now service
Activer un service au démarrage et le démarrer immédiatement
systemctl disable service
Désactiver le démarrage automatique d’un service
systemctl disable --now service
Désactiver le service au démarrage et l’arrêter immédiatement
systemctl mask service
Bloquer complètement le démarrage d’un service
systemctl unmask service
Lever le blocage appliqué avec mask
systemctl reset-failed service
Effacer l’état failed et les compteurs d’échec d’un service
systemctl list-dependencies service
Afficher les dépendances d’un service
systemctl list-dependencies --reverse service
Afficher les unités qui dépendent du service
systemctl cat service
Afficher le fichier unit et les éventuels fichiers de surcharge (drop-ins)
systemctl show service
Afficher toutes les propriétés systemd d’un service
systemctl edit service
Créer ou modifier proprement une surcharge du fichier unit
systemctl daemon-reload
Demander à systemd de relire les fichiers unit après une modification
Pour un diagnostic rapide d’un service qui ne démarre plus, commencez généralement par ces trois commandes :
Si le service a échoué plusieurs fois et que systemd refuse désormais de le relancer avec un message comme Start request repeated too quickly, corrigez d’abord l’erreur puis utilisez :
Enfin, n’oubliez pas que systemctl et journalctl sont complémentaires : systemctl permet surtout de connaître et modifier l’état du service, tandis que journalctl permet d’analyser ses journaux afin de déterminer pourquoi il a échoué.
Un PC ou un serveur Linux qui plante, se bloque, ralentit fortement ou redémarre de manière inattendue peut avoir de nombreuses causes. Le problème peut provenir d’un processus qui monopolise le CPU ou la mémoire RAM, d’un manque de mémoire et de l’OOM Killer, d’un service en échec, d’un disque saturé, d’une erreur du système de fichiers, d’un Kernel Panic ou encore d’une défaillance matérielle.
Linux fournit heureusement de nombreux outils permettant de retrouver l’origine d’un plantage. Les commandes dmesg et journalctl permettent d’examiner les événements du noyau et du système, tandis que top, free, systemctl, coredumpctl ou encore les journaux du démarrage précédent permettent d’identifier une surcharge, un crash d’application ou un redémarrage anormal.
Dans ce guide, découvrez une méthode complète pour diagnostiquer un plantage ou un blocage sous Linux, analyser les journaux, vérifier les ressources du système et déterminer si le problème est logiciel, matériel, lié au stockage, à la mémoire ou au réseau.
Avant de lancer des commandes de diagnostic, commencez par déterminer ce qui s’est réellement produit sur votre système Linux. Un ordinateur complètement figé, un serveur inaccessible en SSH ou une application qui ne répond plus peuvent donner l’impression que Linux a planté alors que les causes sont très différentes.
Par exemple, un serveur peut continuer à fonctionner normalement alors qu’un problème réseau empêche simplement d’y accéder. À l’inverse, un manque de mémoire peut provoquer l’arrêt brutal de certains processus sans entraîner le plantage complet du système.
Le tableau suivant permet d’orienter les premières recherches.
Symptôme
Causes possibles
Vérifications prioritaires
Linux est complètement figé
Kernel Panic, pilote défectueux, problème RAM, GPU ou matériel
L’interface graphique se fige ou affiche un écran noir
Pilote graphique, GPU, serveur d’affichage ou environnement de bureau
journalctl, dmesg, journaux graphiques
Le système se bloque sous forte charge
RAM insuffisante, OOM, surchauffe, alimentation ou problème matériel
free -h, top, sensors, journaux kernel
Il est également important de noter le contexte dans lequel le problème apparaît : pendant une sauvegarde, lors d’une forte charge PHP/MySQL, durant une copie importante de fichiers, après une mise à jour du noyau, au démarrage ou de manière totalement aléatoire. Ces informations permettent souvent de réduire considérablement le champ des recherches.
Après un redémarrage consécutif à un plantage, évitez de vous limiter aux journaux du démarrage actuel. Les informations les plus intéressantes se trouvent souvent dans les journaux du démarrage précédent. Nous verrons notamment comment utiliser journalctl -b -1 pour retrouver les événements qui ont précédé le crash.
La première étape consiste toutefois à vérifier si Linux a réellement redémarré et à déterminer depuis combien de temps le système fonctionne.
Vérifier les journaux du noyau avec dmesg
La commande dmesg permet de consulter les messages générés par le noyau Linux depuis le démarrage du système. Elle est particulièrement utile lorsqu’un PC ou un serveur Linux se bloque, devient instable ou rencontre un problème matériel.
Les messages du noyau peuvent notamment révéler des erreurs de disque, des problèmes de système de fichiers, un manque de mémoire, une surchauffe, un pilote défaillant ou encore une erreur matérielle.
Pour afficher les messages du noyau, ouvrez un terminal puis exécutez :
sudo dmesg
La quantité d’informations peut être importante. Pour afficher uniquement les erreurs et avertissements :
sudo dmesg --level=err,warn
Vous pouvez également utiliser l’option -T afin d’obtenir des dates et heures plus faciles à lire :
sudo dmesg -T
Pour rechercher rapidement les messages susceptibles d’indiquer un problème :
Rechercher les erreurs de disque et de système de fichiers
Un problème de disque dur, de SSD ou de système de fichiers peut provoquer des ralentissements importants, des blocages et parfois un plantage complet de Linux.
Portez notamment attention aux messages contenant I/O error, Buffer I/O error, EXT4-fs error, XFS ou des erreurs associées à un périphérique NVMe/SATA.
Rechercher un manque de mémoire
Lorsque Linux manque de mémoire RAM et de swap, le noyau peut déclencher l’OOM Killer (Out Of Memory Killer) afin de terminer un ou plusieurs processus et récupérer de la mémoire.
Un message contenant par exemple Out of memory suivi de Killed process indique qu’un processus a probablement été arrêté à cause d’un manque de mémoire.
Nous verrons plus loin comment diagnostiquer précisément les problèmes de RAM, swap et OOM Killer.
Rechercher les erreurs matérielles et les surchauffes
Vous pouvez également rechercher les messages susceptibles d’indiquer une défaillance matérielle :
Des messages contenant Hardware Error, Machine Check Exception (MCE) ou EDAC peuvent signaler une erreur détectée au niveau du processeur, de la mémoire ou d’un autre composant matériel.
Les mentions thermal ou throttling peuvent quant à elles indiquer un problème de température ou une réduction automatique des performances pour protéger le matériel.
Voici quelques messages importants que vous pouvez rencontrer :
Message
Cause possible
I/O error
Erreur de disque, SSD, contrôleur ou connexion au périphérique
Buffer I/O error
Échec d’une opération de lecture ou d’écriture
EXT4-fs error / XFS / Btrfs error
Problème du système de fichiers
Out of memory
Mémoire disponible insuffisante
Killed process
Processus terminé, notamment par l’OOM Killer
segfault
Plantage d’un processus avec erreur de segmentation
Hardware Error / MCE
Erreur matérielle détectée
EDAC
Erreur liée notamment à la mémoire avec prise en charge EDAC
thermal / throttling
Température élevée ou limitation thermique
NVRM / amdgpu / i915
Message pouvant concerner le GPU ou son pilote
watchdog
Blocage ou absence de réponse détectée
Un message contenant error ou warning ne signifie toutefois pas systématiquement qu’il est responsable du plantage. Il faut surtout rechercher les événements apparus juste avant le problème et les erreurs qui se répètent.
Enfin, dmesg concerne essentiellement les messages du noyau du démarrage en cours. Si Linux a complètement planté puis redémarré, les informations qui ont précédé le crash peuvent ne plus être présentes dans le buffer actuel. Dans ce cas, il faut examiner les journaux persistants du démarrage précédent avec journalctl, notamment avec journalctl -b -1 et journalctl -k -b -1.
Lorsqu’un serveur ou un PC Linux semble avoir planté, il est utile de déterminer s’il a réellement redémarré et si ce redémarrage a été précédé d’un arrêt normal. Un redémarrage brutal peut notamment être provoqué par un Kernel Panic, un watchdog, une coupure d’alimentation, une surchauffe ou un problème matériel.
La commande last permet de consulter l’historique des connexions, mais également des démarrages et arrêts du système grâce à l’option -x.
Exécutez :
last -x
Vous obtenez des lignes contenant notamment :
reboot system boot 6.8.0-63-generic Thu Aug 7 08:42 still running
shutdown system down 6.8.0-63-generic Wed Aug 6 23:15 - 23:16
Les entrées importantes sont :
Entrée
Signification
reboot
Démarrage du système
shutdown
Arrêt normal de Linux
runlevel
Changement de niveau d’exécution ou de cible systemd
crash
Une session s’est terminée sans arrêt propre enregistré
still running
Le système ou la session concernée est toujours actif
Pour afficher uniquement les redémarrages :
last reboot
Vous pouvez également afficher uniquement les arrêts :
last -x shutdown
Repérer un redémarrage brutal
Ce qui nous intéresse particulièrement lors d’un diagnostic est la succession des événements.
Lors d’un arrêt normal, vous devez généralement retrouver une entrée shutdown avant le démarrage suivant :
shutdown system down ...
reboot system boot ...
En revanche, si vous observez un nouveau reboot sans événement shutdown correspondant juste avant, le système peut avoir subi un redémarrage non propre.
Cela peut se produire après :
Une coupure électrique ou un problème d’alimentation.
Un appui prolongé sur le bouton Marche/Arrêt.
Un reset matériel.
Un Kernel Panic suivi d’un redémarrage automatique.
Le déclenchement d’un watchdog.
Une défaillance matérielle.
La commande last permet donc de confirmer qu’un redémarrage anormal a eu lieu, mais elle n’en indique généralement pas la cause.
Une fois le redémarrage suspect identifié, notez sa date et son heure puis examinez les événements qui l’ont précédé dans le journal du démarrage précédent :
journalctl -b -1
Pour vous concentrer uniquement sur les messages du noyau :
journalctl -k -b -1
C’est souvent dans les dernières secondes ou minutes précédant le redémarrage que vous trouverez les informations les plus utiles : erreur disque, OOM Killer, Kernel Panic, problème matériel, watchdog ou autre anomalie.
Examiner les journaux avec journalctl
La commande journalctl permet de consulter les journaux enregistrés par systemd-journald. Lorsqu’un PC ou un serveur Linux plante, redémarre brutalement ou devient instable, c’est l’un des premiers outils à utiliser pour rechercher les événements qui ont précédé le problème.
Contrairement à dmesg, qui permet surtout de consulter les messages du noyau du démarrage actuel, journalctl peut conserver les journaux des démarrages précédents, à condition que la journalisation persistante soit activée.
Pour afficher les événements du démarrage actuel :
sudo journalctl -b
Pour afficher uniquement les erreurs :
sudo journalctl -b -p err
Examiner le démarrage précédent après un plantage
Si Linux a planté puis redémarré, le plus intéressant est généralement d’examiner le démarrage précédent :
sudo journalctl -b -1
Commencez par regarder les dernières lignes du journal, car elles correspondent aux événements enregistrés juste avant l’arrêt ou le plantage :
sudo journalctl -b -1 -e
Pour limiter l’affichage aux erreurs du démarrage précédent :
sudo journalctl -b -1 -p err
Vous pouvez également afficher uniquement les messages du noyau Linux :
sudo journalctl -k -b -1
Cette dernière commande est particulièrement utile pour rechercher une erreur matérielle, un Kernel Panic, un problème de stockage, une erreur de pilote ou un manque de mémoire ayant précédé le plantage.
Rechercher les événements autour de l’heure du plantage
Si vous connaissez approximativement l’heure à laquelle le problème s’est produit, utilisez les options --since et --until afin de réduire considérablement le nombre de messages à analyser.
Vous pouvez ainsi examiner uniquement les événements enregistrés dans les minutes précédant le crash.
Portez particulièrement attention aux messages contenant des termes tels que :
Out of memory, OOM ou Killed process : manque de mémoire et intervention de l’OOM Killer.
I/O error : problème d’entrée/sortie, souvent lié au stockage.
EXT4-fs error, XFS ou Btrfs : erreur du système de fichiers.
segfault : plantage d’un processus.
kernel panic : erreur fatale du noyau.
watchdog : système ou composant devenu non réactif.
thermal ou throttling : problème de température.
Hardware Error, MCE ou EDAC : erreur matérielle.
Enfin, ne vous focalisez pas uniquement sur la dernière erreur affichée. Un message d’erreur peut être la conséquence du plantage et non sa cause. Examinez plutôt la chronologie des événements dans les secondes ou minutes précédant le problème.
Un Kernel Panic correspond à une erreur critique du noyau Linux dont celui-ci ne peut pas se remettre normalement. Selon la configuration du système, Linux peut alors se figer complètement, afficher un message d’erreur à l’écran ou redémarrer automatiquement après quelques secondes.
Les Kernel Panic peuvent avoir de nombreuses origines : pilote défectueux, module du noyau, problème de RAM, erreur CPU, système de fichiers endommagé, périphérique de stockage défaillant ou bug du noyau.
Après un redémarrage consécutif à un plantage, commencez par examiner les messages du noyau du démarrage précédent :
sudo journalctl -k -b -1
Pour rechercher directement les occurrences de Kernel Panic :
Portez notamment attention aux messages suivants :
Message
Signification possible
Kernel panic – not syncing
Le noyau a rencontré une erreur fatale et ne peut plus continuer son exécution.
Oops
Erreur grave du noyau qui n’entraîne pas nécessairement immédiatement un Kernel Panic.
BUG:
Détection d’un comportement anormal dans le noyau ou un module.
Call Trace
Pile d’appels permettant d’identifier les fonctions et modules impliqués dans le crash.
Unable to mount root fs
Le noyau ne parvient pas à monter le système de fichiers racine.
Machine Check Exception (MCE)
Le processeur a détecté une erreur matérielle.
Hardware Error
Erreur matérielle remontée au noyau.
Identifier le module ou le pilote impliqué
Lorsqu’un Kernel Panic affiche une Call Trace, recherchez les noms de modules présents juste avant ou dans la trace. Ils peuvent permettre d’identifier un pilote responsable du plantage.
Par exemple, des références répétées à des modules tels que nvidia, amdgpu, i915, un pilote réseau ou un module tiers peuvent orienter le diagnostic.
Vérifiez également si le problème est apparu après :
Une mise à jour du noyau Linux.
L’installation ou la mise à jour d’un pilote graphique.
L’ajout d’un module DKMS.
Une mise à jour importante du système.
L’installation d’un nouveau matériel.
Si le problème a commencé après une mise à jour du noyau, vous pouvez temporairement démarrer sur un noyau précédent depuis GRUB afin de vérifier si le plantage disparaît.
Que faire si aucun Kernel Panic n’est enregistré ?
Un Kernel Panic ne peut pas toujours être écrit dans les journaux. Si le noyau ou le stockage devient inutilisable immédiatement, le système peut planter avant que les dernières informations soient enregistrées sur le disque.
Ainsi, l’absence de kernel panic dans journalctlne permet pas d’exclure totalement cette cause.
Si le système redémarre brutalement sans laisser de trace exploitable, poursuivez le diagnostic en recherchant notamment un problème de RAM, une surchauffe, une défaillance du stockage ou une erreur matérielle. Il faudra également vérifier si le redémarrage a été déclenché par un watchdog ou une panne d’alimentation.
Vérifier un manque de mémoire et l’OOM Killer
Un manque de mémoire RAM peut provoquer d’importants ralentissements, rendre un serveur presque inaccessible ou entraîner l’arrêt brutal de certains processus. Sous Linux, lorsque la mémoire disponible devient insuffisante et que le système ne peut plus satisfaire les demandes d’allocation, le noyau peut déclencher l’OOM Killer (Out Of Memory Killer).
Son rôle est de sélectionner et de terminer un ou plusieurs processus afin de libérer rapidement de la mémoire et d’éviter, lorsque cela est possible, le blocage complet du système.
Sur un serveur Web, par exemple, l’OOM Killer peut arrêter un processus PHP-FPM, MySQL/MariaDB, Java ou tout autre service consommant beaucoup de mémoire.
Vérifier l’utilisation de la RAM et du swap
Commencez par afficher l’état de la mémoire :
free -h
Vous obtenez un résultat similaire à celui-ci :
total used free shared buff/cache available
Mem: 15Gi 11Gi 520Mi 650Mi 3.5Gi 3.1Gi
Swap: 4.0Gi 2.8Gi 1.2Gi
Ne vous fiez pas uniquement à la colonne free. Linux utilise volontairement la mémoire inutilisée comme cache. La colonne available est généralement plus pertinente pour estimer la quantité de mémoire encore disponible pour les applications.
Portez notamment attention aux situations suivantes :
available devient très faible.
Le swap est fortement utilisé.
L’utilisation du swap augmente rapidement.
Le système devient lent alors que la RAM est presque entièrement utilisée.
Pour surveiller l’évolution de la mémoire en temps réel, utilisez également :
vmstat 2
Les colonnes si (swap in) et so (swap out) permettent de détecter une activité importante du swap. Des valeurs élevées et persistantes peuvent indiquer une pression mémoire importante.
Rechercher le déclenchement de l’OOM Killer
Après un plantage ou l’arrêt inexpliqué d’un service, recherchez les événements liés à un manque de mémoire :
Out of memory: Killed process 18452 (php-fpm) total-vm:...
ou :
oom-kill:constraint=CONSTRAINT_NONE...
Killed process 18452 (php-fpm)...
Dans cet exemple, le noyau a décidé de terminer un processus PHP-FPM afin de récupérer de la mémoire. Si vous retrouvez ce type de message juste avant qu’un site Web, une base de données ou un autre service devienne indisponible, l’OOM Killer est probablement directement impliqué.
Identifier les processus qui consomment le plus de mémoire
Pour afficher les processus classés par consommation de RAM :
ps aux --sort=-%mem | head -20
Vous pouvez également utiliser :
top
puis trier les processus par mémoire avec la touche M.
Cela permet d’identifier rapidement un processus dont la consommation augmente anormalement, par exemple php-fpm, mysqld, java, un serveur applicatif ou un script mal configuré.
Il faut toutefois rechercher la cause de la consommation excessive plutôt que simplement arrêter le processus concerné. Un OOM peut être provoqué par une fuite mémoire, trop de workers PHP-FPM, une base de données mal dimensionnée, une application trop gourmande, une absence de swap ou simplement une quantité de RAM insuffisante.
Si l’OOM Killer apparaît régulièrement dans les journaux, surveillez ensuite plus précisément les processus qui consomment le CPU et la mémoire, ainsi que la charge globale du système.
Identifier les processus qui consomment CPU et RAM
Une consommation excessive du processeur ou de la mémoire RAM peut fortement ralentir Linux, rendre un serveur difficilement accessible et, dans les cas extrêmes, provoquer l’arrêt de services ou le déclenchement de l’OOM Killer.
La première étape consiste donc à identifier les processus qui utilisent le plus de ressources.
Surveiller les processus avec top
La commande top affiche en temps réel l’utilisation du processeur, de la mémoire et les processus actifs :
top
Dans la liste des processus, surveillez principalement les colonnes suivantes :
Colonne
Description
PID
Identifiant du processus
USER
Utilisateur qui exécute le processus
%CPU
Pourcentage de processeur utilisé
%MEM
Pourcentage de mémoire RAM utilisé
RES
Quantité de mémoire physique actuellement utilisée par le processus
VIRT
Espace mémoire virtuel associé au processus
S
État actuel du processus
TIME+
Temps CPU total consommé par le processus
Dans top, vous pouvez notamment utiliser :
P pour classer les processus par consommation CPU.
M pour les classer par consommation mémoire.
1 pour afficher séparément l’activité de chaque cœur ou processeur logique.
q pour quitter.
Un processus qui reste durablement en tête avec une valeur %CPU ou %MEM élevée mérite d’être examiné.
Afficher les processus consommant le plus de CPU
Vous pouvez également obtenir directement les processus les plus gourmands en processeur avec ps :
ps aux --sort=-%cpu | head -20
Pour afficher seulement les informations essentielles :
ps -eo pid,user,comm,%cpu,%mem --sort=-%cpu | head -20
Cette commande est particulièrement pratique lorsqu’un serveur présente une charge CPU anormalement élevée.
Afficher les processus consommant le plus de RAM
Pour classer les processus selon leur consommation mémoire :
ps aux --sort=-%mem | head -20
Ou avec un affichage plus compact :
ps -eo pid,user,comm,%cpu,%mem,rss --sort=-%mem | head -20
La colonne RSS correspond approximativement à la quantité de mémoire physique actuellement occupée par le processus.
Sur un serveur Web, vous pouvez par exemple constater qu’un grand nombre de processus php-fpm, mysqld, mariadbd, Apache ou Java utilisent une part importante de la RAM.
Repérer les processus bloqués en attente d’I/O
Une forte charge système ne provient pas nécessairement d’une utilisation élevée du CPU. Des processus peuvent être bloqués en attente d’une opération d’entrée/sortie, notamment lorsqu’un disque ou un système de fichiers rencontre des problèmes.
Dans top, examinez la colonne S correspondant à l’état du processus.
Un processus avec l’état :
D
est en Uninterruptible Sleep, généralement parce qu’il attend la fin d’une opération d’I/O.
Quelques processus passant brièvement dans cet état ne sont pas forcément anormaux. En revanche, de nombreux processus durablement bloqués en état D peuvent indiquer un problème de disque, de stockage réseau (NFS), de système de fichiers ou de périphérique.
Dans ce cas, vérifiez les messages du noyau avec :
sudo dmesg -T
et :
sudo journalctl -k
Ne pas se limiter au processus qui consomme le plus
Un processus utilisant momentanément 100 % d’un cœur CPU n’indique pas nécessairement un problème. Une compression, une compilation, une sauvegarde ou une requête de base de données peut légitimement solliciter fortement le processeur pendant quelques secondes ou minutes.
Ce qui doit davantage attirer votre attention est une consommation élevée et persistante, notamment lorsqu’elle coïncide avec les ralentissements ou les blocages observés.
De même, si plusieurs processus d’un même service consomment beaucoup de ressources, recherchez la cause avant de simplement les terminer. Par exemple, de nombreux workers PHP-FPM fortement sollicités peuvent être la conséquence d’un trafic important, d’un script PHP lent, d’une requête SQL bloquée ou d’une mauvaise configuration du pool PHP-FPM.
L’étape suivante consiste alors à examiner la charge système (Load Average) afin de déterminer si le processeur est réellement saturé ou si les processus attendent principalement des ressources comme le disque.
Vérifier la charge système (Load Average)
Le Load Average permet d’évaluer la charge globale d’un système Linux. Il est particulièrement utile lorsqu’un PC ou un serveur devient lent, répond difficilement ou semble se bloquer alors que l’utilisation du processeur ne paraît pas forcément très élevée.
Vous pouvez afficher le Load Average avec la commande :
Les trois valeurs correspondent à la charge moyenne observée respectivement pendant les 1, 5 et 15 dernières minutes.
Vous retrouvez également ces valeurs en haut de l’écran avec :
top
Contrairement à une idée fréquente, le Load Average ne correspond pas directement au pourcentage d’utilisation du processeur. Il prend notamment en compte les tâches prêtes à être exécutées ainsi que certaines tâches bloquées en attente d’une ressource, notamment des opérations d’entrée/sortie (I/O).
Ainsi, un serveur peut présenter un Load Average très élevé avec un CPU relativement peu utilisé si de nombreux processus sont bloqués dans l’attente d’un disque, d’un stockage réseau ou d’un autre périphérique.
Interpréter le Load Average
Il faut comparer la charge au nombre de processeurs logiques disponibles.
Vous pouvez connaître ce nombre avec :
nproc
Par exemple, sur un système disposant de 8 CPU logiques :
Load Average
Interprétation
1
Charge faible
4
Environ la moitié de la capacité disponible est sollicitée
8
Les CPU sont globalement pleinement occupés
16
La demande dépasse fortement les ressources disponibles
Ces valeurs restent toutefois indicatives : un Load Average élevé ne signifie pas automatiquement que le processeur est saturé.
Déterminer si la charge vient du CPU ou des I/O
Commencez par examiner top.
Si le CPU est fortement utilisé et qu’un ou plusieurs processus présentent un %CPU élevé, recherchez le processus responsable.
En revanche, si le Load Average est élevé alors que le CPU reste relativement disponible, recherchez des processus en état D (Uninterruptible Sleep) :
De nombreux processus durablement en état D peuvent indiquer un problème d’I/O, par exemple :
Un disque dur ou SSD très lent ou défaillant.
Des erreurs du système de fichiers.
Un stockage NFS indisponible.
Un périphérique bloqué.
Une saturation importante des entrées/sorties.
Dans ce cas, vérifiez également les messages du noyau :
sudo dmesg -T
ainsi que les journaux :
sudo journalctl -k
Une augmentation brutale et persistante du Load Average constitue donc un indicateur important, mais il faut toujours rechercher ce qui provoque cette charge avant de conclure à un problème CPU.
Un disque ou une partition pleine peut provoquer des ralentissements, empêcher certains services de démarrer ou rendre Linux instable. C’est particulièrement problématique lorsque les partitions /, /var ou /tmp n’ont plus d’espace disponible.
Pour vérifier rapidement l’espace disque :
df -h
Surveillez la colonne Use% et recherchez les systèmes de fichiers proches de 100 % d’utilisation.
Vérifiez également les inodes, car une partition peut ne plus accepter de nouveaux fichiers alors qu’il reste encore de l’espace disque :
df -i
Si une partition est saturée, identifiez ensuite les répertoires et fichiers qui occupent le plus d’espace avant de poursuivre le diagnostic.
Même lorsqu’il reste de l’espace disque disponible, Linux peut devenir incapable de créer de nouveaux fichiers si tous les inodes sont utilisés. Ce problème peut notamment provoquer des erreurs d’écriture, empêcher la création de fichiers temporaires ou perturber certains services.
Pour vérifier l’utilisation des inodes :
df -i
Surveillez particulièrement les colonnes IUse% et IFree. Si IUse% atteint 100 %, le système de fichiers ne peut plus créer de nouveaux fichiers, même s’il dispose encore de plusieurs gigaoctets d’espace libre.
Ce problème est généralement provoqué par la présence d’un très grand nombre de petits fichiers, par exemple dans un répertoire de cache, de sessions PHP, de logs ou de fichiers temporaires.
Si les inodes sont saturés, recherchez les répertoires contenant un nombre anormalement élevé de fichiers avant de les nettoyer.
Un problème avec un service Linux peut parfois donner l’impression que le système entier est en panne. Sur un serveur, l’arrêt de Nginx, Apache, PHP-FPM, MariaDB/MySQL, SSH ou d’un autre service essentiel peut rendre un site ou une fonctionnalité inaccessible alors que Linux continue de fonctionner normalement.
Sur les distributions utilisant systemd, commencez par rechercher les services en échec :
systemctl --failed
Si un service apparaît avec l’état failed, vérifiez son état :
systemctl status nom-du-service
Puis consultez ses journaux :
sudo journalctl -u nom-du-service -e
Ces informations permettent généralement de déterminer si l’échec provient d’une erreur de configuration, d’un problème de permissions, d’une dépendance, d’un port déjà utilisé, d’un manque de ressources ou du plantage de l’application.
Pour aller plus loin et apprendre à diagnostiquer puis remettre en fonctionnement un service en échec :
Si les journaux ne permettent pas d’identifier clairement l’origine du plantage, il est recommandé de vérifier l’état du matériel du PC ou du serveur Linux. Une RAM instable, un SSD défaillant, une surchauffe ou des erreurs CPU/PCIe peuvent provoquer des blocages et des redémarrages difficiles à distinguer d’un problème logiciel.
Linux fournit de nombreux outils permettant de rechercher ces anomalies directement en ligne de commandes. Vous pouvez notamment contrôler :
La mémoire RAM et rechercher les erreurs EDAC.
Le processeur et les erreurs MCE (Machine Check Exception).
Les disques durs, SSD SATA et NVMe avec SMART et les journaux du noyau.
Les températures et le thermal throttling.
Les périphériques PCIe et les erreurs AER.
Les erreurs matérielles enregistrées par dmesg et journalctl.
Si les plantages sont aléatoires, accompagnés de Kernel Panic, segfault, I/O error, Hardware Error, MCE, erreurs PCIe ou de redémarrages inexpliqués, poursuivez le diagnostic avec le guide dédié :
Lorsqu’une application se termine brutalement avec une erreur de segmentation (segfault) ou un autre signal fatal, systemd peut enregistrer un core dump contenant des informations sur l’état du processus au moment du crash.
La commande coredumpctl permet de retrouver ces plantages et constitue un outil particulièrement utile lorsqu’un programme ou un service plante régulièrement sans explication apparente.
Pour afficher les crashs enregistrés :
coredumpctl list
Vous obtenez notamment le PID, le nom de l’exécutable, l’utilisateur, le signal ayant provoqué le crash et la date de l’événement.
Pour afficher les informations détaillées du dernier crash :
coredumpctl info
Vous pouvez également cibler un programme particulier :
coredumpctl info php-fpm
ou rechercher ses différents crashs :
coredumpctl list php-fpm
Portez particulièrement attention aux champs Signal, Executable, Command Line et aux éventuelles informations de pile d’appels. Un signal SIGSEGV indique par exemple une erreur de segmentation, souvent liée à un bug du programme, une bibliothèque ou une extension défectueuse, voire plus rarement à un problème matériel.
Pour analyser plus profondément un core dump avec GDB, utilisez :
coredumpctl debug
ou pour un programme particulier :
coredumpctl debug nom-du-programme
Cette analyse est surtout destinée aux utilisateurs avancés et aux développeurs, mais elle peut permettre d’identifier précisément la bibliothèque, l’extension ou la fonction dans laquelle le programme a planté.
Si coredumpctl ne retourne aucun résultat, cela ne signifie pas nécessairement qu’aucun programme n’a crashé : la collecte des core dumps peut être désactivée ou limitée par la configuration de systemd. Dans ce cas, recherchez également les messages segfault, core dumped ou SIGSEGV dans journalctl.
Vérifier si le problème est réellement réseau
Sur un serveur Linux administré à distance, une perte de connexion SSH ou l’indisponibilité d’un site Web ne signifie pas forcément que Linux a planté. Le système peut continuer à fonctionner normalement alors qu’un problème réseau empêche simplement d’y accéder.
Avant de rechercher une panne matérielle ou un Kernel Panic, vérifiez donc si le serveur répond toujours sur le réseau.
Depuis une autre machine, commencez par tester sa connectivité :
ping adresse-ip-du-serveur
L’absence de réponse au ping n’est toutefois pas une preuve de panne, car les requêtes ICMP peuvent être bloquées par le pare-feu.
Si vous disposez d’un accès local ou d’une console fournie par l’hébergeur, vérifiez l’état des interfaces réseau :
ip addr
Puis les routes configurées :
ip route
Vérifiez également que l’interface réseau est bien active :
ip link
Vérifier le service SSH
Si seul l’accès SSH ne fonctionne plus, contrôlez d’abord l’état du serveur SSH :
systemctl status ssh
Selon la distribution, le service peut également être nommé sshd :
systemctl status sshd
Consultez ensuite ses derniers événements :
journalctl -u ssh
ou :
journalctl -u sshd
Vérifier les ports en écoute
La commande ss permet de vérifier que les services attendus écoutent toujours sur leurs ports :
sudo ss -lntup
Par exemple, vous devez normalement retrouver le port 22 pour SSH, ainsi que les ports 80 et 443 pour un serveur Web.
Si le serveur répond au réseau mais qu’un port particulier n’est plus en écoute, le problème provient probablement du service concerné plutôt que d’un plantage de Linux.
Enfin, vérifiez les journaux du noyau à la recherche d’une perte de lien ou d’une erreur du pilote réseau :
Si le serveur reste accessible depuis une console locale ou la console de l’hébergeur, mais plus depuis Internet, concentrez le diagnostic sur l’interface réseau, le routage, le pare-feu, le service SSH et l’infrastructure réseau. Cela évite de rechercher inutilement un problème de CPU, RAM ou stockage alors que Linux fonctionne toujours correctement.
Que vérifier après un plantage Linux ?
Après un plantage, un blocage ou un redémarrage inattendu de Linux, il est préférable de suivre une méthode de diagnostic plutôt que de rechercher des erreurs au hasard. Commencez par les journaux du système et du noyau, puis vérifiez les ressources, le stockage et enfin le matériel.
Le tableau suivant récapitule les principales vérifications à effectuer.
Priorité
Vérification
Commande principale
Ce qu’il faut rechercher
1
Vérifier les derniers arrêts et redémarrages
last -x
Redémarrage sans arrêt normal, crash ou reboot inattendu
Processus gourmand, RAM insuffisante, swap fortement utilisé
7
Vérifier le Load Average
uptime
Charge anormalement élevée, saturation CPU ou attente d’I/O
8
Vérifier l’espace disque
df -h
Partition pleine, notamment /, /var ou /tmp
9
Vérifier les inodes
df -i
IUse% à 100 %, empêchant la création de nouveaux fichiers
10
Rechercher les erreurs de stockage et de système de fichiers
dmesg -T
I/O error, EXT4-fs error, XFS, Btrfs, NVMe, ATA
11
Vérifier l’état SMART
smartctl -a /dev/sda
Erreurs SMART, secteurs instables, erreurs NVMe
12
Rechercher les crashs d’applications
coredumpctl list
Segfault, SIGSEGV et processus ayant généré un core dump
13
Vérifier les températures
sensors
Surchauffe et thermal throttling
14
Rechercher les erreurs matérielles
journalctl -k
MCE, EDAC, Hardware Error, PCIe/AER
15
Tester la mémoire
Memtest86+
Erreurs de RAM ou instabilité mémoire
Le moment où vous effectuez le diagnostic est important. Après un plantage suivi d’un redémarrage, privilégiez les commandes utilisant -b -1, qui permettent d’examiner le démarrage précédent. Les journaux du démarrage actuel peuvent ne plus contenir les événements qui ont provoqué le crash.
Il faut également rechercher une corrélation entre plusieurs indices. Par exemple, des erreurs I/O error dans le journal du noyau, associées à des erreurs SMART et à des processus bloqués en état D, orientent fortement vers un problème de stockage. De même, des messages Out of memory suivis de Killed process permettent d’identifier un manque de mémoire plutôt qu’un véritable plantage du noyau.
Enfin, si un serveur est uniquement devenu inaccessible à distance, vérifiez d’abord le réseau, SSH et les services concernés. Une perte d’accès ne signifie pas nécessairement que Linux a planté.
Cette check-list permet ainsi de progresser du symptôme vers la cause, en distinguant un problème logiciel, un manque de ressources, une défaillance du stockage, une erreur du noyau ou une panne matérielle.
Lorsqu’un PC ou un serveur Linux plante, se bloque ou redémarre de manière inattendue, l’origine du problème peut être matérielle : mémoire RAM instable, disque dur ou SSD défaillant, surchauffe, erreur CPU, périphérique PCIe ou contrôleur de stockage.
Linux intègre de nombreux outils en ligne de commandes permettant d’identifier le matériel et de rechercher les signes d’une défaillance. Les journaux du noyau avec dmesg et journalctl peuvent révéler des erreurs matérielles, tandis que des outils comme smartctl, Memtest86+, sensors, lspci ou dmidecode permettent d’approfondir le diagnostic d’un composant particulier.
Dans ce guide, découvrez comment diagnostiquer le matériel sous Linux en ligne de commandes : identifier les composants, tester la mémoire RAM, vérifier la santé des disques et SSD, surveiller les températures et rechercher les erreurs CPU/MCE, EDAC, PCIe, SATA ou NVMe.
Si votre ordinateur ne démarre plus correctement ou si vous souhaitez effectuer les tests depuis un environnement indépendant du système installé, vous pouvez également utiliser un Live USB Ubuntu : Tester et faire un diagnostic matériel de son PC sur Ubuntu
C’est particulièrement utile parce que le titre promet du diagnostic en ligne de commandes : le lecteur doit pouvoir reproduire les commandes.
Identifier le matériel du PC ou serveur Linux
Avant de rechercher une panne matérielle, commencez par identifier précisément les composants détectés par Linux. Plusieurs commandes permettent d’obtenir rapidement des informations sur le processeur, la mémoire RAM, les périphériques PCI/PCIe, les périphériques USB et les disques.
Pour afficher les caractéristiques du processeur :
lscpu
La commande indique notamment le modèle du CPU, son architecture, le nombre de cœurs et de threads, les caches ainsi que les fonctions prises en charge.
Pour obtenir uniquement les informations principales :
Pour connaître la quantité de mémoire détectée par Linux :
lsmem
Vous pouvez compléter avec :
free -h
Pour obtenir des informations plus détaillées sur les barrettes de mémoire installées, utilisez dmidecode avec les droits administrateur :
sudo dmidecode --type memory
Vous pouvez ainsi retrouver, lorsque le BIOS/UEFI fournit ces informations, la capacité, le fabricant, la référence, la vitesse et l’emplacement de chaque barrette de RAM.
Identifier les périphériques PCI et PCIe
La commande lspci permet d’identifier les périphériques connectés aux bus PCI et PCI Express :
lspci
Vous pouvez notamment y retrouver :
La carte graphique.
La carte réseau Ethernet ou Wi-Fi.
Les contrôleurs SATA/NVMe.
Les contrôleurs USB.
Les cartes son.
Les autres cartes d’extension PCIe.
Pour afficher également le pilote du noyau utilisé par chaque périphérique :
lspci -k
Cette variante est particulièrement intéressante lors d’un diagnostic, car elle permet de vérifier quel pilote Linux prend en charge un composant.
Cette commande permet notamment de repérer les clés USB, disques externes, webcams, adaptateurs Bluetooth ou Wi-Fi et autres périphériques connectés en USB.
Si un périphérique n’apparaît pas dans lsusb, le problème peut se situer au niveau de la connexion, du port USB ou du matériel lui-même plutôt qu’au niveau de son pilote.
Cette étape permet surtout de déterminer quel périphérique examiner ensuite. Par exemple, après avoir identifié un SSD comme /dev/nvme0n1 ou un disque comme /dev/sda, vous pourrez consulter son état SMART et rechercher dans les journaux du noyau les éventuelles erreurs qui lui sont associées.
Rechercher les erreurs matérielles dans les journaux
Certaines instabilités ou certains plantages de Linux peuvent provenir directement du matériel : processeur, mémoire RAM, carte mère, bus PCIe ou contrôleur de stockage. Le noyau Linux peut détecter une partie de ces anomalies et les enregistrer dans ses journaux.
Commencez par rechercher les principales erreurs matérielles :
Erreur détectée par le processeur, pouvant concerner le CPU, la RAM ou d’autres composants
EDAC
Erreur liée à la détection/correction des erreurs mémoire, notamment avec de la RAM ECC
PCIe Bus Error
rreur signalée par le mécanisme PCIe Advanced Error Reporting
AER
Erreur signalée par le mécanisme PCIe Advanced Error Reporting
Corrected error
Erreur matérielle détectée puis corrigée, qui mérite une surveillance si elle se répète
Uncorrected / Fatal error
Erreur qui n’a pas pu être corrigée et peut provoquer une instabilité ou un plantage
Attention : la présence des termes AER, PCIe ou DPC dans les journaux ne signifie pas nécessairement qu’une erreur matérielle s’est produite. Certains messages indiquent simplement les fonctionnalités prises en charge ou activées par le matériel.
Une erreur corrigée isolée n’indique pas nécessairement qu’un composant est en panne. En revanche, des erreurs matérielles répétées, surtout lorsqu’elles apparaissent juste avant les blocages ou redémarrages, doivent être prises au sérieux.
Sur un serveur, vous pouvez également utiliser rasdaemon lorsqu’il est disponible. Cet outil collecte et facilite l’analyse des événements RAS (Reliability, Availability and Serviceability), notamment les erreurs mémoire, CPU et PCIe.
Enfin, les journaux Linux ne permettent pas de détecter toutes les pannes. Si les plantages restent inexpliqués, poursuivez le diagnostic en testant séparément la RAM, le stockage, les températures et, si possible, l’alimentation et les autres composants matériels.
Vérifier l’état SMART des disques
Un disque dur, SSD ou NVMe défaillant peut provoquer des erreurs d’entrée/sortie, des ralentissements importants, des blocages et parfois un plantage complet de Linux.
Avec smartmontools, vérifiez rapidement les données SMART du disque :
sudo smartctl -a /dev/sda
Pour un SSD NVMe :
sudo smartctl -a /dev/nvme0
Portez notamment attention à l’état SMART général, aux secteurs réalloués ou instables, aux erreurs non corrigibles, aux erreurs d’intégrité NVMe et à la température du disque.
Si dmesg ou journalctl signale parallèlement des I/O error, des erreurs ATA/NVMe ou des erreurs répétées du système de fichiers, une défaillance du stockage doit être sérieusement envisagée. Dans ce cas, sauvegardez les données importantes avant d’effectuer des tests ou des réparations supplémentaires.
Un système de fichiers endommagé peut provoquer des erreurs d’entrée/sortie, des fichiers inaccessibles, des blocages ou le passage d’une partition en lecture seule (read-only).
Commencez par rechercher les erreurs signalées par le noyau :
Si Linux a redémarré après le plantage, examinez plutôt le démarrage précédent :
sudo journalctl -k -b -1
Des messages tels que EXT4-fs error, I/O error, Buffer I/O error ou Read-only file system doivent attirer votre attention.
Si des erreurs de système de fichiers sont détectées, utilisez l’outil de réparation adapté (fsck, xfs_repair, outils Btrfs, etc.). N’exécutez pas fsck sur un système de fichiers monté en lecture/écriture, au risque d’aggraver les dommages.
Une mémoire RAM défectueuse ou instable peut provoquer des plantages difficiles à diagnostiquer : Kernel Panic, erreurs de segmentation (segfault), corruption de données, applications qui plantent aléatoirement ou redémarrages inexpliqués.
Commencez par rechercher les éventuelles erreurs mémoire détectées par le noyau Linux :
Les systèmes équipés de mémoire ECC peuvent également remonter des erreurs corrigées ou non corrigées par l’intermédiaire d’EDAC (Error Detection And Correction). Des erreurs EDAC répétées doivent être examinées, même si elles sont indiquées comme corrigées.
Tester la RAM avec Memtest86+
Les journaux Linux ne permettent pas de détecter toutes les erreurs de mémoire. Pour effectuer un véritable test de la RAM, utilisez Memtest86+, qui fonctionne indépendamment du système d’exploitation.
Redémarrez le PC ou le serveur et lancez Memtest86+ depuis GRUB lorsqu’il est disponible, ou depuis une clé USB bootable.
Laissez le test effectuer plusieurs passes complètes. Une seule erreur détectée est déjà anormale : une mémoire RAM fonctionnant correctement ne doit générer aucune erreur.
Si des erreurs apparaissent :
Désactivez temporairement tout overclocking du processeur ou de la mémoire.
Désactivez les profils XMP/EXPO et rétablissez les paramètres mémoire par défaut du BIOS/UEFI.
Si plusieurs barrettes sont installées, testez-les une par une.
Testez si nécessaire une même barrette dans différents emplacements mémoire afin d’écarter un problème de slot ou de carte mère.
Des erreurs mémoire ne signifient donc pas systématiquement qu’une barrette est physiquement défectueuse. Une fréquence trop élevée, des timings incorrects, une tension inadaptée ou un problème du contrôleur mémoire peuvent également provoquer une instabilité.
Si les plantages sont aléatoires et touchent des applications différentes, notamment avec des segfault, des Kernel Panic ou des fichiers qui se corrompent sans cause évidente, un test approfondi de la RAM fait partie des vérifications matérielles prioritaires.
Vous pouvez aussi utiliser Memtest86, plus de détails:
Une surchauffe du processeur, du GPU ou d’un autre composant peut provoquer des ralentissements, du thermal throttling, des blocages et, dans les cas les plus sévères, un arrêt ou un redémarrage de sécurité du système.
Sous Linux, vous pouvez surveiller les températures avec le paquet lm-sensors. Une fois installé et configuré, exécutez :
sensors
Pour surveiller les températures en continu :
watch -n 2 sensors
Observez particulièrement les températures du CPU, de la carte mère et, lorsqu’elles sont disponibles, celles du GPU et des SSD NVMe. Une température élevée n’indique pas nécessairement une panne : il faut surtout rechercher une température qui atteint régulièrement la limite critique du composant ou qui coïncide avec les blocages.
Vous pouvez également rechercher dans les messages du noyau les événements liés à une surchauffe ou à une limitation thermique :
Des messages faisant référence à thermal throttling, critical temperature ou à une température dépassant un seuil critique peuvent orienter vers un problème de refroidissement.
Dans ce cas, vérifiez notamment l’état des ventilateurs, l’accumulation de poussière, le radiateur et le système de refroidissement. Sur une machine ancienne, une pâte thermique dégradée peut également entraîner une augmentation importante des températures.
Enfin, gardez à l’esprit qu’un arrêt thermique brutal peut ne pas laisser de message exploitable dans les journaux, le système pouvant s’éteindre avant que l’événement soit écrit sur le disque.
Vérifier les erreurs CPU et Machine Check Exception
Le processeur peut détecter certaines erreurs matérielles et les signaler au noyau Linux par l’intermédiaire du mécanisme Machine Check Exception (MCE). Ces erreurs peuvent concerner directement le CPU, mais également les caches, le contrôleur mémoire, la RAM ou les communications avec d’autres composants.
Des erreurs MCE répétées peuvent provoquer des Kernel Panic, des blocages, des redémarrages ou des erreurs applicatives aléatoires.
Pour rechercher les erreurs matérielles enregistrées par le noyau :
Un message peut par exemple contenir Machine check events logged, MCE, Hardware Error, Corrected error ou Uncorrected error.
Toutes les erreurs MCE ne provoquent pas nécessairement un plantage. Une erreur corrigée (Corrected Error) a été détectée et récupérée par le matériel. Une occurrence isolée n’indique pas forcément une panne, mais des erreurs corrigées qui se répètent doivent être surveillées.
À l’inverse, une Uncorrected Error ou une erreur indiquée comme Fatal est plus préoccupante et peut être directement responsable d’un plantage.
Vérifiez si une mise à jour du BIOS/UEFI est disponible.
Recherchez une éventuelle instabilité du CPU, de la RAM ou de la carte mère.
Sur un serveur, des outils comme rasdaemon peuvent également faciliter la collecte et l’analyse des erreurs matérielles remontées par le processeur, la mémoire et les mécanismes RAS.
Enfin, une Machine Check Exception ne signifie pas automatiquement que le processeur est défectueux. Le CPU est souvent le composant qui détecte et signale l’erreur, alors que sa véritable origine peut être la RAM, le contrôleur mémoire, la carte mère ou une configuration matérielle instable.
Vérifier les erreurs PCIe et périphériques
Les périphériques connectés au bus PCI Express (PCIe) peuvent également être à l’origine de plantages ou d’instabilités sous Linux. Cela concerne notamment les cartes graphiques, cartes réseau, contrôleurs NVMe, cartes RAID et autres cartes d’extension.
Linux peut signaler ces problèmes grâce au mécanisme AER (Advanced Error Reporting) de PCI Express.
Pour rechercher les erreurs PCIe enregistrées par le noyau :
Les messages peuvent notamment contenir PCIe Bus Error, AER, Corrected error, Uncorrected error ou Fatal error.
Message
Signification
Gravité / action
AER enabled with IRQ…
Le mécanisme PCIe Advanced Error Reporting est activé pour ce port.
Informatif, ce n’est pas une erreur.
DPC error containment capabilities…
Affiche les capacités Downstream Port Containment permettant d’isoler certaines erreurs PCIe.
Informatif, ce n’est pas une erreur.
Slot(…): Card present
Un périphérique est détecté dans un slot PCIe Hot Plug.
Informatif.
Signaling PME with IRQ…
Configuration de la gestion d’énergie PCIe (Power Management Event).
Informatif.
Failed to check link status
Le pilote pciehp n’a pas réussi à déterminer l’état de la liaison PCIe.
À surveiller si le message se répète ou si un périphérique disparaît/ne fonctionne pas.
Data Link Layer Link Active not set…
La couche liaison PCIe n’est pas passée à l’état actif dans le délai attendu.
Peut accompagner un problème d’établissement de la liaison. À surveiller si répété.
PCIe Bus Error: severity=Corrected
Une erreur PCIe a été détectée puis corrigée par le matériel/AER.
Généralement non critique si occasionnelle ; à surveiller si répétée.
PCIe Bus Error: severity=Uncorrected
Une erreur PCIe n’a pas pu être corrigée.
Anormal, identifier le périphérique concerné.
severity=Fatal
Erreur PCIe fatale.
Critique, peut entraîner la perte du périphérique ou un plantage.
Link down / link is down
La liaison avec le périphérique PCIe a été perdue.
Vérifier périphérique, slot, alimentation et pilote.
timeout
Le périphérique n’a pas répondu dans le délai prévu.
Rechercher d’autres erreurs autour du même périphérique.
reset / resetting
Linux tente de réinitialiser le périphérique après un problème.
À surveiller si les resets sont répétés.
Notez que certaines « error » peuvent être seulement informatives.
Pour identifier les périphériques PCI/PCIe présents sur la machine :
lspci
Pour afficher également le pilote du noyau associé à chaque périphérique :
lspci -k
Lorsqu’un identifiant PCI apparaît dans les journaux, par exemple 0000:03:00.0, vous pouvez identifier précisément le périphérique concerné avec :
lspci -s 03:00.0 -k
Cela permet de déterminer rapidement si l’erreur concerne, par exemple, une carte graphique, un contrôleur NVMe ou une carte réseau.
Des erreurs PCIe répétées peuvent provenir du périphérique lui-même, de son pilote, d’un mauvais contact dans le connecteur PCIe, du BIOS/UEFI, de la carte mère ou parfois de l’alimentation. Sur un PC fixe, si le problème concerne une carte d’extension, vérifiez également qu’elle est correctement insérée dans son slot et que ses éventuels connecteurs d’alimentation sont correctement branchés.
Une erreur AER corrigée et occasionnelle n’est pas nécessairement synonyme de panne. En revanche, une accumulation d’erreurs, des Uncorrected/Fatal errors, des resets répétés ou la disparition d’un périphérique doivent conduire à approfondir le diagnostic.
Vérifier les périphériques de stockage NVMe/SATA
Un SSD NVMe, un disque SATA ou son contrôleur peut être à l’origine de blocages, de ralentissements importants, de systèmes de fichiers passant en lecture seule ou de plantages de Linux. Avant même que SMART ne signale une panne, le noyau peut enregistrer des timeouts, resets et erreurs d’entrée/sortie (I/O).
Commencez par identifier les périphériques de stockage :
Portez notamment attention aux messages suivants :
Message
Cause possible
I/O error
Échec d’une opération de lecture ou d’écriture
Buffer I/O error
Erreur d’accès au périphérique de stockage
ataX: hard resetting link
Linux tente de réinitialiser une liaison SATA en erreur
SATA link down
Perte de communication avec le périphérique SATA
failed command
Commande ATA/SATA ayant échoué
timeout
SSD ou disque n’ayant pas répondu dans le délai attendu
nvme reset controller
Réinitialisation du contrôleur NVMe après un problème
I/O timeout
Opération d’entrée/sortie ayant dépassé le délai prévu
Sur un disque SATA, des erreurs répétées ne signifient pas nécessairement que le disque est défectueux. Un câble SATA endommagé ou mal connecté, un connecteur d’alimentation ou un contrôleur SATA peut également être responsable.
Sur un SSD NVMe, des timeouts ou resets répétés peuvent provenir du SSD, de son firmware, du contrôleur PCIe, d’une surchauffe ou d’un problème de gestion de l’énergie.
Si vous détectez ce type d’erreur, vérifiez ensuite l’état SMART du disque ou du SSD avec smartctl. En présence d’erreurs I/O répétées ou d’un état SMART dégradé, sauvegardez les données importantes avant de poursuivre les tests.
Tableau des commandes de diagnostic matériel Linux
Le tableau suivant récapitule les principales commandes permettant d’identifier le matériel et rechercher une panne sous Linux. Elles constituent une bonne base de diagnostic avant de passer à des tests plus approfondis.
Composant / vérification
Commande
Utilité
Processeur (CPU)
lscpu
Afficher le modèle, l’architecture, les cœurs, threads et caractéristiques du processeur
Mémoire RAM
lsmem
Afficher l’organisation et la quantité de mémoire détectée
Utilisation de la RAM
free -h
Vérifier la mémoire disponible, utilisée et le swap
Barrettes de RAM
sudo dmidecode --type memory
Afficher les caractéristiques des barrettes (capacité, vitesse, fabricant, emplacement)
Test de la RAM
Memtest86+
Détecter les erreurs et instabilités de la mémoire RAM
Périphériques PCI/PCIe
lspci
Identifier les cartes graphiques, réseau, contrôleurs et cartes d’extension
Pilotes PCI/PCIe
lspci -k
Identifier le pilote du noyau utilisé par chaque périphérique
Périphériques USB
lsusb
Lister les périphériques USB détectés
Disques et SSD
lsblk
Identifier les disques, SSD, partitions et points de montage
État SMART
sudo smartctl -a /dev/sda
Vérifier l’état de santé d’un disque SATA
État SMART NVMe
sudo smartctl -a /dev/nvme0
Vérifier la santé et les erreurs d’un SSD NVMe
Températures
sensors
Afficher les températures et autres capteurs matériels
Surveillance des températures
watch -n 2 sensors
Surveiller les températures en temps réel
Messages du noyau
sudo dmesg -T
Rechercher les erreurs matérielles, pilotes, stockage et périphériques
Journal du noyau
sudo journalctl -k
Consulter les événements matériels enregistrés par le noyau
Démarrage précédent
sudo journalctl -k -b -1
Rechercher une erreur matérielle ayant précédé un plantage ou redémarrage
Rechercher les erreurs de système de fichiers et d’entrée/sortie
Erreurs RAS
ras-mc-ctl --errors
Consulter les erreurs matérielles collectées par rasdaemon
Il n’existe pas de commande unique permettant de conclure qu’un composant est défectueux. Il faut généralement croiser plusieurs indices. Par exemple, des erreurs I/O error dans journalctl, des resets NVMe répétés et des erreurs SMART sur le même SSD constituent un faisceau d’indices beaucoup plus significatif qu’un message isolé.
De même, après un plantage suivi d’un redémarrage, pensez à examiner le démarrage précédent avec journalctl -k -b -1 : les journaux du démarrage actuel peuvent ne plus montrer les événements qui ont précédé la panne.
Surveiller les erreurs matérielles dans le temps avec rasdaemon
Pour aller plus loin dans le diagnostic, notamment sur un serveur Linux fonctionnant en continu, vous pouvez utiliser rasdaemon. Cet outil collecte et conserve un historique des événements RAS (Reliability, Availability and Serviceability) remontés par le noyau Linux.
Il permet notamment de surveiller certaines erreurs mémoire ECC/EDAC, Machine Check Events (MCE) et erreurs PCIe/AER afin de déterminer si elles sont isolées ou si elles se répètent et deviennent plus fréquentes avec le temps. Cette surveillance peut aider à détecter la dégradation progressive d’un composant avant qu’elle ne provoque une panne plus importante.
Contrairement à Memtest86+ ou aux autotests SMART, rasdaemon ne teste pas directement le matériel : il enregistre les erreurs détectées pendant le fonctionnement normal du système.
Les serveurs et stations de travail Linux disposent de mécanismes permettant de détecter et signaler certaines erreurs matérielles avant qu’elles ne provoquent nécessairement une panne. Une erreur mémoire ECC corrigée, une Machine Check Exception (MCE) ou une erreur PCIe/AER peut ainsi être enregistrée alors que le système continue à fonctionner normalement.
rasdaemon est un outil Linux dédié à la collecte et à la surveillance de ces événements RAS (Reliability, Availability and Serviceability). Associé à ras-mc-ctl, il permet de conserver un historique des erreurs matérielles, d’afficher leur détail et surtout de déterminer si elles se répètent ou deviennent plus fréquentes avec le temps.
Dans ce guide, découvrez comment installer et configurer rasdaemon sous Linux, enregistrer les événements RAS et utiliser ras-mc-ctl pour surveiller les erreurs mémoire ECC/EDAC, MCE et PCIe/AER. Vous apprendrez également à distinguer les erreurs Corrected, Uncorrected et Fatal et à mettre en place une surveillance régulière du matériel d’un serveur.
rasdaemon est un outil Linux destiné à collecter, enregistrer et faciliter l’analyse des erreurs matérielles remontées par le noyau. Il est principalement utilisé sur les serveurs et les stations de travail pour surveiller la fiabilité du matériel et détecter des anomalies qui peuvent passer inaperçues tant qu’elles restent corrigibles.
Son nom fait référence à RAS (Reliability, Availability and Serviceability), que l’on peut traduire par fiabilité, disponibilité et facilité de maintenance. Il s’agit d’un ensemble de mécanismes matériels et logiciels permettant de détecter, signaler et parfois corriger des erreurs sans provoquer immédiatement l’arrêt du système.
Selon le matériel et les mécanismes pris en charge par le noyau, rasdaemon peut notamment collecter des événements concernant :
La mémoire RAM ECC et EDAC (Error Detection And Correction).
Les erreurs processeur et Machine Check Events (MCE).
Les erreurs du bus PCI Express (PCIe/AER).
Certaines erreurs liées au stockage ou à d’autres composants disposant de mécanismes RAS.
Le noyau Linux peut déjà afficher ce type d’informations dans dmesg ou journalctl. L’intérêt de rasdaemon est de permettre une collecte structurée et persistante des événements, afin de suivre leur évolution dans le temps.
Par exemple, une mémoire ECC peut détecter et corriger automatiquement une erreur sans provoquer de plantage. Le serveur continue donc à fonctionner normalement. Si ce type d’erreur commence toutefois à se répéter régulièrement sur une même barrette, cela peut constituer le signe d’une dégradation matérielle.
Il est donc important de distinguer plusieurs niveaux d’erreurs :
Type d’erreur
Signification
Corrected / Correctable
L’erreur a été détectée et corrigée. Le système peut continuer à fonctionner, mais des occurrences répétées doivent être surveillées.
Uncorrected / Uncorrectable
L’erreur n’a pas pu être corrigée automatiquement et peut provoquer une corruption de données ou une instabilité.
Fatal
Erreur grave pouvant entraîner la perte d’un périphérique, un Kernel Panic ou un arrêt du système.
rasdaemon n’est donc pas un outil de test matériel comparable à Memtest86+ ou à un autotest SMART. Il ne sollicite pas volontairement les composants pour rechercher une panne. Son rôle est plutôt de surveiller et enregistrer les erreurs matérielles détectées pendant le fonctionnement normal de Linux.
Il est particulièrement intéressant sur un serveur fonctionnant 24 h/24, car il permet de repérer une augmentation progressive des erreurs corrigées avant qu’elles ne se transforment éventuellement en panne plus importante.
Dans la suite de ce guide, nous allons voir comment installer rasdaemon, activer la collecte des événements RAS et analyser les erreurs enregistrées avec ras-mc-ctl.
Installer rasdaemon
Le paquet rasdaemon est disponible dans les dépôts de nombreuses distributions Linux. Son installation nécessite les droits administrateur.
Sur Debian et Ubuntu, utilisez :
sudo apt update
sudo apt install rasdaemon
Sur Fedora :
sudo dnf install rasdaemon
Sur RHEL, Rocky Linux ou AlmaLinux, recherchez d’abord si le paquet est disponible dans les dépôts activés :
dnf search rasdaemon
Puis, s’il est disponible :
sudo dnf install rasdaemon
Selon la version de la distribution, l’activation d’un dépôt supplémentaire peut être nécessaire.
Sur Arch Linux :
sudo pacman -S rasdaemon
Une fois l’installation terminée, vérifiez que l’exécutable est disponible :
rasdaemon --version
Vous pouvez également afficher les options prises en charge :
rasdaemon --help
Le paquet installe généralement deux outils importants :
rasdaemon : le démon chargé de collecter les événements RAS remontés par le noyau.
ras-mc-ctl : l’utilitaire permettant notamment de consulter les erreurs et informations collectées.
Vous pouvez vérifier leur présence avec :
command -v rasdaemon
command -v ras-mc-ctl
L’installation du paquet ne garantit toutefois pas que tous les types d’erreurs matérielles pourront être surveillés. Les informations disponibles dépendent du processeur, de la carte mère, de la mémoire ECC éventuelle, des pilotes et des mécanismes RAS pris en charge par le noyau Linux.
Après l’installation, l’étape suivante consiste donc à activer et démarrer le service rasdaemon, puis à vérifier que la collecte des événements fonctionne correctement.
Activer et démarrer rasdaemon
Une fois rasdaemon installé, vérifiez que son service systemd est activé et en cours d’exécution. Le démon pourra ainsi surveiller les événements RAS remontés par le noyau Linux pendant le fonctionnement de la machine.
Pour démarrer rasdaemon et l’activer automatiquement au démarrage de Linux :
sudo systemctl enable --now rasdaemon
L’option --now permet d’effectuer les deux opérations en une seule commande : activer le service au démarrage et le lancer immédiatement.
Vérifiez ensuite son état :
systemctl status rasdaemon
Si le service fonctionne correctement, vous devez notamment obtenir un état similaire à :
Active: active (running)
Vous pouvez également vérifier simplement s’il est actif :
Pour vérifier le démarrage du démon et rechercher d’éventuelles erreurs :
sudo journalctl -u rasdaemon -e
Pour suivre ses événements en temps réel :
sudo journalctl -u rasdaemon -f
Si le service refuse de démarrer, affichez son état détaillé et ses derniers journaux :
systemctl status rasdaemon
sudo journalctl -u rasdaemon -e
Les fonctionnalités réellement disponibles dépendent du matériel, du noyau Linux et des mécanismes RAS pris en charge par la machine. L’absence de certains types d’événements ne signifie donc pas nécessairement que rasdaemon fonctionne mal.
Une fois le service actif, l’étape suivante consiste à vérifier que rasdaemon collecte correctement les événements matériels et, si nécessaire, à activer leur enregistrement persistant.
Pour exploiter pleinement rasdaemon, il est recommandé d’activer l’enregistrement persistant des événements RAS. Cela permet de conserver un historique des erreurs matérielles détectées et de les consulter ultérieurement avec ras-mc-ctl.
Cette fonction est particulièrement utile sur un serveur : elle permet de déterminer si des erreurs mémoire ECC, MCE ou PCIe/AER apparaissent régulièrement ou si leur nombre augmente avec le temps.
Pour activer l’enregistrement des événements, utilisez :
sudo rasdaemon --record
L’option --record demande à rasdaemon d’enregistrer les événements collectés dans une base de données SQLite.
Toutefois, si rasdaemon fonctionne déjà comme service systemd, ne lancez pas immédiatement cette commande, car l’enregistrement peut déjà être activé par le service.
Commencez par vérifier sa configuration :
systemctl cat rasdaemon
Recherchez la directive ExecStart. Si celle-ci contient l’option --record, l’enregistrement persistant est déjà activé et aucune modification supplémentaire n’est nécessaire.
Vous pouvez également vérifier la ligne de commande du processus en cours :
ps -ef | grep '[r]asdaemon'
Afficher un résumé des erreurs avec ras-mc-ctl
Une fois rasdaemon actif et l’enregistrement des événements configuré, la commande ras-mc-ctl permet de consulter les erreurs matérielles collectées.
Pour obtenir une vue d’ensemble, utilisez :
sudo ras-mc-ctl --summary
Cette commande affiche un résumé des événements RAS enregistrés dans la base de rasdaemon. Selon le matériel, le noyau et les mécanismes pris en charge par votre machine, vous pouvez notamment retrouver des compteurs liés à :
La mémoire et EDAC.
Les erreurs Machine Check (MCE).
Les erreurs PCIe/AER.
Les erreurs matérielles corrigées ou non corrigées.
D’autres événements RAS pris en charge par le système.
Si aucun problème matériel n’a été détecté, les compteurs concernés restent à 0 ou ras-mc-ctl indique qu’aucune erreur n’a été enregistrée. C’est un résultat normal.
Interpréter les résultats
Il est surtout important de surveiller l’évolution des compteurs dans le temps plutôt qu’une valeur isolée.
Situation
Interprétation
Aucune erreur
Aucun événement matériel pris en charge n’a été enregistré
Une erreur corrigée isolée
À surveiller, mais ne signifie pas nécessairement qu’un composant est défectueux
Erreurs corrigées qui augmentent régulièrement
Peut indiquer une dégradation ou une instabilité matérielle
Erreurs non corrigées
Anomalie plus sérieuse nécessitant d’identifier le composant concerné
Erreurs fatales
Peuvent provoquer un plantage, un Kernel Panic ou la perte d’un périphérique
Par exemple, sur un serveur équipé de mémoire ECC, quelques erreurs corrigées doivent être surveillées. Si leur nombre augmente régulièrement et qu’elles concernent toujours le même module mémoire, il devient pertinent de vérifier la barrette, son emplacement et la configuration mémoire.
De même, des erreurs PCIe/AER répétées peuvent conduire à examiner le périphérique PCIe concerné, son pilote, le slot, le BIOS/UEFI ou son alimentation.
Vous pouvez relancer périodiquement :
sudo ras-mc-ctl --summary
afin de vérifier si les compteurs évoluent.
Le résumé permet ainsi d’obtenir rapidement une vue générale de la santé matérielle remontée par les mécanismes RAS. Si des erreurs apparaissent, utilisez ensuite les fonctions détaillées de ras-mc-ctl ainsi que journalctl pour identifier plus précisément leur origine.
Surveiller les erreurs mémoire ECC et EDAC
Sur les serveurs et stations de travail équipés de mémoire ECC (Error-Correcting Code), le contrôleur mémoire peut détecter et, dans certains cas, corriger automatiquement les erreurs de mémoire. Sous Linux, ces événements peuvent être remontés par le sous-système EDAC (Error Detection And Correction) et collectés par rasdaemon.
La surveillance de ces erreurs est particulièrement intéressante sur un serveur : une barrette peut commencer à générer des erreurs corrigées tout en continuant à fonctionner normalement. Une augmentation progressive de leur nombre peut alors constituer un signe précurseur d’une défaillance mémoire.
Pour afficher un résumé des erreurs enregistrées :
sudo ras-mc-ctl --summary
Pour obtenir le détail des événements :
sudo ras-mc-ctl --errors
Vous pouvez également rechercher les événements EDAC directement dans les journaux du noyau :
Dans les événements mémoire, vous pouvez notamment rencontrer les termes CE et UE :
Type
Signification
Action
CE – Corrected Error
L’erreur mémoire a été détectée et corrigée par le mécanisme ECC.
Surveiller son évolution et le composant concerné.
UE – Uncorrected Error
L’erreur n’a pas pu être corrigée.
À prendre au sérieux : risque d’instabilité, de corruption ou de plantage.
Erreurs CE répétées
Les erreurs corrigées s’accumulent, éventuellement sur le même module.
Identifier le DIMM concerné et envisager son remplacement.
Une erreur corrigée isolée ne signifie pas nécessairement qu’une barrette de RAM est défectueuse. En revanche, si les erreurs CE augmentent régulièrement, particulièrement sur le même module ou canal mémoire, une investigation matérielle devient nécessaire.
Identifier la barrette mémoire concernée
Lorsque le matériel et le pilote EDAC fournissent suffisamment d’informations, les événements peuvent permettre d’identifier un DIMM, un canal ou un contrôleur mémoire particulier.
Vous pouvez comparer ces informations avec la configuration physique de la mémoire :
sudo dmidecode --type memory
Cette commande permet notamment d’afficher les emplacements mémoire (Locator), la capacité et, selon le matériel, le fabricant et la référence des barrettes.
Si rasdaemon ou EDAC désigne par exemple un emplacement DIMM_A1, DIMM_B2 ou un canal précis, recherchez l’emplacement correspondant dans dmidecode et dans la documentation de la carte mère ou du serveur.
Si les erreurs mémoire deviennent récurrentes, complétez le diagnostic avec un test de la RAM, par exemple Memtest86+, et vérifiez également les paramètres mémoire du BIOS/UEFI. Un overclocking, un profil XMP/EXPO ou une configuration mémoire instable peut également provoquer des erreurs sans que la barrette soit nécessairement défectueuse.
Analyser les Machine Check Events (MCE)
Les Machine Check Events (MCE) correspondent à des erreurs matérielles détectées par le processeur grâce à son mécanisme Machine Check Architecture (MCA). Contrairement à ce que leur nom peut laisser penser, une erreur MCE ne signifie pas nécessairement que le CPU est défectueux : le processeur peut signaler une anomalie provenant de la mémoire RAM, des caches, du contrôleur mémoire, de la carte mère ou d’autres composants.
rasdaemon permet de collecter ces événements et de conserver leur historique afin d’identifier les erreurs qui se répètent.
Commencez par afficher le résumé des événements enregistrés :
sudo ras-mc-ctl --summary
Puis consultez les erreurs détaillées :
sudo ras-mc-ctl --errors
Vous pouvez compléter cette analyse avec les messages du noyau :
Une erreur MCE peut être corrigée, non corrigée ou fatale. Son niveau de gravité et sa répétition sont donc plus importants que la simple présence du terme MCE.
Type d’événement
Signification
Action
Corrected / Correctable
Le matériel a détecté puis corrigé l’erreur.
Surveiller si elle se répète.
Uncorrected / Uncorrectable
L’erreur n’a pas pu être corrigée.
Rechercher rapidement le composant concerné.
Fatal
L’erreur empêche le système de continuer normalement.
Peut être directement liée à un Kernel Panic ou un redémarrage.
Erreurs répétées sur le même composant
Une anomalie matérielle ou une instabilité devient probable.
Approfondir le diagnostic du composant concerné.
Une erreur corrigée isolée n’indique donc pas nécessairement une panne. En revanche, des événements MCE qui apparaissent régulièrement ou dont la fréquence augmente doivent être pris au sérieux.
Rechercher l’origine d’une erreur MCE
Lorsqu’une erreur MCE est enregistrée, recherchez les informations permettant d’identifier sa provenance. Selon le processeur et le matériel, les événements peuvent notamment faire référence :
Au CPU ou à un cœur particulier.
Aux caches L1, L2 ou L3.
Au contrôleur mémoire.
À un canal ou une barrette de RAM.
À une erreur de bus ou d’interconnexion.
Il faut ensuite croiser ces informations avec les autres événements RAS. Par exemple, des MCE associées à des erreurs EDAC/ECC sur le même canal mémoire orientent davantage vers la RAM ou le contrôleur mémoire que vers une défaillance du processeur lui-même.
Si les erreurs MCE se répètent :
Désactivez tout overclocking ou undervolting.
Rétablissez temporairement les paramètres par défaut du BIOS/UEFI.
Désactivez les profils mémoire XMP/EXPO pour effectuer un test.
Vérifiez les températures du processeur.
Testez la mémoire RAM.
Vérifiez si une mise à jour du BIOS/UEFI ou du microcode CPU est disponible.
Recherchez si les événements concernent toujours le même CPU, cœur, cache ou canal mémoire.
L’intérêt de rasdaemon est ici de conserver un historique : plutôt que d’analyser uniquement une erreur ponctuelle dans dmesg, vous pouvez déterminer si les Machine Check Events se répètent ou deviennent plus fréquents, ce qui constitue un indicateur beaucoup plus pertinent d’une éventuelle dégradation matérielle.
Surveiller les erreurs PCIe/AER
Le bus PCI Express (PCIe) dispose d’un mécanisme appelé AER (Advanced Error Reporting) permettant de détecter et de signaler certaines erreurs de communication entre le processeur, le chipset et les périphériques PCIe.
Ces erreurs peuvent concerner de nombreux composants : carte graphique, SSD NVMe, carte réseau, contrôleur RAID, carte HBA ou tout autre périphérique connecté en PCI Express.
Avec rasdaemon, vous pouvez conserver un historique de ces événements afin de déterminer s’ils sont isolés ou s’ils se répètent sur le même périphérique.
Commencez par afficher le résumé des événements enregistrés :
sudo ras-mc-ctl --summary
Puis consultez les erreurs détaillées :
sudo ras-mc-ctl --errors
Vous pouvez compléter le diagnostic en recherchant les erreurs PCIe dans les journaux du noyau :
Toutes les lignes contenant les termes PCIe, AER ou DPC ne correspondent pas à une erreur. Linux affiche également de nombreux messages informatifs lors de l’initialisation du matériel.
Message
Signification
Action
AER enabled with IRQ…
Le mécanisme Advanced Error Reporting est activé.
Informatif, aucune action nécessaire.
DPC error containment capabilities…
Le port indique ses capacités Downstream Port Containment.
Informatif, ce n’est pas une erreur détectée.
Slot(…): Card present
Un périphérique est présent dans le slot PCIe.
Informatif.
PCIe Bus Error: severity=Corrected
Une erreur a été détectée puis corrigée.
À surveiller si elle devient fréquente.
PCIe Bus Error: severity=Uncorrected
L’erreur n’a pas pu être corrigée.
Identifier le périphérique et approfondir le diagnostic.
severity=Fatal
Erreur PCIe grave.
Peut provoquer la perte du périphérique ou un plantage.
Failed to check link status
Le pilote n’a pas réussi à vérifier correctement l’état de la liaison PCIe.
À surveiller si le message se répète ou accompagne la disparition d’un périphérique.
Data Link Layer Link Active not set
La liaison PCIe n’est pas devenue active dans le délai prévu.
Rechercher d’autres erreurs concernant le même port.
Link down
La liaison PCIe avec le périphérique a été perdue.
Vérifier le périphérique, le slot, l’alimentation et le pilote.
timeout / reset
Le périphérique ne répond plus correctement et peut avoir été réinitialisé.
À investiguer si les événements sont répétés.
Cette distinction est importante : une simple ligne AER enabled ne signifie pas qu’une erreur PCIe s’est produite.
Identifier le périphérique PCIe concerné
Les événements PCIe contiennent généralement une adresse permettant d’identifier le périphérique ou le port concerné, par exemple :
0000:03:00.0
Pour identifier ce périphérique :
lspci -s 03:00.0 -k
La commande affiche le composant ainsi que le pilote du noyau utilisé.
Vous pouvez ensuite rechercher tous les événements concernant cette adresse PCIe :
sudo journalctl -k | grep -i "03:00.0"
Cela permet de déterminer si les erreurs concernent systématiquement le même périphérique ou la même liaison PCIe.
Surveiller surtout la répétition des erreurs
Comme pour les erreurs ECC ou MCE, une erreur PCIe corrigée isolée n’indique pas nécessairement une panne matérielle. En revanche, des centaines ou milliers d’erreurs corrigées, des erreurs Uncorrected/Fatal, des pertes de liaison ou des resets répétés doivent être examinés.
Selon le périphérique concerné, vérifiez alors :
Le pilote Linux et le firmware du périphérique.
Le BIOS/UEFI de la carte mère.
Le branchement et le slot PCIe sur un PC ou serveur permettant cette vérification.
L’alimentation du périphérique.
Les températures.
Pour un SSD NVMe, son état SMART et ses propres journaux d’erreurs.
L’intérêt de rasdaemon est surtout de pouvoir déterminer si ces événements s’accumulent au fil des jours ou des semaines. Une augmentation régulière des erreurs sur la même adresse PCIe constitue un indice beaucoup plus significatif qu’un événement isolé observé au démarrage.
Mettre en place une surveillance régulière sur un serveur
Sur un serveur fonctionnant en continu, l’intérêt de rasdaemon est surtout de pouvoir suivre l’évolution des erreurs matérielles dans le temps. Une erreur corrigée isolée peut être sans conséquence, tandis qu’une augmentation régulière des erreurs ECC/EDAC, MCE ou PCIe/AER peut révéler une dégradation progressive d’un composant.
Commencez par vérifier périodiquement le résumé des événements :
sudo ras-mc-ctl --summary
Puis, si de nouvelles erreurs apparaissent, consultez leur détail :
sudo ras-mc-ctl --errors
Vous pouvez également vérifier les événements récents du noyau :
Enregistrez le fichier puis rendez-le exécutable :
sudo chmod 750 /usr/local/sbin/check-ras.sh
Testez-le manuellement :
sudo /usr/local/sbin/check-ras.sh
Puis vérifiez le résultat :
sudo tail -50 /var/log/ras-monitor.log
Exécuter automatiquement la vérification
Vous pouvez ensuite exécuter ce script régulièrement avec cron ou un timer systemd. Pour une simple surveillance matérielle, une vérification quotidienne est généralement suffisante : les événements restent enregistrés par rasdaemon entre deux contrôles.
L’objectif n’est toutefois pas simplement d’accumuler des rapports. Il faut surtout pouvoir détecter l’apparition de nouvelles erreurs ou l’augmentation de leur fréquence.
Par exemple :
Des erreurs ECC corrigées qui augmentent régulièrement sur le même DIMM peuvent indiquer une barrette mémoire à surveiller.
Des MCE répétées peuvent orienter vers le CPU, la RAM, le contrôleur mémoire ou la carte mère.
Des erreurs PCIe/AER répétées sur la même adresse PCIe peuvent signaler un problème de périphérique, de liaison, de slot ou de pilote.
Une erreur Uncorrected ou Fatal doit conduire à examiner rapidement le composant concerné.
Sur un serveur critique, il est préférable de conserver l’historique des événements plutôt que de réinitialiser régulièrement la base rasdaemon. Cela permet de comparer leur fréquence sur plusieurs jours ou semaines et de détecter une éventuelle dégradation matérielle avant qu’elle ne provoque une panne.
Tableau des commandes rasdaemon et ras-mc-ctl
Le tableau suivant récapitule les principales commandes rasdaemon et ras-mc-ctl utiles pour surveiller et diagnostiquer les erreurs matérielles sous Linux.
Commande
Description
rasdaemon --version
Afficher la version de rasdaemon installée
rasdaemon --help
Afficher les options disponibles
sudo systemctl enable --now rasdaemon
Activer rasdaemon au démarrage et lancer immédiatement le service
systemctl status rasdaemon
Vérifier l’état du service rasdaemon
systemctl is-active rasdaemon
Vérifier rapidement si rasdaemon fonctionne
sudo journalctl -u rasdaemon -e
Afficher les derniers messages du service rasdaemon
sudo journalctl -u rasdaemon -f
Suivre les messages du service en temps réel
systemctl cat rasdaemon
Afficher le fichier unit systemd et vérifier les options de démarrage
sudo rasdaemon --record
Lancer rasdaemon avec l’enregistrement des événements dans sa base de données
sudo ras-mc-ctl --summary
Afficher un résumé des erreurs matérielles enregistrées
sudo ras-mc-ctl --errors
Afficher le détail des erreurs matérielles enregistrées
sudo dmidecode --type memory
Identifier les barrettes et emplacements mémoire lors de l’analyse d’erreurs ECC/EDAC
lspci
Identifier les périphériques PCI/PCIe
lspci -s 03:00.0 -k
Identifier le périphérique et le pilote correspondant à une adresse PCIe précise
sudo journalctl -k
Consulter les événements matériels enregistrés par le noyau
sudo journalctl -k -b -1
Examiner les événements du noyau du démarrage précédent après un plantage
Pour un contrôle rapide de la santé matérielle, commencez généralement par :
sudo ras-mc-ctl --summary
Si des événements apparaissent, affichez ensuite leur détail :
sudo ras-mc-ctl --errors
Puis complétez l’analyse avec les journaux du noyau :
sudo journalctl -k
Après un plantage ou un redémarrage inattendu, utilisez plutôt :
sudo journalctl -k -b -1
L’objectif est de croiser les informations : rasdaemon permet de suivre l’historique des événements RAS, tandis que journalctl fournit le contexte du noyau autour de l’erreur. Une accumulation d’erreurs ECC/EDAC, MCE ou PCIe/AER sur le même composant est généralement plus significative qu’un événement corrigé et isolé.
Votre PC sous Windows 11/10 n’est plus à la bonne heure ? L’horloge affiche une heure en avance, en retard ou se remet systématiquement à zéro après chaque démarrage ? Ce problème est plus fréquent qu’on ne le pense et peut avoir des conséquences sur le bon fonctionnement de Windows et de certaines applications.
Une heure incorrecte peut empêcher la synchronisation de fichiers, provoquer des erreurs de certificats HTTPS dans les navigateurs Web, perturber Windows Update, empêcher la connexion à certains services en ligne ou encore provoquer des dysfonctionnements avec Outlook, OneDrive, Steam ou Microsoft Store.
Les causes sont nombreuses : mauvais fuseau horaire, échec de la synchronisation avec un serveur de temps (NTP), service Temps Windows défaillant, pile CMOS déchargée, problème dans le BIOS/UEFI ou encore dual boot entre Windows et Linux.
Dans ce guide, découvrez toutes les causes possibles d’une mauvaise heure sous Windows 11/10 ainsi que les solutions pour retrouver une horloge parfaitement synchronisée.
Quelles sont les causes d’une mauvaise heure sur Windows 11/10
Une heure incorrecte sur Windows 11/10 peut avoir plusieurs origines. Dans la plupart des cas, le problème provient d’un mauvais paramétrage de Windows, d’un défaut de synchronisation avec les serveurs de temps ou d’un problème matériel comme une pile CMOS usée.
Le tableau ci-dessous présente les causes les plus fréquentes ainsi que les solutions à envisager.
Symptôme
Cause probable
Solution
L’heure est décalée d’une ou plusieurs heures
Fuseau horaire incorrect ou réglage automatique désactivé
Vérifier le fuseau horaire et les paramètres de date et d’heure
L’heure est déjà incorrecte dès l’écran du BIOS/UEFI
Mauvais réglage de l’horloge du BIOS ou pile CMOS défectueuse
Corriger l’heure dans le BIOS/UEFI et contrôler la pile
L’heure devient incorrecte après avoir utilisé Linux en double démarrage
Windows et Linux utilisent des méthodes différentes pour gérer l’horloge matérielle (UTC ou heure locale)
Configurer les deux systèmes pour utiliser le même mode
L’heure change régulièrement sur un PC d’entreprise
Synchronisation imposée par un contrôleur de domaine Active Directory
Vérifier la configuration réseau avec l’administrateur informatique
L’heure est incorrecte après une sortie de veille ou d’hibernation
Problème de reprise de l’horloge ou de synchronisation
Redémarrer Windows et vérifier le service Windows Time
L’heure est incorrecte dans une machine virtuelle
Synchronisation avec l’hôte désactivée ou mal configurée
Vérifier les paramètres de synchronisation de l’hyperviseur
Vérifier le fuseau horaire
Un mauvais fuseau horaire est l’une des causes les plus fréquentes d’une heure incorrecte sur Windows 11/10. Dans ce cas, l’horloge est généralement décalée d’une ou plusieurs heures alors que les minutes sont correctes.
Par exemple, si votre PC est configuré sur le fuseau (UTC-05:00) Est (États-Unis et Canada) au lieu de (UTC+01:00) Bruxelles, Copenhague, Madrid, Paris, l’heure affichée sera erronée même si la synchronisation avec les serveurs de temps fonctionne correctement.
Pour vérifier le fuseau horaire :
Ouvrez les Paramètres de Windows avec le raccourci Windows + I.
Accédez à Heure et langue > Date et heure.
Vérifiez que le Fuseau horaire correspond bien à votre pays ou à votre région.
Si nécessaire, activez également l’option Définir le fuseau horaire automatiquement si votre ordinateur est portable et change régulièrement de pays.
Une fois le bon fuseau horaire sélectionné, vérifiez si l’heure affichée est désormais correcte. Si ce n’est pas le cas, le problème provient probablement de la synchronisation de l’horloge ou d’un autre dysfonctionnement.
Vérifier que la synchronisation automatique fonctionne
Windows 11/10 synchronise automatiquement l’horloge avec un serveur de temps (NTP) sur Internet. Cette opération permet de maintenir une heure précise sans intervention de votre part.
Si cette synchronisation échoue, l’horloge peut progressivement prendre de l’avance ou du retard, voire ne plus se mettre à jour du tout. Cela peut être dû à un service Windows désactivé, un serveur de temps indisponible, un pare-feu ou un problème de connexion Internet.
Pour vérifier que la synchronisation automatique est activée :
Ouvrez les Paramètres avec Windows + I.
Accédez à Heure et langue > Date et heure.
Vérifiez que l’option Définir l’heure automatiquement est activée.
Dans la section Paramètres supplémentaires, cliquez sur Synchroniser maintenant afin de lancer une synchronisation immédiate.
Si la synchronisation réussit, Windows affiche la date et l’heure de la dernière synchronisation.
En revanche, si un message d’erreur apparaît ou que la synchronisation échoue systématiquement, il est probable que le service Windows Time, le serveur NTP ou un autre composant de Windows soit en cause.
Après une synchronisation réussie, vérifiez que l’heure affichée est correcte. Si le problème réapparaît après un redémarrage ou quelques heures d’utilisation, il peut s’agir d’un problème matériel, notamment une pile CMOS déchargée ou une horloge du BIOS/UEFI mal configurée.
Synchroniser l’heure manuellement
Si l’heure de votre PC est incorrecte, vous pouvez lancer une synchronisation manuelle avec un serveur de temps afin de remettre immédiatement l’horloge à l’heure.
Cette opération est utile lorsque la synchronisation automatique ne s’est pas effectuée depuis plusieurs jours ou après avoir corrigé le fuseau horaire.
Pour synchroniser l’heure manuellement :
Ouvrez les Paramètres avec le raccourci Windows + I.
Accédez à Heure et langue > Date et heure.
Faites défiler la page jusqu’à Paramètres supplémentaires.
Cliquez sur le bouton Synchroniser maintenant.
Si l’opération réussit, Windows met immédiatement à jour la date et l’heure, puis affiche la date de la dernière synchronisation.
En revanche, si la synchronisation échoue ou qu’un message d’erreur s’affiche, cela peut indiquer un problème avec le service Windows Time, le serveur NTP ou votre connexion réseau.
Si la synchronisation manuelle ne corrige pas le problème ou si l’heure redevient incorrecte après un redémarrage, poursuivez les vérifications ci-dessous, notamment l’heure du BIOS/UEFI et l’état de la pile CMOS
Vérifier le service Windows Time
Le service Windows Time (W32Time) est chargé de synchroniser l’horloge de Windows avec un serveur de temps (NTP). S’il est arrêté, désactivé ou rencontre un dysfonctionnement, votre ordinateur ne pourra plus mettre automatiquement son horloge à jour.
Vous pouvez vérifier son état de la façon suivante :
Appuyez sur les touches Windows + R.
Saisissez services.msc, puis cliquez sur OK.
Recherchez le service Temps Windows (Windows Time).
Vérifiez que son État est En cours d’exécution.
Vérifiez également que son Type de démarrage est réglé sur Manuel (déclenchement) ou Automatique, selon votre configuration.
Si le service est arrêté, cliquez dessus avec le bouton droit de la souris, puis choisissez Démarrer. Vous pouvez ensuite essayer de synchroniser à nouveau l’horloge depuis les paramètres de Windows.
Si le service refuse de démarrer, s’arrête immédiatement ou génère une erreur, cela peut indiquer un problème de configuration, de registre ou de fichiers système.
Si le service Windows Time fonctionne correctement mais que l’heure reste incorrecte, poursuivez les vérifications en contrôlant l’heure enregistrée dans le BIOS/UEFI ainsi que l’état de la pile CMOS.
Vérifier l’heure dans le BIOS/UEFI
Si l’heure reste incorrecte malgré une synchronisation réussie dans Windows, il est recommandé de vérifier l’horloge enregistrée dans le BIOS/UEFI. En effet, Windows utilise l’horloge matérielle de la carte mère au démarrage. Si celle-ci est erronée, le système peut afficher une heure incorrecte avant même d’effectuer une synchronisation avec un serveur de temps.
Cette vérification est particulièrement utile si :
L’heure est déjà incorrecte dès le démarrage de Windows.
L’heure est remise à zéro après un arrêt prolongé.
Le problème réapparaît après chaque redémarrage, malgré une synchronisation réussie.
Pour vérifier l’heure dans le BIOS/UEFI :
Redémarrez votre ordinateur.
Pendant le démarrage, appuyez sur la touche permettant d’accéder au BIOS/UEFI (généralement Suppr, F2, F10 ou Échap, selon le fabricant).
Recherchez la section contenant la date et l’heure système.
Vérifiez que la date, l’heure et, si disponible, le fuseau horaire sont corrects.
Corrigez-les si nécessaire, puis enregistrez les modifications avant de quitter le BIOS/UEFI.
Si l’heure du BIOS est correcte mais que Windows affiche une heure différente, le problème provient probablement de la configuration de Windows ou de la synchronisation avec les serveurs de temps.
En revanche, si l’heure du BIOS est également incorrecte, il est fort probable que le problème soit matériel. La cause la plus fréquente est une pile CMOS déchargée, qui ne parvient plus à conserver les paramètres de la carte mère lorsque l’ordinateur est éteint.
La section suivante explique comment reconnaître les symptômes d’une pile CMOS usée et savoir quand il est nécessaire de la remplacer.
Vérifier la pile CMOS
La pile CMOS (généralement une pile bouton CR2032) alimente la mémoire de la carte mère lorsque l’ordinateur est éteint. Elle permet notamment de conserver la date, l’heure et les paramètres du BIOS/UEFI.
Avec le temps, cette pile se décharge naturellement. Lorsqu’elle est usée, l’horloge matérielle ne fonctionne plus correctement et Windows affiche une heure ou une date incorrecte au démarrage.
Les symptômes les plus courants d’une pile CMOS déchargée sont les suivants :
L’heure et la date sont remises à zéro après un arrêt prolongé de l’ordinateur.
L’heure est systématiquement incorrecte au démarrage, même après une synchronisation réussie.
Le BIOS/UEFI perd certains paramètres, comme l’ordre de démarrage ou la configuration du matériel.
Des messages d’erreur apparaissent au démarrage, tels que CMOS Checksum Error, CMOS Battery Low ou Time-of-Day Clock Stopped.
Pour confirmer que la pile est en cause :
Vérifiez l’heure directement dans le BIOS/UEFI avant de démarrer Windows.
Corrigez la date et l’heure, puis enregistrez les modifications.
Éteignez complètement le PC pendant plusieurs heures ou débranchez-le de l’alimentation.
Redémarrez l’ordinateur et vérifiez si l’heure du BIOS est de nouveau incorrecte.
Si c’est le cas, il est très probable que la pile CMOS soit déchargée et doive être remplacée.
Le remplacement est généralement simple sur un ordinateur de bureau. Il suffit de remplacer la pile bouton par une CR2032 neuve. Sur certains ordinateurs portables, la pile CMOS peut être intégrée à la carte mère ou reliée par un connecteur, ce qui nécessite un démontage plus important.
Réglez à nouveau la date et l’heure dans le BIOS/UEFI.
Vérifiez que Windows affiche désormais la bonne heure.
Lancez une synchronisation manuelle pour vous assurer que l’horloge est correctement mise à jour.
Si le problème persiste malgré une pile neuve, il est alors conseillé de vérifier la configuration de Windows Time, la synchronisation NTP ou un éventuel problème matériel de la carte mère.
Vérifier qu’un logiciel ne modifie pas l’heure
Si l’heure de Windows change régulièrement sans raison apparente, il est possible qu’un logiciel ou un équipement réseau la modifie automatiquement. C’est notamment le cas dans les environnements professionnels, avec certaines machines virtuelles ou des logiciels de synchronisation.
Les cas les plus fréquents sont :
Un PC intégré à un domaine Active Directory, où l’heure est synchronisée avec un contrôleur de domaine.
Une machine virtuelle (Hyper-V, VMware, VirtualBox, Proxmox, etc.) configurée pour récupérer l’heure de l’ordinateur hôte.
Un logiciel de synchronisation NTP tiers, qui remplace le service Windows Time.
Un logiciel d’administration à distance ou de supervision pouvant modifier l’heure système.
Un VPN ou une solution de sécurité d’entreprise appliquant des stratégies de synchronisation spécifiques.
Vous pouvez également vérifier la source de synchronisation utilisée par Windows.
Pour cela :
Ouvrez Invite de commandes ou Windows Terminal en tant qu’administrateur.
Exécutez la commande suivante :
w32tm /query /source
Si le résultat indique Local CMOS Clock, cela signifie que Windows n’est pas synchronisé avec un serveur de temps et utilise uniquement l’horloge matérielle de l’ordinateur. Cette situation peut expliquer une dérive progressive de l’heure, notamment si la pile CMOS est déchargée.
En revanche, si un serveur NTP ou un contrôleur de domaine est affiché, cela signifie qu’une synchronisation est bien configurée.
Si vous utilisez une machine virtuelle, vérifiez également que les paramètres de l’hyperviseur ne remplacent pas régulièrement l’heure de Windows par celle de l’ordinateur hôte.
Enfin, si votre ordinateur appartient à une entreprise ou à un établissement scolaire, il est normal que l’heure soit imposée par l’administrateur réseau. Dans ce cas, les modifications manuelles sont généralement écrasées lors de la prochaine synchronisation.
Vérifier l’intégrité de Windows
Si aucune des vérifications précédentes n’a permis de résoudre le problème, il est possible que des fichiers système de Windows soient corrompus. Cela peut affecter le fonctionnement du service Windows Time ou d’autres composants chargés de la gestion de la date et de l’heure.
Windows intègre deux outils permettant de détecter et de réparer automatiquement ces fichiers : SFC (System File Checker) et DISM (Deployment Image Servicing and Management).
Pour lancer une vérification :
Ouvrez Windows Terminal, PowerShell ou Invite de commandes en tant qu’administrateur.
Exécutez la commande suivante :
sfc /scannow
Patientez jusqu’à la fin de l’analyse.
Si des erreurs sont détectées mais ne peuvent pas être réparées, exécutez ensuite la commande suivante :
DISM /Online /Cleanup-Image /RestoreHealth
Une fois l’opération terminée, redémarrez votre ordinateur.
Relancez si nécessaire la commande sfc /scannow afin de vérifier que toutes les réparations ont bien été effectuées.
Ces outils permettent de réparer de nombreux problèmes liés aux fichiers système de Windows, y compris ceux pouvant empêcher certains services de fonctionner correctement.
Si l’heure reste incorrecte après ces réparations, il est probable que le problème provienne d’un défaut matériel, d’une configuration du BIOS/UEFI ou d’une synchronisation réseau défaillante.
Cas du dual-boot Windows/Linux
Si votre ordinateur est configuré en dual boot avec Windows et Linux, il est normal de constater un décalage d’une ou deux heures lorsque vous passez d’un système d’exploitation à l’autre.
Ce problème provient du fait que Windows et Linux n’utilisent pas la même méthode pour interpréter l’horloge matérielle (RTC) :
Windows considère par défaut que l’horloge du BIOS/UEFI est réglée sur l’heure locale.
La plupart des distributions Linux considèrent que cette même horloge est réglée en Temps universel coordonné (UTC), puis appliquent le fuseau horaire pour afficher l’heure locale.
Par conséquent, lorsque vous redémarrez d’un système vers l’autre, Windows peut afficher une heure décalée d’une ou deux heures, notamment lors des changements d’heure été/hiver.
Ce problème n’est pas lié à une panne de votre ordinateur ni à un dysfonctionnement du service Windows Time. Il s’agit simplement d’une différence de fonctionnement entre les deux systèmes d’exploitation.
La solution consiste à harmoniser la gestion de l’horloge entre Windows et Linux. Il est généralement recommandé de configurer Linux pour utiliser l’heure locale, plutôt que de modifier le fonctionnement de Windows, afin d’éviter d’éventuels problèmes avec certaines applications.
L’erreur 0x80070570 est l’un des codes d’erreur les plus courants sous Windows 11/10. Elle peut apparaître lors de la copie de fichiers, de l’installation de Windows, pendant Windows Update ou lors de l’accès à un disque dur, un SSD ou une clé USB. Selon le contexte, elle indique généralement que Windows ne parvient pas à lire ou écrire correctement certaines données.
Cette erreur n’a pas une cause unique. Elle peut être provoquée par un système de fichiers corrompu, un support de stockage défectueux, des secteurs défectueux, un support d’installation endommagé ou encore un problème lié à Windows Update. Dans ce guide, vous découvrirez la signification de l’erreur 0x80070570, les causes les plus fréquentes, les solutions générales à appliquer et les guides adaptés selon le contexte dans lequel elle apparaît.
Qu’est-ce que l’erreur 0x80070570 ?
L’erreur 0x80070570 est un code d’erreur de Windows qui indique qu’une opération n’a pas pu être effectuée en raison d’un fichier ou d’un répertoire endommagé, corrompu ou inaccessible. Selon le contexte, elle peut également être provoquée par un support de stockage défectueux, une corruption du système de fichiers, un support d’installation endommagé ou un problème lors de la lecture ou de l’écriture des données.
Cette erreur peut apparaître dans différentes situations :
Situation
Exemple
Copie ou déplacement de fichiers
Impossible de copier un fichier vers un disque dur, un SSD ou une clé USB.
Installation de Windows
Le programme d’installation ne parvient pas à lire certains fichiers.
Windows Update
Une mise à jour ne peut pas être téléchargée ou installée correctement.
Accès à un fichier ou un dossier
Windows signale que le fichier ou le répertoire est endommagé ou illisible.
À retenir : l’erreur 0x80070570 ne désigne pas une cause unique. Elle indique simplement que Windows n’a pas pu accéder correctement aux données dont il avait besoin. Pour résoudre le problème, il est donc important d’identifier le contexte dans lequel l’erreur apparaît avant d’appliquer la solution adaptée
Quelles sont les causes les plus fréquentes ?
L’erreur 0x80070570 peut avoir plusieurs origines selon le contexte dans lequel elle apparaît. Elle est le plus souvent liée à un problème d’accès aux données, qu’il s’agisse d’un support de stockage défectueux, d’un système de fichiers corrompu ou d’un fichier endommagé.
Le tableau ci-dessous présente les causes les plus fréquentes.
Cause
Dans quels cas ?
Solution recommandée
Système de fichiers corrompu
Copie de fichiers, accès à un disque, clé USB ou disque externe
Vérifier et réparer le système de fichiers avec CHKDSK.
Disque dur, SSD ou clé USB défectueux
Copie de fichiers, ouverture de dossiers, erreurs d’accès
La cause la plus probable dépend du moment où l’erreur apparaît.
L’erreur apparaît…
Cause la plus probable
Pendant la copie de fichiers
Support de stockage défectueux, système de fichiers corrompu ou fichier endommagé.
Lors de l’installation de Windows
Clé USB, image ISO ou mémoire vive défectueuse.
Pendant Windows Update
Cache ou composants de Windows Update corrompus.
Lors de l’ouverture d’un fichier ou d’un dossier
Corruption du système de fichiers ou problème du support de stockage.
Conseil : avant d’appliquer une solution, identifiez dans quel contexte l’erreur 0x80070570 apparaît. Les vérifications à effectuer ne sont pas les mêmes selon qu’il s’agit d’une copie de fichiers, d’une installation de Windows ou d’un problème de Windows Update.
Que faire selon le contexte ?
L’erreur 0x80070570 peut apparaître dans plusieurs situations. Les solutions ne sont pas les mêmes selon qu’elle survient pendant une copie de fichiers, une installation de Windows ou une mise à jour du système.
Le tableau ci-dessous vous permet d’accéder directement au guide correspondant à votre problème.
Corruption du système de fichiers ou problème du support de stockage.
Si vous ne parvenez pas à identifier le contexte ou si l’erreur apparaît lors d’un accès à un disque, un SSD ou une clé USB, commencez par vérifier l’état du support de stockage.
Conseil : dans la majorité des cas, l’erreur 0x80070570 est liée à un problème de lecture ou d’écriture des données. Identifier le contexte dans lequel elle apparaît permet de trouver beaucoup plus rapidement la solution adaptée.
Les solutions générales
Les solutions à appliquer dépendent du contexte dans lequel apparaît l’erreur 0x80070570. Toutefois, certaines vérifications sont utiles dans la plupart des situations, qu’il s’agisse d’un problème de copie de fichiers, d’un disque dur, d’un SSD, d’une clé USB ou d’une installation de Windows.
Détecte les erreurs SMART et les erreurs de stockage enregistrées par Windows.
Si vous suspectez un problème de disque ou de SSD.
Si aucune de ces vérifications ne permet de résoudre le problème, consultez le guide correspondant au contexte dans lequel l’erreur apparaît. Les solutions diffèrent selon qu’il s’agit d’une copie de fichiers, d’une installation de Windows ou d’un échec de Windows Update.
Conseil : si l’erreur 0x80070570 apparaît à plusieurs reprises sur le même disque, SSD ou clé USB, vérifiez rapidement son état de santé et sauvegardez vos données importantes. Une répétition de cette erreur peut être le signe d’une défaillance du support de stockage.
FAQ
L’erreur 0x80070570 signifie-t-elle que mon disque est HS ?
Non. Elle indique simplement que Windows n’a pas pu accéder correctement aux données. Le problème peut provenir d’un disque défectueux, d’un système de fichiers corrompu, d’un pilote de stockage ou d’un support d’installation endommagé.
Puis-je continuer à utiliser mon disque ?
Oui si l’erreur est isolée. En revanche, si elle se répète ou s’accompagne d’erreurs SMART ou des événements 7, 11, 51, 129 ou 153, sauvegardez rapidement vos données.
Est-ce que CHKDSK suffit ?
Pas toujours. CHKDSK corrige les erreurs logiques mais ne répare pas un disque physiquement défectueux.
Les ID d’événements (également appelés Event ID)7, 11, 51, 129 et 153 figurent parmi les erreurs de stockage les plus fréquemment rencontrées dans l’Observateur d’événements de Windows 11/10. Ils peuvent être associés aux sources Disk, StorPort, storahci, stornvme ou iaStor et signalent un problème de communication entre Windows, le contrôleur de stockage et le disque.
Ces événements ne signifient pas systématiquement que votre disque dur (HDD) ou votre SSD est défectueux. Ils peuvent être provoqués par un pilote de stockage, un contrôleur SATA ou NVMe, un firmware obsolète, un câble défectueux ou une véritable panne du périphérique de stockage. Dans ce guide, vous découvrirez la signification de chaque ID d’événement, les causes les plus fréquentes et les situations dans lesquelles il est réellement nécessaire de s’inquiéter.
Windows surveille en permanence les échanges entre le système d’exploitation, les pilotes de stockage, les contrôleurs SATA/NVMe et les disques durs (HDD) ou SSD. Lorsqu’une anomalie est détectée, le système enregistre un ID d’événement dans l’Observateur d’événements afin de faciliter le diagnostic.
Ces événements ne correspondent pas tous à une panne matérielle. Ils indiquent simplement qu’un problème est survenu pendant une opération de lecture, d’écriture ou de communication avec le périphérique de stockage.
Les ID d’événements les plus fréquents sont les suivants :
ID d’événement
Source
Signification
7
Disk
Windows n’a pas pu lire correctement certaines données. Cela peut être lié à des secteurs défectueux ou à une défaillance matérielle.
Le périphérique de stockage n’a pas répondu dans le délai prévu. Windows a réinitialisé le contrôleur pour rétablir la communication.
153
Disk
Une opération de lecture ou d’écriture a échoué puis a été automatiquement retentée par Windows.
Ces événements peuvent être provoqués par différentes causes :
un pilote de stockage obsolète ou incompatible ;
un câble SATA défectueux ou un mauvais contact ;
un firmware de SSD nécessitant une mise à jour ;
un contrôleur SATA ou NVMe instable ;
une défaillance du disque ;
une alimentation insuffisante ou instable.
À savoir : un ID d’événement isolé n’est généralement pas inquiétant. En revanche, si les mêmes événements (7, 11, 51, 129 ou 153) apparaissent régulièrement ou s’accompagnent de ralentissements, de blocages ou de la disparition du disque, ils constituent un indicateur précieux qu’un diagnostic du stockage est nécessaire.
Que signifie l’ID d’événement 153 ?
L’ID d’événement 153, enregistré avec la source Disk, indique que Windows a rencontré une erreur lors d’une opération de lecture ou d’écriture sur le disque, puis a automatiquement réessayé l’opération.
Le message affiché dans l’Observateur d’événements est généralement le suivant :
L’opération d’E/S à l’adresse logique de bloc … pour le disque … a été retentée.
Contrairement à l’événement 7 (erreur de lecture) ou à l’événement 51 (erreur d’entrée/sortie), l’événement 153 signifie que Windows est finalement parvenu à accéder au disque après une nouvelle tentative. Il s’agit donc davantage d’un avertissement que d’une erreur fatale.
Les causes les plus fréquentes sont les suivantes :
Cause possible
Explication
Disque dur ou SSD en fin de vie
Le périphérique répond trop lentement, obligeant Windows à relancer l’opération.
Câble SATA défectueux
Une mauvaise transmission des données provoque des erreurs temporaires.
Pilote ou contrôleur de stockage
Une incompatibilité ou un bug peut interrompre momentanément la communication avec le disque.
Firmware du SSD
Certains firmwares présentent des problèmes de stabilité corrigés par une mise à jour.
Alimentation instable
Une alimentation insuffisante peut entraîner des pertes de communication temporaires.
Un événement 153 isolé n’est généralement pas inquiétant. En revanche, si ces événements se multiplient ou s’accompagnent d’autres erreurs comme Disk 7, Disk 51 ou StorPort 129, il est recommandé d’effectuer un diagnostic complet du stockage.
Conseil : si vous observez de nombreux événements 153, vérifiez les pilotes du contrôleur de stockage, les connexions SATA ou NVMe, l’état SMART du disque ainsi que les éventuelles erreurs de stockage détectées par AnalysePC. Une augmentation progressive du nombre d’événements 153 peut être le premier signe d’une dégradation du disque ou d’un problème de communication avec le contrôleur.
Qu’est-ce que l’ID d’événement 7 ?
L’ID d’événement 7, enregistré avec la source Disk, indique que Windows n’a pas réussi à lire correctement des données sur le disque. Cette erreur est généralement plus préoccupante que les événements 51 ou 153, car elle peut révéler un problème matériel affectant le support de stockage.
Le message affiché dans l’Observateur d’événements est souvent similaire à :
Le périphérique \Device\HarddiskX présente un secteur défectueux.
Dans la plupart des cas, cet événement signifie que Windows a rencontré un ou plusieurs secteurs défectueux (bad sectors) ou une erreur physique lors de la lecture des données.
Les causes les plus fréquentes sont les suivantes :
Cause possible
Explication
Secteurs défectueux
Certaines zones du disque ne peuvent plus être lues correctement.
Disque dur (HDD) ou SSD en fin de vie
Le support de stockage commence à se dégrader.
Câble SATA défectueux
Une mauvaise transmission des données peut provoquer des erreurs de lecture.
Contrôleur de stockage
Plus rarement, un contrôleur ou un pilote défaillant peut être à l’origine de l’erreur.
Contrairement à l’ID d’événement 153, où Windows parvient généralement à relire les données après une nouvelle tentative, l’événement 7 indique que la lecture a échoué. Il est donc considéré comme un indicateur plus sérieux d’un problème de stockage.
Attention : si des événements Disk – ID 7 apparaissent régulièrement, sauvegardez immédiatement vos données. Ils sont souvent le signe d’une dégradation du disque et peuvent précéder une panne complète.
L’ID d’événement 51, enregistré avec la source Disk, indique qu’une erreur d’entrée/sortie (E/S) s’est produite lors d’un accès au disque. Windows a rencontré un problème pendant une opération de lecture ou d’écriture, mais cela ne signifie pas nécessairement que le disque est défectueux.
Le message affiché dans l’Observateur d’événements est généralement le suivant :
Une erreur a été détectée sur le périphérique \Device\HarddiskX\DRX lors d’une opération de pagination.
L’opération de pagination (paging operation) correspond aux échanges entre la mémoire vive (RAM) et le fichier d’échange (pagefile.sys), mais cet événement peut également survenir lors d’autres opérations de lecture ou d’écriture sur le disque.
Les causes les plus fréquentes sont les suivantes :
Cause possible
Explication
Problème de communication avec le disque
Une erreur temporaire s’est produite pendant un accès au stockage.
Câble SATA ou USB défectueux
Une mauvaise transmission des données provoque une erreur d’entrée/sortie.
Pilote ou contrôleur de stockage
Un pilote instable ou incompatible peut générer des erreurs de pagination.
Disque en cours de dégradation
Le disque répond difficilement à certaines demandes de lecture ou d’écriture.
Problème d’alimentation
Une alimentation instable peut interrompre momentanément les échanges avec le disque.
L’ID d’événement 51 est généralement moins alarmant que l’événement 7, car il ne signifie pas nécessairement que des secteurs défectueux sont présents. En revanche, s’il apparaît régulièrement ou s’accompagne d’événements 7, 129 ou 153, il peut révéler un problème plus important.
À retenir : un événement 51 isolé peut être sans conséquence. En revanche, si les erreurs deviennent fréquentes ou sont accompagnées de ralentissements, de blocages ou de la disparition du disque, il est recommandé de vérifier les pilotes du contrôleur de stockage, les connexions SATA ou NVMe, l’état SMART du disque et les autres événements enregistrés dans l’Observateur d’événements.
Que signifie l’ID d’événement 11 ?
L’ID d’événement 11 indique que Windows ou le pilote de stockage a détecté une erreur de communication avec le contrôleur du disque. Contrairement à l’événement 7, qui est souvent lié à des secteurs défectueux, l’événement 11 concerne principalement les échanges entre le système d’exploitation, le contrôleur de stockage et le périphérique.
Le message affiché dans l’Observateur d’événements est généralement similaire à :
Le pilote a détecté une erreur du contrôleur sur \Device\HarddiskX\DRX.
L’événement 11 peut être enregistré par plusieurs sources, notamment Disk, iaStor ou stornvme, selon le pilote utilisé par votre ordinateur.
Les causes les plus fréquentes sont les suivantes :
Cause possible
Explication
Câble SATA défectueux
Une mauvaise transmission des données provoque des erreurs de communication.
Pilote de stockage obsolète ou incompatible
Le pilote ne communique plus correctement avec le contrôleur ou le disque.
Contrôleur SATA ou NVMe
Le contrôleur rencontre des difficultés à dialoguer avec le périphérique de stockage.
Firmware du SSD
Un bug du firmware peut provoquer des erreurs intermittentes.
Disque en fin de vie
Un disque qui répond difficilement peut entraîner des erreurs du contrôleur.
L’ID d’événement 11 n’indique pas à lui seul que le disque est défectueux. Il est souvent nécessaire de l’interpréter avec les autres événements présents dans l’Observateur d’événements.
Si l’événement 11 est accompagné de…
Cela peut indiquer…
Event ID 129 (StorPort, storahci, stornvme…)
Des délais de réponse ou des réinitialisations du contrôleur de stockage.
Event ID 153 (Disk)
Des opérations de lecture ou d’écriture qui doivent être retentées.
Event ID 7 (Disk)
Une dégradation matérielle du disque ou des secteurs défectueux.
Event ID 51 (Disk)
Des erreurs d’entrée/sortie répétées.
À retenir : un Event ID 11 isolé est souvent lié à un problème ponctuel de communication. En revanche, si les événements se répètent ou s’accompagnent d’autres erreurs (7, 51, 129 ou 153), il est recommandé de vérifier les pilotes du contrôleur de stockage, les connexions SATA ou NVMe, le firmware du SSD ainsi que l’état de santé du disque.
Que faire ?
Les ID d’événements 7, 11, 51, 129 et 153 permettent d’identifier un problème de stockage, mais ils ne suffisent pas à en déterminer l’origine. Selon le contexte, la cause peut être un pilote de stockage, un contrôleur SATA ou NVMe, un SSD, un disque dur ou une simple erreur de communication.
Voici un tableau récapitulatif des gravités selon l’évènement :
Event ID
Gravité
Causes principales
Action
7
secteurs défectueux
sauvegarder
11
contrôleur
vérifier pilote
51
erreur E/S
vérifier stockage
129
timeout
firmware/pilote
153
nouvelle tentative
surveiller
Ainsi
Si les erreurs concernent principalement StorPort, storahci, stornvme ou iaStor, consultez notre guide dédié qui explique le rôle de ces pilotes, les causes des erreurs et les vérifications à effectuer.
Si les événements sont accompagnés de ralentissements, d’erreurs Disk ou NTFS, d’un SMART dégradé ou du message « Windows a détecté un problème de disque », effectuez un diagnostic complet de votre support de stockage.
Microsoft déploie la mise à jour KB5101684 pour Windows 11 24H2 et 25H2. Cette mise à jour facultative de prévisualisation (Preview) n’apporte pas de correctifs de sécurité, mais 42 améliorations et corrections destinées à être intégrées au Patch Tuesday d’août 2026.
Au programme : un Explorateur de fichiers plus rapide, une recherche Windows plus pertinente, des améliorations pour Windows Hello, les widgets, le pavé tactile, l’accessibilité et de nombreux correctifs de fiabilité.
Une mise à jour facultative
KB5101684 est une mise à jour de prévisualisation (« D Release »), distribuée durant la dernière semaine du mois.
Elle n’est pas installée automatiquement. Pour l’obtenir, il faut ouvrir Paramètres > Windows Update puis cliquer sur Télécharger et installer lorsqu’elle est proposée. Si l’option Recevoir les dernières mises à jour dès qu’elles sont disponibles est activée, Windows pourra également proposer ce type de mises à jour plus rapidement.
Après installation :
Windows 11 25H2 passe en Build 26200.8973 ;
Windows 11 24H2 passe en Build 26100.8973.
Un gain de performances pour l’Explorateur de fichiers
L’Explorateur de fichiers reçoit plusieurs optimisations qui améliorent son confort d’utilisation.
Parmi les changements :
affichage des tailles de fichiers en Ko, Mo ou Go au lieu d’un affichage systématique en Ko ;
ouverture d’un dossier dans un nouvel onglet avec le clic du milieu depuis la barre d’adresse et la page d’accueil ;
disparition de certains clignotements gris lors du chargement ;
miniatures plus nettes dans la section Recommandé ;
amélioration générale de la stabilité d’explorer.exe.
Microsoft corrige également un problème affectant les partages DFS, où certains fichiers étaient à tort considérés comme provenant d’Internet, empêchant leur aperçu ou ajoutant un marquage de sécurité inutile.
Une recherche Windows plus efficace
Windows Search bénéficie également de plusieurs améliorations.
La recherche d’applications tolère désormais mieux :
les fautes de frappe ;
les noms partiels des programmes.
Les résultats dans l’application Paramètres sont également mieux classés afin de faire remonter plus rapidement les options les plus pertinentes.
Windows Hello, Widgets et pavé tactile évoluent
Cette mise à jour introduit plusieurs nouveautés.
Windows Hello prend désormais en charge les lecteurs d’empreintes externes compatibles ESS (Enhanced Sign-in Security), permettant d’utiliser une authentification biométrique renforcée sur les PC de bureau et les ordinateurs portables compatibles.
Les Widgets deviennent plus discrets :
les badges utilisent désormais la couleur d’accentuation de Windows au lieu du rouge ;
l’écran de verrouillage affiche uniquement la météo par défaut pour les nouveaux utilisateurs.
Les utilisateurs d’un pavé tactile de précision disposent également de nouveaux réglages permettant d’ajuster la vitesse du défilement, du zoom et de bénéficier d’un défilement accéléré.
De nombreuses améliorations de fiabilité
KB5101684 apporte aussi une longue série de corrections.
Microsoft améliore notamment :
la fiabilité du menu Démarrer ;
les écrans de connexion et de verrouillage ;
la barre des tâches ;
la gestion des plans d’alimentation ;
Windows Update, avec un calcul plus précis de la progression des téléchargements et un nettoyage plus efficace après les mises à jour ;
les sauvegardes Historique des fichiers vers des partages réseau SMB ;
la fiabilité des renouvellements DHCP ;
les performances d’impression des imprimantes IPPS ;
le presse-papiers lors des connexions Bureau à distance et Azure Virtual Desktop ;
la stabilité des applications Office dans les environnements virtualisés.
Accessibilité et commandes vocales
Les utilisateurs de Voice Access profitent de plusieurs nouveautés :
un mode Voice Isolation qui filtre les voix des autres personnes ;
un mode supprimant uniquement les bruits de fond ;
la prise en charge de la langue coréenne ;
une meilleure fiabilité du démarrage de la fonctionnalité.
Du côté de l’accessibilité, Microsoft améliore également Loupe, dont les barres tactiles de déplacement sont désormais désactivées par défaut afin de ne plus masquer une partie de l’écran agrandi.
Faut-il installer KB5101684 ?
Comme toutes les mises à jour Preview, KB5101684 est principalement destinée aux utilisateurs souhaitant tester les futures améliorations de Windows avant leur déploiement général.
Si votre ordinateur fonctionne correctement, vous pouvez attendre le Patch Tuesday d’août 2026, qui intégrera automatiquement ces correctifs avec les prochaines mises à jour de sécurité.
En revanche, si vous êtes concerné par l’un des problèmes corrigés (Explorateur de fichiers, recherche Windows, SMB, Windows Hello ou performances générales), cette mise à jour peut être intéressante à installer dès maintenant.
Les erreurs StorPort, storahci, stornvme ou iaStor apparaissent dans l’Observateur d’événements lorsque Windows rencontre un problème de communication avec un disque dur (HDD), un SSD, un contrôleur SATA/NVMe ou son pilote de stockage. Elles peuvent provoquer des ralentissements, des blocages, des pertes de connexion du disque ou, dans certains cas, des écrans bleus (BSOD).
Ces erreurs ne signifient pas forcément que votre disque est en panne. Elles sont souvent liées à un pilote obsolète, un firmware de SSD, un câble SATA défectueux ou un problème de contrôleur. Dans ce guide, vous apprendrez à identifier le pilote concerné, interpréter les erreurs enregistrées par Windows, vérifier les pilotes, les connexions et déterminer si le problème provient du contrôleur de stockage ou du disque lui-même.
StorPort, storahci, stornvme et iaStor sont des pilotes de stockage utilisés par Windows pour communiquer avec les disques durs (HDD), les SSD SATA, les SSD NVMe et les contrôleurs de stockage de votre ordinateur.
Lorsqu’un problème de communication survient entre Windows et le périphérique de stockage, ces pilotes enregistrent généralement une erreur dans l’Observateur d’événements. Le nom de la source permet souvent d’identifier le composant concerné.
Le tableau ci-dessous résume le rôle de chacun de ces pilotes.
Pilote
Utilisation
Rôle
Concerné
StorPort
Infrastructure de stockage hautes performances utilisée par Windows pour certains contrôleurs de stockage.
Pilote générique utilisé par Windows pour communiquer avec certains contrôleurs de stockage.
Contrôleurs RAID, SAS, NVMe et certains pilotes constructeurs.
storahci
Pilote AHCI intégré à Windows.
Pilote AHCI natif de Windows.
Disques durs et SSD SATA configurés en mode AHCI.
stornvme
Pilote NVMe intégré à Windows.
Pilote NVMe natif de Windows.
SSD NVMe connectés en M.2 ou PCIe.
iaStor
Pilote Intel Rapid Storage Technology (RST).
Pilote Intel Rapid Storage Technology (RST).
Contrôleurs SATA ou RAID Intel lorsque le pilote Intel est installé.
Le pilote utilisé dépend de la configuration matérielle de votre ordinateur. Par exemple :
un SSD NVMe utilise généralement stornvme ;
un SSD SATA fonctionne le plus souvent avec storahci ;
un PC équipé d’Intel Rapid Storage Technology (RST) utilise iaStor ;
certains contrôleurs RAID ou professionnels s’appuient sur StorPort.
À savoir : une erreur provenant de l’un de ces pilotes ne signifie pas forcément que le disque est défectueux. Dans de nombreux cas, elle indique simplement qu’un problème de communication s’est produit entre Windows et le périphérique de stockage. La cause peut être un pilote obsolète, un firmware de SSD, un câble SATA défectueux, un contrôleur instable ou, plus rarement, une panne du disque lui-même.
Que sont les erreurs StorPort, storahci, stornvme et iaStor ?
Les erreurs StorPort, storahci, stornvme et iaStor sont des événements enregistrés par Windows lorsqu’un problème survient lors de la communication avec un disque dur (HDD), un SSD ou leur contrôleur de stockage. Elles sont généralement visibles dans l’Observateur d’événements, sous Journaux Windows > Système.
Contrairement aux erreurs Disk ou NTFS, elles ne désignent pas directement une panne du disque. Elles indiquent le plus souvent qu’un pilote de stockage, un contrôleur SATA ou NVMe, un firmware, un câble ou le disque lui-même rencontre des difficultés de communication.
Les principales sources d’événements sont les suivantes :
Source
Concerné
ID d’événements fréquents
StorPort
Contrôleurs RAID, SAS, NVMe ou certains pilotes constructeurs.
129, 157
storahci
Contrôleurs SATA configurés en mode AHCI.
129
stornvme
SSD NVMe connectés au port M.2 ou PCIe.
129, 11
iaStor
Contrôleurs SATA ou RAID Intel.
11, 129
Une erreur provenant de l’une de ces sources peut avoir plusieurs origines :
un pilote de stockage obsolète ou incompatible ;
un firmware de SSD nécessitant une mise à jour ;
un câble SATA défectueux ou un mauvais contact ;
une défaillance du contrôleur de stockage ;
un disque en fin de vie provoquant des erreurs de communication.
[su_alerte]Important : une erreur StorPort, storahci, stornvme ou iaStor ne signifie pas systématiquement que votre disque est défectueux. Avant de le remplacer, il est recommandé de vérifier son état SMART, les erreurs de stockage enregistrées par Windows ainsi que les pilotes et les connexions du contrôleur de stockage.[/su_alerte]
Pourquoi ces erreurs apparaissent-elles ?
Les erreurs StorPort, storahci, stornvme ou iaStor apparaissent lorsque Windows ne parvient plus à communiquer correctement avec le périphérique de stockage. Elles correspondent généralement à un délai de réponse trop long, une erreur de communication ou une réinitialisation du contrôleur de stockage.
Contrairement aux erreurs Disk ou NTFS, elles n’indiquent pas directement une corruption du système de fichiers ou une panne du disque. Elles signalent avant tout un problème survenu entre Windows et le contrôleur de stockage.
Les causes les plus fréquentes sont les suivantes :
Cause
Explication
Pilote de stockage obsolète ou incompatible
Le pilote ne communique plus correctement avec le contrôleur ou le disque.
Firmware du SSD obsolète
Certains bugs du firmware peuvent provoquer des pertes de communication ou des délais de réponse.
Câble SATA défectueux
Une mauvaise transmission des données entraîne des erreurs d’entrée/sortie.
Mauvais contact du SSD NVMe
Un SSD M.2 mal inséré ou un connecteur défectueux peut provoquer des erreurs intermittentes.
Contrôleur SATA ou NVMe instable
Un problème matériel ou un bug du contrôleur peut provoquer des réinitialisations.
Défaillance du disque
Un disque en fin de vie peut répondre trop lentement ou ne plus répondre du tout.
Problème d’alimentation
Une alimentation instable peut interrompre temporairement la communication avec le périphérique de stockage.
Toutes les erreurs n’ont pas la même gravité.
Situation
Niveau de gravité
Une erreur isolée après une sortie de veille ou un redémarrage
Généralement sans conséquence.
Quelques erreurs occasionnelles sans autre symptôme
À surveiller.
Des dizaines d’erreurs par jour
Un diagnostic est recommandé.
Les erreurs sont accompagnées de ralentissements, de blocages ou de la disparition du disque
Le problème doit être traité rapidement.
À retenir : les erreurs StorPort, storahci, stornvme ou iaStor sont le plus souvent le symptôme d’un problème de communication avec le stockage. Elles ne permettent pas, à elles seules, de conclure que le disque est défectueux, mais elles constituent un indicateur précieux lorsqu’elles deviennent fréquentes ou qu’elles s’accompagnent d’autres anomalies.me de communication plutôt qu’à une défaillance matérielle du support de stockage.
Identifier le pilote concerné
Avant d’appliquer une solution, il est important d’identifier quel pilote de stockage est à l’origine des erreurs. Le nom de la source indiqué dans l’Observateur d’événements permet généralement de savoir si le problème concerne un contrôleur SATA, un SSD NVMe, un contrôleur RAID ou un pilote spécifique du constructeur.
Le tableau ci-dessous résume les principaux pilotes de stockage utilisés sous Windows.
Source de l’événement
Pilote concerné
Vérifications recommandées
storahci
Pilote AHCI natif de Windows
Vérifier les pilotes du chipset, les câbles SATA et les mises à jour Windows.
stornvme
Pilote NVMe natif de Windows
Vérifier le firmware du SSD, les pilotes du chipset et le connecteur M.2.
iaStor
Intel Rapid Storage Technology (Intel RST)
Mettre à jour Intel RST, vérifier le BIOS/UEFI et les pilotes Intel.
StorPort
Pilote de stockage générique utilisé par certains contrôleurs
Vérifier les pilotes du contrôleur RAID, SAS ou NVMe ainsi que le matériel associé.
Pour connaître le pilote utilisé par votre contrôleur de stockage :
Ouvrez le Gestionnaire de périphériques (devmgmt.msc).
Développez la catégorie Contrôleurs IDE ATA/ATAPI ou Contrôleurs de stockage.
Identifiez le contrôleur installé (Intel RST, Contrôleur AHCI SATA standard, Contrôleur NVMe, etc.).
Ouvrez ses Propriétés, puis consultez l’onglet Pilote afin de connaître le fournisseur, la version et la date du pilote.
Conseil : si les erreurs sont apparues après une mise à jour de Windows ou l’installation d’un nouveau pilote, vérifiez si une version plus récente est disponible sur le site du fabricant de votre ordinateur, de votre carte mère ou du contrôleur de stockage. À l’inverse, si le problème est apparu juste après une mise à jour du pilote, un retour à la version précédente peut parfois résoudre les erreurs.
Dans quels cas faut-il s’inquiéter ?
Une erreur StorPort, storahci, stornvme ou iaStor n’est pas toujours synonyme de panne. Windows peut enregistrer une erreur ponctuelle lors d’un redémarrage, d’une sortie de veille ou d’une mise à jour sans que cela ait de conséquence sur le fonctionnement du disque.
En revanche, lorsque ces erreurs deviennent fréquentes ou s’accompagnent d’autres symptômes, elles peuvent révéler un problème plus important.
Situation
Faut-il s’inquiéter ?
Action recommandée
Une erreur isolée après un redémarrage ou une sortie de veille
Non
Surveillez simplement si elle se reproduit.
Quelques erreurs espacées dans le temps, sans autre symptôme
Peu
Vérifiez que les pilotes et Windows sont à jour.
Les mêmes erreurs apparaissent plusieurs fois par jour
Oui
Recherchez l’origine du problème (pilotes, firmware, connexions…).
Les erreurs sont accompagnées de ralentissements ou de blocages
Oui
Effectuez un diagnostic complet du stockage.
Le disque disparaît puis réapparaît
Oui
Vérifiez immédiatement les connexions, les pilotes et l’état du disque.
Des erreurs Disk ou NTFS apparaissent en plus
Oui
Le problème peut provenir du disque lui-même ou du système de fichiers.
Le SMART est dégradé ou AnalysePC détecte plusieurs anomalies
Oui
Sauvegardez les données et poursuivez le diagnostic sans attendre.
Le critère le plus important n’est pas la présence d’une erreur, mais sa fréquence. Une erreur occasionnelle est rarement préoccupante, alors qu’une succession d’erreurs StorPort, storahci, stornvme ou iaStor indique généralement que la communication avec le périphérique de stockage se dégrade.
Conseil : si ces erreurs reviennent régulièrement, ne vous contentez pas de les effacer dans l’Observateur d’événements. Cherchez-en la cause afin d’éviter qu’elles n’évoluent vers des pertes de performances, des erreurs d’entrée/sortie ou une indisponibilité du disque.
Vérifier si le disque est en cause
Les erreurs StorPort, storahci, stornvme ou iaStor ne proviennent pas systématiquement du pilote de stockage. Elles peuvent également être la conséquence d’un disque dur (HDD) ou d’un SSD en fin de vie.
Si ces erreurs sont fréquentes ou s’accompagnent de ralentissements, de blocages ou d’erreurs Disk ou NTFS, il est recommandé de vérifier l’état de santé du disque avant d’aller plus loin.
Situation
Vérification recommandée
Les erreurs sont rares et le PC fonctionne normalement
Vérifiez d’abord les pilotes et les mises à jour du contrôleur de stockage.
Les erreurs reviennent régulièrement
Vérifiez l’état SMART du disque et les erreurs de stockage.
Le disque devient lent ou disparaît
Effectuez un diagnostic complet du disque.
Le SMART est dégradé ou d’autres erreurs apparaissent
Sauvegardez les données et envisagez le remplacement du disque.
Pour savoir si le problème provient réellement de votre disque, consultez notre guide :
Si vous souhaitez uniquement vérifier l’état de santé du disque et interpréter les informations SMART, consultez également notre guide dédié.
Vérifier les pilotes du contrôleur de stockage
Les erreurs StorPort, storahci, stornvme ou iaStor sont souvent provoquées par un pilote de contrôleur de stockage obsolète, incompatible ou corrompu. Avant de suspecter une panne du disque, il est donc recommandé de vérifier que les pilotes sont à jour.
Les contrôleurs de stockage assurent la communication entre Windows et vos disques SATA, SSD NVMe ou contrôleurs RAID. Une incompatibilité peut entraîner des ralentissements, des pertes de connexion ou des erreurs répétées dans l’Observateur d’événements.
Vérification
Pourquoi ?
Action recommandée
Mettre à jour le pilote du contrôleur de stockage
Corrige des problèmes de compatibilité ou de stabilité.
Installez le dernier pilote proposé par le fabricant de votre ordinateur ou de votre carte mère.
Vérifier le Gestionnaire de périphériques
Détecte un pilote manquant ou en erreur.
Assurez-vous qu’aucun contrôleur de stockage n’affiche un point d’exclamation jaune.
Le problème est apparu après une mise à jour
Une nouvelle version du pilote peut être à l’origine des erreurs.
Revenez à la version précédente si le problème est apparu immédiatement après la mise à jour.
Mettre à jour les pilotes du chipset
Les pilotes du chipset incluent souvent les contrôleurs SATA et PCIe.
Téléchargez les derniers pilotes depuis le site du constructeur.
Conseil : privilégiez toujours les pilotes fournis par le fabricant de votre ordinateur (Dell, HP, Lenovo, ASUS…) ou de votre carte mère (ASUS, MSI, Gigabyte, ASRock…). Ils sont généralement mieux adaptés à votre matériel que les pilotes génériques installés automatiquement par Windows.
Si les erreurs persistent malgré des pilotes à jour, poursuivez le diagnostic en vérifiant le firmware du SSD, les connexions SATA ou NVMe et l’état général du stockage.
Mettre à jour le firmware du SSD
Les fabricants de SSD publient régulièrement des mises à jour du firmware afin de corriger des bugs, d’améliorer la compatibilité avec Windows et de résoudre certains problèmes de stabilité. Dans certains cas, une version obsolète du firmware peut être à l’origine d’erreurs stornvme, StorPort ou de pertes de communication avec le disque.
Avant de mettre à jour le firmware, assurez-vous que le problème ne provient pas d’un pilote de stockage ou d’une défaillance matérielle du SSD.
Situation
Action recommandée
Les erreurs concernent un SSD NVMe
Vérifiez si une mise à jour du firmware est disponible.
Le constructeur propose un nouvel utilitaire ou un nouveau firmware
Installez la dernière version en suivant les recommandations du fabricant.
Le problème est apparu après une mise à jour du firmware
Vérifiez si une version plus récente corrige le problème ou contactez le support du fabricant.
La procédure varie selon le constructeur (Samsung, Crucial, Western Digital, Kingston, Seagate, etc.). Nous détaillons les outils compatibles et les précautions à prendre dans ce guide dédié :
Les erreurs StorPort, storahci, stornvme ou iaStor peuvent également être provoquées par un problème de connexion entre le disque et la carte mère. Un câble SATA défectueux, un SSD NVMe mal inséré ou un mauvais contact peuvent entraîner des erreurs de communication, des ralentissements ou la disparition temporaire du disque.
Avant de mettre en cause le disque ou le pilote, effectuez les vérifications suivantes.
Vérification
Pourquoi ?
Action recommandée
Contrôler le câble SATA
Un câble endommagé ou mal branché provoque des erreurs de communication.
Rebranchez le câble ou remplacez-le par un modèle neuf.
Vérifier le câble d’alimentation
Une alimentation instable peut provoquer des déconnexions du disque.
Contrôlez les connecteurs d’alimentation et essayez un autre câble si possible.
Contrôler le SSD NVMe
Un mauvais contact dans le connecteur M.2 peut entraîner des erreurs stornvme.
Vérifiez que le SSD est correctement inséré et fixé.
Tester un autre port SATA
Le port utilisé peut être défectueux.
Branchez le disque sur un autre port SATA de la carte mère.
Vérifier un boîtier externe USB
Le problème peut provenir du boîtier plutôt que du disque.
Testez le disque directement sur un port SATA ou dans un autre boîtier.
Conseil : si les erreurs sont apparues après un déplacement du PC, une intervention matérielle ou l’installation d’un nouveau disque, commencez toujours par contrôler les connexions. Un simple câble SATA défectueux peut générer des erreurs StorPort ou storahci sans que le disque soit réellement en panne.
Utiliser AnalysePC pour détecter les erreurs de stockage
Les erreurs StorPort, storahci, stornvme ou iaStor sont enregistrées dans l’Observateur d’événements, mais elles ne sont pas toujours faciles à identifier ou à interpréter.
AnalysePC automatise cette vérification en analysant les journaux Windows et en signalant les principales erreurs de stockage détectées sur votre ordinateur.
Le logiciel permet notamment de :
Vérification
Intérêt
Détecter les erreurs StorPort, storahci, stornvme et iaStor
Identifie rapidement les erreurs de communication avec le contrôleur de stockage.
Regrouper les erreurs de stockage
Évite de parcourir manuellement l’Observateur d’événements.
Vérifier l’état SMART du disque
Permet de déterminer si les erreurs sont liées à une défaillance du support de stockage.
Présenter un diagnostic synthétique
Facilite l’identification de l’origine probable du problème.
Si AnalysePC détecte des erreurs répétées, il est recommandé de poursuivre le diagnostic en vérifiant les pilotes du contrôleur de stockage, le firmware du SSD, les connexions SATA ou NVMe ainsi que l’état de santé du disque.
Conseil : les erreurs StorPort, storahci, stornvme ou iaStor sont souvent les premiers signes d’un problème de communication avec le stockage. Détectées suffisamment tôt, elles permettent d’intervenir avant que le disque ne devienne inaccessible.
Tableau de diagnostic des erreurs StorPort, storahci, stornvme et iaStor
Les erreurs StorPort, storahci, stornvme et iaStor ont souvent des causes similaires, mais les vérifications à effectuer diffèrent selon le pilote concerné et les symptômes observés. Le tableau ci-dessous vous permet d’identifier rapidement l’origine probable du problème.
Erreur ou symptôme
Cause probable
Action recommandée
Erreur StorPort
Problème de communication avec le contrôleur de stockage
Vérifiez les pilotes du contrôleur, le firmware du SSD et les connexions.
Erreur storahci
Pilote AHCI, câble SATA ou contrôleur SATA
Mettez à jour les pilotes du chipset et contrôlez les câbles SATA.
Erreur stornvme
SSD NVMe, pilote NVMe ou firmware
Vérifiez le firmware du SSD et le connecteur M.2.
Erreur iaStor
Pilote Intel Rapid Storage Technology (RST)
Mettez à jour Intel RST et les pilotes du chipset.
Les erreurs apparaissent après une mise à jour de Windows
Incompatibilité d’un pilote
Installez le dernier pilote du constructeur ou revenez à la version précédente si nécessaire.
Le disque disparaît puis réapparaît
Mauvais contact, câble défectueux ou contrôleur instable
Vérifiez les connexions SATA, NVMe ou USB.
Des erreurs Disk ou NTFS sont également présentes
Le problème ne concerne plus uniquement le pilote de stockage
Effectuez un diagnostic complet de l’état du disque.
AnalysePC détecte des erreurs de stockage répétées
Anomalies récurrentes dans les journaux Windows
Vérifiez les pilotes, les connexions et l’état SMART du disque.
Le SMART est dégradé ou le disque présente d’autres symptômes
Défaillance matérielle du disque
Sauvegardez immédiatement les données et envisagez le remplacement du disque.
À retenir : dans la majorité des cas, les erreurs StorPort, storahci, stornvme ou iaStor sont liées à un problème de communication entre Windows et le périphérique de stockage. Avant de remplacer un disque, vérifiez toujours les pilotes du contrôleur, le firmware, les connexions et l’état de santé du disque afin d’identifier précisément l’origine du problème.
Un disque dur qui fait du bruit n’est pas forcément en panne, mais certains sons doivent vous alerter. Des clics réguliers, des claquements, des grattements ou des bips peuvent révéler une usure mécanique, un problème d’alimentation ou une défaillance imminente. À l’inverse, un léger ronronnement ou quelques cliquetis pendant les accès aux données sont généralement normaux sur un disque dur mécanique (HDD).
Dans ce guide, vous apprendrez à identifier les différents bruits émis par un disque dur, à distinguer un fonctionnement normal d’un signe de panne, à vérifier si le bruit provient réellement du disque et à déterminer quand il est nécessaire de sauvegarder vos données ou de remplacer le disque.
Quels sont les bruits normaux et anormaux d’un disque dur ?
Contrairement à un SSD, un disque dur mécanique (HDD) contient des plateaux qui tournent à grande vitesse ainsi qu’une tête de lecture qui se déplace en permanence. Il est donc normal qu’un disque dur produise un léger bruit de fonctionnement.
En revanche, certains bruits inhabituels peuvent annoncer une usure mécanique, un problème d’alimentation, des vibrations ou une panne imminente. Savoir les reconnaître permet souvent d’éviter une perte de données.
Important : ce guide concerne les disques durs mécaniques (HDD). Un SSD est totalement silencieux. Si votre ordinateur est équipé uniquement de SSD, le bruit provient probablement d’un autre composant (ventilateur, alimentation, pompe de watercooling, etc.).
Le tableau ci-dessous présente les bruits les plus fréquents et leur signification.
Bruit entendu
Est-ce normal ?
Cause probable
Léger ronronnement continu
Oui
Rotation normale des plateaux du disque.
Petits cliquetis occasionnels pendant une copie de fichiers
Oui
Déplacement normal de la tête de lecture.
Vibrations du boîtier
Généralement oui
Vibrations transmises par le disque au châssis ou au support.
Clic régulier toutes les quelques secondes (« clic-clic »)
Non
Tête de lecture en difficulté ou panne mécanique imminente.
Claquement fort au démarrage
Non
Difficulté d’initialisation ou défaillance mécanique.
Grattement continu
Non
Problème de lecture ou contact anormal de la tête avec les plateaux.
Bip ou sifflement inhabituel
Non
Blocage mécanique, alimentation insuffisante ou panne du disque.
Bruit qui augmente avec les ralentissements ou les blocages
Non
Le disque rencontre probablement des erreurs de lecture ou des secteurs défectueux.
Un bruit inhabituel ne signifie pas systématiquement que le disque est hors service. Il peut également être provoqué par des vibrations du boîtier, un support mal fixé ou une alimentation insuffisante, notamment sur un disque dur externe.
En revanche, si le bruit s’accompagne de ralentissements, de fichiers inaccessibles, d’erreurs de stockage ou du message « Windows a détecté un problème de disque dur », il est recommandé de sauvegarder immédiatement vos données puis de vérifier l’état SMART du disque avant qu’une panne définitive ne survienne.
Identifier le type de bruit
Tous les bruits émis par un disque dur (HDD) n’ont pas la même signification. Certains correspondent à un fonctionnement normal, tandis que d’autres peuvent révéler une usure mécanique ou une panne imminente.
Avant d’effectuer des vérifications, essayez d’identifier le bruit que vous entendez en vous aidant du tableau ci-dessous.
Bruit entendu
Description
Gravité
Ronronnement continu
Léger bruit de rotation des plateaux.
Faible
Cliquetis occasionnels
Bruit lors des lectures ou écritures intensives.
Faible
Vibrations
Le disque fait vibrer le boîtier ou le bureau.
À vérifier
Clic régulier (« clic-clic »)
Bruit répété à intervalles réguliers, souvent appelé Click of Death.
Élevée
Claquement au démarrage
Un ou plusieurs claquements lors de la mise sous tension.
Élevée
Grattement continu
Bruit de frottement ou de lecture anormal pendant plusieurs secondes.
Élevée
Bip ou sifflement
Le disque tente de démarrer mais semble bloqué.
Élevée
Bruit accompagné de ralentissements ou de blocages
Les performances chutent en même temps que le bruit apparaît.
Très élevée
Les symptômes associés permettent également d’affiner le diagnostic.
Le bruit est accompagné de…
Cause probable
Aucun autre symptôme
Fonctionnement normal ou vibrations du boîtier.
Ralentissements importants
Erreurs de lecture ou secteurs défectueux.
Fichiers inaccessibles
Corruption du système de fichiers ou défaillance du disque.
Message « Windows a détecté un problème de disque dur »
SMART signale une dégradation du disque.
Erreurs de stockage dans l’Observateur d’événements ou AnalysePC
Défaillance du disque, du contrôleur ou problème de connexion.
Le disque disparaît puis réapparaît
Câble SATA/USB défectueux, alimentation instable ou panne du disque.
Conseil : si le disque produit un clic répétitif, un claquement, un grattement ou un bip, évitez de continuer à l’utiliser. Sauvegardez immédiatement vos données si le disque est encore accessible, puis vérifiez son état SMART. Ces bruits sont souvent les premiers signes d’une défaillance mécanique.
Arbre des solutions : quel bruit entend votre disque dur ?
Avant de conclure que votre disque dur est en panne, commencez par vérifier que le bruit provient bien du HDD. Un ventilateur, l’alimentation, une pompe de watercooling ou une vibration du boîtier peuvent produire des sons similaires.
Suivez ensuite cet arbre de décision :
Le bruit provient-il bien du disque dur ?
Non : vérifiez les ventilateurs, l’alimentation, le boîtier et les câbles.
Oui : poursuivez le diagnostic.
Le disque est-il détecté dans Windows ou dans le BIOS/UEFI ?
Non : une panne mécanique ou électronique est probable. Évitez de multiplier les tentatives de démarrage et sauvegardez les données si le disque redevient accessible.
Oui : identifiez le type de bruit.
Quel bruit entendez-vous ?
Bruit entendu
Niveau de gravité
Que faire ?
Ronronnement continu
Faible
Bruit normal de rotation des plateaux.
Cliquetis occasionnels pendant les accès
Faible
Comportement généralement normal pendant les lectures et écritures.
Vibrations du boîtier ou du bureau
Moyen
Vérifiez la fixation du disque, les supports antivibrations, les câbles et le boîtier.
Clic régulier “clic-clic”
Élevé
Sauvegardez immédiatement les données : une défaillance mécanique est probable.
Claquement au démarrage
Élevé
Le disque peut rencontrer un problème d’initialisation. Sauvegardez les données et prévoyez son remplacement.
Grattement continu
Élevé
Arrêtez autant que possible d’utiliser le disque et sauvegardez les fichiers accessibles.
Bip ou sifflement inhabituel
Élevé
Vérifiez l’alimentation et les connexions. Une panne mécanique reste possible.
Bruit accompagné de lenteurs ou de blocages
Très élevé
Sauvegardez immédiatement les données puis contrôlez le SMART et les erreurs de stockage.
le système de fichiers avec CHKDSK, après avoir sauvegardé les données importantes ;
les erreurs Disk, Ntfs, StorPort, storahci ou stornvme dans l’Observateur d’événements ;
les câbles SATA ou USB, l’alimentation et les connecteurs ;
les pilotes du contrôleur de stockage et le firmware du disque.
Si le bruit est inhabituel et que plusieurs signes de faiblesse sont présents, ne cherchez pas à prolonger la durée de vie du disque. Sauvegardez les données encore accessibles et remplacez-le avant une panne définitive.
Vérifier si le bruit provient réellement du disque
Avant de conclure que votre disque dur (HDD) est en panne, assurez-vous que le bruit provient bien de celui-ci. Dans un ordinateur, plusieurs composants peuvent produire des sons similaires, notamment les ventilateurs, l’alimentation, un lecteur optique ou encore les vibrations du boîtier.
Quelques vérifications simples permettent généralement d’identifier l’origine du bruit.
Vérification
Pourquoi ?
Que faire ?
Écouter le bruit
Permet de localiser le composant concerné.
Ouvrez le boîtier (PC fixe) ou approchez votre oreille des différentes zones de l’ordinateur.
Vérifier les ventilateurs
Un ventilateur usé ou encrassé peut produire un cliquetis ou un grattement.
Nettoyez-les et vérifiez qu’aucun câble ne touche les pales.
Observer les vibrations
Un disque mal fixé peut faire vibrer le boîtier.
Contrôlez les vis de fixation et utilisez des supports antivibrations si nécessaire.
Débrancher un disque externe USB
Le bruit peut provenir d’un disque externe et non du PC.
Déconnectez-le puis vérifiez si le bruit disparaît.
Tester lors d’un accès au disque
Certains bruits n’apparaissent que pendant les lectures ou écritures.
Copiez un fichier volumineux et observez si le bruit se produit au même moment.
Sur un ordinateur portable, le bruit provient le plus souvent du ventilateur ou, sur les anciens modèles, du disque dur. Sur un PC fixe, il est généralement plus facile d’identifier le composant en ouvrant le boîtier.
Conseil : si votre ordinateur est équipé uniquement de SSD, le bruit ne provient pratiquement jamais du stockage. Orientez plutôt vos recherches vers les ventilateurs, l’alimentation, la pompe d’un système de watercooling ou les vibrations du boîtier.
Une fois que vous avez confirmé que le bruit provient bien du disque dur, vous pouvez vérifier son état SMART et rechercher d’éventuelles erreurs de stockage afin de déterminer si le disque est réellement en train de tomber en panne.
Pourquoi un disque dur fait-il du bruit ?
Contrairement à un SSD, un disque dur mécanique (HDD) possède des plateaux en rotation et une tête de lecture qui se déplace pour lire et écrire les données. Il est donc normal qu’il émette un léger bruit de fonctionnement.
En revanche, lorsque le bruit devient inhabituel, il peut révéler un problème mécanique, une alimentation insuffisante, un mauvais montage ou une défaillance imminente.
Les causes les plus fréquentes sont les suivantes :
Cause
Description
Gravité
Fonctionnement normal
Rotation des plateaux et déplacements de la tête de lecture pendant les accès aux données.
Vibrations du disque
Le disque transmet ses vibrations au boîtier ou au bureau.
Fixation insuffisante
Les vis sont desserrées ou le disque est mal maintenu.
Alimentation insuffisante
Le disque peine à démarrer ou s’arrête puis redémarre, notamment avec un disque externe USB.
Secteurs défectueux
Le disque tente plusieurs lectures successives, ce qui peut produire des clics ou des grattements.
Usure de la tête de lecture
La tête ne parvient plus à accéder correctement aux données et effectue des mouvements répétés.
Défaillance mécanique
Moteur, roulement ou mécanisme interne endommagé.
Les disques durs externes USB peuvent également produire des bruits anormaux lorsqu’ils sont alimentés par un port USB insuffisamment puissant, un câble défectueux ou un boîtier externe en mauvais état.
Attention : un disque dur qui commence à produire des clics réguliers, des claquements, des grattements ou des bips ne doit pas être utilisé inutilement. Si les données sont encore accessibles, sauvegardez-les immédiatement puis vérifiez l’état SMART du disque. Une panne mécanique peut évoluer rapidement et rendre les données définitivement inaccessibles.
Si le bruit est accompagné de ralentissements, de fichiers corrompus, d’erreurs de stockage ou du message « Windows a détecté un problème de disque dur », il est fortement recommandé d’effectuer un diagnostic complet avant que la situation ne s’aggrave.
Le disque présente des signes de faiblesse : que faire ?
Si votre disque dur émet des clics, des claquements, des grattements ou tout autre bruit inhabituel, ne cherchez pas immédiatement à le réparer. L’objectif est d’abord de déterminer s’il s’agit d’un simple dysfonctionnement ou d’une panne imminente.
Situation
Action recommandée
Le disque produit un léger ronronnement ou quelques cliquetis pendant les accès
Il s’agit généralement d’un fonctionnement normal. Continuez simplement à le surveiller.
Le disque émet des clics, des claquements ou des grattements
Sauvegardez immédiatement vos données importantes.
Le disque devient lent ou les fichiers sont difficiles à ouvrir
Vérifiez son état de santé et recherchez d’éventuelles erreurs de stockage.
Windows affiche « Un problème de disque dur a été détecté »
Effectuez un diagnostic complet avant de continuer à utiliser le disque.
Le disque disparaît régulièrement
Vérifiez les câbles, l’alimentation et l’état du disque.
Le bruit s’accompagne d’erreurs SMART ou d’erreurs de stockage
Prévoyez le remplacement du disque.
Pour réaliser un diagnostic complet (état SMART, CHKDSK, erreurs Disk, Ntfs, StorPort, utilisation d’AnalysePC et décision de remplacer ou non le disque), consultez notre guide :
Un disque dur (HDD) qui produit des clics, des claquements ou des grattements n’est pas forcément irréparable. Toutefois, certains signes indiquent qu’il est préférable de ne plus prendre de risques et de remplacer le disque avant qu’une panne définitive ne survienne.
Le tableau ci-dessous vous aide à prendre la bonne décision.
Situation
Remplacer le disque ?
Léger ronronnement ou cliquetis pendant les accès aux données
Non, il s’agit généralement d’un fonctionnement normal.
Vibrations du boîtier uniquement
Non, vérifiez la fixation du disque avant tout.
Clics réguliers, claquements ou grattements répétés
Oui, après avoir sauvegardé vos données.
Le disque disparaît régulièrement ou n’est plus détecté
Oui, après avoir vérifié les câbles et l’alimentation.
Le disque devient très lent et les erreurs se multiplient
Effectuez un diagnostic complet. Si une défaillance est confirmée, remplacez le disque.
Le SMART est en état Mauvais ou des erreurs de stockage sont détectées
Oui, le remplacement est fortement recommandé.
Avant de remplacer votre disque, effectuez un diagnostic complet afin de confirmer l’origine du problème. Vous y apprendrez notamment comment vérifier l’état SMART, analyser les erreurs de stockage, utiliser CHKDSK et déterminer si le disque est réellement en fin de vie.
Si vous souhaitez uniquement apprendre à interpréter les informations SMART (Correct, Prudence, Mauvais, secteurs réalloués, température, etc.), consultez également notre guide dédié sur la vérification de l’état de santé d’un disque dur ou SSD.
Tableau de diagnostic des bruits de disque
Le bruit émis par un disque dur (HDD) constitue souvent un premier indice sur son état de santé. En l’associant aux autres symptômes observés, il est généralement possible d’identifier rapidement la cause la plus probable et de déterminer les vérifications à effectuer.
Bruit ou symptôme
Cause probable
Action recommandée
Léger ronronnement continu
Fonctionnement normal des plateaux
Aucune action particulière, surveillez simplement le disque.
Cliquetis occasionnels pendant les accès aux données
Fonctionnement normal de la tête de lecture
Aucun problème si les performances restent normales.
Vibrations du boîtier
Disque mal fixé ou vibrations transmises au châssis
Vérifiez la fixation du disque et utilisez des supports antivibrations si nécessaire.
Clics réguliers (« clic-clic »)
Défaillance de la tête de lecture ou panne mécanique
Sauvegardez immédiatement les données et effectuez un diagnostic complet.
Claquement au démarrage
Difficulté d’initialisation du disque
Vérifiez son état de santé et préparez son remplacement si nécessaire.
Grattement continu
Erreurs de lecture ou défaillance mécanique
Limitez l’utilisation du disque et sauvegardez vos données.
Bip ou sifflement inhabituel
Blocage mécanique ou alimentation insuffisante
Vérifiez l’alimentation, les câbles et l’état du disque.
Bruit accompagné de ralentissements
Secteurs défectueux, erreurs de stockage ou disque en fin de vie
Vérifiez le SMART, les erreurs de stockage et sauvegardez les données.
Bruit accompagné du message « Windows a détecté un problème de disque dur »
Dégradation détectée par Windows
Réalisez un diagnostic complet avant de continuer à utiliser le disque.
Le disque n’est plus détecté dans Windows ou le BIOS/UEFI
Panne matérielle, électronique ou problème de connexion
Vérifiez les connexions. Si le disque reste inaccessible, envisagez son remplacement ou une récupération de données.
À retenir : un bruit inhabituel, surtout s’il s’accompagne de ralentissements, d’erreurs de stockage ou d’un SMART dégradé, ne doit jamais être ignoré. Plus vous intervenez tôt, plus vous augmentez vos chances de sauvegarder vos données avant une panne définitive.
Depuis quelques jours, plusieurs articles affirment que Microsoft s’apprête à utiliser le TPM (Trusted Platform Module) pour mettre fin aux activations pirates de Windows 11.
Cette information est pourtant trompeuse. La nouvelle fonctionnalité KMS Hardware-Secured annoncée par Microsoft ne concerne pas les PC des particuliers, mais uniquement les serveurs KMS utilisés par les entreprises pour activer leurs parcs Windows.
Autrement dit, Microsoft ne déploie pas un nouveau mécanisme destiné à détecter ou désactiver les copies non officielles de Windows 11 sur les ordinateurs personnels.
D’où vient cette confusion ?
Le 22 juillet 2026, Microsoft a présenté KMS Hardware-Secured, une évolution du Key Management Service (KMS), son système d’activation en volume destiné aux entreprises.
Rapidement, plusieurs médias ont rapproché cette annonce de la fermeture de certaines méthodes d’activation pirate en 2025, laissant entendre que Microsoft utilisait désormais le TPM pour empêcher toute activation illégale de Windows.
En réalité, ces deux sujets sont indépendants. Le nouveau mécanisme annoncé par Microsoft vise uniquement à renforcer la sécurité des serveurs KMS légitimes utilisés dans les organisations.
Qu’est-ce que KMS ?
Le Key Management Service (KMS) est une solution de licences en volume utilisée par les entreprises, les administrations et les établissements scolaires.
Au lieu que chaque ordinateur contacte directement les serveurs de Microsoft pour être activé, les postes Windows s’adressent à un serveur KMS interne qui gère l’activation de l’ensemble du parc informatique.
Ce système est totalement transparent pour les utilisateurs et n’est pas utilisé sur les éditions Windows achetées par les particuliers.
Avec KMS Hardware-Secured, Microsoft demande désormais que le serveur KMS puisse prouver son identité grâce à une puce TPM.
Avant d’autoriser un serveur à distribuer des activations Windows, Microsoft vérifiera notamment :
que le serveur possède bien un TPM compatible ;
que son identité matérielle est authentique ;
que la plateforme n’a pas été modifiée ou compromise.
L’objectif est d’empêcher qu’un faux serveur KMS puisse usurper l’identité d’un serveur légitime et distribuer des activations au sein d’une organisation.
Les particuliers ne sont pas concernés
C’est le point le plus important.
Le TPM de votre PC n’est pas utilisé pour vérifier si votre copie de Windows est officielle.
La nouvelle exigence concerne uniquement le serveur KMS utilisé par les entreprises.
Les ordinateurs Windows personnels, qu’ils soient activés avec une licence OEM, une licence Retail ou une licence numérique, ne sont pas concernés par cette évolution.
Les méthodes d’activation pirate actuelles continuent de fonctionner
Windows Latest rappelle également que les principales méthodes d’activation pirate actuellement utilisées ne reposent généralement pas sur un serveur KMS d’entreprise.
Certaines utilisent une fausse infrastructure KMS locale, tandis que d’autres enregistrent directement une licence numérique ou modifient les mécanismes internes d’activation de Windows.
Dans ces cas, le nouveau contrôle TPM sur les serveurs KMS d’entreprise n’intervient pas, ce qui explique pourquoi cette annonce ne constitue pas une offensive générale contre le piratage de Windows.
Microsoft ne rend pas immédiatement cette nouvelle exigence obligatoire.
À partir d’août 2026, Windows Server 2025 affichera simplement des avertissements indiquant si un serveur KMS est prêt à utiliser KMS Hardware-Secured.
L’obligation d’utiliser un TPM n’entrera en vigueur qu’avec une prochaine version LTSC de Windows Server, dont la date de disponibilité n’a pas encore été annoncée. Les déploiements KMS existants continueront donc à fonctionner normalement d’ici là.
Pourquoi Microsoft met-il en place cette protection ?
L’objectif est avant tout de renforcer la sécurité des infrastructures d’entreprise.
Microsoft explique que des attaquants ont déjà utilisé de faux serveurs KMS pour répondre aux demandes d’activation à la place des serveurs légitimes.
En imposant une attestation matérielle via le TPM, l’entreprise souhaite empêcher l’usurpation d’identité de ces serveurs et garantir que seuls des hôtes KMS authentiques puissent distribuer des licences Windows.
Conclusion
Contrairement à ce qui a été relayé par certains médias, Microsoft ne prépare pas un blocage des copies piratées de Windows 11 grâce au TPM.
La nouveauté KMS Hardware-Secured vise exclusivement les serveurs KMS utilisés dans les environnements professionnels afin de renforcer leur sécurité contre les usurpations d’identité.
Pour les particuliers, cette annonce ne change rien au fonctionnement de Windows ou à son activation. Elle illustre surtout la volonté de Microsoft de mieux protéger les infrastructures de licences en volume des entreprises.
Les Aperçus IA (AI Overviews) sont une nouvelle fonctionnalité de Google Search qui affiche un résumé généré par l’intelligence artificielle en haut des résultats de recherche. Si ces réponses peuvent être pratiques dans certains cas, elles ne font pas l’unanimité. De nombreux utilisateurs préfèrent consulter directement les résultats des sites Web, sans passer par un résumé produit par l’IA.
Contrairement à ce que l’on pourrait penser, Google ne permet pas de désactiver officiellement les Aperçus IA. Il existe toutefois plusieurs solutions pour ne plus les voir : utiliser le mode Web de Google, créer un moteur de recherche personnalisé, masquer ces blocs avec uBlock Origin ou installer une extension dédiée.
Dans ce tutoriel, découvrez les méthodes les plus simples pour supprimer les Aperçus IA de Google et retrouver une page de résultats plus proche de celle des anciennes versions du moteur de recherche.
Désactiver les Aperçus IA avec les paramètres de Google
Pendant longtemps, Google proposait les Aperçus IA (AI Overviews) comme une fonctionnalité expérimentale via Search Labs. Il était alors possible de les désactiver en désactivant l’expérience correspondante.
Aujourd’hui, ce n’est plus le cas. Les Aperçus IA font désormais partie intégrante de Google Search et Google ne propose plus de réglage permettant de les désactiver définitivement pour les utilisateurs.
Si vous consultez les Paramètres de recherche ou Search Labs, vous ne trouverez donc généralement aucune option permettant de masquer les Aperçus IA. Les seuls réglages disponibles concernent les nouvelles fonctionnalités expérimentales encore en phase de test, mais pas les AI Overviews déployés dans le moteur de recherche.
En revanche, plusieurs solutions permettent de ne plus les afficher ou de retrouver des résultats de recherche classiques :
utiliser l’onglet Web de Google ;
créer un moteur de recherche utilisant automatiquement le mode Web ;
Ces méthodes sont détaillées dans les sections suivantes.
Utiliser le mode Web de Google pour masquer l’IA
Le moyen le plus simple d’éviter les Aperçus IA consiste à utiliser le mode Web de Google. Contrairement aux résultats de recherche classiques, ce mode affiche uniquement les liens vers les pages Web, sans les résumés générés par l’intelligence artificielle.
Pour l’utiliser, effectuez une recherche sur Google, puis cliquez sur l’onglet Web situé dans la barre des filtres (Tous, Images, Vidéos, Actualités, etc.). Si cet onglet n’est pas visible, cliquez sur Plus pour le faire apparaître.
Une fois le mode Web sélectionné, Google n’affiche plus les Aperçus IA et présente une liste de résultats plus proche de celle des anciennes versions du moteur de recherche.
L’inconvénient de cette méthode est qu’il faut sélectionner Web à chaque nouvelle recherche. Si vous souhaitez utiliser ce mode en permanence, vous pouvez créer un moteur de recherche personnalisé qui ouvrira directement Google en mode Web, comme expliqué dans la section suivante.
Créer un moteur de recherche sans AI Overviews
Si vous utilisez régulièrement Google, il peut être fastidieux de sélectionner l’onglet Web à chaque recherche. Une solution consiste à créer un moteur de recherche personnalisé qui ouvre directement Google en mode Web, sans afficher les Aperçus IA (AI Overviews).
Le principe est simple : au lieu d’utiliser l’adresse habituelle de Google, le navigateur envoie les recherches vers une URL spécifique qui active automatiquement le mode Web.
L’adresse à utiliser est la suivante :
https://www.google.com/search?udm=14&q=%s
Le paramètre udm=14 indique à Google d’afficher directement les résultats en mode Web, ce qui permet de masquer les Aperçus IA ainsi que d’autres éléments enrichis présents sur la page de résultats.
La plupart des navigateurs modernes permettent d’ajouter un moteur de recherche personnalisé :
Google Chrome
Microsoft Edge
Mozilla Firefox
Brave
Vivaldi
Opera
Après l’avoir défini comme moteur de recherche par défaut, toutes vos recherches utiliseront automatiquement le mode Web, sans que vous ayez à sélectionner l’onglet Web à chaque fois.
Cette solution est particulièrement intéressante si vous préférez retrouver une présentation plus classique des résultats de Google tout en continuant à utiliser votre navigateur habituel.
Masquer les Aperçus IA avec uBlock Origin
Si vous utilisez uBlock Origin, vous pouvez masquer les Aperçus IA (AI Overviews) directement sur la page des résultats de Google. Cette méthode est simple à mettre en œuvre et ne nécessite pas de connaître les filtres cosmétiques utilisés par l’extension.
Le principe consiste à utiliser le sélecteur d’élément (la pipette) d’uBlock Origin afin de masquer le bloc des Aperçus IA.
Effectuez une recherche Google faisant apparaître un Aperçu IA.
Cliquez sur l’icône uBlock Origin dans la barre d’outils de votre navigateur.
Cliquez sur l’icône Pipette (Sélecteur d’élément).
Déplacez le curseur sur le bloc Aperçu IA jusqu’à ce qu’il soit mis en surbrillance.
Cliquez sur ce bloc.
Vérifiez l’aperçu du résultat puis cliquez sur Créer pour enregistrer le filtre.
Répétez l’opération pour supprimer tous les blocs liés à l’aperçu de l’IA
En appliquant un filtre sur tous les blocs, vous pouvez facilement masquer les résultats IA de Google
Vous pouvez supprimer les filtres depuis : Paramètres > Mes Filtres
elle ne nécessite pas de modifier manuellement les filtres d’uBlock Origin ;
vous pouvez facilement supprimer le filtre ultérieurement si vous souhaitez retrouver les Aperçus IA.
Remarque : Google modifie régulièrement la structure de ses pages de résultats. Il est donc possible que le filtre créé avec la pipette cesse de fonctionner après une mise à jour de Google. Dans ce cas, il suffit de répéter l’opération ou d’utiliser un filtre cosmétique mis à jour, présenté dans la section suivante.
Ajouter un filtre personnalisé dans uBlock Origin
Si vous souhaitez une solution plus robuste, vous pouvez ajouter manuellement un filtre cosmétique dans uBlock Origin. Cette méthode évite d’utiliser la pipette et permet de masquer automatiquement les Aperçus IA sur toutes les recherches Google.
Pour cela :
Cliquez sur l’icône uBlock Origin.
Ouvrez le Tableau de bord ().
Accédez à l’onglet Mes filtres.
Ajoutez le filtre adapté à votre version de Google.
Si ce filtre ne fonctionne plus, c’est probablement parce que Google a modifié la structure de ses pages de résultats. Dans ce cas, vous pouvez utiliser le Sélecteur d’élément (la pipette) d’uBlock Origin pour générer automatiquement un nouveau filtre ou consulter les listes de filtres mises à jour par la communauté.
Remarque : Les sélecteurs utilisés pour masquer les Aperçus IA évoluent régulièrement. Il n’existe donc pas de filtre universel qui fonctionne indéfiniment. Les utilisateurs d’uBlock Origin mettent généralement à disposition de nouveaux filtres quelques jours après les modifications apportées par Google.
Utiliser une extension pour supprimer les résultats IA
Si vous ne souhaitez pas modifier les paramètres de votre navigateur ou utiliser un filtre personnalisé dans uBlock Origin, vous pouvez installer une extension dédiée. Plusieurs extensions pour Chrome, Edge et Firefox permettent de masquer automatiquement les Aperçus IA (AI Overviews) ainsi que d’autres éléments générés par l’intelligence artificielle dans les résultats de Google.
Une fois installée, l’extension agit automatiquement : les blocs d’IA sont masqués à chaque recherche, sans intervention de votre part.
Parmi les extensions les plus populaires, on trouve notamment :
Hide Google AI Overviews ;
Bye Bye, Google AI ;
d’autres extensions similaires disponibles sur les boutiques de votre navigateur.
Avant d’installer une extension, prenez quelques précautions :
privilégiez une extension provenant d’un développeur reconnu ;
vérifiez la date de la dernière mise à jour, Google modifiant régulièrement la structure de ses pages de résultats ;
consultez les avis des utilisateurs afin de vous assurer que l’extension fonctionne toujours correctement.
Cette solution est particulièrement adaptée aux utilisateurs qui souhaitent masquer les Aperçus IA sans avoir à créer des filtres manuellement. En revanche, gardez à l’esprit que ces extensions doivent être régulièrement mises à jour pour rester compatibles avec les évolutions de Google Search.
FAQ – Questions fréquentes
Peut-on désactiver définitivement les Aperçus IA de Google ?
Non. Google ne propose actuellement aucune option officielle permettant de désactiver définitivement les Aperçus IA (AI Overviews). En revanche, vous pouvez les éviter en utilisant le mode Web, un moteur de recherche personnalisé, uBlock Origin ou une extension dédiée.
Pourquoi les Aperçus IA apparaissent-ils uniquement sur certaines recherches ?
Les Aperçus IA ne sont pas affichés pour toutes les recherches. Google les génère principalement lorsqu’il estime qu’une réponse synthétique peut être utile, par exemple pour des questions techniques, des comparatifs ou des demandes d’explications.
Les Aperçus IA remplacent-ils les résultats de recherche classiques ?
Non. Les résultats naturels sont toujours présents sous l’Aperçu IA. Celui-ci est simplement affiché en haut de la page afin de résumer les informations provenant de plusieurs sources.
Le mode Web supprime-t-il uniquement les Aperçus IA ?
Non. Le mode Web affiche une version plus épurée des résultats de recherche en supprimant également plusieurs éléments enrichis de Google. Vous obtenez principalement une liste de liens vers des pages Web.
Les méthodes présentées fonctionnent-elles sur tous les navigateurs ?
Oui. Le mode Web est disponible quel que soit le navigateur utilisé. Les moteurs de recherche personnalisés peuvent être créés dans Google Chrome, Microsoft Edge, Mozilla Firefox, Brave, Opera ou Vivaldi. Quant à uBlock Origin, il est compatible avec la plupart des navigateurs basés sur Chromium ainsi qu’avec Firefox.
Les Aperçus IA sont-ils disponibles dans tous les pays ?
Non. Le déploiement des Aperçus IA dépend du pays, de la langue et parfois du type de compte Google utilisé. Certaines fonctionnalités peuvent ne pas être disponibles partout ou être déployées progressivement.
Les filtres uBlock Origin continueront-ils de fonctionner ?
as forcément. Google modifie régulièrement la structure de ses pages de résultats. Un filtre qui fonctionne aujourd’hui peut devenir inefficace après une mise à jour. Il suffit alors de créer un nouveau filtre avec la pipette d’uBlock Origin ou d’utiliser un filtre mis à jour par la communauté.
Quelle est la méthode la plus simple pour ne plus voir les Aperçus IA ?
Si vous ne souhaitez pas installer d’extension, le mode Web est la solution la plus simple et la plus fiable. Pour un usage quotidien, la création d’un moteur de recherche personnalisé utilisant automatiquement ce mode est généralement la méthode la plus pratique.
Les clés USB sont pratiques pour transporter et sauvegarder des fichiers, mais elles ne sont pas à l’abri des pannes. Il arrive qu’une clé USB ne soit plus reconnue par Windows, demande un formatage, affiche une capacité de 0 octet, devienne inaccessible ou refuse de copier des fichiers.
Ces problèmes peuvent avoir de nombreuses origines : système de fichiers corrompu, protection en écriture, partition RAW, secteurs défectueux, clé USB contrefaite, port USB défaillant ou encore une usure de la mémoire flash. Avant de remplacer la clé, il est souvent possible d’identifier la cause du problème et, dans certains cas, de récupérer les données ou de remettre le périphérique en état de fonctionnement.
Dans ce guide, découvrez comment diagnostiquer et réparer une clé USB qui ne fonctionne plus sous Windows 11 et Windows 10. Nous verrons comment vérifier si Windows détecte la clé, réparer le système de fichiers, supprimer une protection en écriture, récupérer les données et déterminer si la clé USB est réellement défectueuse ou doit être remplacée.
Quels sont les symptômes d’une clé USB défaillante ?
Une clé USB qui ne fonctionne plus ne présente pas toujours le même comportement. Selon l’origine du problème, Windows peut ne plus détecter le périphérique, afficher un message d’erreur ou empêcher la copie de fichiers.
Le tableau ci-dessous permet d’identifier rapidement le symptôme rencontré et les causes les plus probables.
Système de fichiers endommagé, corruption de la partition.
La clé USB se déconnecte pendant la copie
Faux contact, câble ou port USB défectueux, alimentation insuffisante.
La capacité de la clé est incorrecte
Faux périphérique (contrefaçon), partition mal configurée, firmware défectueux.
Une fois le symptôme identifié, suivez les étapes de diagnostic ci-dessous afin de déterminer si le problème provient de Windows, de la clé USB, du système de fichiers ou d’une défaillance matérielle.
Vérifier les points les plus simples
Avant d’entreprendre des manipulations plus complexes, commencez par effectuer quelques vérifications de base. Elles permettent souvent de résoudre le problème ou d’identifier rapidement si la panne provient de la clé USB, de Windows ou de l’ordinateur.
Tester un autre port USB
Branchez la clé USB sur un autre port de l’ordinateur.
Si possible, utilisez directement un port situé sur la carte mère (à l’arrière d’un PC fixe) plutôt qu’un hub USB ou une rallonge, qui peuvent provoquer des problèmes d’alimentation ou de connexion.
Essayer la clé USB sur un autre ordinateur
Testez la clé sur un second ordinateur.
Si elle fonctionne correctement, le problème provient probablement de votre installation de Windows ou de vos pilotes.
Si elle n’est reconnue par aucun ordinateur, la clé USB est probablement défectueuse.
Vérifier qu’elle apparaît dans Windows
Même si la clé n’apparaît pas dans l’Explorateur de fichiers, elle peut être détectée par Windows.
Retirez la clé USB, patientez quelques secondes, puis reconnectez-la.
Si elle est reliée via une rallonge ou un hub USB, branchez-la directement sur l’ordinateur afin d’éliminer un éventuel problème de connexion.
Redémarrer Windows
Un simple redémarrage peut résoudre un problème temporaire lié au pilote USB ou à un périphérique resté bloqué après une mise en veille ou une déconnexion incorrecte.
Si la clé USB n’est toujours pas reconnue après ces vérifications, poursuivez avec les étapes de diagnostic ci-dessous afin d’identifier plus précisément l’origine du problème.
Vérifier si Windows détecte la clé USB
Avant d’essayer de réparer votre clé USB, il est important de déterminer si Windows la détecte encore. Une clé peut ne plus apparaître dans l’Explorateur de fichiers tout en étant correctement reconnue par le système.
Les outils suivants permettent d’identifier l’origine du problème.
Vérifier dans l’Explorateur de fichiers
Ouvrez l’Explorateur de fichiers (Windows + E) puis cliquez sur Ce PC.
Si la clé USB apparaît avec une lettre de lecteur (par exemple E: ou F:), Windows la détecte correctement. Le problème provient alors probablement du système de fichiers, des permissions ou des fichiers stockés sur la clé.
En revanche, si elle n’apparaît pas, poursuivez les vérifications.
Vérifier dans la Gestion des disques
La Gestion des disques permet de savoir si Windows détecte le périphérique, même lorsqu’il n’est plus accessible.
Appuyez sur Windows + R.
Tapez :
diskmgmt.msc
Validez.
Plusieurs situations peuvent se présenter :
La clé apparaît avec une partition saine : le problème est probablement lié à la lettre de lecteur ou au système de fichiers.
La partition est en RAW : le système de fichiers est corrompu.
L’espace est non alloué : la partition a été supprimée.
La clé n’apparaît pas du tout : Windows ne détecte pas le périphérique.
Enfin, ouvrez le Gestionnaire de périphériques et développez les catégories :
Lecteurs de disque ;
Contrôleurs de bus USB.
Si un périphérique est affiché avec un triangle jaune, un pilote est probablement absent ou défectueux.
Vous pouvez alors essayer de mettre à jour le pilote ou de le désinstaller, puis reconnecter la clé USB afin que Windows le réinstalle automatiquement.
Si la clé USB n’apparaît ni dans l’Explorateur, ni dans la Gestion des disques, ni dans DiskPart ou le Gestionnaire de périphériques, il est probable que le problème soit d’origine matérielle.
Avant de conclure à une panne, testez-la sur un autre ordinateur. Si elle reste totalement indétectable, son contrôleur électronique ou sa mémoire flash est probablement défectueux.
Vérifier le système de fichiers
Le système de fichiers détermine la manière dont les données sont organisées sur une clé USB. S’il est corrompu ou incompatible, Windows peut ne plus être en mesure d’accéder aux fichiers, demander un formatage ou empêcher la copie de nouveaux fichiers.
Identifier le système de fichiers
Pour connaître le système de fichiers de votre clé USB :
Ouvrez l’Explorateur de fichiers.
Faites un clic droit sur la clé USB, puis Propriétés.
Consultez le champ Système de fichiers.
Les formats les plus courants sont :
FAT32 : compatible avec la plupart des appareils, mais limité à des fichiers de 4 Go maximum.
exFAT : recommandé pour les clés USB récentes et les gros fichiers.
NTFS : système de fichiers de Windows, offrant davantage de fonctionnalités (permissions, compression, chiffrement…).
RAW : le système de fichiers est corrompu ou n’est plus reconnu par Windows. Consultez la section dédiée plus bas dans ce guide
Si Windows demande de formater la clé USB, cela signifie généralement que le système de fichiers est corrompu ou n’est plus reconnu. N’acceptez pas immédiatement le formatage si la clé contient des données importantes. Essayez d’abord de récupérer les fichiers ou de réparer le système de fichiers.
Choisir le bon système de fichiers
Si vous devez reformater votre clé USB, choisissez le système de fichiers en fonction de votre utilisation :
FAT32 : pour une compatibilité maximale avec les anciens appareils.
exFAT : pour les clés USB modernes et les fichiers de plus de 4 Go.
NTFS : pour une utilisation principalement sous Windows.
Si les vérifications précédentes n’ont pas permis de résoudre le problème, il est temps de passer aux opérations de réparation.
Selon l’origine de la panne, plusieurs solutions peuvent être envisagées. Certaines permettent de corriger des erreurs du système de fichiers sans effacer les données, tandis que d’autres nécessitent de réinitialiser complètement la clé USB ou de recréer sa partition.
Avant de commencer, gardez à l’esprit que certaines manipulations, notamment le formatage ou l’utilisation de DiskPart, entraînent la suppression des données présentes sur la clé USB. Si elle contient des fichiers importants, privilégiez d’abord une tentative de récupération.
Les méthodes présentées dans les sections suivantes permettent notamment de :
réparer les erreurs du système de fichiers avec CHKDSK ;
recréer une partition ou réinitialiser entièrement la clé USB avec DiskPart ;
supprimer une protection en écriture ;
reformater la clé USB lorsque le système de fichiers est irrécupérable.
Si malgré ces manipulations la clé USB reste inaccessible, affiche une capacité de 0 octet ou n’est plus détectée par aucun ordinateur, il est probable qu’elle présente une défaillance matérielle. Dans ce cas, reportez-vous aux sections consacrées à la récupération des données et au remplacement de la clé USB.
Réparer le système de fichiers avec CHKDSK
Si votre clé USB est détectée par Windows mais qu’elle est inaccessible, que la copie de fichiers échoue ou que des erreurs apparaissent régulièrement, le système de fichiers est peut-être corrompu.
Dans ce cas, l’utilitaire CHKDSK permet d’analyser le support de stockage et de corriger certaines erreurs logiques, sans nécessiter de formatage.
Lancer une vérification avec CHKDSK
Ouvrez Windows Terminal ou Invite de commandes en tant qu’administrateur, puis exécutez la commande suivante en remplaçant X: par la lettre de votre clé USB :
chkdsk X: /f
L’option /f demande à Windows de réparer automatiquement les erreurs détectées sur le système de fichiers.
Une fois l’analyse terminée, retirez puis reconnectez la clé USB avant de vérifier si le problème est résolu.
Si CHKDSK affiche un message indiquant que le système de fichiers est RAW ou qu’il ne peut pas réparer le volume, cela signifie généralement que la partition est trop endommagée.
Avant de formater la clé USB, essayez de récupérer les données si elles sont importantes.
Tester l’état de la clé USB
Si votre clé USB présente des dysfonctionnements répétés (erreurs de copie, lenteurs, déconnexions, capacité incorrecte…), il est recommandé de vérifier son état avant d’essayer de la réparer.
Selon le modèle de clé USB, il est possible de détecter des erreurs matérielles, des secteurs défectueux ou même une contrefaçon.
Vérifier l’état SMART
Certaines clés USB, notamment les modèles haut de gamme ou les SSD externes, prennent en charge les informations SMART (Self-Monitoring, Analysis and Reporting Technology).
Ces données permettent d’évaluer l’état de santé du support et de détecter d’éventuelles défaillances.
Des outils spécialisés permettent de vérifier que la capacité annoncée correspond bien à la capacité réelle et de détecter les erreurs de lecture ou d’écriture.
Les plus connus sont :
H2testw : vérifie l’intégralité de la mémoire et détecte les clés USB contrefaites.
FakeFlashTest : contrôle rapidement la capacité réelle d’une clé USB.
USB Flash Drive Tester : recherche les erreurs de lecture et d’écriture sur le support.
Si votre clé USB est détectée par Windows mais qu’elle est inaccessible, qu’elle apparaît comme Non allouée, clé USB affiche 0 octet qu’elle ne peut plus être formatée ou que sa partition est endommagée, DiskPart peut permettre de la remettre en état de fonctionnement.
Contrairement à la Gestion des disques, DiskPart est un outil en ligne de commandes qui offre un contrôle complet sur les disques, les partitions et les volumes.
Il permet notamment de :
supprimer une table de partition corrompue ;
effacer complètement une clé USB ;
recréer une ou plusieurs partitions ;
reformater la clé USB ;
supprimer certains attributs comme la protection en écriture.
Attention : la procédure suivante efface toutes les données présentes sur la clé USB. Si elle contient encore des fichiers importants, tentez d’abord une récupération des données avant de continuer.
Réinitialiser complètement une clé USB
Ouvrez Windows Terminal ou Invite de commandes en tant qu’administrateur.
Lancez DiskPart :
diskpart
Affichez la liste des disques :
list disk
list volume
Repérez le numéro correspondant à votre clé USB en vous aidant de sa capacité.
Vérifiez attentivement qu’il s’agit bien de votre clé USB. Une erreur de sélection pourrait effacer un autre disque.
Sélectionnez le disque :
select disk X
Remplacez X par le numéro de votre clé USB.
Effacez complètement la table de partition :
clean
Cette commande supprime toutes les partitions de la clé USB.
Créez une nouvelle partition primaire :
create partition primary
Sélectionnez la partition :
select partition 1
Formatez la clé USB (ici en exFAT) :
format fs=exfat quick
Vous pouvez remplacer exfat par ntfs ou fat32 selon vos besoins.
Attribuez une lettre de lecteur :
assign
Quittez DiskPart :
exit
La clé USB devrait de nouveau apparaître dans l’Explorateur de fichiers.
Si la commande clean échoue
Si DiskPart affiche un message indiquant que le disque est protégé en écriture, vérifiez d’abord que la clé USB ne possède pas un interrupteur de verrouillage.
Vous pouvez également essayer de supprimer l’attribut Read-only avec les commandes suivantes :
attributes disk clear readonly
Puis relancez :
clean
Si la protection en écriture persiste ou si DiskPart ne parvient pas à nettoyer le disque, il est possible que la clé USB soit défectueuse.
Quand utiliser DiskPart ?
DiskPart est particulièrement utile dans les situations suivantes :
la clé USB apparaît comme Non allouée dans la Gestion des disques ;
Windows ne parvient plus à formater le périphérique ;
la partition est corrompue ou a disparu ;
la capacité de la clé est incorrecte après une mauvaise manipulation ;
vous souhaitez repartir d’une clé USB entièrement réinitialisée.
À retenir : DiskPart est l’outil le plus efficace pour réinitialiser complètement une clé USB lorsque les outils graphiques de Windows ne suffisent plus. En revanche, son utilisation entraîne généralement la suppression de toutes les données présentes sur le support.
Les problèmes les plus fréquents avec une clé USB
Supprimer la protection en écriture
Si Windows indique que la clé USB est protégée en écriture, il devient impossible de copier, modifier ou supprimer des fichiers. Vous pouvez uniquement consulter son contenu.
Cette protection peut être provoquée par :
un interrupteur physique présent sur certaines clés USB ou cartes SD ;
une protection activée dans Windows ;
une erreur du système de fichiers ;
une défaillance de la clé USB.
Avant d’effectuer des manipulations avancées, vérifiez les points suivants :
Assurez-vous que la clé USB ne possède pas un interrupteur de verrouillage en position Lock.
Débranchez puis rebranchez la clé USB.
Testez-la sur un autre ordinateur afin de vérifier si la protection est toujours présente.
Vérifiez que le problème ne concerne pas uniquement un fichier ou un dossier.
Si la clé reste protégée en écriture, consultez notre guide dédié. Il explique comment supprimer cette protection avec DiskPart, le Registre Windows ou en corrigeant les erreurs du système de fichiers.
Si votre clé USB apparaît au format RAW, cela signifie que Windows ne reconnaît plus son système de fichiers. Les fichiers deviennent alors inaccessibles et Windows peut demander de formater le périphérique avant de pouvoir l’utiliser.
Ce problème est généralement provoqué par :
un retrait de la clé sans éjection ;
une coupure pendant un transfert de fichiers ;
une corruption du système de fichiers ;
des secteurs défectueux ;
une défaillance de la clé USB.
Avant de formater la clé USB, gardez à l’esprit que les données sont souvent toujours présentes, même si Windows ne peut plus y accéder.
Avant d’effectuer toute réparation, il est recommandé de :
Vérifier si les données sont importantes.
Éviter de formater immédiatement la clé USB.
Tenter de récupérer les fichiers avant toute opération susceptible d’écraser les données.
Vérifier l’état de santé de la clé si elle présente régulièrement ce type de problème.
Si vous n’avez plus besoin des données, vous pourrez ensuite recréer une partition et reformater la clé USB.
Si les transferts de fichiers vers ou depuis votre clé USB sont anormalement lents, le problème peut provenir aussi bien de la clé elle-même que de l’ordinateur ou du port USB utilisé.
Les causes les plus fréquentes sont :
la clé USB est ancienne ou de mauvaise qualité ;
elle est connectée sur un port USB 2.0 au lieu d’un port USB 3.0 ;
le système de fichiers présente des erreurs ;
le support est en fin de vie et contient des secteurs défectueux ;
un antivirus analyse chaque fichier pendant la copie.
Avant de conclure à une panne, effectuez les vérifications suivantes :
Essayez un autre port USB, de préférence USB 3.0 ou USB-C.
Testez la clé USB sur un autre ordinateur.
Vérifiez son état avec CHKDSK si des erreurs apparaissent pendant les copies.
Si la lenteur est récente, contrôlez également l’état de santé de la clé ou du disque.
Comparez les performances avec une autre clé USB afin de déterminer si le problème provient du périphérique ou de l’ordinateur.
Si les performances restent très faibles malgré ces vérifications, il est possible que la clé USB soit en fin de vie.
Si votre clé USB contient des fichiers importants, il est recommandé de tenter une récupération avant d’effectuer des opérations comme un formatage, la suppression des partitions ou une réparation avancée.
Dans de nombreux cas, les données sont toujours présentes sur la clé USB, même si Windows ne parvient plus à les lire.
Les situations les plus courantes sont :
la clé USB apparaît au format RAW ;
Windows demande de formater le périphérique ;
certains fichiers ont disparu ;
la partition n’est plus accessible ;
le système de fichiers est corrompu.
Avant toute tentative de récupération :
Évitez de copier de nouveaux fichiers sur la clé USB.
N’acceptez pas le formatage proposé par Windows si les données sont importantes.
Si possible, réalisez la récupération depuis un autre disque afin d’éviter d’écraser les fichiers.
Selon la nature du problème, plusieurs outils peuvent être utilisés :
PhotoRec : récupération de fichiers après une suppression ou une corruption du système de fichiers.
TestDisk : réparation de partitions et restauration d’une partition perdue.
Recuva : récupération de fichiers supprimés par erreur.
ddrescue : récupérer les données d’un disque endommagé
R-Studio ou DMDE : solutions plus avancées pour les supports fortement endommagés.
Si la clé USB n’est plus détectée par aucun ordinateur ou affiche une capacité de 0 octet, les logiciels de récupération ne pourront généralement pas accéder aux données. Dans ce cas, seul un laboratoire spécialisé peut éventuellement intervenir.
Quand faut-il remplacer la clé USB ?
Une clé USB n’a pas une durée de vie illimitée. Comme tout support de stockage à mémoire flash, elle s’use au fil des écritures et peut finir par présenter des dysfonctionnements.
Si les problèmes deviennent fréquents malgré les réparations, il est généralement préférable de remplacer la clé USB plutôt que de continuer à l’utiliser.
Les signes qui doivent vous alerter sont notamment :
la clé USB n’est plus reconnue sur plusieurs ordinateurs ;
elle se déconnecte régulièrement pendant les transferts ;
des erreurs de copie apparaissent fréquemment (CRC, lecture impossible, fichiers corrompus…) ;
elle affiche une capacité incorrecte ou 0 octet ;
des fichiers disparaissent ou deviennent illisibles ;
les performances sont devenues anormalement faibles ;
les outils de diagnostic détectent des erreurs matérielles.
Si la clé USB contient encore des données accessibles, sauvegardez-les immédiatement sur un autre support avant qu’une panne définitive ne survienne.
En revanche, si le problème provient uniquement d’un système de fichiers corrompu ou d’une partition endommagée, un simple formatage ou une réparation peut suffire à remettre la clé en service.
À retenir : une clé USB qui présente des erreurs de manière répétée n’est plus fiable pour stocker des données importantes. Même si elle fonctionne encore après une réparation, il est recommandé de la remplacer afin d’éviter une perte de données imprévisible.
FAQ – Questions fréquentes
Pourquoi ma clé USB n’est-elle plus reconnue par Windows ?
Une clé USB peut ne plus être reconnue pour plusieurs raisons : un port USB défectueux, un pilote manquant, une partition endommagée, un système de fichiers corrompu ou une panne matérielle de la clé. Commencez par la tester sur un autre port USB et un autre ordinateur afin de déterminer l’origine du problème.
Puis-je réparer une clé USB sans perdre mes données ?
Oui, dans certains cas. Si le problème provient d’erreurs du système de fichiers, l’utilitaire CHKDSK peut les corriger sans effacer les données. En revanche, si vous devez utiliser DiskPart ou reformater la clé USB, les fichiers seront généralement supprimés. Si les données sont importantes, tentez d’abord une récupération.
Pourquoi Windows me demande-t-il de formater ma clé USB ?
Ce message apparaît généralement lorsque Windows ne parvient plus à lire le système de fichiers de la clé USB. Celui-ci peut être corrompu ou apparaître au format RAW. Si la clé contient des fichiers importants, n’acceptez pas immédiatement le formatage et essayez d’abord de récupérer les données.
Que signifie une clé USB au format RAW ?
Une clé USB au format RAW possède un système de fichiers que Windows ne reconnaît plus. Les données sont souvent encore présentes, mais elles deviennent inaccessibles. Avant de reformater la clé USB, il est recommandé d’essayer de récupérer les fichiers. A lire : Disque RAW : définition, causes et que faire (guide complet)
Pourquoi ma clé USB affiche-t-elle une capacité de 0 octet ?
Une capacité de 0 octet peut être le signe d’une table de partition corrompue, d’un contrôleur USB défaillant ou d’une panne de la mémoire flash. Si ce problème persiste sur plusieurs ordinateurs, la clé USB est probablement défectueuse.
DiskPart est utile lorsque la clé USB ne peut plus être formatée, apparaît comme Non allouée, possède une partition corrompue ou nécessite une réinitialisation complète. Attention toutefois : son utilisation entraîne généralement la suppression de toutes les données présentes sur le support.
Comment savoir si ma clé USB est défectueuse ?
Si la clé USB n’est plus reconnue sur plusieurs ordinateurs, se déconnecte régulièrement, affiche des erreurs de copie, une capacité incorrecte ou des performances très faibles, il est probable qu’elle soit en fin de vie. Des outils comme H2testw ou USB Flash Drive Tester permettent également de vérifier son état.
Une clé USB peut-elle s’user ?
Oui. Les clés USB utilisent de la mémoire flash, dont le nombre de cycles d’écriture est limité. Avec le temps, elles peuvent devenir plus lentes, présenter des erreurs de lecture ou d’écriture, voire ne plus être reconnues par Windows.
Quel système de fichiers choisir pour une clé USB ?
Le choix dépend de votre utilisation : – FAT32 : pour une compatibilité maximale avec les anciens appareils, mais limité aux fichiers de 4 Go. – exFAT : recommandé pour les clés USB modernes et les fichiers volumineux. – NTFS : adapté à une utilisation principalement sous Windows et offrant davantage de fonctionnalités (permissions, compression, chiffrement…). A lire : FAT32, exFAT et NTFS : différences et quel formatage choisir sous Windows 11/10
Connexion
