Itilv3 Conception Processus

8/18/2019 Itilv3 Conception Processus

1/24

ITIL V3

Les processus de la conception desservices

Création : juillet 2011Mise à jour : juillet 2011


2/24

2

A propos

A propos du document

Ce document de référence sur le référentiel ITIL V3 a été réalisé en se basantdirectement 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 lesconnaissances 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 surles projets d’une direction informatique ayant comme facteur de succès la mise enoeuvre des bonnes pratiques ITIL comme, par exemple, la mise en place d’un site desecours, la mise en place d’un outil de gestion des configurations ou la définition desnormes et standards techniques des environnements de production.

Ces projets requièrent :

la connaissance des différents métiers du développement et de la productioninformatique

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 rationaliseret 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 dedocuments sur le sujet peut vous aider dans vos projets de production ou de mise enoeuvre des processus ITIL, n’hésitez pas à le contacter pour toute question ou demande:

par mail : [email protected]

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’unoutil de gestion de projets avec planification, gestion des ressources, desbudgets, des livrables et des connaissances

Accompagnement avec la réorganisation d’un DSI passant d’une organisation ensilos techniques vers une organisation inspirée du référentiel ITIL et la mise enoeuvre d’outils pour institutionnaliser les processus ITIL

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


3/24

3

Sommaire

1 Gestion du catalogue de services ................................................................................................................... 61.1 Objectifs ................................................................................................................................................. 6

1.2 Activités principales ................................................................................................................................ 6

1.3 Les deux volets du catalogue de services ................................ ............................................................... 6

1.3.1 Le catalogue des services d’affaires ................................................................................................ 7

1.3.2 Le catalogue des services techniques ............................................................................................. 7

2 Gestion des niveaux de service ....................................................................................................................... 8

2.1 Objectifs ................................................................................................................................................. 8

2.1.1 Pour tous les services ..................................................................................................................... 8

2.1.2 Relations avec organisations d’affaires ........................................................................................... 82.1.3 Amélioration continue ..................................................................................................................... 8

2.2 Définitions clés ....................................................................................................................................... 8

2.2.1 Accord sur les niveaux de service (SLA ou Service Level Agreement ) ............................................. 9

2.2.2 Accord de niveau opérationnel (OLA ou Operational Level Agreement ) ........................................... 9

2.2.3 Contrat [de sous-traitance] (UC ou Underpinning Contract ) ............................................................. 9

2.3 Activités clés .......................................................................................................................................... 9

2.3.1 Pour tous les services ..................................................................................................................... 9

2.3.2 Relations avec organisations d’affaires ........................................................................................... 9

2.3.3 Amélioration continue ................................................................................................................... 102.4 Conception des cadres de SLA (accords de niveaux de service) ........................................................... 10

2.4.1 SLA orienté service ....................................................................................................................... 10

2.4.2 SLA orienté client .......................................................................................................................... 10

2.4.3 Une combinaison quelconque de ces deux approches .................................................................. 10

2.4.4 Une combinaison particulière de ces deux approches : les SLA multi-niveaux ............................... 11

2.5 Eléments en entrée et en sortie du processus ....................................................................................... 11

2.5.1 Eléments en entrée ....................................................................................................................... 11

2.5.2 Eléments en sortie ........................................................................................................................ 11

3 Gestion des fournisseurs .............................................................................................................................. 123.1 Buts ...................................................................................................................................................... 12

3.2 Objectifs principaux .............................................................................................................................. 12

4 Gestion de la capacité................................................................................................................................... 13

4.1 Principes du processus ......................................................................................................................... 13

4.1.1 But ................................................................................................................................................ 13

4.1.2 Objectifs ....................................................................................................................................... 13

4.1.3 Un exercice d’équilibrage .............................................................................................................. 13

4.1.4 Le livrable du processus : le plan de capacité ................................................................................ 13

4.1.5 La déclinaison en 3 processus ................................................................................................ ...... 144.2 Sous-processus et activités principales du processus ........................................................................... 15


4/24

4

4.2.1 Activités réactives ......................................................................................................................... 15

4.2.2 Activités pro-actives ...................................................................................................................... 15

4.2.3 Le sous-processus de gestion de la demande ............................................................................... 15

4.2.4 Le sous-processus de modélisation et d’identification des tendances ............................................ 16

4.2.5 Le sous-processus de dimensionnement des applications ............................................................. 16

5 Gestion de la disponbilité .............................................................................................................................. 17


5.1.1 But ................................................................................................................................................ 17

5.1.2 Objectifs ....................................................................................................................................... 17

5.1.3 La déclinaison en deux processus................................................................................................. 17

5.2 Définitions liées à la disponibilité................................ ........................................................................... 17

5.2.1 Disponibilité ( Availability ) .............................................................................................................. 17

5.2.2 Fiabilité (Reliability ) ....................................................................................................................... 17

5.2.3 Maintenabilité (Maintenability ) ....................................................................................................... 18

5.2.4 Agir sur la disponibilité : les deux leviers ....................................................................................... 18

5.2.5 Capacité de soutien extérieur (« Serviceability ») ou maintenabilité externe (« serviçabilité ») ....... 19

5.2.6 Résilience (Resilience).................................................................................................................. 19

5.3 Activités principales du processus ................................................................................................ ........ 19

5.3.1 Activités réactives ......................................................................................................................... 19

5.3.2 Activités pro-actives ...................................................................................................................... 19

6 Gestion de la sécurité de l’information ................................................................................................ ........... 20


6.1.1 But ................................................................................................................................................ 20

6.1.2 Qu’est-ce que l’information ? ................................ ......................................................................... 20

6.1.3 Objectifs ....................................................................................................................................... 20

6.1.4 Disponibilité de l’information .......................................................................................................... 20

6.1.5 Confidentialité ............................................................................................................................... 20

6.1.6 Intégrité de l’information ................................................................................................................ 20

6.1.7 Authenticité et non-répudiation de l’information ............................................................................. 20

6.1.8 Référentiel de sécurité .................................................................................................................. 20

6.2 Activités principales .............................................................................................................................. 21

7 Gestion de la continuité des services ............................................................................................................ 22


7.1.1 But ................................................................................................................................................ 22

7.1.2 Objectifs ....................................................................................................................................... 22

7.1.3 Périmètre ...................................................................................................................................... 22

7.2 Activités du processus .......................................................................................................................... 23

7.2.1 Lancement du projet ..................................................................................................................... 23

7.2.2 Etablissement des besoins et de la stratégie ................................................................................. 23

7.2.3 Mise en oeuvre ............................................................................................................................. 23

7.2.4 Exploitation courante .................................................................................................................... 24


5/24

5

7.2.5 Activation ...................................................................................................................................... 24


6/24

6

1 Gestion du catalogue de services

1.1 ObjectifsLes objectifs de la gestion du catalogue de services sont les suivants :

Fournir une source unique d’informations cohérentes pour tous les services convenus

S’assurer qu’un catalogue de services est produit et maintenu, contenant des informations fiablessur les services en production et ceux en préparation

Gérer les informations contenues dans le catalogue de services

S’assurer que les informations sont disponibles pour l’ensemble des personnes qui y ont un droitd’accès

1.2 Activités principales

Les activités principales de ce processus sont les suivantes : Convenir et documenter une définition de service

S’interfacer avec la gestion du portefeuille de services pour s’entendre sur les contenus duportefeuille et du catalogue de services

Produire et maintenir un catalogue de services en accord avec le portefeuille de services

S’interfacer avec les organisations d’affaires et la gestion de la continuité informatique sur lesservices de support décrits dans le catalogue

S’interfacer avec les équipes de support, les sous-traitants et la gestion des configurations sur lesliens entre services du catalogue et les actifs de service

S’interfacer avec la relation clients et la gestion des niveaux de service pour s’assurer que les

informations du catalogue soient alignés avec les affaires

1.3 Les deux volets du catalogue de services


7/24

7

Le catalogue de services comprend deux parties liées entre elles.

1.3.1 Le catalogue des services d’affaires

Il contient le détail des services d’affaires proposés aux organisations clientes et leurs liens avec les processusd’affaires.

C’est la vue client du catalogue de services et cette partie ne contient pas de termes techniques (les servicessont décrits en termes d’activités et d’objectifs d’affaires).

1.3.2 Le catalogue des services techniques

Il reprend les services d’affaires en détaillant les liens entre ces services d’affaires et les services internes àl’informatique : services de support, services partagés, composants et infrastructures techniques.

C’est la vue informatique du catalogue et elle n’est pas visible des utilisateurs et clients. En revanche, c’est l’outilde travail de toutes les équipes informatiques et des sous-traitants.


8/24

8

2 Gestion des niveaux de service

2.1 ObjectifsLes objectifs de la gestion des niveaux de service se répartissent dans trois catégories :

2.1.1 Pour tous les services

A un niveau local, pour tous les services décrits dans le catalogue des services, les objectifs du processus sont :

définir, documenter, valider, surveiller, mesurer, rapporter et revoir le niveau des servicesinformatiques

s’assurer que des cibles spécifiques et mesurables sont développées

2.1.2 Relations avec organisations d’affaires

Au niveau global sur les relations entre l’organisation informatique et les organisations d’affaires, les objectifs duprocessus sont :

assurer et améliorer les relations et la communication avec les organisations d’affaires

surveiller et améliorer la satisfaction du client par le biais de la qualité de service

s’assurer que l’informatique et les clients ont des attentes claires et non ambigües du niveau deservice

2.1.3 Amélioration continue

Comme pour tout processus dans ce domaine, l’objectif du processus est :

s’assurer que des mesures pro-actives sont mises en place partout il est possible d’en justifier lescoûts

2.2 Définitions clés


9/24

9

2.2.1 Accord sur les niveaux de service (SLA ou Service Level Agreement )

Un SLA (accord de niveau de services) est un accord écrit (pas un contrat) entre un fournisseur

de services et un ou des clients.

Il porte sur un ou plusieurs services d’affaires et décrit les niveaux de services prévus avec laou les organisations d’affaires (disponibilité, capacité, sécurité et continuité de service).

2.2.2 Accord de niveau opérationnel (OLA ou Operational Level Agreement )

Un OLA (accord de niveau opérationnel) est un accord écrit entre le fournisseur de services et

chacune de ses équipes (fonctions).

Il porte sur un ou plusieurs services techniques pour lesquels l’équipe est acteur (supervision,

exploitation, support, installation, etc.) et décrit les niveaux de service attendus (disponibilité,

capacité, sécurité, continuité de service si applicable).

2.2.3 Contrat [de sous-traitance] (UC ou Underpinning Contract )

Un contrat [de sous-traitance] est un contrat juridique passé entre un fournisseur de services et

un fournisseur externe.

Il porte sur un ou plusieurs services techniques et décrits les niveaux de service attendus

(disponibilité, capacité, sécurité, continuité de service si applicable).

2.3 Activités clés

2.3.1 Pour tous les services

Les activités principales du processus dans ce domaine sont les suivantes :

spécifier, négocier, documenter et signer les besoins pour un nouveau service ou un service modifié

(exigences de niveau de service : SLR ou Service Level Requirement )

les gérer et les revoir durant tout le cycle de vie dans les SLAs

surveiller et mesurer l’atteinte des objectifs de niveau de service par rapport aux cibles dans lesSLAs

revoir et réviser les SLAs

établir les périmètres pour les OLAs et contrats

fournir les informations de gestion pour contribuer à la gestion de la performance et démontrer lesréalisations

produire des rapports sur les services

rendre disponible et maintenir à jour les modèles de documents et les standard de la gestion des

niveaux de service

2.3.2 Relations avec organisations d’affaires

Les activités principales du processus dans ce domaine sont les suivantes :

recueillir, mesurer et améliorer la satisfaction client

développer et documenter les contacts et relations avec les affaires, les clients et les partiesprenantes

développer, maintenir et exploiter les procédures pour enregistrer, traiter et résoudre toutesréclamations et diffuser les compliments

d’enregistrer et de gérer toutes les réclamations et compliments

Note personnelle :Il est à noter qu’ITIL parle de compliments faits à l’organisation informatique. Cela doit donc arriver de


10/24

10

temps à autre mais il n’est peut-être pas nécessaire de définir cette partie du processus étant donné lafréquence de ces événements.

2.3.3 Amélioration continue

L’activité principale du processus dans ce domaine est de mener la revue de chaque service et d’inciter les

améliorations en maintenant un plan d’amélioration des services (SIP ou Service Improvement Plan).

2.4 Conception des cadres de SLA (accords de niveaux de service)

D’un point de vue mécanique, il faudrait définir un accord de niveau de service :

pour un service d’affaires donné (parmi tous ceux décrits dans le catalogue de services)

pour une organisation d’affaires (parmi tous ceux utilisant ce service d’affaires, étand donné quechacune peut disposer de niveaux de service spécifiques)

Il est donc rapidement visible qu’un nombre impressionnant de documents d’accords de niveaux de service est àrédiger et à négocier.

Il faut donc aggréger de manière intelligente ces différents SLA "élémentaires" pour minimiser le nombre dedocuments tout en n’accroissant pas la complexité des documents résultants au delà de ce qu’il est raisonnable :en effet, il serait possible d’envisager en théorie un seul SLA décrivant tous les niveaux de service pour toutes lesorganisations clientes, le service fourni s’appelerait "Informatique" !

Ce qu’ITIL dénomme cadres de SLA sont des approches et des règles pratiques pour aggréger ces documents.

2.4.1 SLA orienté service

C’est une méthode d’aggrégation sur un service donné : le SLA couvre un service, pour tous les clients duservice.

Cette approche est particulièrement indiquée pour des services partagés par la totalité ou la quasi-totalité desorganisations clientes comme, par exemple, le service d’affaires de courrier électronique.

Il peut y avoir plusieurs niveaux de service définis dans cet accord (correspondant à une utilisation différente etassociés à une tarification ou une budgétisation différente). Pour simplifier et fixer les idées, chacun de ces

niveaux de service peut être nommé, par exemple de la manière suivante : or, argent, bronze

critique, standard, basique

Chaque organisation cliente ou chaque catégorie de clientèle choisit ensuite son niveau de service avec le coûtassocié.

Une difficulté majeure apparaît très vite : la signature de cet accord car il faut la signature de toutes lesorganisations clientes utilisatrices de ce service.

2.4.2 SLA orienté client

L’idée est de simplifier le point de vue d’une organisation cliente en regroupant dans un seul document tous lesservices utilisés par ce client.

Par exemple : un accord avec la direction financière décrira le détail des niveaux de service de toutes lesapplications financières.

L’avantage est d’avoir une étape de signature simplifiée.

2.4.3 Une combinaison quelconque de ces deux approches

Il est aussi possible de combiner ces deux approches pour une optimisation plus poussée : les services partagés(services de base comme le poste bureautique, la messagerie, la téléphonie, etc.) sont décrits dans une premièreétape par des SLA orientés service et les services plus spécifiques à une organisation d’affaires (applicationsspécifiques) sont ensuite décrit dans des SLA orientés client.

Dans cette approche, il y a deux difficultés :

être exhaustif en couvrant tous les services et tous les clients

éviter les doublons service X client (pas de chevauchement de SLA)


11/24

11

2.4.4 Une combinaison particulière de ces deux approches : les SLA multi-niveaux

Parmi les combinaisons des deux approches SLA orienté service et SLA orienté client, il existe une structure àtrois niveaux (élaborées en trois étapes) qui simplifie la gestion des SLA.

Cette structure comprend les trois niveaux suivants :

niveau entreprise (corporate-level ) : couvre les questions générales de gestion des niveaux deservice communes à toute l’entreprise ; elle est généralement stable et évolue peu dans le temps

niveau client (customer-level ) : couvre toutes les questions de gestion des niveaux de servicespécifiques à chaque client indépendamment des services utilisés

niveau service (service-level ) : couvre toutes les questions de gestion des niveaux de servicespécifiques à un service pour un client

2.5 Eléments en entrée et en sortie du processus

2.5.1 Eléments en entrée

Les entrées du processus sont les suivantes :

Informations d’affaires : stratégies, plans financiers

Analyses d’impact sur les affaires ( BIA ou Business Impact Analysis) : ils fournissent desinformations sur l’impact, la priorité, les risques et le nombre d’utilisateurs associés à chaqueservice

Besoins d’affaires

Stratégies, politiques et contraintes de la stratégie des services

Portefeuille de services et catalogue de services

Informations sur les changements

CMS (Configuration Management System ou système de gestion des configurations) contenant les

liens entre services d’affaires, services de support et technologie

retours, réclamations des clients et utilisateurs

Informations d’autres processus comme les incidents, la disponibilité, la capacité, etc.

2.5.2 Eléments en sortie

Les sorties du processus sont les suivantes :

Rapports sur les services

Plan d’amélioration des services (SIP ou Service Improvement Plan)

Modèles de documents

Exigences de niveaux de services (SLR ou Service Level Requirements)

Accords de niveaux de service (SLA), accords de niveau opérationnel (OLA) et contrats [de sous-traitance] (UC)

Rapports sur les accords de niveau opérationnel (OLA) et contrats [de sous-traitance] (UC)

Compte-rendus de toutes les réunions


12/24

12

3 Gestion des fournisseurs

3.1 ButsLe but de la gestion des fournisseurs est de :

Gérer les fournisseurs et les services qu’ils produisent, de fournir aux affaires une qualité

homogène et cohérente des services informatiques et de garantir une valeur sur

investissement (VFM ou Value For Money )

3.2 Objectifs principaux

Les objectifs principaux de la gestion des fournisseurs sont :

d’obtenir une optimisation des ressources des fournisseurs et des contrats

de garantir que les contrats [de sous-traitance] sont en adéquation avec les besoins des affaires : ilss’alignent sur les cibles convenues dans les SLR et SLA

de gérer les relations avec les fournisseurs

de gérer la performance des fournisseurs

de négocier et convenir des contrats avec des fournisseurs et les gérer durant leur cycle de vie

de maintenir une politique de fournisseurs et une base de données des fournisseurs et des contrats(SCD ou Suppliers and Contracts Database)


13/24

13

4 Gestion de la capacité

4.1 Principes du processus4.1.1 But

Le but de la gestion de la capacité est de :

S’assurer que la capacité à un coût justifiable existe toujours dans tous les secteurs

informatiques et qu’elle correspond aux besoins convenus des organisations d’affaires, actuels

et futurs, au moment opportun.

4.1.2 Objectifs

Les objectifs de la gestion de la capacité sont de :

Produire et maintenir un plan de capacité (Capacity Plan) approprié et à jour

Fournir les avis et conseils sur la capacité et la performance

S’assurer que la performance des services atteigne ou dépasse les objectifs convenus

Aider au diagnostic et à la résolution des incidents et problèmes de capacité et de performance

Evaluer l’impact de tout changement sur le plan de capacité et la performance de tous les serviceset ressources

S’assurer que des mesures d’amélioration de la performance des services sont lancées partout oùcela est justifié financièrement

4.1.3 Un exercice d’équilibrage

En pratique, le processus doit trouver deux équilibres :

entre les coûts et les ressources nécessaires

entre l’offre de capacité et la demande

4.1.4 Le livrable du processus : le plan de capacité

Il s’agit d’un plan d’investissement qui devrait être produit sur une périodicité annuelle et sur la même périodeque les budgets et le cycle de vie des affaires.

Il est destiné à tous les secteurs des organisations d’affaires et informatique et il est géré par le fournisseur deservices.

Il contient les informations suivantes :

les données de planification

l’utilisation actuelle des composants et des services

les plans de développement de la capacité informatique


14/24

14

4.1.5 La déclinaison en 3 processus

Ces trois processus présentent les mêmes objectifs et les mêmes activités mais ils portent sur des périmètres etdes niveaux différents. Ils travaillent aussi sur des échelles de temps différentes.

4.1.5.1 Gestion de la capacité business

Processus proche des stratégies d’affaires et informatique, il s’agit de :

traduire les besoins et plans d’affaires en besoins de services et d’infrastructures informatiques

s’assurer que les besoins futurs des affaires sont quantifiés, conçus et mis en oeuvre au bon moment

4.1.5.2 Gestion de la capacité des services

En raison de la présence dans les accords de niveaux de service (SLA), accords de niveau opérationnel (OLA) etcontrats [de sous-traitance] (UC) d’objectifs en termes de capacité et de performance de services fournis avec lesindicateurs de performance dont les valeurs sont à produire, il est nécessaire d’avoir une vision de la capacité surce niveau.

Il consiste à gérer, contrôler et prévoir la performance de « bout en bout », la capacité d’utilisation et la chargedes services informatiques.

4.1.5.3 Gestion de la capacité des composants

En raison du fait que le métier de base de l’informatique est de gérer et d’exploiter des composantsd’infrastructures qui, assemblés, fournissent des services avec des niveaux de services à atteindre, il estnécessaire d’avoir une vision de la capacité sur ce niveau technique.

Il consiste à gérer, contrôler et prévoir la performance de « bout en bout », l’utilisation et la capacité descomposants techniques.

Ces activités sont essentiellement couvertes par des outils techniques qui mesurent la performance des

serveurs, des réseaux, etc.


15/24

15

4.2 Sous-processus et activités principales du processus

4.2.1 Activités réactives

4.2.1.1 Contrôle permanent

Il s’agit d’un cycle classique de supervision et de réaction en cas de dérive ou de possibilité d’amélioration.

Il s’agit de surveiller, mesurer, produire des rapports et revoir la performance actuelle des services et descomposants.

4.2.1.2 Réactivité sur événement

Il s’agit de répondre à tous les événements de type « franchissement de seuil » liés à la capacité.

4.2.1.3 Réactivité sur incidents et problèmes

Il s’agit de réagir et d’assister les équipes de support face à des difficultés spécifiques de performance.

4.2.2 Activités pro-actives

Elles sont nombreuses :

Anticiper les difficultés de performance en mettant en place les actions nécessaires pour éviter leurapparition

Produire des tendances de l’utilisation actuelle des composants et l’estimation des besoins futurs et

planifier les mises à niveau et les améliorations

Modéliser et identifier les tendances liés à des changements prévus dans les services informatiques etinitier les changements nécessaires sur les services et composants

S’assurer que les mises à niveau sont budgétées, planifiées et mises en oeuvre avant l’apparition dedifficultés

Rechercher activement l’amélioration de la performance partout où cela est justifiable financièrement

Régler et optimiser la performance des services et des composants

4.2.3 Le sous-processus de gestion de la demande

Ce sous-processus a pour principale source d’informations le processus stratégie de gestion de la demande(analyse prévisionnelle de la consommation des services qui seront fournis).

Son objectif est d’influencer la demande de services informatiques pour éviter un impact trop pénalisant d’unedemande supérieure à la capacité disponible pendant les périodes de pointe ou les périodes de pannes).


16/24

16

Influencer la demande veut dire donner des informations, des préconisations voire inciter les utilisateurs et clientsà déplacer leur consommation de services sur des périodes creuses.

Ceci facilite sur le court terme la gestion de la pénurie de composants techniques (capacité moindre consécutiveà une panne).

Ceci est une alternative sur le long terme à la difficulté de justifier un gros investissement pour répondre à lademande pendant les périodes de pointe. Ceci permet aussi d’influencer ou d’étaler la demande.

4.2.4 Le sous-processus de modélisation et d’identification des tendances

Ce sous-processus couvre les activés suivantes :

établissement de bases de référence (baselines)

analyse des tendances

modélisation analytique

modélisation par simulation (tests de charge)

4.2.5 Le sous-processus de dimensionnement des applications

Ce sous-processus permet d’estimer les besoins en ressources pour soutenir un changement sur un service pourgarantir l’atteinte des niveaux de service.

Ce sous-processus est initié à l’étape de conception d’un service et clôturé lorsqu’une application est acceptéeen production.


17/24

17

5 Gestion de la disponbilité


Le but de la gestion de la disponibilité est de :

Assurer que les niveaux de disponibilité des services fournis atteint ou dépasse les besoins

business convenus, actuels et futurs, et ce de façon rentable.

5.1.2 Objectifs

Les objectifs de la gestion de la capacité sont de :

Produire et maintenir un plan de disponibilité approprié et à jour sur les besoins actuels et futurs desaffaires

Fournir les avis et conseils sur les questions de disponibilité

S’assurer que la disponibilité atteint ou dépasse les objectifs, en gérant la disponibilité des serviceset des composants

Contribuer au diagnostic et à la résolution des incidents et des problèmes liés à la disponibilité

Evaluer l’impact de tout changement sur le plan de disponibilité, les services et les ressources

S’assurer que des mesures pro-actives d’amélioration de la disponibilité des services sont lancéespartout où cela est justifié financièrement

5.1.3 La déclinaison en deux processus

La gestion de la disponibilité d’effectue à deux niveaux interconnectés.

5.1.3.1 La disponibilité des servicesCe processus gère la disponibilité et l’indisponibilité de service ainsi que l’impact de la disponibilité etl’indisponibilité des composants sur la disponibilité de service.

5.1.3.2 La disponibilité des composants

Ce processus gère la disponibilité et l’indisponibilité des composants.

5.2 Définitions liées à la disponibilité

5.2.1 Disponibilité ( Availability )

La disponibilité est l’aptitude d’un composant ou d’un service à remplir les fonctions requises

à un instant donné ou sur une période donnée.

Elle est souvent mesurée et rapportée en pourcentage :

5.2.2 Fiabilité (Reliability )

La fiabilité est l’aptitude d’un composant ou système à se maintenir en fonctionnement (à ne

pas tomber en panne).

Elle est souvent mesurée et rapportée sous deux formes : intervalle moyen entre les incidents de service (MTBSI ou Mean Time Between Service Incidents)


18/24

18

intervalle moyen entre les défaillances (MTBF ou Mean Time Between Failures)

5.2.3 Maintenabilité (Maintenability )

La maintabilité est l’aptitude d’un composant ou système à être maintenu ou rétabli en état de

fonctionnement (rapidité de réparation).

Elle est mesurée et rapportée sous la forme d’un délai moyen de restauration du service (MTRS ou Mean Time

to Restore Service)

Il existe une autre mesure qui est partielle : délai moyen de réparation (MTTR ou Mean Time To Repair ).

5.2.4 Agir sur la disponibilité : les deux leviers

Pour agir sur la disponibilité, les personnes travaillant sur ce sujet doivent définr et améliorer les deux aspectsde la disponibilité.

La disponibilité est la résultante combinée de la fiabilité et de la maintabilité.

Pour agir sur la maintenabilité d’un service ou d’un composant, il est nécessaire de minimiser les différentsdélais classiques existants et dont la somme représente le délai d’indisponibilité d’un service ou d’un composantsuite à un incident :


19/24

19

5.2.5 Capacité de soutien extérieur (« Serviceability ») ou maintenabilité externe(« serviçabilité »)

La maintenabilité externe est le soutien contractuel d’un sous-traitant extérieur pour assurer la

fiabilité, la maintenabilité[, la sécurité] et donc la disponibilité des composants, ressources et

services.

5.2.6 Résilience (Resilience)

La résilience est l’aptitude d’un système à rester opérationnel même en cas de défaillances

matérielles d’une ou plusieurs de ses composantes.

Cette aptitude est souvent assurée par la redondance des composants du système résilient.

5.3 Activités principales du processus

5.3.1 Activités réactives

Ces activités consistent en :

la surveillance, la mesure, l’analyse et la gestion de tous les événements, incidents et problèmesconcernant l’indisponibilité

les analyses de défaillance du service (SFA ou Service Failure Analysis)

Ces activités sont assurées par des rôles opérationnels.

5.3.2 Activités pro-actives

Ces activités consistent en la planification, la conception et l’amélioration de la disponibilité.

Ces activités sont assurées par des rôles de conception et de planification.

Ces activités comprennent :

Identification des fonctions business vitales (VBF ou Vital Business Functions) Conception de la disponibilité

Sélection des produits et composants fiables

Gestion des systèmes (pannes)

Conception de la haute disponibilité

Solutions spéciales avec redondance totale (ou à tolérance de panne)

Techniques d’analyse :

o Analyse d’impact de la défaillance d’un composant (CFIA ou Component Impact Failure Analysis)

o Analyse de point de défaillance unique (SPOF ou Single Point of Failure)

o Analyse par arbre de panne

o Analyse et gestion des risques

Calendrier des tests de disponibili té

Maintenance préventive et planifiée

Revue et améliorations continues


20/24

20

6 Gestion de la sécurité de l’information

6.1 Principes du processus

6.1.1 But

Le but de la gestion de la sécurité de l’information est de :

Aligner la sécurité informatique avec la sécurité des affaires et garantir que la sécurité de l’information

est gérée de manière efficace dans tous les services et pour toutes les activités de la gestion des

services.

6.1.2 Qu’est-ce que l’information ?

Le terme information est utilisé ici dans son sens général, ce qui inclut : stockages de données, bases dedonnées, métadonnées.

6.1.3 ObjectifsL’objectif de la gestion de la sécurité de l’information est de protéger les intérêts de ceux qui comptent surl’information et les systèmes de communications qui fournissent l’information des dommages résultant dedéfaillances de disponibilité, de confidentialité et d’intégrité.

6.1.4 Disponibilité de l’information

La disponibilité de l’information garantit que l’information est disponible et utilisable lorsque cela est

requis.

Les systèmes qui la fournissent peuvent résister à des attaques, reprendre à la suite de pannes ou les prévenir.

6.1.5 Confidentialité

La confidentialité de l’information garantit que l’information n’est vue ou divulguée qu’auprès de ceuxqui en ont le droit.

6.1.6 Intégrité de l’information

L’intégrité de l’information garantit que l’information est complète, précise et protégée contre une

modification non autorisée.

6.1.7 Authenticité et non-répudiation de l’information

L’authenticité et la non-répudiation de l’information garantissent que les transactions d’affaires

réalisées électroniquement ainsi que les échanges d’informations entre les entreprises ou avec les

partenaires sont réputées « de confiance ».

Note personnelle : la répudiation dans les législations antiques permettait de renvoyer légalement (safemme) par décision unilatérale du mari.

6.1.8 Référentiel de sécurité

Le référentiel de sécurité doit définir, contenir et maintenir les éléments suivants :

la politique de sécurité de l’information : elle aborde chaque aspect de la stratégie, des contrôles et de larèglementation

le système de gestion de la sécurité de l’information (ISMS ou Information Security Management System)

la stratégie de sécurité globale liée aux stratégies d’affaires

la structure organisationnelle de sécurité efficace

l’ensemble des contrôles de sécurité pour soutenir la politique

la gestion des risques de sécurité


21/24

21

le processus de surveillance (conformité et feed-back )

la stratégie et le plan de communication pour la sécurité

la stratégie et le plan de formation et de sensibilisation

6.2 Activités principalesLes activités clés du processus sont les suivants :

Produire, revoir et réviser la politique globale de sécurité de l’information

Communiquer, mettre en place et appliquer les politiques de sécurité

Evaluer et classifier tous les actifs d’information et la documentation

Mettre en place, revoir, réviser et améliorer l’ensemble des contrôles de sécurité, d’évaluation des risqueset des réponses

Surveiller et gérer toutes les failles de sécurité et les incidents majeurs de sécurité

Analyser, générer des rapports et réduire les volumes et les impacts des failles et incidents de sécurité

Planifier et réaliser des revues, des audits de sécurité et des tests d’intrusion


22/24

22

7 Gestion de la continuité des services


Le but de la gestion de la continuité des services est de :

Soutenir le processus global de gestion de la continuité des affaires en garantissant que les moyens

techniques informatiques et de services nécessaires peuvent être repris dans les délais requis et

convenus avec les organisations d’affaires.

Ceci va impliquer les ressources suivantes :

les systèmes informatiques

les réseaux

les applications le stockage des données

les télécommunications

l’environnement (électricité, climatisation, etc.)

le support technique

le centre de services

7.1.2 Objectifs

Les objectifs de la continuité des services sont :

Maintenir un ensemble de plans de continuité de service et de plans de reprise informatique soutenant les

plans de continuité d’affaires (BCP ou Business Continuity Plan) Effectuer régulièrement des analyses d’impact d’affaires (BIA ou Business Impact Analysis) pour garantir

l’alignement des plans de continuité informatique et d’affaires

Effectuer régulièrement des analyses de risques

Fournir des avis et des conseils à tous sur les questions de continuité et de reprise

Assurer que les mécanismes appropriés de continuité et de reprise ont été mis en place

Evaluer l’impact des changements sur la continuité

Garantir que des mesures pro-actives sont mises en place pour améliorer la disponibilité

Négocier et convenir les contrats [de sous-traitance] avec les fournisseurs sur les plans de continuité

7.1.3 PérimètreIl n’y a pas de frontière franche entre la gestion des incidents et la gestion de la continuité :

les dysfonctionnements les moins significatifs seront qualifiés d’incidents (y compris les incidents majeurs)

les dysfonctionnement les plus significatifs seront qualifiés de désastres et seront traités dans leprocessus de gestion de la continuité

Il reste à préciser la notion de désastre : cette définition varie d’une organisation à une autre et demandera doncà être définie spécifiquement en fonction de l’environnement et de la culture de l’organisation.

D’une manière globale, un désastre est un dysfonctionnement informatique ayant un impact tel sur l’organisationque :

les fonctions vitales d’affaires sont atteintes

l’organisation elle-même est mise en péril


23/24

23

7.2 Activités du processus

Le processus informatique de gestion de la continuité des services est une composante du processus globale degestion de la continuité des affires (BCM ou Business Continuity Management ) et ses activités sont alignées surles phases de ce processus global :

7.2.1 Lancement du projet

Les activités principales de cette phase sont les suivantes :

Etablir la politique

Définir le périmètre

Lancer le projet

7.2.2 Etablissement des besoins et de la stratégieLes activités principales de cette phase sont les suivantes :

Réaliser des analyses d’impact d’affaires (BIA)

Evaluer les risques

Définir la stratégie de continuité des services informatiques

7.2.3 Mise en oeuvre


Elaborer les plans de continuité informatique

Elaborer les plans de reprise et les procédures

Définir l’organisation opérationnelle en continuité

Définir la stratégie de test


24/24

7.2.4 Exploitation courante


Eduquer, sensibiliser et former

Revoir et auditer

Réaliser les tests

Etre partie prenante dans les changements

7.2.5 Activation

Lors de l’activation de la continuité, les procédures définies sont appliquées à la lettre pour minimiser le risqued’erreur causant une perte de temps inutile et préjudiciables pour les organisations d’affaires et les affaires aufinal.

Documents

Itilv3 Conception Processus