Foxency
Réseaux et Fondamentaux

Méthodologie de dépannage d'un réseau informatique

Le dépannage efficace n'est pas une affaire d'intuition mais de méthode. Voici une démarche en sept étapes, un arbre de décision et les commandes clés pour isoler une panne réseau rapidement.

Par Rédaction Foxency Publié le 6 min de lecture

Arbre de décision pour diagnostiquer une panne réseau du lien physique jusqu'à l'application

Face à une panne, la tentation est grande de redémarrer un équipement, de modifier une configuration « pour voir » ou de suivre la première intuition. Ces réflexes masquent parfois le symptôme sans traiter la cause, et peuvent aggraver la situation. Une méthode structurée permet de résoudre plus vite, de manière reproductible, et de documenter ce qui s'est passé.

Objectif : disposer d'une démarche de dépannage applicable à n'importe quelle panne réseau, de la collecte des symptômes jusqu'à la documentation finale.

Les sept étapes de la démarche

  1. Définir le problème à partir des symptômes.
  2. Collecter les informations.
  3. Délimiter le périmètre.
  4. Formuler des hypothèses et les classer.
  5. Tester les hypothèses une par une.
  6. Mettre en œuvre la correction et vérifier.
  7. Documenter et prévenir la récidive.

1. Définir le problème

« Le réseau ne marche pas » n'est pas un problème exploitable. Reformulez-le en une phrase précise et vérifiable :

« Depuis 9 h 40, les postes du VLAN 20 (étage 2) ne peuvent pas ouvrir l'application de gestion app.exemple.local, alors que l'accès Internet fonctionne. »

Questions utiles :

  • Quoi ? Quel service, quelle application, quel message d'erreur exact ?
  • Qui ? Un utilisateur, un service, un site, tout le monde ?
  • Où ? Quel bâtiment, quel VLAN, quel type de connexion (filaire, Wi-Fi, VPN) ?
  • Quand ? Depuis quand ? En continu ou par intermittence ? À heure fixe ?
  • Qu'est-ce qui a changé ? Mise à jour, modification de configuration, nouveau matériel, travaux.

La dernière question résout à elle seule une proportion importante des incidents. Les journaux de modifications et les outils de gestion de configuration sont ici précieux.

2. Collecter les informations

Rassemblez des faits, pas des impressions :

  • configuration IP du poste concerné (ipconfig /all, ip addr, ip route) ;
  • état des interfaces et compteurs d'erreurs des équipements ;
  • journaux système et réseau (syslog, observateur d'événements) ;
  • données de supervision : la panne coïncide-t-elle avec un pic de charge, une perte de lien ?
  • comparaison avec un poste qui fonctionne : c'est souvent la méthode la plus rapide pour repérer une différence.

3. Délimiter le périmètre

Déterminez ce qui fonctionne et ce qui ne fonctionne pas. Un tableau simple aide énormément :

Test VLAN 20 VLAN 10 Wi-Fi
Accès Internet ✔ ✔ ✔
Ping passerelle ✔ ✔ ✔
Résolution app.exemple.local ✔ ✔ ✔
Ouverture de l'application ✘ ✔ ✔

Ici, seul le VLAN 20 est touché, et la résolution DNS fonctionne : on oriente la recherche vers le filtrage ou le routage entre le VLAN 20 et le serveur d'application.

4. Formuler des hypothèses

Listez les causes possibles et classez-les selon deux critères : probabilité et facilité de vérification. Commencez par ce qui est à la fois probable et rapide à tester.

Pour l'exemple : une règle de pare-feu modifiée ce matin (probable, rapide à vérifier), une ACL sur l'interface du VLAN 20, une route manquante côté serveur, un problème applicatif lié à l'adresse source.

5. Tester les hypothèses avec une approche par couches

Le modèle OSI fournit le fil conducteur. Selon le contexte, choisissez :

  • De bas en haut quand le symptôme est vague ou touche un seul poste ;
  • De haut en bas quand d'autres applications fonctionnent ;
  • Diviser pour régner : partir du milieu (souvent un ping vers la passerelle) puis monter ou descendre selon le résultat ;
  • Suivre le chemin : tester chaque saut entre la source et la destination ;
  • Comparer avec une configuration qui fonctionne.
Arbre de décision pour le dépannage réseau
Arbre de décision pour le dépannage réseau

Commandes de référence par couche

Couche Linux Windows Cisco IOS
1 – Physique ethtool eth0, ip -s link Get-NetAdapter show interfaces status, show interfaces
2 – Liaison ip neigh, bridge fdb arp -a, Get-NetNeighbor show mac address-table, show vlan brief
3 – Réseau ip addr, ip route get, ping, tracepath ipconfig /all, Test-Connection, tracert show ip interface brief, show ip route
4 – Transport ss -tan, nc -vz Test-NetConnection -Port show access-lists, show ip nat translations
7 – Application dig, curl -v, journaux du service Resolve-DnsName, Invoke-WebRequest show logging

Règle d'or : un seul changement à la fois. Après chaque modification, testez, observez, et annulez si le résultat n'est pas celui attendu. Modifier trois paramètres simultanément empêche de savoir lequel a résolu (ou aggravé) le problème.

Capturer le trafic

Quand les commandes ne suffisent pas, la capture de paquets tranche :

sudo tcpdump -ni eth0 host 10.20.0.57 and host 10.50.0.10 -w capture.pcap

La capture montre objectivement ce qui part, ce qui revient, et ce qui manque. Analysez-la avec Wireshark. Respectez la confidentialité : une capture peut contenir des données personnelles ou sensibles ; limitez-la au strict nécessaire et supprimez-la après usage.

6. Corriger et vérifier

  • Planifiez la correction : impact, risque, retour arrière possible, fenêtre de maintenance si nécessaire.
  • Sauvegardez la configuration avant toute modification.
  • Appliquez la correction, puis vérifiez avec l'utilisateur que le symptôme initial a disparu.
  • Vérifiez aussi l'absence d'effet de bord sur les autres services.

7. Documenter

Rédigez une courte fiche d'incident :

  • symptômes et périmètre ;
  • chronologie ;
  • cause racine ;
  • correction appliquée ;
  • actions préventives (supervision, procédure de modification, mise à jour de la documentation).

Ces fiches constituent une base de connaissances qui accélère la résolution des incidents similaires. Voir Documentation technique et automatisation de l'administration réseau.

Étude de cas complète

Symptôme : les utilisateurs d'une agence se plaignent de lenteurs « sur tout » depuis la veille.

  1. Définition : lenteurs sur toutes les applications, depuis l'agence uniquement, en continu depuis hier 16 h.
  2. Collecte : la supervision montre un lien WAN saturé à 100 % en sortie depuis 16 h.
  3. Périmètre : le siège n'est pas concerné ; tous les postes de l'agence le sont.
  4. Hypothèses : sauvegarde mal planifiée, poste infecté générant du trafic, synchronisation massive de fichiers, mise à jour système.
  5. Tests : l'analyse des flux (NetFlow/IPFIX) montre un serveur de l'agence envoyant un volume important vers le siège : une tâche de réplication reprogrammée par erreur en journée.
  6. Correction : la tâche est replanifiée la nuit ; une règle de QoS limite la réplication.
  7. Documentation : fiche d'incident et ajout d'une alerte sur le taux d'utilisation du lien.

Erreurs courantes

  • Redémarrer avant de diagnostiquer : on perd les indices (tables, journaux, état des sessions).
  • Modifier plusieurs paramètres à la fois.
  • Se fier au témoignage plutôt qu'aux mesures.
  • Oublier le chemin de retour et les équipements intermédiaires (pare-feu, NAT, proxy).
  • Ne pas documenter, et redécouvrir la même panne six mois plus tard.

Conclusion

Une bonne méthode transforme le dépannage en une suite de questions fermées : définir, collecter, délimiter, supposer, tester, corriger, documenter. Associée à l'approche par couches et aux bonnes commandes, elle permet d'isoler la plupart des pannes en quelques minutes. Gardez sous la main la référence des commandes réseau.

Références