Méthode de diagnostic d'une panne informatique

Diagnostiquer une panne informatique, c'est passer d'un symptôme (« ça ne marche pas ») à une cause prouvée, en formulant des hypothèses et en les testant une par une, de la plus simple à la plus coûteuse. Une méthode évite de deviner, de tout réinstaller par réflexe ou de tourner en rond. Ce chapitre donne cette méthode, les stratégies pour réduire le champ des recherches, le diagnostic réseau couche par couche et les commandes Windows et Linux qui confirment une cause.

La démarche en six temps

1. Observer et délimiter. Le QQOQCP du chapitre 3 a déjà fait la moitié du travail. Les questions décisives : qui est touché (une personne, un service, tout le monde) ? Depuis quand ? Qu'est-ce qui a changé ?
2. Reproduire. Constate la panne toi-même, avec l'utilisateur ou à distance. Une panne qu'on ne reproduit pas, on ne sait pas vérifier qu'on l'a corrigée. Si elle est intermittente, cherche les conditions où elle apparaît (une heure, un fichier, un site).
3. Lister et classer les hypothèses. Écris toutes les causes possibles, puis classe-les : d'abord celles qui sont probables et rapides à vérifier, ensuite les plus rares et les plus longues.
4. Tester une hypothèse à la fois. Chaque test a un résultat attendu ; note ce que tu obtiens. Si tu changes trois réglages d'un coup et que ça remarche, tu ne sais pas lequel a résolu la panne, et les deux autres ont peut-être créé un nouveau problème.
5. Corriger et vérifier. Applique la correction (ou le contournement), puis vérifie avec l'utilisateur, dans ses conditions réelles.
6. Documenter. La solution dans le ticket ; un article de la base de connaissances si elle peut resservir.

Délimiter : la question qui fait gagner le plus de temps

Avant tout test technique, qui est touché ? divise le champ des recherches.

Comparer avec ce qui marche est l'autre accélérateur : un poste voisin qui imprime, le même compte sur un autre poste, la même application dans un autre navigateur. Chaque comparaison élimine une moitié des causes, comme dans le ticket d'escalade du chapitre 4, où l'erreur « suivait le compte, pas le poste ».

Quatre stratégies pour avancer

La dichotomie est redoutable : avec 32 extensions de navigateur suspectes, en désactiver la moitié, puis la moitié de la moitié restante, trouve la coupable en 5 essais au lieu de 32.

Le diagnostic réseau couche par couche

Les pannes « je n'ai plus Internet » ou « je n'accède plus au serveur » se règlent de bas en haut, en suivant les couches du modèle réseau. Chaque étape a un test et un résultat attendu.

Quelques lectures à connaître :

• une adresse en 169.254.x.x sous Windows signifie que le poste n'a obtenu aucune adresse du serveur DHCP : on cherche du côté du câble, de la prise, du VLAN ou du DHCP ;
• si ping 1.1.1.1 répond mais pas ping www.exemple.fr, la connexion fonctionne et c'est la résolution de noms qui échoue ;
• un ping qui échoue ne prouve pas que la machine est éteinte : beaucoup de pare-feu bloquent ce type de paquet. Test-NetConnection sur le port du service est plus parlant.

Ces notions sont développées dans les cours réseaux : les fondamentaux et services réseau. Pour une panne matérielle d'un poste (alimentation, mémoire, disque, démarrage), la démarche est détaillée dans le chapitre Diagnostiquer une panne du cours Poste de travail.

Lire les journaux

Les journaux disent souvent la cause en toutes lettres, à condition de chercher au bon endroit et à la bonne heure.

Sous Windows, l'Observateur d'événements (eventvwr.msc) range les événements dans les journaux Système, Application et Sécurité. Filtre sur la période de la panne et sur le niveau Erreur. Quelques identifiants utiles dans le journal Système : 41 (redémarrage sans arrêt propre : coupure de courant, plantage), 6008 (l'arrêt précédent était inattendu), 7000, 7023, 7031 et 7034 (un service n'a pas démarré ou s'est arrêté de façon inattendue). En PowerShell :

# Les 20 dernières erreurs du journal Système
Get-WinEvent -FilterHashtable @{ LogName = 'System'; Level = 2 } -MaxEvents 20

# Les arrêts inattendus des 7 derniers jours
Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 41, 6008; StartTime = (Get-Date).AddDays(-7) }

# Les stratégies de groupe appliquées à l'utilisateur et à l'ordinateur
gpresult /r

Le Moniteur de fiabilité (perfmon /rel) montre sur une frise les plantages d'applications, les mises à jour installées et les erreurs matérielles, jour par jour : idéal pour répondre à « qu'est-ce qui a changé ? ».

Sous Linux, journalctl lit le journal de systemd :

# État d'un service et ses dernières lignes de journal
systemctl status apache2

# Journal d'un service depuis une heure donnée
journalctl -u apache2 --since "2026-11-09 08:00"

# Les erreurs depuis le dernier démarrage
journalctl -b -p err

# L'espace disque, cause fréquente de pannes « mystérieuses »
df -h

Les outils de supervision (cours supervision) gardent l'historique des mesures : un disque plein, une mémoire saturée ou un lien coupé à l'heure de la panne se voient sur un graphique.

Les outils du poste Windows

Un diagnostic complet, pas à pas

Ticket 4188, chez Cèdre Habitat : « Impossible d'ouvrir les dossiers du service sur le lecteur S: », M. Diaz, site de Villeurbanne, poste PC-VIL-033, depuis ce matin.

Huit tests, aucun redémarrage inutile, aucune réinstallation. Et la passation à Thomas tient en quatre lignes, parce que chaque test a été noté.

Exercices

Adresse IPv4. . . . . . . . . . . . . .: 169.254.18.203
Masque de sous-réseau. . . . . . . . . : 255.255.0.0
Passerelle par défaut. . . . . . . . . :
DHCP activé . . . . . . . . . . . . . .: Oui