3.11 Architecture cloud

Vue d’ensemble et motivation

L’informatique en nuage consiste à louer l’infrastructure de quelqu’un d’autre à la demande, sur un réseau, facturée pour ce que vous utilisez, et libérée quand vous avez fini. L’architecture cloud est la discipline de concevoir des systèmes qui traitent ces ressources louées comme leur foyer natif plutôt que comme une copie louée de votre ancien centre de données. Cette distinction est tout l’intérêt de ce chapitre. Vous pouvez déplacer une application héritée vers un fournisseur cloud et ne rien changer à sa conception, et vous obtiendrez une facture plus grande et à peu près la même fragilité. Ou vous pouvez concevoir pour le cloud et obtenir de l’élasticité, des services gérés qui effacent des catégories entières de travail non différenciateur, et la capacité de survivre à la panne d’un bâtiment entier sans réveiller quiconque. Cela s’appuie directement sur les fondamentaux du chapitre 3.1 : l’architecture cloud est de l’architecture, avec les mêmes compromis et attributs de qualité, appliquée à un substrat que vous ne possédez pas.

Pour les grandes équipes, les enjeux sont plus élevés parce que le cloud reconfigure qui fait quoi. Quand une équipe peut provisionner une base de données, une file, et un équilibreur de charge mondial en minutes, le goulot d’étranglement cesse d’être l’approvisionnement et devient la gouvernance : le coût, la sécurité, et la cohérence à travers des dizaines d’équipes faisant cela à la fois. Le cloud donne à chaque ingénieur une carte de crédit d’entreprise et un entrepôt d’outils puissants, ce qui est merveilleux et dangereux à parts égales. Bien faire l’architecture signifie capturer l’avantage (vitesse, élasticité, résilience) tout en installant les garde-fous qui gardent la dépense, la posture de sécurité, et la résidence des données sous contrôle.

Les entreprises et les gouvernements ressentent les deux tranchants nettement. Les entreprises arrivent avec des décennies de systèmes existants, donc leur histoire cloud est généralement une histoire de migration, pleine de connectivité hybride et de décisions difficiles d’acheter-contre-construire. Les gouvernements portent le poids supplémentaire de la souveraineté, des régimes d’autorisation, et des données de citoyens qui ne peuvent légalement pas quitter certaines frontières. Les décisions ici (quel modèle de service, combien de fournisseurs, où se trouvent les domaines de panne, ce qui fonctionne comme service géré contre votre propre code) façonnent le coût et le risque pour une décennie.

Principes clés

Concevez pour le cloud, ne photographiez pas votre centre de données. L’élasticité, les services gérés, et la conscience des domaines de panne sont les raisons d’être ici ; un transfert-en-l’état jette tout cela.
Tout est provisionné comme du code. Si un humain le fait exister d’un clic, c’est non documenté, non répétable, et non auditable.
Concevez à travers les domaines de panne délibérément. Les régions, zones de disponibilité, et services échouent ; votre architecture décide si c’est un haussement d’épaules ou une panne.
Le modèle de responsabilité partagée est un contrat, pas un slogan. Sachez exactement quelle ligne le fournisseur sécurise et quelle ligne vous sécurisez.
Achetez le non différenciateur, construisez le différenciateur. Les services gérés valent du vrai argent pour la plomberie ; gardez votre avantage compétitif entre vos propres mains.
L’enfermement est un coût à chiffrer, pas un péché à éviter. La portabilité a un prix et le levier a une valeur ; décidez délibérément plutôt que par réflexe.
Le coût est un attribut de qualité de premier ordre. Dans le cloud, l’architecture et la facture sont la même décision.

Recommandations

Choisir délibérément le modèle de service, et par défaut sur géré

Les fournisseurs cloud vendent le long d’un spectre capturé par les modèles en tant que service : Infrastructure as a Service (IaaS) loue du calcul brut, du stockage, et du réseau ; Platform as a Service (PaaS) loue un runtime géré pour que vous déployiez du code sans entretenir de serveurs ; Software as a Service (SaaS) loue des applications finies. L’informatique sans serveur, incluant les fonctions et les services gérés pilotés par événements, pousse cela plus loin : vous fournissez du code ou de la configuration et le fournisseur gère tout le provisionnement, s’échelonnant jusqu’à zéro quand inactif. Chaque pas plus haut sur le spectre échange le contrôle contre le levier, de l’IaaS avec le plus de contrôle et le plus de fardeau opérationnel au sans serveur avec le moins des deux.

La valeur par défaut devrait être de grimper aussi haut sur ce spectre que vos exigences le permettent. Une base de données gérée qui gère les correctifs, les sauvegardes, le basculement, et la mise à l’échelle est presque toujours un meilleur usage de vos ingénieurs qu’une auto-exploitée. Réservez l’IaaS de niveau inférieur aux cas qui en ont vraiment besoin : matériel spécialisé, frontières de conformité inhabituelles, contraintes de licence, ou performance que l’offre gérée ne peut satisfaire. Consignez la raison par écrit comme un registre de décision d’architecture (chapitre 3.1), parce que « nous exploitons notre propre courtier de messages » est une affirmation qui devrait être rejustifiée chaque année.

Concevoir à travers les régions et zones de disponibilité comme domaines de panne explicites

Une région cloud est une zone géographique ; à l’intérieur, les zones de disponibilité sont des centres de données physiquement séparés avec une alimentation, un refroidissement, et un réseau indépendants, assez proches pour une réplication à faible latence mais assez éloignés pour qu’une panne n’emporte pas les autres. Ce sont les coutures le long desquelles le cloud se brise, donc votre architecture doit les traiter comme de premier ordre. La base de référence pour toute charge de travail sérieuse est multi-zone : répartissez le calcul et les données à travers au moins deux, idéalement trois, zones pour que perdre une zone dégrade la capacité plutôt que de causer une panne. C’est une assurance bon marché avec rarement une bonne excuse pour la sauter.

Le multi-région est une décision plus lourde, liée à vos cibles de résilience et de récupération (chapitre 3.5) et votre plan de reprise après sinistre (chapitre 9.5). Se répartir à travers des régions achète la survie d’une panne de région entière et peut rapprocher les données des utilisateurs, mais introduit un vrai coût, de la latence, et des problèmes de cohérence, parce que la réplication synchrone inter-région est lente et la réplication asynchrone signifie accepter une perte de données au basculement. Décidez sur la base d’objectifs explicites de temps de reprise et de point de reprise, pas un vague souhait d’être « hautement disponible ». La plupart des systèmes ont besoin d’un multi-zone robuste et d’un chemin de récupération multi-région testé ; peu ont vraiment besoin d’actif-actif à travers les régions, et ceux qui le construisent sans en avoir besoin paient la complexité chaque jour.

Traiter le modèle de responsabilité partagée comme une frontière architecturale

La sécurité cloud fonctionne sur un modèle de responsabilité partagée : le fournisseur sécurise le cloud (installations physiques, l’hyperviseur, les internes du service géré) et vous sécurisez ce que vous mettez dans le cloud (vos données, les contrôles d’accès, la configuration réseau, et le code). La ligne exacte bouge à mesure que vous grimpez le spectre de service. Avec l’IaaS, vous corrigez le système d’exploitation ; avec une base de données gérée, vous ne le faites pas, mais vous possédez encore qui peut se connecter et si les données sont chiffrées. Les incidents les plus coûteux viennent de mal lire cette ligne, le plus célèbre étant le compartiment de stockage ouvert qui fuit des millions d’enregistrements parce que quelqu’un a supposé que le fournisseur l’avait rendu privé par défaut.

Rendez la frontière explicite dans vos conceptions et remettez les détails au chapitre 4.3, qui couvre l’infrastructure et la sécurité cloud en profondeur. Architecturalement, les impératifs sont constants : chiffrez les données au repos et en transit par défaut, accordez le moindre privilège à travers l’identité plutôt que la position réseau, gardez petit le rayon d’impact de tout identifiant unique, et supposez que toute ressource accessible par internet sera sondée en quelques minutes. Intégrez cela dans votre zone d’atterrissage pour que les équipes en héritent.

Provisionner tout comme du code, à l’intérieur d’une zone d’atterrissage gouvernée

Dans une pratique cloud mature, aucune ressource de production n’existe parce qu’une personne a cliqué dans une console. Tout est déclaré en infrastructure en tant que code (chapitre 8.2), versionné, relu, et appliqué à travers un pipeline, pour que votre infrastructure soit reproductible, auditable, et comparable par diff. C’est ce qui rend le multi-zone, le multi-région, et la reprise après sinistre réels au lieu d’aspirationnels : vous pouvez monter un environnement identique dans une nouvelle région parce que l’environnement est un programme, pas un souvenir.

Enveloppez ce code dans une zone d’atterrissage : une fondation pré-construite et gouvernée de comptes (ou abonnements ou projets), de réseau, d’identité, de journalisation, et de garde-fous sur laquelle chaque équipe construit. Utilisez des comptes séparés comme frontières de rayon d’impact et de facturation, pour que l’erreur d’une équipe ne puisse pas atteindre les données d’une autre et que chaque dollar se retrace à un propriétaire. Imposez des garde-fous comme de la politique-en-tant-que-code qui prévient les configurations interdites (une base de données publique, un volume non chiffré, une ressource dans une région non autorisée) plutôt que de compter sur une relecture après coup. Une équipe de plateforme centrale possède généralement la zone d’atterrissage, rattachant ce chapitre à l’ingénierie de plateforme (chapitre 8.4) et aux conteneurs et runtimes cloud-natifs (chapitre 8.3).

Chiffrer honnêtement l’enfermement, et être sceptique envers le multi-cloud

L’enfermement fournisseur est le coût de changer de fournisseur, et c’est un spectre, pas un binaire. Utiliser la file gérée d’un fournisseur crée un certain enfermement ; utiliser sa plateforme d’apprentissage automatique propriétaire en crée beaucoup. La peur réflexe de cela pousse les équipes à sacrifier un vrai levier (les services gérés qui rendent le cloud digne d’être utilisé) pour préserver une portabilité qu’elles n’exerceront jamais. Le mouvement honnête est de la chiffrer : pour chaque dépendance significative, estimez ce que partir coûterait réellement et pesez-le contre ce que le service vous économise maintenant. Abstraire un service géré pour rester portable coûte souvent plus, en permanence, que la migration contre laquelle vous vous assurez ne coûterait jamais.

C’est pourquoi le vrai multi-cloud (exécuter la même charge de travail à travers deux fournisseurs) est généralement un culte du cargo plutôt qu’une stratégie. Cela vous force vers le plus petit dénominateur commun, double votre surface opérationnelle, et multiplie l’expertise que vos équipes doivent détenir, tout cela pour couvrir un risque qui se matérialise rarement. Il y a des raisons légitimes de toucher plus d’un fournisseur : un SaaS meilleur-de-sa-catégorie d’un second fournisseur, un mandat de résilience réglementaire, ou une exigence de souveraineté délibérée (chapitre 10.11). Le cloud hybride, garder certains systèmes sur site connectés au cloud, est souvent inévitable pendant une migration d’entreprise et pour des données qui ne peuvent légalement pas bouger. Choisissez ceux-là les yeux clairs et avec une justification écrite, pas parce qu’une présentation a dit « multi-cloud ».

Concevoir pour le coût, et adopter la pensée bien architecturée

Dans le cloud, une décision architecturale est une décision de dépense : sur-provisionner « au cas où » apparaît sur la facture du mois prochain. Traitez le coût comme un attribut de qualité pour lequel vous concevez, et adoptez les pratiques FinOps, la discipline de la responsabilité financière partagée pour la dépense cloud (chapitre 9.4), pour que l’ingénierie, la finance, et le produit possèdent ensemble la facture. Étiquetez chaque ressource avec un propriétaire, rendez le coût visible par équipe et par service, redimensionnez continuellement, utilisez la mise à l’échelle automatique pour payer pour la charge plutôt que pour le pic, et exploitez les leviers de tarification (remises d’usage engagé, capacité spot pour le travail interruptible) que le cloud offre.

Au-delà du coût, utilisez un cadre bien architecturé comme liste de contrôle de relecture. Les principaux fournisseurs en publient chacun un, et ils convergent sur les mêmes piliers : fiabilité, sécurité, optimisation de coût, efficacité de performance, excellence opérationnelle, et durabilité. Menez une relecture légère au moment de la conception et périodiquement ensuite, notant le système contre chaque pilier et enregistrant les lacunes comme du travail suivi. C’est un moyen bon marché d’attraper le compromis que vous n’avez pas remarqué.

Compromis : avantages et inconvénients

Approche	Avantages	Inconvénients
Transfert-en-l’état (rehost)	Rapide, faible effort initial, sort rapidement du centre de données	Garde l’ancienne fragilité, manque l’élasticité et les services gérés, coûte souvent plus
Reconception cloud-native	Élasticité complète, résilience, levier de service géré	Effort et compétences initiaux plus élevés ; plus grand changement à absorber
Cloud unique, intégration profonde	Simplicité, levier maximal, surface opérationnelle plus basse	Enfermement concentré et risque fournisseur
Multi-cloud (même charge de travail, deux fournisseurs)	Couverture contre la panne fournisseur, levier de négociation	Conception au plus petit dénominateur commun, opérations et expertise doublées
Hybride (cloud plus sur site)	Satisfait les contraintes de résidence de données et héritées, migration échelonnée	Complexité réseau, deux modèles opérationnels à exploiter à la fois
Sans serveur / hautement géré	Corvée minimale, s’échelonne jusqu’à zéro, livraison rapide	Moins de contrôle, spécifique au fournisseur, limites de démarrage à froid et de quota

La tension centrale est le contrôle contre le levier, et elle traverse chaque ligne. Plus vous remettez au fournisseur, plus vite vous bougez et moins vous exploitez, au prix d’un couplage plus profond. La résolution n’est pas de choisir un pôle mais de placer chaque charge de travail délibérément : grimpez haut sur le spectre géré pour la plomberie de commodité, restez plus bas là où le contrôle mérite vraiment sa place, et chiffrez l’enfermement dans les deux directions plutôt que de traiter la portabilité comme gratuite et la dépendance comme un péché. Les grandes organisations s’attirent des ennuis quand elles laissent la peur (de l’enfermement, du cloud, du coût) faire ce choix par réflexe au lieu de l’analyse.

Questions à discuter avec votre équipe

Lesquelles de nos charges de travail sont transférées-en-l’état, et payons-nous des prix cloud pour une architecture de centre de données ? Il est courant de migrer sous échéance, de tout réhéberger tel quel, et de déclarer victoire, puis de découvrir que la facture est plus élevée que le centre de données et qu’aucun des bénéfices de résilience ou d’élasticité ne s’est matérialisé. L’audit honnête est de lister vos charges de travail majeures et de marquer chacune comme réhébergée, re-plateformée, ou véritablement reconçue, puis de regarder lesquelles fonctionnent encore sur des empreintes de taille fixe, toujours actives, mono-zone. Un certain transfert-en-l’état est une première étape légitime, donc la question n’est pas si vous l’avez fait mais si vous avez un plan et un calendrier pour aller plus loin. Apportez le coût par charge de travail et l’historique d’incidents, parce que les charges de travail à la fois coûteuses et fragiles sont où la reconception rapporte le plus vite. Si tout ressemble encore à l’ancien centre de données un an après la migration, vous avez acheté un centre de données plus cher.
Quand une zone de disponibilité ou une région entière échoue, que se passe-t-il réellement, et l’avons-nous testé ? De nombreuses équipes croient être résilientes parce qu’elles ont déployé sur un cloud, sans avoir conçu leurs domaines de panne ni jamais avoir débranché pour vérifier. La version concrète : pour chaque système critique, combien de zones couvre-t-il, quel est l’objectif documenté de temps de reprise et de point de reprise, et quand avons-nous pour la dernière fois exécuté une journée de jeu qui a fait échouer une zone ou répété une récupération de région ? Le multi-zone devrait être la base de référence banale, donc toute charge de travail critique mono-zone est une constatation ; le multi-région est une décision plus lourde et plus coûteuse liée à des cibles de récupération explicites, pas adoptée par défaut. Apportez votre carte de dépendances, parce que la panne qui fait mal est généralement un service partagé (une base de données, un fournisseur d’identité) dont personne n’a cartographié le domaine de panne. Une résilience jamais testée est une hypothèse, pas une propriété.
Pour nos plus grandes dépendances fournisseur, que coûterait réellement de partir, et est-ce un prix qui vaut la peine d’être payé pour l’éviter ? Les débats sur l’enfermement tendent à fonctionner sur l’idéologie plutôt que les chiffres, avec un camp abstrayant chaque service géré pour rester portable et un autre ignorant entièrement le risque de concentration. Ancrez-le : choisissez vos trois dépendances les plus profondes, estimez le vrai coût d’ingénierie et le temps écoulé pour remplacer chacune, et pesez cela contre ce que le service vous économise aujourd’hui et à quel point vous êtes susceptible de jamais changer. Ajoutez les risques que la portabilité ne corrige pas, comme un régulateur exigeant une seconde source ou une règle de souveraineté sur où les données peuvent vivre, puisque ceux-là peuvent justifier le multi-cloud ou l’hybride même quand la pure économie ne le ferait pas. L’objectif est une position délibérée et écrite par dépendance, pas une politique générale. Une fois que vous le chiffrez, la plupart de l’enfermement craint s’avère moins cher à accepter que la couche d’abstraction construite pour l’éviter.
Quels services exploitons-nous nous-mêmes que le fournisseur exploiterait volontiers pour nous, et que coûte ce choix en heures-ingénieur ? Tout le levier du cloud est de remettre les correctifs, sauvegardes, basculement, et mise à l’échelle à quelqu’un dont le travail à plein temps est ces choses, pourtant les équipes gardent couramment une base de données, un courtier de message, ou un cluster de recherche auto-exploité par habitude ou fierté mal placée. Pour une grande organisation, le coût n’est pas la corvée d’une équipe mais les mêmes opérations non différenciatrices réinventées dans une douzaine de coins, chacun une rotation d’astreinte et une source de dérive. La considération concurrente est réelle : du matériel spécialisé, des termes de licence, une frontière de conformité inhabituelle, ou une performance qu’une offre gérée ne peut satisfaire peuvent justifier de rester plus bas sur le spectre, donc la réponse est par service plutôt que générale. Apportez un inventaire des services auto-exploités, les heures-ingénieur que chacun consomme en maintenance et incidents, et le prix de l’alternative gérée, et exigez un registre de décision d’architecture pour chaque « nous exploitons le nôtre » qui est rejustifié annuellement. Dans les contextes d’entreprise et gouvernementaux, ajoutez si le choix auto-exploité est réellement une contrainte de conformité ou de licence ou simplement de l’inertie déguisée en une telle, parce que les auditeurs et propriétaires de budget poseront la même question.
Pouvons-nous voir ce que chaque équipe et service nous coûte ce mois-ci, et une personne nommée se sent-elle responsable de ce chiffre ? La dépense cloud gonfle discrètement parce que le même libre-service qui permet à un ingénieur de provisionner une base de données mondiale en minutes lui permet aussi de la laisser fonctionner à taille de pic pour toujours, et aucune ligne de facture unique ne semble jamais alarmante. Dans une grande organisation sans visibilité de coût par équipe et par service, la finance découvre le problème des mois trop tard et la réaction est un gel brutal qui punit les disciplinés aux côtés des gaspilleurs. La tension est réelle : poursuivre chaque dollar ralentit la livraison, donc l’objectif est la responsabilité et le bon dimensionnement, pas l’austérité, avec le coût traité comme un attribut de qualité pour lequel vous concevez plutôt qu’un rapport que vous lisez après coup. Apportez une répartition de coût par équipe, la part de la dépense non étiquetée ou non attribuable, l’utilisation actuelle contre la capacité provisionnée, et où des remises d’usage engagé ou de la capacité spot sont laissées sur la table. Pour les entreprises et organismes gouvernementaux, liez cela à la pratique FinOps et à l’examen des dépenses publiques, puisqu’une ressource non étiquetée n’est pas seulement du gaspillage mais une constatation d’audit qui attend de se produire.
Une équipe peut-elle monter un magasin de données public, un volume non chiffré, ou une ressource dans une région interdite en ce moment, et le saurions-nous même ? La plupart des incidents cloud coûteux sont des mauvaises configurations, pas des violations du fournisseur, et le modèle de responsabilité partagée signifie que le compartiment de stockage qui fuit ou la base de données ouverte à internet sont carrément de votre côté de la ligne. Prévenir cela à l’échelle de nombreuses équipes est une question de zone d’atterrissage : des garde-fous imposés comme politique-en-tant-que-code qui bloquent les configurations interdites avant qu’elles n’existent, plutôt qu’une relecture après coup qui les trouve une fois que les enregistrements ont déjà fui. La pression concurrente est l’autonomie du développeur, parce que des garde-fous trop serrés poussent les équipes vers des comptes de l’ombre, donc la conception doit prévenir ce qui est vraiment dangereux tout en laissant de la place pour bouger. Apportez un inventaire des garde-fous réellement imposés, une tentative honnête de provisionner une ressource non conforme dans un vrai compte, et le délai de détection quand la prévention échoue. Dans les contextes régulés et gouvernementaux, connectez cela à la résidence des données et aux régimes d’autorisation, parce qu’une ressource dans une région non autorisée n’est pas une violation de style mais une infraction légale qu’un auditeur traitera comme un événement à signaler.

Regard sectoriel

Jeune pousse. Allez cloud-natif chez un fournisseur unique dès le premier jour et acceptez l’enfermement délibérément. Fonctionnez sur du sans serveur et des services gérés qui s’échelonnent jusqu’à zéro et laissez deux ingénieurs posséder toute la plateforme, parce que votre ressource la plus rare est l’attention, pas la portabilité. Plafonnez fortement la dépense, gardez tout en infrastructure-en-tant-que-code pour qu’un moment viral ne devienne pas une panne, et consignez la décision d’enfermement délibérée à revisiter à l’échelle plutôt que de prétendre qu’elle est temporaire.

Petite entreprise. Sans ingénieur de plateforme et avec un budget serré, traitez le cloud comme quelque chose que vous consommez plutôt qu’exploitez. Préférez le SaaS et les services entièrement gérés à tout ce que vous exploitez vous-même, appuyez-vous sur les valeurs par défaut sûres du fournisseur, et laissez la base de données gérée gérer les sauvegardes et le basculement pour que personne n’ait à le faire. Cadrez le choix comme acheter-contre-construire avec un fort pouce sur acheter, fixez une alerte de facturation pour qu’une ressource oubliée ne puisse pas drainer le mois, et recourez à une option low-code ou gérée avant de monter des serveurs que vous ne pouvez pas doter en personnel.

Grande entreprise. Votre histoire cloud est une histoire de migration à travers de nombreuses équipes, donc l’architecture est réellement un problème de gouvernance. Montez une zone d’atterrissage gouvernée avec des comptes par unité comme frontières de rayon d’impact et de facturation, des garde-fous chiffrés-par-défaut, et de la politique-en-tant-que-code qui bloque les magasins de données publics, et laissez une équipe de plateforme centrale posséder cette fondation. Exécutez FinOps avec de la refacturation par équipe, conditionnez les conceptions significatives à une relecture bien architecturée, et gérez la connectivité hybride vers les systèmes hérités de référence qui ne bougeront pas pendant des années.

Gouvernement. Les règles d’approvisionnement, la transparence, et la souveraineté façonnent chaque décision. Déployez dans une région cloud autorisée ou gouvernementale, documentez la ligne de frontière de responsabilité partagée pour les auditeurs, et épinglez le stockage et le traitement à des zones dans le pays avec de la politique-en-tant-que-code qui bloque toute ressource dans une région non autorisée. Poursuivez le régime d’autorisation requis, gardez la preuve d’audit comme un historique git plutôt qu’une ruée, et favorisez les services gérés dont le fournisseur attestera la posture de conformité plutôt qu’une infrastructure sur mesure que vous devez certifier vous-même.

Exemples

Jeune pousse. Une start-up de douze personnes construit cloud-natif dès le premier jour chez un fournisseur unique et ne ressent aucune culpabilité à ce sujet. L’API fonctionne sur des fonctions sans serveur qui s’échelonnent jusqu’à zéro la nuit, les données vivent dans un Postgres géré avec sauvegardes automatisées et basculement multi-zone, et les tâches d’arrière-plan fonctionnent sur une file gérée. Tout cela est défini en infrastructure-en-tant-que-code, et deux ingénieurs possèdent toute la plateforme parce que le fournisseur exploite les parties difficiles. Quand un moment viral envoie le trafic cinquante fois plus haut en une heure, la mise à l’échelle automatique l’absorbe et la facture augmente en proportion de l’usage réel, puis baisse de nouveau. Les fondateurs acceptent délibérément l’enfermement comme le prix de bouger vite avec une toute petite équipe, et ils ont consigné cette décision à revisiter à l’échelle.

Grande entreprise. Un assureur multinational avec trois cents applications héritées exécute une migration de plusieurs années gouvernée par les « 6 R » (réhéberger, re-plateformer, racheter, refactoriser, retirer, retenir). Les applications de commodité à faible valeur sont rapidement réhébergées pour sortir de deux centres de données selon une échéance ; la plateforme de police centrale est refactorisée pour être cloud-native ; les outils faits maison sont rachetés comme SaaS ; et les systèmes obsolètes sont retirés. Une équipe de plateforme centrale possède une zone d’atterrissage avec des comptes par unité d’affaires, des garde-fous chiffrés-par-défaut, et de la politique-en-tant-que-code qui bloque les magasins de données publics, pendant que la connectivité hybride relie le cloud aux systèmes mainframe de référence qui ne bougeront pas pendant des années. Le coût est gouverné à travers une pratique FinOps avec refacturation par unité, et une relecture bien architecturée conditionne le lancement en production de chaque application.

Gouvernement. Une agence nationale livrant un service de prestations citoyennes est légalement tenue de garder les données de résidents dans les frontières nationales et d’exploiter sur une infrastructure autorisée. Elle déploie dans la région cloud gouvernementale du fournisseur et poursuit une autorisation sous un régime tel que FedRAMP aux États-Unis (avec le travail de conformité au chapitre 4.6), documentant la ligne de frontière de responsabilité partagée pour les auditeurs. La résidence des données et des préoccupations de souveraineté plus larges (chapitre 10.11) pilotent une architecture qui épingle le stockage et le traitement à des zones dans le pays et bloque, par politique-en-tant-que-code, toute ressource dans une région non autorisée. Le système couvre trois zones de disponibilité avec un plan de récupération inter-zone testé et provisionne tout comme du code, donc la preuve d’audit est un historique git plutôt qu’une ruée.

Argumentaire économique : motivations, retour sur investissement et coût total de possession

La promesse phare du cloud est de transformer la dépense en capital en dépense d’exploitation : au lieu d’acheter des serveurs des années avant la demande et de les exploiter à faible utilisation, vous payez pour ce que vous utilisez et échelonnez avec l’affaire. C’est réel, mais le retour plus profond est la vitesse et la concentration. Un service géré qui efface les correctifs, sauvegardes, et le basculement remet ces heures-ingénieur au travail produit, et provisionner en minutes plutôt qu’en mois compresse le temps de l’idée à la production. L’élasticité signifie que vous cessez de payer pour une capacité de pic que vous utilisez deux fois par an. Quand l’architecture est correcte, cela se compose en un coût total de possession qui bat le centre de données à la fois en coût et en capacité.

Le coût de mal faire est également réel, donc l’argumentaire économique doit être honnête. Le transfert-en-l’état sans reconception augmente souvent les coûts tout en ne livrant aucun des bénéfices, et une dépense non gouvernée peut gonfler discrètement à travers des dizaines d’équipes jusqu’à ce que la finance tire la sonnette d’alarme. Cadrez le dossier pour la direction autour de trois leviers : la vitesse (livraison plus rapide et provisionnement plus court), la résilience (moins d’incidents majeurs et plus courts), et l’optionalité (entrer sur un nouveau marché ou une nouvelle région sans un projet de centre de données). Mettez des chiffres sur le renouvellement de centre de données évité, la réduction d’effectif pour l’infrastructure de commodité, et les minutes de panne évitées, et opposez-les au coût de migration et à l’investissement continu FinOps et de plateforme. L’argument le plus fort est rarement l’économie de coût brute ; c’est la valeur d’option de bouger plus vite que les concurrents encore en attente de matériel.

Anti-patterns et pièges

Transfert-en-l’état et l’appeler « cloud ». Réhéberger une conception de centre de données sur de l’infrastructure louée capture les coûts et aucun des bénéfices.
Infrastructure cliquée en console. Les ressources créées à la main sont non répétables, non documentées, et impossibles à récupérer ou auditer ; traitez tout changement manuel de production comme un défaut.
Multi-cloud culte du cargo. Exécuter la même charge de travail à travers deux fournisseurs pour couvrir un risque rare, payant en complexité et conception au plus petit dénominateur commun chaque jour.
« Haute disponibilité » mono-zone. Croire que le cloud est résilient par défaut tout en exploitant des charges de travail critiques dans une zone sans basculement testé.
Mal lire la responsabilité partagée. Supposer que le fournisseur sécurise ce que vous possédez réellement, le chemin classique vers un compartiment public qui fuit des millions d’enregistrements.
Le coût comme réflexion après coup. Concevoir sans égard à la dépense, puis découvrir que la facture a pris vos décisions architecturales à votre place.

Modèle de maturité

Niveau 1 (Initier) : L’usage du cloud est ad hoc et réactif. Les équipes cliquent des ressources en existence dans des comptes partagés, les charges de travail sont transférées-en-l’état, et il n’y a pas de zone d’atterrissage, pas de visibilité de coût, et la résilience est supposée plutôt que conçue. La première panne sérieuse ou choc de facture est une surprise.
Niveau 2 (Développer) : Des pratiques de base apparaissent mais varient par équipe. Une partie de l’infrastructure centrale est provisionnée comme du code et certaines charges de travail fonctionnent multi-zone, quelques comptes sont séparés, mais la couverture est inégale : les choix de modèle de service et d’enfermement sont faits par habitude, le coût est surveillé après coup, les garde-fous sont incohérents, et la récupération multi-région n’est pas testée.
Niveau 3 (Standardiser) : Une zone d’atterrissage gouvernée avec des garde-fous de politique-en-tant-que-code est documentée et imposée à l’échelle de l’organisation. Une équipe de plateforme possède la fondation, tout ce qui est en production est provisionné comme du code, les relectures bien architecturées conditionnent les conceptions significatives, et les décisions acheter-contre-construire et de domaine de panne sont délibérées et enregistrées de façon cohérente à travers chaque équipe.
Niveau 4 (Gérer) : Le parc est mesuré et contrôlé par rapport à des références. Le coût par équipe et par service est suivi à travers FinOps contre des cibles, les objectifs de temps de reprise et de point de reprise sont vérifiés plutôt qu’affirmés, les violations de garde-fou et la dérive de configuration sont révélées comme métriques, le bon dimensionnement est piloté par des données d’utilisation, et chaque décision de feu vert ou non est étayée par des preuves des tableaux de bord de coût, de fiabilité, et de sécurité.
Niveau 5 (Orchestrer) : L’architecture cloud est continuellement améliorée et intégrée à la planification d’affaires et de risque. Les domaines de panne sont exercés à travers des journées de jeu routinières, le bon dimensionnement et la tarification sont automatisés, la souveraineté et la résidence sont imposées par politique, les positions de modèle de service et d’enfermement sont rechiffrées selon une cadence régulière, et le portefeuille de charges de travail est rééquilibré de façon adaptative à mesure que le marché, la tarification, et le tableau de risque changent.

Pistes de réflexion

Où sur le spectre IaaS-vers-sans-serveur se trouve chacune de vos charges de travail majeures, et l’une d’elles pourrait-elle grimper plus haut pour se délester de corvée opérationnelle sans perdre un contrôle dont vous avez réellement besoin ?
Si votre fournisseur principal augmentait fortement les prix ou souffrait d’une panne régionale de plusieurs jours, quel est votre vrai plan, et justifie-t-il une complexité multi-cloud ou hybride que vous portez ?
Qui possède votre zone d’atterrissage et ses garde-fous, et une équipe peut-elle livrer une ressource non conforme (magasin de données public, volume non chiffré, région interdite) aujourd’hui ?
Pour une charge de travail régulée ou souveraine, pouvez-vous produire la frontière de responsabilité partagée et la configuration autorisée comme preuve sans exercice d’incendie ?

Points clés à retenir

Concevez pour le cloud plutôt que de photographier votre centre de données ; l’élasticité, les services gérés, et la conscience des domaines de panne sont les raisons d’être ici.
Grimpez le spectre de modèle de service vers géré et sans serveur pour le travail de commodité, et gardez le contrôle plus bas seulement là où il mérite vraiment son coût.
Rendez les régions et zones de disponibilité des domaines de panne explicites : multi-zone comme référence, multi-région lié à des cibles de récupération testées.
Provisionnez tout comme du code à l’intérieur d’une zone d’atterrissage gouvernée avec des garde-fous de politique-en-tant-que-code, des comptes séparés, et une équipe de plateforme qui possède la fondation.
Chiffrez honnêtement l’enfermement fournisseur dans les deux directions, et soyez sceptique envers le multi-cloud à moins qu’une raison réglementaire, de souveraineté, ou meilleure-de-sa-catégorie concrète ne l’exige.
Traitez le coût comme un attribut de qualité de premier ordre à travers FinOps, et menez des relectures bien architecturées pour attraper les compromis que vous avez manqués.

Références et lectures complémentaires

Peter Mell et Timothy Grance, The NIST Definition of Cloud Computing (NIST Special Publication 800-145)
Amazon Web Services, AWS Well-Architected Framework
Microsoft, Azure Well-Architected Framework et Cloud Adoption Framework
Google Cloud, Google Cloud Architecture Framework
Stephen Orban, Ahead in the Cloud: Best Practices for Navigating the Future of Enterprise IT (et les stratégies de migration des « 6 R »)
J.R. Storment et Mike Fuller, Cloud FinOps: Collaborative, Real-Time Cloud Financial Management
Gregor Hohpe, Cloud Strategy: A Decision-Based Approach to Successful Cloud Migration
U.S. General Services Administration, documentation du programme FedRAMP et référentiels de sécurité
Cloud Security Alliance, Security Guidance for Critical Areas of Focus in Cloud Computing