Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# L'évolution du modèle d'exploitation du cloud
Le document de vision a précisé votre état cible, mais vous devez comprendre où vous en êtes dans votre parcours d'adoption du cloud pour relier la vision à vos capacités actuelles, puis comprendre les prochaines étapes. Nous avons constaté que de nombreux clients se concentrent sur l'endroit où ils veulent aller, mais il peut être difficile de voir quelle devrait être la première étape de leur parcours.
Après l'étape **Envision**, la AWS CAF définit trois autres phases :
+ **Aligner** : L'accent est mis sur l'identification des lacunes en matière de capacités selon les six points de vue de la AWS CAF (entreprise, personnel, gouvernance, plateforme, sécurité et opérations), sur l'identification des dépendances interorganisationnelles et sur l'identification des préoccupations et des défis des parties prenantes.
+ **Lancement** : L'accent est mis sur la mise en œuvre d'initiatives pilotes en production et sur la démonstration de la valeur commerciale supplémentaire. Les pilotes devraient avoir un fort impact. Si et quand ils sont couronnés de succès, ils contribueront à influencer l'orientation future.
+ **Échelle : l'**accent est mis sur l'extension des pilotes de production et de la valeur commerciale à l'échelle souhaitée et sur la garantie que les avantages commerciaux associés à vos investissements dans le cloud soient réalisés et durables.
L'objectif de AWS CAF étant d'améliorer votre préparation au cloud, nous ajouterons une autre phase après la phase de mise **à l'échelle** :
+ **Optimisation** : l'accent est mis sur la révision et l'amélioration continues de la solution finale afin d'apporter des avantages commerciaux supplémentaires.
L'utilisation de ces étapes avec le cadre AWS COM vous aide à identifier les fonctionnalités qui sont importantes pour vous à chaque instant. Par exemple, si vous êtes en phase de **lancement**, vous serez peut-être plus intéressé par la fonctionnalité *Architecture et modèles* que par la fonctionnalité *Resource/Estate Management*, qui est plus pertinente pendant la phase de mise **à l'échelle**.
Vous réalisez des activités spécifiques à chaque étape. Par exemple, dans la phase d'**alignement**, vous identifiez les capacités dont vous disposez actuellement et le niveau de maturité, puis vous déterminez les capacités sur lesquelles vous devez vous concentrer en premier. Si vous êtes en phase de **lancement**, il sera important d'identifier les équipes pilotes chargées de développer le prochain niveau de maturité. Cela nécessite une planification, c'est pourquoi nous vous recommandons de définir une feuille de route.
# Définir une feuille de route
Vous avez peut-être lu la citation suivante de Werner Vogels, vice-président et directeur technique d'Amazon : « *Vous le créez, vous le* gérez. «
Ceci est tiré de l'interview de 2006 [A Conversation with Werner Vogels : Learning from the Amazon technology platform](https://queue.acm.org/detail.cfm?id=1142065) (*ACM Queue*, vol. 4, numéro 4, 30 juin 2006). Werner a parlé du fonctionnement des équipes d'Amazon (le modèle opérationnel) et a décrit la suppression des barrières entre le développement et les opérations. La mise en place d'équipes interfonctionnelles dotées de toutes les capacités nécessaires pour créer, livrer et soutenir leurs produits est devenue une exigence pour une véritable transformation numérique.
Cependant, cette transformation numérique, qui est prise en charge par votre modèle d'exploitation du cloud, est souvent considérée comme trop importante pour être gérée en une seule fois. Nous considérons plutôt l'analogie entre un voyage et une feuille de route qui vous amène à *« Vous le construisez, vous le gérez »* comme destination. Chaque augmentation de la maturité de vos capacités vous rapproche de votre destination. Lorsque vous aurez atteint votre destination, votre organisation aura développé un moyen de mettre à jour en permanence le modèle d'exploitation du cloud pour l'adapter à l'évolution des résultats commerciaux, et la feuille de route sera mise à jour avec la prochaine destination.
Pour soutenir cette approche progressive, nous vous recommandons d'élaborer une feuille de route directement liée à la vision de votre organisation (mission et moteurs) et définissant les étapes (augmentation de la maturité, guidée par des principes) nécessaires pour atteindre la destination (résultats).
# Mettre en œuvre la feuille de route
Une fois que vous avez établi la feuille de route, vous devez la mettre en œuvre. Nous avons découvert que c'est là que les clients sont confrontés au prochain défi : ils ont passé du temps à *réfléchir* et doivent maintenant passer à l'*action*. Pour associer votre stratégie à sa mise en œuvre, nous vous recommandons de suivre les étapes suivantes :
+ [Décidez par où et comment commencer](#decide)
+ [Organisez-vous pour réussir](#organize)
+ [Mettre en place des mécanismes pour favoriser le changement](#establish)
+ [Développez la maturité de manière incrémentielle](#develop)
## Décidez par où et comment commencer
Cela semble facile, mais avec tant de choses à accomplir, trouver un point de départ est souvent une question difficile et controversée. Organisations qui migrent vers le cloud doivent se concentrer sur de nombreux points, et l'initiative peut devenir écrasante si elle n'est pas mise en contexte. Au fil des ans, les tendances des clients ont évolué, mais le [leadership transformationnel](https://docs.aws.amazon.com/whitepapers/latest/aws-caf-people-perspective/transformational-leadership.html) constitue un point de départ constant. L'élaboration des directives et de la stratégie du haut vers le bas et la création de l'énoncé de mission, des principes et de la FAQ sur les relations publiques permettent aux cadres intermédiaires et aux individus de prendre des décisions de manière autonome, d'apporter de la clarté et de générer de la valeur commerciale grâce à la transformation du cloud. Si vous n'avez pas effectué cet exercice ou un exercice similaire, nous vous recommandons de le faire comme première tâche.
Au cours de cet exercice, vous devez reconnaître que, contrairement aux autres transformations technologiques, la transformation du cloud rapproche la technologie de l'entreprise. La technologie est un levier que les entreprises utilisent pour atteindre des objectifs plus larges en permettant l'agilité, la stabilité, l'optimisation des coûts et des résultats similaires. Vous devez planifier cette transformation en tenant compte de la technologie et de l'activité, en vous appuyant sur la stratégie de 3 à 5 ans de votre organisation, en identifiant les objectifs en cours de route et en n'ayant pas peur de changer de cap en cas de besoin.
## Organisez-vous pour réussir
La manière dont votre organisation est structurée pour atteindre les objectifs de migration, d'adoption et de transformation vers le cloud changera à mesure que votre organisation mûrit. Comprendre cela, se préparer et être intentionnel sont essentiels pour garantir le succès.
En général, au début du parcours, les plus grandes équipes travaillent sur l'environnement sur site. Ensuite, à mesure que l'adoption du cloud augmente, ces équipes migrent pour créer, développer, exploiter et optimiser la plateforme cloud, et votre organisation doit s'adapter aux nouvelles méthodes de travail à chacune de ces étapes. Nous avons observé qu'un changement difficile mais important se produit lorsqu'une organisation a transféré 5 à 10 % de ses charges de travail vers le cloud (transition de la phase de lancement à la phase de mise à l'échelle). À ce stade, une entreprise fait appel à des équipes sur site pour exploiter les ressources du cloud, car la migration n'est pas suffisamment importante pour justifier des changements à plein temps. Ces équipes doivent donc trouver un équilibre entre les responsabilités existantes et les nouvelles responsabilités. Dans le même temps, les équipes sur site qui sont désormais invitées à exploiter des services cloud ont besoin de nouvelles compétences, ce qui implique une courbe d'apprentissage abrupte.
Pour comprendre votre organisation et élaborer un plan permettant de mettre en œuvre ces changements, nous vous recommandons d'examiner la topologie des équipes au sein de votre service informatique. Nous utilisons cette méthode avec les clients pour comprendre l'organisation et l'interconnexion des fonctions au sein d'une organisation informatique, qui est souvent différente des structures organisationnelles, puis nous utilisons le cadre AWS COM pour obtenir des conseils sur la manière d'organiser afin de respecter les étapes et les étapes de transformation. Toute modification de la structure organisationnelle qui pourrait être nécessaire est basée sur cet exercice.
Les topologies que nous avons utilisées avec nos clients incluent des modèles décentralisés, centralisés et fédérés. Elles s'appuient sur les représentations 2 par 2 du modèle opérationnel couvertes par le [AWS Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operating-model-2-by-2-representations.html) Framework, Operational Excellence Pillar.
### Décentralisée
Les grandes entreprises internationales qui opèrent dans différentes zones géographiques ou secteurs d'activité utilisent souvent le modèle décentralisé, illustré dans le schéma suivant. Dans ces entreprises, les unités commerciales individuelles disposent de leurs propres dispositions informatiques qui peuvent se chevaucher avec celles d'autres régions ou unités commerciales. Cependant, cela est souvent compris et accepté comme un moyen d'assurer l'autonomie et la spécialisation au sein de la région.
![\[Modèle de fonctionnement décentralisé\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/strategy-cloud-operating-model/images/decentralized-op-model.png)
L'utilisation de l'approche décentralisée signifie que chaque région ou unité commerciale dispose de son propre modèle d'exploitation cloud adapté aux besoins de cette région ou unité commerciale.
### Centralisée
Une fonction informatique centralisée est le modèle le plus fréquemment utilisé. Lorsque ce modèle est en place, les clients cherchent à conserver la même topologie lors de l'établissement de leur modèle d'exploitation cloud. Le diagramme suivant en est l’illustration.
![\[Modèle d'exploitation centralisé\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/strategy-cloud-operating-model/images/centralized-op-model.png)
Dans ce modèle, l'équipe centrale fournit une plate-forme organisée qui peut être utilisée par les équipes chargées de la charge de travail qui ont leurs propres modèles d'exploitation dans le cloud. Grâce à cette approche, les équipes chargées de la charge de travail peuvent se concentrer sur la valeur qu'elles apportent à leurs clients finaux sans avoir à se soucier des services, des opérations ou de la sécurité de la plateforme qu'elles utilisent. Ce modèle fonctionne bien pour les petites entreprises. Toutefois, dans les grandes entreprises internationales, le nombre d'équipes chargées de la charge de travail peut atteindre des centaines ou des milliers. Pour gérer à cette échelle sans perdre les avantages d'une plate-forme centrale, les entreprises optent fréquemment pour le modèle fédéré, décrit dans la section suivante.
### Fédérée
De nombreuses entreprises adoptent le modèle informatique fédéré car il fournit une fonction centrale responsable de la plate-forme cloud, mais permet de recourir à divers modèles d'exploitation au niveau de la charge de travail. Cela signifie que l'équipe centrale peut se concentrer sur la fourniture de la meilleure plateforme possible pour l'organisation sans avoir à travailler au plus petit dénominateur commun. Le schéma suivant illustre le modèle fédéré.
![\[Modèle d'exploitation fédéré\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/strategy-cloud-operating-model/images/federated-op-model.png)
Dans les grandes entreprises, le modèle fédéré fournit l'autonomie requise par les équipes d'ingénierie tout en garantissant que l'équipe centrale fournit la plate-forme et le levage indifférencié de charges lourdes communes à toutes les charges de travail. Dans ce modèle, l'équipe centrale doit travailler de la même manière centrée sur le produit que les équipes d'ingénierie, mais son produit est la plate-forme.
### Modification de la topologie en fonction du parcours
La topologie que vous choisissez dépend de la taille de votre entreprise, mais elle s'adapte également à l'étape de votre transition vers le cloud. L'organisation des départements ou des équipes n'est pas statique, mais évolue à chaque étape de l'adoption du cloud. Cela signifie que vous pouvez concevoir, discuter et augmenter différentes topologies en fonction de l'évolution de l'environnement. Voici des exemples de facteurs d'influence :
+ Passer de la validation de concept (POC) aux charges de travail pilotes
+ Expansion géographique ou d'une unité commerciale
+ Passage à des équipes centrées sur le produit
+ Possibilités de bénéficier d'économies d'échelle grâce à des composants ou à des modèles partagés
+ Mise en œuvre de la [loi de Conway](https://martinfowler.com/bliki/ConwaysLaw.html), qui influence la conception des applications et des services plutôt que les exigences architecturales
+ Mandats axés sur le cloud ou autres initiatives du haut vers le bas
+ KPI ou objectifs commerciaux manqués en raison d'objectifs d'équipe ou d'organisations incompatibles
## Mettre en place des mécanismes pour favoriser le changement
Au sein d'Amazon, un *mécanisme* est défini comme suit : *un processus complet qui convertit les entrées en sorties et qui est assemblé à partir de leviers organisationnels. Il utilise les données et les commentaires pour soutenir le processus et garantir l'atteinte des résultats.* Chaque organisation étant différente, chaque modèle d'exploitation du cloud est différent, mais elles ont toutes besoin d'un mécanisme pour susciter le changement.
Nous vous recommandons de consacrer du temps à comprendre et à développer des mécanismes adaptés aux changements nécessaires à la mise en œuvre de votre modèle d'exploitation cloud. Une approche populaire consiste à adopter les principes agiles. Les mécanismes agiles éliminent les barrières organisationnelles et liées aux processus entre les équipes cloisonnées et créent des boucles de feedback pour garantir que votre organisation passe du temps à innover dans les activités les plus percutantes qui généreront le plus de valeur commerciale.
## Développez progressivement la maturité
Dans le contexte d'un modèle d'exploitation du cloud, la *maturité* fait référence à la proximité de vos capacités avec des méthodes de travail privilégiant le cloud. Par exemple, dans quelle mesure vos processus sont-ils autonomes et quelle implication humaine est nécessaire pour gérer les affaires comme d'habitude (gérer l'entreprise) par rapport à l'innovation (changer l'entreprise) ? Si vos activités sont davantage axées sur le premier, votre maturité (cloud) est faible ; si c'est le second, votre maturité est plus élevée. Être faible sur l'échelle de maturité n'est pas un inconvénient, c'est le reflet de l'état d'avancement de votre parcours. L'objectif est de comprendre où vous vous trouvez et où vous devez vous rendre. Lorsque nous travaillons avec des AWS clients, nous utilisons une échelle de maturité intégrée au cadre AWS COM pour indiquer les étapes du parcours.
Nous vous recommandons d'utiliser un mécanisme pour augmenter progressivement la maturité des fonctionnalités du framework AWS COM. Nous avons notamment travaillé avec nos clients de cette manière en convertissant les évaluations de maturité et la priorisation (intrants) en une augmentation de la maturité (résultats), puis en organisant des événements basés sur l'expérience, tels que des [Game Days](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.gameday.en.html) (boucles de feedback) pour vérifier les résultats et apporter les ajustements nécessaires. En établissant ces mécanismes aux côtés des clients, nous avons découvert que lorsque cette force organisationnelle est développée, elle permet non seulement d'atteindre des objectifs immédiats, mais également d'apporter des améliorations progressives qui se prolongent au-delà des phases initiales du parcours.
Le fait de veiller à faire mûrir les capacités de votre organisation et d'apporter progressivement les modifications nécessaires à des capacités spécifiques, à des moments précis de votre feuille de route, lie la stratégie à la mise en œuvre. Cela vous permet également de tirer parti des économies d'échelle qui découlent de la consolidation de vos réalisations antérieures.
# Mesurez les progrès
Les sections précédentes ont mis en évidence la manière dont les leaders du cloud peuvent créer une vision convaincante pour leur modèle d'exploitation cloud. Nous avons fourni des conseils sur la manière de relier la stratégie à la mise en œuvre afin de vous aider à élaborer votre modèle d'exploitation cloud. Nous avons également expliqué la nécessité d'un cadre, tel que le cadre AWS COM, pour comprendre et développer les niveaux de maturité, et pour établir une feuille de route des fonctionnalités répondant aux besoins de votre organisation. Il reste encore un élément à prendre : veiller à ce qu' KPIs ils soient établis pour mesurer les progrès et indiquer les domaines dans lesquels un changement de direction est nécessaire pour maintenir l'élan.
Au sein de la communauté de la AWS transformation interne, l'une des questions les plus fréquemment posées est la *suivante : « Comment nos clients peuvent-ils savoir s'ils sont réellement en train de transformer leur entreprise ? »*
Pour comprendre pourquoi cette question est importante et ce que l'on peut faire pour y remédier, consultez la présentation re:Invent 2015 d'Eric Tachibana intitulée [9 meilleures pratiques pour éviter le blocage d'un programme de transformation](https://www.youtube.com/watch?v=dU3gFDcsZOw) du cloud. Dans cet exposé, Eric explique comment les clients peuvent ralentir, voire stopper, leur transition vers le cloud (*The* *Great Stall*) et présente les meilleures pratiques recueillies auprès de AWS clients qui ont réussi à accélérer ces délais.
Le graphique suivant met en évidence ce qui peut se passer à The Great Stall, et Eric explique comment passer cette phase. Nous pouvons approfondir cette discussion en disant que pour progresser au-delà de The Great Stall et pour gérer le voyage, vous devez établir des mesures et être en mesure de corriger votre trajectoire.
![\[Mesurer les progrès\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/strategy-cloud-operating-model/images/measuring-progress.png)
L'adoption et la consommation de services cloud permettent cette transformation, de sorte que l'absence d'un modèle d'exploitation cloud fonctionnel et le manque de visibilité sur le parcours peuvent faire entrer l'adoption dans The Great Stall. Par conséquent, nous recommandons aux responsables du cloud de chercher à établir l'observabilité sous la forme d'un tableau de [bord équilibré](https://www.investopedia.com/terms/b/balancedscorecard.asp). Ce tableau de bord consiste en un ensemble de mesures alignées sur la transformation numérique ou cloud. Il permet de comprendre votre situation actuelle et de prévoir tout problème à venir.
## Visualisation des métriques
L'élaboration d'un tableau de bord équilibré pour visualiser les indicateurs permet de comprendre et de situer les efforts de transformation actuels dans le contexte de la valeur commerciale qu'ils visent à apporter. L'une des approches utilisées par AWS les équipes avec leurs clients consiste à créer un tableau de bord de transformation. Cette approche est basée sur une étude réalisée par des analystes auprès de clients ayant mené à bien leur transformation vers le cloud et sur une analyse interne des données (anonymisées) sur la consommation de AWS services de plus de 5 000 clients du monde entier et de plusieurs secteurs d'activité.
Bien que notre discussion dans ce guide soit basée uniquement sur les AWS Cloud services, vous pouvez étendre cette approche à un environnement hybride ou multicloud. À l'aide de cette méthode, nous avons identifié un tableau de bord équilibré pour la transformation et plusieurs modèles pouvant être associés à des clients qui se trouvent à différents stades de leur transition vers un modèle d'exploitation cloud. L'objectif de cette approche est d'aider les clients à identifier les moyens de suivre leur niveau global de croissance transformatrice, d'éviter les blocages et de s'assurer qu'ils continuent à développer leur modèle d'exploitation cloud en tant que catalyseur de la transformation globale de l'entreprise.
Le tableau de bord équilibré de notre tableau de bord de transformation comporte quatre segments :
+ Agilité et délai de mise sur le marché
+ Avantage stratégique (et innovation en matière de services)
+ Réduction des risques
+ Efficacité opérationnelle
Dans ce tableau de bord, deux segments mettent en évidence les valeurs associées au délai de mise sur le marché, à l'agilité, à l'innovation et à l'obtention d'un avantage sur les concurrents (dans un environnement commercial). Les deux autres segments visent à mesurer la manière dont l'organisation devient plus efficiente, efficace et résiliente, et à éviter d'être désavantagée par rapport à ses concurrents. Le tableau de bord est illustré dans le schéma suivant.
![\[Visualisation des métriques\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/strategy-cloud-operating-model/images/visualizing-metrics.png)
En traçant des points de données sur cette matrice, vous pouvez représenter l'objectif de votre organisation. Cela vous permet de comprendre si votre modèle d'exploitation du cloud est développé pour *éviter les désavantages* ou pour en *tirer un avantage*. Dans le premier cas, nous vous recommandons de corriger votre cours pour vous assurer que vous développez des capacités et que vous vous concentrez sur le second, car c'est en tirant le meilleur parti que vous pouvez tirer le meilleur parti.
D'une manière générale, les programmes de migration à grande échelle pour le réhébergement des charges de travail (*lift et shift*) visent à éviter les inconvénients. Une fois la migration effectuée, les activités de modernisation telles que l'adoption d'une plateforme en tant que service (PaaS) ou de technologies sans serveur permettent de gagner en avantages. Par exemple, consultez les deux études AWS commandées suivantes qui passent en revue ces approches et fournissent des informations sur la KPIs base d'études de marché :
+ **Migration :** [la valeur commerciale de la migration vers Amazon Web Services](https://pages.awscloud.com/rs/112-TZM-766/images/hackett-group-the-business-value-of-migration-to-aws-012022.pdf) (The Hackett Group, février 2022). Dans cette étude, The Hackett Group a mesuré la valeur de la migration AWS dans quatre catégories : résilience, agilité, économies de coûts et productivité du personnel.
+ **Modernisation :** [valeur commerciale de la modernisation du cloud](https://pages.awscloud.com/rs/112-TZM-766/images/known-business-value-of-cloud-%20modernization-012022.pdf) (connu, janvier 2022) a permis de saisir l'utilisation de 22 points uniques KPIs pour comprendre la valeur de la modernisation par le biais des services cloud. Dans le cadre de cette étude, ils ont interrogé plus de 500 entreprises ayant déjà migré leurs charges de travail vers le cloud afin de comprendre la valeur associée à quatre stratégies de modernisation technique : conteneurs, solutions sans serveur, analyses gérées et données gérées.
Tout au long de votre transition vers un modèle d'exploitation cloud, il est important de choisir des mesures qui peuvent couvrir à la fois les aspects de migration et de modernisation afin de suivre les progrès, de comparer les données tout au long du parcours et de voir les résultats de la correction de cap.