Gestion des incidents

La gestion des incidents est généralement le premier processus IT Infrastructure Library (ITIL) ciblé pour une mise en œuvre ou une amélioration par les organisations qui souhaitent adopter les bonnes pratiques ITIL. Les raisons sont simples : une meilleure consumérisation et une meilleure réalisation de la valeur du service. La gestion des incidents est le processus quotidien utilisé par l’organisation, via le centre de services ou des technologies en libre-service, pour rétablir rapidement les services.

La performance élevée de ce processus est essentielle pour l’organisation et pour les utilisateurs des services affectés. Sans lui, des comportements chaotiques apparaissent, avec un impact sur la performance des utilisateurs, la performance de l’organisation et la valeur économique globale, tant pour le client que pour le fournisseur du service. La gestion des incidents doit elle-même soutenir la stratégie métier, et cette stratégie doit fournir les moyens nécessaires pour exécuter la gestion des incidents et en tirer de la valeur.

Dans ce guide, nous examinerons en détail le système de gestion des incidents ITIL. En commençant par une définition et un énoncé des objectifs du processus, nous verrons comment ITIL définit le flux du processus, comment l’équipe de support collabore pour résoudre les incidents informatiques, et comment la réussite du processus au sein d’une entreprise peut être mesurée à l’aide d’indicateurs clés de performance (KPI). Enfin, nous examinerons comment les nouveaux logiciels intégrés de gestion des services facilitent l’automatisation, aident les organisations à mettre en place un centre de services consolidé et permettent de résoudre les incidents plus efficacement.

Qu’est-ce que la gestion des incidents ?

Dans ITIL, le terme « incident » désigne une interruption non planifiée ou une dégradation de la qualité d’un service informatique, ce qui peut représenter un coût considérable pour les grandes organisations. L’objectif principal du processus de gestion des incidents est de rétablir le service pour les utilisateurs aussi rapidement que possible lorsque des interruptions surviennent.

Avec l’exécution des demandes de base, la gestion des incidents est l’un des processus les plus importants que les organisations informatiques gèrent au quotidien. Alors que le processus d’exécution des demandes sert à traiter des demandes utilisateur standard, comme la modification d’un mot de passe, la gestion des incidents traite de véritables interruptions de service, avec pour objectif de résoudre la panne et de rétablir le service pour les utilisateurs aussi rapidement que possible.

Dans le modèle de cycle de vie des services en cinq étapes utilisé dans ITIL, la gestion des incidents relève de l’« exploitation des services ». Il s’agit de la quatrième étape du cycle de vie des services, celle où un service est déjà exploité par l’organisation. Ce processus contribue à garantir qu’une organisation peut tirer une valeur maximale des services et des applications qu’elle prend en charge, en veillant à la performance, à la disponibilité et à l’accès des utilisateurs au service.

Quels sont les processus et workflows de gestion des incidents ?

La gestion des incidents est le processus que les organisations informatiques suivent pour gérer le cycle de vie des incidents signalés. Ce processus comprend plusieurs étapes, souvent appelées sous-processus, qui doivent toutes être exécutées afin de garantir que les incidents sont correctement résolus et documentés. Ci-dessous, nous décrivons chacun de ces sous-processus et ce qu’ils apportent à l’organisation.

Support de la gestion des incidents

L’objectif du support de la gestion des incidents est de fournir et de maintenir les outils, processus, compétences et règles nécessaires à une prise en charge efficace et efficiente des incidents. Ce processus contribue à garantir que les agents ou techniciens du centre de services disposent de la formation et des compétences adéquates pour répondre aux incidents qui surviennent au sein de l’organisation informatique et les résoudre. Il maintient également les règles et workflows de traitement et de résolution des incidents, afin que les techniciens sachent toujours quelle est l’étape suivante pour garantir la résolution d’un incident.

Journalisation et catégorisation des incidents

L’objectif de ce sous-processus est d’enregistrer et de hiérarchiser les rapports d’incident avec le niveau de rigueur approprié afin de faciliter une résolution rapide et efficace. Les organisations disposent souvent de ressources limitées pour résoudre les incidents et autres problèmes informatiques ; la priorisation efficace des rapports d’incident entrants est donc une étape cruciale pour s’assurer que les efforts sont affectés de manière appropriée aux incidents les plus prioritaires. Les organisations informatiques doivent être capables de déterminer le périmètre et la gravité d’un incident signalé, puis de le prioriser en conséquence. La journalisation et la catégorisation des incidents sont souvent automatisées, par exemple lorsqu’une solution de supervision des opérations IT crée un incident à la suite d’un événement de performance ou de disponibilité.

Résolution immédiate des incidents par le support de niveau 1

Lorsqu’un utilisateur signale un incident au centre de services pour la première fois, il s’adresse généralement à un technicien de support de niveau 1. Le résultat idéal est que ce technicien puisse traiter l’incident et rétablir le service informatique dès le premier appel, dans le délai de résolution cible défini par l’organisation IT. Lorsqu’un incident ne peut pas être résolu dans le délai cible, ou si sa résolution exige un niveau plus élevé de connaissances techniques spécialisées, une escalade est déclenchée et un technicien de support de niveau 2 peut prendre en charge l’incident.

Résolution des incidents par le support de niveau 2

Une fois qu’un incident a été escaladé au-delà d’une résolution au premier appel par le support de niveau 1, un technicien de support de niveau 2 peut en prendre la responsabilité et commencer à rechercher une solution de contournement pour rétablir le service aussi rapidement que possible. À ce niveau, le technicien peut faire intervenir des groupes de support ou des fournisseurs tiers dans la résolution de l’incident. Si l’incident est dû à une application défaillante, par exemple, le technicien de niveau 2 peut contacter l’entreprise qui a développé l’application afin d’obtenir des conseils supplémentaires pour résoudre l’incident. S’il n’existe aucun moyen de traiter la cause racine de l’incident, le technicien de support de niveau 2 peut créer un enregistrement de problème et transférer l’incident au processus ou à l’équipe de gestion des problèmes.

Traitement des incidents majeurs

Nous avons mentionné plus haut l’importance de prioriser les incidents selon leur urgence afin de déployer les ressources le plus efficacement possible. Les incidents majeurs sont les incidents informatiques les plus prioritaires qu’une organisation puisse reconnaître : ils constituent de graves interruptions ou menaces pour les activités métier et doivent être résolus avec la plus grande urgence afin d’éviter des pertes financières ou d’autres conséquences critiques. Les incidents majeurs sont rapidement escaladés auprès des équipes de support de niveau 1 et de niveau 2, et peuvent impliquer des fournisseurs tiers si l’incident n’est pas résolu rapidement. Là encore, si la correction de la cause racine est impossible, l’incident est transféré à la gestion des problèmes.

Suivi et escalade des incidents

Les organisations informatiques qui suivent les bonnes pratiques ITIL mettent en place et maintiennent un système de suivi de l’état et des escalades de chaque incident informatique signalé. Les responsables IT chargés de la gestion des incidents doivent pouvoir suivre le nombre d’incidents actuellement signalés et consulter leur état dans le processus de gestion des incidents. Les accords de niveau de service ne sont pas respectés lorsque l’équipe de gestion des incidents met trop de temps à répondre aux incidents, et les interruptions de service entraînent des interruptions d’activité. Le suivi des incidents sert à garantir que les tickets de gestion des incidents sont résolus et progressent dans le processus en temps voulu, de sorte que les niveaux de service soient maintenus pour l’organisation.

Clôture et évaluation des incidents

Une fois qu’un incident a été effectivement résolu, l’enregistrement de l’incident est soumis à une étape finale de contrôle qualité. Ce sous-processus confirme que l’incident a été résolu et que son cycle de vie a été documenté avec un niveau de détail suffisant. Les conclusions du rapport d’incident peuvent être utilisées ultérieurement par l’organisation, notamment comme entrée pour le processus de gestion des connaissances . La clôture et l’évaluation des incidents contribuent à garantir que l’organisation suit toutes les informations importantes relatives à un incident, et qu’elle peut en tirer des enseignements après l’avoir résolu.

Information proactive des utilisateurs

Les rapports de gestion des incidents sont généralement soumis via le centre de services de l’organisation, qui fait office de point de contact unique pour les ressources IT au sein de l’organisation. L’équipe du centre de services peut également utiliser ce portail de communication pour informer de manière proactive les utilisateurs des problèmes connus et des interruptions de service au sein de l’organisation. Ce sous-processus permet de diffuser les informations dans toute l’organisation et de réduire le nombre de demandes et de sollicitations adressées au centre de services, en fournissant des informations à jour sur les interruptions de service.

Reporting de la gestion des incidents

Ce sous-processus vise à collecter des informations issues du processus de gestion des incidents et à les transmettre aux autres processus de gestion des services, afin de donner à l’organisation la possibilité d’améliorer ses performances à partir des données des incidents passés.

Comment les organisations mesurent-elles la réussite de la gestion des incidents ?

Mesurer la réussite des processus tout au long du cycle de vie des services ITIL est essentiel à l’amélioration continue des services. Les organisations doivent définir les métriques qui serviront à surveiller la performance de chaque processus et à produire des rapports précis sur ces métriques, afin d’identifier les meilleures opportunités d’amélioration. Ci-dessous, nous avons répertorié cinq des KPI les plus significatifs que les organisations peuvent mesurer pour s’assurer que leur processus de gestion des incidents fonctionne au niveau attendu.

État des incidents - Les organisations peuvent utiliser un logiciel pour suivre l’état des incidents actuellement gérés dans le cadre du processus de gestion des incidents. La consultation en temps réel de l’état de tous les incidents ouverts peut révéler où se créent les principaux arriérés et comment l’organisation peut affecter au mieux ses ressources pour améliorer le flux et réduire les délais de résolution. Par exemple, si de nombreux incidents restent bloqués au niveau du support de niveau 2 sans être résolus, l’entreprise peut envisager plusieurs solutions :

1. Ajouter davantage de personnel de support de niveau 2 afin d’accélérer le traitement des incidents.
2. Renforcer la formation du personnel de support de niveau 2 afin d’améliorer l’efficacité de la résolution des incidents.
3. Renforcer la formation du personnel de support de niveau 1 afin de réduire les escalades.
4. Faire intervenir un support de niveau 3 capable d’aider à gérer l’arriéré d’incidents d’un type spécifique (par exemple, s’il existe un arriéré d’incidents liés à une imprimante défaillante, contacter le fabricant pour aider à résoudre les problèmes).

Résolution au premier appel - Le taux de résolution au premier appel indique à quelle fréquence les incidents sont résolus par le personnel de support technique de niveau 1 dès le premier appel. Les résolutions rapides résultent de collaborateurs efficacement formés, disposant d’une expérience suffisante et d’un accès aux ressources et aux connaissances.

Coût moyen par incident/effort de résolution des incidents - Les organisations peuvent choisir de mesurer soit le coût moyen par incident géré, soit l’effort moyen consacré à la résolution de chaque incident. Elles cherchent à minimiser ces coûts tout en respectant les accords de niveau de service et la satisfaction client. Les investissements IT qui améliorent la disponibilité de l’activité doivent générer un retour sur investissement positif.

Temps moyen de réponse initiale - Ce KPI mesure le délai moyen entre le moment où un utilisateur signale un incident et celui où le centre de services répond à cet incident. Si le centre de services peut résoudre les incidents rapidement, mais qu’il faut trois heures pour obtenir une réponse, l’organisation peut envisager d’ajouter davantage de techniciens de service de niveau 1 afin de réduire le délai de réponse et d’augmenter en conséquence la disponibilité du service.

Nombre d’incidents répétés - Les incidents répétés ou rouverts sont un signal négatif pour votre organisation. Ils peuvent indiquer que les techniciens de support n’ont pas identifié la cause racine d’un problème, qui continue donc de se reproduire. Il se peut que l’équipe IT sache comment résoudre le problème et que les utilisateurs puissent même le faire eux-mêmes, mais qu’aucune ressource ne soit disponible pour faciliter le libre-service. Les incidents répétés peuvent être évités en trouvant la cause racine d’un problème et en communiquant de manière proactive avec les utilisateurs pour les aider à le résoudre sans le signaler à l’IT.

Rôles et responsabilités de la gestion des incidents

Des rôles et responsabilités bien définis sont essentiels à l’exécution efficace du processus de gestion des incidents. L’équipe de gestion des incidents se compose des rôles suivants :

Responsable des incidents

Le responsable des incidents est principalement chargé de piloter et d’améliorer en continu le processus de gestion des incidents. Dans les petites et moyennes organisations, ce rôle est généralement attribué au responsable du centre de services ; dans les grandes organisations, il peut s’agir d’un rôle défini séparément. Ses principales responsabilités comprennent : le leadership de l’équipe, la communication des indicateurs clés de performance (KPI) à la direction, la gestion directe du support de premier et de deuxième niveau, l’administration du système de gestion des incidents et l’application du workflow du processus de gestion des incidents.

Support de premier niveau

Les techniciens du centre de services de premier niveau constituent le point de contact unique pour les utilisateurs finaux qui recherchent des informations et signalent des interruptions de service. Ils sont principalement responsables du support initial et de la classification des incidents, ainsi que de la tentative immédiate de rétablissement d’un service défaillant aussi rapidement que possible. S’ils ne parviennent pas à résoudre l’incident, le technicien du centre de services de premier niveau l’achemine vers les équipes de support appropriées, suit l’activité et tient les utilisateurs informés de l’état de leur incident.

Support de niveau deux

Les techniciens de support de deuxième niveau disposent généralement de connaissances plus avancées que les techniciens du centre de services de premier niveau. Ils peuvent devenir responsables des incidents que le support de premier niveau ne parvient pas à résoudre. Ces techniciens peuvent échanger avec des experts tiers issus de fournisseurs de logiciels ou de matériel afin d’aider à rétablir le service normal aussi rapidement que possible.

KPI de la gestion des incidents

Les mesures sont importantes à toutes les étapes du cycle de vie ITIL. Chaque processus possède des métriques qui doivent être surveillées et faire l’objet de rapports afin d’évaluer efficacement la performance globale. L’amélioration continue des services exige de mesurer la performance de chaque processus afin d’identifier les domaines à améliorer.

Les métriques courantes de gestion des incidents incluent :

• Nombre total d’incidents signalés (par catégorie, priorité, personne, unité organisationnelle, etc.)
• État des incidents
• Délai entre la création et la résolution de l’incident
• Incidents et SLA (respectés, non respectés)
• Coût moyen par incident
• Taux de réouverture
• Incidents traités sans escalade
• Résolution au premier appel
• Éléments de configuration présentant des incidents récurrents
• Incidents par moment de la journée

Les KPI doivent être liés aux facteurs clés de succès (CSF), et les CSF doivent être liés aux objectifs. Cette relation facilite l’aide à la décision pour maintenir l’état actuel et progresser vers l’état souhaité. Bien que chaque organisation soit différente, des rapports pertinents pour les utilisateurs, le personnel et la direction contribueront à éclairer des décisions importantes pouvant servir à améliorer à la fois les processus et l’activité dans son ensemble.

Bonnes pratiques pour mettre en œuvre la gestion des incidents

Adopter le cadre ITIL au sein d’une entreprise peut être une tâche complexe. Comme tout processus ITIL, la mise en œuvre de la gestion des incidents nécessite le soutien de l’entreprise. Il est particulièrement important d’obtenir l’adhésion des dirigeants et de la direction. Avant de commencer le processus d’adoption, il est essentiel de disposer d’au moins une personne dédiée à la gestion globale du projet et à l’orchestration du respect des bonnes pratiques de gestion des incidents. Il est également extrêmement utile de disposer d’un outil de gestion des services IT (ITSM) qui prendra en charge vos processus actuels et vos processus cibles, ainsi que d’un centre de services faisant office d’interface principale avec le service informatique.

1) Comprendre le processus actuel de gestion des incidents

Il arrive qu’une organisation ne dispose pas d’un processus cohérent de traitement des incidents, ou qu’elle ait mis en place un processus moins sophistiqué. Dans les deux cas, il est important de cartographier au mieux le processus existant afin de comprendre ce que le processus actuel du centre de services offre.

2) Identifier la vision à long terme du processus de gestion des incidents

Il est également important de comprendre ce que l’organisation attend du processus de gestion des incidents. Cette attente peut reposer sur des modèles génériques de gestion des incidents inclus dans l’outil ITSM, ou sur un processus plus personnalisé fondé sur les besoins spécifiques de l’organisation.

3) Réaliser une analyse des écarts

Ensuite, identifiez ce qui doit être ajusté entre le processus actuel de gestion des incidents de l’organisation et sa vision à long terme de la gestion des incidents. Vous disposerez ainsi d’informations précieuses sur les efforts, le temps, le budget et les ressources nécessaires pour atteindre vos objectifs de gestion des incidents et vos objectifs globaux de service.

4) Créer une feuille de route de mise en œuvre

L’adoption de tout processus ITIL demandera du temps, et vous aurez besoin d’une feuille de route pour aider à définir les attentes de la direction. Utilisez cette feuille de route pour décrire les activités, le calendrier et les efforts nécessaires à la livraison. Elle doit inclure des gains rapides, la mise en œuvre des outils, les changements de processus, l’accompagnement des personnes et de l’organisation, les plans de communication et les changements globaux de gouvernance.

5) Lancer la mise en œuvre du projet

Il est temps de lancer la mise en œuvre. Créez un plan de projet qui définit les actions ou tâches, les responsabilités et le calendrier d’achèvement de toutes les tâches. Communiquez les réussites au fil de l’eau, à mesure que vous atteignez chaque jalon, afin de démontrer vos progrès vers votre objectif final de mise en œuvre.

Liste de contrôle des fonctionnalités d’un logiciel de gestion des incidents

Pour les organisations informatiques qui évaluent un logiciel de gestion des incidents et/ou des suites de gestion des services IT offrant des fonctionnalités de gestion des incidents, il est important de comprendre les types de fonctionnalités nécessaires pour prendre en charge les processus clés. Au minimum, un logiciel de gestion des incidents doit fournir les capacités suivantes :

• Créer, modifier, résoudre et clôturer des enregistrements d’incident
• Générer des numéros d’enregistrement uniques associés à chaque enregistrement d’incident
• Lier les incidents aux enregistrements de problème, aux articles de connaissances, aux solutions de contournement connues et aux demandes de changement
• Lier les données de gestion de configuration à l’enregistrement d’incident
• Notifier les propriétaires d’incident lorsque le problème associé est résolu
• Enregistrer automatiquement les données historiques dans un journal d’audit
• Catégorisation configurable des incidents
• Capacités de recherche et de reporting sur les incidents
• Acheminer les incidents en fonction de la disponibilité des ressources, des fuseaux horaires, des sites, etc.
• Prioriser, attribuer et escalader les incidents en fonction de leur catégorisation ; escalader selon la priorité ou une autre catégorisation
• S’intégrer aux solutions de supervision des événements, avec la capacité de créer, mettre à jour et clôturer automatiquement les incidents
• Configurations de champs flexibles, notamment texte libre, liste déroulante, date/heure, pièces jointes et captures d’écran
• Lier les incidents aux données client
• Utiliser des solutions/scripts de base de connaissances pour le diagnostic et la résolution
• Attribuer des incidents ou des tâches associées à des prestataires de services externes
• Attribuer des incidents à plusieurs personnes
• Créer un problème ou une demande de changement à partir d’un enregistrement d’incident
• Alertes d’incident automatisées (au personnel IT et/ou à l’utilisateur final) en fonction des échéances, des SLA, de la clôture et d’autres activités
• Lier les enregistrements d’incident aux SLA
• Recueillir les commentaires des utilisateurs finaux via une enquête de satisfaction client
• Initier un incident au nom d’une autre personne
• Arrêter le chronomètre SLA pour mettre un incident en attente
• Faire la distinction entre un incident et une demande de service
• Réactiver un incident résolu
• Déterminer automatiquement la priorité en fonction de l’impact et de l’urgence
• S’intégrer au système de téléphonie/ACD afin de préremplir les informations client à partir de l’identification de l’appelant