Concepts de base

3. Concepts de base

3.1. Cycle de vie d’un incident

Le cycle de vie d'un incident est le suivant :



Quelques remarques :

  • Le centre de services est responsable de l’aboutissement de tous les incidents enregistrés (propriétaire des incidents).

  • Le processus de traitement est essentiellement réactif .

  • Les incidents ne pouvant pas être résolus immédiatement doivent être assignés aux groupes de spécialistes.

  • La résolution ou une solution de contournement doit intervenir le plus vite possible pour rétablir le service impacté

3.2. Cycle de vie d’un incident : préconisations

Tout au long du cycle de vie de l’incident, l’enregistrement doit être à jour pour permettre à n’importe quelle personne de l’équipe du centre de services de communiquer sur l’incident simplement en consultant l'enregistrement.

Il est nécessaire de conserver la description originelle de l’incident même si la description en cours évolue. Par exemple, un utilisateur signale un incident avec son imprimante (son édition ne s'imprime pas). Après investigation, il s'agit en réalité d'un problème réseau mais, lorsque l'incident est clos, il est préférable que le centre de services prévienne l'utilisateur simplement en lui précisant que son problème imprimante est réglé plutôt que de lui expliquer le problème réseau et sa résolution.

Il faut aussi conserver un historique des modifications sur l’enregistrement de l’incident. Tous les changements d'état doivent être tracés (date/heure, personne qui a provoqué le changement, etc.)

Si l’une des équipes n’a pas accès à l’outil de gestion des incidents, il est impératif de bien mettre en place une procédure de mise à jour de ces enregistrements à faire lors des interventions de ces équipes(par exemple: maintenance tierce ou support de nuit n’ayant pas accès à l’outil durant la nuit)

3.3. Premier, deuxième et troisième niveaux de support

Voici un schéma (classique) d'escalade d'un incident sur les différents niveaux de support, à commencer par le centre de services :



Il est à noter que certains niveaux de support peuvent être des sociétés extérieures (externalisation du support ou appel aux constructeur/éditeurs dans le cadre de contrats de support passés entre l'entreprise et ces sociétés extérieures).

3.4. Escalade fonctionnelle et escalade hiérarchique

3.4.1. Escalade fonctionnelle

C'est l'escalade traditionnelle et prévue dans le processus pour transférer un Incident d’un niveau au niveau supérieur .

Cette escalade peut intervenir dans deux cas :

  • par manque de connaissance ou d’expertise du niveau en cours.

  • par dépassement d’un délai (à définir avec précaution et ne pas dépasser les délais des contrats de niveaux de service)

3.4.2. Escalade hiérarchique

Ce type d'escalade n'est pas réellement prévue dans le processus. Cependant, en pratique, on constate que cette escalade existe et est nécessaire au bon fonctionnement du service dans certains cas.

L'escalade hiérarchique peut intervenir à n’importe quel moment dans le cycle de gestion de l'incident lorsqu'il est évident que la résolution interviendra hors-délai ou sera insatisfaisante. Ceci demande un certain recul vis-à-vis du processus qui, s'il est suivi à la lettre, peut aboutir dans certains cas à des situations critiques.

Dans l’idéal , l'escalade hiérarchique devrait intervenir avant la fin du délai pour que la hiérarchie ait le temps de réagir. En pratique, on constate que l'escalade hiérarchique est utilisée lorsque les temps de résolution de l'incident sont hors délai.

3.5. Enregistrement d'un incident

Le centre de services est propriétaire de l'incident et en est responsable jusqu'à la résolution et sa fermeture.

L'élément important de l'enregistrement d'un incident (que l'on peut aussi appeler fiche incident) est sa priorité de traitement par rapport aux autres incidents en cours.

3.5.1. Fixer la priorité

La priorité d'un incident est déterminée par :

  • L'impact sur l’activité de l’entreprise . L'impact représente la criticité sur l’activité métier (Incident ou Problème). Certaines définitions de la criticité (ou niveau de risque) précisent qu'il y a 3 facteurs : fréquence, gravité, probabilité de non-détection. L'impact est souvent mesuré au nombre de personnes ou de systémes affectés.

  • L’urgence à mettre en place une solution définitive ou de contournement (urgence: effort attendu et vitesse nécessaire pour résoudre l’incident)

Pour fixer correctement le niveau de priorité sans perdre trop de temps, il est nécessaire d'avoir un cadre de travail. Ce cadre est fixé par les différents contrats de niveaux de service. En pratique , on retrouvera une codification déjà définie (impact/urgence) dans ces contrats de niveaux de service.

3.5.2. Rôles du centre de services dans la gestion des incidents

Les points importants à prendre en considération sont les suivants :

  • tous les incidents sont remontés vers le centre de services et doivent être enregistrés par celui-ci (y compris les remontées automatiques dans l’idéal)

  • la majorité des incidents (jusqu’à 85%) pourront être résolus par le centre de services (constaté lorsqu'une gestion effective des incidents est en place)

  • le centre de services est la fonction « indépendante » de suivi de l’ensemble des incidents jusqu’à leur résolution

  • le centre de services effectue la coordination des équipes de support intervenant dans la résolution des incidents.

3.5.3. Actions principales à l’enregistrement

  • enregistrement du détail (symptôme, etc.)

  • s’il s’agit d’une demande de service, utilisation de la procédure associée

  • l’élément de configuration (CMDB) à l’origine probable de l’incident est associé à la fiche

  • assignation de la priorité adéquate et communication à l’utilisateur d’un identifiant d’incident

  • l’incident est évalué et, si possible, la solution est donnée (incident fréquent ou erreur connue)

  • l’incident est assigné au support de niveau deux si besoin ou

  • la fiche est complétée et fermée si la solution a été donnée

3.5.4. Actions principales à la fermeture

  • confirmer la résolution avec l’utilisateur ou l’émetteur

  • définir la catégorie de la solution apportée

  • compléter l’enregistrement de l’incident

  • fermer l’incident en vérifiant que :

  • les détails de la solution sont clairs et lisibles

  • les codes de refacturation sont renseignés (cost-centre)

  • les temps passés sur l’incident sont renseignés

Ceci est indispensable pour éviter les conflits entre équipes de support et clients sur la validité de la fermeture

Il est nécessaire d'avoir un accès restreint à l’option de fermeture des incidents (typiquement le responsable du centre de services gère ces accès)

3.6. Incidents, problèmes, erreurs connues et demandes de changement

Un incident est la conséquence d’échecs ou d’erreurs de traitements dans l’infrastructure informatique

La cause d’un incident peut être évidente et peut être éradiquée directement par le centre de services sans investigation complémentaire en :

  • réparation immédiate

  • solution de contournement

  • demande de changement

Quand la cause sous-jacente d’un incident n’est pas connue, il est nécessaire d'initialiser un problème dans le processus de gestion des problèmes.

Un problème est ainsi le signe d’une erreur inconnue dans l’infrastructure.

Plusieurs incidents peuvent sembler partager la même origine donnant lieu à la définition d’un problème unique

Un problème est indépendant des incidents associés. L’analyse du problème peut continuer même si les incidents ont été résolus et fermés.

Résolution d’un problème :

  • Identification de l’erreur sous-jacente

  • Mise au point d’une solution de contournement ou émission d’une demande de changement

Le problème devient alors une erreur connue.

3.7. Définitions

Problème : la cause inconnue d’un ou de plusieurs incidents

Erreur connue : problème diagnostiqué correctement et pour lequel il existe une solution de contournement ou une demande de changement a été émise

Demande de changement : une demande d’ajout, de modification, d’évolution, de suppression de composant(s) de l’infrastructure informatique ou pour tout autre aspect de la production informatique

3.8. Incidents, problèmes, erreurs connues et demandes de changement

Les interactions entre les processus de gestion des incidents et de gestion des problèmes sont complexes mais il est nécessaire de les maîtriser afin de bien séparer ces deux processus dont les finalités sont très différentes.



Dans le processus de résolution d’un incident, les actions suivantes doivent être entreprises :

  • si l'incident semble avoir une cause inconnue, il faut initialiser un problème dans le processus de gestion des problèmes.

  • étudier une correspondance avec les problèmes référencés et les erreurs connues

  • étudier une correspondance avec les incidents référencés (similaires résolus ou en cours)

  • si pas de solution, la gestion des incidents a la responsabilité d’en trouver une (définitive ou de contournement) avec l’impact minimum sur l’activité de l’entreprise

Les flux entre la gestion des incidents et la gestion des problèmes sont croisés :

  • lors de l'analyse de l'incident par la gestion des incidents pour redémarrer le plus vite possible le service impacté, si une solution de contournement est trouvée, l’information doit être transmise à la gestion des problèmes pour analyse

  • lors de l'analyse du problème par la gestion des problèmes, une solution définitive ou de contournement à un ou plusieurs incidents a été trouvée, la gestion des problèmes met à jour la base des problèmes/erreurs connues et transmet l’information à la gestion des incidents pour action sur les incidents associés (passage des incidents en erreur connue ou résolu)

Précédent : Périmètre

Suivant : Bénéfices