Le secours informatique SaaS, une responsabilité du fournisseur à formaliser

Un service SaaS (Software as a Service) est un logiciel mis à disposition et directement consommable depuis Internet. Il est géré et administré par un ou plusieurs fournisseurs.  Le client n’a donc pas la latitude nécessaire pour opérer le secours (pas d’accès aux données brutes, pas d’accès aux codes sources, ni aux applicatifs pour dupliquer l’infrastructure…), il doit donc s’en remettre au bon vouloir de son fournisseur.

Un niveau de couverture du secours informatique pour SaaS variable suivant la maturité du fournisseur

Trois grandes tendances se dessinent :

• Les fournisseurs qui disposent d’un plan de secours informatique inclus
  Dans le cadre de l’offre standard, le fournisseur assure un secours sur un datacenter distant, complété généralement par des sauvegardes externalisées. Il ne s’engage néanmoins que rarement sur les délais de reprise.
  Ex : les grands acteurs du SaaS (ex : Office 365, SalesForce, SAP…) , ainsi que certains acteurs de taille intermédiaire (ex : Evernote, Xero…) ;

• Les fournisseurs qui disposent simplement d’une sauvegarde externalisée
  En tant que tel, aucun plan de secours informatique n’est clairement établi. Le client doit alors s’interroger sur la capacité du fournisseur à restaurer les sauvegardes en cas de sinistre global sur le site principal.
  Ex : Des fournisseurs de taille intermédiaire (ex : Zervant, Sellsy…) ;

• Les fournisseurs qui ne communiquent pas ou n’en disposent pas
  Le sujet du secours informatique n’est pas abordé, il est donc préférable de considérer que rien n’est fait.
  Ex : Les acteurs de petite taille sont généralement dans ce cas.

L’importance de l’aspect contractuel

Dans la très grande majorité des cas, les fournisseurs SaaS ne s’engagent pas dans leur contrat sur leur façon de gérer le secours ; même lorsque ceux-ci mettent en avant leur capacité à traiter cette problématique. En effet, les contrats comportent généralement par défaut des clauses de Force Majeure stipulant que le fournisseur n’est pas responsable de manquement aux obligations du contrat dans la mesure où ce manquement est causé par un évènement en dehors de leur contrôle raisonnable. Le risque juridique doit donc être traité lors de la souscription et ces clauses supprimées pour s’assurer un bon niveau de couverture.

Lors de la souscription, comme pour des contrats classiques, les clients doivent s’assurer que figure bien des engagements de service, en particulier pour les secours informatiques :

• Le délai de reprise (Durée Maximale d’Interruption Acceptable ou DMIA) et les pertes de données (Perte de Données Maximale Acceptable ou PDMA) en cas de sinistre;
• Le plan de secours informatique du fournisseur incluant les modalités de gestion de crise ainsi que l’obligation de conduire plusieurs tests probants par an de ce plan avec la possibilité pour le client d’accès au rapport des tests ;
• Les pénalités financières et le droit de résilier le contrat (avec en particulier la récupération des données exploitables) en cas de manquement aux engagements.

Le secours informatique du IaaS/PaaS, une mise en oeuvre et une responsabilité du client

Le IaaS (Infrastructure as a Service) est une offre standardisée et automatisée de ressources de calcul, de moyens de stockage et de ressources réseau détenus et hébergés par un fournisseur et mis à disposition au client à la demande. L’offre PaaS (Platform as a Service) est similaire à celle du IaaS, à la différence près qu’elle ne concerne que les infrastructures applicative (définitions Gartner) Contrairement au cas du SaaS, le secours reste sous la responsabilité du client dans les deux cas : les fournisseurs IaaS/PaaS mettent à disposition des ressources dans différents datacenters et le client est responsable de l’usage et de la configuration qu’il en fait. Deux solutions s’offrent aux clients utilisant ces services : confier à un prestataire son secours ou bien le gérer lui-même.

Avoir recours à un prestataire de secours, un marché peu mature

Les prestataires de secours dans le Cloud sont désignés par l’acronyme « DRaaS » pour Disaster Recovery as a Service. Initialement, les fournisseurs DRaaS proposaient d’assurer dans le Cloud le secours de votre SI « on-premise ». Mais ils proposent également aujourd’hui d’assurer le secours de vos infrastructures déjà dans le Cloud, AWS ou Azure par exemple. La maturité reste très variable selon les fournisseurs et le cloud utilisé. Certains fournisseurs DRaaS imposent que le Cloud de destination du secours soit le leur, ne permettant pas ainsi de couvrir le secours de service PaaS.

Comme avec le SaaS, pas de garanties incluses par défaut quant aux pertes de données ou au délai de reprise, il faut les négocier. Les fournisseurs promettent de pouvoir s’adapter aux exigences du client ! Pour s’assurer que le secours fonctionne, le client doit prévoir la réalisation régulière de tests probants du secours (recommandation d’une fois par an).

Réaliser soi-même son secours en utilisant les outils proposés par le fournisseur

Comme sur une infrastructure « on-premise », il est nécessaire de réfléchir et définir sa stratégie de secours dès la conception. Cette stratégie doit intégrer la capacité de réaliser des tests probants permettant d’assurer un niveau de confiance suffisant dans son plan.

La mise en place est simplifiée par les outils mis à disposition par les fournisseurs Cloud et la forte standardisation des environnements Cloud. Les grands acteurs publient dans des livres blancs les grandes lignes directrices pour mettre en place un tel projet (par exemple AWS ou Azure).

Les concepts des stratégies du secours informatique restent proches de celles pour les datacenters on-premise.

On peut en dénombrer quatre principales :

• la sauvegarde et restauration: simple sauvegarde des données et images des machines sur un site distant, restaurées en cas de sinistre ;
• la veilleuse: réplication des bases de données et mise à disposition des machines sous forme d’images prêtes à être démarrées en cas de sinistre ;
• le secours à chaud: réplication complète du site primaire (données et machines), le site de secours est sous-dimensionné en termes de performances et est prêt à monter en charge en cas sinistre ;
• le multi site (ou actif-actif): les deux sites sont identiques et se partagent la charge des utilisateurs. En cas de sinistre, le site restant peut monter en charge pour accueillir la totalité des utilisateurs.

Des solutions hybrides pouvant mieux s’adapter aux exigences de délai de reprise, coût et complexité de la solution peuvent être envisagées.

Le véritable apport du Cloud pour le secours concerne les nombreux outils mis à disposition simplifiant la mise en œuvre et le déclenchement.

La réplication des données est ainsi simplifiée pour les options de géo-réplication asynchrones (plusieurs copies répliquées dans d’autres régions). La PDMA est variable en fonction des types de données et des outils proposés. Au-delà de cette option, une redondance locale des données est presque systématiquement incluse.

La forte standardisation permet également d’automatiser la reprise : les scripts ou API mis à disposition par les fournisseurs permettent d’automatiser le déploiement des infrastructures, le redimensionnement des instances en fonction de métriques précédemment définies, la répartition des charges et du trafic ou, l’adressage IP etc… afin d’accélérer de façon significative l’activation d’un site de secours.

Les outils de surveillance et alerte qui sont également proposés visent à faciliter le Maintien en Conditions Opérationnelles (MCO) du secours et peuvent être utilisés pour détecter au plus tôt un incident voire, dans certains cas, automatiser partiellement le déclenchement du secours.

Enfin la capacité à provisionner des nouvelles ressources en quelques minutes permet de limiter l’OPEX. A stratégie équivalente, il est ainsi possible d’avoir des gains de 40 à 70% sur le coût du secours !

Vers une plus grande prise en charge par le fournisseur ?

Azure prévoit une option, courant 2017, pour assurer le secours des machines virtuelles hébergées au sein de leur plateforme via la complétion de leur service « Site Recovery ». En effet, « Site Recovery » propose à l’heure actuelle de prendre en charge le secours de site traditionnel en utilisant le cloud Azure pour accueillir le site secondaire, mais Microsoft souhaite étendre ce service au secours de leurs propres infrastructures. Cet outil permettrait un déploiement automatique du site secondaire (de type actif-passif), une réplication automatique des données et une mise en place de tests facilitée.

Cette option est passée en « public preview » fin mai 2017. Un projet équivalent n’est pas d’actualité chez les autres principaux fournisseurs IaaS/PaaS.

Le cloud face au risque systémique des fournisseurs

Le secours informatique des services hébergés dans le cloud s’aborde différemment selon le type de service utilisé. Le secours du SaaS doit être géré contractuellement et est sous la responsabilité du fournisseur tandis que le secours du IaaS/PaaS, simplifié par les outils, reste sous la responsabilité du client.

Le risque de défaillance généralisé d’une région d’hébergement d’un fournisseur existe comme le montre les derniers incidents. Même si aujourd’hui, les incidents ont été de courte durée ou avec des impacts fiables, une défaillance généralisée ne peut pas être ignorée. Reste donc à traiter la problématique de cyber-résilience. L’utilisation d’un 2^ème fournisseur cloud permet de couvrir le risque de destruction ou d’indisponibilité majeure des infrastructures du premier. Cette solution reste très complexe car la portabilité d’un fournisseur à un autre est délicate. Pour l’instant, peu d’entreprises s’y sont risquées, même si l’on peut citer l’exemple de Snapchat qui utilise le cloud Google pour sa production et prévoit d’utiliser celui d’Amazon pour son secours d’ici à 5 ans.

Cet article Le Cloud, la fin ou renouveau du secours informatique ? est apparu en premier sur RiskInsight.

Une adoption motivée par réduction des coûts et recherche d’agilité

Malgré la dynamique du marché et la promesse de gains sous-jacente, les DSI des grandes entreprises tardent à se mettre en mouvement, réagissant plus au Cloud qu’elles ne l’anticipent. Elles le privilégient essentiellement pour des usages à risques techniques limités et à ROI rapide, principalement en IaaS et en SaaS.

SaaS : une utilisation massive des services standardisés

Le SaaS est aujourd’hui le principal vecteur d’adoption du Cloud. L’adoption du SaaS est centrée sur les fonctions support dont l’usage est standardisé (bureautique, messagerie, CRM, paie…). Le SaaS est également fortement sollicité pour les services de sécurité (antivirus, proxy, services de tests d’intrusion…) qui nécessitent une puissance de calcul importante, des évolutions en cycle court ainsi qu’une disponibilité maximale pour des employés de plus en plus mobiles.

PaaS : une adoption encore confidentielle

C’est le segment le moins bien appréhendé par les grands groupes aujourd’hui. Il correspond à la fourniture d’une plateforme d’exécution de code informatique. Il permet la mise à disposition d’une application en limitant très fortement les opérations sur les couches sous-jacentes (systèmes, bases de données, serveurs d’applications…). Le PaaS reste aujourd’hui cantonné chez les grands comptes à des usages « jetables », comme des prototypes ou des sites web temporaires (événementiels).

IaaS : des déploiements essentiellement en mode « privé »

Le modèle IaaS, fourniture de machines virtuelles (VMs) et ressources associées depuis un Cloud, qu’il soit public ou privé, permet d’introduire davantage d’agilité. Les grandes entreprises déploient aujourd’hui beaucoup de IaaS privés, dans l’optique de capitaliser sur leurs compétences internes et leurs investissements en infrastructures. De son côté, le IaaS public est mis en œuvre de façon très ciblée, par exemple pour une filière web, ou dans une logique de « bac à sable ».

Pour autant, grâce à la consolidation à grande échelle, c’est le modèle public qui permet d’obtenir les gains fonctionnels et financiers les plus importants. C’est pourquoi les stratégies de déploiement de IaaS privés sont ou doivent être considérés comme une étape sur une trajectoire plus ou moins long terme de généralisation d’IaaS public.

Un avenir qui promet plus d’innovation et de valeur ajoutée

La 1ère phase d’adoption du Cloud est motivée par la recherche d’économies et l’optimisation du niveau d’agilité. Ces prochaines années, le marché devrait évoluer pour offrir des solutions avec une valeur ajoutée de plus en plus forte, pour répondre à la fois aux offreurs en quête de relais de croissance et aux entreprises utilisatrices souhaitant optimiser leur marge en se recentrant sur leur cœur de métier.

Le SaaS devrait s’imposer dans les entreprises comme le choix par défaut. Les éditeurs de logiciels vont proposer de manière systématique leurs solutions en mode SaaS, en partenariat avec les fournisseurs IaaS. Ils s’assureront ainsi des revenus constants et proposeront à leurs clients des services très industrialisés, flexibles et au meilleur coût.

L’usage du PaaS devrait exploser lorsque les problématiques de portabilité des applications, bien souvent surestimées, seront résolues. Il devrait alors devenir le socle d’exécution par défaut de toutes les applications qui ne seraient pas consommées en SaaS. Ces plateformes vont s’enrichir pour fournir aux développeurs un maximum d’accélérateurs et de nouvelles possibilités (composants et connecteurs pré-packagés, services de sécurité, réseaux de distribution de contenus… ) et donc en faire un choix par défaut dans les filières de développement.

Par ailleurs, les éditeurs de progiciels devraient rapidement proposer leurs solutions en mode pré-packagé pour les plateformes PaaS du marché. Le IaaS devrait perdurer pour adresser des besoins applicatifs très spécifiques. Mais il ne permettra pas d’aller chercher toutes les économies d’échelle d’une approche Cloud.

 Ce sont le SaaS et le PaaS qui porteront le marché demain.

Cet article Le Cloud : quelle réalité marché derrière les nuages ? est apparu en premier sur RiskInsight.

Le Cloud impose-t-il une évolution forcée ?

Le Cloud simplifie l’accès à l’outil informatique en focalisant l’énergie de l’utilisateur sur le choix du service plutôt que sur la démarche de mise en œuvre. Cette facilité d’accès à des services « clé en main » peut inciter les Métiers de l’entreprise à traiter directement avec les offreurs Cloud sans impliquer la DSI. Pour contrôler l’adoption des services Cloud, la DSI doit devenir un acteur incontournable de ses Métiers : non pas en s’imposant mais bien devenant un partenaire légitime du Métier, apporteur de valeur ajoutée aux services Cloud.

Une priorisation des chantiers nécessaire

Le Cloud n’est pas qu’un outil technique à destination de la DSI seule. Il est essentiel de mettre en place sa stratégie Cloud en impliquant la Direction de l’entreprise pour prendre en compte l’existant et les besoins à venir, en déduire le périmètre éligible et enfin choisir ses modèles de sourcing (Public et/ou privé) et le type de Cloud (IAAS, PAAS et/ou SAAS) adapté aux cas d’usage. Deuxième étape pour la DSI : promouvoir cette stratégie auprès des Métiers avec ses sponsors en valorisant les apports de la démarche et en éclairant les contraintes liées à son utilisation.

A ce stade la DSI devra choisir entre 2 positionnements :

1) Un accès direct des métiers aux fournisseurs Cloud

La DSI ne porte pas la responsabilité du choix des fournisseurs mais apporte son expertise sur les dimensions :
•    Contractuelles, en mettant à profit l’expérience de la DSI pour définir les engagements en matière de niveau de service, de traçabilité, de pilotage des coûts…
•    Techniques, en accompagnant les projets sur l’intégration des services Cloud dans le SI de l’entreprise tout en respectant les contraintes internes de sécurité et d’échanges de données
•    Légales, en apportant sa connaissance des contraintes liées à l’hébergement des données (données personnelles, données sensibles d’entreprise, législation française, contraintes sectorielles…)
•    De réversibilité technique et opérationnelle, pour préparer en amont le désengagement d’un fournisseur.

2) Une DSI « broker de Cloud »

La DSI se positionne comme l’interlocuteur unique à la fois du Métier et des fournisseurs Cloud.  Le rôle d’expertise reste d’actualité et voit son périmètre étendu par une fonction de gestion des  relations clients et fournisseurs. La DSI est alors en responsabilité :
•    D’intégrer des services Cloud technique ou métier au catalogue de la DSI
•    De piloter et de garantir la qualité des services exposés par la DSI
•    De définir et de mettre en place les outils permettant une intégration au SI des services Cloud (IAM, échanges, service management…)
•    De faire évoluer ses processus internes pour fournir un service utilisateur unifié indépendamment des modes de sourcing
•    Et bien sûr, de fournir ces services Cloud au meilleur coût du marché à ses utilisateurs !

Bien que la stratégie de positionnement soit à définir suivant le contexte particulier de chaque entreprise, une majorité aura intérêt à adopter un positionnement « broker de Cloud ». Ce positionnement permettra de définir une stratégie IT globale cohérente entre les besoins internes et les possibilités offertes par les fournisseurs. Elle permettra ainsi de tirer toute la valeur économique et qualitative d’une approche Cloud par le biais d’achats massifiés et intégrables de manière standardisée au SI.

Les « temps métiers » et les « temps IT traditionnels» n’ont plus la même échelle, le Cloud est un des vecteurs de transformation qui permet de contribuer à la performance globale de l’entreprise. Néanmoins, pour combler ce décalage, la DSI doit être en perpétuelle transformation pour fournir les moyens nécessaires aux ambitions de l’entreprise.

Cet article Le Cloud computing : vers une DSI orientée service ? est apparu en premier sur RiskInsight.

La sécurité, une question négligée après la phase de contractualisation

Les limites posées par le SaaS sont aujourd’hui bien connues : difficultés d’adaptation du service aux besoins de l’entreprise, absence de possibilités d’audit, questions réglementaires, etc.

Pourtant, de plus en plus de services cloud sont adoptés, sans que la sécurité ne soit nécessairement un frein. Pour cela, une démarche classique d’analyse de risque est menée en évaluant les contraintes légales / réglementaires,  les mécanismes de protection des données, la gestion de la sécurité par le fournisseur, ou encore les conditions de réversibilité de la donnée.

Cette démarche est de plus en plus maîtrisée : de nombreux retours d’expérience et un outillage qui se professionnalise* amènent à faire des choix éclairés, en toute connaissance de cause des risques encourus, et donc parfois acceptés.

Malheureusement, la démarche sécurité s’arrête souvent là : à partir du moment où le sujet a été traité lors de la contractualisation, on considère qu’un bon niveau est assuré, puisque l’on a exigé du prestataire de s’en occuper !

Le maintien de la sécurité dans le temps est un enjeu régulièrement oublié, alors même qu’il est en partie du ressort de l’entreprise, et pas seulement à la charge du fournisseur.

Des sujets à inscrire dans la durée

Pour s’assurer que la solution cloud est déployée avec le bon niveau de sécurité, et maintenir celui-ci dans le temps, quatre grands thèmes sont à aborder en priorité. S’il s’agit de bonnes pratiques habituelles sur un SI d’entreprise, il faut aujourd’hui les adapter, voire les renforcer pour le SaaS.

•  La gouvernance : les services SaaS doivent être intégrés aux procédures de sécurité et des processus liés au service fourni. Il peut par ailleurs être utile de mener des actions de sensibilisation dans certaines situations.

• L’administration fonctionnelle du service est bien du ressort de l’entreprise : le fournisseur n’est pas en mesure de faire les choix fonctionnels à votre place (et ce n’est souvent pas ce qu’on lui demande) ! Pour l’aspect sécurité plus encore, c’est à l’entreprise de définir  et mettre en œuvre les fonctionnalités avancées disponibles, de restreindre les services au minimum requis par l’utilisateur, de former ses administrateurs… Ces aspects sont souvent les plus négligés, comme nous le constatons lors des audits que nous réalisons.
• Des contrôles réguliers peuvent et doivent aussi être mis en œuvre sur les parties auditables des services. Il s’agit en particulier de vérifier que les paramètres de sécurité sont inchangés, d’exploiter les logs sécurité, et de revoir les habilitations. S’il le permet, enfin, ne pas hésiter à auditer son fournisseur (visites de site, voire tests d’intrusion).
• Il reste enfin à traiter le sujet de l’IAM, enjeu transverse du Cloud, souvent peu ou mal maîtrisé de par sa complexité. Même si cette voie est souvent suivie, il faut pourtant éviter de recréer un compte dans le Cloud pour chaque utilisateur. Pour « synchroniser » les identités de l’entreprise dans le Cloud, il faut également éviter la multiplication des connecteurs  (et notamment ne pas en redévelopper un par fournisseur), sous peine de créer une situation ingérable. Deux approches sont aujourd’hui à prioriser : soit l’utilisation d’un outil de fédération d’identités interne (qui réalise la connexion avec la majorité des fournisseurs de SaaS), soit l’externalisation de l’IAM… dans le Cloud (!) en « Identity as a Service »

Le RSSI, garant de la cohérence des projets

Dans le cas du SaaS, le rôle des responsables sécurité de l’information est double.

D’une part, il s’agit d’accompagner les projets, en leur apportant des solutions transverses : un certain nombre de points peuvent être mutualisés en amont. C’est tout particulièrement le cas des sujets tels que l’IAM, qui doivent faire l’objet d’une approche unifiée et cohérente –  et surtout pas projet par projet.  C’est également le cas des questions légales qui doivent faire l’objet d’une réflexion globale amont.

D’autre part, la SSI demeure la garante du niveau de sécurité dans le temps : la Gestion Opérationnelle de la sécurité devra faire l’effort de partir à la conquête des nuages !

* On peut citer notamment le guide publié par l’ANSSI et la « Cloud Control Matrix » maintenue par la Cloud Security Alliance

Cet article SaaS et sécurité : entreprises, ne mettez pas vos responsabilités dans les nuages ! est apparu en premier sur RiskInsight.

1 – Comprendre le cloud et démystifier ses complexités

L’actuel CloudWashing ne facilite pas la compréhension des différents modèles de services et des bénéfices réels que les grands comptes peuvent en tirer. C’est pourquoi, il est nécessaire de commencer par mener un état de l’art pour comprendre les principes de consommation de ressources banalisées prêtes à l’usage et de segmentation des ressources, les différences avec les précédentes approches (ASP pour le SaaS, outsourcing pour le IaaS) mais aussi les spécificités, niveaux de maturité, bénéfices et complexités propres à chaque modèle.

Contrairement à ce que l’on pourrait penser, les complexités à adresser dans le cadre du cloud public ne se limitent pas à la dimension technologique et doivent être adressées en continu  :

• Complexités organisationnelles : le rôle de la DSI passe du pilotage de ressources à celui de pilotage de fournisseurs (c’est là la fin du mythe du super administrateur !) ;
•  Complexités réglementaires : réversibilité contractuelle, confidentialité, contraintes sectorielles ou légales sur le stockage des données ;
• Complexités technologiques : services d’intégration au SI, forte dépendance au réseau, etc.

2 –  Identifier  les opportunités d’externalisation de services

L’état de l’art permet d’identifier les cas d’usages aujourd’hui possibles dans l’entreprise :

• Le SaaS de par les fonctions génériques qu’il propose est envisagé pour des besoins non spécifiques au cœur de métier avec une faible intégration au SI ;
• Le PaaS public de par l’hétérogénéité des services offerts et le manque de standards est considéré pour les besoins « jetables »  surtout pour des organisations qui ont déjà investi sur leurs filières de développement basées sur des technologies traditionnelles ;
• Le IaaS privé s’inscrit en continuité de l’industrialisation des infrastructures en permettant plus d’agilité via le self-service ;
• Le IaaS public  ou hybride permet quant à lui d’adopter une position de « broker » d’infrastructure modulant le coût et la QoS en fonction des besoins métiers tout en étant capable de fournir une réponse agile à un besoin ponctuel de débordement de capacité.

Il est alors possible de s’appuyer sur un modèle comme SOI (méthodologie de catalogue de services) pour décliner les opportunités d’externalisation de services dans le cloud.

3 –  Affiner le périmètre éligible et définir la cible

Cette troisième étape commence par l’inventaire des critères d’éligibilité techniques et métiers (criticité des applications, environnements de développement, DMZ, étude des coûts …). Le business case est une étape clé et peut notamment révéler des coûts d’exploitation plus importants (par exemple dans le cadre du IaaS dès lors que l’utilisation des serveurs est intensive). L’application de ces critères permet alors de construire et de prioriser un portefeuille de projets. Une démarche usuelle mais avec des spécificités  propres au cloud s’impose :

• Commencer les déploiements par un périmètre pilote afin d’instruire plus facilement et à plus petite échelles les changements organisationnels ;
• Identifier des quick wins opportunistes et les adresser à l’issue du pilote sur des applications avec peu de contraintes technologiques ;
• Puis généraliser les déploiements et mener une politique du changement.

4 – Transformer le SI pour le cloud

Dès lors que les déploiements en mode cloud vont se généraliser, des applications de plus en plus en lien avec le cœur du SI vont partir vers le cloud. Se pose alors la problématique d’intégration aux services du SI. Les transformations à opérer sur le SI seront alors la prochaine étape dans l’odyssée vers le cloud …

Cet article 2012, l’odyssée du cloud : comment bien préparer votre voyage ? est apparu en premier sur RiskInsight.

Les projets de relation clients digitale, à la croisée de différents métiers et donneurs d’ordre sont compliqués à financer. Quelle stratégie de financement adopter ?

De tels projets portent en effet de nouvelles pratiques métiers et induisent des outils et automatismes adaptés à chaque canal. L’appréciation du coût d’un projet doit tenir compte de ces nombreux aspects matériels, logiciels et mais aussi d’accompagnement du changement. Les coûts de mise en œuvre représentent pas moins de 50% des dépenses (voir schéma ci-dessous).

Que la stratégie soit par investissements progressifs ou d’investissements d’ampleur il est recommandé de cadrer périmètre et trajectoire très en amont pour que tous les acteurs concernés adhèrent à la stratégie de financement.

Cette approche permet d’anticiper les besoins en fonctions socles (référentiels, middleware) ou mutualisées (outils de pilotage, reporting) et de répondre de manière progressive aux besoins immédiats des métiers, friands de nouveaux services (chat, FAQ, services en ligne, SFA).

Sur le plan matériel et logiciel, vaut-il mieux investir ou louer ? Que penser du SaaS ?

Dans des contextes de restriction budgétaire comme on peut les connaître aujourd’hui ou si une très forte réactivité de la DSI est demandée par les métiers, les offres en mode SaaS apparaissent  de plus en plus séduisantes.

Les solutions disponibles sont maintenant satisfaisantes sur le plan de la couverture fonctionnelle. Elles permettent d’accélérer la mise en œuvre. Leur usage est réversible et se prête à l’expérimentation. Il est donc primordial, encore une fois, d’anticiper. Anticiper au maximum les demandes ou intérêt des métiers pour ces services.

Il convient toutefois garder à l’esprit trois éléments.

Le point mort financier se situe généralement entre 2 et 4 ans d’usage, période au-delà de laquelle un achat reste préférable.

Ensuite le poste métier le plus candidat au mode SaaS est celui qui nécessite le moins d’intégration autour des données clients, par exemples les populations commerciales B2B.

Enfin, le mode SaaS permet de s’appuyer sur des services métiers et compétences spécifiques à la relation client, par exemple la gestion de la délivérabilité des emails, ce qui représente un véritable avantage.

Comment justifier les investissements ? Quelles pistes de gains ?

La mise en œuvre de la multicanalité porte la piste de gains la plus évidente, le différentiel de coûts entre canaux physiques et digitaux favorise en effet la relation client digitale. Par exemple pour un budget équivalent, une direction marketing peut multiplier par 8 à 10 le nombre de messages sortants en favorisant l’emailing.

 Trois grandes natures de gains sont à étudier. Des gains qui peuvent être quantitatifs ou qualitatifs : création de valeur (fidéliser – développer), efficacité opérationnelle (maîtriser le coût des interactions clients – optimiser ses ressources), perception de la marque (faire du client et du collaborateur un ambassadeur).

Les gains sont à apprécier avec les métiers donneurs d’ordre sur la base du périmètre des besoins exprimés. L’étude d’un business case doit donc être anticipée avec les métiers dès le cadrage du projet.

Vous l’aurez compris, dans le financement de la relation client digitale, s’il n’y avait qu’un seul mot d’ordre à retenir : anticipez !

Cet article Comment financer son projet de relation client digitale ? est apparu en premier sur RiskInsight.

Véritable transformation du SI, l’« informatique dans les nuages » s’accompagne de nouveaux besoins, nouvelles pratiques et d’un nouveau modèle économique. A l’ère des investissements lourds en Datacenter et infrastructures succèderont les services hébergés, facturés à l’usage.

Les offres Cloud du marché IT  couvrent l’ensemble des modèles de services Cloud : IaaS (Infrastructure as a Service), PaaS (Platform as a Service) et SaaS (Software as a Service).

Aussi, on retrouve sous la bannière du Cloud des acteurs allant de l’éditeur de logiciels à l’acteur issu du monde de l’e-business en passant par l’expert en solutions de virtualisation….ou l’opérateur de Télécoms.

Que font les opérateurs télécom dans les nuages ?

Pour déployer l’ensemble des services Cloud, la base est indispensable ; et cette base, c’est l’IaaS – les infrastructures…

Experts dans la conception, la production et l’exploitation de solutions de communications entreprises, les opérateurs ont donc une carte à jouer.

Certains opérateurs proposent déjà des offres Cloud, à base de solutions de virtualisation d’infrastructure et d’accès réseaux à la carte / à la demande. C’est le cas de Verizon Business avec CaaS (Computer as a Service)  et de l’offre Flexible Computing d’Orange business Service, déclinée en version premium depuis Décembre 2010. SFR a de son côté lancé en France une offre Infrastructure SI à la Demande le 30 juin dernier. L’opérateur s’est pour cela allié à HP qui fournit l’expertise Infrastructure manquant à l’opérateur.

Des atouts indéniables

Les opérateurs de télécoms bénéficient d’une notoriété et d’un capital confiance inégalés dans le monde des solutions et services informatiques. Par ailleurs, alors que sécurité et  dépendance au réseau sont évoqués comme des freins majeurs, ils y offrent des réponses concrètes.

– Sécurité : les opérateurs proposent des solutions d’interconnexion d’utilisateurs, de sites ou d’infrastructures sécurisés depuis plusieurs années.

– Dépendance au réseau : les opérateurs exploitent des solutions Très Haut Débit de moins en moins chères, avec une disponibilité bien souvent garantie à 100% et des engagements de niveaux de service associés.

Ils disposent en outre d’avantages concurrentiels établis sur ce marché (clientèle mixte entreprises et grand public, expertise en infrastructure et réseau, couverture globale et capacité d’intervention IT locale) et sont rodés au modèle économique de facturation à l’usage, caractéristique du Cloud.

Un positionnement appelé à évoluer

Le positionnement des principaux offreurs du marché se veut de plus en plus « généraliste ». Après avoir capitalisé sur leurs cœurs de métier respectifs (édition, gestion d’infrastructures, réseau) ils cherchent à élargir l’empreinte de leurs offres.

Pour les opérateurs notamment, cela passe par des alliances stratégiques avec les offreurs actifs sur les autres couches de la pyramide. Par exemple, Orange Business Services s’allie à Microsoft pour intégrer des solutions de messagerie et de collaboration de la plate-forme Microsoft Office 365, hébergée dans le Cloud. Dans ce cas, l’opérateur global qu’est France-Télécom Orange, met également à profit son savoir faire et ses ressources disponibles dans l’intégration de solutions informatiques.

Quelles perspectives ?

Le marché du Cloud n’en est vraisemblablement qu’à ses débuts, mais il dispose d’un potentiel de croissance fort que dénotent les investissements consentis sur le sujet et les premiers bilans économiques.

On ne compte plus les parallèles pour évoquer cette croissance attendue, par exemple avec la VoIP, un marché aujourd’hui mature et au cœur de la sratégie des opérateurs de télécoms.

Selon la plupart des acteurs du Cloud que j’ai pu rencontrer, ce marché représenterait 50% du marché total de l’IT dans le monde à horizon 5 ans. Ce palier de 50% demeurera la limite « physique » de développement du Cloud, tout l’IT n’ayant pas vocation à « basculer ».

Pour les analystes il devrait peser en 2015 dans le monde, entre 200 Mrd$ et 500 Mrd$. Le marché Français pourrait être estimé entre 10Mrd€ et 20Mrd€ cette même année (estimation Solucom).

Il y a fort à parier que Stéphane Richard, Directeur Général du groupe France Télécom, avait ces chiffres en tête en l’identifiant comme levier de croissance clé dans le cadre du plan stratégique « conquêtes 2015 ». Chiffres qui vont avec la certitude que les opérateurs disposent des atouts pour qu’une part importante du gâteau leur revienne d’ici 2015.

Cet article Les opérateurs, acteurs naturels du cloud computing est apparu en premier sur RiskInsight.