Management des services

informatiques

COURS D’ITIL

Enseignant : NDIHOU Henri Martial

Certifié: PMP-PSM1-ITIL-Six Sigma (Green Belt)

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 1
 Centre de service : est le point de rencontre entre les utilisateurs et l'informatique.

CHAP 1 : INTRODUCTION

Le contexte
Le système d’information d’une entreprise est devenu depuis quelques années le cœur de l’entreprise. Les métiers
de l’entreprise sont devenus de plus en plus dépendants de l’informatique et cela dans tous les secteurs. Les échecs
de l’informatique sont extrêmement visibles dans l’entreprise, voire même à l’extérieur de l’entreprise. Que
l’informatique devient au fil des ans de plus en plus complexes. Cette situation est rendue encore plus complexe par
les clients et les utilisateurs qui sont de plus en plus exigeants. Combien coûte l’informatique et combien l’entreprise
est prête à payer pour cette informatique ?

Des réponses à ce contexte

L’informatique, face à ce contexte mouvant depuis quelques années, va apporter des réponses. Elle va se positionner
comme amenant la valeur différenciatrice à l’entreprise.

LES BONNES PRATIQUES ITIL

L’informatique va s’appuyer sur les bonnes pratiques du marché pour se forger une approche professionnelle.
L’intérêt des référentiels publics réside dans l’accès aux meilleures pratiques du métier. Ces pratiques provenant de
la mise en commun d’une multitude de retours d’expériences ont été sélectionnées, généralisées et structurées afin
de permettre leur réutilisation. ITIL est le référentiel utilisé pour la gestion des services informatiques par beaucoup
d’entreprises dans le monde. Mais ce n’est pas le seul référentiel au niveau de l’informatique : on connaît CMMI,
COBIT, Six Sigma, eSCM et d’autres normes comme ISO 9000, ISO 20000.

La démarche ITIL
ITIL est l’acronyme de Information Technology Infrastructure Library. Elles sont produites par l’OGC (Office of
Government Commerce, le ministère du commerce britannique), qui en a la propriété intellectuelle. C’est un cadre de
travail, des recommandations et non un standard et encore moins une norme. La démarche ITIL est ouverte, non
propriétaire, publique.
Les publications de la démarche ITIL
Les publications décrivant la démarche ITIL V3 sont structurées en trois modules : Les publications principales : ce
sont les livres officiels édités par l’OGC qui décrivent ITIL version 3, Les publications complémentaires : c’est en fait
une bibliothèque vivante, composée de livres et d’articles qui évolue et s’enrichit au jour le jour. Les articles sur
Internet : un certain nombre de sites (plus ou moins bons) traitant de la démarche ITIL existent sur le Web.
Les grands principes de la démarche ITIL
Les principes de base de la demande ITIL V3 sont fondés sur quatre concepts :
C1 : Les bonnes pratiques : ce sont des cadres, des lignes directrices : ITIL pour l’adopter, il faut l’adapter. Rien n’est
prescriptif, les bonnes pratiques donnent des indications, des recommandations issues de l’expérience des entreprises
privées ou publiques, petites ou grandes, dans le secteur de l’industrie ou des services.
C2 : La gestion de services : La culture projet est la capacité de l’informatique à implémenter de nouvelles
fonctionnalités liées à des besoins métiers nouveaux, une législation nouvelle, des avancées technologiques. La
culture services est la capacité de produire le service demandé au niveau de qualité demandé avec la maîtrise des
coûts et des risques. Un service est une application qui fonctionne sur une infrastructure, avec la documentation
associée, avec la formation adaptée, avec un support mis en place, de l’assistance aux utilisateurs et surtout un
engagement sur un résultat. La gestion de services, c’est un ensemble de dispositions spécialisées (fonctions et
processus) qui permettent de fournir la valeur aux clients sous forme de services.
C3 : Les processus et les fonctions : Un processus est une suite structurée d’actions, d’activités inter-reliées qui
permetDispensé
d’atteindre
parun but.
: M. Un processus
NDIHOU est mesurable,
Henri Martial il produit
; Certifié desScrum
PMP, ITIL, résultats pour un
Master, Sixclient
sigmaet réagit à des
Page 2 éléments
déclencheurs spécifiques. Un processus est mesurable, c’est-à-dire qu’il comporte des indicateurs qui vont mesurer sa
performance. Un processus doit mesurer son efficacité et son efficience. L’efficacité, c’est l’atteinte d’un but.
L’efficience, ce sont les moyens que le processus va mettre en œuvre pour atteindre son but et la qualité du résultat
obtenu.
Il ne faut pas confondre le processus, la procédure et le mode opératoire. Une procédure va détailler les tâches d’une activité
d’un processus, en précisant en particulier les acteurs, les rôles, les interfaces (entrées et sorties) de ces tâches. Un mode
opératoire est constitué d’une ou plusieurs consignes qui s’appliquent à l’exécution d’une procédure sur un outil.
La fonction est une unité organisationnelle qui a ses ressources et ses moyens propres, responsable de la production d’un
résultat. Un rôle est un ensemble de responsabilités, d’activités et de domaines d’autorité attribués à une personne ou à une
équipe
C4 : Le cycle de vie des services : Représentée par une boucle fermée, la démarche ITIL V3 se nourrit des retours obtenus à
chaque étape du cycle de vie. Cette représentation correspond bien à la réalité de la gestion de services où rien n’est
strictement linéaire ni établi.

-La stratégie de services : C’est la réponse à la question : comment développe-t-on sur le marché en temps que
fournisseur de services ?
-La conception de services : On spécifie le service et les moyens pour le produire.
-La transition de services : On construit le service et on le transfère en production.
-L’exploitation des services : c’est produire et supporter les services de manière efficace et efficiente afin de s’assurer de
la valeur fournie aux clients et aux fournisseurs.
-L’amélioration continue de services : c’est créer et maintenir de la valeur pour les clients via une stratégie, une
conception, une transition et une exploitation de services améliorés.

BON A SAVOIR
L’utilisateur est la personne qui utilise au quotidien le service. L’utilisateur est représenté par le
client : il remonte ses exigences auprès du client. L’utilisateur utilise le service mais ne le paye pas.
Ses relations avec l’informatique sont réalisées uniquement via le centre de services.
Le client est la personne ou l’entité qui est le donneur d’ordre, que l’on appelle aussi la maîtrise
d’ouvrage (MOA). Le client va exprimer des besoins métier, négocier avec l’informatique la solution
qui portera le service, valider cette solution (réception de la solution avec un procès verbal de
recette) et payer cette solution et le service qui supporte cette solution. Le client doit être aussi le
représentant des utilisateurs. Le client peut aussi être un utilisateur de l’informatique. Le client
dispose d’un canal de communication privilégié avec l’informatique via le processus de gestion des
niveaux de services.
Le fournisseur des services informatiques désigne une organisation qui fournit des services à un ou
plusieurs clients internes ou externes. Le fournisseur des services est le département informatique
(la DSI), qui peut s’adosser sur des prestataires externes.
Le fournisseur externe est la tierce partie responsable de fournir des biens ou des services
nécessaires aux services informatiques.
Les différents types de fournisseurs des services informatiques

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 3
 -La direction informatique (la DSI) fait partie intégrante de la branche métier.
-La direction informatique est externalisée, complètement ou partiellement via un fournisseur de
services externes. Ce fournisseur est au service de la branche métier. Cela peut constituer un bon
choix pour certains services spécifiques demandant une expérience forte dans des domaines
technologiques pointus.
-La direction informatique est centralisée et va servir toutes les branches de l’entreprise pour des
applications transverses. On parle alors de DSI entreprise (corporate en anglais).
Les organismes qui gèrent la démarche ITIL V3
-L’OGC (Office of Government Commerce) détient la propriété intellectuelle.
-Les organismes d’accréditation, APM Group, pour l’accréditation, la certification, et la qualification :
EXIN et iseb.
-Les clubs des utilisateurs ITIL, itSMF (information technology Service Management Forum) : les
forums, les ateliers et les séminaires.

CHAP2 : CYCLE DE VIE DES SERVICES

Pré-requis : Maîtriser le chapitre Introduction

Objectifs : À la fin de ce chapitre, vous serez en mesure :
 D’expliquer pourquoi les bonnes pratiques ITIL traitent tout le cycle de vie des services.
 De donner la liste des cinq étapes du cycle de vie.
 De donner la liste des processus qui composent chaque phase du cycle de vie.

CYCLE DE VIE STRATEGIE DE SERVICE

• Quels services doivent être proposés pour satisfaire les exigences du business ?
• Comment créer de la valeur pour les clients ?
• Comment utiliser au mieux les ressources et les aptitudes ?
• Comment se distinguer par rapport aux concurrents ?

La mission de la phase de la stratégie de services est de définir des services informatiques qui vont amener de la
valeur à l’entreprise. Les processus de la phase de stratégie de services sont au nombre de cinq:

La définition de la stratégie de services informatiques

Gestion du Portefeuille des Services
Gestion financière
Gestion de la demande
Gestion relation Business

CYCLE DE VIE ….. CONCEPTION DE SERVICE

Une fois le service est défini, la conception consiste à :

 Etablir les exigences de niveaux de services,
 Etudier la disponibilité et la capacité nécessaires.
 Définir
Dispensé par : [Link] dispositions
NDIHOU Henriadéquates de la continuité
Martial ; Certifié du service.
PMP, ITIL, Scrum Master, Six sigma Page 4
 Valider et établir les exigences de sécurité.
Centre de service : est le point de rencontre entre les utilisateurs et l'informatique.

La phase de conception de services a pour mission de concevoir de nouveaux services ou de faire

évoluer fortement des services existants en vue de les mettre en production. Les processus de la
phase de conception de services sont au nombre de huit:
 La gestion du catalogue de services,
 La gestion des niveaux de services,
 La gestion de la capacité,
 La gestion de la disponibilité,
 La gestion de la continuité,
 La gestion de la sécurité,
 La gestion des fournisseurs.
 Coordination de la conception
CYCLE DE VIE ….. TRANSITION DE SERVICE
Comment faire évoluer le service de la conception vers la production réelle ?
Cette phase est en fait la phase de réalisation et de validation avant la mise en service. Les processus
de la phase de transition de services sont au nombre de sept :
 La gestion des actifs de services et des configurations,
 La gestion des changements,
 La gestion des mises en production et des déploiements,
 La gestion de la connaissance,
 La planification et le support à la transition,
 L’évaluation des changements
 La validation et les tests des services

CYCLE DE VIE…. EXPLOITATION DE SERVICE

Fournir et supporter les services au quotidien.

Du point de vue du client, c’est dans cette phase que le service va produire sa valeur.
Les processus de la phase de conception de services sont au nombre de cinq
 La gestion des évènements,
 La gestion des incidents,
 La gestion des problèmes,
 L’exécution des requêtes,
 La gestion des accès.
Fonctions de l’exploitation de Service
Centre de service
Gestion technique
Gestion des applications
Gestion des opérations

CYCLE DE VIE…. AMELIORATION CONTINUE DE SERVICE

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 5
 Guides pour évaluer et améliorer :
• la qualité du service.
• le cycle de vie des services.
• les processus.

La phase d’amélioration continue de services va maintenir alignés continuellement les services

informatiques sur les besoins métier de l’entreprise et l’évolution de ces besoins en identifiant et en
implémentant des améliorations. Cette phase va prendre aussi en compte la notion de gouvernance
informatique. La phase d’amélioration continue de services comporte un seul processus que l’on
appelle le processus d’amélioration continue en sept étapes.

Processus & modèles Amélioration Continue de Service

Modèle PDCA Plan-Do-Check-Act

Processus Amélioration en 7 étapes
Les bonnes pratiques d’ITIL et ses vingt-six processus sont complétées par quatre fonctions que sont
le centre de services, la gestion des opérations, la gestion technique et la gestion des applications

CHAP3 : LES ROLES ET FONCTIONS

Pré-requis : Maîtriser le chapitre 2

Objectifs : À la fin de ce chapitre, vous serez en mesure : De faire le distinguo entre un processus et
une fonction, D’expliquer la mission des quatre fonctions de la démarche ITIL V3, De mettre en place
et en œuvre une matrice RACI.

Un rôle est un ensemble de responsabilités, d’activités et de domaines d’autorité attribués à un

poste. Un rôle est défini dans un processus ou une fonction. Une personne physique ou une équipe
de personnes peut endosser plusieurs rôles. Par contre les bonnes pratiques précisent que certains
rôles sont incompatibles entre eux. On verra des exemples dans les chapitres suivants. On peut
d’ores et déjà citer le rôle du gestionnaire des incidents qui ne doit en aucun cas être porté par la
même personne que le rôle du gestionnaire des problèmes.

La Matrice RACI

Le modèle RACI est une matrice de référence utilisée pour indiquer les rôles et responsabilités qui
sont en relation avec les activités.

Elle Permet de définir les rôles et les responsabilités pour chaque activité du processus.

RACI veut dire en anglais : Responsable, Accountable, Consulted, Informed. En français : Réalise,
Approuve, Consulté, Informé

 Accountable : (Autorité, redevable) : Propriété de la qualité et du résultat final de l’activité

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 6
La personne qui est A, assume la responsabilité de l’action. Il y a toujours un A et un seul pour
chaque action
 Responsable : (chargé de faire) : La personne(s) qui réalise (ent) l’activité
Le A s’organise comme il le souhaite pour sous-traiter à la personne ou aux personnes qui sont R
l’action à réaliser. Si la ou les personnes qui sont R ne remplissent pas leurs objectifs, c’est la
personne A qui assume la non-atteinte des objectifs. Dans certains cas, la personne qui est A
peut aussi jouer le rôle de R.
 Consulted : (consulté) devra être consulté pour avis
 Informed : (Informé) devra être informé du progrès de l’activité.
L’utilisateur est la personne qui utilise au quotidien le service. L’utilisateur est représenté par le
client : il remonte ses exigences auprès du client. L’utilisateur utilise le service mais ne le paye pas.
Ses relations avec l’informatique sont réalisées uniquement via le centre de services.
Le client est la personne ou l’entité qui est le donneur d’ordre. Le client va exprimer des besoins
métier, négocier avec l’informatique la solution qui portera le service, valider cette solution
(réception de la solution avec un procès verbal de recette) et payer cette solution et le service que
supporte cette solution. Le client doit être aussi le représentant des utilisateurs.
Le propriétaire du service est la personne qui est A (Accountable), sur le service. Le propriétaire du
service représente le service devant toutes les instances de l’organisation. Il va être impliqué dans
tous les contrats relatifs à son service. Il est l’unique responsable du service. Le propriétaire du
service s’assure que le service atteint les objectifs du niveau de services contractualisé et les
exigences des clients du service.
Le propriétaire de processus est la personne qui est A (accountable) sur le processus. Le propriétaire
de processus va être responsable de la définition du processus, garant de sa mise en œuvre et veiller
à son amélioration. Il va nommer le gestionnaire de processus et avec lui définir les activités du
processus. Il va être garant aussi du choix des indicateurs clés de mesure (KPI, Key Performance
Indicators, indicateurs de performance clés).
Le gestionnaire de processus est la personne qui va faire vivre au quotidien le processus. Il est le bras
armé du propriétaire de processus. Le gestionnaire est en R, réalisation, sur les activités du
processus.
La fonction gestion des opérations est garante de la stabilité et de la disponibilité du système
d’information au travers d’activités au quotidien. En d’autres termes la fonction gestion des
opérations est composée de l’ensemble des équipes que l’on appelle communément l’exploitation
ou la production.
L’entité contrôle des opérations (appelée aussi contrôle de l’exploitation) a pour mission de définir
et d’exécuter toutes les activités au quotidien, toutes les procédures, toutes les consignes qui
portent sur l’infrastructure du système d’information.
L’entité gestion des moyens généraux (en anglais facility management) a pour mission de gérer
l’environnement physique de l’infrastructure informatique.
La fonction gestion technique va aider à définir, planifier, implémenter et maintenir une
infrastructure technique stable permettant de produire des services pour les métiers. Cette fonction
est garante de la connaissance technique ou technologique et de l’expertise relative à la gestion de
l’infrastructure.

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 7
La fonction de gestion des applications a pour objectif de supporter les processus métiers en
fournissant son expertise tout au long du cycle de vie des applications. Cette fonction est garante de
l’expertise applicative sur tous les logiciels (progiciel, ERP, etc.).

La fonction centre de services, en anglais service desk : c’est le point de contact unique pour les
utilisateurs. Elle porte toute la relation avec les personnes qui utilisent l’informatique dans
l’entreprise.
Celui-ci est porteur de toute la relation avec les utilisateurs. Cette relation est bidirectionnelle :
-les utilisateurs appellent le centre de services pour communiquer avec l’informatique.
-Lorsque l’informatique veut envoyer des messages d’information vers les utilisateurs, il passe par le
centre de services.
- Le centre de services est responsable de l’information des utilisateurs au quotidien.
-La mission de cette fonction centre de services est de servir les utilisateurs et de les satisfaire.
-Pour réaliser ses objectifs, le centre de services va assurer des activités de niveau 1 de support
(investigation, diagnostic initial) et va gérer les escalades avec les groupes support de niveau 2 ou 3.

Il ne faut surtout pas confondre les trois concepts suivants : Le centre d’appels (call center en
anglais), Le centre d’assistance (help desk en anglais), Le centre de services (service center en
anglais). Seul le centre de services est le concept recommandé par ITIL V3.

Le centre d’appels a pour objectif de prendre des appels en masse. C’est un standard téléphonique
que l’on appelle, permettant de s’identifier (par un nom, un numéro de contrat ou un numéro
d’identification), d’expliquer les raisons de l’appel et de donner éventuellement des symptômes. Le
centre d’appels n’amènera aucune réponse ni valeur ajoutée, au mieux il va transférer l’appel vers un
technicien. Un centre d’appels est au niveau 0.
Le centre d’assistance a pour objectif de gérer les pannes, les dysfonctionnements qui sont remontés
par les utilisateurs. Il est généralement chargé de donner des informations sur l’état d’avancement
du dépannage si l’utilisateur le lui demande. Il s’agit d’actions de type réactif. On attend que
l’utilisateur appelle pour le renseigner.

Les activités de la fonction Centre de services

La prise en compte de l’appel de l’utilisateur, L’enregistrement des informations liées à l’appel de
l’utilisateur, La catégorisation, La codification, L’investigation, La réponse à l’utilisateur en fonction
de la demande, La gestion de l’escalade vers les groupes de support niveau 2 et niveau 3 si
nécessaire, Le suivi de l’appel , La clôture de tous les appels, même s’ils ont été escaladés vers les
groupes support, La gestion des enquêtes de satisfaction des utilisateurs , La mise à jour des bases de
connaissances .

Technologies du centre de services

La technologie peut apporter une aide précieuse à l’équipe du centre de services dans la prise en
charge de ses missions.
Toutefois, il faut garder à l’esprit que la technologie n’est pas un but, mais bien un moyen, et ne doit
être utilisée qu’en ce sens et en complément de procédures et méthodes efficaces.
Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 8
La mise en place de cette technologie associée à l’automatisation d’un grand nombre de tâches
nécessite une discipline plus importante. L’informatique n’est en réalité qu’un amplificateur de
l’organisation et des processus associés. Si ceux-ci sont défaillants dès l’origine, la mise en place
d’outils informatiques ne fera qu’accélérer et amplifier la défaillance.
Il n’y a pas d’organisation universelle et les modalités d’implantation d’un centre de services doivent
être modulées en fonction d’un grand nombre de critères. Cependant, en fonction de l’activité, de la
localisation et de l’importance de l’organisation.

Les bonnes pratiques ITIL V3 proposent quatre types d’architecture avec chacun ses avantages et ses
inconvénients :
1) Le centre de services local ou de proximité est un centre de services qui est implanté sur le
même site que les utilisateurs qu’il sert. Cette architecture est souvent déclinée par un
guichet ou un bureau où les utilisateurs peuvent s’adresser pour leurs demandes ou leurs
pannes.

Les avantages sont bien sûr la proximité des utilisateurs qui va amener une très forte réactivité, un
délai d’intervention plus rapide et surtout une meilleure compréhension de la problématique des
utilisateurs.
A contrario, ce type d’architecture ne permettra pas la mutualisation des ressources et leur
optimisation. Il va rendre plus difficile le partage des connaissances avec les autres centres de
services de l’entreprise.
2) Dans l’hypothèse d’une entreprise qui est implantée sur plusieurs sites, le centre de
services centralisé peut être une réponse. Un centre de services centralisé est implanté sur
un site unique auquel on va accéder via des canaux de télécommunication de type téléphone,
fax ou informatique (par exemple mail).

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 9
Ce type de centre de services est le plus communément implémenté. Un numéro de téléphone
interne unique (un numéro abrégé généralement, facile à retenir), ou une adresse mail générique
permettent de joindre le centre de services sans savoir où il est physiquement basé. Il peut même
éventuellement être basé à l’extérieur de l’entreprise, voire peut-être aussi externalisé. L’avantage
certain de ce type d’architecture réside dans la mutualisation des ressources et des moyens et dans
un meilleur partage de l’information et des connaissances.
Par contre, comme le centre de services n’est pas à proximité de ses utilisateurs, la réactivité sera
moins forte que dans un centre de services local. Pour remédier à cela, les bonnes pratiques ITIL
recommandent de mettre en œuvre des outils de prise en main à distance pour minimiser les
déplacements sur les sites des utilisateurs. On peut aussi remédier à cet inconvénient par le déport
de quelques personnes sur les sites pour gérer les interventions locales. On a alors une
implémentation mixte d’un centre de services local et centralisé.

3) Un centre de services virtuel est un centre de services centralisé qui va mettre en relation
l’utilisateur directement avec la meilleure personne, celle qui a le meilleur profil pour
répondre à sa demande. C’est-à-dire, en fonction de l’heure (par exemple heures de bureau,
jour ou nuit), du pays ou du site d’appel (France ou pays étrangers, site administratif, ou site
de production, etc.), du métier, du profil de l’utilisateur appelant, on va aiguiller l’appel vers
un hotliner adapté au contexte, au métier. Pendant les heures de nuit, on déroute l’appel vers
la cellule d’astreinte. En cas d’un appel d’Angleterre, on déroute l’appel vers une personne
qui parle anglais.
4) Le centre de services qui suit le soleil (en anglais Following the sun) répond à une
problématique particulière. Comment mettre en place un centre de services qui assure son
service 24h/24 sans pour autant avoir besoin d’équipes travaillant en horaires de nuit, en
horaires postés ? Cela nécessite bien sûr des moyens et des outils, des procédures et des
escalades communs et partagés, et aussi la sélection d’une langue commune (souvent
l’anglais).

L’outillage du centre de services

-L’autocommutateur téléphonique intelligent (ACD, en anglais automatic call distributor) : il
distribue les appels téléphoniques aux hotliners en fonction de la charge et de la provenance de
l’appel.
-Le serveur vocal interactif : cela va permettre une préqualification de l’appel en posant des
questions ("tapez 1 si vous appelez pour une demande, tapez 2 pour un incident", etc.), de pallier des
ressources limitées (week-end, nuit, etc.) et de gérer les saturations.
-Le couplage téléphonie informatique : la fiche client est affichée en même temps que l’on prend
l’appel téléphonique.
-Le logiciel de relation utilisateur : il va gérer les tickets d’appels, aider à la saisie de ces tickets, les
suivre, et capitaliser sur les appels précédents.
Le personnel du centre de services doit être sélectionné suivant trois critères :
-Leurs compétences technologiques

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 10
-Leurs compétences métiers
-Leurs qualités humaines

Les indicateurs du centre de services

-L’indicateur principal est bien sûr la satisfaction des utilisateurs.
-Le taux de résolution pour les incidents ou le taux de traitement pour les demandes réalisé sans
intervention des niveaux de support supérieurs ou sans interventions sur site

CHAP4 : PHASE DE STRATEGIE DE SERVICES

Pré-requis : Maîtriser le chapitre3

Objectifs : À la fin de ce chapitre, vous serez en mesure : D’expliquer la mission et les objectifs de la
phase de stratégie de services, De donner la liste des processus de la phase de stratégie de services,
De lister les livrables de la phase de stratégie de services. De donner la liste des processus de la
phase de stratégie de services.

La mission de la phase de stratégie de services est de définir des services informatiques qui vont
amener de la valeur à l’entreprise.
-L’utilité : C’est la fonctionnalité offerte par un service vue du client et des utilisateurs.
-La garantie : C’est l’assurance que le service va remplir les exigences de niveau de qualité de service
contractualisées.
La valeur d’un service est créée par deux autres facteurs que sont : les ressources, les aptitudes.
-Les ressources sont les ressources humaines et les moyens permettant la réalisation et la production
du service. C’est en fait l’argent engagé pour réaliser et produire un service.
-Les aptitudes sont les capacités d’une organisation à piloter les ressources (au sens défini dans le
paragraphe précédent) pour produire de la valeur.
-Les actifs de services désignent les ressources et les aptitudes dont disposent les fournisseurs de
services pour créer de la valeur

Les ressources et les aptitudes constituent les actifs de service.

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 11
 Le dossier d’opportunité métier est un document qui va permettre la prise de décision, la
planification et le support de toute action ayant un impact sur le métier. Ce document va permettre
aussi de justifier un investissement.
Voici une liste d’informations que doit couvrir le document dossier d’opportunité métier : Le
contexte, Les objectifs, Les résultats attendus, Les coûts, les bénéfices, Les options possibles (au
moins une alternative), Les risques, Les recommandations.
Gestion des risques : Dans les bonnes pratiques ITIL V3, il n’y a pas de processus spécifique pour
gérer les risques informatiques comme dans d’autres méthodologies. La gestion des risques va être
portée par la phase de stratégie de services et en particulier par l’élaboration des dossiers
d’opportunité métier vue précédemment, et le suivi de la vie des services au travers du portefeuille
de services.
Gouvernance de l’informatique : Pour les bonnes pratiques ITIL, la gouvernance de l’informatique
assure que la stratégie de l’entreprise et ses objectifs sont bien soutenus par l’informatique et que le
système d’information répond à cela.
Les processus de la phase de stratégie de services
-La définition de la stratégie : c’est un processus qui a pour but de bâtir la politique de l’informatique
et du système d’information pour les années à venir.
-La gestion du portefeuille de services : c’est un processus qui va amener une méthode dynamique
pour gérer la vie des services et en particulier gérer les investissements pour créer de la valeur pour
l’entreprise.
-La gestion de la demande : ce processus garantit la fourniture de services en adéquation avec la
demande.
-La gestion financière : Il gère les investissements de l’informatique.

CHAP5 : PROCESSUS DE DEFINITION DE LA STRATEGIE

Pré-requis : Maîtriser le chapitre 4

Objectifs : À la fin de ce chapitre, vous serez en mesure : D’expliquer la finalité du processus de la
définition de la stratégie, De donner la liste des livrables du processus de la définition de la stratégie.

Mission : Le processus de définition de la stratégie est un processus qui a pour mission de bâtir la
politique de l’informatique et du système d’information pour les années à venir. C’est le processus
maître de cette phase.
Objectifs :
-Veiller à aligner la stratégie de l’informatique sur la stratégie de l’entreprise Déterminer les besoins
présents et futurs des métiers de l’entreprise
-Garantir que les services informatiques correspondent ou vont correspondre aux exigences des
métiers de l’entreprise
-S’assurer que les budgets de l’informatique sont à l’équilibre
Activités :
-Définir le marché : la définition du marché veut dire comprendre les métiers des clients
-Développer l’offre : cette activité va s’appuyer sur le processus de gestion du portefeuille de services
pour bâtir le document portefeuille de services en prenant en compte les besoins du marché.
Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 12
 -Développer les moyens stratégiques : cette activité va permettre de gérer les investissements dans
les moyens tels que l’infrastructure, les applications, les compétences des collaborateurs, la
connaissance, les processus, etc. pour garantir une fourniture efficace des services.
-Préparer la mise en œuvre : cette activité va analyser les points forts et les points faibles de
l’organisation informatique et du système d’information, définir un périmètre et des objectifs et
identifier les facteurs clé de succès associés à ces objectifs.
Toutes ces activités fournissent comme livrable un document qui s’appelle un schéma directeur. Ce
document décrit la politique de l’informatique et du système d’information pour les trois à cinq
années à venir.

Le rôle du gestionnaire du processus de la définition de la stratégie est :

-D’être garant de l’élaboration d’un schéma directeur en ligne avec la stratégie de l’entreprise.
-D’être responsable du fait que chaque nouveau service soit initialisé par un plan d’opportunité
métier.
-De garantir que les ROI seront analysés.
-D’être responsable du fait que les investissements créent la valeur attendue par l’entreprise.

CHAP6 : PROCESSUS DE GESTION DU PORTEFEUILLE DE

SERVICES
Pré-requis : Maîtriser le chapitre 5
Objectifs : À la fin de ce chapitre, vous serez en mesure : D’expliquer la finalité du processus de la
gestion du portefeuille de services, De comprendre les difficultés de mise en œuvre de ce processus,
D’appréhender l’analyse des outils de gestion du portefeuille de services.

La gestion du portefeuille consiste à avoir une vue claire sur la vie des services, leur évolution et
l’arrivée des nouveaux services, ce qui permet de gérer les budgets en conséquence. Le portefeuille
va inclure toutes les informations sur les services fournis, les nouveaux services en développement et
les plans d’amélioration. Il inclut aussi tous les services qui peuvent être proposés par des tiers, des
fournisseurs externes aux métiers. Le portefeuille de services est composé de trois parties :

 Le pipeline des services qui va contenir toutes les informations sur les services en cours de
développement, en gestation.
 Le catalogue de services qui va contenir toutes les informations sur les services en
production ou prêts à être mis en production.
 Les services en cours de retrait.

Seule la partie du portefeuille de services appelée catalogue de services est visible des clients et des
utilisateurs. C’est ce qu’ils peuvent uniquement demander et utiliser. Le pipeline des services n’est

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 13
 pas visibles de l’extérieur car les services sont encore en gestation, en définition et donc sont
susceptibles d’évoluer. Les services en cours de retrait ne sont pas visibles non plus car on ne veut
plus les proposer aux clients et aux utilisateurs.
Le processus de gestion du portefeuille de services est un processus qui a pour mission de maximiser
la création de valeur par l’informatique pour l’entreprise en contrôlant, pilotant, maîtrisant les coûts
et les risques. Le processus de gestion du portefeuille de services est un processus qui va permettre
de prendre des décisions et cela en s’appuyant sur l’outil de portefeuille de services. Le processus de
gestion du portefeuille de services va permettre de mieux anticiper les changements au niveau
stratégique, c’est-à-dire avec un horizon fixé à trois ou cinq ans.

Les activités du processus de gestion du portefeuille de services sont les suivantes :

-Définir : cette activité va effectuer l’inventaire des services existants, valider les informations sur
chacun des services existants, évaluer les coûts de ces services et passer en revue les services
proposés ou en gestation.
-Analyser : cette activité permet de guider l’analyse du service proposé, de définir les livrables de ce
service et ses enjeux en termes métiers.
-Approuver : cette activité a pour but de prendre une décision concernant le service qui a été défini
et analysé dans les deux activités précédentes.
-Lancer : cette activité permet de démarrer la conception du service en identifiant un budget, des
ressources, un plan d’actions et surtout de communiquer cette décision en interne à l’informatique
et vers le métier concerné.
L’acteur moteur du processus de gestion du portefeuille de services est le responsable produit ou
domaine informatique. Le gestionnaire du processus de gestion du portefeuille est souvent l’un de
ses responsables produit ou domaine informatique.

CHAP7 : PROCESSUS DE GESTION DE LA DEMANDE

Pré-requis : Maîtriser le chapitre 6

Objectifs : D’expliquer la finalité du processus de la gestion de la demande. De positionner la mission
du processus de gestion de la demande par rapport à la mission du processus de gestion du
portefeuille de services.

Un schéma ou profil d’activité des métiers définit la dynamique d’un métier et inclut les interactions
avec les clients, les fournisseurs et les parties prenantes. L’analyse des activités d’un processus
métier permet de prévoir les demandes pour des services qui sont au catalogue et qui permettent de
supporter le processus. On va essayer d’obtenir une adéquation entre la demande de l’entreprise
et l’offre fournie par l’informatique par rapport aux services existants. Le processus de gestion de la
demande, va être responsable du fait que les services existants répondent à l’usage que les métiers
en font aujourd’hui et en feront demain. La gestion de la capacité, c’est faire "juste", juste voulant
dire ni trop ni pas assez en fonction de l’usage des métiers et surtout de l’usage qu’en auront les
métiers dans les trois ou cinq ans à venir. Un système d’information surdimensionné va générer un
surcoût qui n’apportera pas de valeur supplémentaire à l’entreprise. À l’inverse, une capacité
insuffisante des services informatiques mettrait en péril la qualité des services et la valeur produite.
Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 14
L’objectif principal du processus de la gestion de la demande est d’aligner l’offre de l’informatique
sur la demande de l’entreprise et réciproquement en termes de capacités et de performances. On est
dans un système qui est tiré par la demande qui va consommer la production. La consommation et la
production des services sont donc fortement. Au contraire d’un produit, que l’on peut stocker, les
services ne peuvent être stockés afin d’anticiper la demande. On doit en permanence ajuster la
capacité, les performances à la demande et surtout obtenir des informations fiables sur les prévisions
de demandes. C’est ce que l’on appelle aussi une production juste à temps, en flux tendu.

Les activités du processus de gestion de la demande : Identifier les métiers et les activités de ces
métiers, Identifier les profils des différents utilisateurs des services proposés, Définir les schémas
d’activité des métiers, Gérer la demande, Développer des offres différentielles, Définir des packages
de services.

CHAP8 : PROCESSUS DE LA GESTION

FINANCIERE
Pré-requis : Maîtriser le chapitre 7
Objectifs : D’expliquer la finalité du processus de la gestion financière. De définir l’implication du
processus de la gestion financière dans la phase de la stratégie de services.

Le retour sur investissement (ROI, Return on Investment) est l’analyse comparée des dépenses, des
coûts financiers liés à un service par rapport à la valeur que va amener à l’entreprise ce service. En
d’autres termes par rapport à ce que l’on investit, combien gagne-t-on ?
Le coût de possession de l’informatique (TCO, Total Cost of Ownership) est l’ensemble des coûts liés
à la fourniture des services informatiques.
Le coût d’un service est l’argent que l’on dépense pour concevoir ou fournir le service. Les coûts
peuvent être directs (identifiables par les factures, comme l’achat de matériel, les contrats de
maintenance, etc.), indirects (par exemple une quote-part à reverser à l’entreprise pour la location
des bureaux, le gardiennage, etc.) ou cachés (ceux-ci vont intervenir dans le TCO, c’est une
estimation des coûts non visibles, par exemple le manque de formation qui induit un surcoût
d’utilisation de tel

Le prix d’un service c’est le coût du service augmenté d’une marge. La valorisation du service. La
valorisation des services se concentre sur deux concepts clés de valorisation :
 Les coûts informatiques sous-jacents.
 L’utilité et la garantie du service comparée à ce que le client peut faire avec ses propres
ressources et aptitudes.
La facturation est l’émission d’une facture permettant de recouvrir de l’argent relatif à un service qui
a un prix convenu.
Le processus de la gestion financière a pour mission principale de comprendre, de quantifier
l’ensemble des coûts de l’informatique service par service pour fournir à chaque métier, et
globalement à l’informatique, la valorisation en termes financiers des services proposés.
L’objectif principal du processus de la gestion financière est de pouvoir prendre des décisions
stratégiques en s’appuyant sur une logique financière.

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 15
 Les activités du processus de la gestion financière sont de deux types : les activités récurrentes, que
le processus va dérouler tout au long de l’année budgétaire, et des activités liées spécifiquement aux
services eux-mêmes.
Les activités récurrentes sont les suivantes : Budgétiser, Comptabiliser, Facturer.
Les activités liées aux services : Valoriser le service, Modéliser la demande, Optimiser la fourniture
du service.
Les enjeux du processus de la gestion financière : Une difficulté dans la mise en place de ce
processus réside dans le fait que les acteurs sont souvent avant tout des financiers et n’ont pas de
connaissance des métiers de l’informatique. La gestion financière est là pour être garante du bon
ratio coût-qualité et malheureusement si on ne connaît pas assez le métier de l’informatique, on
risque de comparer des pommes avec des poires !

CHAP 9 : GESTION DE LA RELATION BUSINESS

Objectifs : À la fin de ce chapitre, vous serez en mesure : D’expliquer la finalité du processus de la gestion de
la relation business, De maintenir une relation positive avec le business, identifier les besoins des clients, et
s’assurer que le fournisseur de service est capable de satisfaire ces besoins via un catalogue de service
approprié.
Les activités
Ce processus a pour activités :
La gestion de la relation du personnel avec les dirigeants business
Assurance que le fournisseur de service informatique à satisfaire les besoins business du client.
Ce processus a un lien étroit avec le processus de gestion de niveau de service

CHAP10 : LA CONCEPTION DE SERVICES

Pré-requis : Maîtriser le chapitre 9

Objectifs : De positionner la phase de conception de services dans le cycle de vie. De donner la liste
des processus de cette phase. De donner une définition synthétique de chacun de ces processus.

Dans le cycle de vie défini par les bonnes pratiques ITIL, la phase de conception est une phase de
réflexion qui va aboutir à une fourniture de documents (documents papiers), surtout pas de
réalisation. Pour prendre un exemple de la vie de tous les jours, si vous voulez faire construire une
maison, vous allez voir un promoteur immobilier, un architecte qui va écouter vos besoins en termes
de maisons et va concevoir un projet : des plans, des croquis, une maquette peut-être, le
positionnement de la maison sur le terrain, un devis financier bien sûr, un choix de matériaux
(maison traditionnelle ou maison en bois), une sélection des entrepreneurs et artisans, etc. Dans
cette phase le promoteur immobilier essaye de cerner votre projet et d’y répondre au mieux. Une
fois l’accord donné, on passera à la phase de réalisation, de construction de la maison, la phase que
l’on appelle dans le cycle de vie des bonnes pratiques ITIL, la transition de services.
La phase de conception de services a pour mission de concevoir de nouveaux services ou de faire
évoluer fortement des services existants en vue de les mettre en production.

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 16
Les objectifs de la phase de conception de services sont : Concevoir les nouveaux services pour
satisfaire les besoins des métiers, des clients. Identifier et gérer les risques qui peuvent survenir
avant la mise en service. Développer les aptitudes dont l’informatique a besoin ou aura besoin pour
satisfaire les besoins des clients, c’est-à-dire les processus et les procédures, et garantir leur
efficacité et leur efficience.

Les facteurs clé de succès :

 Une mise à jour du portefeuille de services, en particulier par la mise à jour des informations
du pipeline de ce portefeuille (informations sur les services en cours de conception).
 Une formalisation des exigences des métiers, des clients sur les nouvelles applications et les
nouveaux services.
 Une prise en compte dès la phase de conception, c’est-à-dire très en amont, des exigences
en termes de disponibilité, de continuité, et de capacité et de performance.
 Une vision claire sur les informations financières, les budgets, qu’ils soient pour la réalisation,
la mise en œuvre, l’exploitation et la maintenance corrective et évolutive.
 Une analyse des risques effectuée très en amont.
 Des options de la fourniture du service (interne, externe, etc.) traitées, chiffrées, évaluées.
Le concept "des quatre P"
Pour qu’une phase de conception de services soit réussie, il faut s’appuyer sur la préparation et
l’utilisation efficace des Personnes, des Processus, des Produits, et des Partenaires. On appelle cela le
concept "des quatre P".
 Personnes, voulant dire les meilleures ressources et compétences internes.
 Processus, c’est définir, ajuster les processus et les procédures en fonction de leurs
utilisations par les services.
 Produits, c’est le choix des produits adaptés aux services requis.
 Partenaires, c’est le choix, l’implication des sous-traitants, des fournisseurs qui sont
spécialisés dans un domaine retenu. Les bonnes pratiques d’ITIL, et en particulier la version 3
d’ITIL, insistent sur le fait que l’on doit s’appuyer sur des prestataires externes qui vont
amener une valeur ajoutée, une compétence que l’informatique n’a pas forcement.
La phase de conception de services possède six aspects majeurs qui vont être portés, gérés par les
activités des différents processus de cette phase :
 Le recueil des exigences du client : les bonnes pratiques ITIL recommandent que ces besoins
soient formalisés par des écrits et surtout validés par le représentant métier, le client. Le
livrable de ce recueil de l’expression des besoins du client est le document SLR (Service Level
Requirement, les exigences de niveaux de qualité de services), incluant les exigences sur les
fonctionnalités du service.
 La définition de la solution : La définition de la solution va permettre d’analyser les exigences
métier recueillies et de concevoir la solution qui va porter le service. Le livrable de la
définition du service est le SDP (Service Design Package), le package de conception de
services, qui est un ensemble de documents qui va définir globalement l’ensemble de la
solution, mais de façon détaillée pour chaque étape ultérieure.

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 17
RAPPEL :
 Un système : un système est un ensemble de composants organisés pour accomplir une
fonctionnalité ou un ensemble de fonctionnalités.
 Une architecture : une architecture est une organisation fondamentale d’un système ou de
plusieurs systèmes, les relations entre eux, et les principes qui guident leur conception, leur
exploitation et leur évolution.
 La conception d’architecture : c’est le document qui va permettre de définir la politique de
conception d’applications, de développement, et d’exploitation en mettant en avant les
contraintes et les obligations retenues. Par exemple, ce document précisera les choix en
termes de bases de données, de système d’exploitation, de technique d’archivage, etc.
Les choix de l’architecture du système d’information devront, dans la mesure du possible, être dictés
par les exigences métier et non pilotés par les exigences technologiques

Les outils nécessaires

 Système de gestion de la configuration (CMS, Configuration Management System).
 Système de gestion de la connaissance (SKMS, Service Knowledge Management System).
 Système d’information de la gestion de capacité (CMIS, Capacity Management Information
System).
 Base de données des sous-traitants et des contrats (SCD, Supplier and Contract Database).
 Système d’information de la gestion de la disponibilité (AMIS, Availability Management
Information System).
 Des outils pour la conception, comme des outils de conception de processus.
 Des outils permettant la représentation graphique des services.
 Des outils pour le centre de services, comme un autocommutateur de type ACD, un couplage
téléphonie-informatique (CTI).
Les indicateurs de mesure du service:
Les indicateurs de mesure du service sont de quatre types :
 La progression ou la volumétrie : quelle est l’évolution des données de volumétrie pour le
service ?
 La conformité : est-ce que le service fait ce que l’on a dit qu’il ferait ?
 L’efficacité : est-ce que le service atteint les objectifs annoncés ?

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 18
  L’efficience : est-ce que le niveau de qualité de service est fourni avec les coûts optimaux ?
Les processus de la phase de conception de services sont au nombre de huit :
 La gestion du catalogue de services.
 La gestion des niveaux de services.
 La gestion de la capacité.
 La gestion de la disponibilité.
 La gestion de la continuité.
 La gestion de la sécurité.
 La gestion des fournisseurs.
 Coordination ou planification de la conception

CHAP 11 : PROCESSUS DE GESTION DU CATALOGUE DE SERVICES

Pré-requis : Maîtriser le chapitre 10

Objectifs : D’appréhender la notion de catalogue de services. D’expliquer la finalité du processus
gestion du catalogue de services. De comprendre les difficultés de mise en œuvre de ce processus.
D’appréhender l’analyse des outils de gestion du catalogue de services.
Le processus de gestion du catalogue de services a pour but de développer et de maintenir à jour un
catalogue de services.
Un catalogue de services est la partie visible par les clients du portefeuille de services. Il va contenir
toutes les informations sur les services produits et sur le savoir-faire de l’informatique. Le catalogue
de services est composé de deux documents qui couvrent les deux aspects : un catalogue de services
métier et un catalogue de services techniques.
 Un catalogue de services métier va contenir le détail des services offerts aux différents
clients.
 Un catalogue de services techniques va contenir le détail des services offerts aux clients sous
une approche technologique, orientée vers les composants. Il va mettre en avant les
éléments de configuration concernés (CI), les ressources, les moyens, etc. qui vont composer
les services.

L’objectif du processus de gestion du catalogue de services est de développer et de maintenir un

catalogue de services qui va contenir toutes les informations détaillées sur tous les services en
production ou prêts à être mis en production.
Les activités du processus de gestion du catalogue de services :
 Définir les services Interfacer avec le portefeuille de services
 Produire les documents catalogue
 Promouvoir les services en interne
 Promouvoir les services auprès de la relation client
 Maintenir les catalogues

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 19
L’acteur principal est le gestionnaire du catalogue de services. Il est le responsable (accountable) de
la production des deux documents qui constituent le catalogue de services et de l’intégrité des
données qui les composent. Il va garantir que les informations sont à jour, exactes, cohérentes, et
sécurisées.
La plus grande difficulté va résider dans le fait de bâtir et maintenir les deux catalogues de services
métier et techniques et surtout de les faire vivre en parallèle (l’un s’appuyant sur l’autre).
Les principaux risques qui sont liés à ce processus de gestion du catalogue de services :
 Des informations erronées ou incomplètes dans le catalogue de services.
 Un catalogue de services qui est sous la responsabilité de plusieurs personnes, voire sans
contrôle proprement dit. Le problème est l’intégrité des données du catalogue de services.
 Une non-connaissance ou une méconnaissance de ce catalogue par les utilisateurs, les
clients, les métiers et par l’informatique.
 Un niveau d’information dans le catalogue mal adapté (trop détaillé ou trop macroscopique).

CHAP 12: PROCESSUS DE GESTION DE NIVEAU DE

SERVICES

Pré-requis : Maîtriser le chapitre 11

Objectifs : D’appréhender la notion de la relation client. D’expliquer la finalité du processus gestion
des niveaux de services. De comprendre les difficultés de mise en œuvre de ce processus.
D’appréhender l’analyse des outils de gestion des niveaux de services
Le client est la personne ou l’entité qui est le donneur d’ordre. Le client va exprimer son besoin et
négocier avec le représentant client coté informatique son expression de besoin pour arriver à un
accord sur une solution qui sera en adéquation entre celle-ci et le prix qu’il est prêt à mettre pour ce
service.
SLM : Service Level Management. Cet acronyme représente le nom du processus gestion des niveaux
de services en anglais.
SLR : Service Level Requirement. En français, la traduction est : exigences de niveaux de services. Les
exigences de niveaux de services sont exprimées par un client pour définir ses besoins sur un ou
plusieurs services informatiques lui permettant d’atteindre un ou plusieurs objectifs des métiers, du
business.
SLA : Service Level Agreement. Cet acronyme est très répandu en France, utilisé en anglais. La
traduction en est : accord sur le ou les services proposés et sur les niveaux de services associés. Cet
accord est le résultat d’une négociation entre le client et le fournisseur du ou des services
informatiques. Il est décrit dans un document contractuel que l’on va appeler contrat de services ou
convention de services. Ce document va définir le ou les services proposés et les cibles de niveaux de
services à atteindre. Un SLA couvre un ou plusieurs services et concerne un ou plusieurs clients. Il
doit être validé et signé par les deux parties (client et fournisseur).
OLA : Operational Level Agreement. Pour réaliser tout ou partie des objectifs d’un SLA, le fournisseur
du service peut avoir besoin de s’adosser à une autre entité de l’entreprise. Par exemple l’appui de
l’entité moyens généraux qui gère l’infrastructure télécom de l’entreprise, un groupe d’expertise
basée dans une autre région... Dans ce cas, le fournisseur du service va négocier avec cette entité

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 20
interne un OLA, un contrat interne d’adossement pour réaliser le SLA avec le client final. Un OLA est
donc associé à un SLA et va définir les engagements de l’entité interne dans la fourniture du service
demandé.
UC : Under Pinning Contract. Pour réaliser tout ou partie des objectifs d’un SLA le fournisseur du
service peut avoir besoin de s’adosser à un fournisseur tiers, externe. Exemple, le dépannage et la
maintenance matériel, le support d’un éditeur logiciel... Dans ce cas, le fournisseur du service va
négocier avec cette entité tierce externe un OLA, un contrat d’adossement pour réaliser le SLA avec
le client final. Un UC est donc associé à un SLA et va définir les engagements du fournisseur externe
(prestataire) dans la fourniture du service demandé. Un UC est un document contractuel.
SIP : Service Improvement Plan. Ce document est souvent appelé en France le plan de progrès. Ce
document va répertorier toutes les demandes d’évolution et d’amélioration du service tant à
l’initiative du client que du fournisseur.
Un SLA est un contrat qui lie un client et l’informatique pour la fourniture d’un ou plusieurs services.
Il doit être validé et signé par les deux parties pour une période donnée. Dans les bonnes pratiques
ITIL, il n’y a pas de tacite reconduction. On renégocie le contrat à l’échéance : le monde bouge,
l’expression des besoins bouge, le SLA doit vivre et évoluer.
Le document SLA doit contenir les informations suivantes (cette liste est non exhaustive) :
 La description du service en terme de fonctionnalités (ou un pointeur sur les informations qui
décrivent le service dans le catalogue de services).
 Les heures d’ouverture du service (heure, jour, période de l’année).
 Le taux de disponibilité sur une période donnée.
 La durée maximale d’indisponibilité.
 Le temps de réponse à une demande de changement.
 Le nombre maximum de changements sur une période donnée.
 Les modalités de mise en production et en particulier les tranches horaires, jours et périodes
alloués à la mise en production.
 Les modalités de support et en particulier les heures d’ouverture du centre de services.
 Les niveaux de sécurisation sur les données (confidentialité, intégrité, disponibilité, voire
authentification et non-répudiation).
 Les performances du service de bout en bout.
 Les modalités du plan de continuité informatique ou un pointeur sur ce plan.
 Les périodes critiques du service et les implications sur les engagements.
 Les coûts ou les prix associés à la production du service (éventuellement en unités d’œuvre).
 Les indicateurs associés à toutes ces données qui vont montrer si les engagements sont
tenus. Avec ces indicateurs, on précise les conditions de mesure, les formules de calcul, le
type des outils de mesure.
 Les modalités du reporting : les tableaux de bord avec des exemples, la diffusion (cadence et
liste de diffusion).
 Et globalement les modalités du suivi : on identifie les instances, leurs rôles, leurs missions, la
fréquence et les participants pour les deux parties.
Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 21
  Les pénalités pour non-respect des engagements de la part du fournisseur du service. Bien
sûr dans le cas d’une relation client interne et fournisseur de la même organisation, il est
souvent très difficile d’appliquer les pénalités.
 Les devoirs du client : il a au moins l’obligation de participer aux différentes instances.
 La liste des contacts significatifs pour les deux parties.
 Les procédures d’escalade en cas de réclamation ou de plainte.
 La date de démarrage du contrat.
 La durée du contrat.
Un contrat de services OLA étant un contrat d’adossement pour réaliser un SLA, le document doit
avoir la même structure que le SLA auquel il se réfère. Étant donné que l’OLA est un contrat interne,
les pénalités sont souvent inexistantes ou non applicables.
Un contrat de services UC étant un contrat d’adossement avec un prestataire externe pour réaliser
un SLA, le document doit avoir la même structure que le SLA auquel il se réfère. Des clauses
juridiques sont à ajouter pour traiter la relation entre les deux organisations.

L’objectif majeur du processus de gestion des niveaux de services est de porter toute la relation
client. Il en est responsable (Accountable dans la matrice RACI).
Les activités
 Définir les structures des contrats d’engagements
 Gérer la relation avec le client
 Collecter les exigences clients
 Collecter les informations sur la conception de la solution
 Écrire les contrats
 Négocier les contrats d’engagements SLA, OLA et UC Faire valider les contrats d’engagements
 Surveiller et mesurer
 Établir et diffuser les rapports et les tableaux de bord
 Revoir avec le client les rapports et les tableaux de bord
 Effectuer les actions correctives

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 22
  Favoriser l’amélioration
 Gérer les réclamations et les plaintes du client
 Mesurer la satisfaction du client
 Améliorer la satisfaction du client
 Revoir les contrats d’engagements
Gérer la qualité globale des services informatiques nécessite à la fois de prendre en compte le
nombre et le niveau des services fournis.
Deux axes principaux de mesure pour ces indicateurs :
Le succès du processus de la gestion des niveaux de services :
 Le pourcentage de services dotés d’un SLA.
 Le pourcentage de diminution du temps de création de SLA.
 Le pourcentage de réunions de revues ayant lieu à la date prévue.
Le succès du service fourni :
 La réduction des services en non-respect de SLA.
 La diminution des non-respects dus à des dépassements d’OLA.
 La diminution des non-respects dus à des problèmes de contrats.
Les acteurs du processus de gestion des niveaux de services
1. Le gestionnaire du processus de gestion des niveaux de services
Le gestionnaire est responsable de la formalisation et de l’implémentation du processus de gestion
des niveaux de services. Il va être en charge de définir tous les documents génériques comme les
contrats SLA, OLA et UC et les autres documents comme SLR et SIP. Il garantit également que des
enquêtes de satisfaction sont réalisées régulièrement et que les conclusions de ces enquêtes sont
diffusées, communiquées et que les plans d’actions induits sont mis en œuvre. Le gestionnaire
s’assure aussi que les contrats OLA et UC soient les plus optimaux au regard des SLA (plus efficients).
D’autre part, il est responsable de la structuration et de l’organisation des SLA par client, groupe de
clients, service, famille de services.
2. Le représentant de la relation client
Ce rôle est très important car il porte la relation client. Ils sont en charge de la relation client pendant
la phase de la vie du ou des services vis-à-vis d’un client. Dans la démarche ITIL, ce rôle va intervenir
beaucoup plus en amont dans la vie du ou des services, c’est-à-dire dès la phase de conception de
services. Il va intervenir dans le recueil de l’expression des besoins du client. Ce rôle est un vrai
nouveau métier qui s’apparente plus à un rôle de commercial qu’à un rôle de chef de projet. La
composante relationnelle est la plus importante. Son objectif est la satisfaction du client et non la
production d’un projet, voire d’un service.
Ce processus est difficile à mettre en œuvre car il n’impacte pas que l’informatique : il inclut le client,
le métier, comme acteur principal. Cela va souvent nécessiter la mise en place d’une organisation qui
n’existe pas au sein de l’informatique et de rôles et de profils spécifiques.
Voici une liste des écueils à éviter, qui sont souvent dus à un dysfonctionnement dans la relation
client :
Le poids du client qui impose ses vues sans négociation possible de la part de l’informatique ;

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 23
à l’inverse, un client qui n’exprime pas ses besoins et s’en remet à l’informatique pour les évolutions
de ses services ;
 un client qui n’est pas représentatif de ses utilisateurs ;
 un client qui ne connaît pas le métier qu’il représente ;
 des SLA écrits dans un vocabulaire trop spécifique, pas clair, ambigu sur les termes ;
 des objectifs inatteignables, non mesurables, pas clairs ;
 des incohérences dans le document ;
 un manque de communication et de diffusion des SLA au sein de l’informatique et plus
exactement auprès des équipes qui vont exploiter, maintenir et supporter ce SLA.

CHAP13 : PROCESSUS DE GESTION DE LA CAPACITE

Pré-requis : Maîtriser le chapitre 12

Objectifs : D’expliquer la finalité du processus de gestion de la capacité. De comprendre les difficultés
de mise en œuvre de ce processus. D’appréhender l’analyse des outils de gestion de la capacité.

Plan de capacité : c’est un document qui va permettre de comprendre l’état de la capacité et des
performances actuelles du système d’information comparés aux besoins contractualisés dans les
différents SLA, d’identifier les besoins futurs en termes de capacité et de performance à moyen et
long termes, et de déduire un plan d’actions pour atteindre ces besoins futurs. Le plan de capacité
doit être cadré par les directives données dans le document schéma directeur, qui est sous la
responsabilité du processus de définition de la stratégie dans la phase de stratégie de services.
La modélisation est une activité qui va permettre d’analyser le comportement d’un composant, d’un
ensemble de composants, ou d’un service pour un certain volume de charge, une certaine capacité
de performance avec une variété de travaux significatifs pour ce ou ces composants ou ce service.
Le dimensionnement des applications est une activité qui va permettre d’identifier les ressources
nécessaires pour supporter une application. Les ressources sont par exemple, l’espace mémoire,
l’espace disque, la bande passante des réseaux, la puissance CPU, etc. Bien entendu, c’est une
activité qui doit être initialisée dès la phase de conception de services et en particulier, dans le
document qui va décrire les exigences du service (le SLR).
Ce processus doit être soutenu par un processus de la stratégie de services, la gestion de la
demande, qui va lui amener les informations sur le schéma d’activités métier de l’entreprise. Le
processus de gestion de la capacité va tenter de dimensionner au plus « juste », ni trop ni pas assez,
en termes de performances.
Pour mettre en œuvre ce processus, on conseille fortement de le découper en trois couches, en trois
strates ou sous-processus :
-Gestion de la capacité métier (BCM : Business Capacity Management) : il s’agit du sous-processus
qui va traiter les tendances, les prévisions, les besoins futurs des métiers.

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 24
-Gestion de la capacité de service (SCM : Service Capacity Management) : on est dans le sous-
processus qui examine la performance des services produits pour un client en fonction des objectifs
de performances décrits dans le SLA.
-Gestion de la capacité du composant (CCM : Component Capacity Management) : ce sous-processus
traite de la performance des ressources de l’infrastructure.
Les activités du processus de gestion de la capacité sont réparties en deux grandes familles :
 Les activités récurrentes ou itératives : ce sont des activités qui doivent être exécutées de
manière répétée pour amener de la valeur.
 Les activités spécifiques : ce sont des activités déclenchées à la demande.
Les activités récurrentes :
 La surveillance de l’utilisation du système d’information.
 L’analyse de cette surveillance et la préparation d’un plan d’actions adéquat.
 Le tunning ou réglage et l’optimisation du système d’information.
 La mise en œuvre d’actions correctives.
 La veille technologique sur les composants utilisés voire sur les services proposés.
Les activités spécifiques sont :
 L’analyse du schéma d’activités métier provenant du processus de gestion de la demande.
 La modélisation pour appréhender le comportement d’un service, d’un composant, dans le
cadre d’une utilisation particulière.
 L’analyse de tendances.
 La simulation de certaines situations.
 Le dimensionnement des applications en fonction des exigences métiers.
Le gestionnaire de la capacité va être responsable du fait que les services et l’infrastructure sont
capables de fournir les performances souhaitées aux meilleures conditions coût/qualité lorsque l’on
en a besoin.
Points de vigilance : Se focaliser sur la capacité des composants, Le manque d’informations sur les
besoins futurs, le fait qu’il faut investir des ressources et des compétences pour gérer ces activités.

CHAP14: PROCESSUS DE GESTION DE LA

DISPONIBILITE

Pré-requis : Maîtriser le chapitre 13

Objectifs : D’appréhender la notion de disponibilité. D’expliquer la finalité du processus de gestion de
la disponibilité. De comprendre les difficultés de mise en œuvre de ce processus. D’appréhender
l’analyse des outils de gestion de la disponibilité.

La disponibilité c’est la capacité d’un composant ou d’un service à remplir les fonctions demandées
pendant une période donnée ou à un moment donné.
La gestion de la disponibilité doit être efficace sur les deux niveaux suivants :
-La disponibilité des services : c’est-à-dire la disponibilité assurée de bout en bout et selon les
objectifs du contrat de services SLA. La disponibilité des services s’appuie sur la disponibilité des
composants.

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 25
-La disponibilité des composants : c’est la capacité des éléments d’infrastructure à assurer leur
fonction conformément aux niveaux de services convenus.
La disponibilité d’un service est équivalente au niveau de disponibilité du maillon le plus faible des
éléments qui le composent. Donc, l’élimination des composants non fiables contribuera
notablement à la disponibilité des services.
La fiabilité c’est l’aptitude d’un composant ou d’un service à fonctionner durablement sans
défaillance. Dans un système, la fiabilité se mesure par rapport à la fiabilité du maillon le plus faible
du système. Par exemple, dans un vidéoprojecteur la fiabilité est déterminée par le maillon le plus
faible du vidéoprojecteur, qui est la lampe. On voit d’ailleurs dans les vidéoprojecteurs récents à
l’affichage lors de la mise sous tension une indication sur la durée de vie restante de la lampe.
Maintenabilité d’un composant ou d’un service : C’est la capacité à remettre en marche un
composant ou un service défaillant. Si on reprend l’exemple du vidéoprojecteur, lorsque la lampe va
griller, en combien de temps vais-je pouvoir changer la lampe ? Disons cinq minutes, le temps de
laisser refroidir l’ampoule. Oui... et non. À condition que l’on ait sur place une lampe de rechange.
Avec la notion de maintenabilité, on aborde des notions de dépannage, de réparation, mais aussi la
notion de pièces de rechange.
« Serviçabilité », capacité de soutien extérieur : C’est le support contractuel qui est assuré par un
fournisseur externe pour garantir la disponibilité, la fiabilité, la maintenabilité d’un composant ou
d’un service.
Le taux de disponibilité, c’est le pourcentage de temps pendant lequel le composant ou le service
fonctionne correctement (conforme à son état normal) sur une période convenue. Le taux de
disponibilité se calcule sur les périodes où le service est ouvert.

-Exemple 1 : si un service est ouvert de 8h à 18h, le calcul du taux de disponibilité sur une journée
avec une panne de 1 heure est de 90%.
-Exemple 2 : si un service est ouvert 24h/24, le calcul du taux de disponibilité sur une journée avec
une panne de 1 heure est de 96%.
Temps moyen de rétablissement (MTTR, Mean Time To Restore) : c’est le temps moyen de
dépannage, de rétablissement d’un composant ou d’un service à la suite d’une panne, sur une
période convenue. Un exemple : si un client accepte un taux de disponibilité équivalent à 1h d’arrêt
sur une période donnée, ce n’est pourtant pas la même chose d’avoir une seule panne qui dure 1h
que 3600 micro coupures de 1 seconde. Le MTTR va permettre d’affiner la notion de disponibilité du
composant ou du service

La résilience

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 26
Capacité d’un élément de configuration ou d’un service informatique à résister à une défaillance ou à
avoir une reprise rapide suite à une défaillance.
Par exemple, un câble équipé d'une armure résistera mieux à la défaillance lorsqu’il sera soumis à
une tension. Voir aussi tolérance aux pannes.
c’est aussi la capacité d’un composant ou d’un système à détecter la panne d’un de ses composants,
à analyser cette panne, et à prendre les mesures pour se remettre en état de marche sans dépanner
et sans aucune intervention humaine. Exemples de composants résilients : les disques de
technologie RAID 5 (un disque est en panne, le RAID redéfinit l’espace disque restant), un cluster (un
serveur tombe, l’autre membre du cluster le détecte et assume les fonctionnalités du premier).

L’objectif principal de ce processus est de s’assurer que le niveau de disponibilité des services
contractualisé dans l’accord de services SLA est bien conforme à ce contrat, c’est-à-dire que le niveau
soit atteint ou dépassé, et cela au meilleur coût.
Dans la disponibilité, à l’inverse de la capacité qui essaye de faire toujours au plus juste, on va
essayer de rechercher toujours à améliorer le taux de disponibilité, mais bien sûr au meilleur coût.
Pour réaliser cet objectif de disponibilité des services (services de bout en bout), il va s’appuyer sur la
disponibilité des éléments qui composent ce service de bout en bout.
Les activités du processus de gestion de la disponibilité sont de deux natures, réactives et proactives.
Les activités réactives sont :
 La surveillance, la mesure, la production des rapports sur les disponibilités des composants et
des services existants.
 L’analyse de ces données et la définition des plans d’actions associés.
Les activités proactives sont :
 La gestion des risques en termes de disponibilité.
 L’élaboration des contre-mesures associées à ces risques.
 La planification de la disponibilité des composants et des services. C’est-à-dire la
détermination des exigences de disponibilité des métiers, les fonctions métiers vitales (Vital
Business Function, VBF), ainsi que la détermination de l’impact des composants défaillants.
On va donc définir les objectifs pour la disponibilité, la fiabilité et la facilité de maintenance.
 L’amélioration de la disponibilité des composants et des services. C’est-à-dire mettre au
point des métriques, investiguer sur les causes sous-jacentes des niveaux d’indisponibilité
des services, et créer et maintenir un plan de disponibilité.
Ces activités vont produire des informations qui sont stockées dans la base de gestion de la
disponibilité, appelée AMIS (Availability management information system).
-Déterminer les exigences de disponibilité des clients : car elle va donner le cadre des seuils et des
limites acceptables par le client. Par contre, trop souvent les clients ne sont pas assez matures pour
identifier eux même le niveau de disponibilité qu’ils souhaitent. À la question "quel taux de
disponibilité demandez-vous ?", la réponse est "100 %, pas de panne, ça doit marcher sans faille".
-Déterminer les fonctions vitales des clients : Cette activité est à réaliser conjointement avec le
processus de gestion de la continuité de services. On va avec les clients identifier les activités qui
sont vitales pour l’entreprise. Une activité vitale est une activité qui, si elle s’arrête, remet en cause la
vie de l’entreprise.

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 27
 Une fois les fonctions vitales déterminées, on va rechercher les éléments de configurations (CI) qui
les composent et les relations qui lient ces composants. Cette analyse va permettre d’identifier les
composants qui sont sur le chemin critique, les maillons faibles. On recommandera d’appliquer des
techniques comme le FTA, Fault Tree Analysis, qui vont permettre de relier chaque composant par de
l’algèbre de Boole, des ET et des OU.
Exemple : je suis formateur, et pour donner ma formation j’ai besoin de visualiser mon discours au
travers d’une présentation que j’affiche via un vidéoprojecteur. Cette fonction de vidéoprojection est
vitale pour moi. Quels sont les éléments de configuration CI qui composent cette fonction : mon PC,
un câble d’alimentation, un câble reliant le PC au vidéoprojecteur, le vidéoprojecteur et le câble
d’alimentation du vidéoprojecteur. J’ai identifié mes composants et leurs relations. On voit dans mon
exemple que tous les éléments sont indispensables et uniques, donc des maillons faibles, sauf le
câble d’alimentation de mon PC, car il peut fonctionner avec sa batterie.

-C’est la définition des objectifs de disponibilité, fiabilité, maintenabilité des éléments qui
composent le service. En s’appuyant sur les données de disponibilité, fiabilité, maintenabilité
communiquées sur chaque composant par les fournisseurs, on va définir des objectifs de
disponibilité, fiabilité et maintenabilité de chaque composant.
-Établir les tableaux de bord de suivi de la disponibilité en identifiant les indicateurs associés : ces
tableaux de bord sont à usage interne et externe à l’informatique.
-Surveiller et analyser les tendances des indicateurs de disponibilité, fiabilité, maintenabilité. Cette
activité est très importante car elle va analyser les tendances des pannes et investiguer sur les causes
des défaillances de niveau de disponibilité.
-Créer et maintenir un plan de disponibilité : Le plan de disponibilité est un document qui va
contenir pour un service un certain nombre d’informations relatives à la disponibilité de celui-ci. Il est
mis à jour régulièrement. Il sert de base à l’élaboration des contrats de type SLA, OLA, et UC relatifs à
ce service.
-Le plan de disponibilité va montrer en ce qui concerne la disponibilité, les exigences du client, les
engagements contractuels dans les différents contrats, l’état actuel de la disponibilité des
composants du service et du service lui-même, et un plan d’actions pour atteindre ces engagements,
et plus tard les dépasser.
Le gestionnaire du processus de gestion de la disponibilité est la personne clé sur ce processus. Il a
pour responsabilité de définir, analyser, planifier, mesurer et améliorer tous les aspects de la
disponibilité des services et des composants. . Le gestionnaire du processus de la gestion de la
disponibilité va donc être obligé de faire intervenir des experts dans tous les secteurs et souvent à
l’extérieur de l’informatique, voire de l’entreprise.
Points de vigilance de ce processus : Le premier point et le plus important, c’est bien sûr une
identification des besoins RÉELS du client. Le manque de personnes qualifiées en disponibilité pour
répondre aux clients.

CHAP15 : PROCESSUS DE GESTION DE LA CONTINUITE

Pré-requis : Maîtriser le chapitre 14

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 28
Objectifs : De distinguer la continuité des services informatiques et la disponibilité du service.
D’expliquer la finalité du processus de gestion de la continuité des services informatiques. De bâtir
un logigramme synthétique du processus de gestion de la continuité des services informatiques.

-Un actif de service est un composant qui est essentiel à la fourniture du service, ou qui coûte cher à
l’entreprise.
-Une menace est une action, une situation ou un fait qui peut entraver le bon fonctionnement d’un
actif de service ou d’un ensemble d’actifs de service.
-La vulnérabilité est la probabilité que la menace se produise sur l’actif ou les actifs concernés. La
vulnérabilité est le pourcentage de risques qui est associé à chaque actif de service.
-Le risque est l’analyse de cette situation (actif, menace et vulnérabilité) pour en comprendre les
effets et les conséquences.
-L’analyse d’impact métier (BIA, Business Impact Analysis) est le document qui va identifier les
impacts, les effets de catastrophes sur l’entreprise. Pour faire simple, si dans l’entreprise on avait à
garder une seule activité, laquelle devrait-on garder ?
-La gestion de la continuité métier est l’approche qui a été définie pour que le métier puisse
fonctionner même si une catastrophe arrive, si une menace se déclenche. La gestion de la continuité
métier, s’appuie sur le document BIA.
-Un plan de secours est un document qui décrit la manière dont on va rétablir les services
informatiques après une catastrophe. Il identifie les critères de déclenchement et la chronologie du
rétablissement. On appelle aussi ce plan de secours, un plan de continuité d’activités informatiques
(PCA) ou un plan de reprise d’activités informatiques (PRA). Dans un PCA, on n’accepte pas
d’interruption des activités, dans un PRA on accepte un délai de rétablissement qui est précisé dans
le plan.
Un plan de secours devrait contenir au moins les informations suivantes :
 le périmètre du plan : c’est-à-dire la liste des services informatiques concernés ;
 Les critères de déclenchement ;
 la liste des personnes autorisées à déclencher le plan avec leurs contacts (tel, adresse mail,
etc.) : ITIL mentionne que ces personnes doivent être des responsables opérationnels ;
 les délais de rétablissement des différents services informatiques ;
 le séquencement de ce rétablissement ;
 les conditions de retour à la normale.
Dans ITIL, il existe trois options de gestion de la reprise :
-La reprise immédiate (ou reprise à très chaud), immédiate voulant dire une reprise sous quelques
minutes, voire quelques heures. Ceci est assez complexe à réaliser et est donc dédié à des contextes
ou l’impact de l’arrêt de l’activité est très fort pour l’entreprise.
-La reprise intermédiaire (ou reprise à chaud), intermédiaire signifie une reprise des activités entre
24 et 72 heures.
-La reprise graduelle (ou reprise douce), graduelle voulant dire une reprise progressive des différents
services informatiques pouvant prendre éventuellement plus de trois jours en passant par un mode
dégradé des différentes activités.

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 29
 Ce processus a pour but de soutenir les activités globales de l’entreprise, des métiers, en s’assurant
que les services informatiques seront rétablis dans les délais nécessaires et convenus. Il est
important de bien comprendre que ce processus n’a pas pour objectif d’empêcher que les
catastrophes surviennent, mais bien de diminuer les effets, les conséquences de cette catastrophe.
Les activités permettant d’analyser le risque: Planification, Analyse d’impact sur l’entreprise,
Évaluation des risques.
Les activités permettant la gestion des risques : Stratégie de l’entreprise, Organisation de la mise en
œuvre, Mise en œuvre des mesures de réduction des risques, Retour à la normale, mise en œuvre.
Le gestionnaire du processus de gestion de la continuité des services informatiques est souvent la
même personne que le gestionnaire du processus de gestion de la sécurité, le RSSI. Ces deux notions,
continuité et sécurité, sont assez proches. Il est globalement en charge d’analyser et de gérer les
risques informatiques.
Les points de vigilance sont : Le manque d’engagement de l’entreprise et de la direction, Le manque
de moyens, Les tests du plan de secours, la prise en compte très en amont dans la phase de
conception des applications de cette notion de continuité.

CHAP16 : PROCESSUS DE GESTION DE LA SECURITE

Pré-requis : Maîtriser le chapitre 15

Objectifs : De faire la distinction entre la sécurité du système d’information et la continuité des
services informatiques. D’expliquer la finalité du processus de gestion de la sécurité. De bâtir un
logigramme synthétique du processus de gestion de la sécurité informatique.

Dans le processus de gestion de la sécurité, on va définir la disponibilité des données et non la

disponibilité des services. . La disponibilité, c’est donner à l’utilisateur qui la demande l’information
dont il a besoin. Par exemple, vous regardez sur Internet le solde de votre compte bancaire. Le
service est disponible ou non (j’atteins l’application qui gère les soldes des comptes), ensuite est-ce
que les informations visualisées sur mon écran sont à jour ? Est-ce que le solde de mon compte n’est
pas le solde d’il y a plusieurs jours ? On touche ici à la notion de disponibilité des informations.
-La confidentialité, c’est rendre accessible l’information à ceux qui en ont l’autorisation et à eux
seuls. Par exemple, un mot de passe sur une boîte de messagerie permet de garantir la
confidentialité des mails.
-L’intégrité, c’est s’assurer que l’information est complète et qu’elle n’a pas été modifiée, altérée de
manière frauduleuse. C’est en fait mettre des protections pour empêcher des modifications non
autorisées.
-L’authenticité consiste à rendre fiables les échanges en introduisant une notion de signature
électronique. Comment peut-on être sûr qu’un mail provenant d’une personne a bien été écrit par
cette personne ? Certes il provient du compte de cette personne, c’est à peu près tout ce que vous
pouvez en dire (et encore !).
-La non-répudiation consiste à assumer le fait d’avoir effectué une action (comme l’envoi d’un mail).

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 30
Système de gestion de la sécurité de l’information (ISMS, Information Security Management System)
est le système qui contient toutes les informations relatives à la sécurité du système d’information.
On va structurer ce système autour de quatre axes :

-Les informations sur la sécurité de l’entreprise et de l’ensemble de l’organisation (en dehors de

l’informatique).
-Les normes, les standards et la législation qui sont applicables sur la sécurité du système
d’information.
-Les procédures de gestion.
-Les directives et les consignes.
Le but du processus de gestion de la sécurité est d’être garant que le système d’information possède
le niveau sécuritaire demandé par l’organisation. Ce processus est le seul parmi les vingt-quatre
processus de la démarche ITIL V3 qui s’appuie sur une norme pour définir son objectif et son cadre. Il
s’agit de la norme ISO 27001.

Une politique de sécurité du système d’information devrait être une déclinaison adaptée à son
contexte informatique de la politique sécuritaire de l’entreprise ou de l’organisation. Cette politique
qui va être décrite dans un document que l’on appelle souvent une Charte de la sécurité du système
d’information devrait être connue de tous les clients, les utilisateurs du système d’information, ainsi
que de tous les collaborateurs informatiques internes ou externes qui travaillent sur ce système.
Les activités du processus de gestion de la sécurité informatique :
-Planifier : cette activité va permettre de définir la politique sécuritaire du système d’information
basée sur la politique sécuritaire de l’entreprise.
-Mettre en place : cette activité va s’occuper de décliner de matière opérationnelle tout ce qui été
défini dans l’activité précédente de planification.
-Évaluer : cette activité d’évaluation va permettre de comprendre si la politique sécuritaire du
système d’information est bien diffusée au sein de l’entreprise, comprise par tous, et appliquée par
tous.
-Maintenir : l’activité d’évaluation précédente va permettre de bâtir un plan d’amélioration,
d’ajustement de la politique sécuritaire du système d’information et de son implémentation.
-Contrôler : cette activité est l’activité de gestion du processus lui-même.

L’acteur principal est bien sûr le gestionnaire du processus de gestion de la sécurité informatique. Il
est chargé d’élaborer une politique de sécurité du système d’information, de la maintenir, de la
communiquer et de la faire appliquer par tous. Il est garant de la confidentialité, l’intégrité, la
disponibilité des données, et des informations.
Le gestionnaire du processus de gestion de la sécurité est souvent aussi le gestionnaire du processus
de gestion de la continuité de services. En effet ces deux processus traitent de la gestion des risques,
des catastrophes qui peuvent intervenir sur le système d’information et visent à déterminer sa
vulnérabilité face à ces risques.

CHAP17 : PROCESSUS DE GESTION DES

Dispensé par :FOURNISSEURS
M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 31
Pré-requis : Maîtriser le chapitre 16
Objectifs : D’expliquer la finalité du processus de gestion des fournisseurs. De comprendre le partage
des responsabilités entre les processus de gestion des fournisseurs et de gestion des niveaux de
services. De comprendre les difficultés de mise en œuvre de ce processus.

Un fournisseur est une organisation externe à l’entreprise qui va intervenir dans le cadre d’un
contrat appelé UC (Underpinning Contract, contrat de liaison par en dessous).
Types de relation avec un fournisseur :
-Sous-traitance : engagement d’une organisation externe pour la fourniture de la conception, le
développement, l’exploitation, ou la maintenance d’un service.
-Co-traitance : engagement d’une organisation externe pour sa participation à des activités du cycle
de vie d’un service.
-Partenariat : engagement entre une organisation externe et l’informatique pour créer de nouvelles
opportunités.
-Mode ASP (Application Service Provision) : engagement d’une organisation externe d’offrir à la
demande la fourniture de tout ou partie d’un service à partir de son propre système d’information et
de son réseau.
La notion de contrat dans ITIL fait référence à deux notions : la notion de « contrat cadre », contrat
qui définit le type de relation entre l’informatique et le fournisseur, ainsi que la notion d’UC qui est le
document qui décrit dans le contexte du contrat cadre les modalités de la prestation du fournisseur.

La réversibilité d’un contrat est l’activité qui permet à la fin de ce contrat au demandeur de
récupérer toutes les connaissances, tout le savoir qui a été développé ou acquis par le fournisseur
dans le cadre de la production de ce contrat.
Le principal objectif de ce processus est de porter la relation avec les prestataires externes et de
suivre les contrats qu’ils endossent pour fournir tout ou partie d’un service avec un souci de garantir
le meilleur ratio coût/qualité. Ce processus va travailler très étroitement avec le processus de gestion
des niveaux de services.
Les principales activités du processus de gestion des fournisseurs sont : Définir la politique de
gestion des fournisseurs, Identifier les exigences des clients pour préparer un dossier à destination
des fournisseurs, Évaluer les fournisseurs, Recruter les nouveaux fournisseurs, Classer les
fournisseurs, Gérer la performance des fournisseurs, Gérer les litiges avec les fournisseurs, Gérer la
fin de contrat.
L’acteur principal du processus de gestion des fournisseurs est son gestionnaire. Malgré tout, deux
autres acteurs interviennent. Il s’agit de l’entité Achats et de l’entité Juridique.
-L’entité Achats va aider le gestionnaire du processus dans les activités liées à la négociation des
modalités des contrats, et bien sûr des prix des différentes prestations auprès des fournisseurs. En
aucun cas l’entité Achats ne doit piloter seule les négociations avec le fournisseur. L’entité Achats est
au service du gestionnaire du processus de gestion des fournisseurs et non l’inverse.
-L’entité Juridique va aider le gestionnaire du processus dans les activités liées aux modalités du
contrat et de sa rédaction. En aucun cas l’entité Juridique ne doit piloter seule les négociations avec

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 32
le fournisseur. L’entité Juridique, comme l’entité Achats, est au service du gestionnaire du processus
de gestion des fournisseurs et non l’inverse.
La responsabilité du gestionnaire du processus est que tous les services produits par les fournisseurs
externes sont bien gérés en garantissant le bon ratio coûts/qualité. Il va être très présent au côté du
gestionnaire du processus de gestion des niveaux de services pour l’assister dans les négociations des
contrats SLA si ceux-ci sont adossés à un contrat UC avec un prestataire externe. Le gestionnaire des
fournisseurs s’assure aussi que tous les fournisseurs remplissent bien leurs engagements et
atteignent les objectifs demandés. Enfin il est garant que sur chaque contrat il y a bien des deux
côtés un responsable identifié du contrat.

CHAP18 : COORDINATION DE LA CONCEPTION

Pré-requis : Maîtriser le chapitre 17

Objectif principal:
S’assurer de la cohérence de la conception des services, des technologies, des architectures afin de
répondre aux besoins actuels et futures du business et de permettre de d’atteindre leurs résultats.

Produire le package de conception de service(SDP) pour répondre à l’affretement de service

(strategie) et aux demandes de changement
Gérer les critères qualités, les exigences et les points de contrôle entre la phase de
conception et les deux phases à savoir stratégie et transition

Dans ITIL V3, ce processus était assuré par le processus de gestion de niveau de services

CHAP19 : LA TRANSITION DE SERVICES

Pré-requis : Maîtriser le chapitre 18

Objectifs : De positionner la phase de transition de services dans le cycle de vie. De donner la liste
des processus de cette phase. De donner une définition synthétique de chacun de ces processus.

Une transition de services efficace peut améliorer de manière significative la capacité d’un
fournisseur de services à traiter un grand volume de changements et de mises en production. Elle va
permettre de :
-faire concorder les nouveaux services ou les évolutions des services existants avec les exigences
métier des clients,
-s’assurer que les clients et les utilisateurs peuvent maximiser la performance de leurs activités en
utilisant les nouveaux services ou les évolutions des services existants.
La transition de services apporte de la valeur aux clients, aux métiers en améliorant :
-La capacité à s’adapter rapidement à de nouvelles exigences et au développement sur de nouveaux
marchés.
-Le taux de réussite des changements et des mises en production.

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 33
 -La prévision en termes de niveaux de services et de « garantie » pour les nouveaux services comme
pour les services modifiés.
-La variation entre les ressources et budgets prévus et réels.
Les processus de la phase de transition de services sont au nombre de sept :
 La gestion des actifs de services et des configurations.
 La gestion des changements.
 La gestion des mises en production et des déploiements.
 La gestion de la connaissance.
 La planification et le support à la transition.
 L’évaluation.
 La validation et les tests
Le point d’entrée de cette phase est une demande de changement RFC (Request For Change).
Processus de gestion des changements : ce processus, qui est le processus maître de la phase de
transition de services, est en charge de contrôler tous les changements qui vont intervenir sur le
système d’information.
Processus de gestion des actifs de services et des configurations : ce processus est en charge
d’identifier tous les composants du système d’information.
Processus de gestion des déploiements et des mises en production: ce processus va intégrer, tester,
et mettre en production les changements.
Processus de gestion de la connaissance : ce processus va être responsable de structurer les bases
de connaissances qui vont permettre de capitaliser sur l’expérience passée.
Processus de planification et de support à la transition : il s’agit d’un processus qui va coordonner
les activités à réaliser dans cette phase pour mettre en œuvre les changements et gérer les
ressources et les moyens à affecter à ceux-ci. C’est un processus qui décline de manière très
opérationnelle les activités de contrôle, porté par le processus de gestion des changements.
Processus d’évaluation : ce processus est déclenché par le processus de gestion des changements
pour déterminer la performance du changement sur le service et en évaluer les effets, les impacts,
les risques associés. Le déclenchement de l’évaluation peut être demandé à tout moment par le
processus de gestion des changements, bien sûr avant de prendre la décision d’autoriser ou de
refuser un changement, mais aussi avant la mise en service.
Processus de validation et tests : ce processus est en charge de fournir des preuves objectives du
bon niveau de qualité de la version que l’on va mettre en production. Il va être garant de la bonne
gestion des réserves, erreurs, dysfonctionnements qui pourraient être découverts. Ce processus va
aussi intervenir dans la phase de conception de services car il va spécifier toute la politique de
validation et les techniques de test des applications qui portent les services

CHAP20 : PROCESSUS DES ACTIFS DE SERVICE ET

DES CONFIGURATIONS

Pré-requis : Maîtriser le chapitre 19

Objectifs : D’appréhender la notion d’élément de configuration. D’expliquer la finalité du processus
de gestion des actifs de services et des configurations.

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 34
La notion d’élément de configuration
Un élément de configuration, dénommé CI (Configuration Item), est un composant du système
d’information qui va contribuer à la fourniture d’un ou plusieurs services ET sur lequel on veut
appliquer un contrôle.
Les types d’élément de configuration décrivent tous les composants du système d’information, c’est-
à-dire :
 Composants matériels : par exemple les serveurs, les postes de travail, les baies de disques,
les périphériques, etc.
 Composants logiciels : par exemple les systèmes d’exploitation, les drivers, les outils de
supervision, l’ordonnanceur, les outils de sauvegarde, etc.
 Composants logiciels applicatifs : par exemple les développements spécifiques, ERP, etc.
 Bases de données : par exemple les bases, les fichiers de paramétrage et de configuration,
etc.
 Flux de données : techniques ou applicatives.
 Équipements réseaux et télécoms : par exemple routeurs, ponts, téléphonie postes et
autocommutateur, vidéoconférence, etc.
 Composants d’infrastructure environnementale : par exemple les sites, l’énergie et les
onduleurs, les climatiseurs, les armoires et racks, etc.
 Services : par exemple les fonctionnalités des services, les contrats de services (SLA, OLA,
UC), etc.
 Documentation : par exemple fonctionnelle, technique, exploitation, maintenance,
annuaires...
 Etc.

Ces éléments de configuration sont identifiés, modélisés par types que l’on appelle classe de CI, ou CI
générique, ou modèle de configuration. La granularité d’un élément de configuration est un point
important, car si elle n’est pas définie correctement, on va vite être submergé par trop de classes de
CI. Prenons un exemple : un poste de travail fixe peut constituer un CI ou des CI (unité centrale,
clavier, écran, voire carte mère, CPU, disque dur, alimentation...). On voit dans cet exemple que le
nombre de classes de CI peut vite être prohibitif. La granularité ou niveau de détail des éléments de
configuration doit être en cohérence avec la politique de maintenance et de support des éléments du
système d’information. Exemple : est-ce que lorsqu’un écran d’un poste fixe est en panne vous
voulez contrôler le remplacement de cet écran ? Si oui, l’écran est un CI à part entière. En fait cette
granularité devrait être en adéquation avec les informations que demande le processus de gestion
des incidents et le processus de gestion des changements. Le niveau de granularité correspond au
niveau le plus bas de la modélisation.

Les attributs d’un CI sont l’ensemble des informations qui vont décrire l’élément et son
comportement pendant sa vie. Ce sont ses caractéristiques techniques, financières, administratives.
Les attributs sont statiques (date d’achat par exemple) ou dynamiques, c’est dire qu’ils peuvent
évoluer suivant la vie de l’élément (dépréciation et amortissement par exemple).
Voici une liste exemple non exhaustive des attributs d’un CI poste de travail :
 Nom
 Numéro de série

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 35
  Catégorie, Type, Modèle
 Localisation, Responsable
 Constructeur, Revendeur
 Dates : livraison, installation, mise en service...
 État (voir la section ci-dessous)
 Prix, coûts, Amortissement, Dépréciation
 Relations (voir la section ci-dessous)
 Liens avec les autres bases de données (incidents, problèmes, changements...)
L’état d’un élément de configuration représente son avancement dans son cycle de vie et son
exploitabilité. C’est-à-dire pour un CI de type élément matériel, "En commande", "Livré", "en Stock",
"Configuré", "Installé", "Mise en service", "en Panne", "au rebus"... L’état va évoluer sous l’effet des
actions des autres processus.
Les relations servent à identifier les liens qui existent entre les différents éléments de configurations
en précisant leur nature. Ces relations vont montrer ces liens sous des aspects différents, ce qui va
permettre à chaque demandeur (à chaque processus demandeur) d’obtenir à partir d’un élément des
informations sur d’autres éléments qui lui sont reliés.
Voici quelques exemples de relations :
Situation : est situé à, est dans la travée x, est dans le rack N° x…
Relation physique de type père-fils : est relié à tel serveur, est périphérique de x, est connecté à tel
routeur...
Relation fonctionnelle : est composé de, fonctionne sous l’environnement x, met à jour tel
composant...

La notion de composant (CI) s’accompagne obligatoirement d’une autre notion qui est le nommage
de ces composants. Chaque CI a un nom, une identification qui permet de l’identifier de manière
unique. Un actif de service (Asset en anglais) est une ressource ou une capacité au sens du processus
de gestion des actifs de services et des configurations. Les actifs d’un fournisseur de services
regroupent tout ce qui peut contribuer à la fourniture d’un service.
Chaque type d’élément de configuration va être modélisé, c’est-à-dire défini et structuré. Un modèle
de configuration va donner les modèles des services, des actifs et des éléments de l’infrastructure en
précisant les relations qu’ils ont entre eux.

Le niveau de granularité est le niveau le plus bas auquel on arrête la modélisation de l’infrastructure
(voir le paragraphe relatif à la définition des éléments de configuration). On appelle ce niveau de
granularité le CI level.

La CMDB (Configuration Management Data Base), la base de données des configurations, désigne la
base de données et l’outil de gestion associé.
Le CMS (Configuration Management System), système de gestion de la configuration, est un système
contenant l’ensemble des informations relatives aux éléments de configuration sur le périmètre
défini.
Par exemple, un élément de configuration de type CI service va contenir des détails sur le
fournisseur, le coût d’achat, la date de renouvellement, le contrat de maintenance et la
documentation relative au contrat de sous-traitance. Le CMS, lui, va maintenir les relations entre les
composants service et les incidents, problèmes, erreurs connues, changements et mises en
production associés.

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 36
Le CMS est un ensemble d’outils et de bases qui permet de gérer les données de configuration. Le
CMS prend des données provenant de plusieurs CMDB pour constituer une CMDB fédérée. La
configuration de base (Base line, en anglais) est la configuration d’un produit ou d’un ensemble de
produits établie à un moment donné.
La configuration de base, à un moment précis dans le temps, récupère à la fois la structure et les
détails de la configuration. Elle sert de référence pour les activités à venir. La base de référence d’une
application ou d’un logiciel apporte la possibilité de modifier ou de reconstruire plus tard une version
particulière.
L’objectif principal du processus de la gestion des actifs de services et de la configuration est de
définir et de contrôler les composants de service et d’infrastructure et de maintenir des informations
précises et exactes sur leurs états actuels, sur leurs historiques et sur leurs états planifiés.
Le périmètre du processus de la gestion des actifs de services et des configurations doit être
clairement défini, car c’est sur ce périmètre que le processus va s’appliquer. Les bonnes pratiques
ITIL V3 recommandent que l’on implémente le processus d’abord sur un périmètre pilote, puis de
l’étendre progressivement à l’ensemble du système d’information : par exemple, un service pilote
(application et infrastructure associée), puis un site ou une branche métier complète, puis l’ensemble
des services et du système d’information.
Les activités du processus
-L’activité de planification est l’activité qui va donner le cadre, le périmètre du processus de gestion
des actifs de services et des configurations.

-L’activité d’identification a pour but de sélectionner, identifier de manière unique et définir les
éléments de configurations (CI), les attributs associés, les relations.

-L’activité de contrôle va s’assurer que seuls les éléments de configuration autorisés et identifiables
sont enregistrés.

-L’activité de gestion des états va produire des rapports sur les états des éléments de configuration
régulièrement.

-La vérification et l’audit

L’acteur principal du processus de gestion des actifs de services et des configurations est le
gestionnaire. Il est le responsable de la mise en œuvre des objectifs définis par l’activité de
planification.

Les points de vigilance

-La résistance au changement
-Le processus est ambitieux. Il est très important de définir un périmètre initial réduit et ensuite de
l’étendre progressivement à l’ensemble des éléments de configuration du système d’information.
-Le volume des informations manipulées doit amener à une grande prudence dans la détermination
du niveau de granularité des éléments de configuration : ni trop profond, on risque de se perdre dans
les informations à gérer, ni trop élevé, il présente alors peu d’intérêt pour les autres processus.
-Une approche hiérarchisée pour la structure des éléments de configuration est fortement
recommandée pour simplifier la modélisation.
Les risques

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 37
Il est clair que la mise en œuvre de ce processus est risquée, car il va être visible par tous les autres
processus et il va demander des investissements parfois importants tant en budget qu’en ressources
humaines.
Voici deux risques à prendre en compte :
 Une trop grande focalisation sur la technique et non sur l’opérationnel, voire une non-
compréhension des services offerts aux clients ou des métiers des clients eux-mêmes.
 Un manque de rigueur dans la gestion du CMS et des CMDB et surtout un manque de rigueur
dans la prise en compte des informations remontées par le processus de gestion des
changements et le processus de gestion des déploiements et des mises en production.

CHAP 21 : PROCESSUS DE GESTION DES

CHANGEMENTS

Pré-requis : Maîtriser le chapitre 20

Objectifs : D’appréhender la notion de changement. D’expliquer la finalité du processus de gestion
des changements. De comprendre les difficultés de mise en œuvre de ce processus.

Au sens ITIL, un changement est une modification d’un ou plusieurs éléments de configuration
(Configuration Items, voir le chapitre Le processus de gestion des actifs de services et des
configurations) composant le système d’information ou d’un ou plusieurs services fournis par ce
système d’information, modification voulant dire ajout, modification d’attribut du CI ou retrait d’un
ou plusieurs CI.
Comme on l’a vu au chapitre précédent décrivant ce qu’est un CI, une modification d’une
documentation ou d’un contrat est un changement. Voici quelques autres exemples de changement :
une nouvelle version d’un logiciel applicatif, l’installation d’un poste de travail, l’introduction d’un
nouveau serveur, le remplacement d’une imprimante...
La modification d’une donnée (data) n’est donc pas un changement. L’attribution d’un droit d’accès
n’est pas un changement. Une modification d’une activité d’un processus métier n’est pas un
changement.
Une demande de changement, RFC (Request For Change) est une formalisation d’une modification
d’un ou plusieurs éléments de configuration. Tout changement doit être formalisé par une RFC.
Dans les bonnes pratiques ITIL V3, on identifie trois types de changement :
 Le changement dit normal : il nécessite une évaluation complète et une autorisation avant sa
réalisation.
 Le changement standard : cela concerne les changements pré-autorisés et qui vont suivre
des procédures prédéfinies.
 Le changement urgent : il demande une réaction plus rapide que prévu pour limiter les
impacts sur le métier.
Les caractéristiques d’un changement dit normal : C’est un changement qui n’est pas standard, ni
urgent. On le caractérise par une nécessité d’évaluation et de suivi (ou de contrôle) qui sera plus ou
moins importante en fonction des risques, de la complexité, de l’effort nécessaire à la réalisation du
changement. On parle de changement normal mineur, significatif ou majeur.

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 38
Les caractéristiques d’un changement standard : Les actions nécessaires pour mettre en œuvre un
changement standard sont connues, documentées, déjà réalisées, testées, sous contrôle. Les risques
sont faibles, et bien maîtrisés. Les ressources et les coûts sont connus. Une pré-validation technique
a déjà été faite. Seule une validation budgétaire est nécessaire.

Les caractéristiques d’un changement urgent : Tout d’abord l’urgence n’est pas la normalité, c’est
l’exception. On va utiliser les changements urgents de manière exceptionnelle. L’urgence est
demandée par l’émetteur de la demande (RFC), mais elle devra être validée, autorisée par une
instance que l’on appelle ECAB (Emergency Board). L’urgence va permettre de court-circuiter les
procédures de réalisation et de mise en oeuvre du changement pour réduire les délais. Par exemple
en repoussant l’écriture de la documentation après la mise en service, voire en minimisant les tests.
Par contre un changement urgent devra toujours appréhender les procédures de retour arrière, et
les tester. Un changement urgent peut nécessiter une déplanification d’autres travaux, une
affectation de ressources supplémentaires au détriment d’autres activités.
Un modèle de changement est la description de la ou des procédures qu’il faut suivre pour réaliser
ce changement.
Le CAB (Change Advisory Board) est le comité consultatif qui évalue et donne un avis sur la mise en
oeuvre des changements dits normaux
Le ECAB (Emergency Change Advisory Board) est le comité qui donne l’autorisation de traiter le
changement en urgence.
EXEMPLE
Sur un aéroport il y a une tour de contrôle. On n’imagine pas aujourd’hui un aéroport sans tour de
contrôle. Pour décoller ou atterrir, un avion a besoin des aiguilleurs du ciel qui sont dans la tour. Le
contrôle aérien est l’organe qui va donner des ordres au pilote pour tous les mouvements de l’avion
sur la piste. Il va lui donner l’ordre de quitter son emplacement de parking, de rejoindre la piste et de
décoller. Pour un autre avion, il va donner l’autorisation d’atterrir, contrôler sa descente (voire
donner des conseils au pilote), une fois sur la piste lui allouer un numéro de parking et de passerelle.
Celui qui pilote l’avion, c’est le commandant de bord. Le contrôle aérien demande au pilote
d’exécuter des ordres. Le contrôle aérien contrôle tous les avions, tandis que le pilote conduit son
avion à destination.
Un changement urgent serait une situation où le pilote de l’avion demande un atterrissage en
urgence car il y a une panne importante dans l’avion ou un passager très malade... Il va devenir
prioritaire, le contrôleur du ciel va déprogrammer les atterrissages des autres avions et les mettre en
attente. Cette situation doit être très exceptionnelle.
Le processus de gestion des changements, c’est le contrôle aérien ; le processus de gestion des mises
en production et des déploiements, c’est le pilote de l’avion.
Bien sûr, si on prend le cas d’un petit aérodrome, où il n’y a que très peu de mouvements d’avions, il
n’y a pas de tour de contrôle : les pilotes prennent connaissance des autres plans de vol et agissent
en conséquence. Le processus de gestion des changements est rendu nécessaire par un nombre
important de changements.
Les objectifs du processus de gestion des changements sont de :
-Garantir que tous les changements sont enregistrés, évalués, autorisés, priorisés et que leur
réalisation, intégration et déploiement suivent une procédure définie.

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 39
-S’assurer que les procédures et les méthodes utilisées pour traiter les changements sont efficaces,
voire efficientes.
-S’assurer que les modifications apportées aux éléments de configuration (CI) lors d’un changement
sont bien enregistrées dans la CMS (Configuration Management System).
-Répondre aux évolutions exprimées par les besoins des clients en minimisant les risques
d’interruption de services et en maximisant la valeur fournie.
Le périmètre : Les objectifs du processus gestion des changements s’appliquent sur un périmètre qui
doit être défini explicitement (en particulier en identifiant aussi ce qui ne fait pas partie de celui-ci).
Il couvre :
-Toute modification ou ajout ou retrait d’un élément de configuration tout au long de son cycle de
vie réalisée en interne ou chez les fournisseurs.
Il ne couvre pas :
-Les changements d’activités ou d’organisation métier.
-Les changements au niveau opérationnel liés à du consommable (exemple, changement de
cartouche d’encre).
Les activités

Les activités
-Créer la RFC (demande de changement)
-Enregistrer
-Filtrer la RFC (demande de changement)
-Question : changement standard ?
-Valider le changement standard
-Évaluer
-Question : autorisation ?
-Planifier
-Contrôler la mise en oeuvre
-Revoir et clôturer
Le gestionnaire des changements

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 40
Il intervient dans l’écriture des différentes procédures qui vont supporter le contrôle des
changements en fonction de leur type, mais aussi dans la vie au quotidien des changements. Le
gestionnaire des changements assure aussi le rôle de secrétaire du CAB, c’est-à-dire qu’il prépare le
CAB, identifie les participants au CAB (et en particulier les participants occasionnels), convoque les
participants, anime la réunion de CAB, enregistre les décisions du CAB et diffuse le compte-rendu. Ce
rôle n’est pas un rôle facile dans l’informatique et même dans l’entreprise. Il peut être vu comme la
personne qui freine voire bloque les évolutions, les changements. Pour tenir ce rôle, le gestionnaire
des changements doit être une personne qui a une légitimité dans l’entreprise.
Le CAB (Change Advisory Board)
Ce comité est une instance qui donne un avis au gestionnaire des changements dans l’évaluation et
la planification du changement. Le CAB se réunit régulièrement pour traiter les changements
normaux significatifs et majeurs.
Le gestionnaire des changements va présenter au CAB le changement pour une évaluation. On va
regarder la justification, les risques, les coûts, la priorité... Le gestionnaire des changements prend sa
décision d’autorisation ou de rejet (voire de report) du changement en tenant compte de l’avis des
membres du CAB.
L’ECAB (Emergency CAB)
Ce comité est une instance qui va donner l’autorisation de traiter un changement dans le mode
urgent. Il va en fait qualifier les changements urgents, c’est-à-dire évaluer le fort impact métier et les
risques associés, pour autoriser de manière exceptionnelle une mise en œuvre plus rapide que la
procédure normale.

Il existe d’autres instances qui vont évaluer et autoriser les changements. Lorsque le changement est
majeur, c’est-à-dire que le changement impacte fortement le système d’information, voire le
fonctionnement de l’entreprise, le CAB n’est souvent pas adapté à la prise de décision. On doit
remonter l’évaluation et l’autorisation à des instances orientées Direction. On parle alors de Comité
de direction informatique ou même, s’il s’agit de projet d’entreprise nécessitant un investissement
important, d’un comité stratégique voire d’un comité exécutif de Direction de l’entreprise.
Schéma d’escalade des instances du changement
Le gestionnaire des changements est la première instance pour les autoriser les changements
simples (standard et normaux mineurs). Ensuite si le changement est plus important, on passera
devant le CAB pour une décision collégiale. Pour un changement significatif ou majeur, on remontera
aux comités de Direction.

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 41
La résistance au changement
Ce processus a une mission qui généralement n’existait pas au sein du département informatique. Il
va donc falloir convaincre les collaborateurs de la nécessité de mettre en œuvre ce processus et des
bénéfices qu’il va apporter sur le niveau de qualité du service rendu. C’est ce que l’on appelle
l’accompagnement du changement.
Les points de vigilance
 Le processus peut être vécu comme bureaucratique, ce qui va forcément entraîner une
mauvaise image de ce processus et donc va amener les collaborateurs à contourner les
procédures de gestion des changements.
 Le processus peut amener des retards dans la mise en œuvre du changement et donc
impacter la réactivité de l’informatique. Ce processus génère un goulot d’étranglement. Les
changements sont en attente d’évaluation et d’autorisation.
 Il peut amener aussi une surcharge de travail, car avant de mettre œuvre le changement, il
faut remplir une demande de changement et se justifier.
 La Direction doit suivre les procédures définies et non user de leur autorité pour les court-
circuiter.
 L’activité d’évaluation doit avoir les moyens, les ressources et le temps pour faire son travail
et amener des réponses aux questions que l’on se pose. Sinon cette activité va vite basculer
dans un simple bureau d’enregistrement des changements. En particulier le lien avec le
processus de gestion des actifs et des configurations est important, car le système de gestion
de la configuration (CMS) va nous offrir une grande visibilité sur les impacts et les risques
associés au changement.
Les indicateurs du processus de gestion des changements
 Le nombre de changements qui ont été réalisés avec succès. Cet indicateur nous montre la
stabilité ou l’instabilité du système d’information.
 Le nombre de changements qui ont échoué. Échoué veut dire que le changement n’a pas
atteint son but. Il n’est pas si simple à mettre en œuvre. Il ne faut pas confondre cet
indicateur avec un autre indicateur, celui qui montre si les mises en production ont réussi ou
échoué.

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 42
  Les interruptions de service qui sont dues à des changements de piètre qualité. Cet
indicateur va mesurer les incidents suite à un changement, non pas sur le nombre, mais sur
l’impact qu’ils vont avoir sur la disponibilité du service.
 Le nombre de changements réalisés qui ne sont pas planifiés. On devrait tendre vers zéro,
bien sûr.
 Le nombre de changements urgents. Le nombre de changements urgents devrait être situé
autour de 5% de la totalité des changements.
 La diminution du nombre de demandes de changements en attente (le backlog). Cet
indicateur est important car il montre si le processus de gestion des changements est ou non
un goulot d’étranglement dans la mise en œuvre des changements.

CHAP22 : PROCESSUS DE DEPLOIEMENT ET

MISE EN PRODUCTION

Objectifs : D’expliquer la finalité du processus de gestion des déploiements et des mises en

production. De comprendre les difficultés de mise en œuvre de ce processus.

Mission : ce processus va couvrir toutes les activités que l’on appelle communément l’intégration, la
pré-production, le déploiement et la mise en production.
Une unité de production est un ensemble d’éléments de configuration (CI) cohérent qui est livré
pour être mis en production. Cet ensemble est conforme aux exigences décrites dans le document de
politique de mise en production. Une unité de production peut contenir du matériel, du logiciel, de la
documentation, un mélange de tous types d’éléments de configuration.
Par exemple, une organisation peut décider que l’unité de mise en production pour une application
métier critique est l’application complète de manière à assurer que les tests sont compréhensibles.
D’autre part, elle peut décider que l’unité de mise en production la plus appropriée pour un site Web
se situe au niveau de la page.
Une unité de production groupée est un ensemble d’unités de production. Cela permet d’embarquer
dans une même mise en production plusieurs changements qui ont des liens entre eux. C’est
souvent, par exemple, ce que l’on appelle communément en informatique un palier technique ou un
palier fonctionnel. On met dans une même version, un ensemble d’évolutions ou de modifications
d’un logiciel ou d’une application.
Par exemple, une nouvelle version d’une application nécessite une mise à jour du système
d’exploitation (Unix, Windows, etc.) et une évolution du matériel. Dans ce cas, il faut envisager une
mise en production groupée.
Une unité de production groupée intègre l’ensemble des changements requis pour assurer le service,
comme :
 La modification de l’infrastructure technique.
 La formation des équipes support.
 La documentation d’exploitation et de maintenance.
 La mise à jour des services dépendants.

La DML, bibliothèque définitive des médias (Definitive Media Library) est une zone d’archivage
physique sécurisée des éléments de configuration logiciels (CI logiciel) mis en production. On stocke
Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 43
les exécutables (les binaires) des différentes versions des logiciels mis en production. C’est la
référence pour tous les logiciels.

La DML est un élément essentiel au processus de gestion des déploiements et mises en production,
car c’est avec les masters qu’elle contient que l’on va effectuer les déploiements futurs.

Les options des modes de déploiement Ce processus est responsable du choix du mode le plus
approprié au déploiement d’une unité de production.
a. Big bang ou par phase
Big bang : le déploiement est effectué en une seule opération vers tous les utilisateurs.
À l’inverse un déploiement par phase s’effectue selon un plan de déploiement qui va tenir compte de
périmètres définis par le client. Une première base d’utilisateurs, puis les autres par phases.
b. Mode Push ou Mode Pull
Push : un mode de déploiement à l’initiative d’un centre vers les sites utilisateurs cibles. On fait une
mise à jour sur l’ensemble des utilisateurs concernés.
Pull : le déploiement est mis à disposition des utilisateurs sur un centre, les utilisateurs vont initier
eux-mêmes le déploiement à leur convenance. Le déploiement est initié depuis les sites cibles.
c. Automatique ou manuel
L’automatisation des déploiements est fortement conseillée chaque fois que c’est possible pour des
raisons d’efficacité. Le déploiement manuel, s’il est utilisé, doit faire l’objet d’une surveillance forte
et de contrôles pour éviter les erreurs humaines.

Le document intitulé la politique de mise en production, est un document qui va spécifier comment
le processus de gestion des déploiements et des mises en production va travailler durant l’année et
définir ses engagements vis-à-vis du processus de gestion des changements. Ce document va donner
les droits et les devoirs de la gestion de la mise en production.
Les activités du processus de gestion des déploiements et des mises en production sont nombreuses.
-La planification de toutes les activités et des ressources associées est l’activité initiale de ce
processus.
-L’approvisionnement de tous les composants
-L’intégration va permettre de mettre ensemble les modules concernés en s’assurant de leur bon
fonctionnement.
-Le packaging va permettre de construire dans sa forme définitive l’unité de production, en
particulier pour les composants matériels comme lors des mises en rack des serveurs.
-Les tests d’intégration font suite aux activités de tests unitaires.
-Bâtir l’exploitabilité du service est une activité qui va permettre de spécifier, implémenter et tester
tous les outils nécessaires à l’exploitation, la supervision, le pilotage, les sauvegardes...
-Les procédures d’installation et de déploiement sont définies, écrites, documentées et testées.
-Tester le retour arrière
-La validation fonctionnelle est une activité qui va dérouler les cahiers de recette fonctionnelle
prédéfinis dans la phase de conception de services et va élaborer le procès verbal de vérification de
bon fonctionnement.
-La mise en place d’un pilote, d’une expérimentation, est optionnelle.

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 44
 -La validation fonctionnelle du pilote fait partie de l’activité de validation fonctionnelle et le résultat
sera ajouté au procès verbal de vérification de bon fonctionnement.
-La validation de la performance est une activité qui va élaborer le procès verbal concernant les
performances.
-La validation d’exploitabilité est une activité qui va élaborer le procès verbal concernant
l’exploitabilité.
-Le transfert de connaissance est à vocation des équipes d’exploitation et de support.
-L’assurance que l’exploitation est opérationnelle est un point important.
-L’assurance que les utilisateurs sont bien formés est une activité souvent très difficile à réaliser car
les utilisateurs ne sont peut-être pas identifiables directement par l’informatique.
-La planification du déploiement : cette activité va lister l’ensemble des tâches à réaliser pour le
déploiement, la chronologie des actions à réaliser, les ressources nécessaires, les chemins critiques.
Elle va procéder à l’établissement d’un plan de déploiement.
-Le déploiement va suivre la technique de déploiement retenue. On effectue les opérations de mise
en œuvre de la version, avec une trace des actions réalisées.
-La mise en service réside dans l’activation de la version pour la mettre en service.
-Le retrait des anciens éléments de configuration n’est pas souvent planifié malheureusement, car on
retrouve souvent dans les systèmes d’information des composants qui ne servent plus et qui
encombrent les salles des machines.
-La validation en service régulier est une période durant laquelle on va s’assurer que la version
fonctionne correctement, conformément aux spécifications fonctionnelles d’exploitabilité et de
performance.

-Le support en début de vie va permettre d’améliorer l’efficacité du support (gestion d’incidents et
assistance aux utilisateurs).

-La clôture de la mise en production est une activité qui couvre la participation à la revue initiée par
le processus gestion des changements, qui s’appelle le PIR (revue de post-implémentation).
Les acteurs du processus
 Le gestionnaire du processus.
 Le gestionnaire du packaging et de la construction.

CHAP23 : PROCESSUS DE GESTION DE LA CONNAISSANCE

Objectifs : D’expliquer la finalité du processus de gestion de la connaissance. De comprendre les

difficultés de mise en œuvre de ce processus.
La mission du processus de gestion de la connaissance est de fournir une information
compréhensible et fiable pour permettre la prise de décisions à tous les instants du cycle de vie.
Une autre mission du processus de gestion de la connaissance va permettre de capitaliser sur des
situations déjà connues. Pour cela, ce processus va mettre en place un système de gestion de la
connaissance (SKMS, Service Knowledge Management System), et en sera le garant.
Une donnée décrit une situation, un fait, de manière instantanée. Exemple : le cours de l’action de
l’entreprise ABC est de XX euros.
Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 45
 Une information est une ou plusieurs données qui ont été enrichies en prenant le temps de
répondre à des questions basiques comme : QUI ? QUAND ? QUOI ? OÙ ? Une information est
structurée et peut être le résultat de plusieurs données. Exemple : le cours de l’action de l’entreprise
ABC est de XX euros à la clôture du CAC 40 le 4 octobre 2010 avec un gain de 3% par rapport au cours
de la veille.
La connaissance est la corrélation d’informations concernant un sujet particulier. On va plutôt
répondre à une question de type : COMMENT ? Exemple : le cours de l’action de l’entreprise ABC est
de XX euros à la clôture du CAC 40 le 4 octobre 2010 avec un gain de 15% depuis le début de l’année
suite au rachat de l’entreprise ZZ.
La sagesse, c’est le but ultime à atteindre dans la connaissance. Arriver à identifier aussi le
POURQUOI ? Exemple : le cours de l’action de l’entreprise ABC est de XX euros à la clôture du CAC 40
le 4 octobre 2010 avec un gain de 15% depuis le début de l’année suite au rachat de l’entreprise ZZ ;
elle est devenue le leader sur un marché très porteur.

La SKMS (Service Knowledge Management System) est un système constitué de l’ensemble des bases
de connaissances de l’informatique, voire des bases de données en dehors de l’informatique comme
les bases métiers, Ressources Humaines, etc. qui vont être fédérées et/ou intégrées.

Le processus de gestion de la connaissance a pour objectif de donner de l’information à un

collaborateur quand il en a besoin, au moment où il en a besoin, sous la forme dont il a besoin, avec
le niveau souhaité, et compréhensible par celui-ci.
Tout le monde est acteur dans la gestion de la connaissance. Le transfert d’informations est l’affaire
de tous. Il faut encourager le partage de l’information pour mieux capitaliser. La rétention
d’information est une plaie dans les entreprises.
Les activités du processus de gestion de la connaissance sont :
-Définir la stratégie de gestion de la connaissance.

-S’assurer du transfert de la connaissance.

-Gérer l’information.

-S’assurer de la bonne utilisation de la base de connaissance

La gestion de la connaissance est malheureusement un sujet qui n’intéresse malheureusement que
peu de monde dans l’entreprise et particulièrement à l’informatique. On n’a pas souvent le temps,
les ressources pour s’en préoccuper. Alors on préfère dire que c’est l’affaire de tous. De tous oui,
mais en fait de personne en particulier. Et donc souvent on ne fait rien.
L’enjeu principal est donc d’arriver à motiver la Direction et les collaborateurs que l’on peut décliner
les activités de ce processus avec un minimum d’effort avec un ROI qui peut être très important.
Le second enjeu est lié à un facteur humain. La gestion de la connaissance passe par le transfert de
connaissances pour pouvoir capitaliser. Beaucoup de personnes pensent que donner de l’information
c’est perdre le pouvoir. Transférer la connaissance c’est peut-être perdre son emploi au profit
d’autres qui ont reçu cette connaissance. Garder l’information c’est se rendre indispensable. La mise
en place de ce processus va donc nécessiter un accompagnement humain, un accompagnement au
changement.

CHAP24 : L’EXPLOITATION DE SERVICES

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 46
Objectifs : De positionner la phase d’exploitation de services dans le cycle de vie. De donner la liste
des processus de cette phase. De donner une définition synthétique de chacun de ces processus.

La phase d’exploitation de services représente la phase de vie des services, c’est-à-dire ce que l’on
appelle communément la production informatique mais aussi toutes les activités support,
maintenance corrective voire évolutive. Les Anglo-Saxons appellent cette phase Service Operations.
Cette phase démarre dès la mise en service officielle d’un service, à la fin de la période d’acceptation
du service en mode régulier (VSR, Vérification du service régulier) ou la fin de la période de garantie
et se termine lors du retrait du service.
-Du point de vue du client, c’est dans cette phase que le service va produire sa valeur.
-Dans cette phase on va enfin voir si le service que l’on a défini atteint son but, on va pouvoir évaluer
son efficacité pour le client.
-Une fois l’efficacité atteinte, on envisagera dans cette phase d’améliorer la productivité de services
pour augmenter l’efficience de l’informatique.
L’équilibre
Une vision métier par rapport à une vision technologique
 Vision métier : l’objectif est de fournir le service tel qu’on l’a défini, et donc l’infrastructure
devient beaucoup plus transparente. Un exemple, la mission de l’entité supervision, pilotage,
exploite des services et non des serveurs.
 Vision technologique : l’informatique prime, les composants technologiques sont
performants et disponibles. On se focalise sur le maintien de l’infrastructure.
La stabilité par rapport à la réactivité
 Stabilité : le système d’information fonctionne normalement et est disponible. On ne change
plus rien. On réduit le nombre de mises en production au minimum.
 Réactivité : l’informatique doit réagir aux sollicitations métier pour que celui-ci soit le plus
performant (Quick to market).
Les coûts par rapport à la qualité
Réduire les coûts en gardant le niveau de qualité demandé, en évitant la sur-qualité, en essayant
d’industrialiser l’exploitation, la supervision et le pilotage.
La réactivité par rapport à la pro-activité
On n’agit qu’en réaction par rapport à des évènements ou des incidents, ou l’on décide d’anticiper en
recherchant des moyens d’optimiser le système d’information. On décide d’investir pour garantir un
bon fonctionnement. C’est l’équilibre entre maintenance corrective et maintenance préventive.
La phase d’exploitation de services va communiquer sur différents sujets comme :
 Les opérations quotidiennes.
 Les rapports sur la performance du système d’information.
 Les changements opérés.
 Les traitements d’exceptions et d’urgence.
À l’inverse, il est important que les équipes opérationnelles soient informées sur la politique
élaborée par la phase de la stratégie de services et sur la conception de nouveaux services.
La phase d’exploitation comporte cinq processus :

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 47
  la gestion des évènements ;
 la gestion des incidents ;
 la gestion des problèmes ;
 l’exécution des requêtes ;
 la gestion des accès.
Voici une définition synthétique de chacun de ces processus :
 La gestion des évènements : ce processus gère tous les faits détectables qui arrivent sur
l’infrastructure, qu’ils soient normaux ou anormaux. La gestion des évènements est là pour
éviter que des incidents se produisent en anticipant sur des situations qui pourraient
impacter les services.
 La gestion des incidents : il a pour but de restaurer le service au plus vite dans les délais
impartis lorsqu’il est arrêté ou dégradé dans sa qualité de service. Il est garant pour
minimiser les effets d’un incident sur les utilisateurs.
 La gestion des problèmes : ce processus recherche les causes et des solutions à des situations
d’incidents répétitifs ou graves.
 L’exécution des requêtes est un processus qui va traiter les demandes de services provenant
des utilisateurs. Les demandes de services sont ce que l’on appelle souvent des petits travaux
(téléchargement de logiciel sur un poste de travail, sauvegarde ou restitution de données
utilisateur, consommables, etc.).
 La gestion des accès : ce processus gère les requêtes qui sont relatives à l’accès, aux droits,
aux privilèges que l’on donne aux utilisateurs. Il va de fait gérer les identités des personnes et
des groupes.

La phase d’exploitation de services va s’appuyer sur deux bases de connaissances : l’une, le système
de gestion des configurations (CMS) qui est sous le contrôle du processus de gestion des actifs de
services et des configurations de la phase de conception de services et l’autre, la base des erreurs
connues (KEDB) qui est gérée par le processus de gestion des problèmes.

CHAP25 : PROCESSUS DE GESTION DES INCIDENTS

Objectifs : De faire le distinguo entre évènement et incident. D’expliquer la finalité du processus de

gestion des incidents.

Un évènement est un fait détectable qui arrive sur l’infrastructure du système d’information ; un
incident est un évènement qui altère ou dégrade un service rendu à un utilisateur. On dit qu’un
incident survient lorsque le service est arrêté ou lorsque la qualité du service est diminuée.
Quelques exemples d’incidents :
 l’écran de mon PC ne s’allume pas ;
 une application métier se bloque ;
 une transaction sur un serveur distant dure en moyenne 2 à 3 secondes, je n’ai pas de
réponse au bout de 10 secondes ;
 mon imprimante ne marche plus.

Tous les incidents ont pour origine un évènement, qu’ils soient détectés ou non. Par contre tous les
évènements ne vont pas amener à la création d’un incident.

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 48
On parlera d’incident si le service rendu à l’utilisateur est impacté et donc si l’utilisateur s’en aperçoit
ou s’il est susceptible de s’en apercevoir. Que veut dire susceptible de s’en apercevoir ? Prenons un
exemple : une application transactionnelle ouvre son service de 8h à 18h. En fait les utilisateurs de
cette application n’arrivent au bureau que vers 9h et généralement se connectent vers 9h15. Si à 8h
du matin il est impossible de lancer le transactionnel, et même si aucun utilisateur ne se connecte,
on détectera quand même un incident car si l’un d’entre eux s’était connecté, il l’aurait vu.
Un incident est détecté soit par un utilisateur qui va contacter le Centre de services, soit par des
outils de supervision ou de pilotage via le processus de gestion des évènements.
Un service a quatre états possibles :

 Nominal : le service fonctionne comme il a été conçu et architecturé. Exemple : une

application fonctionne en partage de charge sur une ferme de cinq serveurs ; les cinq
serveurs sont opérationnels.
 normal (ou standard) : il fonctionne en conformité avec l’accord de niveaux de services (SLA).
Exemple : une application fonctionne en partage de charge sur une ferme de cinq serveurs
où un des serveurs est en panne, mais les performances ne sont pas dégradées et les
utilisateurs ne s’en aperçoivent pas.
 dégradé : le service fonctionne avec un niveau de qualité en dessous de ce qui est mentionné
dans l’accord de niveaux de services (SLA). Exemple : trois des cinq serveurs sont en panne,
l’application est beaucoup plus lente ou limite le nombre d’accès simultanés aux utilisateurs.
Les utilisateurs s’aperçoivent de cette dégradation.
 arrêté : le service ne fonctionne pas.

Un incident survient lorsqu’un service passe de l’état nominal ou normal à l’état dégradé ou arrêté.
Pour conclure sur la définition d’un incident, il est clair que l’on peut parler d’incident uniquement
dans des situations qui sont incluses dans les plages horaires d’ouverture du service, elles-mêmes
décrites dans l’accord de niveaux de services (SLA). On ne pourra pas parler d’incident lorsqu’il s’agit
d’un arrêt programmé du service.
Codifier un incident, c’est déterminer la priorité que l’on va attribuer à cet incident. Pour cela, on
identifiera l’impact et l’urgence de cet incident.
L’impact, c’est l’effet de l’incident sur l’utilisation du service. Exemples : perte d’exploitation, nombre
d’utilisateurs bloqués ne pouvant pas travailler, non-respect de règles légales... L’impact est une
notation que l’on établit souvent sur une échelle de 1 à 3 ou de 1 à 5 (1 : Élevé, 3 ou 5 : Faible).
L’urgence, c’est le temps alloué pour rétablir le service avant que les effets de l’incident ne se fassent
sentir. Par exemple : si le serveur supportant l’application de gestion de la paie tombe en panne le 3
du mois, l’urgence liée à cet incident est moindre que si ce serveur s’arrête le 25 du mois. L’urgence
est une notation que l’on établit souvent sur une échelle de 1 à 3 ou de 1 à 5 (1 : Élevé, 3 ou 5 :
Faible).
La priorité de l’incident est la conjonction de l’impact et de la priorité, et est basée sur ces deux
notions. La priorité va donc permettre d’identifier l’importance relative des incidents les uns par
rapport aux autres. Le tableau ci-dessous nous montre un exemple de calcul de cette priorité en
fonction de l’impact et de l’urgence.

1 2 3
Impact/urgence

1 P1 P2 P2
2 P2 P2 P3
3 P3 P3 P3

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 49
À chaque niveau de priorité (P1, P2, P3), on affectera un délai de rétablissement (exemple : P1 = 2h,
P2 = 8h, P3 = 24h).
Toutes ces notions servant à la codification d’un incident (impact, urgence, matrice d’attribution des
niveaux de priorité et délais de rétablissement) devront être explicitées dans le document accord de
niveaux de services (SLA) avant la mise en exploitation du service.
Certains incidents ont un fort impact sur le métier. Ces incidents sont appelés majeurs. Ils sont hors
grille de codification, et donc d’une priorité plus élevée que P1. Ils sont traités différemment des
autres incidents, on va dérouler une procédure particulière dite de "crise", avec la mise en place
d’une cellule de crise pour les gérer. La communication à l’extérieur de l’informatique est primordiale
pour ces incidents majeurs.
La gestion des incidents a deux objectifs distincts qu’il ne faut surtout pas confondre car la finalité
n’est pas la même :
 rétablir le service dans un état normal, le plus rapidement possible conformément à l’accord
de niveaux de services associé (SLA) ;
 minimiser l’impact de l’incident sur les utilisateurs.
Rétablir le service
Rétablir le service ne veut pas dire trouver une solution, mais bien remettre en marche le service et
qu’il fonctionne à nouveau dans un état dit normal (ou standard).
L’exemple de la voiture en est un très bon exemple : une des roues de votre voiture vient de crever.
Vous changez la roue et mettez votre roue de secours, vous êtes dans la gestion d’un incident. Vous
n’avez pas réparé la roue, ni cherché la cause de cette crevaison, ni trouvé cette cause, vous avez
uniquement rétabli le service dans un état normal qui lui permette de fonctionner, de rouler. Vous
avez atteint l’objectif du processus de gestion d’incident, vous pouvez rouler.
Rétablir le service, c’est souvent relancer le serveur ou l’application sans comprendre la cause. Si le
service marche à nouveau dans l’état normal (ou standard), vous avez résolu l’incident. C’est
l’essentiel pour le client et les utilisateurs du service. Par contre, ce n’est peut-être pas satisfaisant
pour l’informatique, on verra dans le chapitre suivant Le processus de gestion des problèmes
comment on résout cette situation.
Un autre exemple de la vie de tous les jours, pour la gestion d’incidents : les pompiers, lors des
incendies de forêt en été, interviennent dans le cadre de la gestion des incidents. Leur but premier
est d’éteindre le feu et non pas de comprendre les causes du feu. Ils peuvent trouver les causes mais
ce n’est pas leur objectif, c’est celui de la police, qu’on appelle pour la gestion des problèmes.
Pour résumer, rétablir le service, c’est trouver un palliatif qui va remettre le service dans l’état
normal.
Minimiser l’impact
Le deuxième objectif de la gestion des incidents est de minimiser l’impact de l’incident sur les
utilisateurs. Reprenons l’exemple de la roue crevée de la voiture : dans ce cas, c’est mettre
une roue temporaire, la "galette", qui va permettre de rouler à faible allure sur une vingtaine
de kilomètres pour se rendre au garage. Les conséquences de la crevaison ont été
minimisées et la voiture est passée d’un état arrêté à un état dit dégradé. La gestion des
incidents va faire son maximum pour remettre une partie du service en état de
fonctionnement, avec souvent une dégradation de la qualité du service comme, par exemple,
des performances plus lentes, des fonctionnalités limitées, etc.

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 50
 Les activités
-Détection
-Enregistrement
-Classification
-Codification
-Diagnostic initial
-Tentative de résolution
-Rétablissement
-Clôture

CHAP26 : PROCESSUS DE GESTION DES PROBLEMES

La terminologie des problèmes

Le processus de gestion des problèmes est simple à mettre en oeuvre si les notions manipulées par
ce processus sont bien comprises par tous.
1. Définition d’un problème
Un problème est une situation où l’on recherche la cause inconnue d’un ou plusieurs incidents.
Tout d’abord, on ne peut pas parler de problème s’il n’y a pas eu au préalable un ou plusieurs
incidents. Pour être plus direct, pas de problème s’il n’y a pas d’incidents. Les incidents sont traités
par le processus de gestion des incidents et vont amener une restauration du service. La gestion des
problèmes va, elle, examiner les vraies causes, pour amener des solutions.
Dans notre exemple de la voiture avec sa roue crevée, on a changé la roue, remis la roue crevée dans
le coffre, et on a pu repartir avec la voiture. Mais a-t-on compris pourquoi on avait crevé ? Non. Était-
ce un clou, un caillou pointu, l’usure du pneu, etc. ? On ne sait pas. Comprendre la cause de la
crevaison, c’est déclarer une situation de problème. C’est ce que va effectuer le garagiste lorsque
vous allez lui amener votre roue crevée. Lorsqu’il aura compris la vraie cause, il vous proposera une
solution (réparer le pneu, changer le pneu, etc.). Mais est-ce que l’on va immédiatement après la
crevaison chez son garagiste pour faire réparer sa roue ? Souvent non, on verra plus tard... Il n’y a
plus le feu comme l’on dit, car l’incident est clos.
On voit dans cet exemple l’enchaînement entre incident qui traite en temps réel les situations (en
première ligne) et problème qui traite "plus tard" les causes de ces situations (en back office).
Il n’y a pas de problème s’il n’y a pas eu au préalable au minimum un incident, par contre tous les
incidents ne génèrent pas une situation de problème. Cette phrase est très importante car elle est la
base de la gestion de services. L’important c’est de rétablir le service et pas de trouver les causes des
incidents, et de trouver des solutions à ces incidents. Comprendre les causes, trouver des solutions
coûtent du temps et de l’argent. Reprenons notre exemple de la roue crevée, vous allez dépenser de
l’argent uniquement lorsque vous vous rendez chez votre garagiste, lorsque vous allez enclencher la
gestion de problèmes.
Prenons un autre exemple, informatique maintenant. Votre PC vient de se bloquer. C’est un incident.
Que faites-vous ? Vous arrêtez votre PC et vous le relancez (power off, power on) et ça marche. C’est
de la gestion d’incident au sens ITIL. Est-ce que vous investiguez sur la cause de ce blocage ? Non.

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 51
Est-ce que vous cherchez une solution ? Non. Si vous travaillez dans une grande entreprise et si cela
se produit pour un grand nombre de collaborateurs et souvent, alors vous allez ouvrir un problème
et demander à votre fournisseur de PC ou à un éditeur de travailler sur cette situation, on est dans
une situation de problème.
On voit dans ce dernier exemple quelles sont les situations qui demandent l’ouverture d’un
problème. On ouvre un problème dans le cas d’un incident récurrent. La récurrence dépend de votre
contexte : noter que la récurrence commence à deux ! Un autre cas d’ouverture d’un problème, c’est
dans un contexte d’incident majeur. On voit bien que lorsque l’on a rétabli le service sur un incident
majeur ayant un fort impact sur l’entreprise, on n’a pas envie qu’il se reproduise, donc on ouvrira
systématiquement un problème même si la récurrence est à 1.

Dans le cadre des investigations de la gestion des incidents, il arrive que l’on identifie la cause de cet
incident, surtout s’il est récurrent, ou en tout cas un certain nombre de symptômes. Dans ce cas, si
on veut aller plus loin et trouver une solution, parle-t-on de problèmes ? La réponse est oui, car vous
n’êtes pas sûr que l’analyse de la cause ou des symptômes faite par la gestion des incidents soit la
cause réelle. Je prendrai un exemple que j’ai rencontré : une grande banque décide de restructurer
tout l’intérieur de ses agences commerciales, et en particulier décide de repositionner les
équipements informatiques différemment. Un écran plat et un joli clavier sur le bureau de l’agent,
l’ordinateur sous le bureau, et l’imprimante dans un caisson. Au fil de la réinstallation de toutes les
agences, il s’avère que les imprimantes tombent très souvent en panne. Gestion des incidents : un
technicien vient dépanner, il remplace l’imprimante et trouve la cause : le bloc d’alimentation est
grillé. Parce que le nombre d’imprimantes en panne augmente de manière importante, on décide
d’ouvrir un problème. La cause est connue, alimentation grillée, mais on veut investiguer encore
plus. La gestion des problèmes permettra d’identifier que la ventilation dans le caisson de
l’imprimante est légèrement insuffisante et peut amener des conditions de surchauffe de cette
imprimante. Cet exemple simple montre que même si l’on connaît la cause, ouvrir un problème est
important.
2. Définition d’un modèle de problème
Un modèle de problème est un modèle, c’est-à-dire qu’il s’agit de bâtir une série d’étapes, de
questions hiérarchisées qui permettront de regrouper les situations suivant leur type. Il sera utilisé
par la gestion des incidents pour faciliter le diagnostic d’incidents issus de problèmes (voir dans le
chapitre précédent l’activité de classification).
3. Définition d’une Erreur Connue
Une Erreur Connue est un problème dont on connaît la cause ET pour lequel on a identifié une
solution temporaire ou définitive.
On investigue sur la cause, on trouve cette cause et on trouve une solution, soit patch, soit correctif,
et on vient de transformer le problème en erreur connue. Pour autant on ne ferme pas le problème
lorsque l’on est passé en Erreur Connue, on attendra la mise en place de la solution définitive, celle
qui éradique le problème, pour réaliser cette fermeture.
4. La base des Erreurs Connues
La base des Erreurs Connues contient l’ensemble des informations concernant les problèmes dont on
a trouvé la cause et une solution temporaire. Cette base est sous la responsabilité du gestionnaire du
processus de gestion des problèmes et est mise à disposition du centre de services et des acteurs du
processus de gestion des incidents. Cette base peut et doit être complétée avec l’ensemble des

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 52
erreurs connues identifiées par les différents fournisseurs et prestataires qui interviennent sur le
système d’information (éditeurs, constructeurs, SSII).

Les objectifs du processus de gestion des problèmes

1. Introduction
Le processus de gestion des problèmes a quatre objectifs majeurs :
 Faire diminuer le nombre d’incidents.
 Prévenir l’apparition de nouveaux incidents et problèmes.
 Minimiser l’impact des incidents.
 Optimiser l’efficacité des équipes support.

Ces objectifs sont très orientés sur l’amélioration de l’efficacité et de l’efficience du processus de
gestion des incidents.
2. Faire diminuer le nombre d’incidents
C’est l’objectif principal de ce processus. C’est à cet objectif que la Direction, les clients et les
utilisateurs seront sensibles. On recommande fortement de se focaliser sur cet objectif lorsque l’on
met en œuvre ce processus. L’indicateur de réduction du nombre des incidents est l’indicateur
d’efficacité du processus de gestion des problèmes.
3. Prévenir l’apparition de nouveaux incidents et problèmes
Cet objectif est le corollaire de l’objectif précédent, mais il va prendre en charge des actions
beaucoup plus orientées vers l’anticipation, la pro-activité (voir les activités de pro-activité). On
travaille là sur l’efficience du processus de gestion des problèmes.
4. Minimiser l’impact des incidents
La base des erreurs connues va nous permettre d’amener des informations au centre de services et à
l’ensemble des acteurs du processus de gestion des incidents pour restaurer plus rapidement les
services.
5. Optimiser l’efficacité des équipes support
Cet objectif est peut-être le plus difficile à atteindre, car il va envisager les dysfonctionnements
globaux qui peuvent intervenir sur l’ensemble des quatre fonctions ITIL, gestion des opérations,
gestion technique, gestion des applications et centre de services.
6. Conclusion
Les bonnes pratiques ITIL recommandent de mettre en œuvre le processus de gestion des problèmes
de manière très progressive. Se focaliser sur le premier objectif, réduire le nombre d’incidents est
primordial. Rappelons-nous que le processus de gestion des incidents ne résout rien, il remet en
service uniquement, c’est la gestion des problèmes qui va trouver les vraies solutions. Pour les trois
autres objectifs, on est avant tout sur l’efficience.

Les activités du processus de gestion des problèmes

Le processus de gestion des problèmes supporte deux types d’activités : des activités dites réactives,
qui réagissent à des soumissions provenant d’incidents, et des activités dites proactives, celles ne
sont pas liées aux incidents.
1. Logigramme des activités réactives
Le logigramme ci-dessous montre les principales activités réactives du processus de gestion des
problèmes, de manière très synthétique

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 53
 2. Les activités dites réactives
Sélection du Problème : activité qui va permettre de retenir la situation qui va permettre d’ouvrir un
problème. Le gestionnaire s’appuie sur le comité d’ouverture des problèmes pour prendre cette
décision. Un budget est à ce moment identifié.
Enregistrement : activité de collecte de l’ensemble des informations connues sur le problème et
création du ticket problème.
Classification, Codification : activité qui va permettre de catégoriser suivant son type le problème et
de donner sa priorité.
Investigation : activité qui recherche la cause et une solution pour ce problème.
Solution temporaire : question, est-ce que la solution trouvée est provisoire ou définitive ?
Enregistrement dans la base des Erreurs Connues : activité qui va ouvrir une Erreur Connue et
enregistrer dans la base des Erreurs Connues les informations concernant les modèles et la solution à
mettre en oeuvre si nécessaire.
Recherche d’une solution définitive : activité d’investigation pour la recherche d’une solution
définitive.
Changement nécessaire : question, est-ce que la solution définitive trouvée nécessite un changement
?
Résolution : activité qui va suivre le changement et valider la résolution.
Clôture : activité qui va fermer le problème et les erreurs connues associées. Un bilan des travaux
réalisés sera initié.
Support aux incidents majeurs : en plus des activités citées dans le logigramme, le processus de
gestion des problèmes intervient en support dans les incidents majeurs, et en particulier dans la
cellule de crise.

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 54
3. Les activités dites pro-actives
Les activités dites pro-actives de la gestion des problèmes sont les activités qui ne sont pas
directement liées aux incidents. On va rechercher des situations répétitives qui traitent d’un
dysfonctionnement ou des situations qui demandent des améliorations. Par exemple, un manque de
formation d’une population de l’entreprise, qui entraîne un afflux d’appels au centre de services, une
documentation mal rédigée, peu claire, voire inexistante, ou bien un outil mal adapté, etc.

Le rôle du gestionnaire du processus de gestion des problèmes

Voici une liste non exhaustive des activités du gestionnaire du processus de gestion des problèmes :
 Sélectionner les situations de problèmes.
 Obtenir le budget et les ressources nécessaires pour traiter ces problèmes.
 Clôturer formellement les problèmes.
 Être le point focal avec les fournisseurs et les prestataires du système d’information pour la
gestion des problèmes.
 Produire les rapports à destination de la direction, et des propriétaires de services.
 Être impliqué dans le travail des équipes supports.
 Mettre en place les outils nécessaires à la gestion des problèmes et les améliorer.
 Participer activement à la gestion des incidents majeurs.
 Développer et maintenir les procédures et les modes opératoires de son processus.
 Être garant de l’efficacité et de l’efficience de son processus.

Les points de vigilance

Les points de vigilance sont les difficultés que l’on peut rencontrer lors de l’implémentation du
processus gestion des problèmes.
1. Le distinguo entre le processus de gestion des incidents et celui de gestion des problèmes
Trop souvent dans les entreprises on confond la gestion des incidents avec la gestion des problèmes.
Il faut vraiment que tous les collaborateurs aient bien compris le distinguo. Dans les usines de
production dans le cadre industriel on a depuis longtemps bien appréhendé ces deux notions. Dans
une usine de production, la gestion des problèmes relève de l’équipe en charge du contrôle qualité.
En informatique, malheureusement on assimile la gestion des problèmes au support niveau 3,
l’expertise haute. C’est une grosse erreur. L’expertise haute fait partie des fonctions (gestion des
opérations, gestion technique, gestion des applications). La gestion des problèmes va
éventuellement demander à cette expertise haute d’intervenir, mais après que les incidents soient
clos, pour des investigations en profondeur.
2. Séparation des rôles
Il est fortement recommandé d’affecter deux personnes distinctes pour le gestionnaire des incidents
et le gestionnaire des problèmes. Les qualités humaines demandées ne sont pas les mêmes : le
gestionnaire des incidents doit réagir dans l’urgence, le gestionnaire des problèmes travaille lui avec
un certain recul sur les situations.

3. Mise en œuvre du processus

Ce processus peut être très simple à mettre en œuvre. Par contre, il nécessite deux pré-requis :
La mise en œuvre d’un processus de gestion d’incidents, cela paraît évident, mais il faut toujours être
sûr que ce processus est bien en place avant d’initialiser le processus de gestion des problèmes.

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 55
 Savoir retrouver de manière factuelle les incidents récurrents, car un problème est avant tout une
situation d’incidents récurrents.

CHAP26 : PROCESSUS D’EXECUTION DES REQUETES

La terminologie du processus d’exécution des requêtes

1. Définition d’une requête
Une requête est en fait ce que l’on appelle une demande de service provenant d’un utilisateur. Cette
demande de service concerne l’assistance, le conseil, une information, un changement standard
simple, un approvisionnement de consommable, un accès à un service, voire une plainte. En fait
derrière ce mot requête ou demande de service, on va englober tout ce qui n’est pas un incident.
Une requête va réaliser une action limitée dans le temps, à faible risque, généralement traitée par
une seule personne, et à faible coût. Cette notion prend son sens s’il y a une véritable récurrence de
la demande.
Dans beaucoup d’entreprises, on appelle cela des demandes de petits travaux.
Pour éviter d’engorger le processus de gestion des changements, les changements standards simples
vont être traités comme des requêtes. Quelques exemples : téléchargement de logiciel sur un poste
de travail, remplacement d’un écran.
2. Définition d’une demande d’accès à un service
La demande d’accès à un service est une requête qui va être prise en charge par le processus
d’exécution des requêtes et aiguillée pour traitement par un autre processus, la gestion des accès,
que l’on abordera dans le chapitre suivant.
3. Définition d’une plainte
Les plaintes des utilisateurs sont des requêtes que l’on doit prendre en compte et traiter. Un
utilisateur peut être insatisfait du service rendu par l’informatique. On doit lui proposer ce canal
officiel pour déposer une plainte, une réclamation et obtenir une réponse de l’informatique. Les
départements informatiques qui acceptent de mettre en place ces requêtes gérant les plaintes
montrent un grand degré de maturité envers leurs utilisateurs.
Il est clair que l’on parle ici de plaintes des utilisateurs et non de plaintes provenant des clients, des
métiers. Ceux-ci ont à leur disposition pour exprimer leur insatisfaction le processus gestion des
niveaux de services.

4. Définition d’un modèle de requête

Comme pour les incidents, on définit des modèles de requêtes. On bâtit une série d’étapes, de
questions, d’actions hiérarchisées qui permettront de regrouper les demandes suivant leur type et
surtout de les traiter de manière répétitive. Dans chaque modèle de requête, on va identifier le coût
de traitement de cette requête qui sera pré-acceptée, pré-validée.
Les objectifs du processus d’exécution des requêtes
Bien que ce processus soit un petit processus, on le verra par ses activités, il a néanmoins quatre
objectifs très visibles dans l’entreprise, car tous orientés vers la relation avec les utilisateurs.
 Fournir un canal privilégié aux utilisateurs pour émettre et traiter leurs demandes vers
l’informatique.
 Fournir de l’assistance auprès des utilisateurs sur l’utilisation des services.

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 56
  Effectuer les approvisionnements des composants standards des services suivant les
demandes des utilisateurs.
 Fournir un canal pour remonter les plaintes des utilisateurs.
Les activités du processus d’exécution des requêtes
1. Les activités du processus d’exécution des requêtes
On ne présentera pas ici un logigramme du processus d’exécution des requêtes car il est très simple,
avec peu d’activités :
 Enregistrement : activité qui va permettre d’ouvrir un ticket Requête, en déclarant les
informations dites administratives (date et heure, nom du demandeur, lieu et site, numéro
de contrat si nécessaire...) et l’objet de la demande.
 Traitement : activité qui va permettre d’exécuter la demande, après validation par le
responsable concerné. Des mécanismes de suivi du traitement doivent être mis en place.
 Clôture : activité en charge de fermer le ticket Requête en y ajoutant toutes les informations
utiles en particulier, les actions effectuées, les réponses apportées, le nom de l’intervenant,
etc. La clôture doit se faire avec l’accord de l’utilisateur concerné, en essayant de mesurer sa
satisfaction.

2. La mise en œuvre du processus d’exécution des requêtes

La mise en œuvre de ce processus doit être la plus automatisée possible et la plus simple possible
pour les utilisateurs. Le nombre de requêtes peut être très important et consommer beaucoup de
ressources pour l’enregistrement et le suivi de ces requêtes. On conseille fortement de mettre en
place un outil dit "self-service" ; un portail Intranet par exemple est une bonne solution
d’implémentation.
Cette approche nous amène en fait, à formaliser tous les types de requêtes, à bâtir un catalogue des
requêtes (des demandes de services), que ce processus offre aux utilisateurs. Ce catalogue va être un
complément au catalogue de services. Le catalogue de requêtes doit absolument être diffusé auprès
de tous les utilisateurs.

Les acteurs du processus d’exécution des requêtes

Ce processus va être porté par délégation par le centre de services. En effet, cette fonction est en
charge de toute la relation avec les utilisateurs.
Le centre de services va prendre en compte a minima les activités d’enregistrement, de suivi, et de
clôture. En ce qui concerne l’activité de traitement de la requête proprement dite, elle va être portée
soit par le centre de services lui-même s’il en a les compétences, soit par la fonction gestion des
opérations, soit par la fonction gestion technique.
Bien que ce processus soit porté par le centre de services, comme pour tous processus on doit
nommer un gestionnaire d’exécution des requêtes. On nommera le patron du centre de services, ou
son adjoint, comme gestionnaire.
Le gestionnaire d’exécution des requêtes est responsable de la mise en œuvre et du respect de son
processus et en assure le reporting auprès des instances concernées.
Voici une liste non exhaustive des activités du gestionnaire du processus d’exécution des requêtes :
 Être garant de la fourniture d’un catalogue des requêtes.
 Communiquer ce catalogue et en assurer la promotion.
 Produire les rapports à destination de la direction.
Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 57
  S’assurer de la satisfaction des utilisateurs.
 Mettre en place les outils nécessaires à l’exécution des requêtes et les améliorer.
 Développer et maintenir les procédures et les modes opératoires de son processus.
 Être garant de l’efficacité et de l’efficience de son processus.
Les points de vigilance du processus d’exécution des requêtes
Les points de vigilance sont les difficultés que l’on peut rencontrer lors de l’implémentation du
processus d’exécution des requêtes.
1. La relation avec le centre de services
Comme on l’a vu, le centre de services est LE porteur de ce processus. Il est le point focal pour toutes
demandes des utilisateurs. Bien souvent on met en place dans les entreprises la fonction centre de
services sans formaliser le processus d’exécution des requêtes. Ceci peut porter préjudice à
l’efficacité du centre de services lui-même, car cette formalisation va amener rigueur et surtout une
approche répétitive pour traiter toutes ces demandes.
D’autre part, le fait de formaliser le processus de gestion d’incidents, porté aussi par le centre de
services pour son premier niveau, demande aussi cette formalisation pour l’exécution des requêtes.

2. Le catalogue des requêtes

Ce catalogue est la base du bon fonctionnement de ce processus. Il suffit de regarder comment
travaille un infogérant. On n’imagine pas un infogérant prendre la responsabilité de l’exploitation et
de la production d’un système d’information sans offrir un catalogue précis et détaillé des demandes
de services qu’il peut recevoir, avec bien entendu le coût de chacune de celle-ci (coût ou unité
d’oeuvre). L’autre point important dans ce catalogue est le fait que l’on identifie clairement quel
profil d’utilisateur a le droit d’effectuer cette requête. Ceci évitera les discussions lors de
l’enregistrement et les frustrations potentielles en cas de refus.
La diffusion et la promotion de ce catalogue auprès de tous les utilisateurs sont un enjeu majeur. Si
ce n’est pas le cas, le périmètre des demandes possibles risque d’être flou et d’amener des
discussions entre le centre de services et les utilisateurs.
3. Un outil "self-service"
Les bonnes pratiques nous montrent que la mise en place de ce processus passe par la mise en
oeuvre de formulaires que l’on fera remplir directement par les utilisateurs eux-mêmes. L’outillage
consistera donc en un portail Intranet.

CHAP27 : PROCESSUS DE GESTION DES ACCES

DEVOIR à FAIRE SUR LA Gestion d'impact et d'urgence : faire des recherches, exposé et mise en pratique sur la notion MOSCOW qui
rendra des taches prioritaires
La terminologie du processus de gestion des accès
1. Définition de l’accès à un service
L’accès à un service est le niveau et le périmètre de fonctionnalités ou de données d’un service
auquel un utilisateur peut avoir droit. Exemple : les applications portées par SAP, comme la
comptabilité, la facturation, la gestion du personnel, etc., sont ouvertes, accessibles à certains des
collaborateurs de l’entreprise, que ce soit lié à la fonction, au grade, au profil du collaborateur.
L’accès à Internet (Web externe) est un autre exemple : est-ce que cet accès est disponible depuis
tous les postes de travail ?

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 58
L’accès à un service ou à des données d’un service est couvert par la notion de confidentialité, qui est
définie par le processus de gestion de la sécurité.
Concrètement, l’accès à un service va se traduire par la gestion des mots de passe et des règles
associées à ces mots de passe (initialisation, validation, revalidation de ces mots de passe).
2. Définition de l’identité
Qui dit accès à un service, dit forcement une identification fiable de l’utilisateur qui va accéder à ce
service. C’est pour cela que ce processus va être responsable de la gestion des identités des
collaborateurs. Ceci n’est pas simple et l’on va voir que cette activité est trop souvent distribuée,
dupliquée, voire répliquée dans beaucoup d’entreprises.
Comment identifier un collaborateur de l’entreprise, un utilisateur de l’informatique pour lui
attribuer ses accès au système d’information ? Par son nom et son prénom ? Non ce n’est pas
suffisant, il peut avoir des homonymes et avec les mariages, les divorces les noms peuvent changer.

Est-ce que dans votre entreprise les noms des boîtes aux lettres mail sont gérés correctement avec
cette problématique ? Oui, non, ce n’est pas sûr. Le nom, le prénom ne suffisent pas, on ajoute
souvent un numéro matricule. C’est mieux, mais la gestion se complique dans des secteurs de
marché où les entreprises fusionnent, se séparent, absorbent, filialisent... D’autre part, comment
gère-t-on les sous-traitants, les prestataires qui travaillent pendant de longues périodes dans
l’entreprise. Ces numéros matricules sont souvent gérés par le département Ressources Humaines
de l’entreprise dans leur base propre. Certaines entreprises fournissent un badge avec un numéro
(ou une puce) qui permet d’identifier celui-ci, mais qui est responsable de cette base de numéros,
Ressources Humaines ou Informatique ? D’autres entreprises identifient aussi les collaborateurs avec
un numéro de login, une adresse IP, voire un numéro accroché au poste de travail lui-même (type
numéro de série, numéro physique du poste). Et enfin on trouve un mélange de tout cela dans la
plupart des cas.
La gestion de l’identité, c’est avoir une seule entité qui en est responsable, qui est A (Accountable)
dans la matrice RACI. C’est le rôle de ce processus gestion des accès.
3. Définition de l’identité des groupes
On a défini l’identité des utilisateurs, mais souvent on élargit cette notion à celle de groupe
d’utilisateurs. Par exemple, les commerciaux, les managers, la comptabilité, etc. Il va falloir dans
l’entreprise établir une cartographie de ces groupes, en sachant bien sûr que ceux-ci ne sont pas
disjoints (commerciaux et managers par exemple).
Sous un autre angle, la notion de groupe va se décliner par groupe de services offerts à un utilisateur
ou à un groupe d’utilisateurs. Si vous avez accès à un service, vous avez aussi accès à des services de
la même famille. De même une cartographie des services mettant en avant les familles de services en
fonction des droits est à réaliser.
4. Définition des droits
Les droits sont l’ensemble des règles qui vont définir les types d’accès à un service ou un groupe de
services d’un utilisateur ou d’un groupe d’utilisateurs. Les droits sont : lecture, écriture, effacement
(d’une donnée par exemple), modification, exécution d’un programme, etc.
5. Définition des services d’annuaire
Les services d’annuaire sont en fait les outils qui vont porter cette gestion des droits et des identités.
Ils deviennent un outil vital du système d’information. Dans certaines entreprises, le service

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 59
d’annuaire est un des premiers services à remettre en route dans le PRA (Plan de Reprise d’Activité)
du système d’information.
Les objectifs du processus de gestion des accès
De même que le processus exécution des requêtes que l’on a vu dans le chapitre précédent, ce
processus gestion des accès a des objectifs très visibles dans l’entreprise, car ils sont tous orientés
vers la relation avec les utilisateurs.
Deux objectifs sont identifiés pour le processus de gestion des accès :
 Mettre en place les procédures définies par la politique de sécurité du système d’information
et par les recommandations de la gestion de la disponibilité. Gérer l’accès aux services à des
utilisateurs autorisés, c’est aussi mettre en place des règles pour empêcher l’accès des
utilisateurs non autorisés. Ces règles doivent aussi être connues et diffusées auprès de tous.
 Fournir aux utilisateurs les droits et les privilèges d’un service ou d’un groupe de services.
Les activités du processus de gestion des accès
1. Les activités du processus
On ne présentera pas un logigramme du processus de gestion des accès car il est très simple, avec
peu d’activités :
 Enregistrement : activité qui est en fait sous-traitée au processus exécution des requêtes.
 Traitement : activité qui va permettre d’exécuter la demande, après validation par le
responsable concerné. Cette validation peut être une action qui peut être simple ou
beaucoup plus complexe. Un exemple est la revalidation d’un mot de passe. Dans certains
secteurs comme la défense, le nucléaire, les banques, la revalidation d’un mot de passe est
une procédure complexe qui peut prendre plusieurs jours : la revalidation de votre code
secret de carte bancaire est un bon exemple. Cette activité sera facilitée si le processus de
gestion des accès est Accountable (au sens RACI du terme) de l’ensemble des données
d’accès (identité, services, groupe de services, droits, etc.).
Des mécanismes de suivi du traitement de la demande d’accès doivent être mis en place.
 Clôture : activité en charge de fermer le ticket Requête en y ajoutant toutes les informations
utiles, en particulier les actions effectuées, les réponses apportées, le nom de l’intervenant,
etc. La clôture doit se faire avec l’accord de l’utilisateur concerné, en essayant de mesurer sa
satisfaction.
 Gestion de l’identité : activité qui va permettre de centraliser les informations sur les
identités des utilisateurs du système d’information ; centraliser voulant dire dans une base
unique (un outil unique, comme un service d’annuaire) ou fédérer l’ensemble des bases pour
éviter la duplication ou la réplication. Un des enjeux sera de maintenir à jour et en temps réel
cette base d’identités.
2. La mise en œuvre du processus
Ce processus est souvent vu comme un sous-processus de l’exécution des requêtes. C’est une erreur,
car alors on le réduit au traitement de la demande d’accès seulement, en oubliant la gestion de
l’identité.
Ce processus est un vrai processus à part entière car il est en fait la déclinaison
opérationnelle de certaines activités du processus de gestion de la sécurité.
Les acteurs du processus de gestion des accès
Ce processus va être porté par délégation par le centre de services.

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 60
 Le centre de services va prendre en compte, a minima, les activités d’enregistrement, de suivi, et de
clôture. En ce qui concerne l’activité proprement dite de traitement de la requête et plus exactement
de l’action de validation, elle va être portée par soit le centre de services lui-même s’il en a l’autorité,
soit la fonction gestion des opérations, soit la fonction gestion technique, soit la gestion des
applications.
Bien que ce processus soit porté par le centre de services, comme pour tout processus on doit
nommer un gestionnaire du processus de gestion des accès. On nommera un collaborateur qui
travaille dans la sécurité comme gestionnaire.
Le gestionnaire du processus de gestion des accès est responsable de la mise en œuvre et du respect
de son processus et en assure le reporting auprès des instances concernées.
Voici une liste non exhaustive des activités du gestionnaire du processus de gestion des incidents :

 Être garant du respect des délais pour l’obtention d’un accès à un service.
 Communiquer, diffuser et faire la promotion des règles liées aux accès aux services.
 Produire les rapports à destination de la direction.
 S’assurer de la satisfaction des utilisateurs.
 Mettre en place les outils nécessaires à la gestion des accès et en particulier les outils de
services d’annuaires et les améliorer.
 Développer et maintenir les procédures et les modes opératoires de son processus.
 Être garant de l’efficacité et de l’efficience de son processus.
Les points de vigilance du processus de gestion des accès
Les points de vigilance sont les difficultés que l’on peut rencontrer lors de l’implémentation du
processus de gestion des accès.
1. La relation avec le centre de services
Comme on l’a vu, pour le processus d’exécution des requêtes, il y a un lien très étroit avec le centre
de services. Ce point de vigilance est le même que celui décrit dans le chapitre précédent sur
l’exécution des requêtes.
2. La politique sécuritaire du système d’information
L’efficacité de ce processus ne sera atteinte que si une politique sécuritaire du système d’information
existe et est connue, diffusée auprès de tous les utilisateurs. C’est en fait le cadre de travail de la
gestion des accès.
On ne peut donc mettre en place ce processus sans avoir un processus de gestion de la sécurité qui
soit suffisamment mature.

CHAP28 : PHASE D’AMELIORATION CONTINUE DE SERVICES

1. Les objectifs de la phase d’amélioration continue de services

Les objectifs de la phase d’amélioration continue de services mettent en valeur la qualité comme
facteur clé pour qu’un département informatique puisse atteindre et maintenir le niveau de qualité
des services contractualisés.
Tout au long de leur cycle de vie, les services eux-mêmes, les processus de l’informatique,
l’infrastructure ont besoin d’être révisés, analysés et améliorés en termes d’efficacité et d’efficience,

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 61
tant sur la façon dont les services, les processus ou les composants technologiques sont fournis que
sur leurs coûts.
Pour favoriser ces améliorations, il est nécessaire de faire des mesures et de les comparer aux
niveaux de services souhaités afin de déterminer leur performance.
Le coût est un critère important et il doit être mis en perspective avec la satisfaction des clients.
L’objectif principal de cette phase d’amélioration continue de services est d’aligner et de réaligner
continuellement les services informatiques aux besoins du métier des clients.
2. Les activités clés de la phase d’amélioration continue de services
Les activités clés traitées par la phase d’amélioration continue de services sont :
 Revoir, analyser et faire des recommandations sur les opportunités d’améliorations dans
chacune des phases du cycle de vie (stratégie, conception, transition, exploitation et aussi
amélioration).
 Revoir et analyser le résultat des contrats de services (SLA) : cette activité est très importante
car elle va tirer toutes les actions de cette phase.
 Identifier et implémenter les activités permettant l’amélioration de la qualité des services
informatiques et celle de l’efficacité et de l’efficience des processus de la gestion de services.
 Optimiser le coût de la fourniture des services informatiques sans sacrifier la satisfaction des
clients.
 S’assurer que les méthodes de management de la qualité sont utilisées pour supporter les
activités d’amélioration continue.

Les enjeux de la phase d’amélioration continue de services

L’adoption de la démarche d’amélioration continue par toute l’organisation est un des enjeux
majeurs de la mise en oeuvre de cette phase. Une participation constante et visible de la direction
aux activités de la phase d’amélioration continue est nécessaire, par exemple en identifiant une
vision sur les évolutions futures, avec des critères clairs permettant d’attribuer les priorités aux
projets d’amélioration, et surtout en la communiquant auprès de tous les collaborateurs de
l’informatique.
La nomination d’un gestionnaire de l’amélioration continue de services va matérialiser l’adoption de
cette démarche. Le gestionnaire de l’amélioration continue va être responsable (A, accountable) de
cette phase. Il va être en charge de définir le plan des actions d’améliorations avec les propriétaires
des services, les propriétaires des processus et le gestionnaire des services (le responsable du
programme ITIL), garant de le mettre en œuvre dans le cadre de la vision définie par la direction.
Bien entendu, des budgets adaptés au plan d’action d’améliorations doivent être identifiés et des
ressources allouées.
Par contre, une mauvaise analyse des métiers des clients, une connaissance insuffisante des priorités
dues aux métiers amènera de grandes difficultés pour la définition et la planification des actions
d’améliorations. D’autre part, les indicateurs de mesure des performances des services, des
processus et des composants technologiques doivent être consolidés par le gestionnaire de
l’amélioration de manière pertinente.
L’amélioration continue
1. La roue de Deming

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 62
Les bonnes pratiques ITIL vont s’appuyer sur une démarche basée sur la gestion de l’amélioration par
la qualité inventée par un statisticien appelé William Edouard Deming. Cet américain (né au début du
siècle dernier et mort en 1993) a inventé ce qu’on nomme la roue de Deming un peu avant la
Seconde Guerre mondiale, partant du constat que d’une façon générale, une approche de type "Big
bang" débouche rarement sur un programme d’amélioration réussi. C’est la raison pour laquelle le Dr
W.E. Deming a développé une approche progressive, cyclique de l’amélioration. Le schéma ci-
dessous montre la roue de l’amélioration.

Pour atteindre un but difficile à atteindre, en l’occurrence l’alignement du système d’information sur
les besoins des métiers de l’entreprise, il faudra du temps pour monter le niveau de qualité de
l’informatique : on voit donc les deux axes du schéma de la roue de Deming avec l’objectif à
atteindre. Pour avancer vers cet objectif, une seule voie possible, avancer par itération successive
telle une roue qui monte sur un plan incliné. M. Deming a développé une approche en quatre étapes
qui vont permettre d’atteindre un but atteignable qui mènera à avancer vers l’objectif final.
L’acronyme PDCA, en anglais Plan, Do, Check, Act qui veut dire Planifier, Faire, Vérifier, Ajuster (Agir),
montre que cette démarche est basée sur une approche à quatre étapes. Bien sûr, faire tourner la
roue va la faire monter sur le plan incliné vers l’objectif. Il va falloir éviter qu’elle redescende. Pour
cela une cale est indispensable. Cette cale est la surveillance, le maintient, le support nécessaire que
l’on doit mettre en place pour garantir que l’effort obtenu par la montée ne soit pas vain.
Les schémas ci-dessous montrent la rotation de la roue avec ses quatre étapes.

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 63

 Planifier (Plan) : cette étape requiert que les points suivants soient définis :
 Les buts, les objectifs et le périmètre. En d’autres termes la définition de ce qui doit être
atteint.
 Les rôles et responsabilités, les acteurs nécessaires.
 Les développements des processus, les composants techniques et les outils.
 Et les interfaces dans le cycle de vie des services.
 Faire (Do) : cette étape va bâtir un plan d’action en prenant en compte les exigences
financières et les budgets associés, les personnes, les produits, en donnant des directives,
des plannings, des procédures, des ordres d’achat d’outils, et les besoins en communication
et formations.
 Vérifier (Check), c’est surveiller, mesurer et revoir. Il faut que les objectifs et les plans soient
comparés avec ce qui était prévu. Entre autres, on va inspecter la documentation et évaluer
par audit les services, les processus et les composants technologiques.
 Ajuster (Act), agir : c’est identifier des améliorations relatives à n’importe quel aspect des
services, des processus et des composants technologiques et mettre en œuvre ces
améliorations.

Dispensé par : M. NDIHOU Henri Martial ; Certifié PMP, ITIL, Scrum Master, Six sigma Page 64