Académique Documents
Professionnel Documents
Culture Documents
A propos du document
Ce document de référence sur le référentiel ITIL V3 a été réalisé en se basant directement sur les 5
livres ITIL de la version 3 : Service Strategy, Service Design, Service Transition, Service Operation et
Continual Service Improvement parus en 2007.
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
2
Sommaire
1 Introduction .................................................................................................................................................... 4
1.1 Définir un service.................................................................................................................................... 4
1.2 Utilité et garantie d’un service ................................................................................................................. 5
2 Politique : Définir et implanter une politique formelle de transition des services............................................... 5
3 Politique : Implanter tous les changements sur les services au travers de la transition des services................ 6
4 Politique : Adopter standards et cadre communs ............................................................................................ 6
5 Politique : Maximiser le potentiel de réutilisation des processus et systèmes en place .................................... 7
6 Politique : Aligner les plans de la transition des services avec les besoins des affaires ................................... 7
7 Politique : Etablir et maintenir la communication avec toutes les parties prenantes ......................................... 8
8 Politique : Mettre en place des contrôles et des disciplines efficaces .............................................................. 8
9 Politique : Mettre en place des systèmes pour le transfert de connaissances et la prise de décision ............... 9
10 Politique : Elaborer les packages d’installation et planifier leur déploiement .............................................. 10
11 Politique : Anticiper et gérer les écarts de trajectoire ................................................................................. 10
12 Politique : Gérer les ressources de manière pro-active tout au long des transitions ................................... 11
13 Politique : Vérifier le plus tôt possible l’apport réel de valeur d’un changement.......................................... 11
14 Politique : S’assurer de la qualité du futur service : exploitabilité et atteinte des niveaux de service convenus
12
15 Politique : Améliorer de manière pro-active la qualité d’un futur service tout au long de sa transition ......... 12
3
1 Introduction
La stratégie des services définit les principes de base de la transition des services avec les notions-clés de compréhension
d’un service et et de la manière dont il délivre de la valeur aux affaires (résultats des organisations clientes).
Les ressources sont des actifs tangibles et intangibles qui sont possédés ou contrôlés par le fournisseur de services ou
l’organisation. Ces ressources et l’utilisation de ces ressources seront converties au final en produits et services qui seront
utilisés par les clients.
Les ressources seront transformées en services en utilisant des connaissances, de l’expérience, des processus, une
organisation et une direction qui composent eux-mêmes une catégorie particulière d’actifs appelés aptitudes.
Le terme actifs est utilisé dans ITIL pour citer ressources ou aptitudes, ou les deux selon le contexte dans lequel il est cité.
Les services sont un moyen de fournir une valeur ajoutée aux clients comme le montre la figure suivante :
4
La valeur ajoutée des services aux organisations d’affaires est ce qu’apporte l’utilisation de ces services par rapport à la
situation où les organisations d’affaires se débrouilleraient seule sans fournisseur de services.
Elle a deux composantes : l’accroissement de performance des organisations d’affaires et la réduction des risques sur cette
même performance.
En contrepartie de ces services, les organisations d’affaires vont fournir une compensation au fournisseur de services (de
manière concrète, les résultats financiers des affaires réalisées par les organisations clientes permettent de financer les
budgets de l’organisation informatique).
Dire qu’il y a un retour positif sur "investissement" consiste à avoir une valeur ajoutée des services supérieure à la
compensation versée au fournisseur.
Alignement de cette politique avec la gouvernance, l’organisation et les politiques générales de gestion des services
5
Les sponsors et décideurs impliqués dans la conception de cette politique doivent démontrer leur volonté de mettre en
oeuvre cette dernière. Cela inclut l’engagement de délivrer les résultats attendus de tout changement sur les
services.
Utilisation de processus qui intègrent les équipes, mixent les compétences tout en maintenant des frontières claires sur
autorités et responsabilités.
Délivrer les changements sous la forme de packages d’installation (en clair : refuser toute intervention en production
qui ne sera pas reproductible en cas de besoin)
Impliquer tôt les équipes de déploiement dans les étapes de conception du package d’installation et de planification du
déploiement
Les personnes qui n’ont pas autorité pour réaliser un changement ou déployer un package d’installation en production
ne devraient pas avoir accès à l’environnement de production.
La proximité avec les équipes d’exploitation (en clair : connaître les personnes et leur travail) facilite la motivation et
facilite les évolutions de l’organisation.
Chaque package d’installation doit être conçu et suivi par une demande de changement (Request for Change) au
travers du processus de gestion des changements pour s’assurer d’un contrôle et d’une traçabilité efficaces.
Des procédures et méthodes standardisées sont utilisées pour une prise en charge rapide et efficace de tous les
changements, dans le but de minimiser l’impact des incidents consécutifs à un changement sur la continuité des
affaires, la qualité de service et le travail de correction.
Toutes les mises à jour des changements et déploiements sont enregistrées et associées dans le système de gestion
des configurations (CMS ou Configuration Management System) aux actifs de services et items de configuration.
6
Utiliser les meilleures pratiques de l’industrie comme base de standardisation afin de permettre l’intégration au travers
de la chaîne d’approvisionnement (des services).
Contrôler le cadre global de fonctionnement de la transition des services via la gestion des changements et des
configurations (en clair : le processus de gestion des changements pilote l’ensemble des étapes de la transition des
services pour chaque changement et les indicateurs de performance de ces deux processus permettent de
contrôler l’efficacité du cadre global).
S’assurer que les processus sont adoptés et continuent à être respectés en planifiant régulièrement des revues et
audits des processus de la gestion des services.
Parmi les meilleures pratiques, il est possible de citer celles-ci :
Intégrer dans les processus la vérification et l’évaluation d’un service et de son profil de risque avant et après
déploiement d’un package d’installation.
Mettre en place des systèmes supportant et automatisant les processus définis afin de réduire la résistance à
l’adoption des nouvelles règles.
S’assurer que la hiérarchie comprenne la nécessité de travailler avec des règles standards basées sur une réelle
justification métiers et affaires.
la conception de modèles pouvant être déclinés facilement pour s’adapter à des circonstances spécifiques
En se basant sur des expériences concrètes, on aboutit rapidement à l’élaboration d’un modèle générique de processus de
gestion des changements qui va ensuite se décliner en variantes, appelées modèles de changement dans le référentiel ITIL.
L’intérêt de procéder en deux niveaux est la conservation d’une cohérence d’ensemble de la gestion d’un changement, quel
que soit sa nature et son type (de la correction applicative aux projets applicatifs et d’infrastructure). Lors de l’apparition d’un
nouveau type de changement à gérer, le modèle générique sera décliné en une version supplémentaire sans qu’il faille refaire
une conception complète de processus (coûteux et avec un risque d’incohérence avec les autres modèles de processus).
Enfin, il est à noter que l’adoption d’un modèle générique permet de sortir des tableaux de bord (tendances des indicateurs de
performance du processus) globaux et cohérents sur l’ensemble des changements, du plus petit au plus grand.
7
Fournir des informations et prévoir dans les processus la synchronisation des projets des organisations clientes avec
les déploiements de packages d’installation
S’assurer que le service peut être utilisé conformément aux exigences et contraintes exprimées initialement de
manière à améliorer la satisfaction des clients et de toutes les parties prenantes
Superviser et mesurer l’utilisation des services ainsi que l’utilisation des applications et solutions techniques durant le
déploiement et le support du début de vie pour s’assurer que tout va bien avant la clôture du changement
Comparer la performance réelle des services mis en place avec les performances prévues au moment de la
conception de chaque service et prendre toute action corrective si besoin
Parmi les meilleures pratiques, il est possible de citer :
l’adoption des meilleures pratiques en matière de gestion de programmes et de projets pour planifier et piloter les
ressources nécessaires afin d’intégrer les composants développés, créer un package d’installation, le tester et le
déployer avec succès en production dans les coûts, qualité et délais prévus
Communiquer les changements vers les parties prenantes afin d’améliorer leur compréhension et leur connaissance
sur le futur service
Fournir des informations et de la connaissance de bonne qualité pour que tous les intervenants aient accès aux
informations sur la transition du service (plans de livraison du package d’installation et du déploiement,
documentations livrées avec le package)
Automatiser les opérations d’audit des environnements, quand cela apporte un plus, dans l’idée de détecter le plus
possible les changements non autorisés et les écarts dans les configurations.
Définir clairement "qui fait quoi, quand et où" sur toutes les activités de passage de témoin (d’une équipe à une autre)
afin de pouvoir le plus possible rendre compte de ce qui est livré par rapport à ce qui a été prévu dans les plans et
les processus.
8
Définir et communiquer rôles et responsabilités lors des passages de témoin et des périodes de tests (acceptance)
associés aux activités de la transition des services (c’est-à-dire la construction, les tests, le déploiement) afin de
réduire les erreurs résultant d’incompréhensions et de méconnaissances.
Mettre en place des processus basés sur des procédures pour la gestion des configurations, des changements et des
problèmes pour faciliter les audits et collecter les informations de gestion nécessaires à l’amélioration des contrôles.
Les principes sont basés sur une focalisation sur la rédaction des documentations et sur l’accès facile aux informations et
documentations par les bonnes personnes et au bon moment :
Fournir données, informations et connaissances de bonne qualité et au bon moment aux bonnes personnes afin de
minimiser le temps perdu à attendre les décisions (des personnes qui ne sont pas prévenues ou qui recherchent les
informations pour prendre la décision).
S’assurer de formations et de transferts de connaissances vers les utilisateurs afin de réduire le nombre d’appels au
centre de services qui se transforment en formations par téléphone.
Améliorer la qualité des données et des informations afin d’augmenter la satisfaction de toutes les parties prenantes
tout en optimisant les coûts d’exploitation et de maintenance.
Améliorer la qualité de la documentation afin de réduire le nombre d’incidents et de problèmes causés par une
mauvaise qualité des documentations d’utilisation, d’installation, de support et d’exploitation.
Mettre en place un accès facile et rapide aux informations afin de réduire le temps perdu à chercher les informations
nécessaires à ses activités, particulièrement durant des périodes critiques comme la résolution d’un incident majeur.
Etablir une source unique et officielle des informations et la faire partager tout au long du cycle de vie des services
avec l’ensemble des parties prenantes afin d’augmenter la qualité des informations tout en minimisant la surcharge
de travail pour maintenir ces informations.
Fournir des informations consolidées pour permettre à la gestion des changements et des mises en production de
prendre des décisions pertinentes en faisant progresser un package d’installation au travers des différents
environnements de tests vers l’environnement de production.
Parmi les meileures pratiques, il est possible de citer :
Fournir des interfaces et des outils de qualité pour accéder aux systèmes de gestion des connaissances (SKMS =
Service Knowledge Management System) et des configurations (CMS = Configuration Management System) aux
différents intervenants et rôles pour permettre les bonnes décisions au bon moment.
9
S’assurer que les informations de la gestion des configurations et des actifs de service sont gérées par des
notifications d’approbation et des transactions formalisées au travers d’outils de flux de travail (workflow tools)
L’utilisation des ressources est optimisée dans les activités de la transition des services afin de réduire les coûts.
Les mécanismes de distribution et d’installation sont prévus pour garantir l’intégrité des composants pendant les
étapes de livraison, de construction et de manipulation du package d’installation et d’installation en production.
Les déploiements urgents sont tous gérés au travers de la procédure de gestion des changements urgents.
Les risques de retour arrière ou de rattrapage d’une installation en erreur sont évalués et gérés.
Les taux de succès et d’erreur des packages d’installation sont mesurés dans l’objectif d’améliorer efficacité et
efficience tout en optimisant les coûts.
Parmi les meilleures pratiques, il est possible de citer :
Les versions définitives (programmes, fichiers, documentations) sont livrées dans la bibliothèque des supports définitifs
(DML = Definitive Media Library) préalablement à l’installation en environnement de test de la production (appelé
parfois environnement de pré-production).
Les pré-requis et co-requis d’une mise en production (éléments préalables à l’installation et au fonctionnement de la
mise en production : ceux indépendants du changement et ceux installés auparavant dans le cadre du même
changement) sont documentés et communiqués aux parties concernées (par ex. les pré-requis techniques d’un
environnement de tests pour y dérouler un plan de tests).
En effet, la transition d’un changement peut être comparée à un voyage. Pour réussir son voyage, il faut non seulement bien le
préparer mais aussi, pendant le voyage, être attentif aux conditions que l’on rencontre et adapter son voyage, certains
facteurs, bien que prévisibles, ne sont pas sûrs à 100%, comme la météo par exemple.
Ainsi, il faut être capable de s’adapter aux conditions rencontrées tout en se tenant aux points essentiels de ce qui était prévu.
Les principes en sont les suivants :
Faire comprendre aux parties prenantes que la modification des plans (calendrier, réponse fonctionnelle, coûts, etc.)
est nécessaire en cas de besoin et que cette attitude est encouragée.
10
Capitaliser les expériences passées sur les corrections de plans passés afin d’en intégrer les causes dans les futurs
plans et de réutiliser des approches qui ont fonctionné.
Expliciter les écarts, ce qui a fonctionné et ce qui n’a pas marché dans les réunions de bilan avant la clôture d’un
changement, communiquer ce savoir aux acteurs et le déposer dans le systéme de gestion des connaissances des
services (SKMS = Service Knowledge Management System).
Prévoir et gérer les corrections de trajectoire eux-mêmes par les processus et procédures de la gestion des
changements.
Parmi les meilleures pratiques, il est possible de citer :
Utiliser les pratiques de gestion de projet et le processus de gestion des changements pour gérer la corrections des
écarts.
Eviter un processus de gestion des changements bureaucratique : il doit être plus facile de respecter le processus
plutôt que de s’en passer avec toutes les conséquences que pourrait entraîner un changement non autorisé.
Mettre en place des ressources dédiées pour traiter les activités critiques et ainsi réduire les délais.
Identifier les changements qui ne délivreront pas les bénéfices attendus et, soit modifier les exigences du service
(demande initiale) soit stopper le changement avant que trop de ressources ne soient gaspillées (la décision
d’arrêter un changement en cours de traitement est difficile et douloureuse à prendre mais elle fait partie du
processus de gestion des changements).
Parmi les meilleures pratiques, il est possible de citer :
Impliquer les clients ou les représentants des clients dans l’élaboration et la planification des tests pour comprendre la
manière de vérifier l’apport de valeur d’un service fourni aux services et processus d’affaires des clients.
Impliquer aussi les utilisateurs dans l’élaboration et la planification des tests le plus possible : il faut plus baser les tests
sur la manière dont les utilisateurs travaillent aujourd’hui plutôt que sur la manière d’utiliser le service imaginée par
les concepteurs.
11
14 Politique : S’assurer de la qualité du futur service : exploitabilité et
atteinte des niveaux de service convenus
Vérifier et valider que le changement défini dans le dossier de conception d’un service ("package de conception d’un
service" ou SDP = Service Design Package) et proposé aux équipes d’exploitation peut délivrer les exigences de
service et de niveaux de service et satisfaire les besoins d’affaires.
Les principes en sont les suivants :
L’assurance qualité et les techniques de tests fournissent des méthodes pour s’assurer de la qualité et des risques
d’un futur service.
Les environnements de tests doivent refléter le plus possible l’environnement de production tout en optimisant les
efforts de test.
La conception et l’exécution des tests devraient être gérés et réalisés indépendamment des équipes de conception et
de développement afin d’accroître l’efficacité des tests et de respecter le principe de séparation des pouvoirs.
Réaliser des évaluations indépendantes de la conception des services et du futur service afin d’identifier les risques
devant être gérés et atténués pendant les étapes de construction, de tests et déploiement et la phase d’exploitation
du futur service (le processus "Evaluation" permet d’affiner le traitement de chaque changement afin de maximiser
la probabilité que le service soit validé, notamment au travers des différents plans de tests à réaliser et au suivi des
risques spécifiques du changement).
Parmi les meilleures pratiques, il est possible de citer :
Connaître les différences entre environnements de construction (ou d’intégration), de tests et de production de manière
à prévoir le comportement du futur service en production à partir de son comportement dans ces environnements
(en clair : il faut être sûr que, si le service se comporte correctement dans un environnement de test, des différences
entre ce dernier et l’environnement de production ne vont pas induire un comportement différent en production).
Les environnements de tests doivent eux-mêmes être gérés par les processus de gestion des changements et des
configurations et leurs adaptations éventuelles pour tester un futur service font aussi partie du changement (en clair
: les installations et modifications des environnements de tests, comme les jeux de données ou le paramétrage des
pré-requis sont des activités des processus de transition des services et doivent donc être modélisées dans les
processus).
Gérer de manière pro-active et réduire le nombre d’incidents, de problèmes et d’erreurs détectés dans la phase de
transition afin de réduire les coûts, le travail de correction et l’impact sur les activités d’affaires des utilisateurs (en
clair : améliorer la qualité des processus de transition et la stabilité des environnements de transition afin
d’améliorer l’efficacité et l’efficience du traitement d’un changement).
Aligner la gestion des incidents, des problèmes et des erreurs pendant la transition des services avec les processus en
production de manière à mesurer et à gérer aisément l’impact des erreurs durant le cycle complet des services (en
clair : cela permet de comparer les délais et les coûts de traitement d’une erreur et de quantifier le gain de la
détection et correction d’une erreur en fonction de la phase, conception, développement, tests, etc. par rapport à
une détection en production).
12
Parmi les meilleures pratiques, il est possible de citer :
Comparer les aptitudes, performances et coûts prévus et réels d’un service pendant les phases pilotes et le début de
vie du service de manière à identifier toute déviation et risque pouvant être corrigé ou atténué avant la clôture du
changement.
Réaliser une évaluation indépendante du futur service pour identifier le profil de risque et établir des priorités sur les
risques devant être impérativement traités avant la clôture du changement, c’est-à-dire les risques de sécurité
pouvant avoir un impact sur la garantie du service.
Utiliser le profil de risque établi par l’évaluation pour développer des tests spécifiques sur ces risques.
Définir et tester les outils de diagnostic et d’aide en collaboration avec le centre de services et les équipes
d’exploitation et de support de manière à faciliter leur travail si quelque chose se passe mal en production avec le
futur service.
Encourager les échanges d’informations et d’expérience entre les intervenants en phases de transition et d’exploitation
afin d’améliorer le diagnostic des problèmes et leur délai de résolution, c’est-à-dire les solutions de contournement
et solutions définitives.
Mettre en place des procédures et des mesures de traitement des incidents, problèmes et erreurs en phase de
transition qui reflètent celles utilisées en production (en clair : il faut aussi industrialiser et procédurer la gestion des
incidents, problèmes et erreurs survenant dans les environnements de transition, comme l’intégration ou les tests).
Documenter toute résolution effectuée en phase de transition pour utilisation ultérieure éventuelle.
Enregistrer, classer et mesurer le nombre et l’impact des incidents et problèmes à chaque phase du cycle de vie des
services (tests, déploiement, production) afin d’identifier des opportunités d’identification et de résolution plus
précoces que ce qui est fait actuellement.
Comparer le nombre et l’impact des incidents et problèmes entre les déploiements de manière à détecter des
initiatives d’amélioration et fixer tout problème dans la gestion de la conception et de la transition (par ex. évaluation
des risques, tests, déploiement) qui amélioreront l’expérience des équipes dans les futurs déploiements.
Mettre à jour les bases d’informations d’incidents et de problèmes avec les solutions de contournement et solutions
définitives identifiées en phase de transition du futur service.
13