Blog ENI : Toute la veille numérique !
🐠 -25€ dès 75€ 
+ 7 jours d'accès à la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici

La mise en service, le contrôle et la validation

Présentation générale

1. Introduction

La phase de mise en service, de contrôle et de validation va permettre d’intégrer les nouveaux services, les nouvelles évolutions et les nouveaux changements que demande l’entreprise pour réaliser son ou ses métiers. C’est une phase dite de transition. Cette phase de transition est donc un cadre pour le développement et l’amélioration de la capacité à mettre en production des nouveaux services et à améliorer les services existants. On est dans la phase de mise en œuvre des changements qui sont à effectuer sur le système d’information, en mettant en place les mécanismes de contrôle et de validation. De plus, cette phase va traiter la mise en place des correctifs qui vont améliorer le niveau de qualité du système d’information.

Cette phase est donc en charge de gérer les pratiques, les processus, les systèmes, les produits qui vont permettre de réaliser, packager, construire, tester, valider, déployer un service et s’assurer que ce service fonctionnera correctement conformément au niveau de service demandé.

2. Les objectifs de la mise en œuvre

Voici les objectifs de la mise en œuvre (mise en production, contrôle et validation) :

1- Mettre en production des nouveaux services...

La pratique gestion des changements

1. Généralités

a. Définitions

Changement

Au sens ITIL, un changement est une modification d’un ou plusieurs éléments de configuration (CI, Configuration Items) composant le système d’information ou d’un ou plusieurs services fournis par ce système d’information ; modification voulant dire ajout, modification d’attribut ou retrait d’un ou de plusieurs éléments de configuration.

On identifie trois types de changement :

  • Le changement dit normal : il nécessite une évaluation complète et une autorisation avant sa réalisation.

  • Le changement standard : cela concerne les changements pré-autorisés et qui vont suivre des procédures prédéfinies.

  • Le changement urgent : il demande une réaction plus rapide que prévu pour limiter les impacts sur le métier.

Demande de changement (RFC, Request For Change)

La demande de changement est le point d’entrée de la pratique gestion des changements et globalement le point d’entrée de la phase de transition des services. Une demande de changement est un formulaire que le demandeur du changement doit remplir initialement, mais c’est aussi la fiche qui va suivre le changement jusqu’à sa clôture. De ce fait, ce formulaire sera complété par le gestionnaire des changements pendant toute la vie du changement. Il faut définir des formulaires différents suivant le type de changement (normal, standard, urgent), mais aussi suivant la nature et le poids du changement : il doit être adapté à la demande et le plus simple possible.

Voici une liste non exhaustive des informations que l’on doit renseigner :

N° de RFC

Numéro d’ordre

Date d’émission

Date de soumission au processus gestion des changements

Objet

Description du sujet de la demande de changement en quelques mots

Demandeur

Nom du demandeur

Entité demandeur

Nom de l’entité qui demande le changement

Sujet

Description détaillée de la demande de changement (des documents annexes sont possibles)

Date souhaitée de la mise en service

Il s’agit de la fenêtre souhaitée pour la mise en service (date minimale, date maximum)

Type de changement...

La pratique gestion des risques

1. Généralités

Dans la démarche ITIL 4, une pratique dédiée a été définie et s’appuie sur la norme ISO 31000.

Cette norme de l’Institut mondial de normalisation ISO est la référence en matière de gestion des risques. La dernière version de cette norme date de 2018. Elle donne les lignes directrices concernant la gestion des risques pour une organisation, quel que soit son secteur d’activité. Elle peut être considérée comme un peu générique.

On retiendra dans cet ouvrage seulement la terminologie de la norme ISO 31000 qui éclaire sur un certain nombre de notions, mais avec son prisme de norme générique.

a. Terminologie de la pratique

Définition du risque

Un risque est l’effet de l’incertitude sur l’atteinte d’un objectif. Un risque est identifié par des sources de risque, des événements, des conséquences et une vraisemblance.

Source de risque

La source de risque est tout élément, seul ou combiné avec d’autres, qui peut engendrer un risque.

Événement

Un événement est un changement particulier de circonstances. Il peut se produire, mais on ne s’y attend pas ou on s’y attend et il ne se produit pas. Un événement peut être...

La pratique gestion des mises en production (MEP)

1. Généralités

a. Définitions

Unité de production

Une unité de production est un ensemble d’éléments de configuration (CI) cohérent qui est livré pour être mis en production. Une unité de production peut contenir du matériel, du logiciel, de la documentation, ou un mix de tous les types d’éléments de configuration.

Une unité de production groupée est un ensemble d’unités de production. Cela permet d’embarquer dans une même mise en production plusieurs changements qui ont des liens entre eux. On préconise dans la mesure du possible cette approche.

DML

La DML, bibliothèque définitive des médias (Definitive Media Library en anglais), est une zone d’archivage physique sécurisée des éléments de configuration logiciels mis en production. La DML va contenir les kits logiciels, la documentation associée et les clés de licence si nécessaire. Elle contient les médias des logiciels. C’est une bibliothèque qui contient donc la référence des logiciels achetés ou développés.

Il ne faut pas confondre la DML avec la CMS et les CMDB (voir le processus de gestion des actifs de services et des configurations). La DML contient les sources et les exécutables des logiciels, la CMS contient des informations sur les logiciels.

Politique de mise en production

Le document intitulé politique de mise en production est un document qui va spécifier comment la pratique gestion des mises en production va travailler durant l’année et définir ses engagements vis-à-vis de la pratique de gestion des changements. Ce document va donner les droits et les devoirs de gestion de la mise en production. Il est de la responsabilité du gestionnaire de cette pratique d’élaborer ce document.

Ce document contient les informations suivantes :

  • Les conventions de nommage des différents types de versions.

  • La description des différents types de versions.

  • Les rôles et les responsabilités à chaque étape du processus.

  • Les fréquences attendues pour les différents types de versions.

  • Les engagements de délais pour les différents...

La pratique gestion des déploiements

1. Généralités

L’objectif de la pratique gestion des déploiements est de transférer dans les environnements de production tous les éléments qui composent un changement, c’est-à-dire :

  • les éléments matériels nouveaux, modifiés ou remplacés pour cause de panne,

  • les éléments logiciels, applicatifs ou logiciels de base, nouveaux ou modifiés,

  • la documentation pour les produits nouveaux ou modifiés pour cause d’amélioration,

  • les processus ou les procédures opérationnelles.

On parle alors de déployer une unité de production.

La pratique gestion des déploiements peut aussi gérer le transfert vers les environnements de test, d’intégration ou de préproduction.

Cette pratique a des relations très étroites avec les deux pratiques suivantes : gestion des mises en production et gestion des changements. En particulier, toute la communication vers les utilisateurs est de la responsabilité de la gestion des mises en production et non de la gestion des déploiements.

a. Les types de déploiement

Cette pratique est responsable du choix du mode le plus approprié pour le déploiement d’une unité de production, suivant l’impact, la taille et le risque liés à ce déploiement.

Déploiement...

La pratique gestion des configurations

1. Généralités

La pratique gestion des configurations est une pratique qui est dédiée uniquement au département informatique et au service de toutes les autres pratiques de la démarche ITIL 4.

a. Définitions

Élément de configuration

Un élément de configuration (CI, Configuration Item) est un composant du système d’information qui va contribuer à la fourniture d’un ou plusieurs services sur lequel on veut appliquer un contrôle. Les attributs d’un CI sont l’ensemble des informations qui vont décrire l’élément et son comportement pendant sa vie.

Chaque type d’élément de configuration va être modélisé, c’est-à-dire défini et structuré.

Les relations sont les liens qui existent entre les différents éléments de configuration (appartient à. est connecté à, est un module de).

CMDB

La CMDB (Configuration Management Database) est la base de données qui contient les éléments de configuration. Dans les bonnes pratiques ITIL 4, on peut mettre en place plusieurs CMDB si nécessaire (par site, par métier, par technologie, etc.). Souvent, cela est lié à un historique ou à des outils existants.

CMS

Le CMS (Configuration Management System) est un ensemble d’outils et de bases qui permet de fédérer toutes les données de configuration stockées dans les CMDB. Il amène une couche de présentation qui va structurer les données suivant la demande. Des outils de CMS proposés...

La pratique gestion des actifs de services

1. Généralités

Cette pratique reprend des tâches gérées par les processus ITIL V3 gestion des actifs de services et des configurations, et gestion financière.

a. Objectifs de la pratique

Les objectifs principaux de la pratique gestion des actifs de services sont de planifier et gérer le cycle de vie des actifs de services, de manière à maximiser la valeur de ces actifs, à contrôler leurs coûts, et à gérer leurs risques. Elle va aider la pratique gestion des fournisseurs en fournissant des informations sur l’acquisition de nouveaux actifs, leur retrait ou leur réutilisation.

b. Terminologie de la pratique

Actif de service

Un actif de service est un composant qui contribue à la fourniture d’un ou plusieurs services et qui a une valeur financière. En anglais, on appelle cela un asset

Il ne faut pas confondre actif de service avec élément de configuration (CI). Les CI sont gérés par la pratique gestion des configurations.

Types d’actifs de services

Les types d’actifs de services couvrent tous les composants du système d’information, c’est-à-dire :

  • Les composants matériels, par exemple serveurs, postes de travail, baies disques, périphériques, etc.

  • Les composants logiciels, par exemple systèmes...

La pratique validation et tests

1. Généralités

a. Les objectifs

Cette pratique a pour mission de définir, de mettre en œuvre et de dérouler les campagnes de tests d’intégration et les procédures de validation.

Elle est en charge de fournir des preuves objectives du bon fonctionnement et du bon niveau de qualité de service du changement que l’on veut mettre en production (unité de production). Le gestionnaire de la validation et des tests est garant de la bonne gestion des réserves soulevées lors des campagnes de tests.

La phase de validation donnera lieu à l’élaboration de procès-verbaux de recette : recette fonctionnelle, recette de performance, recette d’exploitabilité, recette de service régulier. Le client (le donneur d’ordres) participe aux recettes fonctionnelles et de performance, l’exploitation participe à la recette d’exploitabilité et les représentants des utilisateurs participent à la recette de service régulier.

b. Les acteurs

Dans les grandes structures, des équipes dédiées sont en charge de la validation et des tests. Les membres de ces équipes doivent être indépendants des développeurs, des personnes chargées de la mise en production et des exploitants. C’est un nouveau métier de l’informatique :...