Repères · Tous niveaux · Relecture documentaire : 2 octobre 2026. Les exemples sont génériques ; adapter les noms, versions et chemins avant toute modification.
Écrire ce qui se produit, depuis quand, avec quelle application et après quel changement. « Le PC est lent » peut désigner une attente réseau, un SSD saturé, une mémoire insuffisante ou une application bloquée. Noter heure, message exact et étapes de reproduction. Sauvegarder en priorité les données irremplaçables ; sur un disque qui clique ou disparaît, éviter les tests intensifs et les réparations en écriture.
| Symptôme | Première vérification | Suite si le doute persiste |
|---|---|---|
| Pas de démarrage | Secteur, alimentation, témoins, écran | Configuration minimale, manuel des codes de panne |
| Arrêt en charge | Température, poussière, ventilation | Alimentation et stabilité à paramètres d’origine |
| Lenteur générale | CPU, mémoire, disque dans le gestionnaire | Identifier le processus et l’attente réelle |
| Une application seulement | Journal et version de l’application | Profil neuf ou environnement de test |
| Erreurs de fichiers | Sauvegarde, événements et SMART | Diagnostic fabricant, remplacement ou spécialiste |
| Internet lent | Comparer réseau filaire/local et Internet | Câble, négociation, DNS puis opérateur |
Sous Windows, le Gestionnaire des tâches et le Moniteur de fiabilité permettent de corréler événements et charge. Sous Linux, commencer par uptime, free -h, df -h et journalctl -p err -b. Une charge moyenne élevée n’est pas un pourcentage CPU : elle peut aussi refléter des tâches bloquées sur les entrées/sorties.
Revenir d’abord aux fréquences et tensions normales. Tester la mémoire avec un outil reconnu, sur plusieurs passes si nécessaire, puis isoler barrette et emplacement hors tension. Un test réussi réduit le doute sans prouver une fiabilité absolue. Sur serveur de production, organiser une fenêtre d’arrêt ; ne pas lancer simultanément stress CPU, test disque et sauvegarde.
Consigner la pièce ou le réglage modifié et reproduire la charge initiale. Si la panne disparaît, surveiller encore plusieurs cycles d’usage. Si elle reste aléatoire, joindre les journaux, versions et résultats au dossier d’intervention ; ne pas conclure à une attaque ou à un composant défectueux sur un seul événement.
Retour arrière : restaurer les paramètres connus avant chaque nouvel essai. Un remplacement de disque nécessite une restauration contrôlée, pas une simple confiance dans le clonage d’un support déjà défaillant.
| Symptôme | Premier contrôle | Suite logique |
|---|---|---|
| Aucun voyant | Prise, câble, interrupteur, chargeur | Tester une alimentation compatible, sans ouvrir le bloc |
| Voyants mais pas d’image | Entrée écran, câble, voyant de diagnostic carte mère | Tester écran puis RAM selon manuel |
| Redémarrage sous charge | Température, alimentation, erreurs matérielles | Revenir aux fréquences standard et isoler CPU/GPU |
| Lenteur continue | CPU, RAM, activité disque et espace | Identifier le processus, pas seulement le pourcentage |
| Lenteur uniquement Internet | Liaison et DNS | Suivre le diagnostic réseau |
| Fichiers illisibles | Erreurs I/O, état disque, sauvegarde | Protéger les données avant tout test intensif |
| Plantage après changement | Historique de la modification | Revenir au dernier état connu avec méthode |
Gestionnaire des tâches → Processus : trier par CPU, mémoire et disque, relever le processus et l’heure. Un disque à 100 % d’activité avec peu de Mo/s peut subir de nombreuses petites opérations ou des délais ; cela ne prouve pas à lui seul qu’il est mort. Dans Performances, distinguer mémoire utilisée, disponible et engagée. Le cache mémoire peut être récupérable.
Moniteur de fiabilité : rechercher la date du début de panne, les installations et erreurs correspondantes. Observateur d’événements → Journaux Windows → Système : filtrer sur la période et corréler les messages. Un événement Kernel-Power après coupure indique un arrêt inattendu, pas automatiquement une alimentation défectueuse.
Gestionnaire de périphériques : ouvrir les propriétés d’un périphérique en erreur, relever le code, l’identifiant matériel et la version du pilote. Rechercher le pilote chez le fabricant. Ne pas remplacer tous les pilotes simultanément : on perdrait le lien de causalité.
Le test mémoire doit durer assez longtemps pour couvrir les situations rencontrées ; une passe sans erreur ne garantit pas l’absence de défaut intermittent. En cas d’erreur, noter barrette, emplacement et profil mémoire. Tester aux réglages standard, puis isoler une barrette et un emplacement selon le manuel. Une erreur peut venir de la RAM, du contrôleur ou des réglages.
Les attributs SMART ne se lisent pas de façon identique sur SATA, SAS et NVMe. Examiner l’outil et la documentation du constructeur : erreurs non corrigées, secteurs en attente, usure, erreurs média, température et évolution. Un statut « bon » ne remplace pas la sauvegarde. Un disque qui claque, disparaît ou accumule des erreurs doit être protégé avant des scans lourds.
Choisir un fichier non confidentiel et une opération lente reproductible. Mesurer trois exécutions dans les mêmes conditions. Noter temps, charge, température et erreurs. Changer une seule variable : autre câble, autre port, profil standard ou processus arrêté proprement. Refaire le test, puis rétablir l’état initial si l’hypothèse n’est pas confirmée.
Ne pas utiliser un benchmark destructif sur le support original. chkdsk avec réparation ou une réparation de système de fichiers modifie les structures : avant de l’envisager, connaître l’état du support et disposer d’une copie. Si les données sont uniques et le support physiquement instable, arrêter les essais et faire évaluer une récupération spécialisée.
Écrire « erreurs reproduites avec cette barrette à fréquence standard dans deux emplacements » est plus précis que « le PC plante ». Distinguer fait mesuré, hypothèse et test restant. Après réparation, rejouer l’usage réel et vérifier les sauvegardes ; conserver un historique permet de repérer une panne intermittente.