cloud computing : une remise en question du rôle du si

Cloud Computing : une remise en

question du rôle du SI dans

l'entreprise ?

Quels sont les impacts du Cloud Computing sur le rôle

de la DSI face aux directions métier ?

Version 1.4

Novembre 2015

Clément MARCHE

ISEP Mastère “Expert Cloud Computing and SaaS” 2014/2015

Thèse professionnelle – Cloud Computing : une remise en question du rôle du SI dans l'entreprise ?

Novembre 2015 – Clément MARCHE Page 1 sur 62

Table des matières

Remerciements ......................................................................................................................... 5

Résumé ..................................................................................................................................... 6

Executive summary ................................................................................................................... 7

Introduction ................................................................................................................................ 8

1. .................... Le Cloud : révolution technologique ou réponse naturelle aux besoins et usages ?

.................................................................................................................................................. 9

a. Définition du Cloud : ................................................................................................... 9

i. Base du NIST ......................................................................................................... 9

ii. Compléments : entre usages, marketing, et réalité ............................................... 12

b. Quelle(s) révolution(s) ou évolution(s) ont donné naissance au Cloud Computing ? 15

i. Historique : une évolution du SI depuis les années 60 .......................................... 15

ii. Un contexte où des technologiques arrivent à maturité de manière concurrente ... 17

iii. Une technologie qui répond à des besoins ........................................................... 22

iv. La limite des solutions actuelles ........................................................................ 24

v. Des besoins de soutien SI en évolution rapide et permanente .............................. 25

c. Dans le Cloud, le concept de DSI est-il encore pertinent ? ....................................... 27

2. ............ Comment la DSI peut se réinventer pour rester pertinente afin de maximiser l’efficacité

opérationnelle de l’entreprise ? ................................................................................................ 28

a. La DSI, comme support premier des utilisateurs de Cloud ....................................... 28

b. Une évolution axée sur la technologie et les services, pour aujourd’hui et pour

demain, et toujours centrée sur les usages ..................................................................... 30

i. Opérateur de l’excellence opérationnelle au quotidien .......................................... 30

ii. Innovateur (cœur métier) ...................................................................................... 32

iii. Appui stratégique : travailler de concert avec les directions métier, faire évoluer les

processus, voire proposer de nouveaux moyens ......................................................... 33

c. Supportée par une gouvernance transverse adaptée : ............................................. 35

i. La position de la DSI évolue ................................................................................. 35

ii. Tout le monde avance ensemble, vers un but/une stratégie commun(e) ............... 37

iii. Le soutien ne peut qu’être que global (DAF, DG, DSI, DM) et passe par une

évolution des mentalités ............................................................................................... 41

3. ................Comment faire du SI un avantage concurrentiel pour les entreprises : des outils, des

méthodes, et… des gens ? ...................................................................................................... 43

a. La gestion des compétences .................................................................................... 45

i. Pourtant, en France, ça ne décolle pas, pourquoi ? .............................................. 45


Novembre 2015 – Clément MARCHE Page 2 sur 62

i. Comment faire en sorte de transformer ces réticences, pour embrasser le

changement en le rendant durable et profitable : ......................................................... 47

b. Afin de construire un SI Agile ................................................................................... 55

i. Vie et mort des méthodes agiles ........................................................................... 55

ii. Quelles solutions complémentaires ? .................................................................... 57

Conclusion............................................................................................................................... 61

Références .............................................................................................................................. 62


Novembre 2015 – Clément MARCHE sur 62

Liste des illustrations Image 1 - Les modèles de déploiement Cloud 10

Image 2 - monotenant et multitenant 11

Image 3 - Principe du lean startup 14

Image 4 - Evolution des capacités informatiques depuis les années 60 – source:

www.rethinktechnology.wordpress.com 17

Image 5 - Modèle classique d'un serveur - source : http://www.culture-informatique.net/cest-

quoi-la-virtualisation/ 18

Image 6 - Modèle virtualisé - source : http://www.culture-informatique.net/cest-quoi-la-

virtualisation/ 18

Image 7 - Evolution des débits réseaux dans le monde depuis 1985 - source :

http://www.internetworldstats.com/stats.htm 19

Image 8 - Taux moyen de pénération d'internet dans le monde (2013) - source : Internet

World Stats 20

Image 9 - Terminaux d'accès à internet, par foyer - source : ITU World Télécommunication

(2012) 22

Image 10 - Types de Cloud utilisés en entreprise - source : CloudIndex de PAC (2014) 25

Image 11 - Résultats des projets ERP - source : ERP Report de Panorama consulting (2013)

25

Image 12 - 25% des employés en shadow IT en France 28

Image 13 - Les rôles de la DSI - inspiration : http://www.it-expertise.com/ 30

Image 14 - Roue de Deming 31

Image 15 - Le Cloud : catalyseur de l'innovation en entreprise 32

Image 16 - Facteurs internes et externes influencant la DSI - source : http://www.it-

expertise.com/organiser-sa-dsi-dans-un-environnement-en-mutation-permanente 35

Image 17 - Modèle de l’alignement stratégique, d’après Henderson et Venkatraman (1993)

37

Image 18 - Execution opérationnelle de la stratégie 37

Image 19 - Les SI, vecteurs de la transformation technologique 38

Image 20 - les SI à l’origine de la stratégie et source d’avantage concurrentiel 38

Image 21 - les SI prestataires de services opérationnels 39

Image 22 - Stratégie globale SI / Métiers 39

Image 23 - Sécurité et confiance dans le Cloud : deux aspects complémentaires 40

Image 24 - Passage de l’organisation 1.0 à l’organisation 3.0, Imed Boughzala, HBR, 2015

42

Image 25 - Les freins à l'adoption du Cloud en France - source : PAC (2014) 43

Image 26 - Change Management Framework - Aladwani (2001) 48

Image 27 - UTAUT - Venkatesh, (2003) 48

Image 28 - Type de relation et niveau de maturité 49

Image 29 - Leaders charismactiques et comportement des utilisateurs - Derrick J Neufeld ,

Linying Dong & Chris Higgins (2007) 52

Image 30 - Une des organisations traditionnelles d’une entreprise, en silos 53

Image 31 - Possible organisation où les échanges entre DM et DID sont maximisés 54

Image 32 - Des étapes pour réussir un projet de transformation Cloud 57

Image 33 - Modèle de Dreyfus - setandbma.wordpress.com, 2013 59



Remerciements

J'adresse mes sincères remerciements aux personnes qui m'ont aidé dans la

réalisation de ce mémoire.

Tout d’abord à Michaël Pressigout, DSI de l’institut Pasteur qui, avec une vision juste

et moderne du Cloud, et malgré un emploi du temps très chargé, a pris du temps

pour échanger avec moi et me conseiller.

Je souhaite également remercier Nuageo, Cabinet de conseil-as-a-service spécialisé

Cloud Computing, et particulièrement Antoine Jacquier, qui m’a permis de conjuguer

cette étude à ma mission professionnelle ; me soutenant à tous les niveaux du début

à la fin. Je remercie globalement aussi les autres collaborateurs Nuageo, Alexis,

Benoît, François, pour leur aide et les riches échanges qui ont contribué à ma

réflexion.

Enfin, je remercie l’ISEP qui, au sein de la formation Expert Cloud Computing et

SaaS, m’a donné l’occasion de développer mes connaissances Cloud, et de franchir

un cap dans mon expérience professionnelle.



Résumé

Le Cloud transforme la manière d’appréhender l’informatique. Plus qu’une révolution

technologique, c’est un aboutissement qui reflète des changements économiques et

comportementales durables dans la société. Comme chaque évolution structurelle,

le Cloud génère attentes, craintes, et espoirs. Il est complexe d’en comprendre tous

les enjeux pour maximiser son utilisation, lorsque la technique n’est qu’une petite

partie de l’équation.

Comment alors repenser les directions informatiques pour prendre en compte ces

nouvelles considérations et se reconstruire comme partenaire stratégique de

l’entreprise ?

Nous commencerons par une étude du Cloud, des techniques et technologies

associées, pour ensuite s’intéresser à la manière dont les DSI peuvent évoluer pour

les intégrer.

Nous observerons que la définition marketing du Cloud est également forte de sens,

catalysant les espoirs et les attentes de certains utilisateurs, les craintes d’autres.

Cela sera l’occasion de se pencher sur le facteur humain en jeu derrières les

changements qu’implique le Cloud et surtout sur les moyens de les comprendre, les

prendre en compte et les optimiser.

Au final nous verrons que technologies, organisation et humains sont les trois

facteurs clés d’une transformation Cloud qui, semble être bien plus profonde qu’une

simple transformation informatique.



Executive summary

Cloud Computing transforms our ways of understanding IT. More than a

technological revolution, it is a result that reflects sustainable economic and

behavioral changes in society. Like every structural change, Cloud generated

expectations, fears, and hopes. It is complex to understand all the issues to

maximize its use when techniques are only a small part of the equation.

How then rethink IT departments to reflect these new considerations and rebuild it as

a strategic partner of the company?

We’ll begin with a study of cloud related techniques and technologies, and then we

will focus on how CIOs can evolve to integrate them.

We will see that the marketing definition of Cloud Computing makes sense as well as

it catalyzes the hopes and expectations of some users and other fears’. This will be

an opportunity to address the human factor in play behind the changes implied by

the Cloud as well as ways to understand them, take them into account and optimize

them.

In the end we will see that technology, organization and humans are the three key

factors for Cloud transformation, whose seems to be much deeper than just IT

transformation.



Introduction Le Cloud Computing est un des sujets informatiques à la mode de cette deuxième

décade du 21ème siècle. Il fait la une de la presse, les peurs et les joies des DSI, on

le fait entrer dans le milieu académique pour le théoriser et le pratiquer, certains le

placent même au cœur de la troisième révolution industrielle. Pourquoi une telle

importance ?

Tout d’abord, il est important de ne pas confondre Cloud et SaaS : le SaaS est une

des techniques du Cloud mais est avant tout une rupture d’usage. Suivant la

démocratisation de l’informatique, l’intégration naturelle de certaines limites

techniques dans l’inconscient collectif, a petit à petit bridée les attentes des

utilisateurs vis-à-vis de leurs outils. Aujourd’hui, on assiste à une simplification des

solutions et à une abstraction forte de leur complexité technique, pour se concentrer

sur les usages. Cette démarche est principalement influencée par une évolution des

besoins, tant au niveau privé, qu’au niveau professionnel. Cependant, en entreprise,

faire évoluer le cadre et les réponses afin de les faire correspondre aux attentes est

bien plus complexe.

Dès lors, quels sont les impacts du Cloud Computing sur le rôle de la DSI face aux

directions métier ?

Face à l'avènement du Cloud, on assiste parfois à des réponses qui témoignent

d’une peur ou d’un manque de maîtrise de la part des entreprises en général, et des

DSI en particulier. Ces derniers ne veulent ou ne peuvent pas toujours évoluer assez

vite, et peuvent être perçus comme des freins à la croissance des métiers.

Cependant, d’autres réponses montrent quant à elles, des DSI qui innovent et qui

sont à la pointe en termes de technologies… sans pour autant parvenir à faire

bénéficier de ces avancées aux métiers. Enfin, certains parviennent à se positionner

comme partenaires privilégiés et à créer un contexte d’échange où technique et

usages sont intimement liés. Comment ces derniers parviennent là où d’autres

échouent ?

Nous tenterons de répondre à cette question en étudiant tout d’abord le contexte qui

a permis au Cloud d'émerger, pour ensuite étudier comment les DSI peuvent évoluer

pour s’adapter et devenir un atout stratégique pour l’entreprise autour de trois axes :

les techniques, les organisations et les personnes.



1. Le Cloud : révolution technologique ou réponse

naturelle aux besoins et usages ?

a. Définition du Cloud :

i. Base du NIST

Le terme “Cloud Computing” est un buzzword. Endossant la majorité des espoirs et

des craintes de l’informatique en 2015, il semble impossible de l’ignorer, ou

simplement d’ignorer la réalité derrière ces deux mots. Toutefois, entre les

définitions originales, les dérives marketing, et les scepticismes techniques, il

semble important de prendre le temps de mettre en avant la définition concrète et

officielle du Cloud Computing.

Celle proposée par le NIST semble juste et précise, et permet d’obtenir une base de

vision objective pour qualifier par la suite les définitions diverses venant compléter,

enrichir ou même dénaturer le concept du Cloud.

Selon le NIST, le Cloud Computing doit posséder 5 caractéristiques essentielles :

Le service doit être en libre-service, à la demande. En théorie un service doit

pouvoir être démarré et arrêté à la demande, sans période de carence. Même

si, en réalité, beaucoup de services gardent un niveau de granularité dans la

flexibilité qui n’est pas toujours fin ;

Il doit être accessible sur l’ensemble d’un réseau. Pas de VPN, de réseau

privé, tout passe par Internet ;

Il doit y avoir une mutualisation des ressources ;

Il doit être rapidement élastique (adaptation rapide à une variation du besoin) ;

Enfin, le service doit être mesurable (mesure et affichage de paramètres de

consommation, de qualité de service etc.)

Le NIST distingue également trois niveaux de service :

1. Le logiciel en tant que service (SaaS) : par exemple une banque « loue » un

logiciel de comptabilité, en ligne, à la demande, chez un prestataire externe ;

2. La plateforme en tant que service (PaaS) : une solution qui propose une suite

logicielle et les outils d’intégration et de suivi ; par exemple, un serveur web

avec une suite d’outils adaptés au déploiement de site ;

3. L’infrastructure en tant que service (IaaS) : la totalité de l’infrastructure

(ressources matérielles) est externe. Par exemple, capacité de stockage et

capacité de calcul à la demande sur un réseau.



Et enfin 4 modèles de déploiement :

1. Le nuage privé (au sein d’une même organisation)

2. Le nuage communautaire (réservé à une communauté)

3. Le nuage public (ouvert au grand public)

4. Le nuage hybride (composition de deux ou plusieurs types de nuages)

Image 1 - Les modèles de déploiement Cloud

Une autre appellation est de plus en plus utilisée, même si elle n’est pas explicitée

par le NIST : le Cloud dédié. Ce dernier nous pousse toutefois à faire la différence

entre Cloud privé interne et Cloud privé externe. Dans le premier cas, les serveurs

sont privés et hébergés dans les locaux de l’entreprise.

Dans le cas du Cloud privé externe, les serveurs sont privés mais hébergés dans le

Datacenter d’un prestataire. La plupart du temps ils sont loués par le client. On peut

parler ici de Cloud dédié, dans le sens où les serveurs ne sont pas mutualisés (non

partagés avec d’autres clients).



Image 2 - monotenant et multitenant

Quelques détails sur la mutualisation (multi-tenancy) : on peut l’entendre à deux

niveau, infrastructure (IaaS) et applicatif :

Pour l’infrastructure (IaaS) : le principe de multi-tenancy implique que des

clients utilisant des machines virtuelles séparées, différentes et étanches,

partagent la même infrastructure physique (le même serveur). On pourra parler

de nuage public.

Pour l’applicatif (SaaS) : Ici le principe de multi-tenancy implique simplement

que plusieurs clients utilisent la même instance d’une application. Dans ce cas

la confidentialité entre les clients peut être assurée par l’application en elle-

même (par les rôles et autorisations), par la base de données (tables

spécifiques, clés spécifiques, voir bases spécifiques par client), etc.

On peut parler théoriquement d’application « as a service » (SaaS), seulement si

une seule et même instance de l’application est utilisée par tous ses utilisateurs. De

fait, tous les services SaaS sont “multi-tenancy” et sont donc supportés par un Cloud

public.

Ces définitions permettent avant tout de déterminer si l’on est dans un modèle Cloud

ou non. Elles permettent ensuite de dégager certaines caractéristiques propres à un

type de Cloud ou à un modèle de déploiement qui donne l’occasion à son utilisateur

de pouvoir rapidement identifier les enjeux liés les plus communs, pour mieux savoir

vers quoi se diriger en fonctions de ses usages.



ii. Compléments : entre usages, marketing, et réalité

La définition du NIST offre un cadre très concret à ce qu’est le Cloud Computing.

Cependant, la définition “populaire” repose avant tout sur des promesses d’un

informatique nouveau, plus efficace, à la demande et moins coûteux. Dans un sens

cela reflète une certaine réalité.

Une des origines du Cloud à grande échelle peut se trouver chez AWS (Amazon

Web Services), dont l’objectif premier était de rentabiliser des infrastructures

performantes mises en place pour supporter les montées en charge du site e-

commerce Amazon durant la période des fêtes. Pour compenser le coût des

investissements, l’entreprise met un place un service de location de sa puissance

non-utilisée. La promesse pour les utilisateurs ? Des machines virtuelles à la

demande, un paiement à l’usage, une élasticité des ressources. L’attrait économique

d’un tel modèle, pour le fournisseur, comme pour le consommateur est évident.

De plus si l’on imagine la solution Cloud comme une solution à part entière, et non

simplement comme un complément, on voit rapidement que la location de machine

virtuelle, ou d’ “énergie informatique” en somme, présente un autre avantage : même

si les organisations doivent s’adapter et mettre en place des pratiques pour

supporter ce nouveau modèle, il n’y a pas d’investissement technologique.

Toutefois, il est important de garder en tête qu’un tel modèle ne peut être rentable

dans toutes les situations : il est normal qu’une utilisation forte et constante de

ressources informatiques, sur une longue période de temps puisse se révéler être

moins coûteuse en investissant dans un serveur, qu’en louant en permanence un

serveur Cloud. Le débat sous-jacent est celui de la différence entre l’OPEX et le

CAPEX. Là où un modèle “on premises” sera essentiellement basé sur de

l’investissement (CAPEX), le modèle Cloud se fera principalement financer par de

l’OPEX, laissant plus de liberté dans la manière de gérer le budget de l’entreprise. Il

est cependant important de comprendre que le CAPEX est un modèle encré dans

les entreprises et qu’il peut parfois être plus compliqué de justifier une augmentation

du budget OPEX que du budget CAPEX, dans un contexte où les frais de

fonctionnements doivent se réduire. De même si l’on prend l’exemple des

collectivités françaises qui cherchent avant tout à réduire leurs dépenses de

fonctionnement, la logique budgétaire du Cloud ne leur apparaît pas comme

pertinente.

Si l’on s'arrête à nouveau sur la deuxième caractéristique du Cloud communément

admise, le fait qu’il propose un service “à la demande”, on réalise que cette définition

est inhérente aux concepts premiers du Cloud Computing. Encore une fois, il est

important d’être conscient que la réalité est un peu plus complexe que la théorie.

Bien que la quasi-totalité des services Cloud soient “à la demande”, la différence

réside dans le niveau de granularité que les fournisseurs proposent : location



mensuelle pour accéder à une application, location horaire, location minute, à

l’accès, à la fonctionnalité ?

L’impact budgétaire peut être très important. De plus, dans un modèle centré sur les

usages des utilisateurs, la question d’une facturation en fonction de l’usage peut se

poser. Par exemple : pour un logiciel de restauration collective, une facturation au

nombre de repas semblerait cohérente avec la notion de facturation “à la demande”.

Enfin revenons sur le dernier terme de cette définition populaire : “efficace”. En

entreprise et comme pour les particuliers, une informatique plus efficace est une

informatique qui répond mieux aux besoins des utilisateurs. Ces besoins évoluant de

plus en plus vite, le Cloud offre une flexibilité et une adaptabilité accrue. De même,

comme nous l’avons déjà abordé, le coût, inhérent à la mutualisation, est de manière

générale réduit surtout en termes d’investissements.

Cependant, l'intérêt ici réside dans la notion d’“usages”. Le Cloud, et le SaaS en

particulier, proposent des applications standardisées, en opposition avec les

solutions spécifiques. Ainsi, comment une solution standard peut-elle mieux

répondre à des besoins qu’une solution construite pour répondre précisément à ces

besoins ?

Il est important de prendre en compte le contexte économique du début de la

deuxième décade des années 2000 : pour simplifier, tout évolue très vite, de

nouveaux marchés se créent et d’autres se meurent avec des cycles - plus proches

de la notion de bulles que de cycles - qui sont de plus en plus réduits, de moins en

moins réguliers, de moins en moins prédictifs.

Video 1 - La fin des cycles économiques – Nicolas Doze – BFMTV 2014

Face à ces nouveaux marchés en évolution perpétuelle, l’atout numéro un des

entreprises reste l’adaptabilité, et l’adaptabilité rapide. Il faut pouvoir adresser une

opportunité au moment où on l’identifie, avant qu’il ne soit trop tard. Pour cela, les

entreprises ont besoin, entre autres, d’outils informatiques performants, adaptables

et qui ne demandent pas d'investissement démesuré.

Ce dernier point est important, le manque de certitude est compensé par un

nouveau modèle qui se généralise : le “trial and error” (ou Lean startup).



Image 3 - Principe du lean startup – source : http://www.sitewebefficace.com

Si le contexte est incertain, il faut tester les idées, les poursuivre si elles

fonctionnent, sinon changer. Dans cette démarche, si le temps de réalisation (TTM)

ou le coût, est trop important, l’entreprise ne sera pas capable de s’adapter au

marché.

Le Cloud, une fois maîtrisé, répond à ces prérogatives : une réalisation rapide, des

moyens de tests et des cycles de développements courts, un coût maîtrisé. De plus,

les outils standardisés permettent aux entreprises d’adresser de nouveaux besoins à

moindre coûts (ex : Big Data), et surtout de ne pas retravailler des besoins

informatiques qui ne sont pas différenciant, pour se concentrer sur le cœur de métier

là où se trouve la valeur ajoutée. Réduire l’effort sur des fonctions support permet,

en effet, de gagner en compétitivité en ayant plus de ressources disponibles pour

travailler sur le cœur de métier.

Il est donc primordial de comprendre ce qui se cache derrière cette définition

commune, ou “populaire” du Cloud pour être capable de mettre en lumière les

enjeux qui lui sont inhérents.



b. Quelle(s) révolution(s) ou évolution(s) ont donné naissance au Cloud

Computing ?

i. Historique : une évolution du SI depuis les années 60

Si l’on doit retracer les origines informatiques du Cloud Computing, il faut passer par

un certain nombre de phases, y compris le grid et l’utility Computing et le modèle

ASP (application service provider), pour enfin arriver au modèle SaaS (Software as a

service).

On parle pour la première fois de Cloud Computing en 1996 (Compaq) mais

globalement, l’idée de distribuer des ressources informatiques à la demande par le

réseau remonte aux années 60. Joseph C. R. Licklider, directeur de l’IPTO

(Information Processing Techniques Office) à l’ARPA de 1962 à 1969, a déjà pour

vision que toute personne dans le monde soit interconnectée et ait accès à des

programmes et des données depuis n’importe quel endroit. Également John

McCarthy, qui proposa dans les années 60, l’idée que la puissance de calcul soit

délivrée comme une commodité publique, est considéré comme un des penseurs qui

a inspiré le Cloud.

Dans ces mêmes années 60, la plupart des gens ont utilisé un modèle informatique

centralisé, généralement constitué de superordinateurs (mainframe) situés dans un

centre de données interne. Ces supercalculateurs, avec tous les logiciels, les

périphériques de stockage, imprimantes, etc. étaient très chers. Les années 1980

ont répondu à la demande croissante de microprocesseurs de plus en plus

puissants, moins chers ouvrant la voie à de faibles coûts et la simplicité.

Grid et Utility Computing entrent en jeu dans les années 1990. Ces deux modèles

sont une réponse adaptée à plusieurs problèmes : les super calculateurs sont chers

et les ordinateurs personnels pas assez puissant. Internet a explosé dans le monde

de l'informatique faisant évoluer les modèles centralisés client-serveur vers

l'informatique basé sur Internet et les réseaux. L'idée derrière la grille de calcul était

de faire de l'énergie de l'ordinateur (le “compute”) une commodité tel un réseau

électrique. Le Grid Computing est une infrastructure informatique virtuelle constituée

d’un ensemble de ressources partagées, distribuées, délocalisées, hétérogènes

(contrairement à un cluster) et autonomes. Ce principe se base principalement sur

les ressources (processeurs) non utilisées par des ordinateurs ou serveurs pour

fournir une puissance de calcul supérieure, partagée entre différents utilisateurs.

L'Utility Computing quant à lui, se rapporte principalement à la manière dont le

service est délivré en permettant de louer des services informatiques à l’usage, à la

demande, réduisant ainsi le coût et facilitant l’accès aux ressources. Toujours dans

cette logique d’optimisation et de baisse de coûts, les fournisseurs d’applications

hébergées (ASP) ont émergé fin 1990. Un ASP fournit à plusieurs clients une même

instance d’une application. Cela se justifie particulièrement pour les applications



supports ou standardisées (médical), permettant donc aux entreprises d’externaliser

une partie de leur SI et de se recentrer sur leur cœur de métier. De plus en plus le SI

tend vers la définition de McCarthy : une commodité publique.

Au final, le SaaS est un aboutissement de toutes ces manières de penser

l’informatique : utilisation des ressources hétérogènes disponibles (grid), utilisation

du service à la demande (utility), applications hébergées dont les instances sont

partagées par les utilisateurs et rôle majeur des SLA (ASP). Reprenant également

les principes de facturation à la demande elle devient l’évolution ultime théorique de

l’informatique comme commodité. Bien sûr, d’autres aspects fonctionnels et

techniques, tels que l'élasticité, restent déterminants.

Aujourd’hui le Cloud Computing désigne donc une collection de services à la

demande, fournis par Internet et évolutifs en fonction de la taille de l’entreprise ou de

ses besoins.



ii. Un contexte où des technologiques arrivent à maturité de manière

concurrente

Il est donc aisé de comprendre que l’idée d’une informatique à la demande où les

contraintes sont limitées, n’est pas une idée neuve. Cependant qu’est-ce-qui a

permis au “Cloud” d'émerger : est-ce de réelles innovations ou simplement un

contexte où des technologies arrivent à maturité de manière concurrente ?

Tout d’abord il est important de faire un point sur la puissance de nos ordinateurs :

entendons capacité de calcul et capacité de stockage.

Image 4 - Evolution des capacités informatiques depuis les années 60 – source:

www.rethinktechnology.wordpress.com

Tout d’abord la capacité de calcul augmente toujours de nos jours selon la loi de

Moore qui précise que “le nombre de transistors par circuit de même taille allait

doubler, à prix constant, tous les 18 mois”.

De même, les capacités de stockage explosent et leur coup diminue passant d’une

moyenne de 193$ en 1980 pour un mégabyte, à 8cents pour un giga byte en 2010.

Cette évolution est supportée par une optimisation des processus de fabrication

ainsi que par des innovations technologiques.

Ici, il est important de souligner que l’évolution de la puissance de nos ordinateurs se

fait en parallèle d’une baisse continue des coûts, permettant à l’informatique de se

diffuser de plus en plus. Par contre, il est commun que des serveurs ne soient pas

utilisés à 100% par leur propriétaire. Par exemple, une entreprise achetant un

serveur pour supporter son site Web, n’utilisera qu’une petite partie de sa capacité.

Que faire du reste ?



La virtualisation est une partie de la réponse. Le principe premier de la virtualisation

est de créer une couche d’abstraction entre l’OS et les ressources physiques

permettant ainsi de gérer des ressources physiques indépendamment des “services”

informatiques :

Modèle classique :

Image 5 - Modèle classique d'un serveur - source : http://www.culture-informatique.net/cest-quoi-la-virtualisation/

Virtualisation :

Image 6 - Modèle virtualisé - source : http://www.culture-informatique.net/cest-quoi-la-virtualisation/

L’avantage de la virtualisation est donc de pouvoir optimiser la gestion des

ressources physiques. En effet, un service informatique a besoin de ressources pour

fonctionner (mémoire, CPU, réseau) - à chaque requête, ce service consomme ces

ressources, avant de retourner à un état d’attente. De fait, il n’utilise pas en

permanence 100% des ressources. Elles peuvent donc être allouées à un autre



service, potentiellement sur un autre ordinateur partageant les mêmes ressources

virtuelles. Cet “ordinateur virtuel” est appelé “machine virtuelle”.

Encore une fois la notion de virtualisation remonte aux années 60, mais elle s’est

réellement démocratisée à la fin des années 90, permettant aux entreprises

d’optimiser leurs ressources informatiques, de faire des économies d’infrastructures,

et d’avoir une redondance de leurs serveurs physiques. Un hyperviseur peut, en

effet, virtualiser les ressources d’un serveur mais également de plusieurs.

La virtualisation renforce encore plus l’intérêt du modèle client-serveur en permettant

de rendre plus flexible l’infrastructure supportant les applications.

Il est maintenant intéressant d’observer l’évolution des réseaux d’accès. Ils sont en

effet la pierre angulaire des communications entre terminaux locaux et serveur. Ici,

nous allons nous concentrer sur l’accès Internet. Entre les années 80 et nos jours,

les débits ont progressé très fortement. Sans rentrer dans le détail, il est d’autant

plus pertinent de s’intéresser à l’évolution de la couverture de ces réseaux et du

nombre de personnes y ayant accès : passant de 16 millions en 1995, à 3,2 milliards

en 2015.

Image 7 - Evolution des débits réseaux dans le monde depuis 1985 - source :

http://www.internetworldstats.com/stats.htm



Notons toutefois un taux de pénétration encore assez inégal en fonction des régions

du monde :

Image 8 - Taux moyen de pénération d'internet dans le monde (2013) - source : Internet World Stats

De même, les années 2000 ont été marquées par un fort développement des

réseaux et des terminaux mobiles : comme pour les postes fixes les performances

ont augmenté (même si pour les terminaux mobiles, les coûts ont continué

d’augmenter plus fortement que pour les réseaux fixes).

Au final, on observe que le réseau est devenu plus rapide, plus accessible, et surtout

plus disponible, malgré de grosses inégalités en fonction des régions du monde.

Un autre élément important dans le développement de l’informatique vers le Cloud,

cette fois mois technologique, est l’infogérance. Il s’agit d’un service visant à confier

dans la durée, à un prestataire, tout ou partie du SI d’une entreprise, dans le cadre

d’un contrat. L’objectif initial de cette démarche est de réduire les coûts : désormais

les entreprises utilisent l’infogérance comme levier de transformation. En effet,

l’externalisation des services permet de profiter de l’expertise forte du prestataire, et

surtout de dégager du temps et des ressources pour se concentrer sur le cœur de

métier. Apparu dans les années 1990, le concept s’est peu à peu structuré et

professionnalisé pour gagner la confiance des clients et proposer toujours plus de

services à valeur ajoutée à ces derniers (TMA, BPO…). Là où cette pratique joue un

rôle primordial dans l’histoire du Cloud, c’est qu’elle est le premier pas dans la

“consumérisation” des services informatiques - pour la première fois, on confie ses

serveurs (ou leur contenu) à un tiers de confiance. Toutefois, il reste encore deux

points qui ont permis au Cloud, et plus particulièrement au SaaS, de se construire et

de se développer : l’HTML5 et les APIs.

En effet, lorsqu’une application est standardisée (comme les applications SaaS) et

se veut disponible sur n’importe quel terminal d’accès, il faut une interface unique

pour l’utiliser. Le point commun des terminaux est souvent le navigateur Internet.

Cependant jusqu’à la fin des années 2010, le HTML (langage principal des sites

Internet) ne permet qu’une interaction limitée avec les utilisateurs, et donc une



interface relativement basique. Cela va très vite évoluer avec le HTML5, permettant

d'accéder aux ressources du terminal l'exécutant, qui propose nativement des

standards pour l’audio et la vidéo, supporte le CSS3 qui permet d'exécuter des

sites/applications adaptatif (responsive design), leur permettant de s'exécuter avec

le même code sur un smartphone, une tablette, un ordinateur, tout en adaptant son

interface au terminal et ses spécificités. De plus, une gestion du mode “déconnecté”

(offline) permet de laisser plus de marge aux éditeurs d’applications pour gérer les

pertes de connectivité.

Enfin, une fois des applications SaaS disponibles, se pose le problème de

l’intégration (entre elles et avec les systèmes traditionnels). La réponse à ce besoin

est les API (Application Programming Interface). Interface d’échange standardisée,

elle permet d’exposer ou de consommer des données, dans le but de lier deux ou

plusieurs applications distinctes. Ici l'enjeu est majeur, car dans une application

SaaS, l’instance est unique et le code partagé par tous les utilisateurs : pas de place

pour les développements spécifiques. Les APIs, qui s’activent sans impacter le code

standard, comme une couche supplémentaire exposant ou consommant des

données, sont la réponse à ce manque de personnalisation : nouvelles fonctions,

intégration, migration de données.

Ainsi on observe que le Cloud n’est pas une innovation de rupture mais plus une

arrivée à maturité de plusieurs technologies et pratiques, associées à de réelles

innovations technologiques, mais aussi à une évolution des comportements. Ce

dernier point est important car ils expliquent la raison du succès majeur et massif du

Cloud et l’inscrit dans la durée : c’est avant tout une réponse à de nouveaux

comportements et donc à de nouveaux usages.



iii. Une technologie qui répond à des besoins

Si, en regardant l’évolution des technologies depuis cinquante ans, on peut voir une

tendance se dessiner au sein de laquelle le Cloud semble être un aboutissement

pour de nombreux utilisateurs, c’est avant tout parce qu’il répond à des besoins -

certains relativement neufs - et d’autres bien plus historiques.

Avant de passer en détail les besoins auxquels répond le Cloud, attardons-nous

d'abord sur les limites des technologies précédentes, génératrices de frustrations qui

ont favorisé l'émergence de nouveaux modèles.

La plus grande révolution des dix dernières années est bien sûr l'avènement du

mobile :

Image 9 - Terminaux d'accès à internet, par foyer - source : ITU World Télécommunication (2012)

Les accès Internet sont désormais majoritairement mobiles (source : Google 2015),

induisant un besoin constant d’accès à des applications par des terminaux mobiles

(smartphones, tablettes) - et qui dit mobile, dit à n’importe quel endroit, à n’importe

quel moment : cela sous-entend, entre autres, en dehors du réseau interne à une

entreprise. C’est pourquoi les applications doivent être accessibles par le réseau

commun : Internet.

Les points suivants, expliquant l'émergence du Cloud, résident dans les évolutions

récentes de l’économie : les cycles (instables), sont de plus en plus rapides, et les

prévisions de plus en plus incertaines. Il semble donc difficile, voire impossible, de

penser une application pour les trois années à venir ou de construire une salle

serveur en la provisionnant pour ses besoins en stockage des cinq années à venir.

Dans un cas, le besoin est clairement de pouvoir développer ou utiliser des

applications qui sont disponibles très rapidement : le temps de mise à disposition

(TTM) doit être faible car les besoins changent rapidement et la capacité

d’adaptation des entreprises pour y répondre est en lien direct avec leur

performance. De plus, construire, maintenir et faire évoluer une application n’est pas



toujours rentable car cela demande une expertise parfois très éloignée du cœur de

métier de l’entreprise. De même, pouvoir prévoir l’évolution d’une charge ou d’un

besoin en stockage semble impossible : c’est se limiter, ou être trop coûteux, donc

être moins compétitif. Par exemple, investir dans une infrastructure pour supporter

une demande saisonnière n’est pas rentable dans de nombreux cas.

Il devient essentiel de pouvoir s’adapter au contexte économique fluctuant : les

ressources informatiques doivent pouvoir être élastiques et à la demande.

Dernier point décisif : le besoin de collaboration. Les équipes sont de plus en plus

éloignées, travaillent à différents endroits, dans différents fuseaux horaires et sur

différentes plateformes. La collaboration doit être soutenue par des outils

informatiques efficaces, disponibles partout, en temps réels, avec une problématique

forte de disponibilité et de sécurité. De plus, ces outils de support doivent être

immédiatement mis en place pour permettre aux équipe de travailler : attendre 3 ou

6 mois qu’ils soient disponibles signifie une perte non négligeable pour l'entreprise.

Le Cloud est donc une double réponse : un moyen de faire baisser les coûts

informatiques, et surtout une solution aux attentes et besoins des utilisateurs de

manière générale. Côté utilisateurs, comme dit précédemment, c’est la mobilité, la

facilité, l’usage à la demande, la rapidité, et la flexibilité. On choisit le Cloud car il

répond à un usage, pas parce que c’est du Cloud. De plus, le modèle de

déploiement ne nécessitant pas d’investissement, la gestion du budget (100%

OPEX) est assurée directement par les directions métiers, par leur budget de

fonctionnement. Ils gagnent ainsi, en théorie, une certaine autonomie vis-à-vis de la

DSI voire de la DAF et sont capables d’activer un service Cloud par eux-mêmes,

sans avoir besoin de prévoir un budget d’investissement dédié comme pour les

projets SI traditionnels. On assiste à ce que l’on appelle communément, un “retour

au pouvoir des utilisateurs”. Nous nous attarderons plus tard sur la pertinence de la

gestion et la maintenance de projets SI sans impliquer la DSI ou les autres entités

de l’entreprise, qui souvent posent également problème.



iv. La limite des solutions actuelles

Malgré la réponse évidente à de nombreux besoins et problèmes qu’est le Cloud,

cette réponse, qui ne peut être globale, n’est pas non plus totalement mature.

Tout d’abord, l’importance du réseau a été évoquée, sans réseau, sans Internet, pas

de Cloud. Toutefois, malgré les progrès et les initiatives pour fournir un accès à

Internet vaste, trois problèmes se posent : la couverture, le débit disponible et la

sécurité. Sans passer chaque point en détail, il est primordial de comprendre que

c’est un des principaux freins à l’adoption du Cloud dans certains cas - même si un

mode offline dégradé est devenu courant sur certaines applications.

Ensuite, la facturation à la demande : cette facturation n’a pas toujours le niveau de

granularité suffisant pour réellement s’adapter aux usages des utilisateurs. Une vraie

facturation à l’usage d’un logiciel, comme évoqué au début du chapitre, devrait

s’appuyer sur les processus métiers supportés par ce logiciel. Ce n’est

généralement pas le cas, et beaucoup de modèles de facturation reposent

uniquement sur le nombre mensuel d’utilisateurs. Pour autant cela évolue vite, et de

nouveaux modèles de facturation à la demande émergent (facturation au chiffre

d’affaire, au nombre de clients dans les bases, etc.).

Enfin d’une manière générale, le Cloud est une nouvelle technologie, qui apporte un

nouveau contexte et de nouveaux enjeux : externalisation poussée,

contractualisation, aspects financiers complexes, sécurité à repenser, nouveaux

modèle technologiques, etc. Naturellement cela entraîne un déficit de maîtrise et

donc une perte de confiance qu’il faudra compenser par la suite.



v. Des besoins de soutien SI en évolution rapide et permanente

Globalement, le Cloud est une réponse à des besoins et malgré des limitations, a vu

son adoption fortement progresser. Quels sont les éléments conjoncturels qui ont

permis cette émergence du Cloud ?

Image 10 - Types de Cloud utilisés en entreprise - source : CloudIndex de PAC (2014)

Tout d'abord, il est important de mettre en avant le fait que les entreprises ont

majoritairement terminées les implémentations d’ERP en général. Ces projets se

font souvent dans la douleur (avec un taux de succès de 60%). Toutefois, les

entreprises ayant maîtrisé cet aspect de leur SI, disposent dorénavant du temps et

des ressources pour se poser la question sur ce qui peut être fait pour les fonctions

non couvertes par l’ERP, avec des projets plus simples, plus efficaces, et moins

coûteux.

Image 11 - Résultats des projets ERP - source : ERP Report de Panorama consulting (2013)

Ensuite, comme nous avons commencé à l’aborder, si pour les consommateurs de

services Cloud, l’usage et le coût sont primordiaux, il en est de même pour les

éditeurs. Pour ces derniers, le modèle Cloud est une réelle opportunité de réduire



les coûts et les intermédiaires dans leur processus de distribution. De même, c’est la

possibilité de déployer leurs solutions en les rendant disponibles très rapidement, à

un coût réduit. Il est important de noter que ce nouveau modèle pousse cependant

une nouvelle équation économique : rentabiliser, et gérer des ventes à l’usage plutôt

qu’à la licence. Cela explique parfois le manque de maturité dans la gestion de leur

modèle de facturation, et la difficulté à s’éloigner de la traditionnelle licence

utilisateur. De plus, ils doivent aussi faire face à une réorganisation pour supporter

de nouveaux pans de leurs métiers, inexistants auparavant, tel que la distribution.

Au final, on retrouve les mêmes avantages que pour les utilisateurs finaux à une

différence : les éditeurs poussent de plus en plus le SaaS, pour des raisons

pratiques évidentes mais surtout pour des raisons économiques qui dépassent

parfois la logique métier. Il est donc important de garder cela en tête pour éviter de

se faire tromper lors de son choix dans un marché dirigé par l’offre parfois plus que

par la demande.

Enfin, le Cloud Computing s’inscrit au sein d’un plus grand cycle de tendances de

l’informatique : la consumerization, à savoir le fait que les usages des entreprises

proviennent du monde personnel alors que jusqu’à présent, la transposition des

usages des entreprises permettait de garantir un succès commercial de masse.

Depuis plusieurs années, ce ne sont plus les usages des entreprises, mais les

usages privés qui sont les plus innovants. De fait, chaque employé cherche à

retrouver le confort des outils (souvent gratuits) qu’il utilise à titre personnel, dans le

cadre professionnel. De plus, l’évolution des habitudes de travail fait passer ce

besoin à l’état de nécessité, car les supports informatiques, les horaires et les lieux

étant de plus en plus variés et de moins en moins normés, l’accès à ses données et

ses applications à n’importe quel moment, depuis n’importe quel endroit ou support,

est un besoin vital pour garantir l’efficacité des collaborateurs de l’entreprise.



c. Dans le Cloud, le concept de DSI est-il encore pertinent ?

Dans ce contexte, où les applications et les ressources informatiques sont

accessibles de manière plus simple et où il semble que les utilisateurs peuvent

activer un CRM, comme ils activeraient leur compte mail personnel, dans quelle

mesure le rôle traditionnel de la DSI est-il encore pertinent ?

Ces nouvelles possibilités informatiques rendent les frustrations des utilisateurs face

aux DSI plus difficiles à accepter et peuvent mener à une tendance risquée : le

shadow IT. Le Shadow IT est la mise en place de systèmes d'information au sein

d'organisations sans approbation de la direction des systèmes d'information. Cela

peut aller d’un simple service de stockage à des applications complètes (CRM,

Marketing automation etc.). A n’importe quelle échelle, l’objectif est simple : obtenir

le service le plus adapté au besoin identifié. Avec le Cloud, de plus en plus

d’applications et services sont disponibles simplement et instantanément aux

utilisateurs. Ces derniers sont habitués à les mettre en place dans le cadre privé et

continuent simplement dans le cadre professionnel. La logique est simple : “si c’est

disponible, que ça me permet de mieux travailler, pourquoi m’en passer ?”.

Cet argument est tout à fait pertinent et reflète bien le problème dans le modèle

traditionnel des DSI : souvent, les outils fournis ne répondent pas complètement au

besoin des utilisateurs - en eux-mêmes ou dans le processus de mise à disposition.

Également il semble peu probable que la DSI soit capable de proposer des solutions

équivalentes aux solutions Cloud du marché, aussi nombreuses et complètes, à un

coût compétitif.

De plus, on observe dans les entreprises que les achats ont un rôle de plus en plus

important dans le choix des solutions ou des prestataires, dans un but d’optimisation

des coûts. Cela limite encore plus la marge de manœuvre des DSI.

Egalement, avec le Cloud, une grande partie des responsabilités de la DSI est

basculée sur le prestataire de service Cloud (mises à jour, MCO, etc.). Toujours

avec le Cloud, une autre partie des responsabilités dépend désormais de

compétences qu’une DSI traditionnelle ne possède pas forcément, principalement

légales ou juridiques. D’une manière générale, on observe que les projets SI font

intervenir des acteurs de plus en plus nombreux et variés, en interne et en externe.

Pour piloter correctement ces projets, la DSI aurait besoin d’un pouvoir de décision

plus fort et surtout plus transverse.

Au final, on observe que dans sa structure et son rôle actuel, la DSI ne peut faire

face à cette déferlante qu’est le Cloud. Entre une arrivée à maturité de nombreuses

technologies, des changements dans les comportements et les attentes des

utilisateurs et une économie qui évolue toujours plus vite, comment la DSI peut-elle

se repenser pour aider l’entreprise et améliorer ses performances ?

https://fr.wikipedia.org/wiki/Directeur_des_syst%C3%A8mes_d%27information



2. Comment la DSI peut se réinventer pour rester

pertinente afin de maximiser l’efficacité opérationnelle

de l’entreprise ?

a. La DSI, comme support premier des utilisateurs de Cloud

Comme résumé rapidement auparavant, le Cloud “est un retour au pouvoir des

utilisateurs”. Des applications moins chères qui s’affranchissent de nombreuses

problématiques propres à l’IT (le temps de mise à disposition, le coût de mise à

disposition, le coût de mise à jour etc.). Bien sûr, la vision limitée au côté utilisateur

est incomplète : il faut prendre en compte les nouveaux enjeux (intégration, sécurité,

contractualisation, réversibilité, etc.). De plus, cette sensation d’indépendance,

renforcée par les éditeurs qui s’adressent maintenant aux métiers en priorité, pousse

ces derniers à parfois se passer de la DSI pour obtenir telle ou telle application, peut

générer un sentiment de frustration chez les équipes IT. Pour ces dernières, il peut

être tentant de simplement refuser en bloc ce nouveau fonctionnement en se basant

sur des arguments concrets tel que la sécurité ou l’intégration. De même il est

complexe de remettre en cause un fonctionnement d’une DSI en place depuis de

nombreuses années.

Ainsi, si une telle situation se pérennise et que le dialogue entre DSI et directions

métiers est difficile, voire coupé, chacun continuera à avancer dans le sens qui lui

semble le meilleur, sans pouvoir obtenir une vision complète des enjeux. Si le

Shadow IT n’a pas besoin que la situation soit si dégradée pour exister, il est évident

que c’est à ce moment-là qu’il se développera le plus, et qu’il sera le plus risqué

pour l’entreprise.

Quel rôle peut alors jouer la

DSI ?

Avant tout, il est primordial

de prendre conscience des

raisons qui poussent les

utilisateurs à faire appel à

des solutions Cloud du

marché, et à le faire sans en

informer la DSI : coûts, lourdeur des processus, temps de mise à disposition,

manque de fonctionnalités disponible, etc. Bien sûr on parle ici principalement

d’applications non-cœur de métiers, qui ont souvent des processus standardisés

communs entre les entreprises. En effet, il est encore rare de trouver des solutions

du marché propres au cœur de métier de l’entreprise - même si cela se développe

beaucoup avec les applications “best of breed”. Concernant ces applications

support, faire appel à des solutions Cloud du marché est une solution pertinente.

Image 12 - 25% des employés en shadow IT en France



Cependant, ces applications vont être utilisées dans le cadre d’un SI existant au sein

d’une entreprise, avec des contraintes technologiques, légales, ou de sécurité. Ne

pas prendre en compte ces problématiques peut mettre en danger l’entreprise : c’est

pourquoi le Shadow IT représente une menace pour son bon fonctionnement. Pour

faire face à cela, en plus de comprendre les besoins des métiers, il faut comprendre

et appréhender ces enjeux. C’est là que la DSI a un rôle capital à jouer : sans

refuser l’utilisation de services Cloud, elle doit être capable de mettre en place un

cadre d’intégration pour faciliter, optimiser et sécuriser la mise à disposition de

services Cloud aux utilisateurs. Cela inclut bien sûr une partie technique (sécurité,

intégration), une partie juridique (contractualisation, analyse des contraintes légales),

une partie financière (facturation et refacturation de l’utilisation du service), et bien

sûr une partie métier (usages, intégration, formation). La DSI s’inscrit comme acteur

central permettant le fonctionnement optimal de ces services Cloud dans

l’entreprise.

Concrètement elle prend le rôle de fournisseur de services avec la capacité à

proposer des services, les encadrer, mais aussi à former et aider les utilisateurs en

cas de problème ou de nouveaux besoins. De ce fait, la DSI apparaît comme un

partenaire privilégié des métiers, et non comme le gendarme moralisateur à la

recherche de solutions non validées par ses services.

De plus, elle devra être aussi capable de répondre à des besoins spécifiques, en

trouvant des moyens de s’organiser dans ce nouvel environnement pour proposer

un support stratégique aux équipe métiers, avec une mise à disposition (delivery)

rapide, efficace et pragmatique.



b. Une évolution axée sur la technologie et les services, pour aujourd’hui

et pour demain, et toujours centrée sur les usages

Ce repositionnement stratégique de la DSI est évidemment crucial pour les

entreprises. L’influence de la technologie et du système d’information sur la

performance est plus que jamais décisive, que ce soit dans les opérations ou les

décisions. Ce support se doit d’être structuré, ou restructuré pour être efficace, et

cela doit se faire selon quatre axes : la technologie, le service, l'opérationnel et la

stratégie. En effet, la technologie, bien que décisive, n’est pas l’objectif mais le

moyen de fournir un service. Un service qui doit s’inscrire dans le présent

(l’opérationnel) et en permanence prendre les évolutions futures en compte pour ne

pas être réactif mais être proactif.

Image 13 - Les rôles de la DSI - inspiration : http://www.it-expertise.com/

i. Opérateur de l’excellence opérationnelle au quotidien

Lorsque on parle de transformation SI, de migration ou même d’évolution, il faut être

conscient d’une chose : le SI d’une entreprise ne peut, ni être stoppé pour une

longue durée, ni être décorrélé de l’existant. Même dans le cas de la création d’un

nouveau service, il doit prendre en compte les applications en place et son

intégration avec ses dernières ainsi que les processus métiers associés. C’est

pourquoi la gestion quotidienne des opérations doit être maîtrisée pour pouvoir

construire et faire évoluer le SI sur des bases saines. Pour cela, la DSI se doit de



viser une amélioration continue du fonctionnement qui repose sur la qualité de

service : être capable de mesurer les performances du service qu’on propose pour

ensuite identifier les manques et progresser. De nombreuses méthodes existent

mais un exemple, inspirée du Lean IT, le DMAIC permet de progresser à ce niveau

en gardant en tête la continuité de service et l’amélioration continue : le principe est

simple, il s’agit de définir le contexte, de mesurer sa performance, d’analyser ces

mesures pour identifier des leviers d’amélioration, les mettre en place, vérifier les

résultats et recommencer. On retrouve cette idée avec la roue de DEMING :

Image 14 - Roue de Deming

Cette optimisation de la qualité de service permettra en plus d’optimiser des coûts.

Également cette excellence opérationnelle repose sur une communication rodée et

efficace. En effet, maintenir des systèmes en conditions opérationnelles requière de

faire intervenir différentes équipes (internes, externes), sur différents sites, de

différents départements, gérant différentes applications, avec chacune leurs objectifs

et leurs priorités. Parvenir à coordonner ces équipes, tout en maintenant un niveau

d’échange clair et précis avec les directions métier, est une étape importante dans la

gestion de la performance opérationnelle du SI.



ii. Innovateur (cœur métier)

Avec l’évolution rapide et continue de l’informatique, de nouvelles technologies

émergent régulièrement (Big Data, mobilité, Cloud etc.), et, en plus de répondre à

des besoins, génèrent de nouvelles possibilités d’usage. La DSI a un rôle central

dans la mise en place et l’utilisation d’une veille technologique pour rechercher les

solutions qui resteront pérennes, afin de supporter les métiers et permettre la

création de valeur : pour l’IT, ses métiers, l’entreprise en général et ses clients.

Le Cloud n’est qu’un moyen pour favoriser l’innovation : c’est en effet toute une

organisation et des processus qui sont à mettre en place pour créer un climat qui lui

est propice. Tout d’abord, les économies permises par le Cloud, favorisent la R&D.

D’une part car plus de fonds sont disponibles, mais surtout car les coûts

informatiques de recherche et de test (machines de test, puissance de calcul,

applications à la demande) sont bien plus faibles alors que la valeur ajoutée métier

reste forte. Le Cloud favorise également le travail collaboratif et la réunion d’équipes

transverses capable de travailler sur une problématique commune. Ces outils

collaboratifs permettent également la capitalisation d’informations, et parviennent à

créer un contexte fertile favorisant l’innovation.

Ensuite, le Cloud facilite le passage de l’état de POC à l’état de solution finale, grâce

à des technologies et des méthodes ayant pour but d’optimiser le temps de mise à

disposition des applications (continuous delivery, méthodes agiles,

conteneurisation). Par exemple, une application qui doit être testée ou utilisée à

grande échelle, peut passer du stade de test, au stade “Live” en quelques minutes :

il suffit de lui allouer les ressources nécessaires.

Image 15 - Le Cloud : catalyseur de l'innovation en entreprise

La DSI est garante de la mise en place de ces méthodes, de ces techniques et en

charge de rendre ces processus d’innovation cohérents.



iii. Appui stratégique : travailler de concert avec les directions

métier, faire évoluer les processus, voire proposer de nouveaux

moyens

La DSI a un rôle stratégique dans l’entreprise - l’IT étant un support décisif pour les

métiers. Ce rôle est cependant parfois limité à la définition d’un schéma directeur,

proposant une vision à quelques années des évolutions technologiques supportant

la stratégie de l’entreprise. Mais pour être capable de réaliser cela, la DSI doit être

en mesure de connaître les métiers de l'entreprise, ses processus, et l’existant en

matière de technologie. Ainsi, elle pourra proposer des solutions technologiques

pertinentes et en accord avec la stratégie d’entreprise.

Toutefois, son rôle ne s'arrête pas là. En effet, la DSI endosse le rôle de chef

d’orchestre pour organiser la mise en place de ce plan et faire en sorte qu’il se

déroule au mieux entre les différents acteurs et collaborateurs de l’entreprise. De

même, elle sera en charge de l’adapter et de le faire évoluer en fonction du contexte

général.

Les projets mis en place et les organisations impactées, étant de plus en plus

transverse, il est donc primordial de maîtriser parfaitement les enjeux métiers

associés. A tel point que le rôle de la DSI sur certains projets peut se mélanger à

celui de la direction métiers et inversement : la technologie doit-elle directement

influencer les stratégies métier ou ces dernières doivent-elle guider la transformation

SI, se passant par la même occasion de la DSI, les outils étant désormais

“disponibles” sur le marché ?

La frontière entre les deux étant flou, un nouveau poste avec comme but unique de

réussir à tirer le meilleur de la transformation digitale visant la performance

opérationnelle des métiers, a vu son importance monter en flèche : le CDO (Chief

Digital Officer), en charge de la supervision des opérations de transformation

numérique. Par exemple, dans le domaine du marketing, une étude rapporte que

d’ici 2018 les DSI ayant des relations fortes avec les directions marketing réaliseront

25% de ROI (Gartner : “Gartner says IT leaders will need to develop a stronger

relationship with Marketing”, Jan. 2015). Nous reviendrons sur le rôle et la place du

CDO dans une organisation dans la dernière partie de cette étude.

C’est pourquoi les rôles de la DSI sont multiples, et visent traditionnellement à

fournir un service de qualité, adapté aux usages des utilisateurs. Dans un contexte

où les mutations technologiques sont permanentes et où l’urgence et l'incertitude

sont devenues des standards, la DSI se doit d’avoir un rôle de communication et

d’information au sein de l’entreprise pour l’aider à prendre les meilleures décisions,

le véritable enjeu étant encore une fois de parvenir à travailler en symbiose avec les

directions métiers pour être capable d’anticiper et de répondre au mieux à une

demande en constante évolution.

Bien sûr, la mise en place des nouveaux rôles de la DSI est spécifique au contexte

de chaque organisation, la question de l’équilibre entre ces rôles restant primordiale



et dépendant de nombreux facteurs internes et externes qui se multiplient et dont

l’influence est de plus en plus forte.



c. Supportée par une gouvernance transverse adaptée :

i. La position de la DSI évolue

Pour commencer, comme abordé auparavant, la position de la DSI évolue. Cela est

forcé par le contexte dans lequel elle évolue, tant externe qu’interne :

Image 16 - Facteurs internes et externes influençant la DSI - source : http://www.it-expertise.com/organiser-sa-

dsi-dans-un-environnement-en-mutation-permanente

Concernant les facteurs externes, on peut citer les cycles de vie courts des

solutions, les profils qualifiés qui sont rares, les évolutions réglementaires,

l'émergence de nouvelles technologies et une économie de l’instant, hyperactive. En

interne, l’IT est de plus en plus liée aux directions métiers et doit monter en

compétence sur des problématiques “métiers”. Elle doit faire face à des budgets plus

serrés ainsi qu’à une ouverture massive du SI sur l’intérieur, comme l'extérieur.

La DSI doit donc se repositionner en axant ses efforts autour des trois axes

développés dans la partie 2.2. (Excellence opérationnelle, agent du changement et

de l’innovation, partenaire stratégique). Pour réussir cette mutation, il faut prendre en

compte le contexte spécifique à l’entreprise.



Tout d'abord, il est important d’être capable de maîtriser la dette technologique. En

effet, la maintenance du SI (disponibilité, sécurité etc.) demande des efforts

soutenus. En parallèle, la DSI doit être capable de structurer cette dette pour ensuite

prioriser les actions à prendre pour fiabiliser les systèmes les plus critiques, ou les

faire évoluer en prenant en compte l’historique qu’ils supportent et l’impact sur le

reste du SI. Une gestion fine de ces actions, en plus de rendre le SI plus robuste et

plus sain, permet de dégager ensuite des budgets qui pourront servir pour d’autres

projets.

De plus, parvenir à moderniser un SI historique est un socle indispensable pour une

potentielle transformation (digitale). Si l’ouverture vers l’extérieur du système

d’information est une étape cruciale dans cette transformation, pour être réussie, les

ressources internes doivent être également accessibles en assurant leur sécurité et

leur confidentialité. De même, l’intégration entre les systèmes legacy ou on premises

et les systèmes Cloud requière une architecture moderne et robuste (par exemple, la

SOA) ainsi qu’un environnement SI maîtrisé. Cette capacité à ouvrir le SI et à le

rendre adaptable face aux nouvelles technologies est une des bases qui supportera

sa migration ou sa transformation Cloud.

Concernant les employés liés à ces projets, il y a une double opportunité : d’une part

éviter de maintenir des systèmes qui requièrent des compétences qui sont de plus

en plus rares et dégager des ressources expérimentées pour participer à de

nouveaux projets. Bien sûr, la question de la pertinence des connaissances

techniques et fonctionnelles de ces derniers devra être posée, mais la connaissance

de l’environnement SI et des problématiques métiers liées, qui découle de leur

expérience au sein de l’entreprise est un atout indéniable. Il y a donc un effort de

formation, pour permettre aux équipes en place de monter en compétence sur les

nouvelles technologies, méthodes, et architectures.

Pour résumer, il est évident que les efforts pour transformer son SI commencent

d'abord par des efforts pour le consolider et le préparer à une ouverture. Cela passe

par une compréhension poussée de son existant (technique, humain, métier) et des

étapes nécessaires pour le faire évoluer, en prenant en compte les compétences

indispensables à chaque étape et comment les faire évoluer pour les rendre

pertinentes dans le SI cible.



ii. Tout le monde avance ensemble, vers un but/une stratégie

commun(e)

La DSI doit supporter l’entreprise, ses métiers et sa stratégie. De même, nous avons

vu qu’il existe un besoin fort de rapprochement entre DSI et directions métiers.

Si l’on se réfère au modèle de l’alignement stratégique d’Henderson et Venkatrama,

on peut distinguer quatre modes d’alignement stratégique entre DSI et entreprise :

Image 17 - Modèle de l’alignement stratégique, d’après Henderson et Venkatraman (1993)

1 : Exécution opérationnelle de la stratégie

Image 18 - Exécution opérationnelle de la stratégie Henderson et Venkatraman (1993)

C’est le mode traditionnel, ici la DSI s’adapte à la stratégie de l’entreprise. Elle ne

fait que répondre aux besoins des métiers avec des priorités en termes de rapidité,

de disponibilité, de délai et de coût. La valeur ajoutée stratégique apportée par la

DSI est faible. Ce modèle s’applique aux entreprises matures où l’impact de la

technologie est faible ou modéré.



2 - les SI, vecteurs de la transformation technologique

Image 19 - Les SI, vecteurs de la transformation technologique Henderson et Venkatraman (1993)

Ici, la DSI va être amenée à concrétiser la stratégie définie par l’entreprise. Elle va

devoir fournir l’innovation technologique nécessaire au soutien des objectifs et va

devoir définir un plan de transformation (ou schéma directeur) pour y parvenir. Ce

dernier va se traduire par une évolution possible des métiers et processus de

l’entreprise en fonction des opportunités technologiques.

3 - les SI à l’origine de la stratégie et source d’avantage concurrentiel

Image 20 - les SI à l’origine de la stratégie et source d’avantage concurrentiel Henderson et Venkatraman (1993)

Dans ce cas, la DSI est à l’origine de la stratégie globale de l’entreprise : ce modèle

est donc principalement pertinent dans les secteurs dominés par des impératifs

technologiques (Internet, télécommunications, automobile etc.). Ici, le rôle de la DSI

est d’identifier et mettre en place des technologies innovantes dans le but de fournir

un avantage concurrentiel à l’entreprise.



4 - les SI, prestataires de services opérationnels

Image 21 - les SI prestataires de services opérationnels Henderson et Venkatraman (1993)

Dans ce modèle également, la DSI est à l’origine de sa stratégie (pas celle de

l’entreprise) impactant alors directement les processus et les infrastructures de

l’entreprise dans le but de fournir un service toujours plus performant et qualitatif. Ce

modèle est généralement pertinent pour les entreprises en forte croissance où le

besoin en support est toujours très fort et en constante évolution.

Au final on observe que dans le contexte actuel, les enjeux métiers et IT se

confondent, la technologie est au service des usages et ces derniers découlent

parfois d’opportunités technologiques. C’est pourquoi un cinquième modèle peut être

mis en avant, la mise en place d’une stratégie globale ayant un impact direct sur les

processus transverses de l’entreprise :

Image 22 - Stratégie globale SI / Métiers



Ainsi, tout en gardant les objectifs métiers en tête, la DSI dépasse son rôle de

fournisseur de services pour devenir moteur de l’innovation et impacter directement

la stratégie métier.

C’est pour cela que les approches stratégiques SI pures sont à remettre en cause

car elles ne peuvent pas répondre à ces exigences nouvelles. Par exemple, pour la

sécurité, l’approche traditionnelle consiste à mettre en place des contrôles

centralisés pour faire en sorte que le SI soit le plus sécurisé qu’il soit, avec comme

effet de bord de frustrer les utilisateurs qui contournent alors les contrôles et mettent

l'entreprise en danger. C’est d’ailleurs ces mauvaises pratiques organisationnelles

qui représentent le risque le plus fort en termes de sécurité dans la plupart des

entreprises. C’est pourquoi dans un contexte Cloud, où les systèmes sont encore

plus ouverts et intègrent de plus en plus d’acteurs, il est indispensable de penser la

sécurité pas seulement en termes de restriction (SI) mais aussi d’usages, pour

instaurer des processus pertinents qui permettront aux utilisateurs une utilisation

optimale du SI, sans risque de le mettre en danger. Ici, le rôle de gestion du

changement sera primordial pour instaurer de la confiance envers le fournisseur

(contrats, certifications, audit, retours opérationnels) et envers les utilisateurs

(formations, bonnes pratiques, écoute, accompagnement).

Image 23 - Sécurité et confiance dans le Cloud : deux aspects complémentaires

Pour parvenir à atteindre des objectifs de performance et d’excellence

opérationnelle, il est donc impératif que DSI et directions métiers travaillent de

concert dans un contexte où la communication et l’alignement des objectifs est clé.

Ce dernier ne peut se faire qu’avec un soutien global de la Direction Générale (DG),

de la Direction Administrative et Financière (DAF), de la Direction des Systèmes

d’Information (DSI) et des Directions métiers.



iii. Le soutien ne peut qu’être que global (DAF, DG, DSI, DM) et passe

par une évolution des mentalités

En regardant une entreprise, on peut naturellement supposer que les différentes

fonctions de cette dernière travaillent ensemble à la réalisation d’un objectif commun

partagé : la performance de l’entreprise. C’est le cas, mais cet objectif commun est

souvent éclipsé par des objectifs de performance propre à un département - non pas

dans un but égoïste mais, car pour un objectif donné, les enjeux et les stratégies

pour l’atteindre varient selon les branches et les métiers de chaque fonction de

l’entreprise. Un exemple simple : une direction marketing souhaite obtenir un logiciel

d’envoi d’email. L’objectif de la DSI sera de proposer et fournir cette solution. Cet

objectif est partagé par la direction marketing. Toutefois, lorsque la direction

marketing aura des impératifs forts en termes de délais et de fonctionnalités, la DSI

aura quant à elle, entre autres, des impératifs en termes de sécurité et d’intégration.

Bien sûr, cette situation est exacerbée lorsque l'on multiplie le nombre d’acteurs

nécessaires à la mise en place d’une application : la DAF aura une vision très

orientées coûts (TCO) de la solution, le juridique s’assurera que le fournisseur de

services est contractuellement viable etc. Et tous ces impératifs sont pertinents et

même nécessaires pour faire en sorte qu’un projet soit durable au final. Cependant,

ce phénomène peut vite se transformer en guerre de clochers sclérosant la faculté à

progresser d’une entreprise.

En plus de pousser des objectifs communs, chaque direction métier, chaque

direction de fonction support, et la direction générale doivent travailler ensemble

pour être certains que les impératifs individuels ne prennent pas le pas sur l’objectif

commun. Cela passe, bien sûr, par une communication claire mais également par

une gouvernance adaptée. Cette gouvernance devra favoriser l’innovation en

acceptant le risque et l'échec : si l'échec n’est pas accepté comme une possibilité,

les impératifs individuels des départements ne pourront pas être dépassés -

craignant sans cesse la sentence en termes d’évaluation individuelle. Au final, sans

risque, sans incertitude, pas d’innovation, pas de progrès, pas de performance. De

même il faut être capable de remettre en cause certaines règles internes, ce qui

passe par une certaine impertinence vis-à-vis des moyens en place. Comme le dit

Julien Lévy, professeur à HEC, « il faut accepter une certaine dose d’illégalité par

rapport aux règles internes : on innove aussi en faisant bouger le cadre. ». Bien sûr,

cela doit se faire dans une dynamique de progrès et de partage pour ne pas attiser

des tensions en interne. Par exemple : la DAF doit être capable de revoir les

principes de contrôles budgétaires (en suivant des tendances telles que le « Beyond

Budgeting »), pour éviter qu’ils ne deviennent un frein au besoin d’adaptation

permanent des projets, ou encore d'accepter des ROI incertains pour financer des

innovations à la manière des modèles du capital-risque.

Pour être complète et efficace, cette gouvernance doit également mettre en place un

cadre nouveau, propice à l’innovation et au changement, qui s’affranchit des règles



classiques. Cette nouvelle organisation repose donc sur quatre piliers à faire évoluer

:

1. L’information et la connaissance

2. Les acteurs

3. Les technologies

4. Le management

Avant tout, comprenons les origines des organisations des entreprises en partant de

l’organisation 1.0. Elle s’est imposée comme référence pendant longtemps pour

répondre aux besoins des entreprises. Avec elle, l’information descendante est le

modèle dominant de relation entre décisionnaires et exécutants.

Ensuite, la montée en puissance des moyens de communication a permis à

l’organisation 2.0 d'émerger : l’organisation collective où la participation de chacun

est possible dans le but de favoriser motivation, implication et performance. Ici,

l’utilisateur n’est plus seulement consommateur mais aussi générateur d’information

et de connaissance et donc également créateur de valeur.

Enfin l’organisation 3.0 voit passer le cap du collectif pour atteindre celui de la

collaboration en s’appuyant sur les agents (acteurs non seulement humains mais

aussi non-humains), les technologies (maintenant avec un SI ouvert capable de

traiter des sources multiples et continues de données), et les processus (adaptables

et adaptés au changements et à l’innovation). Cette organisation orientée données

tire profit de toutes les ressources de l'entreprise (humain, non humain,

technologique, métier etc.) pour générer de la valeur et en se basant sur les

données.

Image 24 - Passage de l’organisation 1.0 à l’organisation 3.0, Imed Boughzala, HBR, 2015

Encore une fois, le succès de ces organisation innovantes reposent aussi sur la

capacité à rendre les acteurs suffisamment autonomes grâce à une gouvernance en

partie décentralisée qui permet de prendre des décisions directement au niveau des

équipes, et assouplie les règles. Cela permet aussi d’avoir des cycles de décisions

plus rapides qui ne sont pas tributaires des comités mensuels ou bimensuels,

fonctionnant sur un rythme différent de celui du projet.



3. Comment faire du SI un avantage concurrentiel

pour les entreprises : des outils, des méthodes, et… des

gens ?

Le Cloud est sans aucun doute une opportunité pour les directions informatiques de

se réinventer, de prendre un rôle stratégique au sein des entreprises pour, en

harmonie avec les directions métiers, mieux travailler afin d’obtenir une performance

supérieure. Comme nous l’avons vu, cela passe par une évolution du rôle des DSI

mais aussi une nouvelle organisation en général. Cependant est-ce les seuls

paramètres à prendre en compte ?

De plus, si le marché du Cloud semble décoller en Europe et dans le monde, il

semble que certains pays, tels la France, soient à la traîne : en comparaison avec

les autres pays européens, la France se situe dans la « moyenne basse » : mi-2014,

12% des entreprises françaises déclaraient faire usage du Cloud Computing, contre

une moyenne de 19% des entreprises en Europe et jusqu’à 51% en Finlande par

exemple. Ces chiffres proviennent d'une étude d'Eurostat (11/2014 - 151.000

entreprises interrogées dans 28 pays de l'U.E.).

Quelles sont les raisons de ces retards ?

Image 25 - Les freins à l'adoption du Cloud en France - source : PAC (2014)

Selon le PAC, la sécurité est toujours l’argument mis en avant par les

“néphophobes” (néologisme désignant les personnes ayant peur du Cloud, selon

Louis Nauges).



Mais si l’on regarde ce qui se cache derrière cet argument, plus que la sécurité, c’est

bien la confiance qui fait défaut.

Comment réagir face à ce manque de confiance qui place les entreprises Françaises

dans une position délicate ?



a. La gestion des compétences

La confiance est en lien avec la gestion des compétences au sens large. En effet,

sans être capable de comprendre les enjeux (techniques ou métiers) du Cloud, on

ne peut que craindre sa mise en application ou considérer à priori, qu’il n’est pas une

solution viable pour l’entreprise.

i. Pourtant, en France, ça ne décolle pas, pourquoi ?

Une vision dégradée de la compétence technique

Il est d’abord important de mettre en lumière une chose, il existe en France une

appétence faible des dirigeants pour la technologie. Un des exemples est la place

des développeurs : selon l’étude prospective du secteur professionnel du Numérique

du Syntec (2013), les développeurs sont souvent jeunes avec une expérience

limitée, car en France, afin de passer un cap dans la hiérarchie de l’entreprise, ils se

doivent de passer “manager”. Aux Etats Unis, par exemple, toujours selon le même

rapport, il n’est pas rare de voir des développeurs seniors reconnus et valorisés pour

leur expertise, et considérés comme des atouts stratégiques pour les entreprises.

Cela résulte d'un manque d’expertises, ralentissant la performance de l’entreprise et

l’innovation. En effet, ne pas s’entourer de personnes ayant cette capacité à

identifier les leviers d’amélioration que peut apporter une nouvelle technologie est un

risque stratégique pour l’entreprise ; la direction générale ne sera pas en mesure de

comprendre l’ampleur du potentiel gain que la technologie peut apporter et surtout,

elle n’aura pas les compétences nécessaires en interne pour en tirer profit et la

mettre en place.

Manque d’expertise ?

Le Cloud, le digital, le Big Data, la mobilité, etc., toutes ces tendances qui

révolutionnent la manière de percevoir et de faire l’informatique s'appuient, certes

sur des usages métiers qu’ils supportent et aident à faire évoluer mais aussi sur des

compétences techniques. Ces compétences techniques sont relativement nouvelles

et les ressources disponibles et formées sur le marché sont rares. Elles le sont

d’autant plus lorsque l’aspect métier est une composante importante des

compétences requises.

L’exemple d’un data analyst est assez probant : il doit avoir une compétence

technique pour utiliser les outils Big Data, mathématique pour comprendre et

modéliser les modèles informatiques, et surtout métier afin d’être capable de

construire avec eux les cas d’usage pertinents qui rendront le projet viable. Robert

Mahowald, analyste chez IDC, affirme en s'appuyant sur une étude de son cabinet,

qu’il existe en moyenne un écart de compétence de 50% entre là où se trouvent les

employés IT aujourd’hui, en 2015, et où les entreprises souhaitent qu’ils se trouvent

dans 2 ans.



Ainsi, une entreprise ne possédant pas les ressources nécessaires pour comprendre

les technologies, identifier leur potentiel, les mettre en place et les opérer, auront

une tendance naturelle à la méfiance.

4. Peur du changement ?

La confiance est décisive dans la capacité d’une entreprise à adopter des solutions

Cloud. Selon une étude Aruba, 54% des cadres ne feraient pas confiance au Cloud.

Nous avons vu que cela pouvait en grande partie provenir, d’un manque de maîtrise

technologique. Ce manque de maîtrise peut se retrouver dans les principes mêmes

du Cloud : externaliser des données, des applications, sous-traiter des processus,

etc. C’est perdre un peu de contrôle sur son IT.

La situation a toutefois évolué depuis quelques années : dans le passé, de

nombreux responsables informatiques voulaient essayer le Cloud avec des

applications ou des services spécifiques. Dans le même temps, les PDG, qui n’ont

peut-être parfois pas suffisamment étés sensibiliser au sujet par leurs DSI, ont hésité

à sauter le pas, essentiellement préoccupés par les questions de sécurité,

d'accessibilité et de fiabilité. Maintenant, de nombreux dirigeants d'entreprises ont

surmonté ces inquiétudes, mais les travailleurs en IT ont développé leurs propres

préoccupations au sujet de l'évolution de leurs compétences et de leur emploi. Une

grande partie de l'hésitation est en effet liée à des raisons de politique interne. La

question n’est pas de savoir si la technologie fonctionne ou si elle sera bénéfique

pour la société : mais plutôt de savoir si les employés garderont leur place ou non

dans ce nouveau contexte.

L’ancien DSI adjoint du Centre Pompidou, Trieu Huynh Thien déclare, « la mise en

place d’un projet Cloud ne va pas sans inquiétudes, à des degrés divers, pour

différentes populations de l’entreprise ». En effet, si le Cloud c’est l’externalisation,

les métiers en charge des services et applications désormais externalisés doivent se

repenser. Bien sûr, certains postes sont créés (supervision des services,

orchestration etc.) mais logiquement ils sont moins nombreux qu’avant et les

salariés peuvent craindre pour leur emploi. Face à cela des solutions existent, nous

y reviendrons, mais cette peur n’encourage pas les entreprises, tant au niveau des

salariés, qu’au niveau des dirigeants qui peuvent appréhender la gestion des

formations, des départs et a une autre échelle les mouvements sociaux.

Il en est de même d’un point de vue opérationnel, le Cloud accélère les cycles de

développement et force les employés à travailler dans de nouvelles conditions, avec

de nouvelles contraintes et de nouvelles méthodes. Ces équipes devront se refondre

avec des compétences différentes : développement, recette, opération, métiers bien

sûr, mais aussi juridique, ou légale par exemple.



Il est donc évident, et compréhensible qu’une peur globale du changement soit

observable lorsqu’on parle transformation Cloud, cette peur poussant à ne pas

l’accepter, à réduire l’ampleur de cette évolution, ou même à nier une réelle

innovation. Comme disait Nietzche « “Aussitôt qu'on nous montre quelque chose

d'ancien dans une innovation, nous sommes apaisés ». Cela peut être également

amplifié par la vision culturelle de l'échec en France, comme évoqué auparavant.

Selon Aladwani (2001), la résistance au changement dans les projets IT en général

a pour origine le “Risque perçu et l'habitude”. Le risque perçu réfère à la perception

du risque inhérent à la décision d'adopter l'innovation. Les habitudes sont tous les

usages et techniques actuelles que les gens effectuent régulièrement. Afin d'être en

mesure de réduire la résistance au changement, il est important d’analyser sa cause

pour ensuite y répondre. Avec le Cloud, la modification est multiple (technologies,

organisations, méthodes) et met les entreprises dans une situation où elles doivent

impliquer les employés à tous les niveaux pour faire comprendre l’opportunité que

représente le Cloud, non seulement pour l’entreprise, mais particulièrement pour eux

(nouveaux challenges, formations, évolution etc.).

i. Comment faire en sorte de transformer ces réticences, pour

embrasser le changement en le rendant durable et profitable :

Afin de faciliter la transition et de faire accepter le changement, deux éléments

principaux peuvent être mis en avant : l’implication et la communication. Derrière ces

deux principes réside un même objectif : inclure l'utilisateur final dans le projet de

transformation et donc de lui faire comprendre l'intérêt derrière ce changement.

Communication et implication

La stratégie de sensibilisation (Awareness Strategy) consiste à partager les détails

des projets de transformation avec les acteurs impactés. Par exemple, en donnant

aux individus des détails techniques et opérationnels précis, ou en leur faisant

comprendre le but et la portée du projet de transformation. Ensuite, la stratégie

basée sur le ressenti (Feeling Strategy) vise à convaincre les utilisateurs de la

profitabilité du changement. Par conséquent, les utilisateurs veulent s’impliquer dans

le projet car ils le comprennent et croient en l’apport qui en résultera. Cette phase

inclus bien sûr, des formations et du support mais aussi une communication forte qui

aura pour but de rendre le changement désirable. Enfin, la stratégie d'adoption

(Adoption strategy) est la participation à la mise en œuvre d'une stratégie globale

soutenue par la direction. Ainsi elle légitime d’autant plus le projet et facilite

l’implication des employés ou des utilisateurs.



Image 26 - Change Management Framework - Aladwani (2001)

Ce Framework peut être mis en perspective avec la théorie unifiée de l'acceptation

et de l'utilisation de la technologie (UTAUT Unified Theory of Acceptance and Use of

Technology) qui donne une autre lecture de l'acceptation par les employés. Les

attentes en termes d'effort et de performance sont également gérées par la

communication et l’implication. La facilitation prend appui sur l’implication de la

direction et des sponsors à différents niveaux dans l’entreprise, et sur les formations,

relais de cette communication. La principale différence est l'impact de l'influence

sociale sur l'acceptation.

Image 27 - UTAUT - Venkatesh, (2003)

Travail de concert avec les Directions métiers

Avant d’aller plus loin, il faut qualifier la relation qui unie historiquement IT et métiers,

et précisément Directions métiers et DSI. Pour cela, il faut comprendre les différents

éléments en jeux dans ces types de relations. Selon les recherches de Leonard, on



peut déjà distinguer en 2003 la dimension physique et la dimension abstraite d’une

relation. La première est principalement ce qui doit être adressée lorsqu’on parle

d’alignement métiers / IT et inclue les personnes, la technologie et les processus.

Elle doit être structurée et clairement définie. La seconde dimension est bien plus

difficile à adresser et à mesurer. Elle concerne l’implication, la dynamique et la base

de connaissance des employés. Cette dimension est critique car elle va définir le

comportement des utilisateurs ou des employés et donc, la manière d’adresser la

gestion du changement. Ces deux parties doivent être prises en compte pour

comprendre les réactions, les attentes et les craintes des employés ou des

utilisateurs, et ainsi maximiser leur acceptation du Cloud ou de toute technologie

disruptive.

Une fois cela pris en compte, il est possible de définir le degré de maturité d’une

organisation quant à sa relation métiers / IT. Si les métiers sont fortement tributaires

du soutien informatique, à cause de connaissances techniques insuffisantes, leur

niveau de maturité sera « faible » En revanche, le niveau de maturité est « élevé »

lorsqu'ils sont très indépendants du support informatique. Il est important de préciser

qu'il n'y a pas de bon ou de mauvais niveau de maturité. Cela dépend de la position

de l'employé / utilisateurs finaux par rapport à l’IT et du contexte de l’entreprise.

Cette évaluation permettra aux acteurs de la transformation d'adapter le type, la

fréquence et la nature des contacts entre IT et métiers. Encore une fois le type de

relation est divisé en trois parties de “forte” (hard) à “douce” (soft). En fonction du

type de relation, la fréquence élevée des contacts sera élevée ou non.

Image 28 - Type de relation et niveau de maturité

Être en mesure d'évaluer et de comprendre ces deux critères (niveau de maturité et

de type de relation) est obligatoire pour gérer l’implication des employés pendant un

projet de transformation et même ensuite. Si la relation est trop dure ou trop douce

concernant le niveau de maturité, les employés se sentent perdus et abandonnés.

Dans le cas contraire, ils se sentent trop opprimés et forcés à changer. Dans les

deux cas, une relation inadaptée est susceptible de conduire à un échec.



Il est toutefois important de souligner que ce modèle est en partie remis en cause

par le Cloud où dans tous les cas, le niveau de communication IT/métiers se devra

d’être fort. La nature du support quant à lui dépend bien du contexte, de la maturité,

et de la relation. Comment alors maximiser la relation entre IT et métiers ?

Dans l'étude “Achieving and Sustaining Business-IT Alignment”, Luftman et Brier

définissent une liste de facilitateurs pour l'alignement IT/métiers. Même si la relation

entre l’informatique et les métiers est la clé, elle implique aussi l'appui de l'ensemble

de la hiérarchie, des priorités claires et un leadership efficace.

Le premier point vise à fournir à tous les individus du projet un accès partagé à

l'information. Il est obligatoire d'assurer son évolution cohérente. Chaque partie

prenante doit être en mesure d'aborder les étapes du projet de transformation avec

la même base d'information. Par exemple, les employés “IT” doivent être conscients

des enjeux métier. Cela facilite la communication entre les équipes et évite les

doublons, voir le Shadow IT. D’un point de vue général, la communication est une

des clés de la réussite d’une transformation ou d’une adoption Cloud : elle permet

aux acteurs de comprendre les enjeux et les objectifs de chaque département de

l’entreprise, même si, comme évoqué précédemment, ils sont en partie différents

des leurs. Ainsi, il est du rôle du responsable de la transformation Cloud d’avoir une

réelle double compétence pour appréhender pleinement les enjeux techniques et

métiers afin de sensibiliser ses équipes dans ce sens. Cette vision était déjà

théorisée par Bouraad en 2008 et était alors considérée comme un des facteurs clés

de succès d’un projet IT.

Cela fait déjà quelques temps que les DSI parlent de l’alignement de l’IT et des

métiers. Cependant avec le Cloud, cela se concrétise : les employés "IT" ont

désormais plus de temps pour se concentrer sur des projets à forte valeur ajoutée et

sont maintenant capable de construire, tester et opérer leurs applications beaucoup

plus rapidement car ils s’affranchissent, entre autres, des limites physiques de

l’architecture traditionnelle. Cela signifie que l’IT est en mesure de répondre, voire de

proposer au métier des projets, avec une rapidité jamais atteinte. Cela signifie

également que la DSI doit se concentrer encore plus sur les enjeux métiers que les

enjeux IT historiques et se transformer donc en fournisseur de services. Elle va donc

plus loin que l’alignement IT/métier et la suppression des silos : selon John Trujillo,

DSI de Pacific Life Insurance "La DSI, doit être une partie de l’entreprise autant que

les métiers.". C’est, par exemple, le but de L’Oréal avec son parcours initiatique

(chaque collaborateur rencontre un maximum de personnes de différentes unités,

pour se créer un réseau et comprendre le fonctionnement de chaque branche) ou sa

promotion forte de la mobilité interne aussi nommée “cross fertilization”. L’objectif est

clair : créer des synergies internes pour obtenir de meilleures relations, une

meilleure compréhension, une motivation accrue et donc une plus grande

performance générale des équipes.



Formation maîtrise des compétences

Communication et implications sont les clés pour faciliter l’acception d’un

changement fort. On a également vu l’importance des formations et, d’une manière

plus générale, de la peur et du risque générés par le manque de compétences.

Dans un premier temps, il faut adresser le déficit de compétences. Cela passe par

des formations internes, de l’embauche (de plus en plus de formations adressent

naturellement les besoins d’un marché en développement) et également l’appel à

des prestataires externes qui peuvent de manière temporaire combler le déficit de

connaissance de manière quasi-immédiate.

Toutefois, il est important de comprendre avant tout quelles compétences sont

nécessaires pour assurer le succès d’une transformation Cloud. Cela passe

évidemment par un état des lieux des compétences internes disponibles, à mettre en

parallèle avec la stratégie Cloud (SI et digitale) définie, pour identifier quels sont les

manques pour ensuite les combler. Des emplois pourront donc évoluer, des

fonctions seront requalifiées, et d’autres devront être supprimées.

Maîtrise du risque

Le Cloud, principalement à cause de l’externalisation, représente une modification du risque opérationnel. La maitrise du risque ne se joue plus seulement dans la gestion des opérations mais surtout dans la gestion du niveau de service assuré par le fournisseur de services. Ainsi, il faut comprendre les enjeux liés à ce mode de consommation informatique : gestion de la chaîne de fournisseurs, gestion des contrats, compréhension du contexte légal, mais aussi intégration, réversibilité ou maîtrise de la localisation des données etc. Face à cela, la DSI doit s’organiser et faire appel à de nouvelles compétences, qui ne font pas systématiquement partie de son cœur de métier traditionnel.

Rôle du CDO

Globalement, la gestion du changement implique beaucoup d’étapes essentielles qui

doivent être abordées avec une bonne compréhension du contexte et des

personnes. Toutefois, si ce processus peut être conceptualisé, pourquoi tant de

projets échouent avant même d’avoir démarrés ?

Chaque étape d'un projet de transformation peut être conceptualisée et les

meilleures pratiques peuvent être définies. Cependant, il y a très peu de méthodes

qui tendent à aborder ces projets avec un point de vue global. La partie manquante

est souvent le lien entre chaque morceau, ce qui lie chaque partie d'un projet de

transformation à l’ensemble. Historiquement, c'est le rôle de la gouvernance, et des

directions (DSI pour les projets SI, Directions métiers pour les projets métiers). Elles

sont en charge de la cohérence du projet. Cependant, comme développé dans les

parties précédentes, la cohérence et donc le succès des projets IT, repose sur

l’implication des acteurs, des employés ou des utilisateurs. Cette implication dépend



de la volonté des acteurs à faire partie du projet et du changement en lui-même. Ce

comportement est difficile à mesurer et à contrôler, car il dépend surtout de la

personnalité de l’acteur et de sa relation envers son travail. L'influence d’un leader

sur des employés a été démontrée dans plusieurs études (J. Neufeld, D., Dong, L.,

& Higgins, C. - 2007). Cette influence a un impact direct sur les facteurs impliqués

dans la UTAUT : influence sociale, attentes en termes de performance, d’effort, etc.

En effet, leader dit charismatique, a la capacité de lier la participation individuelle

des utilisateurs au niveau de l'engagement du groupe. Il réussit à aider les individus

à aller au-delà de leur intérêt personnel et d'embrasser l'opinion des autres et du

groupe. Ramené à la transformation Cloud, il a la capacité à rapprocher la vision des

DSI et directions métiers, pour supporter la stratégie globale de l’entreprise. Par

conséquent, ils deviennent une partie de l’identité collective de l'organisation et cela

aura un impact positif sur les efforts attendus (effort expectancy). Comme ils

comprennent le but du projet, les enjeux généraux en plus de leurs enjeux

personnels, ils sont disposés à le soutenir. De même, l'influence sociale est

impactée car les leaders charismatiques ont tendance à stimuler les ressources et à

éliminer les obstacles pour atteindre l’objectif commun.

Leur influence apporte un niveau d’investissement supérieur et améliore les

performances des personnes. Enfin, il a un rôle majeur dans la motivation des

employés à embrasser le changement et la transformation

Globalement, le leader charismatique a une influence globale sur chaque partie de

l'acceptation par les utilisateurs. Elle est résumée dans le graphique ci-dessus.

Image 29 - Leaders charismatiques et comportement des utilisateurs - Derrick J Neufeld , Linying Dong & Chris

Higgins (2007)

Mais comment pouvons-nous définir un tel leader ? Le charisme n’est pas seulement

un ensemble de compétences ou de caractéristiques individuelles. Ce n’est pas non

plus un élément subjectif en lien avec la vision que les autres personnes ont du

leader. Le charisme réside dans la relation que le leader parvient à créer entre les

individus. Cela signifie que les leaders charismatiques sont définis à la fois par le



leader lui-même et par ses “suiveurs”. Voilà la raison pour laquelle cette relation est

si particulière et puissante. Ce lien tend à créer un engagement des suiveurs à la

vision portée par le leader.

Maintenant, qui du DSI et des Métiers a la meilleure position pour endosser ce rôle

de leader de la transformation digitale ?

En plus de ce rôle de leader, maîtrisant à la fois les problématiques techniques

ancienne et nouvelles, et les problématiques métier pour impliquer les employés à

tous les niveaux de l’entreprise, celui en charge de la transformation Cloud devra

être capable de jouer un rôle d’influenceur au sein de l’entreprise - en évangélisant

le Cloud et le digital auprès des directions métiers et informatiques. Plus que la

transformation numérique ou “digitale”, il doit être le moteur du changement et de la

transformation culturelle à chaque étage de l’entreprise et il doit bien sûr pour cela

être indépendant de la DSI traditionnelle, des directions métier et de la DAF, et être

membre du COMEX pour porter la vision du numérique de manière pragmatique

dans l’entreprise. Ainsi, un DSI traditionnel même avec un rôle déterminant, ou des

directions métiers, ne peuvent assumer cette position et un nouveau poste doit être

créé, qui correspond à “méta-DSI”, le CDO.

Toutefois, deux questions se posent : qui peut endosser ce nouveau rôle et quelle

est sa place dans l’organisation ? Est-ce simplement une strate de décision

supplémentaire ?

D’abord, nous avons expliqué que le DSI, dans son rôle traditionnel, ne pouvait pas

endosser la position de CDO. En plus des raisons évoquées précédemment, il

manque d’une position indépendante (il est parfois rattaché à la DAF) et d’un pouvoir

de décision suffisant au sein de l’entreprise.

Image 30 - Une des organisations traditionnelles d’une entreprise, en silos



Toutefois, la DSI a la capacité à comprendre les enjeux techniques et les enjeux

métiers. En effet, il travaille pour ces derniers et est traditionnellement habitué à

prendre en compte leurs besoins. De plus, avec ses compétences historiques, il

aura un rôle clé dans la maîtrise de l’existant, tant dans l’expertise technique, que

dans la compréhension des enjeux applicatifs transverses.

Ces capacités sont nécessaires pour réussir une transformation Cloud mais pas

suffisantes. Alors, faut-il rajouter une strate décisionnelle en charge des échanges

entre métiers et IT pour porter la transformation ?

Cela pose plusieurs problèmes. Il semble en effet difficile de faire endosser un rôle

où le lobbying interne, la connaissance et la compréhension des enjeux métiers et

techniques sont déterminants à une personne externe, donc étrangère, à l’entreprise

- même si cela aurait au moins l’avantage d’apporter une vision nouvelle, dénuée de

beaucoup de préjugés. De plus, le pouvoir donné au CDO servirait alors à créer une

relation artificielle entre IT et métiers, qui ne travailleraient pas ensemble

directement mais par l’intermédiaire d’un tiers. C’est bien sûr une solution potentielle

à court terme, mais ne sera pas viable dans la durée car elle serait très

consommatrice de temps et donc limitée en termes d'efficacité. Pour cela, une

solution possible est de compléter les responsabilités de la DSI et de les faire

évoluer pour endosser celle de DID (Direction Informatique et Digitale). De plus le

CDO aura un rôle transitoire de transformation, alors que celui de la DID sera plus

durable dans l’entreprise.

Image 31 - Possible organisation où les échanges entre DM et DID sont maximisés

De cette manière, la DSI profite de son expérience, tant dans son cœur de métier

traditionnel que le contexte de l’entreprise, pour faire évoluer ses manières de

travailler et prendre un rôle stratégique dans la relation avec les métiers. Le temps et

les ressources que le Cloud lui permettra d’économiser sont des leviers potentiels

pour former, mobiliser ou même embaucher de nouvelles personnes capables

d'endosser ce rôle.



Jusque-là nous pouvons conclure que la peur du changement est adressée par une

meilleure connaissance des techniques, une stratégie définie et partagée, et une

organisation adaptée, supportée par un leader transverse, indépendant, avec le

niveau de décision adapté. Toutefois, un dernier point doit être adressé pour obtenir

les outils nécessaires au succès d’un projet ou d’une transformation Cloud : les

méthodes.

b. Afin de construire un SI Agile

Économie rapide, besoin qui doit être traité immédiatement, réduction des coûts à

chaque étape, nouvelles techniques : il est évident les méthodes classiques de

gestion de projets ne sont plus adaptées dans un contexte Cloud pour l’entreprise.

D’ailleurs, le fait qu’elles soient inadaptées est un risque pour l’adoption et pour la

mise en œuvre d’une stratégie Cloud : des équipes performantes qui utilisent des

outils modernes n’obtiendront pas de résultat si les méthodes qu’elles appliquent ne

sont pas adaptées aux priorités du projet ou aux techniques utilisées.

i. Vie et mort des méthodes agiles

Ces méthodes nouvelles sont avant tout des réponses adaptées aux problématiques

actuelles : un besoin qui n’est pas toujours défini, une impossibilité partielle de

comprendre à priori le périmètre ou les risques de manière globale, la nécessite de

répondre rapidement aux besoins métier, et surtout d’avoir une solution adaptée

qu’ils s’approprient rapidement.

C’est la promesse des méthodes Agiles, telles que définies par le Agile Manisfesto

en 2001 et plus largement du “mouvement agile”. D’un point de vue général, le

principe de base de ces méthodes réside dans ces quatre points :

1. Identifier où l’on se trouve, comprendre sa situation initiale ;

2. Faire un petit pas vers le but recherché ;

3. Ajuster sa compréhension du besoin en se basant sur ce que l'on vient

d’apprendre ;

4. Répéter à nouveau.

L’objectif affiché est clair : s’adapter en continu. Bien sûr, comme on a pu le

souligner dans la partie précédente, “l'agilité” repose sur une transformation durable

des personnes dans l’organisation de l’entreprise. En effet elle est source de conflits

avec des méthodes de projet traditionnelles : un cahier des charges très détaillé, une

conception générale, une conception détaillée et enfin une réalisation où chaque

changement par rapport au à la conception est perçu comme un écart contractuel

qui crispe les relations.

Les méthodes agiles reposent quant à elles sur la capacité à accepter le

changement : pouvoir prendre en compte les changements dans le développement



d’un produit ou d’un service, les besoins ou les souhaits des utilisateurs,

l’environnement, le marché, la technologie, en somme tout ce qui peut être source

de changement.

Les valeurs associées et distinctives des méthodes agiles faces aux méthodes plus

traditionnelles (V, cascades) sont :

S’adapter au changement plutôt que de suivre un plan fixé ;

Faire passer les individus et leurs interactions avant les processus et les outils ;

Préférer un résultat fonctionnel qu’une documentation parfaite ;

Passer du temps sur la collaboration avec le client, plutôt que sur la

négociation contractuelle.

Cela apporte généralement des livrables correspondants aux besoins des

utilisateurs, des délais respectés, un engagement plus fort de l’équipe et

globalement une capacité d’adaptation supérieure. Toutefois, de nouvelles difficultés

sont communes à ces nouvelles méthodes : l’estimation du projet à priori, la gestion

des efforts hors des sprints, le transfert de connaissance à une autre équipe et le

niveau de la documentation.

Face à cela, la solution des entreprises est de mettre en place des solutions mixtes

qui adaptent leurs méthodes en fonction de la typologie et des priorités de chaque

projet, pour choisir entre une méthode traditionnelle ou une méthode agile.

Toutefois, les méthodes agiles sont-elles systématiquement la bonne solution pour

des projets Cloud ?

On a évoqué que la méthode agile reposait sur la capacité à accepter le

changement. Toutefois, la plupart des utilisateurs de ces méthodes ne peuvent pas y

parvenir. La raison est simple : la première fois que l’on apprend une nouvelle

technique ou une nouvelle méthode, nous n’avons pas d'expérience, de modèles

mentaux, ou la capacité d’abstraction sur ce que l’on est en train de découvrir. Ces

éléments sont seulement présents une fois la pratique et l’expérience acquises. De

plus, être capable d’accepter l’incertitude et le doute est une chose très compliquée

à gérer. Cela correspond à un biais cognitif qui nous force en tant qu’Homme, à

souvent choisir de faire le mauvais choix, plutôt que d’accepter d’être dans une

situation instable, potentiellement durable, qui représente le temps nécessaire pour

faire le bon choix. Par exemple, dans le cas d’un projet, il faudrait repousser des

décisions importantes à la fin du projet pour être sûr d’avoir toutes les cartes en

mains pour les prendre de manière optimale.

Un autre aspect qui pose problème est l’expérience. Dans the death of agile

(conférence donnée par D. Thomas, au Rethink 2014 à Dallas, Texas), Dave

Thomas, un des auteurs originaux de l’Agile manifesto, considère cette dernière

comme la difficulté la plus dure à surmonter. En effet, dans une méthode basée sur



le pragmatisme, et l’apprentissage progressif (inverse du dogmatisme basé sur

l’expérience passée accumulée), utiliser son expérience revient à biaiser le

processus qui fait la richesse de la méthode. Toutefois, il est impossible de ne pas

en tenir compte. Ainsi plutôt que d’avancer, de voir où on en est, et d'apprendre de

ce que l’on vient de faire, l’envie naturelle est de se projeter dans un schéma qu’on

semble maîtriser et remettre en œuvre les mêmes méthodes pour y arriver. Cela

peut fonctionner bien sûr, mais compte tenu de la grande spécificité et du contexte

quasi unique de chaque projet, c’est un grand risque - très difficile à éviter.

ii. Quelles solutions complémentaires ?

Le but de l’agilité est de fournir des méthodes nécessaires pour délivrer des projets

IT répondant aux besoins des métiers. Elles sont adaptées au Cloud et

complémentaires avec ses technologies. Méthodes ou techniques, le but est de

fournir une solution pertinente, rapidement, avec un coût et des risques maîtrisés.

On peut pour cela préparer la DSI, non pas avec des schémas prédéfinis, qui ne

seraient pas adaptables, mais avec des étapes à passer systématiquement,

permettant de maîtriser les risques et d’améliorer la capacité de la DSI à fournir des

solutions adaptées.

Image 32 - Des étapes pour réussir un projet de transformation Cloud

1. Maîtrise des données pour être capable d’avoir une cartographie des

données impliquées dans le projet à venir, pour savoir rapidement comment

les intégrer et comprendre les enjeux liés à chaque type de données.

2. Analyse du TCO avec une mise en évidence rapide de tous les coûts

associés aux solutions Cloud (réversibilité, licence, intégration etc.).

3. Maîtrise du cadre légal et contractuel afin de prendre en compte les SLA,

la notion de réversibilité, de dédommagements en cas de non-respect des

engagements, mais aussi de localisation des données et de législation.



4. L’intégration, garante du bon fonctionnement de l’application au sein d’un

environnement SI déjà existant. Cette intégration est autant technique que

fonctionnelle.

5. L’impact sur les organisations et la gestion du changement, par une

maîtrise du contexte et de la communication.

De plus, la DSI et les métiers doivent pouvoir juger ensemble de la pertinence

fonctionnelle de leurs projets afin de se concentrer uniquement sur des projets où la

valeur ajoutée est démontrée et qui s'intègrent à la stratégie globale de l’entreprise.

Pour cela, des critères de pertinences (apports fonctionnel, implication des acteurs,

coûts, pérennité etc.) doivent être définis. En effet, si les coûts et bien sûr les

usages, sont respectivement réduits et propulsés par le Cloud, il y a un facteur qui

reste primordial et qui ne peut être rattrapé : le temps. Mobiliser des équipes sur des

projets qui ne sont pas fonctionnellement pertinents, représentera une perte sèche

de temps qui ne peut être compensée alors que les besoins peuvent être adressés

par un autre projet ou le ROI rattrapé par une initiative future. C’est pour cela que la

capacité à juger rapidement de la pertinence fonctionnelle d’un projet est

indispensable dans le contexte d’une DSI, ou DID, qui doit répondre à de plus en

plus de sollicitations pour des besoins métier, à travers des projets toujours plus

nombreux. Bien sûr, la DSI seule n’est pas en mesure de juger ces besoins, c’est

pour cela qu’elle doit être au contact des directions métiers dans chacun de ces

processus, de manière naturelle et intégrée.

Enfin, tous ces processus doivent être industrialisés. Comme pour le Cloud, la valeur

ajoutée des équipes informatiques ne doit pas être le travail sur des tâches

répétitives à faible valeur ajoutée. Par conséquent, tous les points de méthodes cités

précédemment se doivent d'être compris, intégrés et maîtrisés, de manière à ne pas

perdre de temps sur la méthode elle-même et uniquement l’appliquer pour qualifier,

classifier et réaliser les projets. Si ce n’est pas le cas, cela générera une lourdeur

incompatible avec les ambitions de projets Cloud.

Des méthodes encore plus agiles ?

De nouvelles méthodes voient le jour pour essayer de pallier ces limitations. Par

exemple, la méthode GROWS : GROWS est un acronyme pour “Growing Real-

World Oriented Working Systems” et vient d’une idée de Jared Richardson et Andy

Hunt. Elle est basée sur une idée simple : les solutions informatiques ne sont pas

“désignées et développées” car c’est un modèle trop déterministe et linéaire qui ne

fonctionne pas (un peu comme ce à quoi répondent les méthodes agiles). Au

contraire elles grandissent, “grow” en anglais. Cette métaphore semble adaptée car

avec la croissance, vient le changement. Cette croissance ne peut que se baser sur

des retours en conditions réelles pour être efficace. Tout ce qui ne vient pas du

monde réel et de vraies situations, relève souvent de modèles inexactes voire rêvés



et totalement inadaptés. Bien que le cœur de cette croissance soit la solution, tout

l’environnement doit être pris en compte : la solution bien sûr, mais aussi l’équipe,

les utilisateurs, les sponsors. Tous forment un système unique, qui doit fonctionner

efficacement pour tous les acteurs.

De fait cette méthode s’organise autour de quatre idées :

1. Des preuves concrètes

2. L’adaptation au contexte

3. La prise en compte du système complet du projet

4. Le modèle d'acquisition de compétences de Dreyfus

Le modèle d'acquisition de compétences de Dreyfus met en avant cinq stages au

travers desquels chacun passe à mesure qu’il gagne en expérience :

Le novice (Novice) : qui veut avoir un manuel, sans liberté, sans possibilité

de prendre une décision.

Le débutant confirmé (Advanced Beginner) : qui a besoin d’un peu de liberté

mais qui est incapable de discerner ce qui pertinent ou non.

Le compétent (Competent) : qui veut plus de liberté et qui fait la différence

entre ce qui est pertinent et ce qui ne l’est pas.

L’efficace (Proficient) : qui a une vue d’ensemble de son domaine de

compétence et qui délaisse peu à peu la théorie pour l’intuition. Pour lui, la

théorie cède la place peu à peu à l’intuition.

L’expert (Expert) : qui fait preuve d’intuition et écrit les manuels.

Image 33 - Modèle de Dreyfus - setandbma.wordpress.com, 2013

Ce modèle permet de savoir à quel stade se trouve chaque acteur du projet afin de

l’intégrer de manière efficace avec des tâches correspondant à ses compétences et

ses attentes.



Dans les entreprises, les attentes sont des résultats concrets et différents de ce qui

a été produit jusque-là. Dans le meilleur des cas pour un coût minime, sans avoir à

changer l’organisation ou la technique, en profondeur. Mais globalement, personne

n’aime qu’on les force ou même qu’on les amène à changer. Pour réussir, ils doivent

eux-mêmes vouloir changer. Cela signifie que l’équipe doit pouvoir leur présenter

des avantages très personnels et directs dans leur participation au projet. Des

notions abstraites telles qu’améliorer le “Time to market”, ne suffisent plus.

Dans la méthode GROWS le progrès est basé sur des expériences.

Les expériences s’effectuent dans une période de temps donnée, ce qui limite

l'engagement et le risque. Dans une expérience, il est clair pour toutes les

personnes impliquées, que ce n'est qu’une situation temporaire. Ce n’est donc pas

un « changement », mais simplement un « essai ».

Chaque expérience a comme objectif de faire un essai sur un sujet, dans un

contexte donné et avec des critères d'évaluation spécifiques. Tout le système

participe à l'expérimentation et à l'évaluation des résultats, ce qui permet d'avoir des

retours riches et de progresser.

La partie la plus difficile vient dans l'évaluation des retours ("feedbacks"). Au début,

les commentaires sont simples et univoques. Mais ensuite, à des stades de

compétences plus élevés, ce processus de retours devient plus intéressant mais

beaucoup plus difficile, car équivoque. Toutefois, à ce stade plus avancé du projet,

l’équipe et les autres participants ont construit un contexte de confiance et des

habitudes dans la recherche et l’analyse de ces retours, simplifiant le traitement de

problèmes complexes.

Le principe se veut encore plus agile que « l'agilité » : on essaye, un peu de ceci, un

peu de cela, on évalue les retours, on s'ajuste. On progresse ensemble, en tant que

système, pour traiter des problèmes de plus en plus complexes, de manière de plus

en plus efficace.

Bien que les méthodes agiles soient les plus répandues et éprouvées, il est donc

important de garder en tête qu’elles ne sont pas la solution unique et que d’autres

automatismes peuvent permettre de mieux répondre à un besoin Cloud.



Conclusion

En conclusion, nous pouvons affirmer de manière certaine que la révolution

technologique du Cloud n’en est pas une. C’est bien la somme de multiples

évolutions techniques, mais surtout le résultat d’une évolution de l’économie, du

comportement et de la société en général. Bien sûr, le contexte technologique se

devait d’être suffisamment mûr pour permettre à ce nouveau moyen, de fournir et de

consommer de l’informatique, d'émerger mais il correspond avant tout à une réponse

à des besoins utilisateurs maintenant décomplexés et prêts à nouveau à assumer

leurs attentes vis-à-vis de l’informatique. Associées à un marché où l’instantanéité et

la performance sont nécessaires à la survie de l’entreprise, ces attentes forcent

l’informatique professionnelle à se repenser comme le fait l’informatique personnelle.

Ainsi, si la maîtrise technique reste essentielle, elle doit s’inscrire dans une

démarche plus globale où les organisations, les personnes et les méthodes

évoluent. Dans une informatique tirée et poussée par les usages, les experts

techniques et les utilisateurs doivent parvenir à travailler ensemble pour la

performance de l’entreprise, en éliminant les tensions et les effets de silo. Pour ça, la

DSI doit se repenser afin de devenir un partenaire stratégique des Directions

métiers. Cela passe non seulement par une évolution des compétences, des

mentalités et de la structure des équipes, mais aussi par sa place dans l’entreprise :

elle dépasse son rôle d’expert technique, pour intégrer des expertises transverses,

telles que celles des métiers mais aussi celles liées aux nouveaux enjeux du Cloud.

Pour réussir, cette organisation doit avoir une gouvernance adaptée, qui insuffle une

stratégie commune et où cette nouvelle DSI, méta-DSI ou DID, plus pérenne que le

CDO, a, au même titre que les métiers, le pouvoir décisionnel suffisant. Également,

l’évolution des compétences et des comportements est une étape cruciale, qui

passe par la formation, la communication et surtout par un leader capable de fédérer

les équipes autour d’un but commun. Enfin, pour soutenir ces deux premiers points,

des méthodes adaptées devront être mises en place, qui elles-mêmes devront en

permanence se repenser pour rester pertinentes. Ces dernières ne sont pas des

dogmes figés mais des guides à faire évoluer et à adapter à chaque contexte

d’entreprise.

Il semble donc, au final, que le cloud s’éloigne bien de la définition du NIST dans la

réalité. Il est avant tout le reflet d’un changement dans les comportements et la

plupart des difficultés associées à son essor, ne sont pas techniques mais sociales.

Le principal enjeu étant la capacité de comprendre les objectifs de chaque acteur de

l’entreprise pour progresser plus vite et mieux.

“L'appréciation est une chose merveilleuse : elle fait de ce qui est excellent

en autrui, nous appartenir également” - Voltaire



Références

Articles et publications : “The history of virtualization”, article paru sur le site cloudtweaks.com, 2012 “Organiser sa DSI dans un environnement en mutation permanente”, article

de Aurélie Magniez, paru sur IT-Expertise.com, 2015 “SI historique et transformation digitale : mettez la continuité au service de la

rupture”, article de Jérôme Martin, paru sur JDN.net, 2015 “Marketing et DSI : comment mieux travailler ensemble ?”, article de Aurélie

Magniez, paru sur IT-Expertise.com, 2015 “Gérer les compétences dans une DSI”, article de Damien Alexandre, paru

sur IT-Expertise.com, 2015 “Business IT Integration Maturity Model:BITI Maturity”, par Leenards & Paul,

2001 “Focusing on maturity levels for the effective management of end-users

involved in software project teams” par A. Leonard, publié dans le South African Journal of Business Management, 2004

“Achieving and Sustaining Business-IT Alignment” publié dans le California Management Review, par J. Luftman et T. Brier, 1999

“Beyond the hype: Evaluating and Measuring Agile Development” par Dan Horvath, 2011

“Charismatic leadership and user acceptance of information technology” publié dans the European Journal of Information Systems, par Neufeld, Dong, & Higgins, 2007

“Leadership : (se) transformer pour mieux porter un projet commun”, par Cécile Desjardins, Les Echos, 2015

“Les entreprises françaises en retard sur le cloud”, par Sandrine Cassini, les Echos, 2015

“En France, les développeurs sont condamnés à la stagnation professionnelle”, par Patrice Desmedt, publié sur usine-digitale.fr, 2015

“L'Oréal : au cœur de la nouvelle conception de l'entreprise”, Julie Le Bolzer, Les Echos 2015

“L’informatique en nuage”, Figier.com, 2015 “The cloud changes IT culture, demands new tech skills”, par Sharon Gaudin,

publié sur computerworld.com, 2015 “The GROWS method”, http://growsmethod.com/, 2015

Études : “Cloud Index 2014”, Étude PAC, 2014 “Baromètre IDAOS Lab "Digital & Social"”, IDAOS, 2015 “les cadres français et le Cloud Computing”, étude Aruba - IFOP, 2015 “Etude Cloud 2015”, Silicon.fr, 2015 “Roundup of Small & Medium Business Cloud Computing Forecasts And

Market Estimates”, Forbes, 2015

http://www.it-expertise.com/marketing-et-dsi-comment-mieux-travailler-ensemble/




http://www.it-expertise.com/gerer-les-competences-dans-une-dsi/

http://www.it-expertise.com/gerer-les-competences-dans-une-dsi/


http://www.computerworld.com/author/Sharon-Gaudin/

http://www.computerworld.com/author/Sharon-Gaudin/

http://growsmethod.com/

cloud computing : une remise en question du rôle du si

Documents