The Doppler Quarterly (FRANÇAIS) L'automne 2016 | Page 7

Les confl its survenant entre les équipes de la sécurité et le
service du développement créent également des frictions
inutiles. Ceci se traduit par des obstacles inutiles, qui ralen-
tissent l’adoption du cloud. Chaque fois qu’une grande
entreprise subit une violation d’un type quelconque, les
marchands de peur de la sécurité commencent à dénigrer
les initiatives en cloud public, même si la plupart des obsta-
cles sont sans lien avec le cloud.
Le favoritisme à l’égard des fournisseurs est un autre obsta-
cle majeur. J’ai vu des fans d’un fournisseur rechercher pour
l’entreprise des solutions sous-optimales en raison de leur
fi délité envers un fournisseur de cloud existant. Ces per-
sonnes tiennent une quantité de discours trompeurs sur les
fournisseurs de cloud leaders afi n d’imposer leur agenda
pour de faux clouds. Ils font également la promotion de
mythes sur le cloud public afi n de contraindre les leaders à
poursuivre leurs investissements dans le datacenter et les
clouds à faire soi-même.
Il faut un défenseur du cloud responsable pour combattre
les politiques qui nourrissent des discours trompeurs sur le
cloud, des représentations erronées de la valeur commer-
ciale du cloud et des mythes nuisibles au cloud paralysant
les initiatives cloud.
Problèmes culturels
L’existence de barrières culturelles est probablement le fac-
teur numéro un qui ralentit les initiatives cloud. Pour nom-
bre d’entreprises, passer du computing traditionnel au
cloud computing nécessite un changement d’état d’esprit
majeur. Pour bénéfi cier pleinement du cloud computing, il
faut commencer à considérer les services et les applications
cloud natives.
Traditionnellement, les entreprises sont habituées à con-
cevoir des applications monolithiques et à les déployer deux
fois par an ou éventuellement chaque trimestre. Le nouveau
modèle consiste à fournir de petites séries de changements
et à procéder à un déploiement deux fois par semaine, heb-
domadaire, voire quotidien. Pour ce faire, le cycle de vie
entier du développement de logiciels (SDLC, Software
Development Life Cycle) doit être réévalué. Les déploie-
ments fréquents reposent sur une automatisation de toute
la pile. Les fenêtres d’examen manuel laissent place à une
sécurité automatisée, des plans standard, une mise à jour
corrective et une surveillance proactive.
Il s’agit d’un changement radical par rapport à la manière
dont les applications étaient habituellement conçues,
gérées et gouvernées. Voici pourquoi DevOps est tellement
critique. DevOps n’est pas l’automatisation informatique.
C’est plus que cela. DevOps inclut la chaîne de valeur
entière, du lancement des projets à l’exécution des services
dans le cloud. Les entreprises doivent évaluer leur chaîne de
valeur existante pour en identifi er les goulots d’étrangle-
ment, et éliminer ces goulots d’étranglement avant de
procéder à l’automatisation. Sans cela, elles ne font qu’au-
tomatiser les gaspillages. Une erreur majeure que la plupart
des entreprises commettent est qu’elles ne se concentrent
que sur les aspects technologiques de DevOps et ne pren-
nent pa s en compte les transformations nécessaires au
niveau des personnes et des processus.
Passer au cloud implique en effet des transformations
majeures. C’est la raison pour laquelle nous conseillons aux
entreprises d’exploiter notre méthodologie d’adoption du
cloud et de créer en vue du changement un plan stratégique
qui prépare la réussite de leur initiative cloud.
Défi s technologiques
Concevoir des solutions dans le cloud peut présenter des
défi s technologiques, en particulier si les nouvelles applica-
tions cloud doivent s’intégrer à des solutions sur site. L’in-
tégration à des technologies non cloud crée des complex-
ités, et celles-ci génèrent du chaos, qui se traduit par une
avancée lente.
J’ai participé à de nombreuses initiatives nécessitant de
ramener tout le trafi c réseau cloud aux datacenters sur site
existants. L’intégration aux technologies et aux outils de
réseau existants génère une somme de travail signifi cative
et mène souvent à des solutions sous-optimales. Elle
entraîne également des problèmes liés par exemple à la
latence, qui à leur tour se traduisent par plus de travail non
planifi é et des solutions de contournement fréquentes.
Le manque de compétences internes et de réfl exion sur le
cloud mène souvent à des architectures sous-optimales.
Trop souvent, les entreprises adoptent une approche du
cloud orientée sur le datacenter, et le cloud de ce fait ne
devient rien de plus qu’un autre datacenter, et non pas une
plate-forme dédiée à l’agilité et l’innovation.
Intégrer vos anciens outils au cloud génère souvent des
solutions sous-optimales et du travail inutile pour résoudre
la quadrature du cercle. J’ai trop souvent été témoin de ce
scénario. L’entreprise ne prend aucune mesure, attendant
de nouvelles fonctionnalités, tandis que les tenants de l’in-
formatique gaspillent des cycles précieux à bricoler des
outils et des processus sous-optimaux qui n’apportent
aucune valeur à l’entreprise. Saisissez cette opportunité
pour évaluer le remplacement des outils existants par des
solutions SaaS modernes ou des outils cloud natifs plus
récents.
Exécution pauvre
Même si vous arrivez à résoudre les trois problèmes précé-
dents, il vous reste encore à gérer cette initiative complexe
et transformationnelle effi cacement. La clé ici consiste à ne
pas en faire trop, trop vite. Nous recommandons une
approche de cloud viable minimum (MVC, Minimal Viable
Cloud). La stratégie MVC cible un ensemble restreint de
charges de travail et permet à l’entreprise d’effectuer des
changements constants à travers la conception
AUTOMNE 2016 | THE DOPPLER | 5