Questions d'entretien Architecte cloud

La haute disponibilité et la reprise après sinistre sont des préoccupations liées mais distinctes, et je les conçois séparément. Pour la HA, je pars d'un déploiement multi-AZ comme référence pour toute charge de travail de production : aucun composant ne devrait avoir un point de défaillance unique dans une région. J'utilise des services gérés là où ils gèrent nativement la HA, comme RDS Multi-AZ, ECS avec ALB et S3. Je définis des SLOs dès le départ (typiquement 99,9 % ou 99,95 %) et travaille à rebours pour déterminer quel niveau de redondance justifie le coût. Pour la DR, je définis les objectifs RTO et RPO avec les parties prenantes avant de toucher à l'infrastructure. Une charge de travail avec un RTO de quatre heures est très différente d'une avec quinze minutes : la première peut utiliser des snapshots quotidiens vers une région secondaire, tandis que la seconde nécessite une réplication quasi-temps réel et un standby actif. J'organise aussi des exercices DR trimestriels, car un plan de récupération non testé n'est pas un plan.

Le contrôle des coûts à grande échelle est autant un problème organisationnel que technique. Côté technique, j'implémente des politiques de taggage appliquées à la création du compte pour que chaque ressource ait un centre de coût, une équipe et une balise d'environnement dès le premier jour. J'utilise AWS Cost Explorer ou GCP Billing avec des alertes budgétaires par équipe, donnant aux ingénieurs une visibilité sur ce que leurs charges coûtent en quasi-temps réel. Je lance aussi une vérification hebdomadaire Trusted Advisor ou Recommender pour identifier les ressources sous-utilisées et les opportunités de dimensionnement. Côté organisationnel : j'encourage un modèle où chaque équipe possède ses dépenses cloud et dispose d'une revue mensuelle. Cela crée de la responsabilité sans nécessiter un contrôleur central. J'ai vu des programmes FinOps bien gérés réduire les dépenses cloud de 30 à 40 % en six mois sans régression de performance.

Le zero-trust part du principe qu'aucun emplacement réseau n'est intrinsèquement fiable, ce qui signifie passer des contrôles basés sur le périmètre à des contrôles basés sur l'identité et le contexte. En pratique, cela signifie remplacer les accès VPN par des proxys conscients de l'identité comme Google BeyondCorp ou AWS Verified Access, appliquer des politiques IAM avec le moindre privilège et des revues d'accès régulières, et chiffrer les données en transit et au repos par défaut. J'utilise les SCPs AWS ou les Org Policies GCP pour imposer des garde-fous au niveau du compte afin qu'aucune équipe ne puisse accidentellement ouvrir un bucket S3 public ou désactiver CloudTrail. Je sépare aussi les charges de travail dans des comptes différents par frontière de sécurité, pas seulement par environnement. La gestion des secrets passe par Secrets Manager ou Vault, avec des politiques de rotation qui rendent impossibles les identifiants à longue durée de vie.

Cette décision doit être guidée par le risque business, le calendrier et le coût final d'exploitation de la charge dans chaque état, et non par une préférence générale pour une approche. Le lift-and-shift est la bonne première étape quand l'objectif principal est de quitter un centre de données dans un délai fixe, quand l'application est stable et peu changeante, ou quand l'équipe manque d'expertise cloud-native pour re-architecturer en toute sécurité. La re-architecture cloud-native est pertinente quand la charge a des schémas de charge variable que le serverless ou la conteneurisation serviraient mieux, ou quand le coût opérationnel d'exécution de la version liftée sur des VMs cloud est comparable ou supérieur à l'on-premise. Je recommande généralement une approche par phases : lifter d'abord, puis re-architecturer les composants où le bénéfice de coût ou opérationnel est le plus clair, en laissant les services stables à faible trafic tels quels.

J'ai dirigé la migration d'un ERP monolithique legacy vers AWS pour un client manufacturier. L'application n'avait pas été modifiée depuis sept ans et avait des dépendances non documentées sur des lecteurs réseau et des objets COM locaux. Nous les avons découvertes lors de la migration pilote de la première unité commerciale. Plutôt que de tout corriger avant de migrer, j'ai introduit un pattern strangler-fig : nous avons lifté le monolithe vers une flotte EC2 derrière un ALB, puis identifié les trois composants les plus sensibles au réseau et les avons remplacés par des équivalents AWS gérés sur douze semaines. Nous avons aussi découvert que l'application écrivait des fichiers temporaires dans un chemin local codé en dur : nous l'avons détecté en staging grâce à une couche d'émulation de système de fichiers réseau. La migration s'est terminée dans les délais et le client a bénéficié d'une réduction de 22 % des coûts d'infrastructure dans le premier trimestre complet sur cloud.

Une équipe de développement voulait stocker tout l'état de session dans un grand cluster ElastiCache sans réplication, pour économiser des coûts. L'application était orientée grand public et la perte de ce cache déconnecterait tous les utilisateurs actifs. J'ai construit un modèle de coût montrant que la différence entre un cluster à nœud unique et un répliqué était inférieure à 400 $ par mois, contre une perte de revenus projetée d'environ 12 000 $ par heure d'indisponibilité selon le volume de transactions. J'ai présenté cela non pas comme une opinion d'architecture mais comme un calcul risque/coût, en encadrant la question de la réplication comme une décision business pour le product owner avec toutes les informations. L'équipe a accepté la configuration répliquée et nous avons aussi ajouté un chemin d'expiration de session gracieux pour que les futures pannes de cache déclenchent un flux de ré-authentification plutôt qu'une déconnexion brutale.

J'ai rejoint une équipe dépensant environ 180 000 $ par mois sur AWS. La première chose que j'ai faite était de générer une analyse Cost Explorer par service et par balise, qui a révélé que 34 % des dépenses concernaient des instances EC2 fonctionnant en moyenne à moins de 15 % d'utilisation CPU. 12 % supplémentaires provenaient de frais de transfert de données causés par une architecture qui routait tout le trafic inter-services à travers une NAT Gateway plutôt que d'utiliser des VPC endpoints pour S3 et DynamoDB. J'ai redimensionné les instances sous-utilisées en utilisant les recommandations de Compute Optimizer, réduisant les dépenses EC2 de 28 %. J'ai remplacé le routage NAT Gateway par des VPC endpoints, éliminant entièrement le coût de transfert. J'ai aussi converti les dépenses on-demand des charges stables en Compute Savings Plans. La réduction totale est passée de 180 000 $ à environ 98 000 $ par mois en trois mois.

Mon approche standard est Terraform avec une architecture basée sur des modules, où les primitives d'infrastructure partagées (VPCs, rôles IAM, groupes de sécurité) vivent dans une bibliothèque de modules centrale et les équipes individuelles les consomment comme dépendances. J'utilise Terragrunt pour gérer la configuration entre environnements, en gardant les valeurs spécifiques à l'environnement dans des fichiers YAML et le code Terraform lui-même indépendant de l'environnement. L'état est stocké dans S3 avec verrouillage DynamoDB et un bucket d'état séparé par environnement et compte. La CI/CD exécute terraform plan sur chaque PR, publiant la sortie du plan comme commentaire pour revue avant tout apply. Pour les équipes nouvelles à l'IaC, j'implémente une couche policy-as-code avec Open Policy Agent ou Checkov pour détecter les mauvaises configurations de sécurité avant qu'elles n'atteignent la revue de code.

Le multi-cloud est souvent proposé comme stratégie de gestion des risques mais il introduit ses propres risques : complexité opérationnelle, fragmentation des compétences et coût total de possession plus élevé. Je conseille aux clients de distinguer le vrai multi-cloud (charges de travail actives sur deux fournisseurs ou plus simultanément) de la portabilité cloud (construction sans créer de dépendance forte). Pour la plupart des organisations, la portabilité cloud via la conteneurisation et des couches de données abstraites est la bonne réponse : elle préserve les options sans payer le coût opérationnel de la gestion de deux environnements cloud au quotidien. Le vrai multi-cloud a du sens dans trois scénarios : exigences réglementaires mandatant la diversité des fournisseurs, acquisitions où l'intégration de l'infrastructure coûterait plus que la gestion de deux estates, et services spécifiques où un fournisseur est clairement supérieur pour une charge particulière.

Le point de départ est de cartographier le budget de latence : quel est le temps de réponse maximum acceptable pour la requête utilisateur, et comment se répartit-il entre transit réseau, calcul et stockage ? Pour une application distribuée mondialement, j'utiliserais un CDN comme CloudFront ou Fastly pour les assets statiques et les réponses API cachables en périphérie, en plaçant le calcul dans trois à quatre régions sélectionnées selon la géographie des utilisateurs. Le routage API passe par un équilibreur de charge global comme AWS Global Accelerator ou GCP Global LB, dirigeant les requêtes vers la région saine la plus proche. Pour la couche de données, la décision dépend des exigences de cohérence : si la cohérence éventuelle est acceptable, DynamoDB Global Tables ou Spanner fournissent des lectures à faible latence mondialement. Si une cohérence forte est requise, je maintiens une seule région primaire avec des réplicas de lecture dans les régions secondaires. J'implémenterais aussi des circuit breakers à la frontière régionale.