Eviter les pièges du référentiel ITIL : confondre « changement » et « mise en production »

2.2 Confondre « changement » et « mise en production »

2.2.1 L’origine de la confusion : les outils logicielsITIL®

Lors de mon utilisation de plusieurs logiciels certifiés ITIL®, quelle ne fut pas ma surprise de constater qu’une équipe projet doit faire des demandes de changement à chaque fois qu’elle demande aux équipes d’exploitation de mettre en production un serveur, une base de données ou un package d’installation applicatif.

Historiquement et avant la popularisation du référentiel ITIL®, le terme change était utilisé dans ce sens dans ces logiciels.

Beaucoup de présentations ITIL® font aussi cet amalgame.

2.2.2 Autre confusion : « déployment » et « release »

Le nom du processus « Gestion des déploiements et des mises en production » est aussi très ambigü en français car il est difficile de traduire correctement « Release and Deployment Management ». En effet, le terme release est traduisible à la fois par package d’installation (le binaire) et par l’action de mettre en production le package d’installation.

Le terme mise en production doit être pris dans le seul sens de package d’installation.

Le nom du processus aurait pu être « Gestion des packages d’installation et des déploiements », la première partie étant matérialisée par la bibliothèque des media définitifs (DML ou Definitive Media Library).

2.2.3 Un projet est déclenché par une demande de changement

La séquence prévue dans ITIL® est la suivante :

  • demande de changement pour toute modification de l’environnement de production (au sens large, comprenant tous les actifs de service : organisation, processus, personnes, connaissances, etc.) : certains changements (les plus importants) seront traités en mode projet

  • les processus de gestion des changements, de méthodologie projet et d’autres processus de la transition des services sont déclenchés

  • lorsqu’arrive le moment de livrer un « media définitif » et de le déployer dans l’environnement de production, le processus de gestion des changements ou la méthodologie projet, va faire des demandes de mise en production déclenchant ainsi la partie la plus importante du processus de gestion des déploiements et des mises en production

Ainsi, un changement ou un projet, peut déclencher un ou plusieurs déploiements. Le processus de gestion des déploiements et des mises en production peut, de son côté, décider de regrouper plusieurs mises en production dans une seule (déploiement d’un ensemble de correctifs par ex.) pour des questions pratiques.

2.2.4 Les projets statégiques « affrètent » un changement

Les projets stratégiques seront aussi traités de manière classique dans le processus de gestion des changements.

Les projets stratégiques sont initiés par le processus de gestion du portefeuille de services, lui-même initié par d’autres processus stratégiques (gestion de la stratégie ou gestion financière des services par ex.) ou l’amélioration continue des services.

Le schéma suivant résume les activités macros du processus de gestion du portefeuille de services :



Lorsqu’est arrivé le moment pour un nouveau service de passer dans la partie « catalogue de services » du portefeuille de services (encore une autre ambiguïté du référentiel ITIL®), le processus de gestion du portefeuille de services va faire une « demande de changement améliorée » appelée « proposition de changement » (Change Proposal) pour déclencher le processus de gestion des changements.

La proposition de changement est une demande de changement enrichie de tous les documents stratégiques qui ont déjà été réalisés sur le futur service avant même que le changement ait été initié (et le projet lancé), notamment le dossier business (qui est l'équivalent d'un document d’avant-projet).

Une fois le changement lancé, le changement se déroule de manière classique bien qu’il soit suivi (de loin) par le processus stratégique de gestion du portefeuille de services.

Dans la vraie vie, c’est exactement ce qui se passe sur un projet stratégique en cours de réalisation : même si le directeur informatique n’est pas le chef de projet, il suit quand même d’assez près l’évolution du projet stratégique.

2.2.5 La gestion des changements est un processus de pilotage et non pas de réalisation

Bien que j’utilise rarement le schéma ITIL® du processus de gestion des changements en raison de sa trop grande simplification, il permet néammoins de voir qu’une fois la demande de changement autorisée, les activités du processus parlent de planifier et de coordonner les activités de réalisation et de faire un bilan sur la réalisation :



Ce qui n’est pas présenté dans ce schéma, ce sont les interactions avec les autres processus, qu’ils soient ITIL® ou appartenant à la méthodologie projet.

D’autre part, l’activité « Coordonner l’implantation » couvre toutes les étapes de conception, de développement/paramétrage, de test et de mise en production du produit.

Lorsqu’on aligne les activités de ce processus avec une méthodologie projet, il est possible de détailler les activités de changement qui sont à rapprocher avec les activités jalons d’un projet.

Evidemment, ceci n’est valable que pour les changements traités en mode projet :



Nous sommes là très loin d’un processus opérationnel où l’équipe projet fait des « demandes de changement » aux équipes d’exploitation à chaque fois qu’une intervention de production est nécessaire.

Ces demandes faites par l’équipe projet sont en fait des demandes de mises en production qui vont déclencher le processus de gestion des déploiements et des mises en production.

2.2.6 Le processus de gestion des changements : un premier pas vers le Dev-Ops

Dev-Ops est une approche permettant d’accélérer très fortement les projets en structurant d’une manière complètement intégrée les processus de développement et les processus d’exploitation et en mettant un œuvre un outillage logiciel automatisant un maximum d’activités de ce macro-processus.

Ceci découle directement de la mise en œuvre des principes Lean sur ce domaine d’activités.

Le processus de gestion des changements est celui qui va permettre de structurer toutes ces activités (méthodologie projet et processus ITIL® concernés) et de les positionner autour des activités jalons de la gestion des changements.

Ensuite, avec une vue globale de toutes ces activités, il sera moins difficile de sélectionner un outil ou un ensemble d’outils pour automatiser et accélérer le traitement de ces activités.