Management de La Qualité Avec ITIL

Management de la qualité
Management de la qualité avec Méthodologie ITIL
Chapitre 1 : le référentiel de bonnes pratiques ITIL

ITIL signifie Information Technology Infrastructure Library.
En français, on traduirait par Bibliothèque pour l'infrastructure des technologies de

l'information .
ITIL, c’est un ensemble de 5 ouvrages appelés aussi des publications (c’est d’ailleurs pour
ça qu’on parle de bibliothèque)
ITIL regroupe 5 publications
Ces publications contiennent des recommandations qui sont des bonnes pratiques pour
mieux gérer votre service IT. Vous y trouverez les bonnes manières de faire les choses
(comme par exemple qu’il faut généralement mettre les céréales avant le lait ).
On parle de bonnes pratiques car elles ont été testées et validées par des experts de différents
types d’organisations.
Ces livres couvrent et détaillent tous les aspects de la gestion d’un service IT.
Comprenez le référentiel de bonnes pratiques ITIL.mp4
1
ITIL aborde :
• La mise en place de la stratégie de ce service (objectifs, définition du périmètre) ;

• La conception d’un service IT (disponibilité, capacité, sécurité, coûts…) ;
• Le déploiement d’un service (mise en œuvre, test, déploiement) ;
• La gestion opérationnelle (incidents, problèmes, gestion des accès…) ;
• L’amélioration en continu du service (audit, analyse des forces et faiblesses).
C’est quoi précisément un service ?
Ici le terme Service IT ne signifie pas “département informatique d’une société”. Il désigne
plutôt un service fourni à l’aide de la technologie : un accès à Internet, un service
messagerie, de la téléphonie, un site web, une application web…
Ce référentiel de bonnes pratiques a été développé par l'Office of Government Commerce

britannique au cours des années 1980. Il comprenait à l'origine plus de 30 publications.
Il a été révisé et amélioré au fil du temps, et la dernière version (ITIL v3) a été publiée en
2007 et mise à jour en 2011.
ITIL est aujourd’hui LA référence pour de nombreuses organisations et entreprises : secteur

public ou privé, de l’entreprise du CAC 40 à la petite start-up en croissance.
Comment ça marche ?
La méthodologie éprouvée d'ITIL est liée à son approche par les processus, fonctions et
rôles (ou responsabilités).
2
Cela veut dire que :
1. Il y a au total 26 processus qui vous expliquent comment faire. Il existe aussi bien un
processus pour gérer les incidents qui arrivent au service desk (le support), qu’un
processus pour gérer les coûts ou tester et valider un service avant de le déployer ;
2. Vous y trouverez le détail des fonctions et rôles, c'est-à-dire qui fait quoi ;
3. Il suffit enfin de mettre ensemble les pièces du puzzle en s’accordant et en définissant
qui fait quoi et comment ?!
En vous organisant de cette façon, vous travaillez de manière cohérente et avec précision.
Quels sont les bénéfices d’ITIL ?
Adopter un référentiel tel qu'ITIL va vous permettre d’améliorer la gestion de votre service
IT.
ITIL se concentre sur la valeur du service fourni : les résultats et non les outils.
Plus précisément, il peut permettre plusieurs choses :
• Aligner les besoins des utilisateurs avec la technique. Si vous ne savez pas où vous
allez, vous n’y arriverez jamais ! Partant des besoins des utilisateurs, vous pourrez
répondre efficacement à leurs besoins. Il fournit des processus pour assurer un service
efficace de bout en bout, plutôt que de ne répondre qu’aux sollicitations des
utilisateurs du SI ;
3
• Améliorer la qualité du service fourni. En introduisant un ensemble cohérent de

processus, vous identifierez les problèmes et les faiblesses potentiels SI. Cela vous
permettra d’améliorer votre qualité de service. Si vous savez qui fait quoi et
comment, vous pouvez facilement mettre la main sur les faiblesses de votre
organisation et donc optimiser le comment, le qui ou le quoi ;
• Réduire les coûts. ITIL permet de s’assurer que vous pouvez délivrer un service dont
vous pouvez supporter le coût. En créant des modèles de coûts (coûts directs,
indirects), vous vous assurez de fournir un service dont le coût est quantifiable ;
• Il est facilement transposable aux pratiques existantes d’une entreprise. Une

norme est un ensemble d'exigences à mettre en place afin d’atteindre un standard.
Mais ITIL n’est pas une norme, ces recommandations ne sont pas des exigences.
Elles doivent être adaptées à votre organisation et aux pratiques existantes.
Bon à savoir ! Les bonnes pratiques d’ITIL sont à l’origine de la première norme de gestion
des services informatiques (BS15000), qui date de 2003.
En résumé
• ITIL® est une bibliothèque de 5 ouvrages recensant les bonnes pratiques dans la
gestion d’un service IT ;
• Sa méthodologie s’articule autour de processus, fonctions et rôles en déterminant qui
fait quoi et comment ;
• ITIL® permet d’améliorer la qualité d’un service IT, de réduire les coûts et
d’aligner les besoins des utilisateurs avec la technique.
C’est le référentiel ITIL dans ses grandes lignes, au chapitre suivant, on va apprendre certains
termes et concepts clés qui font partie de son vocabulaire.
4
Chapitre 2 : La terminologie ITIL
Le référentiel de bonnes pratiques ITIL propose un ensemble de connaissances pratiques et

utiles dans la gestion d’un service IT. Mais avant d’aller plus loin, il faut maîtriser certains
termes et concepts clés de ce référentiel. Ils sont aujourd’hui largement utilisés dans le monde
professionnel et ce vocabulaire est utilisé dans toutes les DSI.
Processus
Un processus est une suite d’activités coordonnées qui met en œuvre des ressources et
aptitudes afin de délivrer un résultat à un client.
Plus simplement, il s’agit d’une suite d’activités qui s’exécutent de manière à réaliser une
tâche.
Pensez à une recette qui détaille les différentes étapes à réaliser pour obtenir disons… une
ratatouille. Les différentes étapes nécessaires à la réalisation de notre ratatouille constituent un
processus.
Un process est comparable à une recette de cuisine
Un processus transforme donc un ou plusieurs éléments d’entrée en éléments de sortie en

suivant un objectif : vous combinez aubergine, courgette et autres ingrédients… pour obtenir
une ratatouille
Un processus est mesurable :
• Quantitativement
• Qualitativement.
Vous devez être capable d’évaluer le coût et la qualité des ingrédients qui entrent dans votre
recette de ratatouille. Si vous pouvez le mesurer, vous pouvez l’améliorer.
En IT c’est pareil, en maîtrisant le nombre et le type d’incidents ainsi que la satisfaction du

client à la fermeture du ticket incident, vous pourrez améliorer votre processus de gestion des
incidents.
5
Fonctions
L’autre élément clé dans ce référentiel de bonnes pratiques est la notion de fonctions. Il s’agit
des intervenants qui exécutent les activités d’un processus. C’est-à-dire :
• Les personnes ;
• Les équipes ;
• Les outils.
Dans le cas de notre ratatouille, les fonctions vont combiner gestes et automatismes pour
exécuter notre processus (notre recette).
Dans une grande organisation, ces fonctions peuvent être éclatées en départements.
Pour notre exemple, dans un grand restaurant nous aurons :
• La plonge ;
• La brigade (les commis + le chef) ;
• L’électroménager ;
• La salle (les serveurs et le maître d’hôtel).
Ramenées à une DSI, les fonctions peuvent être représentées par :
• Le management ;
• Les développeurs ;
• L'exploitation (admin système) ;
• Le support niveau 1 ;
• Le support niveau 2 ;
• Les fournisseurs externes ;
• L’outil de ticketing utilisé pour traiter les dossiers ;
• La ligne téléphonique.
Rôles
À chaque fonction, on attribue un ou plusieurs rôles.
Un rôle est un ensemble de responsabilités, d’activités et d’autorités attribuées à une personne

ou une équipe dans un contexte spécifique.
Appliqué à notre restaurant, cela reviendrait à :
• La plonge a pour rôle de préparer les ustensiles ;

• La brigade a pour rôle préparer les ingrédients ;
• L’électroménager a pour rôle de cuire les aliments ;
• Le chef contrôle la qualité des plats servis ;
• Le serveur a pour rôle de nous livrer (enfin) notre repas.
En IT, dans le processus de gestion des incidents, ce serait :
6
• Le management a pour rôle coordonner le travail des équipes ;

• Les développeurs ont pour rôle de coder les modifications qui corrigent l’incident ;
• L'exploitation a pour rôle de superviser le SI et résoudre les incidents liés à
l’infrastructure ;
• Le support niveau 1 a pour rôle d’effectuer une première analyse de l’incident ainsi
que de communiquer avec les utilisateurs ;
• Le support niveau 2 a pour rôle d’effectuer un diagnostic technique de l’incident et
de trouver sa cause ;
• Les fournisseurs externes ont pour rôle de rétablir des services externalisés (accès
Internet, data center) ;
• L'outil de ticketing a pour rôle de recueillir l’ensemble des informations relatives à
l’incident ;
• La ligne téléphonique a pour rôle de permettre les échanges audio avec les
utilisateurs ou entre les équipes.
Une fonction peut se voir attribuer plusieurs rôles. Le support de niveau 1 pourra effectuer un
diagnostic de 1er niveau et résoudre l’incident s’il en a la capacité par exemple.
Services
Autre terme important, le service.
Un service est un moyen de fournir de la valeur aux clients en facilitant les résultats que les
clients veulent atteindre sans en avoir la propriété des coûts et des risques.
Bon, d'accord. Mais c’est quoi concrètement un service ?
Les gens ne veulent pas acheter une perceuse et un foret de 3 centimètres avec une queue
cylindrique. Tout ce qu’ils veulent, c’est faire un trou de 3 centimètres dans le mur, donc trouver
le moyen de le faire. Un service va leur permettre de le faire sans qu’ils aient à supporter
le coût de la perceuse ou encore de savoir comment utiliser une perceuse (et donc éviter de
se couper un doigt !).
Dans l’IT, c’est pareil. En tant qu'administrateur système, vous offrirez de nombreux services
aux utilisateurs, tels que la messagerie, le CRM, l'accès aux documents partagés. Les
utilisateurs n’auront pas besoin de savoir que pour envoyer un mail, il faut mettre en place une
infrastructure, des solutions de messagerie, des solutions réseau, du stockage…
7
En tant que fournisseur, vous apportez de la valeur à un client via un service. Le client
utilise le service afin d’atteindre un résultat qui lui est propre. Cela, moyennant
rémunération… ou pas.
Dans la suite du cours, le terme "service" fera automatiquement référence à un service

informatique ou service IT. À ne surtout PAS confondre avec le département informatique au
sein de l’entreprise.
Pour vous aider à bien comprendre, voici quelques exemples de ce qu’est un service IT dans
ce cours :
• Le service IT fourni par un FAI est l’accès à Internet ;

• Votre hébergeur cloud vous fournit comme service IT une infrastructure cloud ;
• En tant qu’administrateur système cloud, vous fournissez comme services
informatiques un accès aux applications métier et aux mails. Vous êtes le
fournisseur, et vos clients sont les utilisateurs de ce service.
Maintenant que nous avons défini un service, passons enfin au dernier point important dans ce
guide de bonnes pratiques : le cycle de vie d’un service !
Cycle de vie d’un service
Il est temps d’aborder un concept fondamental : le cycle de vie d’un service.
Le cycle de vie d’un service est constitué des différentes phases par lesquelles passe un
service : depuis la première séance de brainstorming qui lance le projet, à son exploitation au
quotidien.
Dans ITIL, 5 phases/étapes constituent le cycle de vie d’un service, chacune étant traitée dans
une publication. Comme cité précédemment, le référentiel ITIL est constitué de 5 livres.
Il s’agit de :
1. La stratégie des services (Service Strategy) ;

2. La conception des services (Service Design) ;
3. La transition des services (Service Transition) ;
4. L’exploitation des services (Service Operation) ;
5. L’amélioration continue des services (Continual Service Improvement).
Dans le chapitre suivant, nous aborderons en détail les différentes phases du cycle de vie d’un
service.
Ces cinq phases seront centrales à tout le cours, mais nous allons nous arrêter là pour l’instant.
Maintenant que vous avez acquis le vocabulaire de base, il est temps de réunir toutes les
pièces du puzzle.
8
En résumé
• Les concepts fondamentaux dans ITIL sont : processus, fonction, rôles, service et
cycle de vie d’un service ;
• Un processus est une suite d’activités coordonnées qui décrit comment réaliser une
tâche pour atteindre un objectif ;
• Une fonction est une entité organisationnelle, un groupe de personnes qui exécutent
les activités d’un processus ;
• Un rôle est un ensemble de responsabilités allouées à une fonction ;
• Une fonction peut se voir attribuer plusieurs rôles ;
• Un fournisseur produit de la valeur pour un client via un service ;
• Un service est un moyen de fournir de la valeur aux clients, en facilitant les
résultats que les clients veulent atteindre sans en avoir la propriété des coûts et des
risques ;
• Le cycle de vie d’un service définit les différentes phases par lesquelles passe un
service : de sa naissance à son exploitation quotidienne (voire sa suppression).
Dans le chapitre suivant, vous découvrirez comment articuler les processus, fonctions et
rôles au sein du cycle de vie d’un service.
9
Chapitre 3 : Organisation du SI avec ITIL
Pourquoi mettre en place le cycle de vie d'un service ?
Imaginons que, suite à une migration de serveur, il n’y ait plus d’accès à la messagerie
d’entreprise. Cela depuis déjà 2 bonnes heures ! En tant qu’administrateur système, vous
êtes contacté par le helpdesk et vous commencez vos investigations. Très vite, vous vous
apercevez que ce problème vient en fait d’une erreur de configuration. Les questions suivantes
vont se poser :
• Pourquoi le helpdesk a mis autant de temps à remonter l’incident alors que plus
personne n’a accès aux mails ?
• L’équipe qui a effectué la migration a-t-elle testé la modification de configuration
avant la mise en production ?
• Avions-nous besoin d’effectuer cette migration de serveur ?
• N’y avait-il pas un autre moyen d’offrir les nouvelles fonctionnalités attendues lors
de cette migration ?
Ce que votre esprit critique essaie de dire, c’est qu’il ne sert a rien de chercher à maintenir un
service qui à été mal pensé et élaboré. Il faut se poser des questions en amont.
Eh bien, c’est pour répondre à toutes ces préoccupations qu’a été introduit le concept de cycle
de vie d’un service.
Le cycle de vie d’un service
Le concept de cycle de vie d’un service est un élément fondamental depuis la mise à jour V3.
Avant, ITIL était concentré sur la fourniture de service et le service support : Comment
garantir la continuité du service ? Comment devons-nous réagir face aux incidents ?
Aujourd’hui, ITIL est aligné avec la stratégie du business (vous savez, l’équipe en costard-
cravate qui commercialise le service). Il s’agit alors de fournir des processus de bout en bout
(depuis le projet du service jusqu'à son exploitation… voire jusqu’à son
décommissionnement).
• Pourquoi le client a-t-il besoin de ce service ?

• Quel type de service fournir ?
• Quelle solution mettre en œuvre ?
• Comment l’exploiter au quotidien ?
Comme nous avons vu précédemment, ITIL propose 5 publications, dont chacune traite une
phase du cycle de vie d’un service. Ces 5 phases fournissent l’orientation pour atteindre un
standard de qualité.
10
Voyons maintenant comment cela fonctionne concrètement, phase par phase, publication par
publication.
Définissez la stratégie du service—Service Strategy—SS
C’est la toute première étape du cycle de vie d’un service. C’est ici que vous élaborez la
direction stratégique du service grâce aux 5 processus qui la constituent.
Les 5 processus dans cette étape vont permettre de :
• Gérer les exigences du business ;

• Établir une stratégie de livraison du service ;
• Valider les coûts directs et indirects engendrés par le service ;
• Introduire le service dans un écosystème (le portefeuille de services).
Les questions qu’on se pose à ce niveau sont : Quels besoins le service couvrira-t-il ?
Comment fournir un service qui se différencie de l’existant ? Comment le service pourra-t-il
créer de la valeur pour les utilisateurs ?
Concevez le service—Service Design—SD
Une fois la stratégie établie, il est temps de démarrer la conception du service.
On utilise ici 8 processus pour établir les exigences de niveaux de services, de disponibilité,
capacité et de sécurité. Les activités décrites dans cette étape permettent de :
• Établir les niveaux de services ;

• Étudier la capacité nécessaire à la mise en oeuvre du service ;
• Sélectionner les fournisseurs externes ;
• Définir les exigences de disponibilité du service ;
• Valider et établir les exigences de sécurité ;
• Introduire le service dans le catalogue de services.
Les questions qu’on se pose à ce niveau sont : Combien de serveurs me faudra-t-il ? Quelles
solutions utiliser ? Devrais-je concevoir ou utiliser un fournisseur externe ? Quel niveau de
disponibilité, de capacité du serveur dois-je prévoir ?
À cette étape, vous avez réalisé ce qu’on appelle le SDP—Service Design Package, une
documentation qui servira à concevoir et mettre en oeuvre votre service dans l’environnement
de production.
Mettez en œuvre le service—Service Transition—ST
11
L’étape précédente a fourni une documentation complète sur le service à réaliser. Il faut
maintenant se retrousser les manches, car le service est prêt à être mis en oeuvre.
Maintenant que toutes les questions pratiques ont été couvertes, vous allez concevoir, tester
et déployer le service dans l’environnement de production.
Dans cette troisième étape, 7 processus vont permettre de :
• Mettre en place le plan de déploiement ;

• Évaluer, approuver, et mettre en œuvre le changement (création, modification,
mise à jour, décommissionnement) ;
• Tester le service dans un environnement de test ;
• Documenter le service ;
• Intégrer ses composants et leurs relations dans la base de données des éléments de
configuration ;
• Déployer le service dans l’environnement de production ;
• Et enfin évaluer la mise en production effectuée.
Vous passez donc des plans à la mise en production de votre service. Au terme de cette étape,
le service sera désormais accessible aux utilisateurs.
Bravo, vous venez de créer une business value. Il va donc falloir maintenir cette business
value au quotidien. Cela nous mène à la quatrième étape du cycle de vie, l’exploitation des
services.
Exploitez le service—Service Operation—SO
Ça y est. Vous avez déployé votre service, les utilisateurs l’utilisent, et là interviennent les
incidents, les problèmes et les requêtes des utilisateurs. La vie de tous les jours, quoi.
Dans cette quatrième étape, vous coordonnez les activités pour délivrer le service convenu
aux utilisateurs.
Les 5 processus qui contiennent cette phase permettent de :
• Traiter les demandes des utilisateurs de ce service ;

• Gérer l'accès au service ;
• Surveiller les évènements et les alertes du service ;
• Gérer les incidents liés qui perturbent le service, en évitant des récurrences.
C’est une étape très importante, car c’est ici que les utilisateurs perçoivent la qualité du
service.
Ça y est ? On a tout bon ? Oh, que non. À un moment, il va falloir se remettre en cause.
Déterminer les forces et faiblesses de notre service, et l’améliorer.
Améliorez continuellement votre service—Continual Service Improvement—

CSI
12
Aussi étrange que cela puisse paraître, cette étape constitue la dernière étape du cycle de vie
des services. En réalité, elle est impliquée au cours de toutes les phases. Pour beaucoup, il
s’agit du point de départ, car elle permet d’effectuer un audit du service et d’en sortir les axes
d’amélioration qui guideront l’amélioration de vos activités dans toutes les autres phases.
Cette étape contient 1 processus chargé de mesurer tous les autres processus de toutes les
autres phases, et de documenter ces résultats.
Les résultats de vos mesures vous serviront à évaluer la maturité des processus de tous les
cycles. Souvenez-vous, l’une des caractéristiques d’un processus, c’est qu'il est mesurable. Le
reporting obtenu va ensuite vous servir d’entrée pour mettre en œuvre un plan. Ce plan vous
permettra d’améliorer les autres phases du cycle de vie du service.
♼ À bien y réfléchir, il s’agit d’une boucle (d'où le terme "cycle"). On se remet en question,
on mesure l'efficacité et on définit un nouveau standard de qualité à atteindre. Puis, on établit
une stratégie, on lance la phase de conception. Voici présenté, le concept de cycle de vie d’un
service.
Cycle de vie d'un service selon ITIL
Définissez qui fait quoi — Fonctions et Rôles
Rappelons-le, une fonction est une organisation structurelle : une équipe, un groupe ou encore
un département. Un rôle est une responsabilité portée par une fonction. N’hésitez pas à relire
le chapitre 2, si vous ne vous en souvenez plus !
Comme vous avez pu le voir, toutes les publications ou phases du cycle de vie d’un service ont
des processus correspondants. Plutôt que de préconiser l’emploi de 15 ingénieurs, 30
techniciens et 10 chefs de projets, ITIL propose 4 fonctions principales qui pourront supporter
les rôles nécessaires à l’exécution des processus.
13
Il s’agit entre autres des fonctions suivantes :
• Le Service Desk ou centre de service. C’est le point focal des utilisateurs du service.
Il recueille tous les besoins des utilisateurs du service (incidents, demandes
diverses);
• L’exploitation ou la gestion des opérations. C’est ici que le service est exploité
(sauvegarde, supervision, surveillance, gestion des moyens généraux IT) ;
• La gestion technique ;
• La gestion applicative.
Les fonctions du Service Desk et la gestion des opérations fournissent les ressources
nécessaires à la phase d’exploitation des services. La gestion technique et la gestion
applicative endossent les fonctions dans toutes les phases du cycle de vie du service.
En résumé
ITIL recommande de structurer la gestion d’un service IT avec ce qu’il appelle l’approche
par le cycle de vie d’un service.
• Le cycle de vie d’un service est le cadre organisationnel, il est constitué de 5 étapes ;
• Chaque publication ITIL traite d’une étape du cycle de vie d’un service ;
• Chacun de ses 5 livres décrit en détail les processus (26 processus au total) qui
répondent à la problématique en objet de l’étape du cycle de vie ;
• Un processus est un ensemble d’activités à exécuter pour atteindre un objectif ;
• Certains processus couvrent plusieurs phases du cycle de vie des services ;
• Enfin, ITIL décrit les 4 fonctions principales qui supporteront les rôles nécessaires à
l’exécution des activités contenues dans ces processus.
Nous avons désormais une vision d'ensemble de l'utilité d'ITIL, comment il est structuré, et à
quoi il sert. Dans la prochaine partie, nous allons apprendre à garder le contrôle du SI en
établissant une procédure opérationnelle de gestion des changements.
14
Chapitre 4 : Gestion des changements avec ITIL

Après avoir présenté le référentiel de bonnes pratiques ITIL et ses 5 ouvrages ainsi que les 4
concepts clés que sont le cycle de vie d’un service, les processus, les fonctions et les rôles.
Dans cette seconde partie, on va apprendre à garder le contrôle de notre SI, en établissant une
procédure opérationnelle de gestion des changements. Vous commencerez par découvrir la
terminologie utilisée lors du déploiement d’un SI, puis définir les activités nécessaires pour
effectuer un changement. Enfin, je vous présenterai un outil opensource qui vous servira à
modéliser l’ordinogramme d’un processus de gestion des changements.
Les dangers d'un changement non contrôlé
En entreprise, il est assez courant de rencontrer des SI avec des dizaines, centaines, voire des
milliers de serveurs, applications et autres éléments de configuration (carte réseau, base
de données, switch, NAS…).
Tout changement non maîtrisé dans un SI peut donc avoir des conséquences désastreuses.
Imaginez-vous dans la situation où un collègue modifie rapidement la configuration d’un
serveur, quelques heures avant ses vacances d’été. De plus, il oublie de le mentionner à l’équipe.
Avec la chance qu’il a, ce changement va affecter la base de données hébergée sur le serveur
modifié. S’ensuit alors un inévitable incident de production.
La conséquence naturelle d’un changement non contrôlé est un incident de production générant
une rupture partielle du service, voire une indisponibilité totale du SI. Une procédure de
gestion des changements va vous permettre de garder le contrôle sur votre SI en autorisant,
priorisant, planifiant les actions nécessaires ; cela même avant d’exécuter toute action de
changement (déploiement, modification ou suppression).
Pour bien comprendre et établir les activités essentielles de votre procédure de gestion des
changements, il y a certains termes que vous devez maîtriser.
Commençons par définir le terme "procédure".
Procédure
Quelle est la différence entre procédure et processus ?
Dans la première partie du cours, nous avions défini un processus comme étant une suite
d’activités qui s’exécutent afin de réaliser une tâche. Les étapes détaillées décrivant la
manière dont les activités de processus seront exécutées vont se retrouver dans une
procédure.
15
La procédure est donc un descriptif organisationnel détaillé pour réaliser le processus.

Elle détaille les activités d’un processus et attribue aux équipes des rôles et responsabilités. La
procédure décrit simplement le Qui fait Quoi et Comment pour un processus donné.
Changement
Un changement peut être défini de plusieurs façons.
Simplement, un changement se traduit par l’ajout, la modification ou la suppression d’un

service ou d’un composant de ce service.
Non seulement un déploiement est considéré comme un changement, mais la modification et

la mise hors service sont aussi des changements.
Voici quelques exemples de changements :
• Une mise à jour applicative ;

• Le remplacement d’une carte réseau ;
• L’installation / désinstallation d’une application ou d'un service ;
• L’externalisation d’un service vers un fournisseur externe ;
• Une modification de l’infrastructure ou d'une procédure.
En entreprise, les changements surviennent pour une variété de raisons, ce qui permet de
définir 3 types de changement.
CHANGEMENT STANDARD
C’est un changement relativement commun et présentant peu de risques. Ce type de

changement est préautorisé, voire automatisé (ex. : la masterisation d’un ordinateur destiné
à un nouvel employé).
CHANGEMENT URGENT
Ici, il s’agit de résoudre des erreurs, des incidents, mais aussi de s’adapter à des
circonstances particulières. Un changement urgent doit être mis en œuvre assez rapidement.
CHANGEMENT NORMAL
Ce type de changement n’est ni standard, ni urgent. Il suit la procédure classique de

changement. Contrairement au changement standard, il suit une chaîne d’approbation et de
validation.
Tout changement doit être introduit par une une RFC.
Qu’est-ce qu’une RFC ?
16
La demande de changement—RFC
Le point de départ de tout changement, c’est la demande de changement, en anglais

Request For Change (RFC). C’est un élément très important. Il s’agit d’une demande formelle
de changement d’un service, incluant les détails du changement proposé.
À titre d’exemple, le simple fait de réclamer la réinitialisation de votre mot de passe sur un site
web génère une RFC pour une demande standard suivant un modèle. Dans le cas des
changements standard, la RFC peut être pré approuvée et traitée automatiquement.
Quand le changement est majeur, on utilise une proposition de changement.
La proposition de changement
C’est une RFC détaillée concernant un changement important avec des implications
significatives. Elle est utilisée pour les changements majeurs qui impliquent des coûts et
des risques importants.
La proposition de changement est complète. Contrairement à une RFC, elle inclut un business
case complet (enjeux, alternatives, budget…) ainsi qu’un calendrier pour la réalisation et la
mise à jour du changement.
Avant d’être exécutées, les RFCs et les propositions de changements sont soumises à
l’approbation d’un comité consultatif. Il s’agit du CAB.
Le comité consultatif de changement—CAB
CAB est l’acronyme de Change Advisory Board ; en français, le comité consultatif de

changement. C’est un groupe de personnes autorisant un changement après avoir passé en
revue la RFC.
Le CAB donne le GO ou le NO-GO à tous les changements. Il valide aussi le planning et le

calendrier de changement. Les membres du CAB peuvent donner leur accord, car ils ont une
compréhension claire de l’ensemble des implications du changement.
Par exemple, le CAB validant la RFC concernant le remplacement du CRM utilisé par le
service commercial, doit faire inclure des utilisateurs du nouveau CRM (le service
commercial) et l’équipe technique (qui fournira un avis sur le choix de la solution
informatique).
Le comité consultatif d’urgence—eCAB
Lorsque votre besoin de changement est urgent, et que vous manquez de temps, il est alors
nécessaire d’identifier un groupe plus restreint de personnes. Ces personnes auront
l’autorité pour prendre les décisions urgentes.
17
Ce comité consultatif d’urgence est appelé l’eCAB (Emergency CAB). L’eCAB vous
permettra de gérer rapidement des situations d’urgence, sans sacrifier les contrôles
habituels.
Voici un exemple : la résolution d’un incident d’astreinte (de nuit ou le weekend) peut
nécessiter un changement. Vous devrez donc obtenir l’accord du manager d’astreinte qui, lui,
peut décider par téléphone d’autoriser le changement, sans avoir à réunir toute la chaîne de
décideurs.
Le RACI
Pour être efficace, votre procédure de gestion des changements doit distribuer les rôles et
responsabilités pour chacune des activités du processus. Pas toujours évident de savoir qui
fait quoi. C’est ce à quoi répond le RACI. C’est une matrice, un tableau qui permet d’établir les
rôles et responsabilités. Les rôles sont définis par chacune des lettres :
• Réalisateur : ce sont les personnes qui exécutent l’activité de la procédure ;

• Approbateur : c’est l’autorité, la personne qui rend des comptes sur l’activité. Il ne
doit y avoir qu’une seule personne pour une activité donnée ;
• Consulté : les personnes dont les conseils et opinions sont utiles ;
• Informé : les personnes que vous devez tenir informées du déroulement des activités.
18
La matrice RACI
Elément de configuration—CI
Un élément de configuration, ou Configuration Item (CI) est un composant de votre SI,

susceptible de subir un changement. Cela inclut tout ou une partie d’un service IT, du
hardware, du software, ou encore des locaux (un data center), des personnes (le service desk)
et même la documentation.
Il est important de connaître l’ensemble des éléments de configuration de son SI et d’en tenir
un inventaire précis des attributs et relations entre CIs. Cela va vous permettre de savoir que
le serveur X est mutualisé avec telle ou telle application, et qu’une action sur ce serveur
affectera un nombre précis d’éléments.
Base de données des éléments de configuration—CMDB
La CMDB, pour Configuration Management Database, ou base de données des éléments de

configuration, contient les informations sur les CI. Vous y placerez tous les détails et attributs
des CI de votre SI : inventaire du matériel, des logiciels, applications. Elle devra contenir
aussi le détail des relations entre tous les CI qui composent votre SI.
Il existe des outils opensource qui vont permettre de mettre en œuvre votre CMDB et bien plus
encore. Exemple iTop est un outil de gestion des services informatiques offrant des modules
19
permettant de gérer les incidents, les demandes des utilisateurs, votre parc informatique
(éléments de configuration) ainsi que les relations entre CI.
En résumé
Dans ce chapitre, on a vu le vocabulaire normalisé de la gestion des changements :
• Un changement se définit par l’ajout, la modification ou la suppression d’un service

ou d’un composant de ce service ;
• Il existe 3 types de changement : changement normal, changement standard et
changement urgent. À la différence des changements normaux, les changements
standard et urgents suivent une procédure spécifique ;
• Une RFC est une demande de changement, initiant tout changement ;
• Quand le changement est majeur, on utilise une proposition de changement, qui est
une RFC incluant un business case complet ;
• Le CAB un comité consultatif autorisant un changement après avoir passé en revue la
RFC ;
• Quand le besoin de changement est urgent, et que l’on manque de temps, on fait appel
à l’eCAB ;
• Le RACI une matrice qui définit qui fait quoi. Ça permet d’établir les rôles et
responsabilités pour chacune des activités d’un processus ;
• Un CI, Configuration Item, est un élément de configuration de votre SI (software,
hardware, documentation) ;
• La CMDB, quant à elle, est le registre qui inventorie tous les CI de votre Si, ainsi que
leurs relations.
Maintenant qu’on a vu le vocabulaire, il temps de s’attaquer à l’élément déclencheur d’un

changement, la RFC ! Dans le prochain chapitre, on va apprendre à rédiger une RFC, la
qualifier, et la prioriser.
20
Chapitre 5 : Organisez les changements au sein du SI
Dans ce chapitre, nous allons voir ensemble comment préparer et organiser un changement.
Grâce à la règle des 7R, vous apprendrez à définir le périmètre de votre changement et ainsi
faire apparaître les risques potentiels. Ensuite, vous apprendrez à catégoriser une RFC pour
déterminer la priorité d’un changement. Pour finir, nous aborderons les plans de retour arrière
qui constitueront votre assurance de retrouver la situation initiale en cas de problème.
Les demandes de changements sont diverses
Le point de départ de tout changement est la RFC. Pour des raisons diverses, tout le monde
peut demander un changement. Il peut s’agir d’une demande concernant :
• L’installation d’un serveur d’impression pour gérer plus rapidement les impressions
;
• Une mise à jour de sécurité pour pallier une faille dans l’OS ;
• Une migration vers une infrastructure cloud qui pourrait permettre de faire des
économies à long terme ;
• L'ajout de CPU/mémoire pour résoudre un incident de production dans lequel le site
web de l’entreprise est inaccessible ;
• Un widget connecté qui affiche la météo et les dernières informations de la bourse sur
le bureau des ordinateurs.
Lesquelles doit-on traiter en premier ? Les retours attendus par l’exécution de ces
changements nécessitent-ils un changement ?
Déjà, à bien y regarder, on s’aperçoit que toutes les demandes ne se valent pas. Certaines
sont urgentes, d’autres un peu moins, mais présentent un risque réel si elles ne sont pas
effectuées dans un certain délai.
La règle des 7R va aider à y voir un peu plus clair.
La règle des 7R
Comme vous l’avez appris, la RFC est le point de départ de tout changement. L’impact
potentiel des changements, les éléments de configuration (et leurs relations) doivent être
abordés. Cette évaluation est réalisée dans l’étape d’analyse de la RFC.
La règle des 7R vous aidera à vous poser les questions essentielles lors de l’analyse d’une RFC.
Vous pourrez ainsi établir le périmètre de ce changement :
• Requis : qui a requis ce changement ?

• Raison : quelle est la raison de ce changement ?
• Retour : quel est le retour attendu de ce changement ? Quels sont les bénéfices
attendus ?
• Risque : quels sont les risques encourus à la réalisation ou la non-réalisation de ce
changement ?
21
• Ressources : quelles sont les ressources nécessaires pour réaliser ce changement ? De

quoi aurons-nous besoin ?
• Responsable : qui est responsable de la réalisation de ce changement ?
• Relation : quelle relation avec d’autres changements ? Existe-t-il des dépendances ?
Une fois le périmètre du changement établi, il est temps de catégoriser la demande de

changement et ainsi faire apparaître les demandes devant être traitées en priorité.
Catégorisez vos changements
Catégoriser un changement consiste à lui affecter une priorité. Dit autrement, il s’agit de
lui affecter une importance relative. Pour cela, vous pouvez vous appuyer sur l’évaluation du
risque que présente ce changement (souvenez-vous, R comme Risque…), ainsi que la
probabilité que ce risque se réalise.
Une autre méthode consiste à déterminer la priorité d’un changement grâce à une matrice
prenant en compte l’impact et l’urgence de ce changement :
• L’impact représente l’ampleur du périmètre et/ou le nombre d’utilisateurs concernés

par ce changement. Il doit être inscrit dans la RFC ;
• L’urgence va mesurer le niveau de criticité sur l’activité, l’urgence à mettre en place
le changement.
En évaluant l’impact et l’urgence sur 3 niveaux (fort, moyen, faible), vous pourrez ensuite
déterminer la priorité du changement, c'est-à-dire un couple urgence–impact.
Les 5 niveaux de priorité des changements
Vous obtenez 5 niveaux de priorité que vous pourrez affecter aux changements.
22
Pour rendre le tout plus pratique, on décrit dans le tableau ci-dessous les priorités en fonction
du type de changement (corriger un incident ou déployer/améliorer un nouveau service) :
Priorité Changement correctif Changement d'amélioration
P1 – Critique : À Risque vital causant une perte Ne doit pas être utilisé pour ce
traiter comme un significative de la qualité de type de changement.
changement service. Action immédiate
urgent. requise.
P2 – Majeur : La Service dégradé avec impact Déployer un patch de sécurité,
priorité la plus sur un grand nombre répondre à une obligation légale,
haute pour les d’utilisateurs. déploiement d’un nouveau service
actions de avec une forte valeur ajoutée pour
déploiement. le business, non-respect d’un délai
contractuel.
P3 – Moyen Impact peu sévère de Changement apportant une
l’incident sur les utilisateurs. amélioration dans l’utilisation du
Cas où la correction doit service, planifiée avec un délai
attendre le déploiement d’une contractuel.
nouvelle version, ou d’une
mise à jour.
P4 – Normal Changement correctif justifié Changement apportant une
mais pas nécessaire, car il amélioration dans l’utilisation du
existe une solution de service, planifiée avec un délai de
contournement. Peut attendre contractuel moins important que le
la prochaine mise à jour. P3, voire sans délai contractuel.
P5 – Planifié Ne doit pas être utilisé pour les Tout autre cas non abordé pour les
changements correctifs. changements d’amélioration.
Voici quelques exemples de changements associés à leur niveau de priorité :
• L’ajout de CPU ou de mémoire pour résoudre un incident de production dans lequel

le site web de l’entreprise est inaccessible : urgence Forte (on perd de l’argent si en
plus il s’agit d’une boutique en ligne) + impact Fort (tous les clients n’y ont plus accès)
= P1–Critique. Changement à réaliser immédiatement.
•
• Une migration vers une infrastructure cloud qui pourrait permettre de faire des
économies : urgence Moyenne (l’infrastructure actuelle est fonctionnelle) + impact
Fort (on réalise des économies substantielles) = P2–Majeur. Déploiement d’un service
à forte valeur ajoutée pour le business.
•
• Un widget connecté qui affiche la météo et les dernières informations de la bourse le
bureau des ordinateurs : urgence Faible (franchement on peut encore utiliser le
navigateur pour avoir la météo) + impact Faible = P5–Planifié. Ce changement est
planifié pour être exécuté mais avec la plus faible priorité.
23
Planifiez vos changements
De manière générale, vous devrez éviter que vos changements s’interfacent avec d’autres
processus de changement (prestataires et fournisseurs externes). Autant que possible, établissez
votre planning de changement en fonction des besoins du business, plutôt qu’en fonction
des besoins informatiques.
Évitez d'effectuer vos opérations aux heures de forte utilisation du service. Imaginez les pertes
financières engendrées par un changement sur un site web marchand qui serait en maintenance
en période des soldes. N’attendez pas la fin du mois pour effectuer un changement sur le CRM
utilisé par l’équipe de la paie (à vos risques et périls). De plus, croyez-en mon expérience, évitez
d’effectuer un changement le vendredi, car en cas de pépin, l’incident pourrait durer tout le
weekend ! D’ailleurs cette règle est suivie dans de nombreuses entreprises.
Établissez un calendrier des changements autorisés. Prévoyez toujours une durée approximative
de la maintenance.
Établissez un plan de remédiation
Aucun changement ne devrait être mis en œuvre sans au préalable fournir un plan de
remédiation. On parle aussi de Backout Plan.
Il s’agit de prévoir un plan de retour dans le cas où le déploiement se passe mal (oui, ça peut
arriver !). Idéalement, établissez une solution qui vous permettra de redonner au service sa
situation initiale. Restaurez vos sauvegardes du système pour le software, prévoyez du matériel
de secours dans le cas du hardware.
Si pour une raison ou une autre vous ne pouvez pas effectuer un retour arrière, déclenchez le
plan de continuité d’activité. Mais ça, c’est une tout autre histoire.
Un snapshot est une sauvegarde complète du système qui peut être restaurée dans le cadre d’un
retour arrière.
En résumé
Organiser les changements consiste à :
• Définir les activités à mettre en œuvre dans votre processus de changement ;

• Prévoir un processus pour chaque type de changement : Normal, Standard, Urgent ;
• Commencer par le changement normal, et simplifier le processus pour obtenir un
changement standard, ou changement urgent, sans pour autant supprimer les contrôles
et l’analyse des risques liés à ce changement ;
• Utiliser la règle des 7R afin d’établir le périmètre du changement : Requis, Raison,
Retour, Risques, Ressources, Relation, Responsable ;
24
• En fonction de l’impact et de l’urgence, catégoriser vos changements en leurs

affectant des priorités ;
• Planifier vos changements, ce qui vous permettra de limiter l’impact sur le service
d’un arrêt pour maintenance ;
• Enfin, toujours prévoir un plan de retour arrière dans l’éventualité d’un mauvais
déroulement.
Dans le chapitre suivant, on va lister les activités, rôles et responsabilités de notre processus
de gestion des changements.
25
Chapitre 6 : Activités d'un processus de gestion des changements
Procédure de gestion des changements
Établir une procédure opérationnelle de gestion des changements va vous permettre de :
• Réaliser des changements (évolutions/modifications) en limitant les risques de

dégradation de services ;
• Maîtriser les impacts et limiter les interruptions de services ;
• Améliorer la qualité de service.
Comme évoqué dans le chapitre 1, la procédure décrit simplement le Qui fait Quoi et
Comment pour un processus donné.
De ce fait, votre procédure opérationnelle de gestion des changements devra comporter,

pour chaque type de changement (urgent, normal, standard) :
• Un processus de gestion des changements ;

• Un RACI pour chaque type de changement.
Les activités d’un changement Normal
Commençons par définir ensemble les activités nécessaires dans un processus de changement.
À la manière d’une recette de cuisine, votre processus doit préciser les différentes étapes à
réaliser lors d’un changement dans votre SI.
De façon générale, pour un changement normal, vous devrez effectuer les actions suivantes :
1. Créer et enregistrer la RFC
Tout commence avec la création d’une demande de changement, une RFC. C’est comme à la
mairie. On remplit un formulaire, puis ce formulaire est enregistré, et un numéro de suivi lui
est attribué. Utiliser un formulaire vous facilitera la tâche. Vous pourrez y faire apparaître les
informations dont vous aurez besoin pour effectuer ce changement.
2. Passer en revue la RFC
Bien entendu, comme à la mairie, les formulaires incomplets seront rejetés ou retournés aux
demandeurs ! Profitez-en pour réclamer un complément d’information, supprimer les demandes
en doublon ou fausses.
26
3. Analyser et évaluer le changement
Cette étape vous permettra de déterminer les parties prenantes qui devraient être impliquées
dans le CAB (le comité consultatif). Le CAB pourra ensuite évaluer la justification business,
l’impact, le coût, les avantages et les risques de ce changement.
4. Autoriser le changement
Une fois le périmètre de ce changement évalué (priorité, risque, justification), il revient au CAB
d’autoriser ou de refuser le changement. Dans le cas d’un refus, la RFC sera retournée au
demandeur.
5. Implémenter le changement
La phase pratique peut démarrer. Ici, vous devrez planifier, concevoir, tester puis déployer
le service. Le service conçu et testé, il revient au CAB d’approuver le déploiement.
6. Revoir et clôturer le changement
Une fois le déploiement effectué, c’est le moment d’effectuer un bilan. Ce bilan vous
permettra de faire ressortir les axes d’amélioration de votre processus. Ça y est, vous
pouvez archiver le dossier.
27
Processus des activités d'un changement Normal
28
Dans le chapitre suivant, on va réaliser un ordinogramme de ce processus. Un

ordinogramme est une représentation graphique de l'enchaînement des activités d’un
processus.
La troisième partie du cours aborde en détail la phase d’implémentation du changement :

Conception, Test et Déploiement.
Les activités d’un changement Standard
Les changements standard sont préautorisés, car ils présentent peu de risques. Il vous revient
d’adapter votre processus de changement normal pour le simplifier, sans pour autant sacrifier
les contrôles nécessaires à la validation de ce changement. Les activités d’un processus de
changement standard peuvent être comme suit :
1. Création et enregistrement de la RFC ;

2. Validation du changement ;
3. Implémentation du changement ;
4. Revue et clôture.
Prenons par exemple une demande d’installation d’un nouveau matériel, une imprimante
reliée à un serveur d’impression, dans un service. La mise en œuvre de ce changement
standard va se dérouler comme suit :
1. Création et enregistrement de la demande via un formulaire ;

2. Validation de la demande par le manager de service et le service financier (qui
constituent le CAB) ;
3. Achat, test de la configuration et déploiement de l’imprimante ;
4. Revue du formulaire (avec ajout des détails de l’opération, production de la
documentation), puis clôture du dossier.
Les activités d’un changement Urgent
Un changement urgent requiert des actions immédiates. Il est très souvent mis en œuvre pour
répondre à une rupture de service ou des changements correctifs. L’urgence de la situation
ne doit pas sacrifier les étapes de contrôle et de validation nécessaires. De façon générale, vous
devez exécuter les mêmes activités que celles d’un changement normal, sauf que cette fois,
vous mettez tout en œuvre pour qu'il soit effectué le plus rapidement possible.
Cela implique de mettre en place un eCAB (un comité consultatif d’urgence), constitué de
membres disponibles et mobilisables sans délai, et ayant une connaissance du périmètre
abordé.
29
Résoudre un incident en plein milieu de la nuit peut demander un changement urgent. Il vaut
mieux avoir une chaîne de décision courte pour ce genre de situation, plutôt que d’avoir à réunir
une dizaine de personnes en moins d’une heure.
Le processus de changement urgent ne doit pas être utilisé juste pour traiter rapidement un
changement. Les changements urgents comportent des risques, que l’on accepte de prendre,
lors d’une situation avec un impact critique.
Déterminez les rôles des intervenants
Comme évoqué dans le chapitre 1, la matrice du RACI est utilisée pour définir les rôles des
acteurs dans un processus ou une activité.
Intégrer une matrice RACI dans votre procédure opérationnelle va vous permettre de décrire
ce que font les intervenants. Cela va faciliter la coordination des équipes.
Pour chaque activité du processus, commencez par répondre aux questions ci-dessous pour
déterminer les rôles des intervenants :
• R–Qui réalise de cette tâche ?

• A–Qui est le décideur ? Qui peut trancher en cas de problème ? Qui valide les
résultats ?
• C–Qui détient une expertise dans le domaine ? Qui peut apporter son aide par de
précieux conseils pour faire avancer la tâche ?
• I–Qui est impacté par l'activité ? Qui doit être nécessairement informé ?
Ensuite, établissez un tableau attribuant une responsabilité à chaque intervenant.
Fonction 1 Fonction 2 Fonction 3

Activité 1 R A C
Activité 2 R, A R I
Activité 3 C I A
Toujours un seul A par ligne. Il ne peut y avoir qu’un seul décideur par activité (un seul
chef). Un intervenant peut avoir plusieurs rôles sur une même activité.
Plutôt que de nommer les intervenants dans le tableau, (Anne, Jean-Marc, et Thibault, Lucie),
utilisez leur fonction.
Si Anne et Jean-Marc sont tous les deux Sysadmin, ils n'auront qu’une seule et même
fonction, celle dans l’organigramme de la société. Équipe Run par exemple.
30
En résumé
• Une procédure opérationnelle de gestion des changements détaille les activités de

votre processus de changement ;
• Elle va contenir les processus et le RACI de chaque type de changement : normaux,
standard et urgents ;
• Les activités essentielles d’un processus de changement doivent être détaillées dans la
procédure opérationnelle ;
• Vous devez établir une matrice RACI qui va attribuer des rôles aux fonctions.
Par la suite on va réaliser un ordinogramme d’un processus de gestion des changements.

Pour cela, on utilisera XMind, un outils opensource pour représenter de façon graphique
l'enchaînement des activités, des décisions ainsi que les rôles et responsabilités.
31
Chapitre 7 : Ordinogramme d'un processus avec XMind
Dans ce chapitre on va réaliser l’ordinogramme de nos processus de gestion des changements,

afin de représenter graphiquement l'enchaînement des activités d’un processus de gestion
de changement.
Qu'est-ce qu'un ordinogramme ?

C’est une représentation graphique permettant une meilleure compréhension d’une procédure
et c’est un prérequis indispensable à son exécution.
Maintenant que nous avons listé les activités de notre processus, il est temps de détailler, étape
par étape et de manière logique, les actions à mener et les décisions à prendre pour effectuer
notre changement. L'ordinogramme va nous permettre de visualiser clairement et simplement
ces activités, actions et décisions à prendre.
Mais avant, il faut aborder certains principes de base dans la réalisation d’un ordinogramme.
Principes de réalisation d’un ordinogramme

Avant de vous lancer dans la réalisation d’un ordinogramme, il est nécessaire d’établir
certaines règles :
• L’ellipse pour représenter un événement qui intervient en entrée ou en sortie de
processus ;
• Le rectangle pour représenter une activité intervenant en cours de processus ;
• Le losange pour représenter une décision dans le processus ;
• Le cercle pour représenter une activité ou un point qui fait appel à un autre processus.
32
Les éléments d'un ordinogramme
Il existe de nombreux outils pour réaliser un ordinogramme, le plus célèbre étant Microsoft
VISIO. Toutefois, vous pouvez utiliser des outils gratuits tels que Présentations de Google, ou
Keynote de Apple pour réaliser vos ordinogrammes. Vous pouvez également utiliser des outils
accessibles directement sur votre navigateur, comme le très puissant Draw.io.
Réalisez un ordinogramme avec XMind
XMind vous permet de créer des ordinogrammes

XMind est un outil populaire opensource de mind mapping (carte mentale) et de Brain Storming
(recherche d'idées/réflexions). Sa version de base est gratuite, en français, et présente l’avantage
d’être très intuitive.
Vous pouvez télécharger la version 8 ici.
33
Chapitre 8 : Mise en production grâce aux packages
Dans les chapitres précédents, nous avons appris à mettre en place une procédure
opérationnelle de gestion des changements dans notre SI. Cette procédure nous apprendra à
contrôler et à sécuriser tous les changements dans notre système d’information, en approuvant
et en pilotant les demandes de changement. Nous avons aussi appris à coordonner les actions
des équipes grâce à l’établissement d’une matrice des rôles et des responsabilités (le RACI).
Dans cette partie, on va aborder de façon pratique les activités de conception, test et
déploiement d’un processus de gestion des changements. Nous aborderons la planification
des mises en production—MEP, l’organisation et la réalisation des livrables, la phase de test
du package à déployer, et le déploiement.
Commençons tout de suite par préparer notre MEP (mise en production).
L’étude de cas
Soit OPC, une boutique en ligne dont le succès de ses trottinettes électriques n’est plus à
démontrer. La DSI a décidé de mettre en place une solution de supervision qui permettrait le
contrôle en temps réel de l’état de santé du SI et de ses composants. Cette supervision
permettrait la détection des situations à risque et ainsi éviter les incidents et les pertes liées à
l’indisponibilité de la boutique en ligne.
La solution de supervision requiert le déploiement de :
• Un serveur de supervision traitant les alertes et évènements remontés par les agents
de supervision ;
• Des agents de supervision installés sur chaque serveur de production afin de
surveiller les services applicatifs, les éléments réseau, et l’état des disques ;
• Une montée en version de l’OS sur les serveurs devant recevoir les agents afin qu’ils
puissent être opérationnels ;
• La mise en place de scénarios de supervision applicative.
Ces changements ont tous été approuvés via le processus de gestion des changements, et un
planning de déploiement a été établi. Vous abordez maintenant les activités de conception, test
et déploiement.
Livrables, Packages et Mises en Production (MEP)
Un déploiement induit un changement dans votre SI, et donc présente des risques. Raison
pour laquelle il doit être préalablement approuvé et validé dans le processus de gestion des
changements.
Mettre en production la solution de supervision va consister à effectuer dans votre SI un
ensemble de changements. Ces changements sont regroupés en packages ou release en anglais
(voir tableau ci-dessous).
34
Le terme de Mise en Production (MEP) est très souvent utilisé pour décrire les changements
applicatifs. Notez qu’une MEP s’utilise aussi bien pour du hardware que pour du software. La
MEP est constituée d’un ensemble de changements déployés simultanément.
Pour réaliser un package, vous devez regrouper les changements par unité de mise en
production.
Une unité de mise en production est un ensemble d'éléments du SI subissant généralement un
ensemble des changements. L’unité peut varier en fonction du type d'éléments de configuration
devant subir les changements.
Le regroupement des changements par unité de mise en production permet de :
• Faciliter le nombre de changements nécessaires pour mettre en œuvre une MEP ;
• Optimiser les ressources humaines et le temps nécessaires pour concevoir, tester et
déployer les changements.
Package Changement Description
Release 1 RFC001 Installation du serveur de supervision (Hardware)

Release 1 RFC002 Installation du serveur de supervision (software)
Release 1 RFC003 Installation de l’application de supervision (Serveur)
Release 2 RFC004 Montée en version de l’OS sur serveur de prod 1 (secondaire)
Release 2 RFC005 Installation de l’agent de supervision sur serveur de prod 1
(secondaire)
Release 3 RFC006 Montée en version de l’OS sur serveur de prod 2 (principal)
Release 3 RFC007 Installation de l’agent de supervision sur serveur de prod 2

(principal)
Release 4 RFC008 Configuration des scénarios de supervision
Dans notre exemple, les unités de mise en production sont les suivantes:
• Le serveur de supervision ;
• Le serveur de production 1 ;
• Le serveur de production 2.
Pour déployer notre solution, les changements vont être organisés en releases, en regroupant
les RFC en fonction des unités de configuration précédemment établies, mais aussi en fonction
des prérequis : il faut installer le hardware avant le software, par exemple.
35
Conception du package de mise en production

Le package de mise en production est le résultat de la phase de conception.
Il va permettre de passer d’une situation actuelle à une situation désirée. Il contient tout ce qu’il
faut pour effectuer les changements dans le SI.
Dans notre exemple, il est composé du matériel à installer pour le serveur de supervision, du
software à installer ou à concevoir, de la documentation ainsi que de la formation.
La phase de conception de la Release1 va consister à :
• Acquérir le matériel (hardware) qui hébergera le serveur de supervision ;
• Acquérir la distribution de l’OS à installer sur le serveur ;
• Acquérir ou développer la solution de supervision côté serveur.
Une fois la phase de conception achevée, il est temps de tester le package conçu afin de s’assurer
qu’il répond au besoin du changement, mais aussi et surtout qu’il s’intègre parfaitement dans
le SI.
En résumé
• Un Package (Release) est un groupe de changements à effectuer via une mise en
production ;
• La mise en production (MEP) est un ensemble de changements autorisés apportés à
un service et déployés ensemble ;
• Les éléments de configuration habituellement mis en production ensemble constituent
une unité de mise en production ;
• Le découpage par unité de mise en production permet d’optimiser les ressources et le
temps nécessaires pour construire, tester, distribuer et implémenter une MEP ;
• Un package de mise en production contient tout ce qui est nécessaire pour passer de
la situation actuelle à la situation désirée (changement). Il s’agit des logiciels, du
matériel, de la documentation, et souvent de la formation. C’est le produit de la
conception.
36
Chapitre 9 : Test et validation des packages
Dans le chapitre précédent, nous avons vu comment la DSI de OPC prépare la mise en
production de la supervision de l’infrastructure de sa boutique en ligne. Les différents
changements ont été regroupés en packages ou releases, sur la base des unités de mise en
production. La phase de conception est achevée une fois que le package de mise en production
est livré (hardware, software, documentation).
Dans ce chapitre, nous allons aborder la phase de test et de validation du package de mise
en production.
Objectifs
Les tests et validations assurent que le package correspond à ses caractéristiques de
conception, et qu’il répondra aux besoins du business. Il permet aussi de s’assurer que les
éléments, une fois déployés et/ou modifiés, s'intégreront parfaitement dans le SI.
Une fois réalisés, les packages de mise en production sont déployés dans un environnement de
test.
Un environnement de test est un environnement contenant du matériel, des instruments, des
simulateurs, des outils logiciels et d'autres éléments de support nécessaires à l'exécution d'un
test. En clair, c'est ce qui permet de tester le service sans avoir à impacter la production.
Cet environnement doit être maîtrisé, protégé et maintenu pour éviter les écarts avec
l’environnement de production.
Les tests de validation vont permettre de valider les points suivants :
• La déployabilité du package ;
• L’utilisation de l’interface par les utilisateurs ;
• La documentation fournie ;
• Le plan de retour arrière.
Validez le passage en environnement de production

La phase de test est aussi une occasion pour la direction de valider l’efficacité de la solution
de supervision, en mesurant les retours obtenus. Il convient également de s’assurer que le
service desk peut répondre aux incidents liés aux packages déployés, en validant la
documentation fournie.
Dans notre exemple, une fois la solution de supervision déployée dans l’environnement de test,
il faudra simuler des évènements (surcharge réseau, coupure, saturation) afin de s’assurer que
les alertes remonteront et que les évènements importants sont remontés dans la console de
supervision. Cela permettra de valider le fonctionnement de notre supervision.
Le plan de retour arrière doit aussi être testé et validé.
37
Nous en profiterons pour effectuer des tests utilisateurs : l’équipe d’exploitation de

l'infrastructure qui sera la première utilisatrice de l’outil de supervision pourra confirmer le bon
fonctionnement de l’interface utilisateur, ainsi que les interfaces avec d’autres applications
(dans le cas d’utilisation d’une API).
Déployez une version pilote

Une version pilote est une version testée en conditions réelles par un petit groupe d’utilisateurs.
Il s’agit de déterminer les écarts entre l’environnement de test (aussi appelé la "recette") et
l’environnement de production.
Dans le cas de OPC, vous pouvez constater que la release 2 déploie la supervision sur serveur
de production secondaire afin d’effectuer des tests en situations réelles, sans pour autant
perturber la production.
Le déploiement d’une version pilote ne peut intervenir qu'après la validation en phase de
test. Durant la phase pilote, les équipes de déploiement doivent :
• Prévoir un plan de retour arrière s’il existe des écarts non acceptables ;
• S’assurer que les utilisateurs en phase pilote soient formés ;
• S’assurer que la documentation initiale soit disponible au service desk ;
• Diagnostiquer et résoudre les incidents qui pourraient survenir ;
• Documenter les améliorations à apporter au projet.
Une fois les tests validés, le déploiement en production des changements peut sereinement avoir
lieu.
En résumé
• Les tests et la validation de service assurent que le service correspond à ses
caractéristiques de conception et qu’il répondra aux besoins du business ;
• Il est impératif de déployer le package de mise en production dans un environnement
de test ;
• L’environnement de test doit être maîtrisé, protégé et maintenu pour éviter les écarts
avec l’environnement de production ;
• Une version pilote est une version testée en conditions réelles par un petit groupe
d’utilisateurs. C’est une version dite de préproduction qui permet de déployer en
production le package, sans perturber la production.
38
Chapitre 10 : Méthode de déploiement adaptée
Dans notre étude de cas, nous avons commencé par planifier les MEP en organisant les
changements nécessaires en package ou release. Ensuite, nous avons abordé la mise en place
d’un environnement de test afin de valider le service à déployer.
Dans ce chapitre, nous allons passer en revue les différentes méthodes de déploiement de vos
packages.
Comprendre les grandes étapes des phases de conception, test et déploiement
Lors des phases de conception, test et déploiement, vous devez :
• Mettre en place une identification unique : une numérotation et une convention de
nommage (ex: V1.3.4) ;
• Vérifier la fréquence prévue pour chaque MEP ;
• Vérifier l’approche d’acceptation et de regroupement des modifications dans une
MEP (création des packages) ;
• Gérer les rôles et responsabilités à chaque étape de conception, test et déploiement ;
• Assurer des critères d’acceptation en fin de déploiement qui permettent la sortie de
la phase de transition vers la phase d’exploitation du service.
En fonction du type de service à déployer et de ses potentiels impacts, vous devrez choisir une
méthode de déploiement adaptée à la situation. Voyons cela en détail.
Les différentes approches de mise en œuvre du déploiement
Approche phasée
Dans une approche phasée, le service est déployé pour une partie des utilisateurs au départ,
puis cette opération est répétée pour les parties suivantes de la base des utilisateurs, avec un
planning de déploiement. Ce type de déploiement permet d’effectuer un retour arrière et de
minimiser les coûts d’un déploiement raté à grande échelle.
Approche Big Bang
Dans une approche Big Bang, le service est déployé pour l’ensemble des utilisateurs en une
seule fois. Cette option est utilisée pour les changements sur les applications, et lorsque la
cohérence du service sur l’ensemble des utilisateurs est primordiale.
Approche push
L'approche de type push est utilisée lorsque le composant de service est déployé depuis
l’espace de distribution et poussé vers les utilisateurs cibles par l’administrateur du service.
Lors du déploiement, fournir les composants du service à tous les utilisateurs, soit par une
approche Big Bang, soit par une approche phasée, constitue un push dans la mesure où le
pakage est livré dans l’environnement de production à un moment imposé.
39
Approche pull
L'approche de type pull est utilisée pour les productions de logiciels, lorsque le logiciel est
mis à disposition en centrale de distribution (du type App store). Un bon exemple est celui
des signatures de virus, qui sont téléchargés pour mettre à jour le PC ou le serveur, au moment
où l’utilisateur le désire.
Fonctions, rôles et responsabilités
Plusieurs rôles et responsabilités peuvent être identifiés lors des phases de conception, test et
déploiement.
Il s’agit entre autres de la construction des packages de MEP, avec les responsabilités
suivantes :
• Établir la configuration de la mise en production finale ;
• Concevoir le livrable ;
• Tester le livrable final avant les tests indépendants ;
• Établir les rapports sur les erreurs connues en suspens et les solutions de
contournement à communiquer ;
• Participer à la validation de la mise en œuvre finale.
Le personnel de déploiement aura les responsabilités suivantes :
• Délivrer physiquement la MEP des services ;
• Coordonner la communication et la documentation relatives à la mise en
production, la formation et les notes aux équipes techniques ;
• Fournir un guide d’application technique et un support tout au long du processus de
mise en production, y compris les erreurs connues et les solutions de contournement ;
• Fournir un feedback concernant l’efficacité de la mise en production.
Le personnel de support de début de vie participe à la phase de déploiement et de mise en
production et aussi à la première période d’exploitation. Par exemple, pour résoudre les
incidents avec le service modifié ou nouveau, ou pour parfaire la documentation.
En résumé
• Il existe 4 méthodes de déploiement d’un service ;
o Approche phasée : le service est déployé pour une partie des utilisateurs au
départ, puis l’opération est répétée pour les autres groupes d’utilisateurs ;
o Approche Big Bang : le service est déployé pour l’ensemble des utilisateurs en
une seule fois ;
40
o Approche de type push : lorsque le composant de service est déployé et poussé

vers les utilisateurs par l’administrateur du service ;
o Approche de type pull : lorsque le logiciel est mis à disposition en centrale de
distribution ;
• Il existe 2 fonctions principales dans la mise en œuvre des phases de conception, test
et déploiement ;
o La fonction de construction des packages de MEP a pour rôles de construire
et tester le livrable, mais aussi de participer à la validation de la mise en
œuvre finale ;
o Le personnel de déploiement aura les responsabilités principales de délivrer
physiquement la MEP, coordonner la communication et la documentation
et assurer la formation et les notes aux équipes techniques.
41

Management de La Qualité Avec ITIL

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Management de La Qualité Avec ITIL

Transféré par

Droits d'auteur :

Formats disponibles

Management de la qualité

Management de la qualité avec Méthodologie ITIL

Chapitre 1 : le référentiel de bonnes pratiques ITIL

En français, on traduirait par Bibliothèque pour l'infrastructure des technologies de

ITIL regroupe 5 publications

Comprenez le référentiel de bonnes pratiques ITIL.mp4

• La mise en place de la stratégie de ce service (objectifs, définition du périmètre) ;

C’est quoi précisément un service ?

Ce référentiel de bonnes pratiques a été développé par l'Office of Government Commerce

ITIL est aujourd’hui LA référence pour de nombreuses organisations et entreprises : secteur

Cela veut dire que :

Quels sont les bénéfices d’ITIL ?

Plus précisément, il peut permettre plusieurs choses :

• Améliorer la qualité du service fourni. En introduisant un ensemble cohérent de

• Il est facilement transposable aux pratiques existantes d’une entreprise. Une

Chapitre 2 : La terminologie ITIL

Le référentiel de bonnes pratiques ITIL propose un ensemble de connaissances pratiques et

Un process est comparable à une recette de cuisine

Un processus transforme donc un ou plusieurs éléments d’entrée en éléments de sortie en

Un processus est mesurable :

En IT c’est pareil, en maîtrisant le nombre et le type d’incidents ainsi que la satisfaction du

Pour notre exemple, dans un grand restaurant nous aurons :

Ramenées à une DSI, les fonctions peuvent être représentées par :

À chaque fonction, on attribue un ou plusieurs rôles.

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

Appliqué à notre restaurant, cela reviendrait à :

• La plonge a pour rôle de préparer les ustensiles ;

En IT, dans le processus de gestion des incidents, ce serait :

• Le management a pour rôle coordonner le travail des équipes ;

Autre terme important, le service.

Bon, d'accord. Mais c’est quoi concrètement un service ?

Dans la suite du cours, le terme "service" fera automatiquement référence à un service

• Le service IT fourni par un FAI est l’accès à Internet ;

Cycle de vie d’un service

Il est temps d’aborder un concept fondamental : le cycle de vie d’un service.

1. La stratégie des services (Service Strategy) ;

Chapitre 3 : Organisation du SI avec ITIL

Pourquoi mettre en place le cycle de vie d'un service ?

Le cycle de vie d’un service

• Pourquoi le client a-t-il besoin de ce service ?

Définissez la stratégie du service—Service Strategy—SS

Les 5 processus dans cette étape vont permettre de :

• Gérer les exigences du business ;

Concevez le service—Service Design—SD

Une fois la stratégie établie, il est temps de démarrer la conception du service.

• Établir les niveaux de services ;

Mettez en œuvre le service—Service Transition—ST

Dans cette troisième étape, 7 processus vont permettre de :

• Mettre en place le plan de déploiement ;

Exploitez le service—Service Operation—SO

Les 5 processus qui contiennent cette phase permettent de :

• Traiter les demandes des utilisateurs de ce service ;

Améliorez continuellement votre service—Continual Service Improvement—

Cycle de vie d'un service selon ITIL

Définissez qui fait quoi — Fonctions et Rôles

Il s’agit entre autres des fonctions suivantes :

Chapitre 4 : Gestion des changements avec ITIL

Les dangers d'un changement non contrôlé

Commençons par définir le terme "procédure".

Quelle est la différence entre procédure et processus ?

La procédure est donc un descriptif organisationnel détaillé pour réaliser le processus.

Un changement peut être défini de plusieurs façons.

Simplement, un changement se traduit par l’ajout, la modification ou la suppression d’un

Non seulement un déploiement est considéré comme un changement, mais la modification et