BÂTIR SON CATALOGUE DE

SERVICES

22 conseils pour ne pas se tromper

Que veut-on mettre dans le Cloud. Qu’est ce qui ne

doit pas être dans le Cloud ?

Identifier le portefeuille de

services

1

Créer un catalogue de services pertinent pour une

population d’utilisateurs (le service juridique, la R&D, la

logistique, le marketing, la filiale, le pays..)

Pour les services « transverses » les publier dans un

catalogue public (visible par tous les utilisateurs

accédant au portail)

Créer des Catalogues Privés

et Publics

2

Identifier par population les services dont ils ont

besoin, isoler du cloud les services qui ne sont

demandés que par trop peu d’utilisateurs

Faire une étude de marché

préalable

3

Mettre le « bon » prix devant le bon service : un

service trop cher pour la valeur délivrée ne sera

pas consommé, un service 3 fois plus cher que le

même service disponible sur le cloud public ne

sera pas utilisé

Tarifer ses services

4

Limiter les offres

Ne pas confondre « catalogue de services » et

« inventaire des Galeries Lafayette », et limiter le

nombre de services disponibles

5

Lisibilité des services

Etre explicite sur le contenu du service proposé

dans le catalogue, ce qu’il fait, le niveau de service

proposé

6

Lier le catalogue de

services à la gestion des

demandes et des incidents

Pouvoir identifier et gérer rapidement un utilisateur

se perdant dans le catalogue, souhaitant exprimer

un besoin particulier, et tracer les éventuels

incidents de procédure

7

Limiter la consommation

pour éviter les excès voulus

ou non

Eviter d’accepter la création d’un volume

« inhabituel » de services par un utilisateur (mal

intentionné, ou faisant une simple erreur de saisie)

pour éviter les conflits au moment de la facturation.

Penser à poser une validation manuelle au-delà

d’une quantité convenue de services

8

Penser à la journalisation

des actions

Pouvoir tracer la liste des demandes posées sur le

portail, de façon à mieux piloter le fonctionnement

du portail, et présenter un justificatif auditable en

cas de litige

9

Mesurer la qualité du SLA

fourni

Eviter l’insatisfaction des clients en cas de sous-

qualité du service rendu. Mais également éviter la

sur-qualité conduisant à réduire la marge

opérationnelle du fournisseur de services

10

Penser au cycle de vie

Une fois le catalogue de services publié, penser

qu’il faudra le faire vivre : ajouter de nouveaux

services, éteindre des services obsolètes ou non

consommés

11

Sécuriser les droits d’accès

administrateur

Eviter un accès frauduleux aux outils

d’administration pour créer des services

fantômes, hacker les outils de facturation….

12

Ne pas se limiter à la gestion

des ressources virtuelles

Certaines applications/certains services peuvent

justifier l’utilisation complète ou partielle de

ressources physiques (un serveur physique, une

baie de stockage physique…)

13

Disposer de processus

clairs et documentés

Le provisioning des services consiste à

automatiser des processus. Si on veut créer ex-

nihilo un service alors qu’aucun processus

n’existe pour le constituer invalidera sa

publication dans le catalogue de services

14

S’ouvrir vers le sourcing de

services hybrides

Prévoir les situations d’atteinte des limites de

capacités internes pour aller consommer la

ressource à l’extérieur du cloud, le temps de

l’absorption des pics de charge

15

S’ouvrir vers le sourcing de

services hybrides

Prévoir les situations d’atteinte des limites de

capacités internes pour aller consommer la

ressource à l’extérieur du cloud, le temps de

l’absorption des pics de charge

16

Penser à l’évolutivité horizontale

et verticale des services

Un utilisateur doit pouvoir faire évoluer sa

demande de service horizontalement (passer

d’une VM type Small à une VM Large ou XL) et

verticalement (passer d’un service peu sécurisé

à un niveau de criticité plus important)

17

Quelle réactivité apporter

aux clients

Quel est le temps « raisonnable » pour créer un

nouveau service ? Comment le mesurer, et le

respecter ?

18

Associer le pool de

ressources adaptées aux

SLAs proposés

Avoir des mécanismes de redondance permettant

la tenue d’objectifs de disponibilité pour les

besoins critiques, et à l’inverse, ne s’appuyer

que sur les mécanismes nécessaires pour les

niveaux de criticité moindre

19

Assurer la conformité

réglementaire

Lors de la demande de création d’un service

composite, valider avant de délivrer le service à

l’utilisateur que tous ses composants (serveur,

stockage, Operating System, applicatifs, niveaux

de correctifs…) sont conformes aux politiques de

sécurité du fournisseur et/ou du demandeur

20

Prévoir des mécanismes

d’audit

Pouvoir à tout moment d’auditer le niveau de

conformité des environnements en usage et

notifier l’utilisateur de son écart par rapport aux

règles, voire couper le service en cas de risque

de sécurité majeur

21

Identifier les ressources

orphelines

S’assurer que toutes les ressources

commisionnées ont bien un propriétaire que l’on

pourra facturer, éliminer les VM orphelines

20

S’assurer de la qualité de

support aux utilisateurs

Prévoir les compétences, et les contrats du

support back to back avec les composants

matériels et logiciels des services proposés

22