Résoudre un problème
De quelque chose ne va pas à résolu ou transmis.
The case
Quelque chose ne va pas. Vous ne savez pas exactement quoi, vous ne savez pas à quel point c’est grave, et ce que vous faites ensuite va soit résoudre le problème, soit vous faire perdre une heure. La plupart des séances de diagnostic échouent non pas parce que les gens sont mauvais pour résoudre les problèmes, mais parce qu’ils ne prennent pas le temps de décrire précisément ce qui se passe.
Le réflexe est de commencer à essayer des choses immédiatement. Redémarrer. Réinstaller. Chercher le symptôme sur Google avant de l’avoir pleinement formulé. Ça marche parfois, par chance — et quand ça ne marche pas, vous avez introduit de nouvelles variables dans une situation déjà peu claire.
Une routine de diagnostic n’est rien d’autre qu’un arbre de décision avec un point d’entrée cohérent. Vous décrivez le problème précisément, vous essayez de le reproduire, vous vérifiez ce qui a changé, vous cherchez de façon délibérée et vous testez les meilleures options dans l’ordre. À chaque embranchement, vous avancez ou vous sautez des étapes. Si vous arrivez au bout sans solution, vous escaladez — mais avec quelque chose d’utile, pas avec un haussement d’épaules.
Ce qu’une routine apporte aussi, c’est une condition d’arrêt. Sans elle, le diagnostic tend à s’étirer pour remplir le temps disponible. Le point de décision à l’étape #12 force la question : est-ce encore une bonne utilisation de votre temps, ou est-ce maintenant le problème de quelqu’un d’autre ?
Résoudre un problème
- Notez les étapes que vous avez suivies, ce que vous attendiez et ce qui s'est passé réellement.
- Essayez de reproduire le problème en suivant votre liste à la lettre. Si vous n'y parvenez pas, revenez au @1 — votre liste n'est pas encore complète.
- Identifiez ce qui a changé récemment. Mise à jour logicielle, nouvelle entrée, modification de configuration, n'importe quoi. Si rien n'a changé, passez au @7.
- Annulez la modification. Revenez à l'état ou à la version précédente. Si vous y êtes parvenu, retournez au @2 pour vérifier si le problème persiste.
- Isolez la modification. Désactivez, déconnectez ou supprimez uniquement ce qui a changé, puis testez à nouveau. L'objectif est de confirmer si cette modification est la cause avant de faire quoi que ce soit d'autre. Si cela résout le problème, passez au @13.
- Réappliquez la modification. Vous avez confirmé qu'elle est en cause. Notez-le. Passez au @13.
- Recherchez le message d'erreur ou le symptôme exact. Copiez l'erreur mot pour mot si elle existe. Les recherches vagues donnent des résultats vagues.
- Notez les solutions qui reviennent le plus souvent dans les résultats. La fréquence est un point de départ, pas une preuve.
- Vérifiez la date de ce que vous vous apprêtez à essayer. Une solution vieille de cinq ans n'est peut-être plus applicable.
- Essayez la solution la plus crédible. Si cela résout le problème, passez au @13.
- Essayez la solution suivante la plus crédible. Si cela résout le problème, passez au @13.
- Décidez : continuer ou escalader. Depuis combien de temps êtes-vous dessus ? Quelle est la criticité ? Si vous escaladez, passez au @14. Si vous continuez, revenez au @10.
- Documentez ce qui a résolu le problème. Une phrase. Vous oublierez, et vous retomberez dessus.
- Rédigez un compte rendu pour la personne qui prend le relais. Ce que vous avez essayé, ce que vous avez écarté, ce que vous suspectez. Passez le relais proprement.
Adaptez-le
L'étape la plus importante est le #13, et c'est celle que la plupart des gens sautent. Résoudre un problème et documenter la solution sont deux tâches distinctes — la seconde est ce qui vous évite de perdre quarante minutes sur la même chose dans six mois. Une phrase suffit.
Les étapes #10 et #11 sont des jalons pour une boucle qui peut s'allonger. Certains problèmes nécessitent dix tentatives avant qu'une solution fonctionne. Ajoutez des étapes si nécessaire et prenez la décision au #12 : continuer ou passer le relais.
La voie d'escalade au #14 mérite d'être prise au sérieux. Un passage de relais clair — ce que vous avez essayé, ce que vous avez écarté — est vraiment utile pour la personne qui reprend le problème. Arriver avec « ça ne marche pas » ne l'est pas.
Si vous utilisez cette routine pour un domaine spécifique — logiciel, matériel, un équipement — adaptez les étapes intermédiaires à votre séquence de diagnostic habituelle. La structure reste la même ; les détails vous appartiennent.