Identifier et définir le problème

Identifier le problème constitue la première étape et est sans doute la plus importante. Un problème mal identifié oriente toutes les étapes suivantes dans la mauvaise direction. L’objectif est d’obtenir une description claire, précise et vérifiée du problème. Le temps consacré à comprendre précisément le problème est rarement perdu, car il concentre tous les efforts suivants sur le véritable symptôme plutôt que sur une supposition.

Commencez par recueillir les faits. Interrogez les utilisateurs concernés, consultez les tableaux de bord de supervision et les journaux, puis effectuez vous-même quelques tests rapides. Cherchez à déterminer l’étendue (un utilisateur, un étage ou tout le site), le moment (quand le problème a commencé) et les symptômes (lenteur, fonctionnement intermittent ou panne totale). Plus les informations sont concrètes, plus votre théorie sera précise.

Une question très utile est : « qu’est-ce qui a changé ? » La plupart des problèmes commencent juste après un changement : nouveau matériel, modification de configuration, mise à jour logicielle ou incident électrique. Interrogez les utilisateurs et consultez les journaux des changements. Si un service fonctionnait hier et échoue aujourd’hui, quelque chose est différent ; trouver cette différence mène souvent directement à la cause. Les changements récents sont les premiers suspects.

Les utilisateurs décrivent les symptômes avec leurs propres mots ; interrogez-les donc attentivement et avec bienveillance. Posez des questions ouvertes : « Que faisiez-vous lorsque le problème est survenu ? » et « Est-ce que quelque chose d’autre a changé ? » Évitez les questions orientées qui suggèrent une fausse réponse. Gardez à l’esprit que les utilisateurs peuvent omettre des détails ou décrire des conséquences plutôt que des causes. La patience et de bonnes questions transforment une plainte vague en données utiles.

Déterminer l’étendue réduit considérablement le champ des recherches. Si un seul PC est concerné, examinez cet appareil ou son câble. Si tout un VLAN est en panne, suspectez un commutateur ou la passerelle. Si le site entier n’a pas accès à internet, concentrez-vous sur la liaison WAN ou sur l’ISP. Adapter l’ampleur des recherches à celle du problème et de sa cause probable fait gagner énormément de temps.

Lorsque c’est possible, reproduisez vous-même le problème. Reproduire la panne confirme qu’elle est réelle, révèle les conditions exactes et vous fournit un test que vous pourrez répéter après la correction. Si un site web échoue pour l’utilisateur, essayez d’y accéder depuis votre propre machine sur le même réseau. Les problèmes intermittents sont plus difficiles à reproduire, mais cette démarche est précieuse pour confirmer la résolution.

CompTIA indique explicitement de remettre en question ce qui semble évident. De nombreuses pannes ont des causes banales : un câble débranché, un appareil éteint, un mot de passe expiré ou la touche Verr. Maj. activée lors de la connexion. Vérifier ces éléments en premier ne prend que quelques secondes et résout souvent le problème. Négliger les vérifications simples parce qu’elles « ne peuvent pas être la cause » est une façon classique de perdre des heures sur une panne insignifiante.

Les appareils signalent souvent eux-mêmes leurs problèmes. Consultez les journaux à la recherche de messages d’erreur, observez les voyants de liaison des interfaces et examinez les alertes de supervision. Un voyant rouge sur un port de commutateur, un événement consigné indiquant « interface inactive » ou un message d’erreur DHCP peut pointer directement vers la panne. Laisser l’équipement vous indiquer ce qu’il détecte complète les informations fournies par l’utilisateur.

Déterminez si vous êtes confronté à un seul problème ou à plusieurs. Il arrive que deux pannes sans rapport surviennent en même temps et ressemblent à un symptôme étrange unique. Si les indices ne correspondent pas à une seule cause, demandez-vous si deux problèmes se chevauchent. Séparer les problèmes enchevêtrés évite de chercher à tout expliquer par une théorie unique et forcée.

Rassemblez vos constatations dans une description précise du problème : qui est concerné, ce qui échoue, quand cela a commencé et quel schéma se dégage. « Depuis le redémarrage du commutateur à 9 heures, tous les téléphones du VLAN 20 ne peuvent plus s’enregistrer » est bien plus utile que « les téléphones sont en panne ». Une bonne description constitue le fondement sur lequel repose le reste de la méthode.

Une définition solide du problème oriente naturellement vers les théories de sa cause. Si le problème a commencé après une modification de configuration sur un seul commutateur et ne concerne que les utilisateurs de ce commutateur, votre première théorie s’impose d’elle-même. Consacrer de vrais efforts à l’identification rend l’élaboration des théories, les tests et la correction bien plus rapides et précis. Définissez correctement le problème, et le reste du dépannage s’enchaînera naturellement.

Testez votre compréhension de l’identification des problèmes.

Vous avez appris à identifier et à définir les problèmes. Points clés :

• Recueillez l’étendue, le moment et les symptômes auprès des utilisateurs, dans les journaux et au moyen de tests.
• Demandez toujours : « qu’est-ce qui a changé ? »
• Déterminez l’étendue pour évaluer la cause probable ; reproduisez le problème lorsque c’est possible.
• Remettez d’abord en question ce qui semble évident.
• Rédigez une description précise du problème qui guidera toutes les étapes suivantes.