ITIL Gestion des mises en production Mode d'emploi

ITIL V2

La gestion des mises en production

Création : novembre 2004

Mise à jour : août 2009

A propos

A propos du document

Ce document de référence sur le référentiel ITIL a été réalisé en 2004 et la traduction des 2 livres ITIL

Service Support et Service Delivery a nécessité 4 mois de traduction et d

écriture.

Il est mis à la disposition de la communauté francophone ITIL pour diffuser les connaissances de base sur ce référentiel.

Ce document peut être utilisé de manière libre à condition de citer le nom du site (www.itilfrance.com) ou le nom de l auteur (Pascal Delbrayelle).

A propos de l'auteur

Pascal Delbrayelle intervient avec plus de 25 ans d'expérience comme consultant sur les projets d'une direction informatique ayant comme facteur de succès la mise en oeuvre des bonnes pratiques ITIL comme, par exemple, la mise en place d'un site de secours, la mise en place d'un outil de gestion des configurations ou la définition des normes et standards techniques des environnements de production.

Ces projets requièrent :

 la connaissance des différents métiers du développement et de la production informatique

 la pratique de la conduite de projets techniques de la direction informatique

 la maîtrise de la définition et de la mise en place de processus pour rationaliser et adapter les méthodes de travail au sein de la direction informatique

A propos de mission et de formation

Si vous pensez que l expérience de l auteur sur le référentiel ITIL ou la formalisation de documents sur le sujet peut vous aider dans vos projets de production ou de mise en oeuvre des processus ITIL, n hésitez pas à le contacter pour toute question ou demande :

 par mail : pascal.delbrayelle@itilfrance.com

 par téléphone : +33 (0)6 61 95 41 40

Quelques exemples de mission :

 Modélisation simple des processus de gestion des changements, des projets et des mises en production en vue de la sélection, l'achat et l'implantation d'un outil de gestion de projets avec planification, gestion des ressources, des budgets, des livrables et des connaissances



Accompagnement avec la réorganisation d'un DSI passant d'une organisation en silos techniques vers une organisation inspirée du référentiel ITIL et la mise en oeuvre d'outils pour institutionnaliser les processus ITIL



Accompagnement d'une DSI dans la formulation de l'appel d'offres au futur centre de services en se basant sur les processus et la fonction centre de services du référentiel ITIL

2

Sommaire

1 Objectif .......................................................................................................................................................... 5

1.1 Objectif ................................................................................................................................................... 5

1.2 Objectifs détaillés ................................................................................................................................... 5

2 Périmètre ....................................................................................................................................................... 5

2.1 Périmètre ............................................................................................................................................... 5

2.2 Changements contrôlés par le processus ............................................................................................... 5

2.3 Tous les livrables nécessitent d’être suivis .............................................................................................. 6

2.4 La Gestion des Mises en Production recommandée pour ........................................................................ 6

2.5 Activités et cycle de vie d’un Changement .............................................................................................. 6

3 Concepts de base .......................................................................................................................................... 6

3.1 Distribution ............................................................................................................................................. 6

3.2 Politique et préparation des Mises en Production .................................................................................... 7

3.3 Unité de Distribution ............................................................................................................................... 7

3.4 Déploiements ......................................................................................................................................... 7

3.5 Elaboration et configuration de la Distribution (Intégration) ...................................................................... 7

3.6 Homologation de la Distribution .............................................................................................................. 7

3.7 Scénarios de retour arrière ..................................................................................................................... 8

4 Bénéfices et problèmes possibles .................................................................................................................. 8

4.1 Quelques bénéfices d’une gestion combinée des Changements, des Mises en Production et des

Configurations .................................................................................................................................................... 8

4.2 Problèmes potentiels .............................................................................................................................. 8

5 Politique sur les Distributions et les Déploiements .......................................................................................... 9

5.1 Documentation préalable à la mise en place du processus ..................................................................... 9

5.2 Documentation sur le Déploiement des Distributions ............................................................................... 9

5.3 Procédures sur le Déploiement en production ......................................................................................... 9

5.4 Procédures sur les retours arrière ......................................................................................................... 10

5.5 Rôles et responsabilités dans le processus ........................................................................................... 10

6 Activités ....................................................................................................................................................... 10

6.1 Phase de préparation ........................................................................................................................... 10

6.2 Phase d’intégration ............................................................................................................................... 11

6.3 Phase d’homologation et d’acceptation ................................................................................................. 11

6.4 Phase de Déploiement ......................................................................................................................... 12

6.4.1 Le Déploiement par phases .......................................................................................................... 12

7 Métriques et indicateurs de performance ....................................................................................................... 13

7.1 Indicateurs de performance .................................................................................................................. 13

7.2 Métriques ............................................................................................................................................. 13

8 Interactions avec les autres processus .......................................................................................................... 13

8.1 Gestion des Configurations ................................................................................................................... 13

8.2 Gestion des Changements ................................................................................................................... 13

3

8.3 Logiciels livrés par les Etudes et les fournisseurs tiers .......................................................................... 13

8.4 Gestion des Problèmes et Centre de Services ...................................................................................... 14

4

1 Objectif

1.1 Objectif

Protéger l’environnement de production et ses services par l’utilisation de procédures formelles et par des

vérifications lors de l’implémentation des Changements

Les Changements sont intégrés dans les Distributions (Release) et implémentés en production par les Déploiements

(Release)

Il est recommandé une étroite collaboration avec la Gestion des Changements et la Gestion des Configurations pour s’assurer que :

 la CMDB est à jour des Changements implémentés par les Déploiements

 le contenu de ces Déploiements est intégré dans la DSL (Definitive Software Library)

La Gestion des Mises en Production est souvent budgétée par les grands projets plutôt que d’être intégrée dans les coûts d’exploitation courants

1.2 Objectifs détaillés

 planifier et superviser le Déploiement d’un logiciel et du matériel associé



élaborer et implémenter les outils de distribution et d’installation des Changements

 de s’assurer que les matériels et logiciels changés sont traçables, sûrs et que seules les versions correctes, autorisées et testées sont installées

 de communiquer et de gérer les attentes des Clients pendant la planification et le déroulement des déploiements

 de valider le contenu exact d’une Distribution et le scénario de Déploiement en liaison avec la Gestion des

Changements

 d’installer les nouvelles versions logicielles et les matériels en production en respectant les procédures de la Gestion des Changements et des Configurations

 de s’assurer que les distributions d’origine de tous les logiciels sont stockées et sécurisées dans la Bibliothèque des

Versions Logicielles Définitives (Definitive Software Library ou DSL) et que la CMDB est mise à jour

2 Périmètre

2.1 Périmètre

 planification, conception, élaboration, configuration et homologation des matériels et logiciels pour créer un ensemble de composants destiné à être déployé en production (kit d’installation ou de déploiement)

 planification et préparation du Déploiement d’un Changement à un ensemble d’Utilisateurs et de sites

 communication, préparation et formation à un Changement

 audits matériels et logiciels avant et après l’implémentation d’un Changement

 déploiements des Changements

 mise à jour de la CMDB et de la DSL

2.2 Changements contrôlés par le processus

 applications développées en interne

 logiciels externes (logiciels standards du marché ou développements spécifiques par des sociétés tierces)

 logiciels utilitaires

 logiciels systèmes

 matériels et spécifications matérielles

5

 manuels d’installation et utilisateur

2.3 Tous les livrables nécessitent d’être suivis

1. développement ou achat

2. adaptation et configuration

3. homologation et implémentation

4. exploitation dans l’environnement de production

2.4 La Gestion des Mises en Production recommandée pour

 mise en place importante ou critique de matériels (surtout si impact sur les logiciels et applications)

 donc exclu : installation d’un nouveau poste de travail

 mise en place importante d’une première version ou d’une nouvelle version d’application

 regroupement d’un ensemble de Changements dans des Déploiements de taille acceptable

2.5 Activités et cycle de vie d’un Changement

3 Concepts de base

3.1 Distribution

Ce terme désigne une collection de Changements autorisés sur l’infrastructure (corrections de problèmes et améliorations fonctionnelles)

La Distribution inclut le code logiciel et toute nouveauté et mise à jour matérielle pré-requise

Généralement, on distingue trois catégories :

1. Distributions logicielles majeures et mises à jour matérielles

 contient : ajouts fonctionnels importants, quelques correctifs

 normalement, annule et remplace tous les Distributions antérieures : mises à jour mineures, Distributions, correctifs urgents

2. Distributions logicielles mineures et mises à jour matérielles

 contient : quelques ajouts ou modifications fonctionnelles mineures, des correctifs

 normalement, annule et remplace tous les correctifs urgents passés depuis la dernière Distribution majeure ou mineure

3. Correctifs urgents logiciels et matériels

6

 contient la correction d’un petit nombre de Problèmes connus

3.2 Politique et préparation des Mises en Production

La politique des Mises en Production couvre :

 la numérotation des versions (numéro unique gérée ensuite par la Gestion des Configurations),

 la fréquence des Déploiements en production (dépend de la taille et du nombre de systèmes, des contraintes utilisateurs et métiers),

 le niveau de contrôle sur le détail de l’infrastructure au-dessus duquel il est nécessaire de gérer des Déploiements



Elle permet de préciser strictement les cas de Déploiements de correctifs urgents et de reporter les autres correctifs dans des Déploiements programmés et planifiés à l’avance (verrouiller toutes les possibilités de contourner)

3.3 Unité de Distribution

Il s'agit d'un ensemble d’Items de Configuration (éléments de l’infrastructure) qui ne peuvent être mis à jour qu’ensemble (pour des raisons pratiques et d’efficacité)

Si un Item de Configuration est impacté par un Changement, alors la Distribution correspondante contiendra tous les items de l’Unité de Distribution

Par exemple :

 une application complète (même si un seul programme est modifié),

 ou un programme de l’application (quelle que soit la correction, modification ou ajout apporté)

3.4 Déploiements

On distingue trois catégories de Déploiements :

1. Déploiement complet (full Release)



Tous les composants d’une Unité de Distribution sont reconstruits, homologués, distribués et installés en même temps



Plus consommateur de temps qu’un Déploiement delta (delta Release) ... en théorie



Les tests de non-régression concerne l’ensemble des composants (re)déployés

2. Déploiement delta (delta Release)

 Seuls les composants concernés par la Distribution sont déployés (modifiés ou nouveaux).



Exemple : un programme d’une application considérée comme une Unité de Distribution

 Plus rapide à déployer mais attention aux risques

3. Déploiement groupé (package Release)

S’il est possible de différer des Déploiements (complets ou partiels) sans perturbation significative de la production, il est recommandé de grouper ces Déploiements dans un seul appelé alors Déploiement groupé.

Le Déploiement groupé est aussi à utiliser lorsque plusieurs Déploiements complets ou partiels doivent être réalisés en même temps.

Par exemple : afin d’être sûr que tous les correctifs urgents déployés sur l’infrastructure par un outil de déploiement d’urgence soient bien déployés partout, un Déploiement groupé reprend tous ces correctifs urgents pour les redéployer sur l’infrastructure

(DIPATCH pour DIstribution de PATCHes)

La fréquence de ces régularisations est de une par mois

Il faut cependant faire attention à la taille du Déploiement groupé

3.5 Elaboration et configuration de la Distribution (Intégration)

La construction d’une Distribution doit respecter des procédures et doit être automatisée si possible

Elle comprend aussi les composants matériels

3.6 Homologation de la Distribution

7

Elle peut comprendre l’homologation fonctionnelle, l’homologation technique de l’application, l’homologation de l’intégration et les tests de performances

Ces homologations se font en relation avec la Gestion des Changements

3.7 Scénarios de retour arrière

Ils devraient être établis pour documenter la restauration de l’état précédent en cas d’échec du Déploiement

Le partage des responsabilités est le suivant :



Gestion des Changements : Chaque Changement devrait avoir son scénario de retour arrière



Gestion des Mises en Production : un Déploiement de retour arrière doit cumuler les scénarios de retour arrière de tous les Changements implémentés par une Distribution

Deux approches existent (à combiner éventuellement) :

 complète réversibilité d’un Déploiement (retour exact à l’état précédent) : critique pour un Déploiement complet et préférable pour un Déploiement delta

 mesures partielles à envisager si la réversibilité n’est pas pratique ou impossible à réaliser

4 Bénéfices et problèmes possibles

4.1 Quelques bénéfices d’une gestion combinée des Changements, des

Mises en Production et des Configurations

 taux de réussite plus important dans les Déploiements

 diminution du risque d’incompatibilité entre composants lors de Changements importants sur l’infrastructure

 assurance que les logiciels et matériels en production sont connus et de qualité

 meilleure stabilité de l’environnement de production car l’utilisation de Distributions diminue le nombre de mises en production

 meilleure utilisation des ressources Utilisateurs pour tester (cohérence globale de l’ensemble des homologations)

 minimisation des tests de non-régression

 meilleure information à l’avance des Changements qui vont être déployés

 audit complet des Changements mis en place

 capacité pour absorber un taux important de Changements sur l’environnement de production sans impacter sur la qualité de service

 meilleure détection des mauvaises versions et des copies non autorisées des logiciels

 réduction des délais et temps de déploiement

 transitions plus douces entre les environnements de développement et l’environnement de production

4.2 Problèmes potentiels

 résistance initiale à la mise en place de nouveaux processus : campagne de sensibilisation à mener pour expliquer les avantages d’une Gestion des Mises en Production

 contournement possible de la Gestion des Mises en Production (« installations sauvages ») à surveiller

 utilisation possible de la procédure de Déploiement de correctif urgent pour installer des Distributions mineures voire majeures non urgentes

 résistance à passer par des environnements d’homologation (passage direct de l’environnement de développement vers l’environnement de production)

 meilleure approche d’installation sur des environnements distribués (synchronisation des installations)

 quelques personnes (y compris la hiérarchie) peuvent voir la Gestion des Mises en Production comme lourde et coûteuse. Néammoins, elle représente presque toujours le seul moyen de s’en sortir efficacement avec les

Changements logiciels

 absence de clarté dans les responsabilités et rôles dans le Déploiement entre les équipes de développement et de production

8

 ressources insuffisantes pour homologuer les distributions ou trop de variantes en production pour pouvoir toutes les tester

 plates-formes d’homologation pas assez puissantes augmentant les temps d’élaboration et d’homologation des

Distributions

 plates-formes d’homologation non représentatives de l’environnement de production (tests incomplets)

5 Politique sur les Distributions et les Déploiements

5.1 Documentation préalable à la mise en place du processus

Un document de politique sur les Distributions et les Déploiements devrait être produit et contenir :

 un guide sur le niveau de granularité des Distributions (Unités de Distribution) : par exemple, application complète, module ou programme

 des conventions de nommage des Distributions et de numérotation des Versions

 des définitions des Distributions majeures et mineures et une politique sur la gestion des correctifs urgents

 des indications générales sur la fréquence des Distributions majeures et mineures

 l’identification des périodes de neutralisation, par exemple : o la semaine précédent l’arrêté comptable mensuel pour les applications comptables o du 15/12 au 15/01 pour toutes les applications impliquées dans les bilans annuels

 les livrables attendus pour chaque type de Distribution, par exemple : o manuel d’installation o notes de mise à jour (Release notes)

 une politique sur les retours arrière en production et leurs tests en homologation

 les responsabilités de l’équipe chargée des Distributions et des Déploiements dans les comités techniques sur l’architecture des applications

 une description du processus de Gestion des Mises en Production

 une documentation sur la DSL et les critères d’acceptation de tout nouveau logiciel dans cette DSL

Ces points sont parfois intégrés dans un document plus général à destination des Maîtrises d’Oeuvre : les Normes

d’Exploitabilité des applications en production

5.2 Documentation sur le Déploiement des Distributions

Une documentation sur le Déploiement des Distributions en production devrait contenir :

 la copie/diffusion de la Distribution des environnements d’homologation/d’intégration vers la production (avec vérification de l’intégrité des kits copiés en production)

 pour une mise à jour : la sauvegarde de l’ancienne version, la migration des données vers la nouvelle version

 la désynchronisation dans certains cas de l’installation et de l’activation du logiciel :

 par exemple : activation générale à une date/heure précise (contraintes légales) ou activation après démarrage d’une application ou base de données centrale

 mécanisme de déclenchement de l’activation : central, inclus dans la Distribution elle-même, etc.

 mécanismes à tester impérativement en homologation

5.3 Procédures sur le Déploiement en production

 les scripts et paramétrages devraient être testés en homologation

 objectif : avoir des composants fiables dans la diffusion/installation/activation des logiciels en production (déploiement simple, infaillible et sécurisé au maximum)

 limiter les opérations locales au minimum (montage de bande, etc.)

 prendre impérativement en compte la vérification de la bonne installation/activation du logiciel après l’opération

9

 vérifier le bon état de fonctionnement de l’infrastructure de Déploiement avant une opération

5.4 Procédures sur les retours arrière

La Gestion des Changements nécessite un plan de retour arrière à chaque implémentation d’un Changement

Ces plans devraient être testés dans la phase d'homologation.

Parfois, il n’est pas possible de revenir en arrière en cas de problème (par exemple : contraintes calendaires légales rendant impossible l’utilisation des anciens programmes). Dans ce cas, il est recommandé d'avoir des procédures de minimisation du dysfonctionnement (retours arrière alternatifs) à tester également le plus possible.

5.5 Rôles et responsabilités dans le processus

Ils sont à définir à l’avance.

Les rôles les plus importants dans le processus sont :



Responsable des Changements (Change Manager)

 Responsable des Déploiements (Release Manager)



Responsable des Homologations (Test Manager)

Dans les installations standards, prédéfinies et approuvées, il n'est pas nécessaire de faire intervenir la Gestion des

Changements (exemple : installation d’un nouveau poste de travail) qui peut être initié par le Centre de Services

Voici des exemples de rôles et responsabilité dans le processus :

Nature du

Déploiement

Développement :

Livré par

Homologation :

Accepté par

Homologation :

Livré à la production par

Production :

<Accepté et supporté par

Nouveau logiciel externe

Chef de projet

Etudes

Nouvelle application interne

Chef de projet

Etudes

Modification Base de

Données

Chef de projet

Etudes

Responsable homologation

Responsable Changement Responsable Exploitation

Responsable

Homologation

Responsable Changement Responsable Exploitation

Gestionnaire

Base de données (DBA)

Responsable Changement Gestionnaire Base de données (DBA)

Serveur Ingénieur système Responsable

équipe système

Responsable Changement Responsable équipe système

Application existante sur PdT

Chef de projet

Etudes micro

Poste de travail Logistique

Responsable support micro

Support micro

Responsable support micro

Responsable Changement

Responsable support micro

Responsable support micro

Responsable Changement

Responsable support micro

6 Activités

6.1 Phase de préparation

Cette phase comporte les éléments suivants :

 définition et acceptation du contenu de la Distribution

 définition et acceptation de la méthode de Déploiement (par phases, par unités géographiques, etc.)

 production d’un calendrier détaillé du Déploiement

10

 audit pour vérifier les matériels et logiciels en production

 prévision des ressources (logistiques, humaines)

 acceptation des rôles et responsabilités de chaque équipe

 obtention des devis et négociations avec les fournisseurs pour l’achat de matériels, de logiciels et de services

 production des plans de retour arrière

 développement d’un Plan Qualité pour le Déploiement

 acceptation du calendrier par les équipes de support et les Utilisateurs

En entrée du processus, nous trouvons :

 cycle de vie du projet (Etudes)

 livrables attendus

 Demandes de Changement (RFCs ou Requests for Change) autorisées

 document sur la politique des Distributions et des Déploiements

 résumé des besoins métiers

 contraintes et dépendances du Déploiement

 Avis du CCC ou Comité Consultatif des Changements (CAB ou Change Advisory Board)

Cette phase produit un plan de tests détaillé et des critères d’acceptation de la Distribution pour Déploiement

6.2 Phase d’intégration

Il s'agit de l'élaboration, de la construction et de la configuration de la Distribution

Les éléments produits par cette phase sont :

 instructions d’assemblage et de construction de la Distribution

 bons de commande, licences et garanties pour les matériels et logiciels tiers

 scripts d’installation et plans de tests associés

 kit de la Distribution et manuel d’installation pour insertion dans la DSL

 procédures de retour arrière

6.3 Phase d’homologation et d’acceptation

L’homologation de la Distribution devrait être réalisée par des équipes indépendantes de celles des Etudes et de la Production impliquées dans le contenu de cette Distribution

Les procédures de retour arrière devraient en faire partie

Cette phase inclut à la fois des tests fonctionnels et des tests techniques (installation, performances, etc.)

Chaque homologation devrait produire un document de résultats

Voici quelques recommandations sur les environnements de tests :

 réinitialisables facilement

 le plus possible à l’image des environnements de production

Si un avis négatif est rendu sur la Distribution, la replanification devrait être à la charge de la Gestion des Changements

En sortie du processus, nous trouvons :

 composants validés de la Distribution

 procédures validées d’installation et de retour arrière

 défauts connus et acceptés qui vont être introduits en production avec la Distribution

 résultats des homologations

 documentation de support

 instructions d’exploitation et d’administration

 calendrier de formation pour les équipes de support et les Utilisateurs

11

 documents d’acceptation de la Distribution signés par toutes les parties

 autorisation d’implémenter la Distribution (au travers de la Gestion des Changements)

6.4 Phase de Déploiement

 production d’un calendrier détaillé des événements

 lister les Items de Configuration (CIs ou Configuration Items) à installer et à désinstaller ou démonter



édition d’un plan d’actions détaillé par site (en prenant en compte les décalages horaires pour un Déploiement world-

wide si besoin)

 production des notes de mise à jour et des communications aux Utilisateurs

 communication sur le calendrier de Déploiement

 acquisition des nouveaux matériels et logiciels avec leur référencement (étiquetage du matériel par exemple)

 planification des réunions de pilotage du Déploiement

Voici un exemple de politique de Déploiement sur des Postes de Travail :

6.4.1 Le Déploiement par phases

Les distributions peuvent être déployées en production :

 en une seule fois (« big bang »)

 en plusieurs passes (déploiement par phases)

Voici quelques exemples où il est nécessaire de déployer par phases :

 diffusion et installation de la Distribution par phases (car lourd et long) et activation en une seule fois (contrainte légale)

 implémentation graduelle du Changement par site (pour éviter les « explosions » au niveau des équipes de support)

 Changements sur le matériel à implémenter avant un Déploiement logiciel

Ces exemples peuvent évidemment être combinés

L’implémentation graduelle d’une nouvelle version applicative n’est possible que si l’environnement de production peut supporter d’exploiter simultanément deux versions différentes de la même application

Ceci est un exemple de ce qu’il est nécessaire de prendre en compte très tôt dans le cycle de vie de l’application (au moment du design)

Il est recommandé d'éviter de faire un Déploiement « big bang » mais de procéder graduellement :

 site(s) pilote(s) (1 ou 2 étapes sites alpha et beta)

12

 puis déploiement par phases sur le reste des sites

7 Métriques et indicateurs de performance

7.1 Indicateurs de performance

 distributions créées, testées et déployées dans les temps prévus et avec les budgets prévus (éviter le piège des retards de livraison par les Etudes)

 très peu (idéalement aucun) de retours arrière dûs à des erreurs non détectées en homologation (mais il est possible de déployer volontairement une Distribution contenant des erreurs)

 tous les composants de la DSL sont légaux et ont été validés

 les Distributions sont déployées partout où cela était prévu

 pas de retours non autorisés sur une version antérieure

 pas de licences logicielles utilisées illégalement

 pas de gaspillage en coûts de support (contrats, équipes) pour des logiciels non utilisés sur certains sites

7.2 Métriques

 nombre de Distributions majeures et mineures par période

 nombre de Problèmes liés à une mauvaise Distribution ou à un mauvais Déploiement (à mesurer les premiers mois) comme par exemple : « fichier manquant » ou « mauvaise version de fichier »

 nombre de composants nouveaux, modifiés et supprimés par une nouvelle Distribution

 nombre de Déploiements terminés dans les délais prévus (cela nécessite de publier avant Déploiement les délais prévus)

8 Interactions avec les autres processus

La Gestion des Mises en Production utilise les processus de contrôle de la Gestion des Configurations et de la

Gestion des Changements

8.1 Gestion des Configurations

 nouvelles versions logicielles insérées dans la DSL et changements sur les matériels : à intégrer dans la CMDB

 utilisation d’autres processus (audit des Configurations avant Déploiement)

 possibilité de confondre en une seule équipe la Gestion des Configurations et des Déploiements avec ou sans la

Gestion des Changements

8.2 Gestion des Changements

Le CCC ou Comité Consultatif des Changements (CAB ou Change Advisory Board) est responsable (sur les conseils de la

Gestion des Mises en Production) de faire des recommandations sur le contenu des Distributions et leur calendrier de

Déploiement

La Gestion des Mises en Production exécute ensuite ce qui a été décidé par le CCC

Même si la Gestion des Mises en Production supervise la mise en place des Changements, elle reste sous le contrôle et l’autorité de la Gestion des Changements

8.3 Logiciels livrés par les Etudes et les fournisseurs tiers

Lorsqu’une application interne ou tiers a été acceptée, la Gestion des Mises en Production l’insère dans la DSL et la référence dans la CMDB

La Gestion des Mises en Production est responsable de la fabrication de la Distribution (de la DSL vers les environnements d’homologation)

Une fois les tests concluants, la Gestion des Mises en Production devrait être responsable du Déploiement de la Distribution en production

13

8.4 Gestion des Problèmes et Centre de Services

A la fin d’un Déploiement correct d’une nouvelle Distribution (ITIL ne précise pas quand se situe ce moment : à la fin du

déploiement ou à la fin d’une période de vérification appelée quelquefois VSR ou Vérification de Service Régulier), il est nécessaire :

 de fermer les Problèmes et demandes d’améliorations correspondants

 d’ajouter les nouveaux Problèmes Connus apportés par la Distribution (le Centre de Services doit pouvoir effectuer le support de la nouvelle version)

 de former/d’informer la Gestion des Problèmes et le Centre de Services sur le contenu de la Distribution (et sur le

calendrier de Déploiement)

14