Cela fait dix ans que les organisations évoquent des politiques « cloud-first » pour moderniser leurs parcs informatiques. À cette époque, l’approche cloud-first consistait surtout à déplacer les applications vers le Software-as-a-Service (SaaS) et à provisionner l’infrastructure — du calcul au stockage — en tant qu’Infrastructure-as-a-Service (IaaS).

En réalité cependant, bon nombre d’organisations réagissent lentement, freinées par leurs infrastructures déjà en place. Beaucoup d’entre elles en sont restées à la phase expérimentale, se retrouvant avec des environnements hétérogènes et complexes mêlant infrastructure IT sur site, cloud privé, multicloud et parfois même cloud « hérité ».

Une approche “cloud-first” consiste simplement à adopter le cloud, quel qu’en soit le coût. L’approche Cloud Right™, quant à elle, consiste à observer le paysage en constante évolution, puis à faire les bons investissements technologiques au bon moment. Si l’évolution du cloud peut profiter à tous, toutes les organisations informatiques n’en sont pas au même point dans leur parcours.

Qu’est-ce qui a changé ?

C’est en novembre 2014, alors que les entreprises commençaient à peine à implémenter leurs premières stratégies cloud-first, que AWS a annoncé les débuts du calcul sans serveur avec le lancement de AWS Lambda. Néanmoins, l’adoption du cloud est un processus lent. Netflix et Capital One ont ainsi mis, respectivement, sept et huit ans à remplacer tous leurs datacenters.

Si vous démarriez aujourd’hui la migration cloud-first de vos processus IaaS et DevOps, vous ne termineriez probablement votre parcours qu’après 2028 — sous réserve que vous disposiez de la vitesse, de la capacité et de l’envergurede Netflix ou de Capital One. Pire : vos créations seraient, au mieux, qualifiées de « neuf ancien », car le reste de l’industrie serait déjà passé au calcul sans serveur.

Soyons honnêtes : choisir le “cloud-first” aujourd’hui, c’est prendre le risque de s’enfermer dans un processus qui ne mène à rien. Focalisons-nous sur nos objectifs futurs, et non sur nos réalisations passées — telle est la finalité de l’approche Cloud Right de DXC Technology.

Préférer les résultats opérationnels aux prouesses technologiques

Le délai de rentabilité constitue l’avantage concret du calcul sans serveur. Un cadre d’une société d’assurance internationale fondée il y a un siècle l’explique en ces termes : « Nos fournisseurs avaient à peine eu le temps de répondre à notre appel d’offres que notre système sans serveur était déjà opérationnel, avec un coût par transaction passé de vingt dollars à huit centimes. »

Il poursuit : « La charge cognitive est trop lourde : vous pouvez soit disposer d’une équipe sans serveur chargée de réduire les coûts des transactions et d’accélérer le traitement des réclamations/tâches, soit disposer d’une équipe focalisée sur les complexités de la distribution de conteneurs. En tant que compagnie d’assurance, nous sommes intéressés par les résultats de nos clients, et non par les clusters d’infrastructure. »

Cette dernière phrase est intéressante : le débat actuel sur le cloud porte majoritairement sur des questions liées à la dépendance vis-à-vis des fournisseurs et à la sécurité. La priorité n’est pas suffisamment donnée aux résultats opérationnels.

Comme le dit le vice-président  d’une entreprise d’ingénierie, « les conversations entre DSI portent naturellement sur l’hybride, les conteneurs, l’enfermement propriétaire et le retour sur investissement, mais jamais sur la rapidité de commercialisation, le délai de création de valeur ou les résultats opérationnels. Posez-vous la question suivante : comment feriez-vous pour rivaliser avec une entreprise 100 % cloud, comme Capital One ou Netflix ? Tiendriez-vous la cadence face à ces cadors qui, contrairement à vous, consacrent 100 % de leurs efforts à leur cœur de métier ? »

À l’ère du calcul sans serveur, le résultat est une thématique récurrente. Comme l’affirme le directeur d’un organisme gouvernemental importante, « dans un environnement multicloud, tous les clouds sont identiques en apparence, mais la complexité rend la gestion très difficile et aboutit à un univers très fragmenté, sauf si une architecture sous-jacente ultra-robuste a été mise en place — une architecture qui n’empêchera pas toutefois les problèmes de compétence liés au multicloud. Ce raisonnement tient plus du mythe que de la réalité. Pour DXC, la mission est un enjeu stratégique, où la vitesse joue un rôle essentiel. C’est le résultat qui compte : dès lors, nous devons utiliser des environnements de cloud public et sans serveur, même si cela s’oppose à notre mentalité et à notre politique initiale. »

Que signifie Cloud Right pour vous ?

Cloud Right est une approche combinant plusieurs concepts : où devons-nous aller, et quels compromis devons-nous faire ? Nous savons que nous avons besoin du cloud. Nous savons également que Cloud Right est une approche sans serveur, mais également que le marché ne cesse d’évoluer et que de nouveaux systèmes plus performants (programmation conversationnelle, par ex.) verront le jour. Nous savons que pour bon nombre d’entre nous, il est impossible d’entreprendre ces étapes à l’heure actuelle, et que notre inaction peut prendre des formes très diverses — coûts irrécupérables, modes de travail venus du passé, etc. Il aurait fallu s’intéresser au cloud lors de ses cinq premières années (2006 à 2011) avant d’enchaîner avec huit ans de processus de migration... mais en réalité, très peu sont ceux qui l’ont fait.

Nous avons raté le coche, et nous ne pouvons pas revenir sur le passé. On se dit parfois que la pression de la concurrence n’est pas suffisante pour devoir changer, mais attention : la complaisance est un sentiment souvent illusoire et dangereux, quel que soit le secteur.

On pourrait se rassurer en se disant qu’un jour, la technologie pourra nous faire voyager dans le futur, mais on aurait alors tendance à simplement attendre que tout nous tombe du ciel.

Comme l’indique un dirigeant d’une grande société financière internationale : « Le cloud est en pleine évolution, mais il faut une révolution pour migrer vers le cloud. Il faut désapprendre les modèles du passé et, plus votre chemin pour y parvenir sera long, moins vous aurez de chances d’arriver à destination. Vous devrez vous déconstruire pour pouvoir réussir. »

Les prochaines étapes

Si certains éléments de ce langage peuvent paraître difficiles, le défi est une composante clé du parcours. Sur la base de ses principes directeurs, DXC Technology aide les entreprises à relever le défi en cartographiant leurs paysages du marché et leurs propres parcs informatiques. Votre parc informatique sera peut-être très différent de celui d’autres entreprises, mais ce ne sera pas le cas de la cartographie du paysage du marché. Je vous le dis avec certitude : vous ne devriez pas investir dans une infrastructure privée ou dans la création de clusters, ni même démarrer une transformation DevOps.

Mais si on se place du point de vue de l’approche Cloud Right, ces étapes peuvent être précisément ce dont vous avez besoin pour vous lancer. Il n’existe pas de playbook, et il n’en existera certainement jamais. Chaque situation et chaque entreprise sont différentes. Néanmoins, vous pouvez suivre certains principes directeurs : Intéressez-vous à vos utilisateurs et à leurs besoins, efforcez-vous de comprendre les détails (par ex. votre chaîne d’approvisionnement logicielle) et les éléments considérés (c’est-à-dire le degré d’évolution des composants), décidez d’un langage commun, remettez en question les idées reçues et concentrez-vous sur les résultats.

Dès 2015, le PDG de Capital One, Richard Fairbank, décrivait le cloud comme un avantage stratégique : « Nous nous focalisons de plus en plus sur le cloud  et nous mettons en place les capacités sous-jacentes, afin que le développement produit gagne en vitesse et en efficacité.

La seule question à se poser est la suivante : allons-nous rater cette nouvelle opportunité ? Cloud Right ne vous offrira peut-être pas immédiatement monts et merveilles, mais vous permettra de vous lancer sur le parcours — et le bon.

L’auteur