Adopter une démarche structurée pour diagnostiquer une panne : isoler le périmètre, formuler des hypothèses, tester et documenter.
Notions de base en réseau et système (voir fiches Linux et Réseau). Cette fiche complète le processus ITIL de gestion des incidents avec une méthode pratique de diagnostic.
Face à une panne, la tentation est de tester au hasard ('et si je redémarre ?', 'et si je réinstalle ?'). Cette approche perd du temps, masque parfois la cause réelle et ne permet pas de documenter correctement la résolution. Une méthode structurée permet d'être efficace même sur des problèmes inconnus.
| Étape | Objectif | Questions à se poser |
|---|---|---|
| 1. Écouter et reformuler | Comprendre précisément le problème signalé | Que se passe-t-il exactement ? Depuis quand ? Sur quel équipement ? |
| 2. Isoler le périmètre | Déterminer ce qui est affecté et ce qui fonctionne | Un seul utilisateur ou plusieurs ? Un seul service ou tous ? |
| 3. Formuler des hypothèses | Lister les causes possibles, de la plus probable à la moins probable | Qu'est-ce qui a changé récemment ? Quelle est la cause la plus fréquente pour ce symptôme ? |
| 4. Tester méthodiquement | Vérifier chaque hypothèse une par une | Comment confirmer ou infirmer cette hypothèse rapidement ? |
| 5. Documenter la résolution | Capitaliser la solution pour soi et les collègues | Quelle était la cause réelle ? Comment l'a-t-on corrigée ? |
La dichotomie consiste à diviser le système en deux parties et déterminer dans laquelle se trouve le problème, puis répéter l'opération jusqu'à isoler la cause exacte. C'est très efficace sur les problèmes réseau.
Exemple — "Je n'ai pas accès au site intranet" Étape 1 : Le PC a-t-il accès à Internet ? OUI → le problème n'est pas la connectivité réseau locale NON → problème de connexion réseau (câble, WiFi, DHCP) Étape 2 (si OUI) : Le ping vers le serveur intranet répond-il ? OUI → le serveur est accessible au niveau réseau (couche 3) NON → problème de routage, pare-feu, ou serveur éteint Étape 3 (si OUI au ping) : Le port 80/443 du serveur répond-il ? OUI → le service web tourne, le problème est applicatif NON → le service web est arrêté ou bloqué par un pare-feu local → On a isolé le problème en 3 étapes au lieu de tout vérifier au hasard
| Outil | Usage | Exemple de commande |
|---|---|---|
| ping | Tester la connectivité réseau de base | ping 8.8.8.8 |
| traceroute / tracert | Identifier où se situe une coupure réseau | traceroute google.com |
| ss / netstat | Voir les connexions et ports en écoute | ss -tulpn |
| journalctl | Consulter les logs système sur Linux | journalctl -u nginx -n 50 |
| Gestionnaire des tâches / htop | Identifier un processus qui consomme trop de ressources | htop |
| Observateur d'événements | Consulter les logs Windows | eventvwr.msc |
| Wireshark | Analyser le trafic réseau en détail | Capture sur l'interface concernée |
La loi de la cause la plus probable (parfois appelée 'rasoir d'Occam' en dépannage) dit qu'il faut commencer par tester les causes les plus fréquentes et les plus simples avant les causes rares et complexes.
| Symptôme | Hypothèse probable (à tester d'abord) | Hypothèse rare (à tester en dernier) |
|---|---|---|
| Pas d'accès réseau | Câble débranché, WiFi désactivé | Panne du commutateur central |
| Imprimante ne répond pas | Plus de papier, bourrage, hors ligne | Pilote corrompu, carte réseau HS |
| Site web inaccessible | Service web arrêté, mauvaise URL | Attaque DDoS, certificat SSL expiré |
| PC très lent | Trop de programmes au démarrage, RAM pleine | Disque dur défaillant, virus |
| Situation | Action |
|---|---|
| Le problème dépasse mes compétences techniques | Escalader vers le N2/N3 avec toutes les informations collectées |
| Le problème nécessite un accès que je n'ai pas | Transmettre avec la demande d'accès nécessaire |
| Le délai de résolution SLA est dépassé | Escalader pour respecter l'engagement de service |
| Le problème impacte plusieurs services/utilisateurs | Escalader en priorité, prévenir le responsable |