Ce document présente une politique de gestion du changement destinée à améliorer la qualité des services informatiques en assurant une gestion efficace des changements dans l'environnement de production d'une entreprise. Il décrit les procédures, les avantages et les classifications des changements, ainsi que le rôle du Change Advisory Board (CAB) dans le processus d'approbation. La politique couvre également la documentation requise et les exigences de suivi pour assurer la conformité et l'analyse des tendances de changement.

1. Change Management Policy
A Quick IT Change Management Policies
and Procedures Guide
Version 1.0 de Février 2020
Créé par OUAGHLANI Chiheb

2. Tables des abréviations
ITIL Information Technology
Infrastructure Library
Bibliothèque pour l'infrastructure
des technologies de l'information
CI Configuration item Elément de configuration
eCAB emergency change advisory board Comité d'approbation des
changements urgents
CAB Change Advisory Board Comité d'approbation des
changements
ITSM information technology service
management
Gestion des services informatiques
RFC Request for a Change demande de changement
1. Définitions
1.1 Introduction
Ce document est rédigé afin de présenter l’importance de mise en place d’une politique
de gestion du changement au sein d’une entrepris et de fournir quelques méthodes et
procédures normalisées pour répondre aux exigences de ce processus qui
soutiennent les opérations de l’entreprise.
Il est important de noter que toutes les meilleures pratiques ITIL pour la gestion des
changements informatiques ne sont pas incluses dans ce document.
1.2 Objectif
Assurer une gestion efficace du changement dans l'environnement informatique de
production de l'entreprise est extrêmement important pour assurer une prestation de

3. qualité des services informatiques. L’intention de ce guide de politique et procédures
est d'établir des directives bien définies pour demander et / ou introduire des
modifications dans l'environnement informatique au sein de l’entreprise.
Nous pouvons préciser, aussi, que l’objectif de la mise en place d’une telle politique
est d'atteindre une stabilité maximale dans l'environnement informatique de production
tout en établissant des normes à l'échelle de l'entreprise concernant la documentation
des changements, la notification, la révision, l'approbation, la mise en œuvre et le suivi.
1.3 Avantages d’avoir une politique de gestion de
changement
Le fait d'avoir une politique de gestion du changement permet à l’entreprise de :
 Être en mesure d'améliorer la technologie et les services sans interrompre
l’expérience client lors des changements.
 Accroître la sensibilisation et la compréhension des changements proposés au
sein de l’entreprise.
 Planifier efficacement et mettre en œuvre des changements rapidement.
 Augmenter les chances de succès des opérations et des projets.
 Savoir prioriser les changements en conséquence.
1.4 Périmètre
Il est recommandé de préciser les concernés par la politique du changement.
Il est important aussi de préciser les unités informatique et divisions de l’entreprise
dont cette politique s'applique.
Cette politique est destinée à couvrir tous les éléments techniques et physiques de
l'environnement informatique de production principalement (c'est-à-dire matériel,
logiciel, application, données, base de données, réseau, infrastructure et installation
environnementale).

4. Elle est destinée également à couvrir les documents et les enregistrements (c'est-à-
dire les plans, les accords de niveau de service, les politiques et les processus) qui
ont été désignés comme éléments de configuration gérés (CI).
Le Change Advisory Board (CAB) peut modifier périodiquement le champ d'application
pour inclure des éléments dans périmètre du processus global de gestion du
changement de l'entreprise.
1.5 Définition du Changement
Un « changement » est défini comme toute action d’ajout, de modification ou de
suppression du matériel, des logiciels, de la configuration, des applications, des
données, de la base de données, du réseau, de l'infrastructure, des installations
environnementales ou d’un document l'environnement informatique de l’entreprise.
Un « changement » peut être défini aussi comme une action corrective requise pour
résoudre un incident ou un problème impactant l'environnement informatique de
production, une action préventive afin de minimiser la probabilité d’un risque ou de son
impact ou même un point d’amélioration permettant de mieux exploiter un composant
ou ajuster une configuration de l’environnement afin de mieux s'aligner sur les plans de
l’entreprise.
2. Règles
2.1. Le changement
Chaque changement doit être classé et se voir attribuer une priorité / urgence.
La classification des changements dépend de plusieurs facteurs tel que: le niveau de
risque et des impacts, la maitrise du changement, les plateformes concernées, …
 Changement urgent avec un impact majeur => passage eCAB
 Changement avec un impact significatif => passage CAB
 Changement maitrisé avec un impact mineur => autorité Change manager
Chaque changement doit être revu et fermé avec le code de fermeture approprié ainsi
qu’une description après la mise en œuvre ou l'annulation.

5. Il est important de mettre en place un diagramme de flux d’activité donnant une vue
d’ensemble du processus de gestion des changements dans l’entreprise.
Les différentes étapes du changement peuvent être décortiquées et présentées en
digrammes dans un autre document « le change management process ».
La catégorisation des changements est aussi une tâche intéressante (Infrastructure,
Système, Applicatif par exemple) afin de spécifier les équipes / personnes concernées
et savoir la tendance des changements dans l’entreprise.
2.2. Request for a Change
Chaque changement proposé nécessite qu'une demande de changement (RFC) soit
entrée dans l'outil de gestion du changement d'entreprise ou le logiciel ITSM utilisé dans
l’entreprise ou soit saisie dans une Template des RFC appliquée (Document Word ou
Excel, …).
Chaque RFC doit inclure les données essentielles du changement tel que l’objectif du
changement, le nom du changement qui doit être unique afin de le différencier des
autres, la date souhaitée d’implémentation, les clients et la plateforme impactés, une
description, le/les Intervenant(s), ….
Chaque RFC doit inclure aussi la manière dont la modification doit être annulée (Plan
de retour en arrière) ou corrigée en cas d'échec.
Chaque RFC doit être évalué pour son impact potentiel sur les contrôles de sécurité,
les plans de capacité, les plans de continuité et les plans de disponibilité.
Un délai maximum est fixé pour la soumission des RFC entre deux réunions CAB.
Tout RFC qui est soumis avec moins que le délai minimum pour un changement normal
doit se conformer au processus de demande / approbation de changement accéléré ou
d'urgence.
Lorsqu'un RFC est disponible pour approbation et que certains champs sont modifiés,
les approbateurs doivent être réinitialisés afin que le contenu modifié puisse être
réévalué pour approbation. Si cette action fait tomber le RFC en dehors du délai

6. minimum pour un changement normal, le RFC doit se conformer au processus de
demande / approbation de changement accéléré ou d'urgence.
Chaque RFC doit être examiné et approuvé conformément au processus d'approbation.
2.3. Change Advisory Board
La réunion CAB se déroule d’une façon périodique (une semaine, 15 jours) dont la
présence est obligatoire pour l’organisateur (change manager), les validateurs
(responsables) et les initiateurs des changements, on parle aussi des membres
permanents du CAB.
Il faut que la change manager envoie une invitation aux initiateurs des changements au
CAB afin de mieux expliquer et détailler leur(s) changement(s).
Chaque groupe désigné comme approbateur sur un RFC spécifique doit évaluer et
approuver ou refuser le RFC sur la base d'une analyse des risques et de pertinence du
changement.
En cas d’absence d’un validateur de la réunion CAB, il faut prévoir une autre personne
qui le remplace dans un délai fixe avant son rétablissement, de même pour l’initiateur,
sinon le changement qui lui concerne sera reporté.
Des périodes de restriction de changement peuvent être imposées. Pendant ces
périodes, les initiateurs seront invités à appliquer un examen supplémentaire à leurs
modifications ou à différer les modifications qui ne sont pas nécessaires à ce moment-
là.
La personne qui demande le changement (initiateur) ne peut pas être la même personne
qui approuve le changement au nom du groupe initiateur.
La mise en œuvre de chaque changement doit être coordonnée entre l'initiateur, les
testeurs, les validateurs, ou les exécutants et les approbateurs.
Des tests post-implémentation seront effectués pour tous les changements validés lors
de la réunion CAB afin de s’assurer de la bonne implémentation avant d’être clôturés.

7. Si un changement prévu peut impacter un ou plusieurs clients et/ou une tierce partie, le
change manager doit demander au centre de services d’informer ces parties
concernées et avoir leur(s) accord(s) en leur transmettant les informations nécessaires.
Un système de vote peut être appliqué pour certains changements lors du CAB.
2.4. Documents liés à la gestion du changement
Les preuves documentaires des réunions CAB seront collectées et archivées.
Les enregistrements des changements doivent être analysés régulièrement pour
détecter les tendances de changements dans l’entreprise et les points d’amélioration à
faire.
Un calendrier de changement à terme doit être maintenu et communiqué pour être
utilisé comme base pour le calendrier de changement et de publication.
Les rapports de gestion du changement sont recommandés et doivent être élaborés
d’une façon périodique (chaque six mois ou annuellement).
Les rapports de gestion du changement comprennent:
Raisons du changement (demandes des utilisateurs, urgence, améliorations, exigences
commerciales, demande de service / incidents / corrections de problèmes, amélioration
des procédures / formation, etc.)
Nombre de changements réussis
Nombre de modifications ayant échoué
Nombre de modifications annulées, ainsi que les raisons (par exemple, évaluation
incorrecte, mauvaise construction)
Nombre d'incidents liés au changement et aux raisons
Nombre de RFC (et toutes les tendances en matière d’origine)
Nombre de modifications mises en œuvre examinées et taille des arriérés d’examen
Données des périodes précédentes (dernière période, année dernière) pour
comparaison
Nombre de RFC rejetés
Nombre de changements par catégorie