Comment approchez-vous la conception pour la haute disponibilité et la reprise après sinistre dans le 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.

Comment gérez-vous les coûts cloud à grande échelle sans ralentir les équipes engineering ?

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.

Quelle est votre approche de la sécurité cloud, et comment implémentez-vous un modèle zero-trust ?

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.

Comment décidez-vous entre une migration lift-and-shift et une re-architecture cloud-native ?

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.

Parlez-moi d'une migration cloud complexe que vous avez dirigée. Qu'est-ce qui a mal tourné et comment avez-vous géré la situation ?

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.

Décrivez une situation où vous avez dû vous opposer à une équipe qui voulait construire quelque chose d'une manière que vous jugiez architecturalement non saine.

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.

Donnez un exemple où vous avez significativement réduit les coûts d'infrastructure cloud.

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.

Comment implémentez-vous l'infrastructure as code sur plusieurs environnements et équipes ?

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.

Comment abordez-vous la stratégie multi-cloud, et quand est-ce que cela a du sens ?

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.

Expliquez-moi comment vous architectureriez une application distribuée mondialement à faible latence.

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.

Architecte cloud

Les entretiens pour un poste d'architecte cloud évaluent votre capacité à concevoir une infrastructure sécurisée, rentable et résiliente à grande échelle. Les recruteurs testent vos connaissances sur AWS, GCP et Azure, vos pratiques d'infrastructure-as-code et votre expérience dans la conduite de migrations et de stratégies multi-cloud. Ce guide couvre les questions les plus fréquentes et les réponses qui signalent une vraie expérience d'architecture plutôt que de simples connaissances de certification.

Pour des conseils généraux de préparation aux entretiens, consultez notre guide sur les questions d'entretien courantes.

Aller plus loin

Réussir l'entretien comportemental (méthode STAR)Comment se préparer à un entretien technique

Questions d'entretien courantes pour Architecte cloud

Questions comportementales pour les postes Architecte cloud

Questions techniques pour les candidats Architecte cloud

Ce que les recruteurs recherchent pour un poste Architecte cloud

Ce que les recruteurs cherchent vraiment chez les candidats architecte cloud :

Une large couverture des fournisseurs, avec une profondeur dans au moins un. Vous n'avez pas besoin d'être expert en AWS, GCP et Azure simultanément, mais vous devez être à l'aise avec les trois et avoir une expérience pratique approfondie sur votre plateforme principale.
Un focus sur l'impact business. Les meilleurs architectes traduisent les décisions d'infrastructure en termes de coût, risque et revenus. Les réponses purement techniques sans contexte business ne convainquent pas.
La sécurité par défaut, pas comme réflexion après coup. Mentionnez les SCPs, le moindre privilège et le chiffrement tôt dans vos réponses, pas seulement quand on vous demande directement la sécurité.
La maîtrise de l'IaC. Terraform est le standard de facto. Les candidats qui n'ont pas utilisé l'IaC en production à grande échelle auront du mal dans les équipes cloud modernes.
L'honnêteté sur les compromis. Les recruteurs se méfient des architectes qui prétendent que chaque problème a une solution propre. Montrez que vous pouvez raisonner sur les compromis et faire des choix défendables dans l'incertitude.

Questions à poser à votre interlocuteur

→Quelle est la maturité cloud actuelle de l'organisation, et où se trouvent les plus grandes lacunes architecturales ?
→Comment la fonction d'architecture cloud est-elle structurée : les architectes sont-ils intégrés dans les équipes ou opèrent-ils comme une guilde centrale ?
→Quel est l'état actuel d'adoption de l'IaC, et quelle proportion de l'infrastructure est encore gérée manuellement ?
→Comment l'organisation gère-t-elle la gouvernance des coûts cloud, et quelle visibilité ont les équipes individuelles sur leurs propres dépenses ?
→Quels sont les plus grands défis d'infrastructure à venir que l'équipe planifie pour les 12 prochains mois ?

Entrainez-vous sur ces questions avant votre entretien

Le simulateur d'entretien construit une session de pratique autour d'une offre d'emploi spécifique et de votre parcours, pour que vous répétiez les questions les plus susceptibles d'être posées.

Commencer l'entrainement

Gratuit pour commencer. Sans engagement.

Métiers similaires

Ingénieur DevOps

Tech9 questions

Responsable informatique

Tech9 questions

Ingénieur logiciel

Tech10 questions