ITIL V2

La gestion des incidents

Cration : novembre 2004
Mise jour : aot 2009



2


A propos

A propos du document
Ce document de rfrence sur le rfrentiel ITIL a t ralis en 2004 et la traduction des 2 livres ITIL
Service Support et Service Delivery a ncessit 4 mois de traduction et d criture.
Il est mis la disposition de la communaut francophone ITIL pour diffuser les connaissances de base
sur ce rfrentiel.
Ce document peut tre utilis de manire libre condition de citer le nom du site (www.itilfrance.com)
ou le nom de l auteur (Pascal Delbrayelle).
A propos de l'auteur
Pascal Delbrayelle intervient avec plus de 25 ans d'exprience comme consultant sur les projets d'une
direction informatique ayant comme facteur de succs la mise en oeuvre des bonnes pratiques ITIL
comme, par exemple, la mise en place d'un site de secours, la mise en place d'un outil de gestion des
configurations ou la dfinition des normes et standards techniques des environnements de production.
Ces projets requirent :
la connaissance des diffrents mtiers du dveloppement et de la production informatique
la pratique de la conduite de projets techniques de la direction informatique
la matrise de la dfinition et de la mise en place de processus pour rationaliser et adapter les
mthodes de travail au sein de la direction informatique

A propos de mi ssi on et de formati on
Si vous pensez que l exprience de l auteur sur le rfrentiel ITIL ou la formalisation de documents
sur le sujet peut vous aider dans vos projets de production ou de mise en oeuvre des processus ITIL,
n hsitez pas le contacter pour toute question ou demande :
par mail : pascal.delbrayelle@itilfrance.com
par tlphone : +33 (0)6 61 95 41 40
Quelques exemples de mission :
Modlisation simple des processus de gestion des changements, des projets et des mises en
production en vue de la slection, l'achat et l'implantation d'un outil de gestion de projets
avec planification, gestion des ressources, des budgets, des livrables et des connaissances
Accompagnement avec la rorganisation d'un DSI passant d'une organisation en silos
techniques vers une organisation inspire du rfrentiel ITIL et la mise en oeuvre d'outils
pour institutionnaliser les processus ITIL
Accompagnement d'une DSI dans la formulation de l'appel d'offres au futur centre de services
en se basant sur les processus et la fonction centre de services du rfrentiel ITIL


3


Sommaire
1 Objectif .......................................................................................................................................................... 4
2 Primtre ....................................................................................................................................................... 4
2.1 Dfinition dun Incident et extensions ...................................................................................................... 4
2.2 Extensions de la dfinition ...................................................................................................................... 4
2.3 Processus de Gestion des Incidents ....................................................................................................... 4
3 Concepts de base .......................................................................................................................................... 5
3.1 Cycle de vie dun Incident ....................................................................................................................... 5
3.2 Cycle de vie dun Incident : Prconisations ............................................................................................. 6
3.3 Premier, deuxime et troisime niveaux de support ................................................................................ 6
3.4 Escalade fonctionnelle et escalade hirarchique ..................................................................................... 6
3.4.1 Escalade fonctionnelle .................................................................................................................... 6
3.4.2 Escalade hirarchique..................................................................................................................... 7
3.5 Enregistrement d'un Incident .................................................................................................................. 7
3.5.1 Fixer la priorit ................................................................................................................................ 7
3.5.2 Rles du Centre de Services dans la Gestion des Incidents ............................................................ 7
3.5.3 Actions principales lenregistrement ............................................................................................. 7
3.5.4 Actions principales la fermeture.................................................................................................... 7
3.6 Incidents, Problmes, Erreurs Connues et Demandes de Changement ................................................... 8
3.7 Dfinitions .............................................................................................................................................. 8
3.8 Incidents, Problmes, Erreurs Connues et Demandes de Changement ................................................... 8
4 Bnfices ........................................................................................................................................................ 9
4.1 Pour lentreprise : ................................................................................................................................... 9
4.2 Pour la Production Informatique : ............................................................................................................ 9
4.3 A contrario, la non-implmentation dune Gestion des Incidents entrane : .............................................. 9
5 Mise en oeuvre et planification ........................................................................................................................ 9
5.1 Squencement et calendrier ................................................................................................................... 9
5.2 Difficults prvoir : ............................................................................................................................. 10
6 Traitement des Incidents majeurs.................................................................................................................. 10
7 Indicateurs cls de performances (KPI : Key Performance Indicators) ........................................................... 10
7.1 Mtriques couramment utilises : .......................................................................................................... 10
7.2 Diffusion des informations ..................................................................................................................... 11








4


1 Objectif
La dfinition ITIL de l'objectif de la Gestion des Incidents est la suivante :

Restaurer aussi vi te que possi bl e l e foncti onnement normal des services et mi nimi ser l impact ngatif sur l es activi ts
mti ers et sassurer ai nsi que l es meil l eurs niveaux de qual it de servi ce et de di sponi bil it sont maintenus.

Le fonctionnement normal des services sentend ici comme le fonctionnement des services dans les limites des Contrats
de Niveaux de Service (SLAs)
2 Primtre
2.1 Dfinition dun Incident et extensions
La dfinition ITIL d'un Incident est la suivante :

Tout vnement qui ne fait pas parti e du foncti onnement standard d un servi ce et qui cause, ou peut causer, une
i nterruption ou une dimi nuti on de l a quali t de ce servi ce.

Quelques exemples :
application : application non disponible, erreur programme empchant lUtilisateur de travailler, nombre d'E/S disques
excessifs
matriel : systme HS, remonte dalerte automatique, sortie imprimante bloque
demandes de services : demande dinformation, de conseil ou de documentation, oubli dun mot de passe
2.2 Extensions de la dfinition
Le terme Incident est gnralement compris comme un dysfonctionnement signal par un Utilisateur. Cependant, deux
extensions cette dfinition sont gnralement utilises car elles vont suivre le mme processus de traitement que les
dysfonctionnements proprement dits et sont donc assimils des Incidents :
Les demandes pour un nouveau servi ce (ou l extensi on d un servi ce exi stant) sont considres comme des
Demandes de Changement (RFCs) mais assimiles des Incidents en pratique (traitement identique) et traites
dans le cadre de la Gestion des Incidents
Les Remontes d al ertes automati ques (espace-disque satur par exemple) : elles sont souvent considres
comme faisant partie de lexploitation courante ; ces vnements sont traits dans le cadre de la Gestion des
Incidents mme si le service dlivr aux Utilisateurs nest pas affect
2.3 Processus de Gestion des Incidents



5


En entre du processus, nous retrouvons :
Dtails des Incidents (du Centre de Services et des diffrentes sources automatiques)
Dtails des Configurations (de la CMDB)
Recherche correspondances (matching) entre Incidents et Problmes & Erreurs connues (de la base de donnes
Problmes/Erreurs Connues)
Dtails de la rsolution de lIncident de nature similaire (de la mme base)
Retour des Demandes de Changement en correction dun Incident (du processus Gestion des Changements)
En sortie du processus, nous avons :
Routage des demandes de services
Demandes de Changement pour rsoudre certains Incidents
Mise jour de la base des Problmes/Erreurs Connues
Communication aux Utilisateurs (pendant lavancement et la fermeture)
Rapports la hirarchie
Dans le processus, les activits de la Gestion des Incidents sont les suivantes :
Dtection et enregistrement des Incidents
Support initial et classification
Investigation et diagnostic
Suivi global des Incidents
Rsolution et rtablissement
Fermeture des Incidents
3 Concepts de base
3.1 Cycle de vie dun Incident
Le cycle de vie d'un Incident est le suivant :





6

Quelques remarques :
Le Centre de Services est responsable de laboutissement de tous les Incidents enregistrs (propritaire des
Incidents).
Le processus de traitement est essentiellement ractif .
Les Incidents ne pouvant pas tre rsolus immdiatement doivent tre assigns aux groupes de spcialistes.
La rsolution ou une solution de contournement doit intervenir le plus vite possible pour rtablir le service impact
3.2 Cycle de vie dun Incident : Prconisations
Tout au long du cycle de vie de lIncident, lenregistrement doit tre jour pour permettre nimporte quelle personne de
lquipe du Centre de Services de communiquer sur lIncident simplement en consultant l'enregistrement.
Il est ncessaire de conserver la description originelle de lIncident mme si la description en cours volue. Par exemple, un
Utilisateur signale un Incident avec son imprimante (son dition ne s'imprime pas). Aprs investigation, il s'agit en ralit d'un
problme rseau mais, lorsque l'Incident est clos, il est prfrable que le Centre de Services prvienne l'Utilisateur simplement
en lui prcisant que son problme imprimante est rgl plutt que de lui expliquer le problme rseau et sa rsolution.
Il faut aussi conserver un historique des modifications sur lenregistrement de lIncident. Tous les changements d'tat doivent
tre tracs (date/heure, personne qui a provoqu le changement, etc.)
Si lune des quipes na pas accs loutil de Gestion des Incidents, il est impratif de bien mettre en place une procdure de
mise jour de ces enregistrements faire lors des interventions de ces quipes(par exemple: maintenance tierce ou support
de nuit nayant pas accs loutil durant la nuit)
3.3 Premier, deuxime et troisime niveaux de support
Voici un schma (classique) d'escalade d'un Incident sur les diffrents niveaux de support, commencer par le Centre de
Services :



Il est noter que certains niveaux de support peuvent tre des socits extrieures (externalisation du support ou appel aux
constructeur/diteurs dans le cadre de contrats de support passs entre l'entreprise et ces socits extrieures).
3.4 Escalade fonctionnelle et escalade hi rarchique
3.4.1 Escalade fonctionnelle
C'est l'escalade traditionnelle et prvue dans le processus pour transfrer un Incident dun niveau au niveau suprieur .

7

Cette escalade peut intervenir dans deux cas :
par manque de connaissance ou dexpertise du niveau en cours.
par dpassement dun dlai ( dfinir avec prcaution et ne pas dpasser les dlais des Contrats de Niveaux de
Service)
3.4.2 Escalade hirarchique
Ce type d'escalade n'est pas rellement prvue dans le processus. Cependant, en pratique, on constate que cette escalade
existe et est ncessaire au bon fonctionnement du service dans certains cas.
L'escalade hirarchique peut intervenir nimporte quel moment dans le cycle de Gestion de l'Incident lorsqu'il est vident que
la rsolution interviendra hors-dlai 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 lidal , l'escalade hirarchique devrait intervenir avant la fin du dlai pour que la hirarchie ait le temps de ragir. En
pratique, on constate que l'escalade hirarchique est utilise lorsque les temps de rsolution de l'Incident sont hors dlai.
3.5 Enregistrement d'un Incident
Le Centre de Services est propritaire de l'Incident et en est responsable jusqu' la rsolution et sa fermeture.
L'lment 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 dtermine par :
L'impact sur l acti vit de l entrepri se . L'impact reprsente la criticit sur lactivit mtier (Incident ou Problme).
Certaines dfinitions de la criticit (ou niveau de risque) prcisent qu'il y a 3 facteurs : frquence, gravit, probabilit
de non-dtection. L'impact est souvent mesur au nombre de personnes ou de systmes affects.
L urgence mettre en pl ace une sol ution dfinitive ou de contournement (urgence: effort attendu et vitesse
ncessaire pour rsoudre lIncident)
Pour fixer correctement le niveau de priorit sans perdre trop de temps, il est ncessaire d'avoir un cadre de travail. Ce cadre
est fix par les diffrents Contrats de Niveaux de Service. En pratique , on retrouvera une codification dj dfinie
(impact/urgence) dans ces Contrats de Niveaux de Service.
3.5.2 Rles du Centre de Services dans la Gestion des Incidents
Les points importants prendre en considration sont les suivants :
tous les Incidents sont remonts vers le Centre de Services et doivent tre enregistrs par celui-ci (y compris les
remontes automatiques dans lidal)
la majorit des Incidents (jusqu 85%) pourront tre rsolus par le Centre de Services (constat lorsqu'une Gestion
effective des Incidents est en place)
le Centre de Services est la fonction indpendante de suivi de lensemble des Incidents jusqu leur rsolution
le Centre de Services effectue la coordination des quipes de support intervenant dans la rsolution des Incidents.
3.5.3 Actions principales lenregistrement
enregistrement du dtail (symptme, etc.)
sil sagit dune Demande de Service, utilisation de la procdure associe
lElment de Configuration (CMDB) lorigine probable de lIncident est associ la fiche
assignation de la priorit adquate et communication lUtilisateur dun identifiant dIncident
lIncident est valu et, si possible, la solution est donne (Incident frquent ou Erreur Connue)
lIncident est assign au support de niveau deux si besoin ou
la fiche est complte et ferme si la solution a t donne
3.5.4 Actions principales la fermeture
confirmer la rsolution avec lUtilisateur ou lmetteur
dfinir la catgorie de la solution apporte

8

complter lenregistrement de lIncident
fermer lIncident en vrifiant que :
les dtails de la solution sont clairs et lisibles
les codes de refacturation sont renseigns (cost-centre)
les temps passs sur lIncident sont renseigns
Ceci est indispensable pour viter les conflits entre quipes de support et Clients sur la validit de la fermeture
Il est ncessaire d'avoir un accs restreint loption de fermeture des Incidents (typiquement le responsable du Centre de
Services gre ces accs)
3.6 Incidents, Problmes, Erreurs Connues et Demandes de Changement
Un Incident est la consquence dchecs ou derreurs de traitements dans linfrastructure informatique
La cause dun Incident peut tre vidente et peut tre radique directement par le Centre de Services sans investigation
complmentaire en :
rparation immdiate
solution de contournement
Demande de Changement
Quand la cause sous-jacente dun Incident nest pas connue, il est ncessaire d'initialiser un Problme dans le processus de
Gestion des Problmes.
Un Problme est ainsi le signe dune erreur inconnue dans linfrastructure.
Plusieurs Incidents peuvent sembler partager la mme origine donnant lieu la dfinition dun Problme unique
Un Problme est indpendant des Incidents associs. Lanalyse du Problme peut continuer mme si les Incidents ont t
rsolus et ferms.
Rsolution dun Problme :
1. Identification de lerreur sous-jacente
2. Mise au point dune solution de contournement ou mission dune Demande de Changement
Le Problme devient alors une Erreur Connue.
3.7 Dfinitions
Probl me : La cause inconnue dun ou de plusieurs Incidents
Erreur connue : Problme diagnostiqu correctement et pour lequel il existe une solution de contournement ou une Demande
de Changement a t mise
Demande de Changement : Une demande dajout, de modification, dvolution, de suppression de composant(s) de
linfrastructure informatique ou pour tout autre aspect de la Production Informatique
3.8 Incidents, Problmes, Erreurs Connues et Demandes de Changement
Les interactions entre les processus Gestion des Incidents et Gestion des Problmes sont complexes mais il est ncessaire de
les matriser afin de bien sparer ces deux processus dont les finalits sont trs diffrentes.



9


Dans le processus de rsolution dun Incident, les actions suivantes doivent tre entreprises :
si l'Incident semble avoir une cause inconnue, il faut initialiser un Problme dans le processus de Gestion des
Problmes.
tudier une correspondance avec les Problmes rfrencs et les Erreurs Connues
tudier une correspondance avec les Incidents rfrencs (similaires rsolus ou en cours)
si pas de solution, la Gestion des Incidents a la responsabilit den trouver une (dfinitive ou de contournement) avec
limpact minimum sur lactivit de lentreprise
Les flux entre la Gestion des Incidents et la Gestion des Problmes sont croiss :
lors de l'analyse de l'Incident par la Gestion des Incidents pour redmarrer le plus vite possible le service impact, si
une solution de contournement est trouve, linformation doit tre transmise la Gestion des Problmes pour
analyse
lors de l'analyse du Problme par la Gestion des Problmes, une solution dfinitive ou de contournement un ou
plusieurs Incidents a t trouve, la Gestion des Problmes met jour la base des Problmes/Erreurs Connues et
transmet linformation la Gestion des Incidents pour action sur les Incidents associs (passage des Incidents en
Erreur Connue ou Rsolu)
4 Bnfices
4.1 Pour lentreprise :
Rduction de limpact des Incidents sur les activits mtiers augmentant ainsi leur efficacit
4.2 Pour la Production Informatique :
Surveillance amliore des Incidents permettant une relle mesure des performances vis--vis des Contrats de
Niveaux de Services
Gestion de la qualit amliore
Meilleure utilisation des ressources
Disparition des Incidents et Demandes de Services perdues ou errones
Mise jour de la CMDB lenregistrement dun Incident
Augmentation de la satisfaction des Utilisateurs et des Clients
4.3 A contrario, la non-implmentation dune Gestion des Incidents entrane :
Pas de gestion, pas descalade des Incidents : ils deviennent plus graves quil ne le devraient, ils dgnrent
Les quipes de spcialistes sont sujets de constantes interruptions, les rendant moins efficaces
Les utilisateurs sont drangs par des collgues demandant des conseils au lieu dappeler le Centre de Services
Rsolution frquente partir de zro dun Incident plutt que dutiliser une solution dj rfrence
Absence dinformations de synthse pour la hirarchie
Incidents perdus ou grs de manire incorrecte
5 Mise en oeuvre et planification
5.1 Squencement et calendrier
Ne pas mettre en place de manire isole des autres processus et fonctions (Centre de Services, Gestion des
Problmes, des Configurations, des Changements, Gestion des Nouvelles Versions)
Si cela n'est pas possible, il est ncessaire d'implmenter au moins en mme temps Centre de Services & Gestion des
Incidents (objectifs rapides atteindre)

10

Profiter des dmarrages de services importants pour les intgrer tout de suite dans une Gestion des Incidents (mme
si le nombre d'Utilisateurs ou le nombre d'appels ne justifient pas dans ce cas la mise en place d'un Centre de
Services et d'une Gestion des Incidents)
Planification de la mise en place du processus : 3 6 mois
Mise en place du processus : 3 mois 1 an
Choix des outils logiciels : prendre les logiciels conformes ITIL
CMDB inexistante ou pas mise en place en mme temps : intgrer les informations de configuration dans la base de
Gestion des Incidents
5.2 Difficults prvoir :
pas dengagement de la hirarchie
manque de clart des besoins mtiers
mthodes de travail non rvises
pas dinformations sur les niveaux de services
manque de connaissances des Incidents rsolus
manque dintgration avec les autres processus
rsistance au changement
6 Traitement des Incidents majeurs
Il est noter que le chapitre sur les Incidents majeurs dans le document ITIL Service Support est lger et que tout le chapitre
est mis au conditionnel.
Les Incidents majeurs sont ceux pour lesquels le degr dimpact sur lensemble des Utilisateurs est extrme.
Devraient tre considrs comme Incidents majeurs les Incidents pour lesquels lchelle de temps des perturbations devient
excessif au regard des temps de rsolution (SLAs) (mme si cela impacte un petit nombre dUtilisateurs)
Le Gestionnaire de Problmes devrait tre averti (sil ne lest pas dj) afin dorganiser une runion (ou une srie de runions)
avec toutes les parties concernes :
quipes de support internes
quipes de support des matriels/logiciels (et/ou mainteneur)
quipes de gestion des services de la Production
Le Centre de Services devrait participer ces runions et enregistrer dans la base dIncidents toutes les actions prises et les
dcisions.
Nous pouvons considrer qu'il s'agit l d'une priode de crise qui ne peut pas tre dcrite de manire exhaustive dans une
mthode car l'important est d'agir vite malgr le nombre peut-tre important d'intervenants. Cependant, on peut en dduire en
pratique deux points avoir en mmoire :
1. le traitement des Incidents majeurs est sous la responsabilit du Gestionnaire de Problmes
2. une information jour et une communication cohrente sont importantes (volution trs rapide des informations et
un besoin trs fort en informations des quipes de la Production impliqus et des Clients et Utilisateurs impacts).
Ce rle est rempli par le Centre de Services qui doit collecter ces informations et les enregistrer au niveau de ou
des Incidents associs au Problme.
7 Indicateurs cls de performances (KPI : Key Performance
Indicators)
Juger de l a performance du processus : l es KPIs (Key Performance Indi cators)
7.1 Mtriques couramment utilises :
nombre total dIncidents
temps moyen de rsolution par code dimpact

11

pourcentage dIncidents rsolus dans les temps contractuels ( dfinir dans les Contrats par code dimpact par
exemple)
cot moyen de traitement dun Incident
pourcentage dIncidents ferms par le Centre de Services sans support extrieur (la satisfaction Clients est fortement
influence par le fait que le Centre de Services puissent apporter une solution immdiate l'Incident)
nombre et pourcentage dIncidents rsolus sans dplacement sur site
7.2 Diffusion des informations
La diffusion se fait par le responsable de lquipe Gestion des Incidents
Il est ncessaire de dfinir la priodicit et les listes de diffusion en accord avec le Centre de Services et les diffrentes
quipes de support.
La diffusion doit inclure au minimum lquipe charge des Contrats de Niveaux de Services et les quipes de support
Il faut aussi considrer aussi une diffusion vers les Clients et Utilisateurs (par le biais des rapports sur les Contrats de Niveaux
de Service par exemple)