Club des Responsablesd’Infrastructures et de Production

LiVR

E BL

ANC

Juin 2012

L’OBSERVATOIREdes Directeursd’Infrastructureset de Production

CLOUD COMPUTING PaaS, Sécurité et Cloud,Sourcing, facturation etrefacturation des services Cloud, Observatoire HPC

Patrick Joubert& Stéphane GeisselAssistance Editoriale : Renaud Bonnet

PAG

E 3

Table matièresdes

IntRoduCtIon 4

1. Le PaaS : défInItIon, PRobLématIqueS, uSageS 61.1. etats des lieux, définitions, typologie des services PaaS 71.2. gestion du cycle de vie : build et Run dans le PaaS 91.3. environnements spécifiques pour le build et le Run 101.4. qu’héberger en mode PaaS public ? 111.5. frameworks 111.6. gérer les architectures Hybrides avec le PaaS 121.7. administration et exploitation des offres PaaS 131.8. modèles économiques et engagements de qualité de service 151.9. Réversibilité, portabilité entre plates-formes 161.10 Conclusion 16

2. SéCuRIté et CLoud ComPutIng 182.1. Le Cloud vu par les RSSI 182.2. questions de sécurité indiscrètes pour votre (futur ?) fournisseur de Cloud 212.3. Perspectives / Conclusion 21

3. LeS modèLeS de SouRCIng et Le CLoud 233.1. typologie des modèles de Cloud en fonction des types d’applications : quels Clouds pour quelles applications ? 233.2. Les apports principaux du référentiel eSCm aux pratiques de sourcing du Cloud Computing 243.3. Recommandations d’ordre juridique sur les Contrats portant sur les services Cloud, formulées par deux avocats ayant contribué au livre blanc 27

4. faCtuRatIon et RefaCtuRatIon danS Le CLoud 284.1. Collecte des métriques 28 4.1.1 métriques techniques 30

4.1.2 métriques SLa’s 31

4.1.3 métriques métiers ou business 32

4.2. Reventilation des coûts : Showback ou Chargeback 334.3. Conclusion 34

5. CLoud et HIgH PeRfoRmanCe ComPutIng 36

6. RetouRS d’eXPéRIenCe 396.1. Valeo Vega 396.2. Stime (Informatique des mousquetaires) 416.3. unéo 446.4. orange-ft groupe 46

7. ConCLuSIon Le Cloud est une réalité dans nos sociétés 48

a propos du CRiP 49

PAG

E 4

Le Cloud, la concrétisation

Trois ans, trois Livres Blancs. C’est en effet déjà la troisième production du Groupe de Travail Cloud Computing du CriP que vous lisez depuis 2010, année de sa création. Une fécondité due en particulier au dynamisme du domaine traité.

Réduire le phénomène Cloud à un effet marketing était très tentant... il y a trois ans. Mais aujourd’hui, le Cloud a atteint sa phase de maturation, celle qui précède le plein développement et en dessine déjà les grands traits. Et plus personne ne s’avise de nier la valeur et l’importance du phénomène Cloud, dont nous répétons une fois de plus qu’il ne s’agit pas d’une technique, ou même d’une famille de techniques, mais d’une nouvelle façon de produire et de consommer les services informatiques.

Cette année, le fruit des efforts Groupe Cloud Computing pour sa saison 2011 - 2012 est encore une belle réussite collective, un travail d’équipe et nous tenons à remercier vivement les participants et contributeurs.

Voici les sujets que vous allez découvrir dans ces pages :

- Le PaaS, le jeune premier du Cloud, et pour entrer dans ce sujet aux contours encore flous nous poserons quelques jalons pour mettre en regard les problématiques et les usages.

- Nous avons ensuite souhaité confronter les

points de vue des membres du Groupe Cloud Computing avec ceux des RSSI (Responsables de la sécurité des systèmes d’Information) de plusieurs adhérents du CRiP sur le sujet de l’adoption du Cloud dans les entreprises et administrations. Pour découvrir que finalement

les avis ne sont pas si opposés ! Une check-list pratique vous permettra d’aborder sereinement le sujet de la sécurité avec votre fournisseur préféré.

- Notre troisième chapitre est issu du travail réalisé avec le Syntec Numérique pour traiter des modèles de Sourcing à l’heure du Cloud, un focus particulier porte sur les référentiels tels eSCM qui constituent un support pour une bonne mise en œuvre de projets multi-sourcés.

- Notre quatrième chapitre porte sur la facturation et la refacturation des services Cloud, des éléments d’importance dans une démarche de maîtrise des coûts. C’est l’occasion de mieux se pencher sur ce sujet pointu.

- Le domaine du HPC, abordé plus en détail l’an dernier, a connu des évolutions ces douze derniers mois. Nous avons souhaité vous en tenir informé dans un bref observatoire de tendances qui souligne les points-clés de la maturation de ce domaine complexe et encore mouvant.

- Enfin, notre dernier chapitre illustre, par des exemples de la vraie vie, des références de projets réalisés par les membres : IaaS, PaaS, SaaS. Les 3 composantes du Cloud y sont représentées, encore merci à tous pour vos témoignages.

Bonne lecture !

Pilotes du Groupe de Travail Cloud Computing du CRiP

Stéphane GEISSELPatrick JOUBERT

Intro duction

CLO

UD

CO

MP

UTI

NG

: P

aas,

Séc

urité

et C

loud

, Sou

rcin

g, fa

ctur

atio

n et

ref

actu

ratio

n de

s se

rvic

es C

loud

, Obs

erva

toir

e H

PC

PAG

E 5

REMERCIEMENTS

Ce Livre Blanc a été rédigé par les membres suivants du GT Cloud Computing du CRiP :

Pascal Dechamboux Orange – FT GroupeStéphane Geissel SFRAlain Hutié EdF R&DPatrick Joubert CRiPStéphane Lafon SanofiArnaud Lecomte STIMEKathleen Milsted Orange – FT GroupePierre Oblin Orange – FT GroupeMichel Raulet PSA PEUGEOT CITROËNFrançois Stephan CRiPArnaud Viselthier EdFJacques Witkowski CRiP

Les contenus de ce Livre Blanc ont bénéficié des échanges, débats, désaccords, discussions, retours d’ex-périences et commentaires divers tenus au sein du Groupe de Travail Cloud Computing depuis septembre 2011. Que tous les participants soient chaudement remerciés pour leurs contributions :Marc Bégué CNESDenis Descamps PublicisClaude Fauconnet TotalStephane Gilmer PublicisJean Guyot Société GénéralePierre Haslee Société GénéraleFranck Honnecker CA-CIBAlain Roy Generali

Nous remercions pour leurs témoignages : Lamia Elias Société GénéralePierre Faure Boost AérospaceAnnelise Massiera DISICBenjamin Rameix UnéoCédric Siben Ministère de l’Economie et des FinancesJean Roy Valeo

Nous remercions les RSSI participants à nos rencontres RSSI – GT Cloud :Antoine Béligné PSA PEUGEOT CITROËNAlain Bernard L’OréalMartine Hanin TotalValérie Zorzi CNES

Nous remercions les membres du Groupe de Travail Sourcing Cloud du Syntec Numérique et tout particulièrement Renaud Brosse

Assistance et coordination éditoriale : Renaud Bonnet (CRiP)

LiVR

E B

LAN

C

PAG

E 6

LE PAAS : DéFINITION, PROBLéMATIQUES, USAGES

Le PaaS – Platform-as-a-Service – constitue la famille de services Cloud la plus en rupture avec l’existant. En effet, dans le SaaS (Software-as-a-Service), tout le monde reconnait le modèle ASP développé au tournant du XXIème siècle. Et l’IaaS ne fait que donner plus de souplesse et d’agilité aux services de fourniture de serveurs préconfigurés par les hébergeurs que nous connaissons depuis les débuts du Web.

Le PaaS présente un visage nettement plus original. Plus riche que l’IaaS, il ne se limite pas à la machine nue ou juste équipée de son système d’exploitation. Moins étroit que le SaaS, il ne fournit pas un service applicatif complet mais bien un environnement de développement et d’exécution d’applications plus ou moins complexe qui se compose de ressources système, d’un système d’exploitation et de diverses couches middleware : bases de données, répartiteurs de charges, serveurs d’applications, serveurs d’annuaires, etc. on pourrait allonger la liste sans fin.

Ce schéma rappelle que les différents types de services Cloud se distinguent par les composants de la pile informatique pris en charge par le prestataire pour leur exploitation et leur maintenance.

1

En bleu : composants contrôlés par le prestataireEn rouge : composants contrôlés par le clientEn hachuré : composants fournis par le prestataire selon le choix du client.

CLO

UD

CO

MP

UTI

NG

: P

aas,

Séc

urité

et C

loud

, Sou

rcin

g, fa

ctur

atio

n et

ref

actu

ratio

n de

s se

rvic

es C

loud

, Obs

erva

toir

e H

PC

PAG

E 7

LiVR

E B

LAN

C

Le PaaS a été abordé en détail par le groupe de travail Cloud Computing du CRiP à l’automne 2011 en réponse avant tout à une nette maturation du sujet à la fois chez les membres du CRiP qui commencent des expérimentations dans ce domaine (voir le retour d’expérience Orange-FT en fin de ce volume) et chez les fournisseurs qui multiplient les offres.

Le PaaS apparait à certaines entreprises comme un prolongement naturel de l’IaaS. Au fil des ans, le processus de fabrication des logiciels a beaucoup progressé, s’est structuré, ce qui a provoqué une diminution des délais de réalisation. Mais la mise en production de ces logiciels reste complexe, car elle demande de passer par de nombreux silos (développement, tests, recettes, pré-production, production), et de réaliser de nombreuses actions manuelles ou faiblement automatisées. Il existe en fait un immense écart entre environnements de développement et de production, le chemin qui va de l’un à l’autre prend du temps, trop pour beaucoup d’entreprises. Le PaaS serait le moyen de réduire cet écart, en mettant à la disposition des développeurs un environnement adapté à leurs besoins mais en même temps déjà largement– voire totalement – conforme aux principes de la Production. Ainsi le cycle développement-tests-recettes-préproduction-production se déroulerait d’une façon plus fluide, avec une moindre débauche d’efforts.

Une autre dimension doit être soulignée dans ce désir de consommer du PaaS. La virtualisation et l’IaaS ont déjà apporté un gain significatif d’agilité dans la mise à disposition de ressources. Mais savoir livrer une souche technique en quelques heures pour répondre à un besoin ponctuel ne suffit pas. Beaucoup d’entreprises voudraient progresser dans l’agilité en possédant un environnement d’accueil qui – en respectant un cahier des charges de développement idoine – soit capable de fournir une élasticité d’exécution, une plate-forme capable de prendre en charge elle-même les problèmes de dimensionnement de ressources en fonction de la charge d’une application. La plate-forme PaaS devrait rapprocher les entreprises de ce mode de fonctionnement. On ne provisionne plus des serveurs, mais le comportement de l’application détermine la mise à disposition de ressources par la plate-forme.

1.1 Etats des lieux, définitions, typologie des services PaaS

La définition du PaaS est moins unifiée que celle de l’IaaS, au point qu’il serait plus juste de considérer une famille de définitions. Ces variations découlent à la fois du savoir-faire des offreurs et des besoins des entreprises, et peuvent même dans le cas de Cloud PaaS internes correspondre à la nécessité de développer le PaaS en continuité avec l’existant de l’entreprise.

En effet, le besoin business définit les fonctionnalités à développer et par voie de conséquence les composants logiciels nécessaires, ainsi que les modules applicatifs indispensables ou utiles pour développer plus rapidement les fonctionnalités demandées. Or le PaaS possède une grande modularité, il commence dès que quelques briques intermédiaires (des composants middleware tels bases de données ou serveurs d’applications) s’ajoutent aux serveurs virtuels, mais peut atteindre un haut niveau de richesse fonctionnelle avec l’intégration d’environnements de développement complets par exemple, ou d’outils perfectionnés de gestion de charge. Il n’existe donc pas a priori de besoin unique identifiable dans ce domaine, du moins à ce stade de maturité.

PAG

E 8

Dans l’offre actuelle très diversifiée, deux tendances se dégagent dès à présent :

1. Des plates-formes IaaS enrichies parfois baptisées IaaS+ : elles se composent de machines virtuelles unitaires avec différentes versions de systèmes d’exploitation et de logiciels de base (serveurs d’applications, serveurs de bases de données, middlewares, etc.) pré-chargées. Avec ce type de service, le client doit composer lui-même son architecture technique et définir le dimensionnement nécessaire à son application. Il lui faut donc choisir chaque machine virtuelle avec les logiciels de base associés dans un catalogue. Notons cependant que les assemblages sont le plus souvent prédéfinis et les versions disponibles limitées en nombre, ce qui borne les combinaisons effectivement possibles (le nombre de ces combinaisons peut toutefois se montrer déroutant pour les entreprises). Nous classons dans cette catégorie Amazon EC2 avec les Amazon Image Machines (AMI) (chacune pouvant embarquer au choix du catalogue un SGBD, et un serveur d’application web en plus de l’OS) et les offres IBM SmartCloud Application Services.

2. Des environnements d’exécution PaaS complets fondés sur des architectures techniques prédéfinies par le fournisseur avec plusieurs machines virtuelles sur lesquelles sont répartis les composants logiciels de base. A ce niveau, le client ne choisit pas des machines individuellement, ni par exemple leur taille, mais choisit un environnement logiciel, c’est-à-dire principalement un langage de programmation, un framework Web et un SGBD. Les packages sont prédéfinis avec plus ou moins de flexibilité. Les éditeurs de ces solutions proposent souvent des services logiciels complémentaires (ex. middlewares, composants logiciels réutilisables). La plate-forme prend en charge automatiquement la flexibilité et la scalabilité lors de l’exécution de l’application. On trouve dans cette catégorie Google App Engine, DotCloud, Cloud Foundry, Microsoft Azure, Amazon Elastic Beanstalk, CloudBees, RedHat OpenShift.

On notera que dans cet écosystème cohabitent des acteurs connus et déjà anciens (IBM, Microsoft), des entreprises ayant assis leur réputation sur leurs opérations Web (Google, Amazon) et de nouveaux acteurs. Bien qu’il soit pour le moment difficile de proposer un tableau général des clients de ce type de services, on notera l’existence d’une première génération d’adopteurs qui ont choisi de s’appuyer sur des plates-formes PaaS pour réduire au maximum leurs délais de mise sur le marché et de se lancer avec un minimum de mise en œuvre physique. En France, l’entreprise d’assistants à la conduite Coyote, dont l’App sur iPhone a rencontré un immense succès, a démarré ce service sur Google App Engine.

Limitation du modèle : comment intégrer des applications complexes au PaaS ?

Envers du décor, la plupart des offres PaaS actuelles ne supportent pas nativement les architectures logicielles complexes et relèvent d’un paradigme de type une application = une plate-forme PaaS. La mise en œuvre d’un système informatique pour un domaine métier, ou d’une application elle-même constituée de sous-applications ou de modules applicatifs n’est pas facilitée dans l’état présent de l’offre. En effet, les entités gérées actuellement par les PaaS sont des applications, ou des modules applicatifs autonomes. Il s’agit concrètement d’applications web, étroitement associées à

CLO

UD

CO

MP

UTI

NG

: P

aas,

Séc

urité

et C

loud

, Sou

rcin

g, fa

ctur

atio

n et

ref

actu

ratio

n de

s se

rvic

es C

loud

, Obs

erva

toir

e H

PC

PAG

E 9

LiVR

E B

LAN

C

un point d’entrée sur le web (url). La notion de système informatique composé de plusieurs applications n’est pas gérée dans un tel modèle.

Les opérations de communication inter-applicatives doivent alors mettre en œuvre des interfaces web qui ne possèdent à ce jour que des fonctionnalités de communication élémentaires.

En résumé, les fournisseurs PaaS vont devoir évoluer au-delà du modèle actuel qui fait qu’une application se résume souvent à l’association d’un point d’accès web et d’une base de données pour aller vers un modèle ou une application fonctionne comme la combinaison d’un ensemble d’autres applications.

Ces différents facteurs pousseront sans doute des entreprises à se tourner vers des solutions de PaaS privées, en construisant en interne leur plate-forme. L’une des questions importantes à se poser sera celle de la standardisation : quels composants et combinaisons de composants privilégier concernant les bases de données, les versions de moteurs et de langages, les frameworks ? De plus, ces PaaS privés risquent de se trouver en concurrence avec les PaaS publics, au sens où les équipes de développement risquent de se tourner vers des plates-formes externes afin de développer en toute autonomie, sans aucun contrôle de la DSI. Or, cela posera un véritable problème de gouvernance lors de la ré-internalisation des applications ou de leur nécessaire maintenance dans le temps.

1.2 Gestion du cycle de vie : Build et Run dans le PaaS

Le PaaS va exercer un impact organisationnel important sur l’ensemble des intervenants sur les différentes couches du SI d’entreprise – utilisateurs finaux exceptés -. Il devrait aussi provoquer l’apparition de nouveaux rôles, exploitant d’applications PaaS par exemple. De ce point de vue, le PaaS présente une dimension plus disruptive que le SaaS ou l’IaaS car, comme expliqué plus haut, il affaiblit la frontière entre environnements de Développement-Tests-Recette et environnements de Production, et ce au prix de la mise en place de nouvelles règles de fonctionnement.

La liste des métiers impactés se compose de :

• Equipes de conception/développement : elles devront intégrer les contraintes spécifiques liées au PaaS, par exemple de ne plus exprimer leurs demandes sous forme de spécifications techniques, mais de pures spécifications applicatives : accès Web, base de données, serveur, etc.

• Architectes techniques : leur rôle diminuera éventuellement auprès des équipes projets, puisque le cadre d’architecture se trouvera inscrit ‘en dur’ directement dans la plate-forme PaaS. Mais leur contribution reste essentielle. D’abord pour constituer l’architecture technique de l’offre d’une plate-forme PaaS (offre qui pourra ensuite se démultiplier sans eux ou presque), ensuite pour constituer l’architecture d’une application par assemblage de multiples serveurs d’une offre IaaS+ (interne ou externe). Leur rôle reste d’actualité dans la gestion du cycle de vie des plates-formes.

PAG

E 10

• Architectes logiciels : Pour eux aussi une partie importante de l’architecture se retrouvera cadrée directement par la plate-forme. Mais leur rôle va s’amplifier au sein des projets. D’une part, ils devront assimiler les spécifications techniques et les règles de fonctionnement des plates-formes, au service des projets candidats. D’autre part, ils devront valider auprès d’eux une conception logicielle et une mise en œuvre conformes aux règles et optimisées sur le plan technique et économique. Dans un autre contexte, leur rôle reste essentiel pour constituer l’architecture logicielle de l’offre d’une plate-forme PaaS (qu’elle soit interne ou externe, aussi bien pour les architectes des entreprises utilisatrices que pour les architectes des fournisseurs).

• Intégrateurs techniques, aussi connus comme Intégrateurs d’Exploitation (cf. nomenclature cigref 2011, chapitre 4.6) : Eux aussi devront assimiler au minimum les spécifications techniques des plates-formes des projets et applications dont ils ont la responsabilité. Ils devront surtout assimiler les outils, les interfaces techniques et les processus imposés par ces plates-formes, pour la fabrication des applications et pour leur exploitation en vie courante.

• Exploitants en vie courante, Exploitants applicatifs, Exploitants d’infra PaaS, Exploitants d’infra IaaS, Pilotes d’Exploitation (cf. nomenclature Cigref 2011, chapitre 4.7).En phase de vie courante, ils devront exploiter les applications déployées sur des plates-formes PaaS au même titre que les autres applications historiques. Ils devront assimiler les modes de fonctionnement, procédures et gammes opératoires imposées par ces plates-formes. Les plates-formes internes développées sur mesure par une entreprise utilisatrice pourront respecter les standards d’exploitation déjà en vigueur. Les plates-formes acquises, hébergées en interne ou les plates-formes externes imposent actuellement leur propre modèle d’exploitation auquel ces métiers doivent s’adapter (à ce jour, les premières plates-formes ne mettent pas en œuvre de standards en la matière).

• Développeurs de grands groupes, en Sociétés de services ou Indépendants : Quelle que soit leur origine, les concepteurs et les développeurs doivent assimiler les composants logiciels proposés (middleware, plugins), leurs spécifications, et les interfaces programmatiques des plates-formes qu’ils mettent en œuvre afin de concevoir et développer les applications.

• Sociétés marketing/évènementiel, Vendeurs de solutions SaaS : tout fournisseur qui souhaite proposer une offre de service sur Internet (qu’elle soit proposée en mode SaaS ou non) bâtie à l’aide d’une plate-forme PaaS, doit assimiler la technologie de la plate-forme pour chacun des métiers intervenant.

1.3 Environnements spécifiques pour le Build et le Run

Dans les premières offres de PaaS les outils de gestion de cycle de vie des applications étaient peu répandus. Cette situation évolue actuellement. On observe deux tendances.

• Une partie des fournisseurs promeut un modèle de développement intégralement interne au Cloud. Ils proposent l’équivalent d’une suite d’applications de

CLO

UD

CO

MP

UTI

NG

: P

aas,

Séc

urité

et C

loud

, Sou

rcin

g, fa

ctur

atio

n et

ref

actu

ratio

n de

s se

rvic

es C

loud

, Obs

erva

toir

e H

PC

PAG

E 11

Li

VRE

BLA

NC

développement des applications en mode SaaS (des services de développement tels un gestionnaire de versions et de contenus, un système de gestion de droits, un serveur d’intégration, etc.) en frontal de leur plate-forme PaaS. C’est par exemple le cas de CloudBees.

• D’autres fournisseurs s’orientent plutôt vers une logique de développement local avant chargement vers le PaaS, quitte à fournir des outils additionnels pour communiquer avec le service PaaS. Par exemple Cloud Foundry propose une machine virtuelle à faire tourner en local sous VMPlayer, Google propose un plugin Eclipse Google App Engine pour de la simulation.

Dans l’ensemble, nous considérons que le lien entre outils de développement et environnements d’exécution PaaS reste faible et lacunaire. Notons aussi que certains fournisseurs proposent dès maintenant de piloter les opérations de développement et d’exploitation depuis une console unique. Ce mode de fonctionnement intéressant reste rare.

1.4 Qu’héberger en mode PaaS public ?

Les fournisseurs de services PaaS assurent que leurs plates-formes sont totalement polyvalentes et adaptées au développement, aux tests utilisateurs, à la réalisation de Proof-of-Concepts (prototypes, maquettes, PoC), mais aussi capables de recevoir des applications en production. Et de fait, de leur point de vue, il n’existe pas de différence entre plates-formes de développement et de production ; seul l’utilisateur décide de ce qu’il fait avec le service. Le problème qui se pose est ici exactement le même qu’avec les plates-formes de type IaaS. Il n’existe pas d’engagements de SLA comparables à ce qu’une grande entreprise est en mesure d’exiger d’un hébergeur par exemple (ceci est souvent vrai pour l’engagement sur la disponibilité de la plateforme, et pratiquement systématique pour l’engagement sur les performances). Il paraît donc prématuré d’envisager l’utilisation de ces plates-formes en production. L’adoption de ce type de solutions par les développeurs sans consultation préalable de la Production, risque pourtant parfois d’obliger la Production à prendre en charge des applications PaaS dans des conditions encore précaires.

Le PaaS public constitue donc un bon candidat pour la création de prototypes (PoC) et de pilotes. Pour le reste, le problème du passage en production n’est pas encore résolu, personne ne sait comment ré-internaliser proprement un développement effectué sur une plate-forme PaaS. Il y a là un point d’attention que devront lever les fournisseurs.

1.5 Frameworks

Les plates-formes PaaS publiques réduisent souvent les possibilités de choix d’un framework de développement, puisqu’elles n’en proposent qu’un ou quelques-uns. Le Framework n’est toutefois pas systématiquement imposé, néanmoins, chaque PaaS comporte son propre cadre, avec des outils logiciels, des API, des composants spécifiques. Les entreprises savent que la normalisation des frameworks de développement est une bonne chose, sauf qu’avec le PaaS les choix appartiennent plus à l’offreur du service qu’à l’entreprise qui doit se plier aux décisions de son

PAG

E 12

prestataire. Ne soyons pas caricaturaux, et reconnaissons à certains fournisseurs une large ouverture. Mais d’autres se montrent plus restrictifs : CloudFoundry impose par exemple d’utiliser le Framework Spring dès lors que l’on choisit la filière Java.

Imposer des frameworks, et donc des normes aux développeurs, constitue un moyen de raccourcir les délais de développement en réduisant la procédure de prise de décision et en unifiant les développements autour d’un socle commun sur lequel capitaliser de l’expérience et de l’expertise. Ceci étant, cette rationalisation imposée ne convient pas forcément aux grands groupes qui possèdent un historique important, voire même une « culture technique » accumulée au fil du temps, et qui effectuent des choix stratégique de normalisation sur des environnements de développement qu’ils définissent eux-mêmes au plus près de leurs besoins métier.

1.6 Gérer les architectures hybrides avec le PaaS

Le modèle du Cloud public ne constitue pas une panacée pour les grands groupes qui se montrent plus intéressés par le fonctionnement sur un modèle hybride où les applications résultent de combinaisons de traitements internes et de traitements abrités sur le Cloud public. Ceci résulte en particulier de la volonté de rester maître de certaines données sensibles et de certains traitements critiques dont le déplacement vers l’extérieur ne paraît pas envisageable pour des raisons stratégiques, légales et de politique technique interne. Cependant, le mode de fonctionnement hybride suppose de disposer de bonnes possibilités d’interfaçage entre IT interne et Cloud, couvrant les différentes dimensions techniques mises en jeu dans ce mode de fonctionnement : interfaçage logiciel par le biais d’APIs et de SDKs, interfaçage de sécurité par le biais d’outils d’IAM (Identity and Access Management), transferts de données, et même interfaçage des fonctions d’administration et de monitoring que nous traiterons plus bas.

Voici une liste de points de vigilance et de constats sur les domaines Sécurité, Identity and Access Management, Transfert de données :

IAM : De façon générale, l’interfaçage des solutions PaaS avec les annuaires d’entreprise pour la mise en place de chaînes IAM est théoriquement largement faisable, mais dans la réalité mal pris en compte à ce jour.

• Il est difficile d’intégrer les annuaires d’entreprise avec les plates-formes PaaS (y compris lorsqu’un même éditeur fournit les deux, comme dans le cas d’Active Directory avec Azure !)

• Le protocole LDAP ne s’avère pas fonctionnellement suffisant pour la gestion du mode hybride. Connections / versions / NTLM ... des problèmes techniques rendent cette feature Microsoft affichée difficile à mettre en œuvre au sein des applications (en effet, ce sont les développeurs qui doivent la mettre en place, qui ne sont pas forcéments des expertes IAM). Le protocole standard d’échange d’informations de sécurité SAML reste peu répandu

• L’intégration d’une PKI avec un service de Cloud public reste difficile• Des protocoles d’authentification comme OpenID et OAuth sont encore rarement

supportés nativement par les offres PaaS.

CLO

UD

CO

MP

UTI

NG

: P

aas,

Séc

urité

et C

loud

, Sou

rcin

g, fa

ctur

atio

n et

ref

actu

ratio

n de

s se

rvic

es C

loud

, Obs

erva

toir

e H

PC

PAG

E 13

Li

VRE

BLA

NC

Relevons cependant qu’une meilleure prise en compte des fonctions de gestion d’Identités figure dans le calendrier d’évolution de plusieurs fournisseurs.

Sécurité :

• Les souscripteurs à un service PaaS ne disposent que de peu de visibilité sur les mécanismes de la plate-forme. Rien n’est prévu pour leur permettre de descendre dans les couches basses du système, et le niveau de contrôle reste faible. Les garanties de service sont faibles ou inexistantes. Il y a donc encore un problème de sécurité avec le PaaS alors que les équipes sécurité ont commencé à accepter l’utilisation de services IaaS.

• La question des droits à attribuer aux consommateurs de PaaS (administration complète, partielle, temporaire, etc.) reste ouverte en l’absence de bonnes pratiques claires. Ces bonnes pratiques doivent en général être établies, appliquées et surveillées par les équipes sécurité des clients du PaaS .

Transfert de données :

De façon générale, nous constatons la faiblesse actuelle de la prise en compte des besoins d’import et d’export de données depuis et vers les plates-formes PaaS.

• Ce point est difficile à adresser efficacement, en particulier du fait des importantes volumétries à faire transiter entre infrastructures publiques et privées.

• Pour l’initialisation de bases de données (du fait du volume initial) ou la récupération de données, la méthode manuelle qui consiste à envoyer un disque dur vers son prestataire de services reste très efficace.

• Les outils et protocoles classiques et standards sont peu adaptés au Cloud public et pas toujours intégrés ou intégrables.

Le fonctionnement en mode échanges de fichiers reste souvent impossible :- CFT pour les gros transferts de fichiers est inutilisable- la fiabilisation des échanges nécessiterait de réinventer un mécanisme de

sécurité par-dessus http par exemple, sachant que ce protocole n’assure pas de garantie d’acheminement.

• Quelques vendeurs commencent à proposer des solutions (appliances de transfert, logiciels dédiés, partenariats) pour gérer et optimiser les transferts.

Sur l’ensemble de ces sujets, une offre de type Middleware-as-a-Service voit le jour afin de prendre en compte les problématiques d’acheminement et les connecteurs. Les fournisseurs Cloud ont compris qu’il y avait un marché à explorer.

1.7 Administration et Exploitation des offres PaaS

Ce domaine souffre lui aussi d’une maturité peu avancée au regard des standards auxquels sont habituées les grandes entreprises avec leurs outils internes.

Deux tendances se dégagent actuellement, pas toujours mutuellement exclusives :

• La mise à disposition d’une console Web d’administration• La mise à disposition d’un système de commandes shell avec options (CLI pour le

déploiement et l’administration).

PAG

E 14

Les fonctions standards actuelles fournies par les prestataires PaaS sont : gestion du compte, upload, paramétrage, supervision, contrôle de l’usage (facturation), etc. De nombreuses faiblesses persistent concernant l’intégration de ces outils avec les processus d’exploitation des entreprises, ainsi que pour la gestion des opérations de sauvegarde et restauration. L’interface en mode CLI offre l’avantage de pouvoir être intégrée assez aisément dans des automatismes existants, qu’il s’agisse de scripts de pilotage préexistants ou construits pour l’occasion, ou bien encore de logiciels de pilotage ou d’orchestration dès lors qu’ils disposent de la capacité d’invoquer des commandes externes. Mais dans ce contexte, si tout est possible, tout reste à faire pour intégrer l’administration et l’exploitation d’une plate-forme PaaS dans un dispositif existant. A contrario, une console web d’administration offre l’avantage d’une prise en main plus rapide, avec des fonctions plus évoluées de pilotage et de gestion de la performance, mais elle impose alors un outil supplémentaire aux métiers (intégrateurs d’exploitation, pilotes d’exploitation) ce qui n’est pas souhaité lorsque l’on cherche à optimiser son exploitation en rationalisant les outils.

Exemple ci-dessous : le dashboard de la console web Google App Engine

En matière d’administration, un problème particulièrement préoccupant apparait. Les montées de versions des composants de la plate-forme PaaS ne sont pas négociables, et parfois imposées sans information préalable et suffisamment claire du client. Cette façon de procéder impacte le cycle de vie des applications, et en particulier le financement de leurs évolutions par les métiers utilisateurs. En effet dans un tel modèle il devient impossible après un développement initial de laisser fonctionner plusieurs années durant une application sans lui apporter de modifications ; il y a contrainte de mise à jour technique – et donc de coûts de mise à jour – avec une valeur ajoutée métier nulle.

CLO

UD

CO

MP

UTI

NG

: P

aas,

Séc

urité

et C

loud

, Sou

rcin

g, fa

ctur

atio

n et

ref

actu

ratio

n de

s se

rvic

es C

loud

, Obs

erva

toir

e H

PC

PAG

E 15

Li

VRE

BLA

NC

Les fonctions de supervision, de gestion de performances et d’émission d’alertes restent limitées.

En conclusion : quelques fournisseurs en pointe proposent une console web avec un niveau fonctionnel qui permet de piloter et superviser la plate-forme. D’autres se contentent pour démarrer du mode CLI. Pour une petite entreprise, une console web peut éventuellement suffire en l’état pour piloter une application en PaaS à condition d’accepter d’intégrer un outil spécifique. Pour les entreprises plus cadrées au niveau exploitation, c’est le problème d’intégration avec les outils existants et les processus d’exploitation qui peut être rédhibitoire.

Ci-dessous quelques exemples de points d’attention et questions opérationnelles à se poser avant de se lancer dans le PaaS public :

Alertes de disponibilité et informations de performance (capacity management) :

• qui les consomme et devrait les recevoir : développeurs ? Équipes de production ?

• qu’a-t-on réellement besoin de superviser sur une plateforme PaaS (à choisir judicieusement car superviser du PaaS est plus complexe que de l’IaaS) ?

• doit-on installer des frameworks dédiés à la gestion et l’analyse des performances ?

• y en a-t-il de fournis dans les offres PaaS ?

Backup :

• à quel niveau sauvegarder les données: IaaS (basique, générique) ou PaaS (intelligent, portable, par objet métier) ?

• doit-on utiliser les outils de sauvegarde du fournisseur (PaaS public) ou implémenter ses propres méthodes (ex snapshots)?

1.8 Modèles économiques et engagements de qualité de service

Les modèles économiques du Cloud restent complexes, et le PaaS n’échappe pas à la règle. Les modèles suivants se rencontrent tous, et parfois même plusieurs d’entre eux cohabitent chez un même fournisseur :

• Facturation à la ressource avec des niveaux de détail très variable dans la définition de cette ressource (puissance processeur, entrées-sorties disques, écritures dans des bases de données, mémoire vive, volume de stockage, etc.)

• Packs forfaitaires avec produits d’appels et planchers, plafonds, seuils d’utilisation.

• Facturation modulaire par services sous forme de plug-in payants ajoutés sur une base.

PAG

E 16

Cette complexité incite à se poser la question de l’optimisation des coûts, éventuellement en prenant en compte les spécificités du modèle de facturation pour les intégrer dans le développement. Si un fournisseur facture les entrées-sorties d’une base de données à un coût plus élevé que celui qu’il ne facture pour de la mémoire vive, il faudra privilégier un fonctionnement de type en mémoire dans la conception des applications pour de simples raisons économiques. Le mode de facturation pourrait dicter dans une certaine mesure l’architecture interne du développement, ce qui serait contraire aux bonnes pratiques d’architecture. L’architecte doit parvenir à conserver sur le Cloud des principes d’architectures indépendants des modalités de facturation de ses fournisseurs, en raison de leur caractère hautement volatile en comparaison de la durée de vie des applicatifs.

La complexité de cette tarification se double de risques de modifications unilatérales du modèle économique, peu de fournisseurs s’engageant à conserver sur des durées raisonnables un mode de facturation. Fin 2011, Google a par exemple décidé de modifier les paramètres de facturation de sa plate-forme App Engine (en passant du mode bêta qui existait auparavant au mode actuel).

Enfin, comme nous l’avons déjà souligné, les engagements de SLA et de disponibilité restent faibles, et les garanties en matière de sécurité ou de temps de réponse quasi nulles.

1.9 Réversibilité, portabilité entre plates-formes

Comment en sortir ? Comment déplacer des applications développées sur une plate-forme PaaS vers une autre, ou comment les rapatrier en interne ? Pour le moment la situation n’est pas réellement adressée par les fournisseurs. Dans certains cas, l’utilisation d’API et de frameworks propriétaires, le manque de contrôle sur les versions des composants utilisés constituent autant de freins à la portabilité. Même pour un PaaS fondé sur une pile relativement standardisée comme LAMP (Linux, Apache, MySQL, PHP) ou ses équivalents, le prestataire de services conserve la main sur les versions de socle qu’il met en œuvre. Et pour des raisons de coût d’exploitation il ne maintiendra probablement qu’une mince combinaison de socles. Dans ces conditions, il paraît assez difficile à ce jour d’être certain de trouver une plate-forme concurrente de celle sur laquelle a été effectué un premier développement et qui offre une compatibilité suffisante pour autoriser un portage. La récupération des données n’a pour sa part pas été prévue, il faudra donc traiter en mode applicatif ce type d’opération, en développant une passerelle spécifique.

Il n’existe de fait aucun standard qui garantirait la portabilité entre plates-formes, même si quelques initiatives commencent à voir le jour. Nous ne pouvons qu’appeler à un travail de la part d’organisations internationales qui seraient en mesure de définir un cadre de portabilité.

1.10 Conclusion

A ce stade, le PaaS apparaît comme un domaine en pleine croissance, et de ce fait en quête de maturité. On oserait dire que le PaaS a la figure d’un adolescent du Cloud : prometteur, mais pas encore totalement formé, même si certains éléments se laissent deviner.

CLO

UD

CO

MP

UTI

NG

: P

aas,

Séc

urité

et C

loud

, Sou

rcin

g, fa

ctur

atio

n et

ref

actu

ratio

n de

s se

rvic

es C

loud

, Obs

erva

toir

e H

PC

PAG

E 17

Li

VRE

BLA

NC

Il monte en puissance à la fois comme une extension logique de l’IaaS, mais aussi comme une déclinaison du SaaS, puisque certains éditeurs proposent des extensions PaaS à leurs offres SaaS. Il porte plusieurs promesses.

• Accélérer radicalement la mise à disposition d’environnements complets.

• Contribuer à l’agilité du cycle Développement/Production, en réduisant en particulier les écarts existant aujourd’hui entre ces environnements. Une telle évolution peut s’inscrire dans une démarche comme celle proposée par le mouvement Devops. Il s’agit au bout du compte de réduire les temps de Time-to-Market lors de la création de nouvelles applications et de la mise à disposition de nouveaux services.

• Automatiser les opérations de provisioning mais aussi de libération de ressources lorsqu’elles ne se trouvent plus sollicitées. Ce point vise un double objectif : apporter une réponse calquée au mieux sur les besoins des métiers d’une part, optimiser les coûts en ajustant l’usage des ressources de l’autre.

• Le PaaS dessine et cadre de nouveaux patterns d’architecture technique et

logicielle (web 2.0) qui amèneront une évolution des métiers de l’informatique chargés de sa mise en œuvre.

Intéressantes promesses, mais qui restent baignées de beaucoup de flou. L’offre jeune, en phase de croissance, est encore très diversifiée, avec des acteurs majeurs et des challengers, pas stabilisée ni standardisée, et cette absence de standards lui nuit. De plus il s’agit pour le moment le plus souvent d’offres externes, de type public. Cela correspond dès maintenant aux besoins des petites structures, mais ne rentre pas dans les exigences des grandes entreprises qui exercent un contrôle plus étroit sur leurs environnements techniques. Et le modèle économique reste sinon confus du moins peu lisible. Il devra être simplifié.

Bien sûr, les concepts du PaaS s’avèrent dès maintenant en phase avec les besoins de certains projets, mais les offres ne correspondent pas à une possibilité de mise en production maîtrisée comme cela se pratique dans les grandes structures. Des fonctionnalités manquent : le fonctionnement en mode hybride, les outils de pilotage nous semblent les plus critiques, ainsi que l’absence de réversibilité. Les fournisseurs promettent de prochaines déclinaisons de leurs plates-formes sous forme de PaaS privés, mais en attendant, les entreprises intéressées doivent concevoir leur PaaS elles-mêmes.

Aujourd’hui le PaaS constitue déjà une plate-forme de choix pour la réalisation de maquettes, ou pour des applications à cycle de vie rapide, jetables au bout de quelques mois, et qui ne réintégreront jamais pleinement le SI de l’entreprise. Mais il ne semble pas encore mûr pour une production pleinement contrôlée. Cela ne saurait qu’évoluer dans les prochains mois.

PAG

E 18

SéCURITé ET CLOUD COMPUTING

On sait que la sécurité fonctionne transversalement à toute démarche d’Infrastructure et Production ; tout projet demande donc de se poser une double question :

• Quels risques de sécurité découlent de ce nouveau projet ?• Quels moyens faudra-t-il mettre en œuvre pour assurer la sécurité ?

Et à quel coût ?

La sécurité se pense donc toujours sur deux fronts : une démarche technique de sécurisation et une démarche de réflexion sur les impacts de l’introduction d’un nouveau composant du Système d’Information. Le Cloud Computing n’échappe pas à la règle, on peut même dire qu’il l’illustre de façon excellente. Non seulement assurer la sécurité du Cloud pose problème, mais en plus les effets de bord de ses usages sur la sécurité restent encore difficiles à appréhender.

Nous souhaitons ici exposer l’état de nos réflexions sur le sujet, mais aussi affirmer que la défiance ne suffit pas. Le Cloud Computing provoque une série de ruptures dans la Production comme dans la consommation des services informatiques. Ces ruptures affecteront les organisations et doivent s’accompagner d’une réflexion sur la sécurité.

De même que le modèle client-serveur a remis en cause les modèles de sécurité issus de l’Informatique centralisée, de même que les architectures Web ont remis en cause les modèles de sécurité des architectures client-serveur, le Cloud Computing demandera une extension des paradigmes de sécurité. Il n’y va d’ailleurs pas que de la protection des avoirs numériques de l’entreprise et de sa réputation, mais aussi de son futur fonctionnement et de sa future agilité.

2.1. Le Cloud vu par les RSSI

La pression mise par les utilisateurs et les métiers sur les directions informatiques rend incontournable à plus ou moins brève échéance le recours au Cloud. Mais les questions de sécurité et d’intégration à l’existant constituent un frein majeur à une adoption rapide et massive de ces solutions.

Les RSSI, dont c’est la fonction, rappellent qu’il n’est pas question de laisser leurs données circuler n’importe où, et en particulier dans des environnements tiers dont le contrôle échappe entièrement à l’entreprise. L’exigence de confidentialité doit s’appliquer. Une première solution consisterait à trier, à définir dans une politique de sécurité d’entreprise quelles données peuvent ou ne peuvent pas sortir de l’enceinte numérique directement sous contrôle de la RSSI. Plus facile à dire qu’à faire, car comme le rappelle un RSSI : “Passer sur le Cloud pose le difficile problème de la qualification des données. Comment définir ce qui est confidentiel et ce qui ne l’est pas ? ”.

2

CLO

UD

CO

MP

UTI

NG

: P

aas,

Séc

urité

et C

loud

, Sou

rcin

g, fa

ctur

atio

n et

ref

actu

ratio

n de

s se

rvic

es C

loud

, Obs

erva

toir

e H

PC

PAG

E 19

Li

VRE

BLA

NC

Ce problème possède lui aussi une double composante. Il n’est pas toujours simple de savoir et de décrire dans une politique d’entreprise ce qui est confidentiel, si on en excepte les documents soumis à réglementation. Mais il est encore moins simple d’exiger des utilisateurs qu’ils classifient tout document, tout fragment d’information qu’ils produisent, sur une échelle de confidentialité. Il faut donc atteindre le bon niveau d’automatisation, mais aussi de responsabilisation pour les informations qui ne peuvent se voir automatiquement cataloguées.

Comme l’affirme un autre RSSI : “La sécurité ne se juge pas seulement en termes de confidentialité des données, nous avons aussi une responsabilité dans leur disponibilité.” Ce point n’a pas moins d’importance que le précédent. Les problèmes de confidentialité et de sécurité se trouvent de plus en plus liés. Une faille de sécurité risque très souvent de se traduire par un problème d’indisponibilité (s’il faut remonter une base de données corrompue, faire le ménage dans des informations modifiées hors de tout contrôle, mettre fin à une attaque par déni de service, etc.). La disponibilité n’est que l’autre face de la sécurité. Or, les fournisseurs Cloud externes ne brillent pas par la qualité de leurs clauses contractuelles en matière de disponibilité.

Nous pouvons étendre ce problème en considérant que le Cloud pose aujourd’hui un problème global de contrôle qui se manifeste dans de multiples objections à son usage : contrôle des politiques de sécurité des fournisseurs au sein de leur Cloud, contrôle de la disponibilité des services, contrôle des échanges entre l’IT interne et les différentes formes de Cloud, contrôle des conditions de cohabitation entre applications et entre clients.

D’autre part, les DSI ne peuvent que constater que l’utilisation du Cloud se propage au sein de leur écosystème via l’adoption sauvage par les salariés de services proposés par des sociétés tierces telles Dropbox, Google Docs, iCloud, etc. Ces usages, difficiles à bannir dans un contexte d’environnements de travail de plus en plus mobiles et connectés, posent les mêmes questions que l’adoption du Cloud en interne : quid de la sécurité des données ? Comment éduquer efficacement les utilisateurs sans empiéter sur leur vie privée ? Comment sensibiliser aux risques une population pour laquelle l’usage du Cloud représente avant tout un gain de productivité ?

a) Craintes liées au Cloud

Les principales craintes évoquées lorsque l’on parle de Cloud concernent la confidentialité, la disponibilité et l’étanchéité des données et des charges applicatives. Ce dernier point, celui de la promiscuité applicative, est particulièrement critique. L’isolation des workloads sensibles et/ou critiques est une règle rarement ignorée en entreprise. Le Cloud, reposant sur un principe de mutualisation systématique et poussée ne connaît pas ce mode de fonctionnement. L’entreprise ne contrôle pas le placement de ses applications, ce qui constitue une menace potentielle pour leur disponibilité comme pour l’intégrité des données qui y résident.Le premier élément de réponse réside dans le choix du type de Cloud à adopter : privé ou public, interne ou externe. Il est à noter que de par sa nature, ce choix n’est le plus souvent pas du ressort du CTO, mais de la DSI et du RSSI.

PAG

E 20

Alors qu’un Cloud public-externe présente à priori un intérêt financier plus grand qu’un Cloud privé-interne ou même qu’un Cloud privé-externe, il pâtit souvent du manque de confiance que les RSSI ont en leur prestataire et de l’imparfaite transparence dont font preuve ces prestataires quant aux garanties qu’ils apportent à leurs clients. “Il existe avec le Cloud pour le moment un problème de confiance, on ne sait pas à quel point faire confiance à ces acteurs.”, confirme un troisième RSSI.

Si le Cloud public convient à certains usages (développement, tests, recette), l’utilisation d’un Cloud privé externe offre davantage de garanties, notamment via la possibilité d’auditer la plateforme dédiée à l’entreprise. Cependant, certains RSSI n’accordent que peu de crédit à la pratique d’audits : “Je ne crois pas à la clause d’audit. On paie pour envoyer un auditeur, très bien, mais finalement le prestataire peut très bien ne pas respecter les recommandations que nous lui faisons.” Certaines clauses contractuelles permettent cependant d’engager le fournisseur à mettre en œuvre les mesures préconisées.

Alors que la certification apparaît comme un recours possible, d’autres réticences apparaissent : “Les certifications telles qu’elles existent ne nous disent rien sur la sécurité réelle mise en place. Même au travers d’une certification, comment allez-vous apprendre que votre prestataire a par exemple déplacé ses administrateurs en Inde ?”.

Les RSSI s’accordent à partir de là à considérer qu’un usage du Cloud – modéré - est acceptable pour certaines catégories de données, non-sensibles, ou dans un contexte de chiffrement qui lève les problèmes de confidentialité. Mais comme le rappelle un membre du Groupe de Travail : “Le problème avec les données n’est pas tant leur isolement, leur protection, que leur sélection avant de leur appliquer des politiques et traitements.” De plus, les RSSI constatent que l’application à grande échelle des pratiques de chiffrement reste complexe, et d’autant plus complexe que l’utilisateur conserve la responsabilité de pratiquer ou pas ce chiffrement.

Il faut garder à l’esprit que le point de vue d’un responsable de production informatique d’une PME qui remplit en général également les fonctions de DSI/RSSI peut être très voire radicalement différent. En effet, certaines PME se considèrent plus sécurisées sur un cloud opéré par un grand fournisseur que lorsque c’est la PME elle-même qui opère l’infrastructure (problématique des compétences et de la masse critique des équipes).

b) Avantages/Inconvénients

Il est nécessaire de rappeler les avantages et les limites que le Cloud procure en raison de son modèle de fonctionnement. Ces avantages sont principalement économiques. En effet, le Cloud présente de très bons coûts initiaux, mais qui évoluent ensuite linéairement; tandis qu’avec des plates-formes internes les coûts initiaux élevés tendent à s’affaiblir avec le volume d’utilisation.La tarification à l’usage permet d’envisager des gains importants sur les environnements de tests ou de recettes qui ne font pas l’objet d’un usage intensif mais qui immobilisent des ressources de l’entreprise.

CLO

UD

CO

MP

UTI

NG

: P

aas,

Séc

urité

et C

loud

, Sou

rcin

g, fa

ctur

atio

n et

ref

actu

ratio

n de

s se

rvic

es C

loud

, Obs

erva

toir

e H

PC

PAG

E 21

Li

VRE

BLA

NC

Dans l’estimation de ces gains, il faudra pour être complet prendre en compte les coûts de mise en place de l’infrastructure de sécurité permettant de faire dialoguer les serveurs mis sur le cloud et ceux qui restent dans l’entreprise (les cas où on peut mettre des serveurs sur le cloud sans avoir ensuite besoin de dialoguer avec l’interne sont marginaux).

Le Cloud bénéficie aussi des avantages de standardisation et de mises à jour continues qui permettent de résoudre les problèmes de gestion de l’obsolescence ou encore d’apporter une réponse aux clients sur le “no software” (éviter les fastidieux processus d’installation et de mises à jour de logiciels). Toutefois, certaines limites apparaissent dans ce modèle. En particulier le fait que les mises à jour soient déclenchées par le fournisseur. Le client doit suivre, en espérant que la mise à jour ne casse rien, ne provoque aucun désordre. Notons au passage que ces problématiques ne sont, en général, pas traitées, vu des DSI ou RSSI, de façon satisfaisante et que le passage au cloud est, de ce point de vue, perçu comme une véritable opportunité (on se débarrasse du problème en passant au cloud).

2.2. Questions de sécurité indiscrètes pour votre (futur ?) fournisseur de Cloud

A la lumière des échanges du Groupe de Travail Cloud, voici une liste de questions à poser à un prestataire concernant la dimension sécurité et disponibilité de son offre Cloud.

• Vos politiques de sécurité sont-elles écrites et consultables ? OUI NON

• Quels sont les indicateurs relatifs à la sécurité que vous publiez ?

• Quelle est votre politique d’application des patches de sécurité critique ?

• Le client a-t-il un droit de regard/veto sur ce type de mise à jour ? OUI NON

• Est-il informé du passage d’un patch critique ? OUI NON

• Proposez-vous des sauvegardes ? OUI NON

• Les échanges de données et les sauvegardes sont-ils chiffrés ? OUI NON

• Vérifiés ? OUI NON

• Selon quelles procédures ?

• Comment faites-vous la gestion des clés de chiffrement ?

• Quels sont les débits offerts en sauvegarde/restauration ?

• Votre solution complète est-elle certifiée ? (ISO 27001, SAS 70, ...) OUI NON

• Avant mise en production (d’un nouveau palier sur l’infrastructure Cloud), des tests d’intrusion sont-ils réalisés ? OUI NON

• Si oui, ces tests sont-ils effectués par des équipes maison ou par des équipes tierces ? OUI NON

• Quelle est votre politique de remédiation sur les failles rencontrées ?

• Proposez-vous des modes d’interfaçage avec les annuaires de vos clients ? OUI NON

• Le client peut-il gérer directement des pools de ressources mis à disposition sur le Cloud ? (une réponse positive à cette question indique l’existence d’accès depuis l’extérieur à des interfaces d’administration de ressources qui constituent un danger potentiel de sécurité élevé, et donc aussi la question de leur sécurisation)

OUI NON

PAG

E 22

2.3. Perspectives / Conclusion

Le concept de Cloud inclut de nombreuses nuances dont chacune peut être un élément de réponse à l’optimisation de votre SI. Si l’utilisation d’un Cloud public externe pose de nombreux problèmes de sécurité, il peut s’avérer tout à fait adéquat pour l’hébergement d’une plate-forme temporaire liée à un évènement ponctuel dont l’impact n’est pas clairement défini (exemple : jeu concours, campagne marketing ponctuelle, besoin urgent d’un serveur de développement pour un PoC). La mise en œuvre sera facilitée si cette plate-forme présente peu ou pas (cas idéal) d’adhérence avec le SI existant.

A l’opposé, l’adoption d’un Cloud Privé interne, simple implémentation d’une solution “sur étagère” proposée par un éditeur ou un constructeur, réduit considérablement l’impact des questions de sécurité tout en permettant de bénéficier de beaucoup d’avantages du Cloud tels que la fluidification de la mise à disposition de ressources, la simplification de la refacturation interne, l’assainissement de la gestion des cycles de vie, etc.

Mais pour certaines entreprises, l’adoption de services Cloud externes et internes constitue également une opportunité de repenser leur politique de sécurité globale, en l’appuyant notamment sur la forte standardisation qu’implique son adoption et en visant une simplification. Les réflexions en cours sur l’évolution des modèles de sécurité, pour passer en particulier à une logique de prise en compte de contexte global de connexion (qui se connecte à quoi depuis quel terminal et à quel endroit ?), montrent que le Cloud fera aussi sentir son effet dans ce domaine.

• Quels moyens de sécurité mettez-vous en œuvre en Interne ?

• Quelles remontées sur ces outils faites-vous vers vos clients (statistiques, logs partiels, au travers de quelles interfaces) ?

• Le client peut-il demander la mise en place de sondes IPS/IDS ? OUI NON

• Comment gérez-vous la mise à disposition de firewalls à vos clients ?

• Quel est le niveau de maîtrise par le client du filtrage de ports sur sa VM par exemple ?

• Idem pour les VLAN : quel est le niveau de délégation de la gestion du réseau donné au client ?

• Les réseaux d’administration sont-ils séparés des réseaux de fonctionnement normal comme c’est la règle dans une majorité de salles informatiques ? OUI NON

• Le client peut-il demander sur une plate-forme IaaS la mise à disposition d’images d’OS durcies ou sécurisées ? OUI NON

• Peut-il fournir ses propres images ? OUI NON

• Quels moyens d’interconnexion offrez-vous entre les datacenters du client et votre Cloud ?

• Quels sont les moyens mis en œuvre lors de la destruction d’une VM ?

• Comment blanchissez-vous les données hébergées sur votre infrastructure ? (cf. effacement sécurisé type DoD 5220.22-M)

CLO

UD

CO

MP

UTI

NG

: P

aas,

Séc

urité

et C

loud

, Sou

rcin

g, fa

ctur

atio

n et

ref

actu

ratio

n de

s se

rvic

es C

loud

, Obs

erva

toir

e H

PC

PAG

E 23

Li

VRE

BLA

NC

LES MODèLES DE SOURCING ET LE CLOUD

Le Groupe de Travail Cloud Computing du CRiP l’affirme depuis plusieurs années : le Cloud ne constitue pas une rupture technique mais d’abord une nouvelle façon de produire et de consommer des services IT.

Cette évolution se produit cependant sur un fond continu de problématiques, dont celle de l’approvisionnement et de la contractualisation que les anglo-saxons rassemblent sous le terme de sourcing. En effet, dès lors qu’il n’est plus strictement privé et internalisé, le Cloud Computing se présente sous la forme d’une prestation extérieure comparable mais pas similaire à des pratiques existantes comme l’infogérance, l’externalisation, l’hébergement, etc., ce qui pose la question des modalités d’achat et de suivi de la prestation Cloud.

En 2011, le CRIP et l’Ae-SCM (association de promotion des bonnes pratiques de sourcing et du Sourcing Capability Model, http://www.ae-scm.fr/) ont collaboré avec le Comité Infrastructures du Syntec Numérique pour la rédaction de son troisième livre blanc consacré au Cloud Computing et intitulé « Cloud Computing : nouveaux modèles ! »

Ce livre blanc, est accessible sur l’url : http://www.syntec-numerique.fr/Actualites/Livre-blanc-Cloud-Computing-Nouveaux-modeles

Il se compose de 6 chapitres allant des définitions de base et des modèles économiques aux conséquences du Cloud sur le rôle de la DSI. Il aborde en particulier les effets du modèle Cloud sur le « sourcing » des services IT.

Les lignes qui suivent présentent une synthèse de ce document sur les thèmes suivants :

• typologie des modèles de Cloud en fonction des types d’applications

• apports principaux du référentiel eSCM au mode de sourcing du Cloud Computing

• recommandations d’ordre juridique, formulées par deux avocats ayant contribué au livre blanc

3.1. Typologie des modèles de Cloud en fonction des types d’applica-tions : quels Clouds pour quelles applications ?

Le Livre Blanc Cloud Computing Nouveaux Modèles du Syntec Numérique décrit divers modèles de déploiement du Cloud :

• Privé internalisé : les infrastructures et les réseaux sont propriété de l’entreprise

3

PAG

E 24

• Privé externalisé : les infrastructures et les réseaux sont dédiés à l’entreprise mais éventuellement gérés par un tiers

• Public : infrastructure et réseaux sont externes à l’entreprise et partagés

• Hybride : un mélange des modèles précédents avec une partie interne à l’entreprise et une partie externe.

Le livre blanc positionne sur un graphe le mode de déploiement actuellement privilégié des applications en fonction de leur degré de spécificité et de criticité. Ce graphe prend en compte quatre zones possibles de déploiement : le Cloud Public, le Cloud Privé (Internalisé ou externalisé), les zones de virtualisation (les serveurs équipés d’hyperviseurs qui permettent donc un certain degré de consolidation) et enfin les silos d’applications (qui sont les ressources IT les plus spécifiques et critiques de l’entreprise, souvent issues de son héritage technique, et faiblement mutualisées).

Ce graphe présente des lignes directrices générales telles qu’elles sont constatées aujourd’hui, qui seront amenées à évoluer rapidement dans le temps. Il illustre bien le fait que le Cloud se caractérise d’abord par sa capacité importante à la flexibilité.

3.2. Les apports principaux du référentiel eSCM aux pratiques de sourcing du Cloud Computing

L’eSCM (e-Sourcing Capability Model) est un référentiel de bonnes pratiques pour la gestion de la relation entre clients et fournisseurs de services utilisant les technologies de l’information. Il a été conçu puis publié en 2002 par l’Université Carnegie Mellon qui l’a ensuite confié à sa spin-off l’ITSqc qui fournit des services de formation et assure la promotion de ce modèle, l’Ae-SCM est l’association qui favorise la diffusion et l’adoption du référentiel eSCM par le plus grand nombre d’entreprises en France.

CLO

UD

CO

MP

UTI

NG

: P

aas,

Séc

urité

et C

loud

, Sou

rcin

g, fa

ctur

atio

n et

ref

actu

ratio

n de

s se

rvic

es C

loud

, Obs

erva

toir

e H

PC

PAG

E 25

Li

VRE

BLA

NC

Le référentiel eSCM souhaite prendre place auprès des autres grands référentiels IT (ITIL, CMMI, etc.) avec lesquels il est compatible. Il prend en compte des modèles de fourniture d’IT de nature très variable : outsourcing, hébergement, TMA, fourniture de services réseaux et autres. Le Cloud Computing comportant une dimension d’externalisation, c’est tout naturellement que l’eSCM propose un référentiel pour le pilotage économique du Cloud Computing et la gestion des relations entre clients et fournisseurs de Services Cloud, externes ou internes à l’entreprise.

Dans cette démarche, l’eSCM recommande en particulier d’élaborer et de faire évoluer dans le temps un modèle économique (« business case ») des Services Cloud en considérant :

• l’évolution de la demande, en prenant en compte la montée à l’échelle et l’impact de la tarification,

• les bénéfices et coûts, y compris indirects et internes, par exemple la réduction grâce au Cloud de certains risques (disponibilité), ou bien l’accroissement par le Cloud de coûts indirects comme ceux des réseaux, etc.

• les bénéfices et coûts de transition, comme par exemple l’allocation automatique des ressources, la réduction de la durée des cycles Projets, etc.

eSCM recommande ensuite de prendre en compte les opportunités de création de valeurs apportées par le Cloud pour les clients, en articulant ces opportunités autour d’une liste de catégories :

• agilité/juste à temps,

• optimisation des ressources,

• coûts,

• conformité, qualité de service,

• cohérence technologique et interopérabilité,

• innovation par l’offre,

• innovation métier,

• différenciation.

PAG

E 26

eSCM identifie le besoin émergent, côté Clients, d’un rôle de Contrôleur de Services Cloud. Cette fonction pourrait être tenues par des acteurs indépendants à l’instar des auditeurs financiers. Le Contrôleur de Services Cloud aurait pour mission de s’assurer de la bonne réalisation des clauses contractuelles.

En ce qui concerne la contractualisation de services Cloud, eSCM propose une liste de plus de 50 points de contrôle, dont on citera les principaux :

CLO

UD

CO

MP

UTI

NG

: P

aas,

Séc

urité

et C

loud

, Sou

rcin

g, fa

ctur

atio

n et

ref

actu

ratio

n de

s se

rvic

es C

loud

, Obs

erva

toir

e H

PC

PAG

E 27

Li

VRE

BLA

NC

Enfin, eSCM identifie une évolution concernant les activités de pilotage opérationnel, tactique, ou stratégique des services Cloud, amenant à une nouvelle Gouvernance de l’externalisation. Ce tableau résume les éléments clé de ce paysage du pilotage opérationnel en environnement Cloud :

Comme on le voit, ces éléments de réflexion s’inscrivent dans la continuité directe de nos remarques sur l’évolution des Métiers présentes dans notre Livre Blanc 2011.

3.3. Recommandations d’ordre juridique sur les Contrats portant sur les services Cloud, formulées par deux avocats ayant contribué au livre blanc

Le Livre Blanc du Syntec numérique fait un point sur les considérations juridiques afférentes aux contrats de services Cloud. Nous en isolons les points suivants, qui nous semblent les plus saillants.

- Veiller aux garanties sur les données à caractère personnel en application de la loi Informatique et Libertés pour les données hébergées en France ; clause spécifique couvrant la confidentialité et l’intégrité des données confiées, avec des dispositions (audits de sécurité) afin de s’assurer de l’effectivité des garanties offertes en matière de protection des données. Point d’attention particulier pour les entreprises : savoir si le prestataire propose ou non les « model clauses » décidées par la Commission Européenne en 2010. Privilégier les contrats comprenant cette garantie importante.

- Le contrat doit aborder de manière précise la question des niveaux de service aussi bien dans leur description que dans les procédures attachées à leur suivi : périmètre d’engagement, mécanismes de calcul de respect ou de non-respect de ces niveaux de service, conservation des éléments de preuve, conséquences en cas de non-respect de ces engagements, mécanismes d’escalade en cas de désaccord entre les parties.

PAG

E 28

- Il ne faut pas oublier la question de la réversibilité : comprendre la fin du Contrat et définir les modalités de reprise de ce qui a été fourni en mode Cloud.

- Il importe de préparer la conclusion d’un contrat de service Cloud avec des équipes de travail transverses impliquant notamment les DSI, les métiers, les achats, ainsi que les juristes et les avocats.

FACTURATION ET REFACTURATION DANS LE CLOUD

La facturation à l’usage est un des piliers du Cloud Computing : cela se comprend simplement. Si nous voulons « l’informatique à la demande », nous voulons que son impact financier apparaisse « à la demande » aussi !

Le principe établi, restent quelques questions :

• Dans le cadre du déploiement d’un Cloud de type privé, comment mettre en place une facturation des services à l’usage, quels sont les critères pertinents sur lesquels fonder cette facturation ?

• Ce Cloud privé peut-il être une étape vers un service de refacturation interne ?

• Comment aborder le Cloud public en terme de refacturation et métriques dans les usages budgétaires d’une société ?

• Sans oublier des approches qui peuvent être différentes dès que l’on parle de IaaS, PaaS ou SaaS …

Toutes ces questions ont été discutées lors des réunions du Groupe de Travail Cloud Computing. Ce document reprend les thématiques abordées et propose des pistes d’investigation.

4.1. Collecte des métriques

Dans un contexte de réduction des coûts IT, préoccupation permanente des directions Infrastructures, les projets de consolidation et de mutualisation de la Production informatique, en s’appuyant sur une virtualisation de plus en plus poussée, ne sauraient être menés sans une gestion des capacités appropriée. La virtualisation des infrastructures se généralise, elle exige effectivement ce type de démarche : connaître la capacité disponible, optimiser le taux d’usage, anticiper l’accroissement des ressources en fonction des besoins, pour ne citer que les points clés.

4

CLO

UD

CO

MP

UTI

NG

: P

aas,

Séc

urité

et C

loud

, Sou

rcin

g, fa

ctur

atio

n et

ref

actu

ratio

n de

s se

rvic

es C

loud

, Obs

erva

toir

e H

PC

PAG

E 29

Li

VRE

BLA

NC

Avant même la transformation d’une infrastructure de production en Cloud privé, l’identification des indicateurs signifiants pour la maîtrise du « Capacity Management » constitue une étape essentielle.

A titre d’illustration, le « schéma capacitaire » ci-dessous, représente les différents indicateurs et leur niveau d’agrégation :

Au-delà des métriques techniques, qui correspondent à l’usage effectif des ressources d’infrastructures (Processeurs utilisés, mémoire, stockage, bande passante réseau, nombre de requêtes, etc.), il convient aussi de mesurer le niveau de service (taux de disponibilité, temps de réponse, etc.) et des indicateurs sur la nature même de l’activité métier (nombre de transactions réalisées, nombre d’utilisateurs d’un service, quantité de flux échangés, etc.)

PAG

E 30

4.1.1 Métriques techniques

Les premiers indicateurs sont des métriques techniques qui mesurent l’utilisation et la disponibilité des infrastructures, par exemple :

• Taux d’usage des serveurs : CPU, Mips, nombre de serveurs virtuels, etc.,

• Occupation de la mémoire : RAM,

• Stockage : espace alloué, taux d’utilisation (nombre d’I/O), taille des blocs, type de supports utilisés (high-end, mid-range, archivage),

• Réseau : taux d’usage de la bande passante, (Mo entrants, Mo sortants).

Dans cette classe d’indicateurs, la mise en équivalence des taux d’usage des serveurs (taux CPU) permet d’introduire une unité d’œuvre indépendante de la nature et de la puissance individuelle des différents serveurs. Cette unité de mesure « équivalente 1 » constitue ainsi un indicateur d’usage de la puissance serveur consommée, quelle que soit la puissance spécifique du type de processeur utilisé et de l’operating System (Linux, Windows, Unix). Ce type d’unité d’œuvre est effectivement utile pour mesurer et refacturer l’usage des serveurs en fonction des projets ou des applications.

Pour les fournisseurs de service « IaaS », la facturation se calcule généralement en fonction du trafic, du stockage et de la puissance des processeurs utilisés. Selon le type et le nombre de machines virtuelles mises à disposition, le fournisseur détermine la puissance processeur utilisée.

Dans le cadre de services « PaaS », des variables complémentaires peuvent être prises en compte, en complément des métriques propres à l’usage « IaaS ».

Cette seconde classe de métriques s’adresse à l’usage des middlewares – par exemple :

• Nombre de requêtes SGBD (Oracle, Mysql, etc.),

• Nombre de requêtes HTTP,

• Temps de traitement des requêtes transactionnelles (Tomcat, Jboss).

Cette classe de métriques rend possible la ventilation des coûts logiciels Middlewares, en fonction de leur usage, par application ou projet.

Le coût prévisionnel d’une infrastructure « IaaS », voire « PaaS », compte tenu de la variabilité des indicateurs retenus, peut s’avérer complexe à déterminer. A titre d’exemple, l’hébergeur Amazon propose une grille d’évaluation pour estimer le coût mensuel d’hébergement2 sur ses infrastructures :1 A titre d’exemple, on peut citer des unités de mesure standardisées comme celles que propose le Transaction Processing Performance Council (TPC-C, TPC-H, etc) ou le Standard Performance Evaluation Corporation (SpecCPU, SpecVirt, etc.) ou des unités propriétaires comme le SMIPS proposé par Systar2 Amazon Simple Monthly Calculator (http://calculator.s3.amazonaws.com/calc5.html)

CLO

UD

CO

MP

UTI

NG

: P

aas,

Séc

urité

et C

loud

, Sou

rcin

g, fa

ctur

atio

n et

ref

actu

ratio

n de

s se

rvic

es C

loud

, Obs

erva

toir

e H

PC

PAG

E 31

Li

VRE

BLA

NC

On pourrait imaginer, à l’instar de l’usage de l’électricité, que les services Cloud deviennent une « commodité » dont la facturation fasse abstraction de la complexité et de la nature des composantes d’infrastructures sous-jacentes. Ainsi, la facturation pourrait être consolidée sur la base d’un coût fixe (CAPEX) et d’une unité d’œuvre (OPEX) inspirée de l’énergie :

[ABO > accès au service Cloud] Coût fixe (~abonnement) [CUH > Cloud Unit per hour] Coût variable (~consommation)

4.1.2 Métriques SLA’s

Cette catégorie de métriques permet de mesurer le niveau de service et d’appliquer ensuite une facturation en fonction d’une grille adaptative, par application et selon la nature du contrat SLA. Cette catégorie de métriques comprend par exemple :

• Le taux de disponibilité,• Le temps de reprise sur incident,• Le temps de réponse,• Système de pénalités en cas de non-respect des clauses du SLA,• Etc. …

Une unité d’œuvre incluant les « métriques SLA’s » ou impactant le total par un coefficient de pondération permettrait d’établir une facturation en fonction des engagements de service et impliquerait par conséquent de la part du fournisseur d’infrastructures (hébergeur ou Cloud privé) un engagement sur les moyens mis en œuvre et sur les résultats.

PAG

E 32

4.1.3 Métriques Métiers ou Business

Pour le responsable de projet, les métriques techniques ne parviennent pas forcément à qualifier de façon pertinente la nature des flux qui auraient plutôt du sens d’un point de vue « métier ». L’engagement sur le résultat importe plus du point de vue métier que l’engagement sur les moyens. Ce constat s’applique en premier lieu aux solutions de type « SaaS », où l’utilisateur achète un service final comme une boite mail, une feuille de paie …

Pour bien comprendre : la garantie d’un taux de disponibilité (engagement de moyens) de 99,999 % pour des serveurs en mode « IaaS » rassure le métier. Mais cela ne garantit pas que les pages Web se chargeront dans un délai raisonnable pour l’internaute lors de pics de trafic, ni que la gestion de capacité associée aux infrastructures permettra la livraison effective du service, notamment dans un mode « SaaS » (exemple : un site évènementiel mis en place pour une durée définie et couplé à une campagne marketing : le site doit être en mesure d’encaisser une forte montée en charge, qui peut dépasser les prévisions).

L’alignement des services d’infrastructure sur les indicateurs métiers plutôt que sur les indicateurs techniques implique aussi la mise à plat des composantes du contrat de service et des indicateurs pris en compte pour facturer à l’usage.

Ces métriques devraient constituer également autant « d’indicateurs pertinents » en fonction de la nature du métier et de l’application. Pour un site de e-commerce par exemple, le nombre de transactions réellement abouties est plus critique que le nombre de pages vues. Dans ce cas, baser la facturation à l’usage sur ce nombre de transactions suppose effectivement que les métriques techniques, qui restent significatives pour suivre et adapter l’usage de l’infrastructure sous-jacente, soient suffisamment efficientes pour adapter l’infrastructure en fonction du trafic.

La mise en place d’une solution BAM3, permettant la collecte et l’agrégation d’indicateurs clés (KPI4) correspondant à l’activité réelle des processus métiers, pourrait être déployée pour « mesurer » l’activité métier supportée par l’infrastructure Cloud et par suite intégrer ces « métriques métiers » dans le système de facturation.

L’adoption d’un modèle de facturation aligné avec les indicateurs métiers ne présente pas a priori d’obstacle technique. Elle implique cependant un profond changement de culture et d’adaptation pour répondre aux exigences des métiers, en termes de « commodité » d’usage des services Cloud (hébergés ou via un « cloud privé ») et de transparence des coûts (payer au juste prix ce que l’on consomme !).

3 Business Activity Monitoring – Supervision des activités de l’entreprise4 Key Performance Index – ou « Indicateurs clés de performance »

CLO

UD

CO

MP

UTI

NG

: P

aas,

Séc

urité

et C

loud

, Sou

rcin

g, fa

ctur

atio

n et

ref

actu

ratio

n de

s se

rvic

es C

loud

, Obs

erva

toir

e H

PC

PAG

E 33

Li

VRE

BLA

NC

4.2. Reventilation des coûts : Showback ou Chargeback

La collecte des différentes métriques (techniques, SLAs, Métiers), via un ou plusieurs logiciels appropriés, permet de constituer une base d’indicateurs à destination d’usages divers :

• Gestion de capacités,

• Etudes de performances,

• Tableaux de bords,

• Planification budgétaire,

• Etc…

Sur lesquels il convient d’ajouter la composante financière (Opex / Capex & amortissement) dont la source doit-être la DAF :

• Contrôle de gestion

In fine, cette base d’indicateurs permet la ventilation des coûts vers les différents clients (hébergeur de services Cloud) ou aux clients internes de l’entreprise (Business Units, métiers) dans le cas d’un Cloud privé. C’est généralement l’entité « pilotage économique » de la direction technique ou DSI qui porte le sujet et possède la maîtrise des calculs, tout en y associant de près le Contrôle de gestion afin d’obtenir le tampon financier, sésame souvent indispensable pour la diffusion des coûts vers les clients internes.

La facturation des services à l’intérieur de l’entreprise, pour l’usage d’un Cloud privé ou pour l’ensemble des services d’Infrastructure, reste un problème complexe. Dans la plupart des cas, les entreprises sont structurées en silos autonomes avec pour chacun leurs budgets propres et peuvent ainsi facturer les services entre les différents silos (« Cross-Sharing »).

Le fait de facturer les services en fonction des ressources utilisées, pour les organisations qui ne possèdent pas de système de refacturation interne, constitue un changement important. Avant de passer à la phase de facturation effective des services (« ChargeBack »), il est préférable d’adopter une phase « éducative » vis-à-vis des clients, visant à afficher les coûts à facturer en fonction des ressources utilisées (solution de « ShowBack »).

Le « ShowBack » peut aussi être utilisé pour mettre au point un système de tarification adapté, vérifier son impact en fonction de l’usage des ressources, avant de le généraliser dans le système réel de « ChargeBack » …

De plus, l’arrivée de toute nouvelle technologie (i.e. le Cloud Computing au sein d’une entreprise) impose une pénalité au premier qui s’engage : la première entité

PAG

E 34

qui a un besoin paie généralement tout ce socle ou cette phase d’installation ! Les projets complémentaires ont alors le bon rôle, pouvant s’appuyer sur l’existant et demander une facturation dite incrémentale (les coûts supplémentaires liés à la mise en œuvre uniquement) en faisant abstraction de l’utilisation « gratuite » d’une quote-part du socle existant.

La méthode ABC5 constitue par ailleurs une méthode d’analyse des coûts par processus ou activités, qui peut s’avérer judicieuse dans l’application d’une matrice de ventilation des coûts, en tenant compte des métriques collectées.

Néanmoins, cette facturation devient un état de fait dans le cas d’un Cloud public : du fait de sa nature de service externe acheté (une sorte d’ « utility »), l’utilisateur connaît alors directement sa consommation et le montant des coûts associés en OPEX / CAPEX qui se trouvent directement imputés sur son budget.

La complexité se déplace alors vers la maitrise du budget global transverse à l’entreprise afin de garantir que la somme des petites facturations ne s’avérera pas prohibitive par rapport à une solution interne ou ne nécessite pas un plafonnement contractuel que les achats pourraient prévoir, sans oublier la gestion du parc et son décommissionnement.

4.3. Conclusion

La construction de la facturation à l’usage du Cloud Computing se décline suivant 2 axes :

• la métrique • la facturation

Axes sur lesquels le type de Cloud (privé, hybride, public) et le mode de service (IaaS, PaaS, SaaS) se répartissent.

Ce graphique résume la tendance actuelle :

5 Activity Based Costing, prise en compte dans le modèle développé par le Groupe de Travail Analyse des coûts de la Production.

CLO

UD

CO

MP

UTI

NG

: P

aas,

Séc

urité

et C

loud

, Sou

rcin

g, fa

ctur

atio

n et

ref

actu

ratio

n de

s se

rvic

es C

loud

, Obs

erva

toir

e H

PC

PAG

E 35

Li

VRE

BLA

NC

Où nous retrouvons logiquement le « IaaS en mode Cloud privé » sur des métriques techniques en facturation ShowBack pour aller jusqu’au « SaaS en mode Cloud public » s’appuyant sur des métriques plutôt métiers lié à une refacturation directe des utilisateurs.

De plus, le tableau ci-dessus illustre les natures de métriques envisageables :

Nb. : le Cloud Hybride sans existence industrielle à date, reste à définir ainsi que les métriques qui permettront, par exemple, d’avoir avec un même sous-traitant un Cloud privé en interne exploité par ce sous-traitant connecté à son Cloud externe.

Aujourd’hui les questions de facturation et de refacturation restent peu développées dans de nombreuses entreprises, et de ce fait rarement utilisées. Les métriques métiers pour leur part manquent presque partout car elles ne correspondent pas aux façons traditionnelles d’envisager l’outil informatique. Cette situation devrait rapidement évoluer sous l’effet du Cloud Computing :

• En premier lieu parce que le Cloud généralise le principe de la consommation d’informatique sur un mode service.

• En second lieu car le Cloud incitera de plus en plus les fournisseurs internes à imposer aux métiers l’utilisation de services refacturables, et donc comparables à ceux du marché.

Encore émergent, le sujet de la facturation et de la refacturation des services Cloud devrait rapidement progresser.

IaaS

Privé CPU, Go de RAM et To de stockage

Hybride CPU, Go de RAM et To de stockage

Public Configuration petit-moyen-large :CPU, Go de RAM et To de stockage

PaaS

Privé CPU, Go de RAM et To de stockage + requêtes http,serveur d’applications et SGDB

Hybride Non défini

PublicRequêtes http, serveur d’applications et SGDB+ taux de disponibilité et temps de réponse http(qui garantit la monté en charge)

SaaS

Privé Capacité http, serveur d’applications et SGDB+ taux de disponibilité et temps de réponse applicatif

Hybride Non défini

Public Nombre de services (type boite mail)avec nombre d’options (collaboratif à 10)

PAG

E 36

CLOUD ET HIGH PERFORMANCE COMPUTING

Le Livre Blanc Cloud Computing 2011 du CRiP comportait un chapitre consacré au sujet Cloud et HPC (calcul scientifique et technique) appuyé sur les réflexions en cours chez quelques membres du Groupe de Travail engagés sur ce sujet.

Après avoir posé quelques éléments de qualification des plates-formes HPC, ce chapitre dressait le tableau suivant de la situation :

• Une offre en souffrance : il existait un manque d’acteurs – nationaux, européens ou mondiaux – sur le territoire français.

• Un modèle Cloud pas toujours adapté au HPC et ceci aussi bien dans ses éléments

techniques qu’économiques.

• Des points de résistance spécifiques : la sécurité, le problème du transfert de forts volumes de données, le respect des modes d’exploitation spécifiques au HPC.

En l’absence de progrès réels dans l’adoption des solutions de Cloud HPC par les membres du Groupe de Travail, nous n’avons pas jugé utile de rédiger un nouveau chapitre sur le sujet. Cependant, nous voulons ici rendre brièvement compte de quelques faits marquants intervenus au cours des douze derniers mois, et particulièrement de quelques évolutions importantes.

• La question de la constitution d’une offre bien représentée sur le territoire français reste posée, et la situation ne progresse que lentement. Cependant, mi-mai 2012, nous apprenons le lancement du projet NumInnov qui vise à la création d’un opérateur indépendant de services de calcul intensif en mode Cloud à l’échelle européenne. Le projet, porté par Bull et la Caisse des Dépôts, disposera d’une trentaine de millions d’euros de financement. Une façon de répondre à l’activité forcenée d’Amazon Web Services, qui, avec la mise en production de son service de HPC Cloud Cluster Compute Eight Extra Large a atteint la 42ème place du classement Top 500 des super calculateurs.

• L’utilisation de services de HPC Cloud commerciaux tels qu’il en existe déjà quelques-uns constitue désormais une alternative économiquement rentable à la construction d’un cluster interne pour des utilisations temporaires. Le Cloud HPC parvient donc déjà à se substituer dans certaines conditions aux clusters HPC, même s’il ne peut encore prétendre fournir les performances des plus puissantes plates-formes traditionnelles. Une étude menée par l’Université de Berkeley indique que les opérations de base conduites dans un Cloud reviendraient de 5 à 7 fois moins cher que les mêmes opérations effectuées sur une grille ou un centre de données classique.

5

CLO

UD

CO

MP

UTI

NG

: P

aas,

Séc

urité

et C

loud

, Sou

rcin

g, fa

ctur

atio

n et

ref

actu

ratio

n de

s se

rvic

es C

loud

, Obs

erva

toir

e H

PC

PAG

E 37

Li

VRE

BLA

NC

• Parmi les fournisseurs, Cycle Computing, éditeur spécialisé dans les outils et services d’administration des flux de calculs sur fermes HPC, commercialise désormais une offre de Cloud HPC baptisée Cycle Cloud appuyée sur le Cloud d’Amazon. Cycle Computing a ainsi mis en œuvre pour un client de l’industrie pharmaceutique à l’été 2011 un cluster composé de 30 000 cœurs, 26,7 To de mémoire et 2 Po de disques au prix de 1 279 dollars de l’heure. Depuis, Cycle Computing a réalisé un cluster de plus de 50 000 cœurs. La particularité de Cycle Cloud est d’utiliser des instances Amazon standard (et non pas des instances HPC plus coûteuses), instances réparties dans plusieurs datacenters pour des questions de disponibilité, et d’offrir à ses clients un guichet unique tant pour l’administration (et la sécurité) que pour la facturation de la ressource. Le prix atteint, environ 1 000 euros de l’heure, s’avère très compétitif pour des besoins ponctuels, même si les performances obtenues sont probablement moindres que celles à attendre d’un cluster HPC traditionnel interne du fait des surcouches de virtualisation et d’automatisation utilisées.

• Une autre approche du calcul HPC dans le cloud, adoptée par la société Vcodyne, consiste à adapter le modèle Cloud Computing (utilisation de ressources informatiques externalisées en mode service) aux exigences du monde du calcul intensif (performance et sécurité). L’idée est de mettre à disposition des utilisateurs des nœuds de cluster physique gérés avec les principes du cloud computing. Il est possible, selon ce modèle, d’avoir un accès sécurisé à des ressources HPC physiques dédiées (cpu, stockage, réseaux) avec un contrôle total sur ces ressources. Il est possible de redimensionner dynamiquement le cluster en fonction de la charge (intégration avec l’ordonnanceur local inclus). Comme pour les autres services de Cloud le paiement s’effectue à l’usage. Vcodyne a choisi de développer son offre sur des data-centers (certification SAS70 llb Sox) en France ou en Allemagne.

• Le problème de l’accroissement des volumes de données, et partant celui de leurs mouvements a connu un renforcement ces derniers mois où il fut beaucoup question de Big Data. En réponse à ces problèmes, un membre du CRiP a initié un projet pour la mise en place d’une plate-forme de stockage, de traitement et de partage de données basée sur Hadoop – MapReduce, soit un type de Cloud interne HPC. Les obstacles restent importants : complexité du développement, difficulté à paramétrer efficacement les schedulers pour éviter l’engorgement sur les nœuds, quasi impossibilité de sauvegarder efficacement des quantités de données énormes, et défaut de support.

• Le problème de la confiance et de la sécurité des données reste largement en suspens. Plusieurs démarches visent à remédier à cet état de fait. L’ENISA (European Network and Information Security Agency) s’associe ainsi à la démarche CAMM (Common Assurance Maturity Model), une méthode qui vise à mettre en place des indicateurs de sécurité partagés concernant le niveau de sécurité des différentes plates-formes Cloud. Pour le moment, la seule démarche sécurisée consiste à mettre en œuvre un Cloud de type privé.

PAG

E 38

• Le problème de la gestion des licences dans le Cloud HPC appelle des réponses originales car les modèles traditionnels, souvent liés à des identifications physiques de machines ne fonctionnent plus. Des architectures de type Licence-as-a-Service devraient voir le jour pour assurer la distribution temporaire de droits de licence à un utilisateur par Internet, avec une sécurisation renforcée des clés logicielles pour éviter les risques de craquage.

Comme nous le voyons, en particulier en matière de sécurité, le Cloud HPC rencontre des problématiques générales au Cloud. La grande particularité du domaine reste ses exigences importantes en termes de bande passante et de réduction de la latence, domaines dans lesquels les infrastructures publiques actuelles ne semblent pas à même d’apporter de solution satisfaisante.

CLO

UD

CO

MP

UTI

NG

: P

aas,

Séc

urité

et C

loud

, Sou

rcin

g, fa

ctur

atio

n et

ref

actu

ratio

n de

s se

rvic

es C

loud

, Obs

erva

toir

e H

PC

PAG

E 39

Li

VRE

BLA

NC

RETOURS D’EXPéRIENCE

6.1. Valeo Vega

entreprise : Valeo Secteur : Industrie, équipements automobilestype de Cloud : public SaaSmise en service : 2009

Le contexteEntreprise de dimension internationale – 124 sites dans 28 pays et plus de 60 000 collaborateurs –, avec de forts objectifs de développement dans les pays émergents, Valeo se trouve confronté en 2006 au besoin de remplacer sa plate-forme de communications interne. Basée jusqu’ici sur Lotus Notes, cette infrastructure se dirigeait alors vers sa fin de vie, tandis que de nouvelles attentes des utilisateurs se profilaient. La question se pose donc : quels besoins pour la future plate-forme ? Comment y répondre ?

Valeo distingue alors quatre axes stratégiques à prendre en compte :

Besoin métier : mettre plus de temps réel dans les échanges entre les équipes, savoir gérer des interactions et partenariats multiples de type entreprise étendue, savoir répondre aux besoins de communication des utilisateurs multiples dont le nombre et la diversité culturelle augmente rapidement.

Flexibilité : augmenter l’agilité du système en le rendant plus réactif, mais aussi introduire un modèle de paiement à l’usage, et respecter les standards ouverts pour faciliter les évolutions futures.

Maîtrise des coûts : une constante de cette industrie qui sait que son évolution se joue sur sa capacité à innover d’une part et sur sa capacité à maîtriser et réduire ses coûts d’autre part.

Amélioration continue : gagner en agilité dans la fourniture de nouvelles fonctionnalités en conformité avec les besoins des métiers, dépasser les limites des outils jusqu’ici en place, simplifier les process.

Enfin, Valeo a la conviction que l’innovation se tient à ce moment du développement des techniques informatiques plutôt dans le domaine grand public que dans celui des solutions pour entreprises.

L’entreprise se fixe quelques principes :

• Universalité du client : l’accès aux outils devra se faire par de simples navigateurs du marché• Universalité de l’accès : tous les utilisateurs devront pouvoir accéder au service de façon

identique de partout depuis tout type de terminal.

Le CloudLa solution déployée se nomme VeGa pour Valeo empowered by Google apps. Elle se compose d’un ensemble de services Cloud de diverses origines, mis à disposition de l’organisation

• La suite Google Apps (messagerie, chat, calendrier, Google Docs, outils de création de sites, de partage de vidéos, etc.)

• Une couche de sécurité et d’archivage fournie par Google Postini• Une plate-forme de développement d’applications de Workflows administratifs fournie par

Cordys Process Factory• Et un cœur de système d’intégration et de gouvernance de l’ensemble qui comporte les services

d’authentification, les annuaires, le Master Data Management la gestion du support et le pilotage des interfaces avec le Système d’information. Ce cœur de système est fourni en partenariat avec Cap Gemini

6

PAG

E 40

Ce qu’il faut savoirVeGa est actuellement utilisé au quotidien par 35 000 collaborateurs dans 28 pays.

La chaîne de gestion d’un compte utilisateur a été complètement automatisée, le système RH (PeopleSoft) la pilote directement : provisionnement et gestion du cycle de vie de l’identité numérique de l’employé Valeo

VeGa fonctionne selon une logique d’indépendance de plate-forme : toute plate-forme cliente, tout navigateur, doivent pouvoir accéder aux services. Ce qui ne signifie pas que l’utilisateur possède le choix inconditionnel de son terminal d’accès, mais que la décision de standardisation côté client revient à l’entreprise : elle n’est pas dictée par le fournisseur. Pour le premier cycle d’utilisation, Valeo retient le navigateur Firefox, installé sur tous les postes de travail de l’entreprise, et Android comme plate-forme mobile. Ces choix ne traduisent pas un sacrifice du principe d’indépendance de plate-forme, mais seulement une décision temporaire de standardisation de ses clients. Une migration vers Google Chrome est prévue en 2012 pour bénéficier de certaines fonctions avancées des Google Apps que seul ce navigateur procure.

Conceptuellement, le système se compose de quatre couches. Trois d’entre elles sont fonctionnelles et prennent en charge les usages personnels, d’équipe, d’entreprise. En dessous se tient une couche technique aux mains de l’entreprise pour la délivrance de services génériques fondamentaux : l’authentification, le Master Data Management, la gestion des interfaces avec les applications business SAP BW, Peoplesoft, le PLM, etc.

Un service de migration a été mis en place pour faciliter, le plus automatiquement possible, les nécessaires transferts de données entre l’ancien système et le nouveau.

Ce projet incorpore une forte volonté de concentrer l’IT sur l’axe accompagnement des métiers plus que sur l’axe technique et de gestion des infrastructures, et de réduire la part d’activité consacrée à ce dernier (intérêt du mode SaaS).

Les profils d’utilisation du réseau ont été complètement transformés par ce projet. Les échanges notoirement internes ont maintenant migré sur Internet. Il a, ainsi, fallu séparer les flux métiers (VeGA ou autres SaaS) des flux sociaux (autres), ces derniers ayant toujours tendance à occuper beaucoup de bande passante.

Les solutions mobiles, précédemment basées sur Blackberry, passant sur Android, ont fait exploser les charges de roaming en mobilité. Cela a entrainé des négociations « musclées » avec les opérateurs mobiles.

La sécurité a été centrée sur les terminaux des utilisateurs. Mais les comportements des utilisateurs restent la plus grande source de soucis.

Points positifs• Performances, évolutivité, disponibilité, sécurité• Il y a un retour IT (remplacement d’un système vieillissant) mais surtout un retour métier avec

une meilleure diffusion de l’information et une collaboration étendue• Le système permet la mise à disposition rapide de nouveaux environnements selon un modèle

de paiement à l’usage• Les services sont standardisés au niveau de l’entreprise et évoluent rapidement avec la

puissance de la plate-forme du fournisseur• Simplicité d’utilisation

Points de vigilance• Attention à la consommation réseau• La gestion de la réversibilité reste problématique• Le fournisseur se trouve en situation quasi-hégémonique (imposition de Chrome)• Les comportements des utilisateurs engendrent des risques accrus de sécurité• Ce système est sensible aux risques politiques : dans certains pays du monde, Google n’est pas

le bienvenu et ses services sont difficiles d’accès• Etre bien armé pour accompagner le changement auprès des utilisateurs, en termes techniques,

mais surtout en termes d’usages métier (formation des utilisateurs)• Respecter les standards Internet et ses choix d’architecture (REST)

CLO

UD

CO

MP

UTI

NG

: P

aas,

Séc

urité

et C

loud

, Sou

rcin

g, fa

ctur

atio

n et

ref

actu

ratio

n de

s se

rvic

es C

loud

, Obs

erva

toir

e H

PC

PAG

E 41

Li

VRE

BLA

NC

• Conserver le contrôle des paramètres-clé du fonctionnement du service : par exemple les règles de partage

• Assembler et intégrer mais éviter voire proscrire le spécifique sur les parties conservées dans l’entreprise

• Prendre la mesure de l’impact sur les compétences internes. Un tel projet demande de la maturité en ce qui concerne le pilotage de contrats d’externalisation, un haut niveau d’expertise sur les solutions cloud et l’architecture

6.2. Stime (Informatique des Mousquetaires)

entreprise : groupement des mousquetairesSecteur : grande distributiontype de Cloud : IaaS privé internemise en service : 2011

Le contexte Le Groupement des Mousquetaires est un acteur majeur de la grande distribution en Europe : 3 500 points de vente, 130 000 collaborateurs, 37 milliards d’euros en 2011. Sa filiale Stime est en charge de la conception, du déploiement, de l’exploitation et du support des tous les projets informatiques. Elle emploie 750 collaborateurs dont 200 au sein de sa Direction des Opérations Amont qui exploite quatre datacenters pour un total d’environ 1 000 serveurs (MVS, AIX, Linux, Windows).

En 2010, la Direction des Opérations Amont décide d’ajouter une offre Cloud IaaS à son catalogue de services. L’objectif est de disposer d’une offre « agile » pour répondre aux demandes urgentes ou temporaires de mise à disposition d’environnements serveurs, demandes que les processus existants ne permettaient pas de traiter dans des délais satisfaisants. En effet le séquençage des intervenants dans le déroulement de ces processus de mise à disposition de serveurs engendrait un délai habituel d’une à plusieurs semaines. Dans ces conditions, le risque était fort de voir les demandeurs se tourner vers des services externes, ou renoncer à certaines opérations.

L’orientation retenue consiste à créer un Cloud privé interne afin de pérenniser et d’optimiser les investissements existants dans les datacenters.

Quelques éléments de cadrage ont été établis :• La Stime doit rester libre de ses choix de fournisseurs de serveurs, réseaux, stockage et

hyperviseurs• La solution devra gérer des serveurs Windows, Linux et, ultérieurement, Unix• Les serveurs gérés seront principalement des machines de développement et de recette. La

solution doit toutefois permettre de gérer des serveurs de production• La solution devra automatiquement mettre à jour la CMDB Stime existante et proposer une

interface avec l’outil de facturation déjà en place

Le CloudLa solution mise en œuvre repose sur l’offre ISDM d’IBM (IBM Service Delivery Manager). Elle permet à la Stime de créer des serveurs Windows ou Linux en moins de 30 minutes. L’utilisateur choisit le système d’exploitation, le nombre de CPUs, la quantité de RAM, la surface disque, la localisation réseau et détermine le client (Business Unit par exemple) à facturer. Il peut choisir l’installation automatique de packs logiciels additionnels.La solution permet de modifier, à la demande, la configuration des serveurs déjà créés. Elle permet aussi d’enregistrer l’image d’un serveur à des fins de restauration ultérieure (pour un retour arrière après une opération échouée par exemple).

Les utilisateurs accèdent à la solution au travers d’un portail intranet. Ce portail s’appuie sur un moteur de workflows, un orchestrateur qui pilote les opérations techniques et un outil de comptabilisation.

Les serveurs demandés sont fournis par une plateforme VMWare déployée sur plusieurs datacenters afin de garantir un plan de reprise d’activité. Cette plate-forme a été dimensionnée et évoluera de manière à disposer en permanence de ressources disponibles pour respecter l’aspect « à la demande » de l’offre Cloud.

PAG

E 42

L’usage du portail est réservé aux Chefs de projets techniques. Ceux-ci vérifient l’éligibilité de chaque demande avant de souscrire un service Cloud. Divers critères entrent en jeu dans ce processus : support de la virtualisation, versions des OS et des logiciels, flux réseaux, adéquation du SLA aux capacités de la plate-forme, contraintes sur les licences à ajouter... Les Chefs de projets techniques agissent donc comme un filtre d’expertise pour aiguiller les Clients vers la meilleure solution répondant à leurs besoins.

Selon le cas d’usage, les serveurs créés sont soit directement fournis au client (hébergement sec), soit administrés par les équipes de la Stime (hébergement avec exploitation).

Ce qu’il faut savoirLe projet a inclus deux grandes phases : la recherche de la solution logicielle idoine puis son déploiement. Comme expliqué plus haut, la Stime souhaitait conserver la totale maîtrise de ses approvisionnements en matière de matériels informatiques ainsi que le choix de ses hyperviseurs. L’adoption d’une solution tout-intégrée – matériel + orchestrateur et outils d’administration + hyperviseurs - ne convenait donc pas à son cahier des charges.

Le planning a été le suivant :

La phase de rédaction du cahier des charges a été importante. Une formalisation précise et exhaustive du service attendu constitue un facteur clé de réussite.

L’intégration a été menée par IBM avec formation et transfert de connaissances auprès de l’équipe Stime. Au cours du projet, certaines demandes fonctionnelles ont été adaptées afin de se rapprocher du fonctionnement standard du produit. Cette façon de procéder a permis de maîtriser la part de personnalisation et ainsi d’alléger les futurs cycles de maintenance. Toutes les fonctions importantes pour la Stime ont été maintenues et implémentées.

Le pan sécurité a porté sur la mise en œuvre de règles renforcées de routage réseau, de contrôle de conformité et de gestion des mots de passe ainsi que sur le déploiement d’une technologie d’isolation de bas niveau sur le réseau virtuel (Private VLAN Cisco).

CLO

UD

CO

MP

UTI

NG

: P

aas,

Séc

urité

et C

loud

, Sou

rcin

g, fa

ctur

atio

n et

ref

actu

ratio

n de

s se

rvic

es C

loud

, Obs

erva

toir

e H

PC

PAG

E 43

Li

VRE

BLA

NC

Le service est opérationnel depuis fin 2011. Il vient en complément des prestations habituelles de la Direction des Opérations Amont.

Les premières offres du catalogue comportent quelques contraintes techniques : disque virtuel unique et seulement trois versions d’OS proposées. Ces contraintes vont être levées et le catalogue s’étoffera dans le cadre de la maintenance de la solution.

Le Cloud Interne Stime compte au printemps 2012 une vingtaine d’utilisateurs habilités. Sur les quatre premiers mois d’usage, 62 serveurs ont été créés et 49 supprimés. Il s’agissait principalement de systèmes de maquettages, de PoC ou bacs à sable. La durée de vie moyenne constatée d’un serveur sur ce Cloud est de 10 jours ouvrés.

Points positifs• L’agilité obtenue, pour les demandes éligibles au Cloud, est très bien perçue par les clients• L’offre a créé un processus de traitement rapide des demandes simples ou urgentes• Réduction de la charge et du délai de fourniture d’un serveur standard• Récupération en hébergement interne de demandes qui, auparavant, partaient en externalisation

du fait des délais• Permet de proposer des serveurs à usage saisonnier. Ces serveurs ne sont activés que pendant

les périodes utiles. Leur facturation n’est plus annuelle mais seulement pour leur durée d’activation. Cela se traduit côté Production par une mutualisation des moyens et côté client par une facture plus légère

Points de vigilance• Il faut adresser tous les aspects du projet dès son lancement : technique, organisationnel,

sécurité, juridique, financier et SLA. Le projet concentre des thématiques parfois dissociées• Pour l’accompagnement au changement, il faut communiquer et impliquer les services impactés

afin d’emporter l’adhésion. Le projet peut transgresser certaines organisations en silos• Veiller au capacity planning des ressources physiques• Veiller à ce que les utilisateurs ne provisionnent qu’au bon moment et libèrent les ressources

quand ils ne les utilisent plus. Ce changement d’attitude est nécessaire pour optimiser le taux d’usage du datacenter

• Prévoir l’évolution de certains profils Systèmes qui vont développer une expertise sur la solution retenue et vont en assurer la maintenance et le développement

• Prévoir une procédure d’assistance Systèmes pour les clients qui s’annoncent administrateurs de Windows ou Linux mais ont finalement besoin d’accompagnement

PAG

E 44

6.3. Unéo

entreprise : groupe unéoSecteur : assurance type de Cloud : SaaS externe publicmise en service : 2012

Le contexte Unéo est une mutuelle de la fonction publique, plus particulièrement tournée vers les personnels militaires et leurs familles. Issue de la fusion en 2008 de l’activité santé des trois mutuelles des militaires existant auparavant, Unéo bénéficie d’un référencement par le ministère de la Défense. Cette mutuelle assure plus de 90 % des militaires en activité (en France, Outre-mer et à l’étranger) et 70 % des militaires retraités, soit 630 000 adhérents pour 1,2 millions de personnes protégées. Unéo compte 450 salariés et 100 délégués bénévoles.

Le projet Cloud prend naissance dans le contexte qui suit la fusion en 2008 de la Caisse Nationale du Gendarme (CNG), de la Mutuelle Nationale Militaire (MNM) et de la Mutuelle de l’Armée de l’Air (MAA) au sein d’Unéo. La solution de messagerie qui s’impose alors en interne à l’ensemble des personnes repose sur IBM Lotus Notes Domino et un serveur Blackberry pour l’accès en mobilité. Cette configuration ne fait pas l’unanimité. Le nombre d’incidents élevé et la complexité perçue de l’usage engendrent un problème d’acceptation. La gestion des annuaires laisse à désirer. Les différences d’ergonomie entre l’interface client lourd et client léger posent problème. Il faut réagir.

Une étude d’opportunité de migration vers une plate-forme de messagerie Microsoft met en évidence une facture jugée trop importante. Dans le même temps, début 2010, le phénomène Cloud commence à faire beaucoup parler de lui. Tellement qu’en janvier, la DSI d’Unéo, sans posséder encore de projet nettement formulé, souhaite préparer les équipes au fait que l’arrivée du Cloud constitue un facteur de changement important pour les années à venir. Une présentation des principes du Cloud Computing a lieu durant une réunion du Club des managers Unéo, et suscite des retours encourageants. En conséquence, dès mars 2011, décision est prise d’expérimenter une solution de messagerie Cloud.

Le CloudUnéo retient la solution Google Apps pour cette expérimentation qui porte sur deux lots : la messagerie et les smartphones dans un premier temps, l’Intranet ensuite. La dimension environnement de travail, la possibilité d’utiliser des outils bureautiques en ligne, fait l’objet d’un examen, mais une migration semble prématurée.

Unéo souscrit aussi aux services de passerelle de sécurité Postini de Google.

Les règles antérieures fixaient les volumes des boites aux lettres à 250 Mo par boite, avec 500 Mo ou 1 Go d’archives. Une fois arrivés sur le Cloud Google, les utilisateurs disposent de 25 Go d’espace.

Une phase de tests est conduite de juin à septembre 2011. Le déploiement a ensuite été organisé sous ses aspects techniques (préparation de la migration des terminaux mobiles) et humains (organisation de sessions de formation). Le déploiement général a été conduit de janvier à mars 2012. Les serveurs Lotus seront arrêtés à l’été 2012.

Ce qu’il faut savoirLe projet a d’abord été lancé sous la forme d’une expérimentation, d’un protocole d’évaluation totalement réversible piloté par un Groupe Projet associant la Communication interne, la Maîtrise d’ouvrage et des Infrastructures, la Direction Générale Adjointe et le DSI qui occupe le rôle de chef de projet.

Le projet a été accompagné d’une campagne de communication et d’accompagnement méthodique et systématique, multi-canaux, à différents niveaux de l’entreprise. Un gros travail a été fourni du point de vue de la gestion du changement, avec des séries de messages, de newsletters, d’interventions dans le journal interne de l’entreprise.

Pour la phase de tests, un appel à candidature interne a mobilisé 10 % de la population de l’entreprise,

CLO

UD

CO

MP

UTI

NG

: P

aas,

Séc

urité

et C

loud

, Sou

rcin

g, fa

ctur

atio

n et

ref

actu

ratio

n de

s se

rvic

es C

loud

, Obs

erva

toir

e H

PC

PAG

E 45

Li

VRE

BLA

NC

des volontaires. Ils ont été formés à la nouvelle solution, et ont rempli des évaluations à la fin de la phase de tests. L’opération a suscité une forte adhésion à la solution, et une envie de migrer, alors qu’il ne s’agissait encore officiellement que d’une expérimentation et non pas d’un projet de migration.

Par la suite, tous les salariés de l’entreprise ont été formés. La bascule de leur messagerie vers la nouvelle plate-forme s’effectue durant leur session de formation afin qu’à la sortie de la salle ils disposent du nouvel outil. La migration des contenus existants des messageries vers Google Apps représente un volume global d’environ 250 Go.

Une des difficultés a consisté dans la reprise des boites partagées et des processus métiers inscrits dans la messagerie. En effet, cette dernière servait en particulier à récupérer les formulaires saisis par Internet. Des alternatives ont dû être développées pour la gestion des courriers clients entrants en les déplaçant vers les outils de Gestion de la Relation Client (CRM).

La migration a été accompagnée par Revevol qui a fourni certains outils.

Le RoI de l’opération est estimé inférieur à un an, le coût annuel facturé par boite aux lettres s’avérant inférieur au coût de la maintenance technique de la plate-forme de messagerie interne.

Le serveur Notes sera éteint en Juin 2012, une fois les dernières migrations de processus métier effectuées.

Points positifs• Le service de messagerie est plus apprécié des membres de l’entreprise• Les tâches de maintenance se trouvent allégées• De nouveaux usages apparaissent avec la demande de configuration des terminaux personnels

pour qu’ils accèdent à la messagerie d’entreprise• Fiabilité de la solution• Extension massive de la taille des boites aux lettres• Grande facilité à partager des agendas, ce qui était plus compliqué avant

Points de vigilance• Les services Google n’étaient pas bien gérés sur Blackberry au moment de cette opération• Les offres Google manquent encore d’intégrateurs et de distributeurs• La question de la réversibilité reste posée

PAG

E 46

6.4. Orange-FT Groupe

entreprise : orange-ft groupe activité : Services de télécommunicationstype de Cloud PaaS internemise en service : en cours de création

Le contexte Opérateur de télécommunications de taille mondiale, et fournisseur de services associés, Orange-FT Groupe développe de nombreuses applications pour ses besoins. Or, si le processus de fabrication des logiciels a connu une accélération significative depuis deux décennies, la mise en production reste complexe. Il existe de nombreux silos techniques que chaque logiciel doit traverser avant son passage en production, ce qui entraine des délais pouvant atteindre plusieurs semaines.

Ce constat conduit à une réflexion sur les moyens à mettre en œuvre afin de simplifier la vie des Projets en leur permettant de demander eux-mêmes la ressource dont ils ont besoin, sans que la Production doive construire cette dernière à chaque fois. Ce qui implique que les projets parviennent à formaliser leurs contraintes de façon fonctionnelle, au travers d’une ingénierie standardisée, qui n’ait pas besoin d’être ré-exprimée in-extenso pour chaque projet.

La solution devra donc :

• Permettre d’arriver à une expression de besoins simplifiée• Offrir un outil partagé entre acteurs du Build et du Run• Assurer un déploiement 100 % automatique des applications

Le CloudOrange-FT ne dispose encore d’une plate-forme PaaS totalement intégrée telle que l’entreprises souhaiterait la mettre en place à terme. Cependant, certains éléments émergent déjà très nettement.

Les composants techniques du PaaS s’inscrivent dans une démarche de rationalisation et de gouvernance technique qui consiste à dégager un jeu réduit de socles techniques au-dessus desquels développer

• Ces socles sont animés principalement par Linux (RHEL) et Windows • Java Enterprise Edition constitue la filière de développement.• Pour les composants Middleware, l’open source prévaut avec Apache, le serveur d’applications

Jonas, MySQL et PostgreSQL sur Linux. • La virtualisation x86 repose sur vSphere de VMWare

Ce qu’il faut savoirLe PaaS a vocation à mettre en place un modèle unique de fourniture des ressources sur l’ensemble du processus qui va de la chaîne de développement au passage en Production.

Le modèle PaaS impose une normalisation du format des applications et des données : les développeurs doivent apprendre à travailler avec ces formats normalisés.

L’utilisateur (côté Projets) n’aura qu’à gerer son code et ses données. La mise en place des ressources techniques, la souscription des services communs, le déploiement et l’intégration de l’application, la supervision et le traitement des logs applicatifs, sont entièrement pris en charge par la PaaS.

L’un des points de difficulté tient au besoin de modifier les façons de penser des équipes de développement : elles ne demandent plus un socle technique composé de serveurs, OS, bases de données, briques intermédiaires, etc., mais une série de fonctionnalités ou de SLAs.

La Plate-forme PaaS doit prendre en charge le bon dimensionnement automatique des ressources

L’évolution vers le PaaS s’inscrit dans une tendance générale de passage des architectures orientées services (SOA) vers les Infrastructures Orientées Services (SOI).

CLO

UD

CO

MP

UTI

NG

: P

aas,

Séc

urité

et C

loud

, Sou

rcin

g, fa

ctur

atio

n et

ref

actu

ratio

n de

s se

rvic

es C

loud

, Obs

erva

toir

e H

PC

PAG

E 47

Li

VRE

BLA

NC

Le Cloud et le PaaS constituent de grands enjeux d’organisation, parce qu’aujourd’hui l’entreprise a déjà conquis une efficacité par silos, mais beaucoup moins d’agilité transversale.

Le PaaS s’accompagne du passage à un processus de continuous delivery : la mise en Production devient un phénomène naturel et fréquent, et non pas une étape exceptionnelle et difficile à franchir

Points positifs• Temps gagné dans les cycles de Développement-Production• Simplification des tâches de déploiement et de supervision• Forte standardisation des plates-formes allant dans le sens d’une meilleure gouvernance

technique et d’une urbanisation renforcée• Les problèmes de dimensionnement sont traités par la plate-forme plutôt que par anticipation

selon des scénarios de consommation de ressources

Points de vigilance• La gestion de l’interfaçage entre les systèmes d’exploitation et la couche Middleware reste très

complexe du fait de la fragmentation du domaine• Faible maturité des solutions PaaS commerciales non-publiques, manque de standards, forte

hétérogénéité des modes de fonctionnement• Nécessité d’accompagner les développeurs depuis une démarche de demande technique vers

une démarche de demande fonctionnelle

PAG

E 48

7CONCLUSIONLE CLOUD EST UNE RéALITé DANS NOS SOCIéTéS

Après vous avoir laissé dévorer ce livre blanc, nous souhaitions partager trois constats sur le marché, le Cloud et les perspectives que cela engendre pour le Groupe de Travail.

Premier constat : c’est parti ! Les projets Cloud, au-delà des premières implémentations de SaaS sont une réalité au travers des projets IaaS et PaaS engagés chez de nombreux adhérents du CRIP.

Deuxième constat : le Cloud bouleverse les modes de fonctionnement classiques. C’est une vraie rupture, et comme tout changement il devra être accompagné au sein de la DSI mais aussi au-delà, dans les directions métiers ou business.

Troisième constat : ce n’est que le début. Au-delà des sujets déjà traités, de nouvelles problématiques s’imposent, énumérons-en quelques-unes :

- Assurer l’Urbanisation du SI lors de l’introduction d’applications Cloud - Examen des conditions de mise en œuvre d’un Cloud Hybride - Bonnes pratiques de migration des applications existantes dans le Cloud - Modèles d’engagement à déployer pour les nouveaux contrats Cloud - Gestion du cycle de vie des composants du PaaS - Qu’est-ce que le Patriot Act ? Dans quelles circonstances devient-il problématique de de tourner

vers un prestataire soumis au Patriot Act ?- Emergence d’un Cloud Européen : inventaire des services et des prestataires, raisons de se tourner

de préférence vers un prestataire national ou Européen. - Mise en place d’une gouvernance pour réaliser un mouvement stratégique vers le Cloud.- Cloud et Big Data : définitions, usages, convergences. - Accompagnement du changement des métiers impactés par le Cloud et perspectives RH.- Cloud et PRA

Bref, le voyage continue vers ce nuage étonnamment concret. Partis d’une perception théorique concrétisée par les premières créations de pilotes, nous en sommes venus au « Build », à la construction de solutions grandeur nature, et voilà que nous entrons à présent rapidement dans le concret des nouvelles problématiques de « Run », de l’exploitation dans la durée de ces solutions Cloud qui se multiplient. Parmi ces questions, celle de l’achat de prestations Cloud fera l’objet d’une réunion de travail commune entre le GT Cloud Computing du CRiP et le GT Cloud du CRAI, le Club des Responsables d’Achats Informatiques.

Autant de nouveaux sujets qui augurent une année à venir riche pour le Groupe de Travail Cloud du CRiP !

Que les passionnés d’Infrastructures et de Production voulant vivre de l’intérieur cette rupture, soient les bienvenus à notre saison 4 dès la réunion de rentrée en septembre prochain !

Patrick Joubert / Stéphane GeisselPilotes du groupe de travail “Cloud Computing” du CRiP.

PAG

E 49

Le Club des Responsables d’Infrastructures et de Production

A propos du

Chaque groupe de travail apporte une contribution importante dans l’élaboration de documents de référence.

L’analyse des enquêtes renseignées par les membres du CRiP permet de mesurer et d’observer l’évolution des enjeux des CTOs et de leurs infrastructures.En outre, elle met en relief les grandes tendances liées aux principaux challenges des productions informatiques.

Tous ces ouvrages deviennent inéluctablement une référence importante pour les CTOs et leurs équipes, ils constituent des outils reconnus pour l’amélioration de la performance opérationnelle et stratégique.

Les Livres Blancs Les Essentiels& Executive NotesDepuis fin 2011, les CRiP Thématiques sont suivies par la publication de leurs synthèses, les « Essentiels », distribuées à l’ensemble de la communauté du CRiP.

Enfin, le CRiP publie régulièrement, depuis début 2012, des « Executive Notes » qui sont des synthèses de vulgarisation à destination des dirigeants. Elles ont pour objectif de présenter de façon synthétique et stratégique certains des grands thèmes qui animent le domaine des Technologies de l’Information.

www.itiforums.comRetrouvez les contenus produits par le CRiP sur

Véritable associé du CRiP, ItIfoRumS est chargé de la communication, de la production et de la diffusion des documents et vidéos issus des travaux du CRiP, de l’organisation des évènements (Convention, CRiP thématiques, CeRCLe i), du référencement fournisseurs, de la relation avec les partenaires stratégiques du CRiP, et de la relation avec les partenaires fournisseurs du CRiP (présence de porte-parole aux évènements propriétaires, voyages d’étude, etc..)

Le réseau social des professionnelsde l’Infrastructure et de la Production

Itiforums interconnecte et informe les différents groupes – utilisateurs, membres du CRiP, fournisseurs de services et de technologies – qui composent la communauté de l’Infrastructure et de la Production.

Une relation privilégiée avec itiforums

PAG

E 50

Plus de 170 adhérents, grands Comptes, entreprises et administrationsACCOR · ADP GSI · AEROPORTS DE PARIS · AÉROPORT TOULOUSE BLAGNAC · AG2R LA MONDIALE · AIR FRANCE · AIR LIQUIDE · AIRBUS S.A.S · ALLIANZ GIF · ALLIANZ INFORMATIQUE · ALSTOM · AMUNDI · APHP · AREVA · ARKEMA · ARVAL · AUCHAN · AVIVA · AXA IM PARIS · AXA Luxembourg · BANQUE DE FRANCE · BANQUE PALATINE · BIC · BNF · BNP PARIBAS · BONDUELLE · BOUYGUES CONSTRUCTION · BOUYGUES TELECOM · BUREAU VERITAS · CA CIB · CAISSE DES DEPOTS ET CONSIGNATIONS · CANAL+ · CARREFOUR · CA-SILCA · CEA (Commissariat d’Energie Atomique) · CFAO · CG · CNAV · CNES · CNP ASSURANCES · COFACE · COFIDIS · COFINOGA · CREDIT AGRICOLE S.A · CREDIT IMMOBILIER DE FRANCE · DANONE · DARTY · DARVA · DASSAULT SYSTEMES · DCNS · DECATHLON · DEXIA CREDIT LOCAL · DEXIA TECHNOLOGY SERVICES · DIRECTION DE L’AVIATION CIVILE · DISIC · DISNEY · EAU DE PARIS · EDF · EIFFAGE · ERAMET · ERDF · ESSILOR INTERNATIONAL · ETABLISSEMENT FRANÇAIS DU SANG · ETAM · ETAT DE GENEVE · EULER HERMES · EUROMASTER · GCETECH - CAISSE D’EPARGNE · GCS D-SISIF · GDF SUEZ · GEMALTO · GENERALE DE SANTE · GENERALI · GICM ARKEA · GIE AGIRC ARRCO · GIE AXA TECH · GIE CHOREGIE · GIE EUROPEX - MAAF · GIE ISS SERVICE · GIE PROD · GMF · GROUPAMA SI · GROUPE ADEO · GROUPE AGRICA · GROUPE CASINO · GROUPE PREVOIR · GROUPE PUBLICIS · I-BP · INA · ING Luxembourg · INSERM · KEOLIS · KIABI · KPMG Luxembourg · LA BANQUE POSTALE · LA FRANCAISE DES JEUX · LA POSTE · LAFARGE · LATÉCOÈRE · LEGRAND · LOMBARD INTERNATIONAL · LOMBARD ODIER · L’OREAL · LVMH · MACIF · MACSF · MANPOWER · MATMUT · METEO France · MICHELIN · MINEFI · MINISTERE DE LA DEFENSE · MINISTERE DE L’INTERIEUR · MINISTERE DE LA JUSTICE · MINISTERE DES FINANCES · MINISTERE DES TRANSPORTS · MIPIH (Midi Picardie Informatique Hospitalière) · MUREX · NATIXIS · NEXTER · OCDE · ORANGE FRANCE FT GROUP · TELECOM · PIERRE FABRE · PLASTIC OMNIUM · PMU · POLE EMPLOI · POMONA · POULINA · PRAXIS SERVIER · PSA PEUGEOT CITROËN · RATP · RBC DEXIA · RCBT (Réseau Clubs Bouygues Telecom) · RENAULT · RESEAUX FERRES DE FRANCE · RHODIA · RIO TINTO · RSI (Régime social des indépendants) · RTE · SAFRAN · SAINT-GOBAIN · SANOFI AVENTIS · SCHLUMBERGER · SCOR · SFR · SI2M · SIMPLY MARKET · SNCF · SOCIETE GENERALE · SODEXO · SPIE · STEF · STIME · SUPERMARCHES MATCH · SYSTALIANS · SYSTEME U · TARKETT · THALES · THALES · ALENIA SPACE · TOTAL · UNEO · UNIBAIL-RODAMCO · UNIVERSCIENCE · VALEO · VALLOUREC · VENTE PRIVEE · VEOLIA · VOLVO IT …

Le bureau est constitué de CTOs et de DSI (Directeurs Infrastructures et Production Informatique) de grandes entreprises et administrations françaises, élus lors de l’Assemblée Générale. Philippe Sersot, CTO de Crédit Agricole-CIB en est le Président.

Philippe SERSOT - CREDIT AGRICOLE CIBCTO - Président du CRIP

Daniel JONDET - GENERALICTO - Trésorier du CRIP

Jean-Paul AMOROS - GDF SUEZCTO - Directeur des Infrastructures Groupe Secrétaire du CRIP

Francis ROBERT - AP-HPCTO - Directeur de l’Agence Technique Informatique - Vice-Président du CRIP

Frédéric DIDIER - ARVALDSI - Directeur Infrastructures et ProductionVice-Président du CRIP

David DECOVEMACKERAUCHAN INTERNATIONAL TECHNOLOGYCTO - Directeur de la Direction Technique Informatique - Président NORD-PAS-DE-CALAIS

Olivier HEITZ - BOUYGUES TELECOMCTO - Directeur des Opérations et de la Qualité de Services - Vice-Président du CRIP

Marc BEGUE - CNESCTO - Sous-Directeur Exploitation ArchitectureVice-Président du CRIP - Président CRIP TOULOUSE

Thierry DESVIGNES - CNP ASSURANCESCIO - DSI - Vice-Président du CRIP

Philippe MICHON - GIE ALLIANZ INFORMATIQUECTO - Directeur de la Production InformatiqueVice-Président du CRIP

Jean-Philippe MURE CTO - Directeur de la Production InformatiqueVice-Président du CRIP

Patrick DURIEZ - GROUPE CASINOCTO - Directeur Infrastructure et ProductionPrésident CRIP Rhône-Alpes

Marc LIMODIN - LA BANQUE POSTALECTO - Directeur de la Production Informatique Vice-Président du CRIP

Lionel VERLAINE - ORANGE FT GROUPEDirecteur de l’Ingénierie et de la Gouvernance des Infrastructures et Outils de l’Exploitation IT Vice-Président du CRIP

Jean Pierre DUMOULIN - PSA PEUGEOT-CITROËNCTO - Vice-Président du CRIP

Pierre AUGUSTE - SFRCTO - Directeur de l’Ingénierie des Infrastructures Vice-Président du CRIP

Le Bureau exécutif du CRiP

Le Réseau Social des Responsablesd’Infrastructures et de Production IT

Le CRiP (Association Loi 1901) compte +170 Grands Comptes, Entreprises et Administrations utilisatrices des technologies de l’information, adhérentes ou en cours d’adhésion. Il rassemble une communauté de plus de 1500 membres, responsables d’infrastructure ou de production.

Le CRiP est un cercle de confiance, lieu d’échanges et d’informations entre les différents membres confrontés aux mêmes défis financiers, technologiques et organisationnels.

La Mission du CRiP : Rendre ses membres plus performants dans leur métierUn Cercle de confiance pour :• Partager visions et retours d’expériences• Echanger et travailler collectivement sur les technologies, les

ressources humaines, les organisations et processus, les approches financières des projets, les relations avec les offreurs

• Pousser un projet en interne en s’appuyant sur les travaux du CRiP• Promouvoir les fonctions d’Infrastructure et de Production au sein des

Entreprises• Créer un réseau de communication rapide et efficace entre dirigeants

Philippe SERSOT Président du CRiP

CTO CA-CIB

Accélérer ses projetsLe CRiP est un lieu d’échanges très efficace où se partagent les bonnes pratiques sur nos sujets de tous les jours. Participer activement à un groupe de travail m’a permis d’avancer rapidement sur des projets de mon département, m’évitant ainsi de longues études de cadrage préalables. Les interactions directes de mes équipes, avec leurs pairs, chez d’autres adhérents, ont souvent permis d’accélérer des projets en interne. Enfin, le CRiP Toulousain que j’ai fédéré en 2011, a créé une dynamique d’échanges et de partages entre entreprises et entités utilisatrices de la Région sans précédent, avec des interactions très riches avec l’ensemble des activités du CRiP.

Marc BEGUESous-directeur Exploitation & Architecture,

CNESPrésident du CRiP Toulouse

Vice-Président du CRiP France

Les valeurs du CRiP : Indépendance

et Partage

En application de la loi du 11 mars 1957, il est interdit de reproduire ; sous forme de copie, photocopie, reproduction, traduction ou conversion de ce livre blanc que ce soit mécanique ou électronique, intégralement ou partiellement le présent ouvrage, sur quelque support que ce soit, sans autorisation du CRiP.

ContactsClub des Responsables d’Infrastructures et de Productioncontact@crip-asso.frwww.crip-asso.fr

Cré

atio

n : f

red.

lam

eche

- w

ww

.ano

usde

joue

r.frwww.crip-asso.fr

15 rue vignon

75008 PAriS