• Aucun résultat trouvé

ITIL V3. Les processus de la conception des services

N/A
N/A
Protected

Academic year: 2022

Partager "ITIL V3. Les processus de la conception des services"

Copied!
24
0
0

Texte intégral

(1)

ITIL V3

Les processus de la conception des services

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

(2)

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 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

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

(3)

3

Sommaire

1 Gestion du catalogue de services ... 6

1.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 ... 8

2.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 ... 10

2.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 ... 12

3.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 ... 14

4.2 Sous-processus et activités principales du processus ... 15

(4)

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 Principes du processus ... 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 Principes du processus ... 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 Principes du processus ... 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)

5

7.2.5 Activation ... 24

(6)

6

1 Gestion du catalogue de services

1.1 Objectifs

Les 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 fiables sur 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 droit d’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 du portefeuille 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 les services de support décrits dans le catalogue

 S’interfacer avec les équipes de support, les sous-traitants et la gestion des configurations sur les liens 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)

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 processus d’affaires.

C’est la vue client du catalogue de services et cette partie ne contient pas de termes techniques (les services sont 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’outil de travail de toutes les équipes informatiques et des sous-traitants.

(8)

8

2 Gestion des niveaux de service

2.1 Objectifs

Les 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 services informatiques

 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 du processus 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 de service

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 les coûts

2.2 Définitions clés

(9)

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 la ou 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 les SLAs

 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 les ré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 parties prenantes

 développer, maintenir et exploiter les procédures pour enregistrer, traiter et résoudre toutes ré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)

10

temps à autre mais il n’est peut-être pas nécessaire de définir cette partie du processus étant donné la fré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é que chacune 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 de documents 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 les organisations 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 du service.

Cette approche est particulièrement indiquée pour des services partagés par la totalité ou la quasi-totalité des organisations 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 et associé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ût associé.

Une difficulté majeure apparaît très vite : la signature de cet accord car il faut la signature de toutes les organisations 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 les services 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 les applications 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 (applications spé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)

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 de service 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 service spécifiques à chaque client indépendamment des services utilisés

niveau service (service-level) : couvre toutes les questions de gestion des niveaux de service spé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 des informations sur l’impact, la priorité, les risques et le nombre d’utilisateurs associés à chaque service

 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)

12

3 Gestion des fournisseurs

3.1 Buts

Le 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 : ils s’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)

13

4 Gestion de la capacité

4.1 Principes du processus 4.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 services et 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ériode que 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 de services.

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)

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 et des 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) et contrats [de sous-traitance] (UC) d’objectifs en termes de capacité et de performance de services fournis avec les indicateurs de performance dont les valeurs sont à produire, il est nécessaire d’avoir une vision de la capacité sur ce niveau.

Il consiste à gérer, contrôler et prévoir la performance de « bout en bout », la capacité d’utilisation et la charge des 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 composants d’infrastructures qui, assemblés, fournissent des services avec des niveaux de services à atteindre, il est né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é des composants techniques.

Ces activités sont essentiellement couvertes par des outils techniques qui mesurent la performance des serveurs, des réseaux, etc.

(15)

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 des composants.

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 leur apparition

 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 et initier 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 de difficulté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’une demande supérieure à la capacité disponible pendant les périodes de pointe ou les périodes de pannes).

(16)

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 à la demande 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 pour garantir 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ée en production.

(17)

17

5 Gestion de la disponbilité

5.1 Principes du processus 5.1.1 But

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 des affaires

 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 services et 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ées partout 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 services

Ce processus gère la disponibilité et l’indisponibilité de service ainsi que l’impact de la disponibilité et l’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)

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 aspects de 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érents délais classiques existants et dont la somme représente le délai d’indisponibilité d’un service ou d’un composant suite à un incident :

(19)

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èmes concernant 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 disponibilité

 Maintenance préventive et planifiée

 Revue et améliorations continues

(20)

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 de données, métadonnées.

6.1.3 Objectifs

L’objectif de la gestion de la sécurité de l’information est de protéger les intérêts de ceux qui comptent sur l’information et les systèmes de communications qui fournissent l’information des dommages résultant de dé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 ceux qui 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 (sa femme) 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 la rè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)

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 principales

Les 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 risques et 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)

22

7 Gestion de la continuité des services

7.1 Principes du processus 7.1.1 But

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ètre

Il 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 le processus 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’organisation que :

 les fonctions vitales d’affaires sont atteintes

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

(23)

23

7.2 Activités du processus

Le processus informatique de gestion de la continuité des services est une composante du processus globale de gestion de la continuité des affires (BCM ou Business Continuity Management) et ses activités sont alignées sur les 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égie

Les 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

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

 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

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

 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 risque d’erreur causant une perte de temps inutile et préjudiciables pour les organisations d’affaires et les affaires au final.

Références

Documents relatifs

© 2021 KPMG S.A., société anonyme d'expertise comptable et de commissariat aux comptes, membre français du réseau KPMG constitué de cabinets indépendants adhérents de

HEAT Service Catalog utilise une gamme de services standard qui définit les niveaux de service, les coûts et les délais de livraison associés, tout en offrant aux utilisateurs

Bien que, dans le cadre de l’essai, seuls la fonction Centre de services et les processus de Gestion des incidents et de Gestion des demandes aient été testés de façon

►La Gestion des Niveaux de Service pour comprendre les engagements de la fourniture de services. ►La Gestion de la Disponibilité pour fournir des mesures de réduction des

Le Centre de Services doit être au minimum face aux utilisateurs pour répondre à leurs besoins et doit être avec eux pour qu'ils puissent atteindre leurs objectifs9. Il est un point

Les Accords de Niveaux de Services (SLAs ou Service Level Agreements) définissent des objectifs spécifiques sur lesquels les performances de l’organisation des SIs peuvent

Les fondamentaux de MS Project Professional (monoposte) 1 jour Gestion de projet Gérez et pilotez votre projet avec MS Project Professional (monoposte) 3 jours Gestion de projet

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