Mis à jour le 04/02/2019

Maîtrisez la terminologie ITIL

Comme nous l’avons vu précédemment, 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, vous devez
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. Alors, prêt à apprendre à parler ITIL ? 😉

Comme je vous l’ai présenté dans le chapitre précédent, le référentiel de bonnes pratiques ITIL se base sur :
 Des processus;
 Des fonctions ;
 Des rôles. Depuis sa mise à jour V3, le référentiel a également introduit le concept de cycle de vie d’un
service. Maintenant, prenons un moment pour bien définir ces concepts.
Processus
Commençons par définir les processus.

C’est quoi un 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 bonne blanquette de
veau😛. Les différentes étapes nécessaires à la réalisation de notre blanquette 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 viande, légumes et autres ingrédients… pour obtenir une blanquette de veau (miam) !

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 blanquette
de veau. 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.

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 blanquette, 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 blanquette.
En IT, dans le processus de gestion des incidents, ce serait :

 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…

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.
Vous vous en souvenez probablement, le référentiel ITIL est constitué de 5 livres !

Il s’agit de :

 La stratégie des services (Service Strategy) ;

 La conception des services (Service Design) ;
 La transition des services (Service Transition) ;
 L’exploitation des services (Service Operation) ;
 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.

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.

 #
Mis à jour le 04/02/2019
Organisez le SI avec ITIL
Dans les chapitres précédents, vous avez appris que ITIL propose un ensemble de bonnes pratiques et que ces
bonnes pratiques offrent des connaissances utiles dans la gestion d’un service IT. Vous avez aussi acquis le
vocabulaire normé de ce référentiel.

Maintenant, il est temps de découvrir comment il s’articule autour de ses 4 concepts clés : les processus, les
fonctions, les rôles et le cycle de vie d’un service.

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. Le
génie que vous êtes va se poser les questions suivantes 🤔 :
  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 d’une phase du cycle de vie
d’un service. Ces 5 phases fournissent l’orientation pour atteindre un standard de qualité.

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

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

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.

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.
Vous avez désormais une vision d'ensemble de l'utilité d'ITIL, comment il est structuré, et à quoi il sert. Dans la
prochaine partie, je vous propose d’apprendre à garder le contrôle de votre SI en établissant une procédure
opérationnelle de gestion des changements.

Mis à jour le 04/02/2019

Maîtrisez le vocabulaire de gestion des changements
Dans la première partie du cours, je vous ai présenté le référentiel de bonnes pratiques ITIL. Les 5 ouvrages de ce
référentiel contiennent les expériences d’apprentissage de professionnels et d’experts dans le domaine
informatique.

Par la suite, je vous ai présenté les concepts clés que sont le cycle de vie d’un service, les processus, les fonctions et
les rôles.

Enfin, vous avez découvert comment ITIL améliore la qualité d’un service IT en proposant 26 processus et 4
fonctions principales dans le cycle de vie d’un service informatique. Si un seul des termes cités ci-dessus vous paraît
abstrait, foncez relire la première partie du cours. J’ai tout mon temps !

Dans cette seconde partie, je vous propose d’apprendre à garder le contrôle de votre 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 je définirai les activités nécessaires pour effectuer
sereinement un changement. Enfin, je vous présenterai un outil opensource qui vous servira à
modéliser l’ordinogramme d’un processus de gestion des changements.

Programme alléchant donc. Calez-vous confortablement dans votre fauteuil, on démarre tout de suite !

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…). Je vous épargne
les liens et relations entre ces derniers.

Mon record personnel est de 2 380 serveurs pour environ 650 applications !

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 ?
Souvenez-vous, 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.

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 beaucoup de façons.

Expliqué 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 ?

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—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.

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.

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 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 de votre SI.

Il existe des outils opensource qui vont vous permettre de mettre en œuvre votre CMDB et bien plus encore. iTop est
un outil de gestion des services informatiques offrant des modules 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, je vous ai présenté le vocabulaire normalisé de la gestion des changements. Vous devrez retenir
que :

 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 définit qui fait quoi. Il 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 que vous avez acquis le vocabulaire, il temps de s’attaquer à l’élément déclencheur d’un changement, la
RFC ! Dans le prochain chapitre, vous allez apprendre à rédiger une RFC, la qualifier, et la prioriser.

Mis à jour le 04/02/2019

Organisez les changements dans votre SI
Dans le chapitre précédent, vous avez acquis le vocabulaire de gestion des changements. Ce vocabulaire normalisé
est utilisé dans toutes les entreprises. Si l’un des termes abordés vous paraît flou, n’hésitez surtout pas à relire le
chapitre précédent.
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, j’aborderai
les plans de retour arrière qui constitueront votre assurance de retrouver la situation initiale en cas de pépin.

C'est parti !

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 vous aider à y voir un peu plus clair.

Découvrez 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 ?
 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.

Pour rendre le tout plus pratique, je vous ai 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 : À traiter Risque vital causant une perte significative Ne doit pas être utilisé pour ce type de
comme un changement de la qualité de service. Action immédiate changement.
urgent. requise.
P2 – Majeur : La priorité Service dégradé avec impact sur un grand Déployer un patch de sécurité, répondre à une
la plus haute pour les nombre d’utilisateurs. obligation légale, déploiement d’un nouveau
actions de déploiement. service avec une forte valeur ajoutée pour le
business, non-respect d’un délai contractuel.
P3 – Moyen Impact peu sévère de l’incident sur les Changement apportant une amélioration dans
utilisateurs. Cas où la correction doit l’utilisation du service, planifiée avec un délai
attendre le déploiement d’une nouvelle contractuel.
version, ou d’une mise à jour.
P4 – Normal Changement correctif justifié mais pas Changement apportant une amélioration dans
nécessaire, car il existe une solution de l’utilisation du service, planifiée avec un délai de
contournement. Peut attendre la contractuel moins important que le P3, voire sans
prochaine mise à jour. délai contractuel.
P5 – Planifié Ne doit pas être utilisé pour les Tout autre cas non abordé pour les changements
changements correctifs. 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é.
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 ;
 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, je vous propose de lister les activités, rôles et responsabilités de votre processus de gestion
des changements.

Mis à jour le 04/02/2019

Définissez les activités d'un processus de gestion des changements
Dans le chapitre précédent, vous avez appris à établir le périmètre d’un changement, en utilisant la règle des 7R.
Ensuite, je vous ai présenté une méthode basée sur l’évaluation de l’impact et de l’urgence, qui vous permettra
d’établir la priorité d’un changement. Pour terminer, j’ai abordé la notion de plan de retour arrière, qui sera votre
assurance tous risques et permettra au service, de retrouver sa situation initiale.

Dans ce chapitre, je vous propose de découvrir les activités essentielles en gestion des changements.

Vous êtes prêt ? Allons-y !

Découvrez ce qu'est une 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 farfelues (oh, que
oui vous en aurez !).

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.
Processus des activités d'un changement Normal
Dans le chapitre suivant, Je vous apprendrai à 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 oeuvre 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é.

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 je l’ai é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 shérif 😉). 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.

En résumé
Voici un résumé de ce que vous avez appris dans ce chapitre :

 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.
Voilà, il ne vous reste plus qu'à réaliser un ordinogramme d’un processus de gestion des changements. Pour cela,
retrouvez-moi au prochain chapitre, où j’utiliserai 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.
 Mis à jour le 04/02/2019

Réalisez l'ordinogramme d'un processus avec XMind

Dans le chapitre précédent, j'ai évoqué les activités essentielles d’un processus de gestion des changements.
Ensuite, j’ai abordé les spécificités liées aux changements urgents et standard.

Dans ce chapitre, je vous propose de réaliser l’ordinogramme de vos processus de gestion des changements, afin
de représenter graphiquement l'enchaînement des activités d’un processus de gestion de changement.

On commence tout de suite.

Qu'est-ce qu'un ordinogramme ?

Une meilleure compréhension d’une procédure 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 votre changement. L'ordinogramme
va nous permettre de visualiser clairement et simplement ces activités, actions et décisions à prendre.

Mais avant, j’aimerais 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 :

 Utilisez une forme ovale pour représenter un événement qui intervient en entrée ou en sortie de processus
;
 Le rectangle représente une activité intervenant en cours de processus ;
 Utilisez le losange pour représenter une décision dans le processus ;
 Utilisez un cercle pour représenter une activité ou un point qui fait appel à un autre processus.

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 de mind mapping (carte mentale). Sa version de base est gratuite, en français, et
présente l’avantage d’être très intuitive.

Dans la vidéo au début de ce chapitre, c'est XMind que j'utilise pour réaliser l'ordinogramme. Vous pouvez le
télécharger ici.

Voilà, c’est maintenant à vous de jouer !

 Mis à jour le 04/02/2019
Préparez et organisez une mise en production grâce aux packages
Dans les chapitres précédents, vous avez appris à mettre en place une procédure opérationnelle de gestion des
changements dans votre SI. Cette procédure vous apprendra à contrôler et à sécuriser tous les changements dans
votre système d’information, en approuvant et en pilotant les demandes de changement. Vous avez 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, je vous propose d’aborder de façon pratique les activités
de conception, test et déploiement d’un processus de gestion des changements. Au fil de cette partie, 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
Bienvenue chez 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).

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 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 2 (secondaire)
Release 2 RFC005 Installation de l’agent de supervision sur serveur de prod 2 (secondaire)
Release 3 RFC006 Montée en version de l’OS sur serveur de prod 1 (principal)
 Release 3 RFC007 Installation de l’agent de supervision sur serveur de prod 1 (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.

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 Release 1 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 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. Il s’agit des logiciels, du matériel, de la documentation, et souvent de la formation. C’est le
produit de la conception.


Testez et validez vos 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.

Testez et validez vos packages

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 ;
 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é.

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.

Mis à jour le 04/02/2019

Choisissez la 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 dernier chapitre, je vous propose de passer en revue les différentes méthodes de déploiement de vos
packages.

Comprenez 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érents 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 une push dans la mesure où le pakage est livré dans l’environnement de
production à un moment imposé.
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 ;
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 oeuvre 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.
Voilà, ainsi s’achève ce cours. J'espère que vous avez pris plaisir à le suivre ! Je vous souhaite bon courage dans vos
études et vos projets professionnels.