Gestion des problèmes : cause racine, 5 pourquoi, Ishikawa

La gestion des problèmes est la pratique ITIL qui cherche la cause des incidents pour qu'ils ne se reproduisent plus. Là où la gestion des incidents rétablit vite, la gestion des problèmes prend le temps d'analyser, avec des méthodes comme les 5 pourquoi et le diagramme d'Ishikawa, puis enregistre une erreur connue et lance la correction. Ce chapitre explique quand ouvrir un problème, comment remonter à la cause racine et comment rédiger un post-mortem sans blâme.

Quand ouvrir un problème

Un incident résolu par un contournement peut revenir demain. Ouvrir un problème, c'est décider de chercher pourquoi. Les déclencheurs habituels :

• la répétition : le même incident revient (trois fois en un mois est une règle courante) ;
• la série : plusieurs incidents différents semblent avoir un point commun (même salle, même modèle de poste, même mise à jour) ;
• la gravité : après un incident majeur, on ouvre un problème même s'il ne s'est produit qu'une fois ;
• l'anticipation : un éditeur annonce un défaut, la supervision montre une dérive (un disque qui se remplit chaque semaine), une faille est publiée ; on traite la cause avant toute panne. C'est la gestion proactive des problèmes, par opposition à la gestion réactive qui part des incidents passés.

Chez Cèdre Habitat, Lucas remarque en février cinq tickets « Perte du réseau » en un mois, tous au siège, salle de réunion du 1er étage, tous un lundi matin. Chaque fois, le N1 a escaladé au groupe Systèmes et Thomas a réactivé la prise sur le commutateur. Cinq incidents éteints un par un, une même cause probablement. Il ouvre un problème dans GLPI (Assistance > Problèmes) et y lie les cinq tickets.

Incident ou problème : deux temps, deux objectifs

Les étapes de la gestion d'un problème

1. Identifier le problème : repérer la répétition dans les tickets, les statistiques par catégorie, la supervision.
2. Enregistrer le problème et lier les incidents concernés.
3. Analyser : réunir les faits (dates, heures, postes, journaux, changements récents) et remonter à la cause racine.
4. Enregistrer l'erreur connue : la cause et le contournement, pour que le N1 résolve vite les incidents qui arrivent encore.
5. Corriger par un changement (chapitre 6), puis vérifier que les incidents cessent.
6. Clore le problème et mettre à jour la base de connaissances.

Les 5 pourquoi

La méthode des 5 pourquoi, issue de l'industrie automobile japonaise, consiste à partir du symptôme et à demander « pourquoi ? » à chaque réponse, jusqu'à atteindre une cause sur laquelle on peut agir. Le chiffre 5 est un repère : parfois trois questions suffisent, parfois il en faut sept.

Le problème de la salle de réunion, déroulé par Thomas :

Cause racine : une borne Wi-Fi invités manquante. Le contournement (réactiver la prise) restait valable ; la vraie correction est d'installer la borne et d'afficher les consignes de connexion des invités. Réactiver les prises chaque lundi aurait continué indéfiniment.

Chaque réponse doit être vérifiée (dans les journaux du commutateur, l'agenda des réunions, le plan de câblage) et non supposée. Une chaîne de pourquoi construite sur des suppositions mène à une fausse cause.

Le diagramme d'Ishikawa

Les 5 pourquoi suivent un seul fil. Quand plusieurs causes peuvent jouer en même temps, le diagramme d'Ishikawa, aussi appelé diagramme causes-effet ou en arêtes de poisson, aide à n'en oublier aucune. On écrit l'effet à droite, et on range les causes possibles par familles, sur des arêtes.

Dans l'industrie, les familles classiques sont les 5M : matière, matériel, méthode, main-d'œuvre, milieu. En informatique, on les adapte. Voici le diagramme d'un problème de Cèdre Habitat : « Le logiciel de gestion locative est très lent chaque fin de mois ».

Le diagramme ne donne pas la réponse : il fait la liste des hypothèses. On les vérifie ensuite une par une, en commençant par les plus probables et les moins coûteuses à tester. Ici, Nadia trouve dans les journaux du serveur que la sauvegarde complète mensuelle tourne de 8 h à 10 h le dernier jour ouvré du mois, au moment où tous les gestionnaires lancent le calcul des loyers. Elle déplace la sauvegarde à la nuit (un changement standard) et demande à l'éditeur d'examiner la requête sans index.

L'erreur connue et la base des erreurs connues

Dès que la cause est trouvée, le problème devient une erreur connue : on sait pourquoi, même si la correction n'est pas encore faite. On l'enregistre avec son contournement, pour que les incidents qui continuent d'arriver soient résolus en quelques minutes.

L'ensemble de ces fiches forme la base des erreurs connues (known error database, KEDB). Dans GLPI, le problème porte ces informations (champs d'analyse : causes, symptômes, et la solution) et peut donner un article de la base de connaissances (chapitre 11).

Le post-mortem sans blâme

Après un incident majeur ou à la clôture d'un problème important, l'équipe rédige un post-mortem (on dit aussi retour d'expérience, ou RETEX). Il est sans blâme : il cherche ce qui, dans l'organisation, les outils ou les procédures, a rendu l'incident possible, jamais un coupable. Si les gens craignent d'être désignés, ils cachent les erreurs, et l'équipe n'apprend plus rien.

Exemple de résumé : « Le lundi 2 février, de 8 h 40 à 10 h 05 (1 h 25), les 35 salariés du site de Vénissieux n'ont pas eu accès au logiciel de gestion locative. Cause racine : le certificat du lien VPN entre le site et le siège avait expiré ; aucune alerte de supervision ne surveillait sa date d'expiration. Actions : ajouter la surveillance des dates d'expiration des certificats (Thomas, 13 février) ; inscrire les renouvellements au calendrier de l'équipe (Inès, 6 février). »

Note qu'aucune phrase ne dit « Thomas a oublié de renouveler le certificat ». La cause retenue est l'absence d'alerte, et c'est elle qu'on corrige.

Exercices

Exercice 1 sur 4 Faut-il ouvrir un problème ? Réussi À revoir

Pour chaque situation, dis si tu ouvres un problème et pourquoi.

1. Un utilisateur a renversé son café sur son clavier.
2. Depuis la mise à jour de lundi, huit tickets signalent que le logiciel de comptabilité se ferme à l'ouverture d'un état.
3. La messagerie est tombée une seule fois, pendant trois heures, pour tous les salariés.
4. L'éditeur du pare-feu publie un avis : une faille critique touche la version installée chez Cèdre Habitat. Aucun incident n'a eu lieu.

Voir la réponseMasquer la réponse de l'exercice 1

1. Non. Incident isolé à cause évidente ; on remplace le clavier.
2. Oui : série d'incidents avec un point commun probable (la mise à jour). On lie les huit tickets au problème.
3. Oui, malgré l'unique occurrence : c'est un incident majeur, il appelle une analyse et un post-mortem.
4. Oui, en gestion proactive : la cause potentielle d'incidents (de sécurité) est connue avant qu'ils arrivent. La correction passera par un changement, probablement urgent.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 2 sur 4 Les 5 pourquoi Réussi À revoir

Problème : « Chaque matin vers 9 h, l'application de prise de rendez-vous des locataires renvoie des erreurs 500 pendant une dizaine de minutes. » Voici des faits établis par Nadia, dans le désordre :

• le disque du serveur est plein à 100 % chaque matin vers 9 h ;

• l'application ne peut plus écrire ses fichiers temporaires quand le disque est plein, d'où les erreurs 500 ;

• la tâche planifiée de nettoyage des journaux tourne à 9 h 10 et libère de la place ;

• l'export nocturne des rendez-vous écrit un fichier de 6 Go dans le dossier temporaire et ne le supprime pas ;

• le script d'export a été écrit par un prestataire sans étape de nettoyage, et aucune revue n'a été faite avant sa mise en service.

1. Écris la chaîne des 5 pourquoi.
2. Quelle est la cause racine ? Propose une correction et une mesure de prévention.
3. Quel contournement le N1 peut-il appliquer en attendant ?

Voir la réponseMasquer la réponse de l'exercice 2

1. Erreurs 500 → pourquoi ? L'application ne peut plus écrire ses fichiers temporaires → pourquoi ? Le disque est plein vers 9 h → pourquoi ? L'export nocturne laisse un fichier de 6 Go dans le dossier temporaire → pourquoi ? Le script d'export n'a pas d'étape de nettoyage → pourquoi ? Il a été mis en service sans revue.
2. Cause racine : un script mis en production sans revue, donc sans nettoyage de son fichier. Correction : ajouter la suppression du fichier à la fin du script (par un changement). Prévention : une revue et un test de chaque script avant sa mise en service, et une alerte de supervision quand le disque dépasse 80 %. Le nettoyage de 9 h 10 explique pourquoi les erreurs cessent seules, ce n'est pas une cause.
3. Supprimer à la main le fichier d'export de la nuit dans le dossier temporaire, selon une procédure écrite, si le N1 a les droits ; sinon escalader immédiatement au N2, qui le fait.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 3 sur 4 Ishikawa Réussi À revoir

Problème : « Les appels au centre de services sont souvent coupés au bout de quelques minutes. » Range ces causes possibles dans les familles matériel, logiciel, réseau, méthodes, personnes, environnement :

a. le casque d'un technicien a un câble abîmé ; b. la version du logiciel de téléphonie n'est pas à jour ; c. le lien Internet du siège sature à certaines heures ; d. la règle de renvoi des appels raccroche après 5 minutes d'attente ; e. les appels sont mis en attente sans prévenir l'appelant ; f. des travaux dans l'immeuble coupent ponctuellement le courant.

Voir la réponseMasquer la réponse de l'exercice 3

• Matériel : a.
• Logiciel : b.
• Réseau : c.
• Méthodes : d (une règle de configuration décidée par l'organisation ; on peut aussi la ranger en logiciel si on la voit comme un réglage, l'essentiel est de ne pas l'oublier).
• Personnes : e.
• Environnement : f.

Ensuite, on vérifie chaque hypothèse : les journaux de l'autocommutateur montrent-ils des coupures à 5 minutes pile ? Si oui, d est la piste la plus probable.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 4 sur 4 Un post-mortem à corriger Réussi À revoir

Voici un extrait de post-mortem. Repère ce qui ne respecte pas l'esprit sans blâme et réécris ces passages.

« Cause : Lucas a lancé la mise à jour du serveur d'impression en pleine journée, ce qui a bloqué toutes les impressions pendant 40 minutes. Lucas aurait dû attendre le soir. Action : rappeler à Lucas les horaires. »

Voir la réponseMasquer la réponse de l'exercice 4

Le texte désigne une personne et propose une action qui ne change rien au système. Réécriture possible :

« Cause : la mise à jour du serveur d'impression a été lancée pendant les heures ouvrées. Aucune règle écrite ne fixait de fenêtre de maintenance pour ce serveur, et l'outil de mise à jour permettait de lancer l'opération à tout moment sans validation. Actions : définir une fenêtre de maintenance pour les serveurs (Inès, 20 mars) ; classer les mises à jour du serveur d'impression en changement standard planifié hors heures ouvrées (Thomas, 27 mars). »

Tu avais trouvé ?

Oui, j'avais bonPas encore