Méthode de diagnostic structurée

Diagnostiquer plutôt que deviner

Un réflexe fréquent en support est de proposer immédiatement une solution basée sur une expérience passée similaire, sans vérifier si le contexte actuel correspond réellement. Une méthode structurée évite ce biais.

Du plus simple au plus complexe

flowchart TD
    A[Reproduire le problème] --> B{Reproductible ?}
    B -- Non --> C[Demander plus de détails\nou observer en direct]
    B -- Oui --> D[Isoler la cause :\nutilisateur seul ou plusieurs ?]
    D --> E{Un seul utilisateur ?}
    E -- Oui --> F[Cause probable : poste,\ncompte, configuration locale]
    E -- Non --> G[Cause probable : serveur,\nréseau, application partagée]

Isoler avant de résoudre

La question la plus utile en diagnostic n'est souvent pas "comment réparer", mais "qu'est-ce qui est différent entre ce qui marche et ce qui ne marche pas". Un seul utilisateur affecté oriente vers son poste ou son compte ; plusieurs utilisateurs simultanément orientent vers un serveur ou un service partagé.

Vérifier avant d'affirmer

Un technicien qui affirme "c'est probablement le réseau" sans avoir testé la connectivité perd en crédibilité si l'hypothèse est fausse, et fait perdre du temps en mobilisant les mauvaises personnes (l'équipe réseau) sur un problème qui n'en relève pas.

Cas concret

Un utilisateur signale ne plus pouvoir accéder à un dossier partagé. Plutôt que de supposer immédiatement un problème de droits d'accès, le technicien vérifie d'abord si d'autres utilisateurs du même service ont le même problème (non, uniquement lui), puis si son poste a redémarré récemment ou si sa session a expiré. Il découvre que la connexion réseau du dossier partagé (lecteur mappé) s'est simplement déconnectée après un changement de réseau Wi-Fi, un problème résolu en 30 secondes une fois la vraie cause isolée, plutôt qu'une intervention plus lourde sur les droits d'accès qui n'était pas en cause.

Erreurs fréquentes

• Proposer une solution avant d'avoir isolé la cause, basée sur un cas similaire passé qui peut ne pas s'appliquer ici.
• Ne jamais vérifier si le problème touche un seul utilisateur ou plusieurs, une information qui oriente immédiatement vers la bonne famille de causes.
• Affirmer une hypothèse non vérifiée à l'utilisateur ou à l'équipe technique, créant de la confusion si elle s'avère fausse.

À retenir

• Isoler la cause (un utilisateur seul vs plusieurs) oriente immédiatement vers la bonne famille de solutions.
• La question clé est "qu'est-ce qui est différent" entre ce qui fonctionne et ce qui ne fonctionne pas.
• Ne jamais affirmer une cause sans l'avoir vérifiée concrètement, au risque de perdre du temps et de la crédibilité.

Mini-exercice

Trois utilisateurs d'un même service signalent simultanément ne plus pouvoir accéder à une application interne. Quelle est la première question de diagnostic à se poser, et pourquoi ?

Réponse : est-ce que d'autres utilisateurs, dans d'autres services, sont aussi affectés ? Si oui, la cause est probablement centrale (serveur, application, réseau global) plutôt que locale à ce service précis, orientant immédiatement l'investigation vers les bons systèmes plutôt que vers les postes individuels.