Mémo de la fiche B2-32 : une page A4, à imprimer ou à enregistrer en PDF.
B2-32

Incidents et dépannage méthodique

Distinguer incident, problème et demande, appliquer une démarche de diagnostic couche par couche, utiliser les bons outils et rédiger un compte rendu d'incident clair.

Version en ligne
SIO1 · semestre 14 h (cours + TP)Bloc 2 – SISRMémo · Portail SIO
DÉPANNERavec méthode Qualifierincident · problème · demandepriorité = urgence × impact Démarcherecueillir · reproduire · tester1 changement à la fois Méthodesbas → haut · haut → basdiviser pour régner (ping) Outilsipconfig · ping · tracertnslookup · arp · show Indices169.254 → DHCP · nom → DNSadmin. down → shutdown Tracersymptômes · tests · causesolution · suite à donner

L'essentiel

  1. Incident : service interrompu, à rétablir vite ; problème : cause d'incidents répétés, à éliminer ; demande : besoin standard prévu.
  2. Priorité = urgence × impact, jamais « celui qui appelle le plus fort ».
  3. Trois questions d'ouverture : qui est touché, depuis quand, qu'est-ce qui a changé ?
  4. Cycle : recueillir, reproduire, hypothèses, tester, corriger et vérifier, documenter.
  5. Un seul changement à la fois, et on annule ce qui n'a rien résolu.
  6. De bas en haut pour une panne totale, de haut en bas pour une seule application, diviser pour régner (un ping) pour aller vite.
  7. Le long du chemin, chaque test réussi innocente tout ce qui se trouve avant le point testé.
  8. ping par adresse OK mais pas par nom : c'est le DNS. 169.254.x.x : c'est le DHCP.
  9. « administratively down » = un shutdown a été tapé ; « down / down » seul = pas de signal (câble).
  10. Compte rendu : symptômes, diagnostic (tests et résultats), cause, solution vérifiée, suite à donner.

Les trois questions d'ouverture

À chaque appel, avant de toucher à quoi que ce soit : Qui est touché (une personne, un service, tout le site) ? Depuis quand ? Qu'est-ce qui a changé juste avant (mise à jour, déménagement de bureau, intervention d'un collègue) ? La réponse à la troisième question donne souvent la panne.

Piège classique

Un ping qui échoue ne prouve pas que le réseau est en panne : le pare-feu de Windows bloque les pings entrants par défaut, sur tous les profils, tant que le partage de fichiers et d'imprimantes n'est pas activé. Avant de conclure, teste un autre équipement du même réseau ou un autre protocole (Test-NetConnection 172.16.50.10 -Port 445).

Un bon compte rendu

Il est factuel (des commandes et des résultats, pas « ça marchait pas »), daté, compréhensible par un collègue qui n'était pas là et réutilisable : rédigé ainsi, il alimente la base de connaissances du support.

Commandes clés

Pour…Commandes
Configuration IP du posteipconfig /all (Windows) · ip -br a, ip route (Linux)
Tester la joignabilité et le cheminping · tracert -d (Windows) · traceroute (Linux)
Tester le DNSnslookup nom · ipconfig /flushdns
Tester un serviceTest-NetConnection 172.16.50.10 -Port 445 · ss -tulpn
Couche 2arp -a · show mac address-table
État des équipements Ciscoshow ip interface brief · show cdp neighbors · show running-config