Accueil

ITIL®

Lean IT

Pratique

Plus

Crédit image : Fotolia

Incident informatique ou demande de service : que choisir ?

Publié le 8 févr. 2016 par Pascal Delbrayelle

Un utilisateur appelle l'informatique : "je n'arrive pas à me connecter à l'application alors que mon collègue le peut". Dans le cas présent, il rentre de vacances et n'est plus très sûr de son mot de passe.

Est-ce un incident ? Est-ce une demande de service ?

Le point de vue ITIL®

Pour ITIL®, un incident est une "interruption non planifiée d’un service informatique ou une réduction de la qualité d’un service informatique". Est-ce vraiment le cas : le service fonctionne et c'est l'utilisateur qui n'arrive pas à se connecter ? D'autant plus que pour remédier à cette situation, une simple réinitialisation du mot de passe, demande de service classique, y suffira.

Mais, d'un autre côté, pour l'utilisateur, il y a interruption de service car il ne peut pas utiliser son application favorite.

Cette définition très générale ne permet pas de trancher ce cas. D'ailleurs, je n'ai pas trouvé dans ITIL® d'explications concrètes permettant de faire le tri entre incident et demande de service.

Reprenons l'exemple.

Le point de départ est l’utilisateur : il contacte l’informatique car il a un souci. A partir du moment où il exprime une gêne (il ne peut pas travailler normalement), c’est un incident. Là où cela devient ambigü c'est lorsque, par exemple, la cause se situe dans l’entrée d’un mot de passe erroné (plus généralement ce qu’on appelle avec dédain l’interface entre la chaise et le clavier de l’ordinateur). Si l’utilisateur s’exprime en disant : « je n’arrive pas à me connecter » (non-dit : « j’ai oublié mon mot de passe »), nous avons en théorie un incident. Si l’utilisateur s’exprime en disant : « réinitialisez mon mot de passe », cela sera qualifié d'entrée en demande de service. Or, la situation est la même dans les deux cas et, selon les mots employés par l’utilisateur, nous aurons un incident ou une demande de service. Il y a donc un problème de fond.

Changer de paradigme

Il faut distinguer plusieurs choses :

  1. Différencier ce qui est exprimé par l’utilisateur (incident/demande) et la réponse/solution apportée : certains logiciels permettent de catégoriser la requête (incident ou demande) ET la réponse apportée (« réinitialisation du mot de passe » est un code très fréquemment utilisé par exemple).

  2. Le statut d’un ticket peut évoluer pendant son traitement, notamment le diagnostic qui permet d’identifier l’élément qui demande une intervention : sauf s’il n’y a pas d’ambiguïté (« réinitialisez-moi mon mot de passe ») où il s’agit clairement d’une demande, le ticket doit toujours être créé sous un type incident et évoluer si besoin en demande de service, la catégorie initiale de type incident reste enregistrée pour exploiter statistiquement les formulations des utilisateurs basés sur un ressenti, une humeur, un historique perçu, une tentative (réussie ou non) de diagnostic de la part de l’utilisateur, etc., un troisième code peut alors apparaître qui catégorise l’origine diagnostiquée de l’incident (avec une catégorie INCONNUE qui peut déboucher ultérieurement sur la création d’un problème).

  3. Un incident reste un incident, même si l’origine est l’utilisateur lui-même (l’utilisateur ne reconnaît pas avoir oublié son mot de passe et s’exprime en disant que l’informatique ne fonctionne pas car il n’arrive pas à se connecter) : cependant, certaines catégories d’incident devront être sorties des statistiques de calcul du respect des SLAs (les codes à exclure sont à convenir avec les clients et doivent être documentés dans les SLAs) et l’interruption de service (ou la dégradation de la qualité de service) n’est pas comptabilisée si l’origine identifiée d’un incident est l’oubli du mot de passe par l’utilisateur par exemple.

Pour ajouter des liens entre incidents et demandes de service, il arrive fréquemment que des incidents se résolvent en déclenchant une demande de service (et en la traitant). C’est le cas de l’incident « je n’arrive pas à me connecter » qui se résout, après diagnostic, avec une « demande de réinitialisation du mot de passe ».

Trois catégories pour un seul ticket

La création des 3 listes de codes (classifications « type initial d’incident », « type d’origine d’incident » et « type de résolution ») est aléatoire et ne peut pas être établie de but en blanc. Il y a quelques exemples simples (comme l’histoire du mot de passe oublié) mais le reste est plus difficile à établir. Une approche amélioration continue est plus rapide et donne de meilleurs résultats (surtout dans un contexte de succès rapides ou Quick Wins) : exporter une liste de types et de libellés de tickets en partant d’un historique d’incidents significatifs et analyser (travail fastidieux mais très instructif si cela est bien encadré). Cela permet de mieux comprendre les mécanismes de gestion des incidents et permet de mieux paramétrer le logiciel qu’il y a derrière.

Sujet sensible car lié aux statistiques de performance de la DSI

En général, les problématiques évoquées sont liées aux rapports et aux statistiques sur les incidents et les demandes. Elles sont très sensibles car souvent les équipes et la DSI sont notées sur ces résultats. En revanche, lorsque l’utilisateur appelle, à ce moment-là, tout le monde se fiche de savoir si cela rentre dans la case incident ou la case demande de service (cela serait d'ailleurs très malvenu d'y perdre du temps à ce moment-là). A ce propos, l’activité de clôture du ticket d’incident doit inclure une vérification du bon renseignement des 3 codes (et du reste du ticket) pour éviter des désagréments statistiques par la suite et cela améliore aussi en même temps la qualité de l’information stockées dans la base de connaissances (incidents résolus). La clôture d'un incident fait le lien entre la gestion court terme de l'incident et sa gestion à long terme.