ITIL - Processus de gestion des incidents

Qu’est-ce que la gestion des incidents ?

Définition

ITIL (Information Technology Infrastructure Library) ou « Bibliothèque pour l'infrastructure des technologies de l'information » est un référentiel qui aide à améliorer la gestion des systèmes d’information.

Selon le référentiel ITIL, un incident peut être défini comme tout événement ne faisant pas partie du fonctionnement normal d’un service (ou d’un équipement), et qui cause ou peut causer une son interruption ou une altération de sa qualité. En conséquence, la gestion des incidents permet de rétablir rapidement le fonctionnement normal du service et de minimiser l’impact de ceux-ci sur l’entreprise. L’action doit être menée tout en assurant le niveau de disponibilité et de service défini dans le contrat de services (SLA), à savoir le meilleur niveau possible.

Retenez qu’il s’agit de traiter les conséquences et non les causes.

La gestion des incidents exige :

1. Un accord de niveau de service entre le fournisseur et le client, définissant les priorités d’incidents, les trajectoires d’escalade et les délais d’intervention/résolution.

2. Des modèles qui permettent de résoudre efficacement ces incidents.

3. Une catégorisation des types d’incidents.

4. Un accord sur les statuts et les priorités en cas d’incident.

5. Une mise en place d’un processus de réponse en cas d’incident majeur.

6. Un accord sur l’affectation des rôles de gestion des incidents.

Attention : Ne confondez pas « gestion des incidents » et « gestion des problèmes ». Faites bien la distinction puisque l’objectif de la gestion des incidents est axé sur le niveau de l’utilisateur, elle sert à rétablir un service normal le plus rapidement possible, soit agir « en mode pompier ». Alors que la gestion des problèmes permet de résoudre la cause profonde des incidents dans le but d’empêcher que de futurs incidents ne se produisent.

Classification des incidents

Les incidents sont classés en fonction :

• De leur priorité (faible, moyenne et élevée)

⌑ Les incidents de faible priorité n’interrompent pas les utilisateurs finaux, ils peuvent généralement terminer le travail malgré l'incident.

⌑ Les incidents de priorité moyenne sont des problèmes qui touchent les utilisateurs finaux, mais la perturbation est légère ou brève.

⌑ Les incidents de priorité élevée affectent un grand nombre d’utilisateurs finaux et empêchent le bon fonctionnement d’un système.

⇨ On constate le volume et l’ampleur d'un incident sur une entreprise en mesurant le nombre d’utilisateurs ou le nombre de systèmes touchés par un dysfonctionnement. Lorsqu’un incident présente un impact majeur pour un grand nombre d’utilisateurs, on considère qu’il s’agit d’un incident hautement prioritaire.

• De leur type

⌑ Matériel (Problème de réseaux et autres pannes du système).

⌑ Logiciel (Bug d’application ou problème de disponibilités de service).

⌑ Sécurité (Accès non autorisé d’un domaine ou tout autre menace qui compromet et viole les données).

⇨ Notez tout de même qu’un problème de performances résulte souvent de n’importe quelle combinaison de ces domaines.

Qui est responsable de quoi ?

Le premier niveau de résolution des incidents est le centre de services. Si celui-ci ne parvient pas à résoudre rapidement un incident, une procédure d’escalade est engagée. Cette procédure correspond au transfert de l’incident à un niveau de support supérieur (deuxième, troisième niveau, etc.) composé de spécialistes qui disposent de plus de compétences et de temps pour trouver une solution au dysfonctionnement. La structuration du support informatique autour des niveaux permet de répondre stratégiquement aux besoins de la clientèle, de créer une expérience client positive, de résoudre rapidement les problèmes mineurs, d’améliorer la formation des employés en favorisant la mobilité ascendante, etc.

• Niveau 1 : Il fournit généralement un support ou une assistance rudimentaire grâce à la base de connaissances et de solutions identifiées (CMDB : Configuration management database). Ce niveau comprend l’identification, l’enregistrement, la hiérarchisation et la catégorisation des incidents, ainsi que la décision de passer au niveau deux du soutien si besoin. Il tente donc de résoudre l'incident s’il en est capable, cela permet d’augmenter la satisfaction de l’utilisateur final. Par exemple : un ordinateur ne fonctionne pas, l'utilisateur demande assistance et on l'invite à vérifier si la barre de prise est bien branchée. Ce niveau gère aussi les réinitialisations de mots de passe et les dépannages informatiques.

⇢ L’acteur principal est le « Service Desk ».

• Niveau 2 : Il passe par un processus similaire mais répond à des demandes plus complexes qui nécessitent de plus de formation, de compétences ou d’accès à la sécurité pour être satisfaites. Le support de niveau 2 peut rendre visite à l’utilisateur final si besoin, ce que le personnel du Service Desk ne peut pas faire.

⇢ Les acteurs principaux sont les « techniciens IT ».

• Niveau 3 : Ce niveau concerne les incidents majeurs, ceux qui perturbent réellement le fonctionnement d’une entreprise, comme un problème de réseau. Les techniciens tentent de définir les causes profondes à l’aide de codes et de spécifications. Une fois la cause profonde identifiée, des correctifs aux incidents sont apportés, documentés puis communiqués aux techniciens de niveau 1 et de niveau 2 comme références futures.

⇢ Les acteurs principaux sont « des experts IT, comme les ingénieurs réseaux ».

• Niveau 4 : Les incidents concernés par le niveau 4 relèvent de la responsabilité de services externalisés, soit les fournisseurs. Par exemple, si le logiciel Skype dysfonctionne, seule l'entreprise Microsoft pourra résoudre l’incident.

Notez tout de même que cette structure n’est pas systématique. De nombreuses entreprises adaptent cette hiérarchie et combinent les niveaux de support en fonction de leur capacité de ressources, de leur capacité financière et de leur « philosophie ». Dans certaines entreprises par exemple, les groupes fonctionnels de niveau 1 et de niveau 2 peuvent être gérés par les mêmes techniciens. Tandis que d’autres peuvent préférer combiner les fonctions de niveau 2 et de niveau 3 dans les mêmes groupes.

Quels sont les objectifs de la gestion des incidents ?

• Maintien du niveau de service. Un accord ou contrat SLA offre une définition claire du niveau de service qu’une entreprise doit fournir à sa clientèle. Si une entreprise ne respecte pas un SLA, les conséquences peuvent être importantes pour elle mais aussi pour ses clients. Grâce à la gestion des incidents ITIL, votre entreprise comprendra exactement comment traiter n’importe quel incident, et ceci à tout moment. Vous pourrez aussi utiliser ITIL pour résoudre les incidents avant qu’ils ne deviennent hors de contrôle. Vous minimiserez ainsi l’impact sur le métier client et vous serez assuré que le niveau de service convenu avec l’utilisateur ou le client est bien respecté.

• Augmentation de la satisfaction des utilisateurs finaux. Grâce à la mise en place d'ITIL, votre entreprise dégagera des solutions en amont afin d'éviter des incidents futurs dans la mesure du possible. Si l'incident se produit tout de même, votre entreprise comprendra comment minimiser les interruptions de service et rétablir les services le plus rapidement possible.

• Renforcement de l’efficacité et de la productivité du personnel. ITIL aide les professionnels de la gestion des incidents à découvrir les meilleures façons de traiter ces incidents.

• Optimisation de l’utilisation des ressources matérielles et humaines. Ces ressources, impliquées dans le processus de support seront optimisées et un suivi efficace des incidents sera garanti. Ainsi votre entreprise capitalisera l’expérience des différents techniciens en conservant l’historique des incidents et de leurs solutions. Ce suivi pourra être utilisé conjointement avec des solutions informatiques pour accroître la productivité.

Comment fonctionne le processus de gestion des incidents ?

Étape 1 : Identification de l’incident

Idéalement les incidents sont identifiés à un stade très précoce par la surveillance automatisée des évènements, donc avant même qu’ils n’aient des répercussions sur un utilisateur. Cependant, ce n’est pas toujours le cas. Parfois, les incidents sont identifiés par l’utilisateur touché qui le signale au Service Desk.

Étape 2 : Enregistrement de l’incident

Afin de tenir un registre historique complet, tous les incidents, quelle que soit la méthode utilisée pour les identifier et les signaler au Service Desk, doivent être enregistrés avec tous les détails pertinents, par exemple :

• Numéro incident : Numéro unique renseigné automatiquement par l'outil lors de l'enregistrement de la déclaration.

• Statut de l’incident : État de traitement de l’incident.

• Date de détection de l’incident : Date à laquelle l’incident a été détecté par le déclarant (Date du jour par défaut).

• Déclarant interne : La personne remontant l’incident au sein de l'entreprise.

• Déclarant externe : La personne remontant l’incident n’est pas salariée de l’entreprise.

• Département : Vous définirez le périmètre concerné par l’incident.

• Description de l’incident : Vous indiquerez succinctement en quoi consiste l'incident.

• Pièce jointe : Possibilité d'ajouter des pièces jointes si besoin.

Étape 3 : Classification et priorisation de l’incident

L’attribution de la priorité est essentielle pour déterminer comment, quand et par qui l’incident sera traité.

Une fois enregistré, vous effectuerez une catégorisation de l’incident pour déterminer sa prise en charge, et pour donner la priorité aux ressources d’intervention. Par exemple, si un incident est classé comme une panne de système, l’incident sera considéré comme à priorité élevée, et sera directement confié à un niveau supérieur afin de ne pas perdre de temps.

Pour résumer, vous prioriserez le traitement des incidents en fonction de leur catégorisation, donc de leur urgence et de leur impact sur les utilisateurs finaux.

Vous renseignerez les éléments suivants :

• Catégorie de l’incident

• Périmètre de l'incident

• Source de détection

• Impact

• Priorité (critique, haute, moyenne, faible)

Étape 4 : Recherche et diagnostic de l’incident

Au cours de cette étape, l’équipe mènera son enquête sur l’incident, elle devra décrire le problème le plus précisément possible. L’incident devra être diagnostiqué par toutes les parties concernées et ceci jusqu’à ce que le problème soit résolu. L’enquête et le diagnostic comprendront les mesures suivantes :

• Établir la cause exacte de l’incident.

• Comprendre l’ordre chronologique des évènements.

• Confirmer l’impact complet de l’incident.

• Identifier tout évènement qui aurait pu le déclencher (un changement récent ou une action de l’utilisateur par exemple).

• Rechercher les erreurs connues dans la base de connaissances CMDB afin de trouver rapidement une solution de contournement ou de résolution.

• Rechercher s'il existe des évènements antérieurs similaires (des incidents déjà enregistrés, des erreurs fréquentes, chercher dans la CMDB, dans les journaux d’erreurs, dans les bases de connaissances des fabricants et fournisseurs associés, etc.)

Je vous propose de rédiger une check-list afin de rationaliser le processus d’enquête. L’équipe sera en mesure d’exécuter des diagnostics plus efficacement et de résoudre plus rapidement le problème.

Étape 5 : Affectation ou escalade d’incident

Au cours de cette étape, votre entreprise devra mettre en pratique ce que je vous expliquais précédemment. Initialement, le technicien du service desk tentera de résoudre l’incident. S'il n’est pas en mesure de fournir une solution, l’incident sera élevé au niveau approprié de soutien (niveau deux ou trois).

Si d’aventure un incident s’intensifiait, l’escalade devrait se poursuivre dans la chaîne de gestion. Les cadres supérieurs devraient être avisés de la situation afin qu’ils puissent se préparer à prendre toutes les mesures nécessaires, comme l’allocation de ressources supplémentaires ou la participation de fournisseurs par exemple.

Étape 6 : Résolution de l’incident et restauration du service

Une fois l'incident résolu, la solution pourra être implémentée (assurez-vous bien de disposer des autorisations nécessaires pour le faire) et testée pour confirmer la récupération du service. Si tout fonctionne, le service confirmera que le service de l’utilisateur a été restauré au niveau SLA requis.

Étape 7 : Clôture de l’incident

Pour finir le service confirmera le correctif et fermera le ticket. Assurez-vous de recueillir une confirmation de bon fonctionnement de la part de l’utilisateur qui a déclaré l’incident avant de fermer le ticket.

L’analyste de l’incident devra rédiger le rapport d’incidence en s’assurant de décrire les éléments ci-dessous :

• Date de clôture effective : date de résolution effective de l’incident.

• Délai de traitement : journées nécessaires au traitement de l’incident.

• Source de l’incident : interne ou externe.

• Catégorie de l’incident .

• Type d’incident.

• Cause de l’incident.

• Conséquence de l’incident.

• Le ou les responsables du plan d’action.

• Plan d’action d’amélioration continue.

Enfin il faudra bien penser à mettre à jour la base de données CMDB !

Source : « ITIL pour un service informatique optimal 2e édition »

Source : « les services agiles et les processus Retours d’expérience basés sur ITIL »