Messages d'erreur Windows/Linux — diagnostic et interventions écrites (PR11)

Ce que tu sauras faire, par écrit

L'épreuve pratique AMPCR se passe uniquement par écrit (consignes officielles 2026-2027/1, p. 3). Face à une capture d'écran, un extrait de journal ou un tableau d'observations, tu dois rédiger ce que tu fais. À la fin de ce cours, tu sais :

1. lire un message d'erreur ou un journal et en relever les éléments utiles (texte exact, code, source, heure, contexte) ;
2. situer le stade où l'erreur survient (firmware, chargeur, système, session, service, application, pilote, périphérique, stockage, réseau) ;
3. distinguer le symptôme, la cause probable, l'hypothèse et le test qui la confirme ;
4. choisir des vérifications non destructives sous Windows et sous Linux, et dire ce qu'elles prouvent ;
5. décrire une réparation adaptée, réversible d'abord, avec sauvegarde et autorisation avant toute action risquée ;
6. confirmer le résultat et rédiger un compte rendu professionnel.

Exigences officielles travaillées dans ce cours

• AP-09 (p. 5) — « Les principaux messages d’erreurs, l’interprétation et les démarches d’intervention y afférant. »
• AP-13 (p. 5) — « Connaître les principaux messages d’erreurs, comment interpréter ceux-ci et comment intervenir si possible. »
• AP-15 (p. 5) — « Dépannage sur les dysfonctionnements courants (hardware ou software). »

Les deux premières puces sont proches mais figurent toutes les deux au PDF : ce cours traite les principaux messages, leur interprétation et la démarche d'intervention (sections 1 à 6). AP-15 est travaillée pour sa partie logicielle (le matériel est en PR06).

Compléments pédagogiques (hors liste officielle des pp. 5-6, signalés comme tels) :

• AP-C01 (complément pédagogique) — « Rédiger une réponse écrite de technicien : décrire une intervention étape par étape et justifier chaque choix. »
• AP-C03 (complément pédagogique) — « Protéger les données du client : sauvegarde préalable, confidentialité et autorisation avant tout effacement ou toute réinstallation. »

Prérequis : la théorie déjà publiée

Relis au besoin les mini-cours du parcours « Théorie » (séparé de ce parcours) : MC07 BIOS, UEFI, POST et démarrage, MC08 Partitionnement, GPT/MBR et formatage, MC10 Windows : administration et commandes, MC11 Linux : bases utiles, MC12 Pilotes et périphériques, MC29 Dépannage matériel, MC30 Dépannage Windows et Linux, MC31 Dépannage réseau, MC36 Rapport technique. Le diagnostic du matériel (PC inerte, POST, bips) est traité dans PR06.

Comment travailler ce cours

Lis la méthode (1), puis les erreurs de démarrage (2), Windows (3), Linux (4) et les cas croisés (5) ; termine par le compte rendu (6). Étudie les cinq cas résolus, fais les 16 exercices corrigés (ici ou dans « S'entraîner », correction après envoi), puis passe le mini-examen noté sur 20 dans l'onglet « Examen blanc ».

Important — les situations, captures, journaux et noms de ce cours sont des supports fictifs construits pour s'entraîner. Les messages et codes reproduits sont ceux des systèmes réels, mais aucun de ces exercices n'est une question officielle ni une question déjà posée par le Jury.

2.1 « Aucun périphérique de démarrage » : quatre messages, une même question

Ces messages viennent du firmware, avant tout chargeur. Ils ne disent pas si la cause est matérielle ou de configuration. Vérifications, dans l'ordre :

1. Le disque est-il détecté par le firmware ? S'il n'apparaît pas : piste matérielle (câble, alimentation, emplacement M.2, disque en panne ; voir PR06).
2. Mode de démarrage : UEFI (disque GPT avec une partition EFI) ou hérité (Legacy/CSM, disque MBR). Un disque MBR ne démarre pas en UEFI seul, et inversement. Une mise à jour ou une remise à zéro du firmware change souvent ce réglage.
3. Ordre de démarrage : la bonne entrée (« Windows Boot Manager », « ubuntu ») est-elle en tête ? Une clé USB ou un nouveau disque est-il passé devant ?
4. Câblage et ports (après un nettoyage, un ajout de disque).
5. Partitions : la partition EFI (ESP) existe-t-elle ? A-t-elle été supprimée ?
6. Chargeur (Windows Boot Manager, BCD, GRUB) : seulement si tout ce qui précède est bon.

Les étapes 1 à 4 sont des réglages et contrôles réversibles ; les étapes 5-6 touchent au disque : sauvegarde et prudence.

2.2 Windows Boot Manager, BCD et WinRE

• Windows Boot Manager est le chargeur de Windows. En UEFI, c'est un fichier de la partition EFI (\EFI\Microsoft\Boot\bootmgfw.efi). Il lit le BCD (Boot Configuration Data, magasin de configuration du démarrage) pour savoir quel Windows lancer.
• Si le BCD est absent ou abîmé, Windows Boot Manager affiche un écran de récupération avec un code, par exemple 0xc000000f (cas 1 ci-dessous).

• WinRE (environnement de récupération Windows) s'ouvre après plusieurs échecs de démarrage, depuis une clé d'installation (« Réparer l'ordinateur ») ou par Maj + Redémarrer.

Prudence avant toute commande qui modifie le démarrage (bootrec /rebuildbcd, bcdboot C:\Windows, diskpart) : identifier d'abord les volumes (lettres différentes dans WinRE), sauvegarder les données si possible, essayer la réparation automatique avant. Dans diskpart, une commande comme clean efface la table de partitions du disque sélectionné : ne jamais l'utiliser pour « réparer » un démarrage.

2.3 Linux : GRUB, initramfs, racine et /etc/fstab

• /etc/fstab liste les systèmes de fichiers à monter au démarrage. Chaque ligne désigne le volume (de préférence par son UUID, identifiant unique du système de fichiers, que donnent blkid ou lsblk -f), le point de montage, le type, les options.
• Un UUID change quand on reformate ou remplace un disque, même si l'on recopie les fichiers : la ligne fstab doit être mise à jour.
• L'option nofail évite le mode d'urgence pour un disque non indispensable au démarrage.
• Avant de modifier fstab : copie de sauvegarde du fichier, puis test par mount -a (ou findmnt --verify) avant de redémarrer.

2.4 MBR, GPT et partition EFI

Règles à écrire dans une réponse d'examen :

• Windows démarre en UEFI sur un disque GPT ou en mode hérité sur un disque MBR ; Windows 11 exige l'UEFI.
• La partition EFI contient les chargeurs de tous les systèmes du disque : la supprimer ou la formater empêche tout démarrage, même si C: ou / sont intacts.
• Une partition « sans lettre » dans la Gestion des disques n'est pas inutile : ce peut être l'ESP, la partition de récupération ou une partition Linux.
• La conversion MBR → GPT (outil mbr2gpt de Windows, après mbr2gpt /validate) modifie la table de partitions : sauvegarde préalable.
• Jamais de formatage ni de réinstallation comme premier réflexe : on vérifie d'abord la détection, le mode, l'ordre, les partitions.

3.1 Écran bleu (BSOD) et STOP code

Un écran bleu (Blue Screen of Death) signale un arrêt du noyau Windows : il redémarre pour protéger le système. À relever :

• le code d'arrêt (STOP code), en texte (DRIVER_IRQL_NOT_LESS_OR_EQUAL) et parfois en hexadécimal (0x000000D1) ;
• la ligne « Ce qui a échoué » quand elle est présente (un fichier .sys, c'est-à-dire un pilote) ;
• le contexte : au démarrage, en jeu, à la mise en veille, après un ajout de matériel ou une mise à jour.

Redémarrage automatique. Par défaut, Windows redémarre aussitôt : l'écran disparaît avant d'être lu. On peut désactiver « Redémarrer automatiquement » (Paramètres système avancés > Démarrage et récupération, ou WinRE > Paramètres). Après coup, le code se retrouve dans le journal Système, événement BugCheck, ID 1001, et un fichier de vidage est écrit (par exemple dans C:\Windows\Minidump), lisible avec l'outil WinDbg de Microsoft.

Les hypothèses classiques — pilote, RAM, disque, mise à jour, température — se testent : mode sans échec (le problème disparaît-il sans les pilotes tiers ?), restaurer le pilote récent, test mémoire, état du disque, relevé de températures, désinstaller la mise à jour.

3.2 Gestionnaire de périphériques (devmgmt.msc)

Le numéro du code est l'élément fiable ; le texte varie un peu selon la version de Windows. L'onglet Pilote permet de mettre à jour, restaurer le pilote précédent (réversible), désactiver ou désinstaller le périphérique.

3.3 Observateur d'événements (eventvwr.msc)

Journaux à connaître : Journaux Windows > Système (noyau, pilotes, services, disques) et Application (programmes), plus Sécurité (ouvertures de session) et Installation. Chaque événement porte un niveau (Critique, Erreur, Avertissement, Information), une date et heure, une source et un ID.

Un événement corrélé n'est pas une preuve de causalité. Deux événements proches dans le temps peuvent être sans lien ; on cherche ce qui se répète à chaque panne, puis on le teste (cas 2, exercice E15).

3.4 Gestion des disques (diskmgmt.msc)

3.5 Services (services.msc)

Chaque service a un statut (En cours d'exécution, Arrêté), un type de démarrage (Automatique, Automatique — début différé, Manuel, Désactivé), un compte d'ouverture de session (onglet Connexion) et des dépendances (onglet Dépendances : un service ne démarre pas si celui dont il dépend est arrêté). Un service qui ne démarre pas se diagnostique avec son message, ses dépendances et le journal Système (Service Control Manager). Exemple : le service Spouleur d'impression arrêté → aucune impression possible.

3.6 Commandes : diagnostic ou modification ?

Précaution chkdsk — sur un disque qui fait du bruit ou signale des blocs défectueux, sauvegarder d'abord : /f et surtout /r sollicitent le disque et modifient le système de fichiers. Un disque mécaniquement défaillant passe par la récupération de données, pas par chkdsk.

3.7 Mises à jour, profils, droits, applications : pas de solution magique

• Échec de Windows Update : relever le code (Paramètres > Windows Update > Historique, journal WindowsUpdateClient), vérifier l'espace disque (0x80070070 = espace insuffisant), la connexion, l'heure du PC ; utiliser l'utilitaire de résolution des problèmes ; ne pas désactiver les mises à jour « pour régler le problème ».
• Profil utilisateur : « Vous êtes connecté avec un profil temporaire » (User Profile Service 1511) — ne rien enregistrer dans cette session, vérifier le dossier C:\Users\<nom>, l'espace et l'état du disque ; sauvegarder avant toute réparation du profil.
• Droits et permissions : « Accès refusé » — l'utilisateur a-t-il les droits sur ce fichier ou ce dossier (onglet Sécurité) ? Un compte standard ne peut pas installer de programme pour tous : on demande l'élévation, on ne rend pas l'utilisateur administrateur.
• Application : message exact, journal Application (Application Error, ID 1000 : programme et module en cause), version, mise à jour récente, droits, espace ; un seul utilisateur ou tous ?

Toujours : périmètre (qui, quoi, depuis quand), journaux, stockage, connexion, permissions. « Nettoyer le registre », « optimiseur miracle » ou « réinstaller par précaution » ne sont pas des diagnostics.

4.1 Messages Linux fréquents

4.2 systemd et journald : lire avant d'agir

Méthode : systemctl status dit que le service a échoué ; le journal du service dit pourquoi. On corrige la cause (configuration, droits, espace, dépendance), on teste la configuration quand l'outil le permet (sshd -t, nginx -t, apachectl configtest), puis on redémarre le service et on vérifie de nouveau.

4.3 Espace disque, montages, réseau : les commandes de lecture

Un fichier supprimé mais encore ouvert par un programme continue d'occuper le disque jusqu'à sa fermeture (lsof +L1 le montre « (deleted) »). On ne supprime pas au hasard dans /var : on identifie ce qui grossit, on décide avec le responsable, on corrige la cause (rotation des journaux par logrotate, purge d'un cache, journalctl --vacuum-size=… pour le journal systemd).

4.4 Droits Unix : lire ls -l avant de toucher

-rw-r----- 1 marc compta 4096 mars 10 08:30 bilan.ods
│└┬┘└┬┘└┬┘   │    │
│ │  │  │    │    └ groupe propriétaire
│ │  │  │    └ utilisateur propriétaire
│ │  │  └ droits des autres : aucun
│ │  └ droits du groupe : lecture
│ └ droits du propriétaire : lecture, écriture
└ type : - fichier, d dossier, l lien

• r lecture, w écriture, x exécution (pour un dossier : droit d'y entrer). En chiffres : r = 4, w = 2, x = 1 (ex. 640 = rw-r-----).
• chmod change les droits (chmod u+x script.sh, chmod 640 bilan.ods) ; chown change le propriétaire et le groupe (chown marc:compta bilan.ods, en administrateur).
• « Permission denied » : vérifier qui est l'utilisateur (id), à qui appartient le fichier et quels droits s'appliquent (propriétaire, groupe ou autres), puis corriger le minimum : ajouter l'utilisateur au bon groupe, donner un droit précis.
• Ne jamais recommander chmod 777 comme dépannage : tout le monde pourrait lire, modifier ou supprimer le fichier, et un script modifiable par tous devient une faille.

4.5 Paquets : apt, dnf et leurs messages

Un gestionnaire de paquets installe les logiciels et leurs dépendances depuis les dépôts de la distribution. Les commandes ne sont pas les mêmes partout :

Sur Ubuntu, une commande absente affiche souvent le paquet à installer : Command 'ifconfig' not found, but can be installed with: sudo apt install net-tools — et l'on peut aussi utiliser la commande actuelle équivalente (ip addr). Ne jamais forcer une installation en cassant les dépendances : lire le message, mettre à jour la liste des paquets, vérifier la version de la distribution.

5.1 Réseau : tests gradués

Ordre des tests : physique (voyants, câble, Wi-Fi) → configuration du poste (ipconfig /all, ip addr) → passerelle (ping) → Internet par adresse IP (ping d'une adresse publique) → noms (nslookup, dig). Le périmètre sépare les causes : un seul poste touché → le poste ou son câble ; tous les postes → DHCP, DNS, routeur, fournisseur d'accès. On distingue ainsi panne de l'OS, du DHCP, du DNS, de la couche physique et du routeur.

5.2 Messages du firmware et du POST

Les bips, LED et codes POST, ainsi que les messages du firmware, dépendent du constructeur de la carte mère ou du PC : on lit le manuel du modèle, on ne se fie pas à une table « universelle » trouvée en ligne. Méthode complète : PR06.

5.3 Pannes intermittentes : chronologie et preuves

Une erreur qui apparaît « de temps en temps » ne se règle pas sur une intuition :

1. Chronologie : date et heure de chaque occurrence, ce que faisait l'utilisateur.
2. Conditions : température, charge (jeu, export, copie), branchement d'un périphérique, moment de la journée.
3. Changements : mises à jour, pilotes, matériel, réglages, déplacements du PC.
4. Preuves : événements du journal à chaque occurrence, relevés, captures.
5. Chercher ce qui se répète à chaque panne ; ce qui n'arrive qu'une fois est une coïncidence jusqu'à preuve du contraire.
6. Reproduire dans les mêmes conditions, puis tester un changement à la fois.

Erreur fréquente — « Ça plante depuis l'orage, c'est l'orage. » Une coïncidence dans le temps n'est pas une preuve : il faut un test.

6.1 Le modèle de compte rendu

6.2 Ce que l'on attend d'une réponse écrite

Une bonne réponse d'épreuve écrite contient :

1. des étapes ordonnées et numérotées, du plus simple au plus invasif ;
2. les outils choisis, nommés précisément (journal, console, commande et option) ;
3. pour chaque test, le résultat attendu et ce qu'il prouve ;
4. une justification de chaque choix (« parce que… ») ;
5. la sécurité des données : sauvegarde et accord avant toute action risquée ;
6. la validation finale.

Exemple de réponse courte et complète. Situation : « Le service d'impression d'un serveur Linux ne démarre plus. » — « 1) Je lis l'état avec systemctl status cups pour savoir s'il est en échec et depuis quand. 2) Je lis son journal avec journalctl -u cups -b pour trouver la cause exacte. 3) Selon le message, je corrige la cause (configuration, droits, espace disque) après avoir copié le fichier modifié. 4) Je redémarre le service (systemctl restart cups) et je vérifie qu'il est active (running). 5) J'imprime une page de test depuis un poste client. 6) Je note la cause et l'action dans le compte rendu. »