La gestion des problèmes ou la réduction du nombre d’incidents

ITIL est actuellement un référentiel IT omniprésent. Sa mise en place, progressive, s'accompagne de plus en plus souvent de la mise en œuvre du processus de gestion des problèmes.

I. La gestion des incidents et des problèmes, selon ITIL.
Il existe divers malentendus sur la gestion des incidents et des problèmes, c'est pourquoi il semble utile de rappeler précisément les principes et surtout leur périmètre.

I.a) La gestion d'incidents Un incident, c'est la perte d'une fonctionnalité (de manière visible ou invisible) du système d'information (SI). Autrement dit, c'est une panne.La gestion des incidents, c'est la mise en place d'un palliatif afin de rendre la fonctionnalité de nouveau disponible, le plus rapidement possible, sans contrainte de qualité.

I.b) La gestion des problèmes
ITIL nous dit que la gestion des problèmes se compose : 
1.
 de l'analyse de la cause sous-jacente d'un incident,
2. de la mise en place d'une solution pérenne.

Traduisons :
 1. ITIL mentionne la cause sous-jacente, c'est-à-dire la cause initiale. Parce qu'un incident est généralement composé de diverses causes, générées en cascade. Si l'on souhaite que l'incident ne se reproduise plus jamais (c'est le but de la gestion des problèmes), alors il faut comprendre quel a été le premier déclencheur, afin d'y répondre d'en un second temps. Sans l'identification de la cause sous-jacente, peu de chance de trouver la solution adéquate. 
 2. La mise en place d'une solution pérenne, c'est la mise en place d'une solution durable, afin que cet incident ne se reproduise plus jamais.

I.c) Exemple simple Afin de bien comprendre la distinction entre la gestion des incidents et la gestion des problèmes, voici un exemple concret : 
1.
 L'outil de supervision remonte une alerte : un service applicatif vient de tomber. 
2. Première étape de résolution de l'incident : se connecter sur le serveur qui héberge le service applicatif concerné.
3.
 Ensuite, nous allons lire les logs applicatifs. Ces dernières nous indiquent que le service ne pouvait plus écrire sur son File System (FS) car il n'y avait plus d'espace disponible.
4. Nous vérifions que le FS est effectivement plein, ce qui est le cas.
5.
 Nous analysons l'arborescence du FS afin de le purger de certains fichiers, obsolètes.
6.
Nous relançons le service applicatif. La gestion de l'incident est terminée. Commence alors la gestion du problème.
7. Tout d'abord il faut analyser la cause initiale. Nous avons eu une alerte de supervision, car le service applicatif est tombé. Celui-ci est tombé car il ne pouvait plus écrire sur le FS. Il ne pouvait plus écrire sur le FS car le FS était plein.

Pourquoi était-il plein ? voici quelques réponses possibles.  
a.
 Le FS est sous-dimensionné,
b.
Un utilisateur a lancé une commande extrêmement gourmande en ressource,
c. Il n'y a pas de mécanisme de purge automatique,

8.
Choisissons pour notre exemple la réponse c. Avec la gestion du problème, nous allons chercher une solution afin que cet incident ne se reproduise plus. Ici, nous allons spécifier un mécanisme de purge, en adéquation avec les besoins applicatifs. Par exemple :
a. Mettre en place un traitement applicatifs, lancé pendant une période creuse, qui viendra compresser tous les fichiers n'ayant pas été modifié depuis plus de deux semaines sur le FS.
b. Rajouter une alerte de supervision, qui avertira lorsque le FS sera plein à 85%.

I.d) Qu'en conclure ?

La gestion du problème va permettre d'apporter une solution afin que cet incident (ainsi que tout incident similaire à notre exemple) ne se reproduise plus.
Au final, le temps passé à analyse la cause sous-jacente, à spécifier, puis mettre en place une solution pérenne sera rentabilisé par rapport à la gestion d'incidents récurrents.

II. Les préjugés sur la gestion des problèmes

II.a) La récurrence de l'incident

Le but de la gestion des problèmes, c'est mettre en place une solution afin qu'un incident ne se reproduise pas.
Mais cela ne signifie pas que l'incident doit être récurrent pour être considéré comme un problème. Les statistiques d'alertes et/ou d'incidents permettent en effet d'identifier des incidents récurrents, qui ont intrinsèquement un fort potentiel de retour sur investissement (RSI, ou ROI en anglais) pour la gestion des problèmes, mais la récurrence n'est qu'un critère parmi d'autres. On peut tout aussi bien :
 · se focaliser sur les incidents majeurs (i.e. incidents ayant un fort impact pour l'utilisateur final),
 · analyser systématiquement tout incident survenu hors période ouvrée (ces derniers engendrent un surcoût en terme de RUN et en terme de tarif horaire),
 · analyser systématiquement tous les incidents impactant une application sensible,
 · analyser systématiquement tous les incidents impactant un périmètre métier critique,
 · etc.
Tout est question de priorité et de contraintes.II.b) L'incident mineur
Il y a une question récurrente que se posent les personnes en charge de la gestion des incidents : "est-ce qu'une panne mineure voire non visible pour l'utilisateur final, doit être déclarée dans l'outil de suivi des incidents". La réponse est oui, pour deux raisons :

 1. La déclaration de l'incident permet d'initialiser le processus d'évaluation du risque opérationnel.
Or, le risque opérationnel n'est pas lié à l'impact dudit incident. Il correspond à une évaluation du coût (financier, fonctionnel, voire d'image de la société vis-à-vis de ses clients) engendré par l'incident dans le pire des cas, c'est-à-dire
   a. au moment de la journée le plus impactant pour les utilisateurs,
   b. avec chacune des causes (techniques ou fonctionnelles) initiées au plus mauvais moment,
   c. avec un délai théorique de résolution de l'incident supérieur à celui spécifié par le contrat de service (SLA en anglais),
   d. etc.
 2. Le second intérêt de déclarer un incident mineur et non visible par l'utilisateur final, c'est qu'une fois l'incident résolu, le ticket sera traité par le processus de gestion des problèmes. Ainsi, il y aura une réponse d'apportée au Responsable de la Sécurité des Systèmes d'Information (RSSI).III. La difficulté du rôle de Problem Manager

La difficulté du rôle de Problem Manager (PM) est avant tout de fédérer chacun des acteurs de la gestion des incidents autour du processus de gestion des problèmes.

Il y a plusieurs problématiques à cela :
 1. Dans un SI, la gestion des incidents est toujours prioritaire, puisque c'est elle qui ramènera le SI en mode nominal.
Il est du devoir du PM de respecter cette règle, tout en sachant faire valoir ses besoins.
 2. Le RSI de la gestion des problèmes n'est pas visible à court terme pour les intervenants.
Il est alors utile pour le PM de mettre en place un tableau de bord qui mesure les RSI. Cela permet ainsi de prouver l'utilité du temps et de l'effort consacrés à la gestion des problèmes. Mon retour d'expérience sur ces Tableaux de bords est également d'y intégrer plusieurs points de vue : non seulement il doit contenir des KPI à destination de la Direction, mais il est fort utile d'y intégrer des KPI à destination des clients et des opérationnels.
Ainsi, la démonstration de la plus-value de la gestion des problèmes sera comprises des tous.

Autour du même sujet