ITIL

Information Technology
Infrastruture Library
1
 ITIL
ITIL regroupe un ensemble de « bonnes
pratiques pour la gestion d’un système
d’informations »

• Recueil contenant les meilleures pratiques

constatées et glanées dans diverses
organisations de toutes tailles
• Devenu en 1990 un standard adopté
mondialement pour la gestion des services
d’informations 2
 ITIL
• Approche qualité et clients:
Tous les métiers ou processus de l’entreprise
sont réalisés ou accompagnés par les services
informatiques

Longtemps axés sur la gestion « technique » ,

ITIL amène une orientation « clients » basée
sur la qualité des services

3
 ITIL
Buts:
• Aligner les SI au « business » de l’entreprise
• Assurer la qualité des services en réduisant les coûts
• Avoir une utilisation rentable et efficace des
ressources
• Fournir des services contractualisés avec les clients
• Améliorer l’image grâce à la transparence des
activités
• Etre force de proposition avec les organisations
métiers en terme de développement
4
 ITIL
La gestion des services

Scindée en deux parties:

• Le soutien des services

• La fourniture de services
5
 ITIL
Le soutien des services

6
 ITIL
Attribué à un centre de services (Service Desk)

• Différent d’un Call center (volume d’appels

téléphoniques important) et d’un Help Desk
qui traite spécifiquement la résolution des
dysfonctionnements
• Englobe toutes les demandes liées à la
production informatique émanant des
utilisateurs
7
 ITIL
Intérêts pour l’organisation
• Point de contact unique entre les différents
acteurs de l’entreprise et les prestataires
externes -> cohérence et visibilité claire du
service informatique
• Démontre son professionnalisme et son niveau
de qualité de service (savoir être et savoir
faire)
• Aide à identifier les TCO pour l’ensemble des
services 8
 ITIL
Le service Desk est alors un centre de
profit en lieu et place d’un centre de coûts,
il refacture ses services aux demandeurs
(coût par appel, coût au temps passé
…..définis dans les SLA)

9
 ITIL
Rôle et responsabilités:
• Réception et enregistrement de tous les appels
utilisateurs
• Evaluation, résolution ou transfert (escalade)
de tous les incidents sur la base des SLA
convenus
• Veiller à ce que toutes les demandes
enregistrées soient traitées
• Tenir informer les utilisateurs sur l’état et le
déroulement de leurs demandes 10
 ITIL

Produire des tableaux de bord et mesurer la

satisfaction clientèle Les canaux utilisables pour
l’annonce des différents incidents ou demandes
sont:
• Téléphone
• Fax
• E-mail
• Web (intranet)
11
 ITIL
On trouve également les outils de
supervision qui permettent :
Le mode préventif en détectant les
incidents avant qu’ils n’affectent les
utilisateurs: mode « pro-actif »

12
 ITIL
Il existe trois types de structure de service
desk :
• Une organisation locale
• Une organisation centralisée
• Une organisation décentralisée

13
 ITIL
Il faut superviser les activités du service desk
sur :
• La gestion des services : traitement des
demandes, des incidents, ordre de priorité
,escalades
• La gestion des situations de crise : arrêt
majeur des activités de l’entreprise
• La gestion quotidienne des encours

14
 ITIL
Mesure de l’efficience du service desk à l’aide d’indicateurs :
(KPI : Key performance indicators)

• Résolution des incidents

• Disponibilité du système d’information
• Réduction du nombre d’incidents
• Nombre d’appels
• Qualité de résolution
• Info sur la qualité de service
• Satisfaction des utilisateurs …..

15
 ITIL
La gestion des incidents :

Définition: un incident est un événement qui ne

fait pas partie du fonctionnement normal d’un
service et qui provoque ou peut provoquer une
interruption de ce service ou une dégradation
de la qualité de celui-ci

16
 ITIL

Objectif de la gestion des incidents:

Restaurer aussi vite que possible le SLA avec le client-

utilisateur et minimiser l’impact négatif sur
l’organisation

17
 ITIL
Caractéristiques d’un incident:
La description doit être standardisée et détaillée et doit
répondre à deux paramètres primordiaux:
• La traçabilité des événements : date et heure de
l’appel, durée de l’appel, opérateur ayant
réceptionné l’appel, média utilisé etc …)
• La lisibilité : décrit toujours de la même manière ,
elle doit être la plus précise possible. La qualité de
celle-ci influence fortement l’efficacité du processus
et permet de minimiser le temps d’interruption ou la
dégradation sur le service impacté
18
 ITIL
Un incident enregistré doit comporter :

Des information de gestion:

• un identifiant unique : « ticket d’incident »
• Date et heure d’ouverture et/ou fermeture
• Nom du demandeur, coordonnées de contact
• Coût de traitement
• Planning prévisionnel de résolution
19
 ITIL
Des informations descriptives:
Services affectés, dates et heures de détection,
symptômes et phénomènes constatés, contexte,
lieux, particularités ..
Des informations de traitement :
Priorité, état d’avancement, ressources et
moyens alloués, description des actions
réalisées, nom des acteurs, affectation
financière, date et heure de fin ..
20
 ITIL
Priorité d’un incident :
Deux facteurs influençant : l’impact et l’urgence
L’impact est mesuré sur trois critères de volume et
d’ampleur :

1) Bloquant pour plus de dix personnes (clients,

utilisateurs) ou pour une personne occupant un
poste clef
2) Bloquant pour une personne
3) Non bloquant

21
 ITIL
L’urgence est fonction de la criticité par rapport à
l’activité de l’utilisateur ( influence sur son travail)
1) Critique
2) Forte
3) Faible

La priorité d’un incident se traduit par un délai de

résolution (SLA) :
1 = Moins d’une heure
2 = Moins de 8 heures
3 = Sous 3 jours 22
 ITIL
• Etat d’un incident :

Dès qu’il est enregistré , il doit passer par

différentes étapes connues de tous les
acteurs, qui selon la taille et le type de
l’organisation peuvent être agrégés

23
ITIL

24
 ITIL
L’objectif reste la solution définitive (
incident ne se reproduisant plus jamais )
mais il peut parfois être contourné
-> un ticket d’incident peut donc être
fermé mais un ticket problème peut être
ouvert

25
 ITIL
c
Traitement d’un incident:
On trouve en entrée :
• Détails de la base des données de configuration (
CMDB : configuration management data base)
• Recherche des relations entre les incidents et les
problèmes où les erreurs connues ( issus des bases
spécifiques de la CMDB)
• Détails de la résolution ( des mêmes bases)
• Retour des demandes de changement en correction
d’un incident
26
 ITIL
On peut trouver en sortie :
• Mise à jour des bases incidents et/ou erreurs
connues
• Demande de changement pour résoudre les incidents
• Communication de l’état d’avancement aux
utilisateurs ainsi qu’à la fermeture des tickets
• Redirection des demandes de services
• Edition des rapports de l’activité à destination de la
hiérarchie

27
 ITIL
L’escalade (grandes entreprises)
Objectif : résoudre 80% des incidents par le support
de niveau 1 ,c’est-à-dire le service desk ( organisme qui
l’enregistre)
Si non résolution : escalade fonctionnelle ( au niveau
N+1) : correspond dans la plupart des cas à
l’ouverture d’un ticket problème
Cas exceptionnels : escalade hiérarchique-> le SLA ne
pourra être respecté, une ressource de 2ème niveau
manque, nécessité d’obtenir une ressource particulière
(financière, matérielle ou humaine)
28
 ITIL
On se trouve ici au support de 2è niveau (gestion des
problèmes ) dont l’objectif majeur est de proposer une
solution définitive ou de contournement pour rétablir le
service
La propriété du ticket reste celle du centre de service desk
Le ticket d’incident est enrichi des nouvelles informations
issues de l’’activité , les acteurs en sont toujours informés
La fermeture ne peut toujours se faire qu’avec l’accord du
demandeur (l’utilisateur)

29
ITIL: cycle de vie d’un incident

30
 ITIL
La gestion des problèmes :
But : rechercher la cause première des incidents et y
apporter des solutions correctrices pour éviter de
nouveaux incidents
Problème : Se dit lorsque l’on ne connaît pas la cause
d’un phénomène ou d’un comportement en principe
anormal. Même si la cause n’est pas connue, il est
possible qu’une solution de contournement existe.
On ouvre un problème lorsque le contournement d’un
incident nécessite des coûts et un temps de traitement
trop important ou si aucune solution n’existe à ce jour
31
 ITIL
A contrario : un incident dont la cause n’est pas
connue ne donne pas forcément lieu à un problème si
la solution de contournement est efficace , rapide et
durable et la fréquence des incidents faibles
Les erreurs connues :
Lorsque la gestion des problèmes a découvert la cause
du ou des incidents et proposé une mesure corrective
->ouverture d’un ticket erreur qui a pour but de gérer
la mise en œuvre de la correction. La correction peut
être refusée à ce stade (facteur économique) , on
applique donc la solution de contournement sans
éradication 32
 ITIL
La gestion des problèmes a de l’influence sur la
perception de la qualité des services, notamment pour
les problèmes récurrents très mal perçus par les
utilisateurs (la majorité des incidents annoncés au
niveau 1 ne sont pas inédits et les équipes ont déjà
résolu des cas similaires)
->Le suivi des cas et le mode proactif prend ici tout son
sens ( traitement provenant de la prévention)

33
 ITIL
Le contenu de la description d’un ticket problème est
généralement identique à celui des incidents
La priorité s’estime aussi sur la base de l’impact de
l’urgence sauf que :
L’impact mesure l’effet sur le business et est défini
selon 3 classes:
• Majeur : business affecté plus de 3 jours cumulés
• Significatif : sur plus de un jour cumulé
Mineur : business affecté inférieur à la journée

34
 ITIL
L’urgence est fonction du nombre de sollicitations
quotidiennes du service défaillant:
• Critique : nb sollicitations > à 1000
• Forte : > 100 et < 1000
• Faible : < à 100

Etat des tickets problèmes : ils suivent à peu de choses

près les mêmes items que les tickets d’incident

35
ITIL

36
 ITIL
La gestion des changements
Des incidents, des problèmes ou des exigences peuvent
engendrer des modifications d’infrastructure nécessaire du
SI (exemple : nouvelle législation, nouveau projet, réaction
proactive, modification pour améliorations ..)
De ce fait, cette gestion permet
• D’assurer l’application de changements à l’aide de méthodes,
processus, et procédures standardisées.
• Faciliter le changement en le rendant plus efficace et plus
rapide
• Gérer et amoindrir les effets négatifs d’un changement

37
 ITIL
A savoir: la majorité des incidents (80%) sont
issus de changements
2 types de changements :
• Les urgents (immédiats
• Les planifiés (au minimum 95% des
changements doivent être dans ce mode)

38
 ITIL
La gestion des changements se chargent de :
• Enregistrement des demandes
• Évaluation de l’impact ( cout, risques et avantages
liés)
• Réalisation d’une justification et obtention des
accords nécessaires
• Gestion et coordination de la mise en œuvre des
changements
• Rédaction et contrôle des rapports issus de la mise
en œuvre
• Vérification et clôture des demandes de changement 39
 ITIL
Origine des changements :

• Déclaration d’un incident ou d’un problème

• Demande de service ou extension de celui-ci
• Amélioration de services
• Nouvelles exigences de sécurité
• Mise à niveau, montée de version des logiciels
• Péremption d’une version matérielle ou logicielle
• Nouveaux produits ou services

40
 ITIL
Priorité, catégorisation et état d’un changement:
Comme pour les incidents et les problèmes
l’enregistrement d’une demande de changement
nécessite de fixer une priorité et de le catégoriser en:

• Changement standard : changement habituel

suffisamment rodé avec ses procédures pouvant être
géré de façon industrielle par du personnel non
spécialisé

41
 ITIL
• Changement non standard :
Classé en 3 niveaux : majeur, significatif et mineur
Les 2 premiers nécessitent ce qu’on appelle le comité
consultatif sur les changements ( CAB :change
advisory board) composés du gestionnaire de
processus, de technicien , de l’IT, de spécialistes et
d’utilisateurs clients.

Pour le dernier, le gestionnaire de processus évalue et

prend seul la décision du changement

42
 ITIL
Le changement , de sa demande à sa mise en
production passe par différents états :

43
 ITIL
Résumé de l’activité de la gestion des changements :
• Enregistrer et filtrer la demande de changement
• Affecter une priorité initiale
• Affecter un modèle standard ou une catégorie
• Traiter un changement standard
• Analyser et autoriser un changement non standard
• Traiter un changement urgent
• Effectuer la revue post-implémentation
• Suivre et coordonner l’exécution du changement

44
 ITIL
Avantages :
• Impact négatifs moindres
• Meilleur évaluation des coûts liés aux changements
• Meilleur productivité des utilisateurs moins soumis
aux interruptions liées aux changements
• Meilleure productivité des collaborateurs
informatiques
• Capacité plus importante à absorber le nombre de
changements

45
 ITIL
Sa mise en œuvre trop « bureaucratique » peut
provoquer des réticences de la part du personnel
informatique

->Nécessité d’avoir une CMDB efficiente pour

mesurer les impacts financiers et avoir le soutien de
la direction
Manque de contrôle et de suivi lors des changements
urgents si CMDB absente ou non à jour

46
 ITIL
La gestion de la mise en production
Indissociable de la gestion des changements; elle est
issue du monde du développement (release
management = gestion des versions)
ITIL définit la mise en production comme une
combinaison d’éléments de configuration ( CI
nouveaux ou modifiés) testés et introduit dans un
environnement de production
Une mise en production est un ensemble de
changements autorisés par le service IT

47
 ITIL
Une mise en production est composé de :

• Nouveaux logiciels
• Logiciels existants modifiés
• Matériels neufs ou modifiés
• De documentations

48
 ITIL
En résumé , la gestion des mises en production est
responsable de :
• La planification, la gestion et le contrôle du déploiement des
nouveaux logiciels, montée en version ainsi que du matériel et
des documentations s’y rapportant
• La collaboration avec la gestion des changements pour
déterminer le contenu et la planification de la mise en
production
• Le contrôle de tous les éléments de configurations qui sont
déployés ou modifiés et s’assurer de leur existence dans la
CMDB
• La communication envers les utilisateurs et les clients touchés
par la mise en production
49
 ITIL
Politiques des mises en production:
En plus de la notion de base de données des configurations,
elle introduit deux nouvelles bases importantes :
La DSL (definitve software library) : base qui contient toutes
les copies originales de tous les logiciels controlés et validés
dans une organisation
La DHS: (definitive hardware store) réserve de matériel
définitif , base de matériel en réserve ou nouveau mais non
installé conservé dans un endroit sûr et maintenu au même
niveau que le matériel en exploitation
les détails les concernant sont également inscrits dans la
CMDB

50
 ITIL
Test et retour arrière:
Les mises en production doivent subir des
tests rigoureux et être acceptés par les
utilisateurs avant leur déploiement . De plus,
des plans de retour arrière décrivant les
mesures à prendre en cas d’échec total ou
partiel doivent être édités

51
 ITIL
Gestion de la configuration:

Objectifs: fournir un modèle logique de

l’infrastructure en inventoriant , contrôlant et en
maintenant à jour toutes les données et versions des
éléments de configuration (CI : configuration Item )
existants
On y retrouve l’ensemble des produits liés au SI :
matériels , applications, documentations,
procédures.
52
 ITIL
Dans un premier temps, la gestion des
configurations va dénombrer les éléments appelés
composants, eux-mêmes scindés et/ou décrits par ses
composés
Exemple : un PC est un composant , ses composés
sont une carte mère XY, un HDD de 120 Go, mais
aussi l’application Z, le XP SP3 etc …(il faut limiter
le niveau descriptif et trouver un compromis)

53
 ITIL
Points Clés: toutes ces informations doivent figurer
à un seul endroit: La CMDB
Il est important de sélectionner et de travailler avec
un outil qui permette un inventaire automatique
mais surtout qui puisse gérer les liens (relations)
entre les composés (CI)

Exemple : une application client lourde associée à

une application serveur (lotus et domino …)

54
 ITIL
Ces outils servent souvent également à la gestion des
immobilisations informatiques ( date d’achat,
garantie, amortissement, contrat de maintenance,
cout d’acquisition, licences, fournisseurs ..)
La CMDB contient ou peut contenir également des
informations sur les SLA.
La mise en œuvre de la gestion des
configurations est longue et nécessite des
moyens humains et financiers importants
mais l’avantage qu’il procure doit influencer
positivement sa planification 55
 ITIL
La fourniture de services (Service Level
Management)

56
 ITIL
Gestion des niveaux de service:
Buts:
• maintenir et améliorer en permanence la qualité des
services fournis par le SI à l’entreprise
• notifier et documenter les accords de niveaux de
services
• s’assurer que les objectifs convenus (négociés) , les
niveaux demandés ont été atteints et si non,
pourquoi ?

57
 ITIL
Les SLA définissent les objectifs sur lesquels le
centre de service peut être jugé
Périmètre:
• Accords de service (SLA) sur tous les services
fournis par le SI
• Accords avec les fournisseurs externes
• Contrats OLA (operational Level Agreements) pour
les liens internes ( entre le support 1, 2è et/ou 3è
niveau par exemple)

58
 ITIL
Les SLA sont des documents réalisés en partenariat
entre le fournisseur de services et le client en
définissant les objectifs et responsabilités des deux
parties. Les fournisseurs comme les clients peuvent
être internes ou externes
Ils permettent :
• Une meilleure compréhension des processus métiers
et de ses règles
• Une reconnaissance de l’ampleur des tâches liées
aux services proposés et de l’intérêt de débattre en
amont des impacts d’un changement
59
 ITIL
• un partenariat entre le SI et les organisations métiers dans la
recherche d’amélioration continue des processus

Responsabilités :
• Négocier et définir un accord commun avec le client
concernant les exigences et les caractéristiques attendues du
service
• Analyser et éditer les rapports sur les niveaux de service
respectés , les ressources utilisées, le coût des prestations de
service
• Améliorer sans cesse les niveaux de service
• Adapter les SLA en fonction des évolutions de l’entreprise
60
 ITIL
Contenu et structure des SLA:
• Description simple du service et de ses livrables
• Les heures de service négociées
• Les temps de réponse aux demandes des utilisateurs
• Le délai de résolution suite à l’annonce d’un incident
• Idem pour les changements
• La disponibilité du service, les objectifs et moyens pour
assurer la continuité de service
• Les spécificités liées à l’entreprise comme les périodes
sensibles, les congés, les conditions d’une escalade
hiérarchique….
Tous ces objectifs doivent être mesurables
61
 ITIL
On trouve généralement trois types de structure:

• Niveau entreprise : concerne toute l’entreprise sans

distinction de clients ( exemple : temps de réponse à un
appel)
• Niveau client: niveau de service négocié avec un client sans
tenir compte d’un service particulier
• Niveau service : le plus courant car il traite toutes les
questions de gestion des SLA concernant un service
particulier pour un client particulier

62
 ITIL
Avantages :
• clarification des responsabilités et des objectifs de chacun
• Le suivi de la qualité de service permet d’améliorer ceux-ci
• Les malentendus entre les parties sont évités
• Ils jouent un rôle de soutien des relations avec les
fournisseurs
• Peuvent servir de base pour la facturation et permettent de
démontrer la valeur ajoutée du SI
• Les OLA et les contrats de sous-traitance sont mieux adaptés
au business de l’entreprise
Il faut prêter une attention particulière aux aspects réalistes et
mesurables des objectifs , les SLA doivent être soutenus par des
contrats fermes 63
 ITIL
Autre processus de la fourniture de services :
Gestion financière des services :

s’occupe des dépenses et des rétributions financières

entre les services dont l’objectif est d’arriver à une
gestion raisonnée des coûts qui ne pénalise pas
l’entreprise . Il faut toutefois garder à l’esprit qu’une
prestation de qualité est plus onéreuse qu’une
prestation de base, ce processus ne peut prétendre à les
réduire indéfiniment sans que cela ait un impact sur la
qualité des services
64
 ITIL
Gestion de la capacité : garantit que les capacités
nécessaires pour les niveaux de qualité requis sont
disponibles ( investissements matériels, humains ..)

Gestion de la disponibilité :
Garantit que les services IT sont disponibles lorsque
cela est nécessaire. On pourrait imager qu’un
responsable système s’assure que ces serveurs soient
disponibles lors de l’activité « métier » et effectue tous
les entretiens (maintenance) nécessaire

65
 ITIL
Gestion de la continuité : garantit une prestation de
qualité même en cas de catastrophe. Minimise les
interruptions des processus clés lors d’un incident
majeur
-> planification de mesures d’urgence et création de
plans de récupération de données (PRA) , révisée
régulièrement
Ils sont accompagnés de la maintenance du matériel
dédié , non seulement à la récupération de données
mais à l’exploitation après incident qui peut avoir lieu
de manière délocalisée
66
 ITIL
Le plus gros incident pouvant intervenir reste
l’incendie
Si l’activité est répartie sur différents sites, la survie de
l’entreprise peut dépendre de la gestion de la
continuité
Les coûts de possession du matériel et des ressources
nécessaires pour gérer ce processus sont importants, ce
qui provoque souvent l’abandon de cette fonction
Un calcul doit être effectué pour balancer les risques et
les coûts

67
 ITIL
Différents logiciels du marché qui suivent les
recommandations ITIL :

• BMC Service management

• HP service management
• Lan Desk
• GLPI

68
69