Le catalogue de services est au Cloud ce que le menu est au restaurant : INDISPENSABLE ! C’est en effet lui qui fait le lien entre les directions métiers et les ressources. Définir le catalogue de services est donc inévitable. Comment s’y prendre ? A quoi faut-il penser ? Ne manquez pas ce diaporama, qui passe en revue 22 conseils pour ne rien oublier !

1. BÂTIR SON CATALOGUE DE
SERVICES
22 conseils pour ne pas se tromper

2. 1
Identifier le portefeuille de
services
Que veut-on mettre dans le Cloud. Qu’est ce qui ne
doit pas être dans le Cloud ?

3. 2
Créer des Catalogues Privés
et Publics
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)

4. 3
Faire une étude de marché
préalable
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

5. 4
Tarifer ses services
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é

6. 5
Limiter les offres
Ne pas confondre « catalogue de services » et
« inventaire des Galeries Lafayette », et limiter le
nombre de services disponibles

7. 6
Lisibilité des services
Etre explicite sur le contenu du service proposé
dans le catalogue, ce qu’il fait, le niveau de service
proposé

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

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

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

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

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

13. 12
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….

14. 13
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…)

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

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

17. 16
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

18. 17
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)

19. 18
Quelle réactivité apporter
aux clients
Quel est le temps « raisonnable » pour créer un
nouveau service ? Comment le mesurer, et le
respecter ?

20. 19
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

21. 20
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

22. 21
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

23. 20
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

24. 22
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