AFFICHER TOUT LE CONTENU

Table des matières

Articles reliés

Introduction

Cet article présente les concepts clés du processus de Gestion des changements selon le cadre de référence ITIL®. Nous avons inclus les éléments essentiels qui aideront à la compréhension du processus et son opérationnalisation dans Octopus.

Quelle que soit la taille d'une entreprise, des changements mal gérés ont des conséquences non négligeables autant pour l'entreprise que pour l'organisation TI. Les changements ne servent pas seulement à corriger des erreurs de l'infrastructure au moment où ils surviennent. En les planifiant de manière à minimiser les risques et les impacts, l'organisation TI démontre qu'elle sait soutenir les besoins d'une entreprise, dont l'objectif est la croissance et... la survie.

Pour une organisation TI, une gestion des changements déficiente peut se manifester de différentes façons, entre autres par :

des pannes « surprises »
l'apparition d'incidents suite à un changement
un nombre élevé de changements urgents

Du point de vue des utilisateurs, ça se traduit par des interruptions qui les empêchent de faire leur travail, ce qui implique un coût pour l'entreprise. Cela a un impact négatif sur la perception des utilisateurs face à l'organisation informatique. Les changements sont vus comme des « problèmes » et sont accueillis avec réticence et suspicion.

Qu'est-ce qu'un changement?

La définition ITIL® d'un changement est l'ajout, la modification ou la suppression de quoi que ce soit pouvant avoir un effet sur les services TI. La vraie question est : qu'est-ce qui doit être considéré comme un changement et comment une organisation TI doit-elle le traiter de manière à minimiser les impacts et les risques, et être certaine de répondre aux besoins réels d'une entreprise? Il ne peut y avoir de changement sans risque, mais ce dernier doit être connu et géré. Dans cette perspective, on pourrait dire aussi qu'un changement est « toute intervention qui constitue un risque pour un service TI ».

Vous trouverez d'autres définitions dans la section « Gestion des changements » de notre Glossaire ITIL®.

Le processus

But & Objectif

Le but de la gestion des changements est de contrôler le cycle de vie de tous les changements, et d'entreprendre des changements bénéfiques pour l'entreprise avec le minimum de perturbations aux services TI.

L'objectif principal est de s'assurer que tous les changements soient enregistrés, évalués, autorisés, priorisés, planifiés, testés, mis en oeuvre, documentés et revus de manière contrôlée.

Pour que ce contrôle soit effectué de façon satisfaisante, le processus de Gestion des changements doit voir, entre autres :

à utiliser des méthodes et des procédures standardisées et réutilisables
que ces méthodes soient connues et appliquées par tous les acteurs
à enregistrer tous les changements
à tenir compte des risques et des impacts sur les affaires

Portée

Très simplement, la portée du processus de gestion des changements pourrait être identifiée par tout ajout, modification ou retrait aux éléments de configuration qui servent dans la livraison des services TI. De quoi sont constitués les services TI? D'actifs physiques (serveurs, actifs réseau), virtuels (serveurs virtuels, stockage virtuel), logiciels ou applicatifs, documentation, services TI, processus ou autres. Ils impliquent les ressources TI, les clients/utilisateurs et les fournisseurs externes.

Pour être réaliste, ceci ne veut pas dire que le processus de gestion des changements doit être appliqué sur tous types d'actifs dès le premier jour. L'enregistrement de tous les changements est déjà, pour certaines organisations, un grand pas, par les ressources TI qui comprennent bien ce qu'est un changement.

Catégorisation

Il existe trois (3) catégories de changement :

Changement standard

Le changement standard est un changement pré autorisé par la Gestion des changements, relativement commun, exécuté selon une procédure ou une instruction de travail pré établi (« workflow ») et dont le risque est contrôlé (exemples de changement standard : correctif « patch » de sécurité, remplacement d'une imprimante, déménagement de plus de x utilisateurs). Une liste de changements standards peut être pré déterminée; un changement ne faisant pas partie de cette liste devra être traité comme un changement normal.

Diagramme de processus

Changement normal

Changement qui n'est ni un changement standard ni un changement urgent. Il suit les activités telles que définies dans le processus de Gestion des changements. Selon les risques, les impacts, les coûts et les dépendances avec d'autres changements, il se subdivise en 3 catégories :

Mineur
Significatif
Majeur

Diagramme de processus

Changement urgent

Le changement urgent est un changement normal qui doit être mis en oeuvre dès que possible. Essentiellement, il suivra le même processus que les changements normaux, mais il sera adapté à la situation d'urgence. Si le CAB ne peut se réunir rapidement, on invoquera le ECAB qui aura le niveau d'autorité nécessaire pour prendre des décisions, on procédera aux tests autant que possible, et la documentation du changement et des données de configurations pourra être effectuée ultérieurement (exemples de changement urgent : résoudre un incident majeur, déployer un correctif de sécurité urgent, etc.).

Priorisation

La priorité d'un changement est dérivée de l'impact et de l'urgence. Dans le contexte d'un changement, on pourrait les définir de la façon suivante :

Impact : mesure l'effet d'un changement sur les affaires. Repose sur les bénéfices liés au changement ou sur l'étendue des dommages si le changement tourne mal.
Urgence : temps que met un changement à avoir un impact significatif sur les affaires. Basée sur le délai d'implantation acceptable du changement.
Priorité : identifie l'importance relative d'un changement. Basée sur l'impact et l'urgence. Considère la notion de gestion du risque et les conséquences sur les affaires.

Activités

Afin de mieux comprendre le déroulement du processus de Gestion des changements, voici une brève description de chaque activité.

Enregistrer

Une demande de changement peut provenir de l'entreprise ou de l'organisation TI. En premier lieu, il faut s'entendre sur qui peut soumettre un changement (un super utilisateur, un propriétaire d'application, une ressource TI). Tous les changements enregistrés sont identifiés d'un numéro unique. Les impacts, les risques, les bénéfices du changement, etc. font partie des informations à fournir qui serviront à la validation et l'évaluation. La documentation de ces requis peut prendre la forme d'un formulaire, d'un document à remplir, ou autre.
Valider

On procède à un filtrage. Parmi toutes les demandes de changement soumises, certaines peuvent être illogiques, inapplicables, incomplètes, ou avoir déjà été soumises par quelqu'un d'autre.
Analyser et évaluer
- Le changement est catégorisé et on applique le niveau approprié d'approbation
- On détermine la composition du CAB
- On évalue la justification du changement, les bénéfices d'affaires, l'impact, le coût, les risques
Approuver

L'approbation du changement accorde le passage en environnement de production; cette responsabilité relève de la Gestion des changements. Les impacts, les risques, les bénéfices, la procédure de retour arrière, etc. ont été évalués et l'instance d'approbation désignée donne son accord ou refuse le déploiement. Dans un premier temps, on doit s'entendre sur qui approuve quoi. Par exemple, on pourrait convenir que :
- les changements standards sont pré approuvés
- le gestionnaire des changements prend en charge l'approbation des changements mineurs
- le CAB s'occupe des changements significatifs, majeurs et urgents / le ECAB prend la relève si le CAB n'est pas disponible
Qu'est-ce que le CAB / ECAB ?
- Le CAB (« Change Advisory Board ») est le comité consultatif sur les changements. Son rôle est de contribuer à l'évaluation, la priorisation et la cédule des changements, et de participer à leur approbation. Lors des réunions du CAB, tous les changements adressés doivent être évalués en considérant deux perspectives : technique et opérationnelle (point de vue affaires). L'important est d'identifier les bons acteurs et le bon niveau hiérarchique à impliquer; ceci pourrait inclure des ressources et des gestionnaires TI, des clients/gestionnaires et des fournisseurs externes.
  
  Un CAB permanent peut être constitué et lors des changements particuliers, d'autres acteurs sont impliqués. Il revient au gestionnaire des changements de constituer le CAB et de le présider.
- Le ECAB (« Emergency Advisory Board ») est le comité consultatif sur les changements urgents. Il est invoqué lorsque le CAB régulier ne peut être réuni. On doit s'assurer que le ECAB ait l'autorité de prendre des décisions urgentes et voir à ce que la business soit représentée.
_________________________________________________________

RÉUNIONS DU CAB

Les réunions du CAB peuvent être conduites à distance - parfois la situation l'exige - par courriel, téléphone, ou tout autre mode de communication à distance telle que la vidéoconférence. Étant donné le niveau décisionnel exigé pour les changements à risques et impacts plus élevés, il convient que les participants soient dans des conditions de communication optimales pour favoriser les échanges menant à une décision éclairée (le courriel n'en est pas un ici).

Le CAB sera adapté au contexte et à la taille de l'organisation informatique. L'important est d'avoir une autorité qui voit à ce que les changements soient contrôlés, les risques évalués et les interruptions de services minimisées afin de viser un déploiement réussi à la première tentative. Les documents pertinents doivent être distribués à l'avance pour permettre aux membres du CAB d'évaluer les changements et de se préparer aux réunions. Une date limite de soumission des changements s'avère une bonne idée et évitera que les demandes soient déposées à la dernière minute.

Comme toute réunion efficace, le CAB doit avoir un ordre du jour, et surtout ne pas servir à discuter de la construction du changement. Les changements soumis au CAB doivent être prêts à être évalués et approuvés. Le CAB se réunit à intervalles réguliers pour prioriser, évaluer les changements présentés, faire une revue des changements complétés, discuter des changements implantés sans autorisation, etc. En principe, il constitue une entité consultative, mais on pourrait le désigner comme étant l'autorité décisionnelle. En cas de désaccord, le directeur TI sera sollicité pour décider du sort du changement.

Un modèle d'approbation peut être constitué pour préciser les niveaux hiérarchiques impliqués dans les changements significatifs, majeurs et urgents, lesquels ont un impact et un risque variables.

Exemple de modèle d'approbation
Coordonner la mise en oeuvre

Les étapes de réalisation des changements approuvés doivent être transmises aux équipes techniques concernées et aux utilisateurs « testeurs », le cas échéant, pour préparer la mise en oeuvre. Il faut tester minutieusement les changements, déterminer une procédure de retour arrière, documenter les solutions aux incidents connus qui surviendront, etc.
Revoir et fermer

Les changements normaux et urgents mis en oeuvre sont revus après leur passage en environnement de production; le CAB détermine si c'est nécessaire. Les questions suivantes peuvent être abordées :
- Est-ce que le changement a atteint le but souhaité?
- Est-ce que les parties prenantes sont satisfaites du résultat?
- Y a-t-il eu des effets secondaires imprévus?
- Y a-t-il eu des dépassements de coûts et d'efforts par rapport à l'évaluation initiale?
- Pouvons-nous faire mieux la prochaine fois et améliorer le processus?
Si le changement est réussi, il peut être clos. Sinon, la gestion des changements ou le CAB décidera de ce qu'il faut faire : un nouveau changement ou une modification au changement enregistré.

Au moment de la clôture, le gestionnaire des changements vérifie que la documentation du changement est complète, et s'assure d'inclure le résultat de la revue du changement. Toute cette information pourra servir de base de connaissance pour un nouveau changement de nature similaire, ou encore comme contribution à l'amélioration continue du processus.

Métriques

Nombre ou % de changements partiellement réussis / réussis / en échec
Nombre ou % de changements en échec sans plan de retour-arrière
Nombre ou % de changements non autorisés
Nombre de changements en attente (en « backlog »)
% des changements complétés dans les temps
% des changements ayant causé des incidents
Nombre ou % de changements urgents

Changement ou demande de service ?

Par définition, une demande de service est un changement standard. Les deux sont pré autorisés, relativement communs, avec une procédure pré établi (« workflow ») et leur risque est contrôlé. Il revient à chaque organisation de définir une liste formelle de requêtes respectant ces critères; elles représentent la plupart du temps les demandes soumises par les utilisateurs finaux. Prises en charge par le processus d'Exécution des requêtes, elles sont suivies par le Centre de services et contribuent à alléger le processus de gestion des changements.

Voici certaines règles qui pourraient vous situer davantage :

Définir clairement ce que représente une demande de service et un changement dans votre organisation, et vous assurer que les membres de l'équipe comprennent la différence
On enregistre un changement si une intervention présente un risque ou un impact sur les affaires, même minime, et/ou qui nécessite un arrêt de service (indisponibilité d'un système)
On pourrait décider qu'un type de CI spécifique passe obligatoirement par la gestion des changements, comme un équipement réseau, par exemple
Toutes les demandes qui ne font pas partie de la liste de demandes de service disponibles doivent être enregistrées comme changements
Les demandes de services et les changements standards sont pré approuvés et ne passent pas par le CAB

Plus les règles seront claires, connues, comprises et suivies, mieux la gestion des changements s'en portera.

Aidez-nous à améliorer l’article

Gestion des changements - Processus ITIL®