Article – Quel est le niveau de maturité cloud de votre organisation ?

Du SaaS au PaaS, du cloud privé au multicloud, l’adoption des technologies cloud est lente et progressive. Pour gagner en maturité, une entreprise ou une administration doit s’interroger sur les bénéfices attendus d’une stratégie de transformation puis suivre un parcours aux étapes désormais bien identifiées.

En 2021, le cloud computing n’est plus, à proprement parler, une technologie émergente. Si cela fait maintenant quinze ans que Google et Amazon ont popularisé ce terme, ses racines sont plus anciennes encore. Avant le modèle du SaaS préexistait celui de l’Application Service Provider (ASP), ou fournisseur d’applications hébergées (FAH) en bon français.

En dépit de cette antériorité, le niveau de maturité des organisations dans leur transformation vers le cloud est très disparate. Du cloud privé au multicloud en passant par le cloud hybride, du SaaS au PaaS en passant par le IaaS, la montée dans le nuage est lente et progressive.

Pour évaluer le degré d’appropriation des technologies cloud, OBS s’appuie sur le framework Cloud Maturity Model (CMM), proposé par l’Open Alliance for Cloud Adoption (Oaca). Reprenant la graduation du CMMi, le référentiel de bonnes pratiques du développement logiciel, ce CMM comprend cinq niveaux de maturité, sans compter le niveau zéro. À ce stade initial, l’organisation reste clouée au sol. Elle a peu ou pas de connaissances sur le cloud et son système d’information repose exclusivement sur une infrastructure on premise.

Du décollage à la mise sur orbite, cinq niveaux de maturité

Au niveau1 (CMM1), des poches de virtualisation existent, mais elles restent limitées. L’accent est mis sur le cloud privé bien que le cloud public soit déjà utilisé pour des applications de niche. Au niveau2 (CMM2), des processus en cloud sont engagés et quelques initiatives permettent de dégager des gains capacitaires. Au niveau3 (CMM3), la structure s’est outillée et documentée, ses process sont automatisés.

Au niveau4 (CMM4), elle s’est dotée d’une gouvernance et ses compétences sont réunies au sein d’un centre d’expertise cloud (Cloud Center of Excellence, CCoE). Les déploiements ont gagné en agilité et répondent aux enjeux de business. Le PaaS devient omniprésent.

En fin de parcours, au niveau5 (CMM5), l’organisation est sur orbite. Elle pratique couramment le multicloud, les approches DevOps et FinOps. Son système d’information repose sur des normes fédérées, interopérables et ouvertes. À ce stade ultime, tous les gains escomptés en termes de qualité, de vitesse, de réduction de coûts et d’automatisation sont au rendez-vous.

« Cette méthodologie permet à une entreprise ou à une administration non seulement d’évaluer son niveau de maturité mais aussi de se comparer à des structures comparables évoluant dans le même secteur, explique Thierry Hortin, consultant senior Cloud Transformation chez OBS. Les technologies cloud étant transverses, cette approche s’adresse à l’organisation dans son ensemble : les technologies, les process et les hommes. La DSI comme la direction générale et les directions métier sont concernées. »

La phase d’audit d’une entreprise comprend une série d’entretiens : les premiers sont menés auprès de la direction générale, la plus à même d’avoir une vision globale de la stratégie de transformation cloud et des bénéfices attendus. « Les leviers diffèrent d’une organisation à l’autre, poursuit Thierry Hortin. Une entreprise peut vouloir gagner en agilité, automatiser ses processus métier, accéder à des services innovants dans le domaine de l’intelligence artificielle ou du big data, optimiser ses coûts, réduire son time to market ou s’affranchir de l’obsolescence programmée d’une infrastructure en propre. »

Les interviews se poursuivent auprès des directeurs métier, du DSI et de ses N-1 et, plus particulièrement, du pilote de la production, de l’architecte en chef ou du responsable applicatif. Les fonctions support sont également interrogées et notamment les achats et le DAF avec le passage, sur le plan comptable, du mode Capex au mode Opex. Sont-ils « cloud aware » ? Prennent-ils leurs décisions dans une optique cloud ?

Ces entretiens permettent, selon Thierry Hortin, d’identifier les points de blocage internes. « À la question ‘‘quels sont les freins qui vous empêchent d’aller au niveau 2 ?’’, les personnes interrogées répondent généralement qu’elles manquent d’outils, de compétences, de cadre de gouvernance ou de leadership sur le sujet. La transformation peut aussi buter sur une organisation en silos ou bien sur un plan stratégique qui n’a pas défini le cloud comme une priorité. »

À l’issue de la phase d’audit, l’entreprise reçoit un livrable. Il prend la forme d’une feuille de route listant les chantiers à dérouler pour passer de la situation existante à l’organisation cible. Des diagrammes de Kiviat (en toile d’araignée) permettent de visualiser les axes forts et ceux à renforcer dans le domaine de la stratégie, de la gouvernance, de l’architecture ou de l’infrastructure.

Du SaaS aux applications nativement cloud

Le CMM identifie onze domaines business et douze domaines techniques, et propose différents outils pour gagner en maturité. Sans impact sur l’infrastructure, le mode SaaS est le premier retenu pour répondre rapidement à des besoins métier. L’adoption du IaaS est plus progressive. Tout commence par le « lift and shift », qui consiste à faire migrer des applications ou des bases de données on premise vers des machines virtuelles sans les modifier, simplement en les copiant-collant. Ce « rehost » permet de déplacer ces ressources IT dans un autre data center ou vers un cloud public.

Le « replatform » s’applique quand les systèmes d’exploitation ou les bases de données sont dépassées. Cette obsolescence contraint à effectuer une mise à jour des plateformes avant de les faire migrer dans le cloud. Le « refactor » consiste à modifier les fichiers de configuration de l’application.

Avec le « rearchitect », on quitte le monde du IaaS pour s’approcher de celui du PaaS et du CaaS (Containers as a Service). Il s’agit d’encapsuler une application avec ses librairies dans un container logiciel pour assurer sa portabilité d’un cloud à l’autre.

Le « rebuild » consiste à redévelopper de zéro une application pour la désigner spécifiquement pour le cloud. Par son approche microservices, une application nativement cloud gagne en résilience. À la différence d’une solution monolithique du legacy, cette Cloud Native Application (CNA) ne « plantera » pas intégralement en cas de bug. Une partie de ses fonctionnalités continueront à être disponibles.

Quand un éditeur propose déjà une version cloud de sa solution – par exemple, Word dans Office 365 versus Word en version on premise –, on parle de « replace ». Le « remove » consiste à profiter de la transformation pour décommissionner une application obsolète ou non utilisée. Enfin, le « remain » revient à… ne rien faire. Une option inenvisageable à l’ère du cloud omniprésent.