L'architecte landing zone travaille pour toutes les équipes à la fois. Il décide comment les comptes AWS, les abonnements Azure ou les projets GCP sont rangés, quelles règles s'appliquent à chaque branche, par où passe le trafic réseau et où partent les journaux. Il s'appuie sur Organizations et Control Tower chez AWS, sur l'accélérateur Azure Landing Zones et ses modules Terraform ou Bicep chez Microsoft, sur Cloud Foundation Fabric chez Google.
Beaucoup de CV citent une landing zone déployée avec l'accélérateur par défaut. C'est un bon début, et la difficulté arrive ensuite : une policy qui bloque un projet en production, une exception à accorder sans ouvrir de brèche, un compte à livrer en une journée au lieu de trois semaines, une mise à jour du socle qui ne doit casser aucun compte existant. Les profils venus de la sécurité connaissent bien les garde-fous et moins le réseau. Les anciens ingénieurs réseau, c'est souvent l'inverse.
Le candidat dessine la hiérarchie qu'il a mise en place, avec le nombre de comptes, les règles posées à chaque niveau et ce qu'il changerait aujourd'hui. On voit vite s'il a fait vivre un socle ou s'il a seulement installé un modèle. Le cas pratique du PDF part de 40 comptes AWS créés à la main.
Les briques d'une landing zone chez AWS, Azure et Google
AWS Organizations et Control Tower
Organizations range les comptes AWS en unités organisationnelles (OU). Control Tower construit par-dessus une landing zone avec un compte de journaux, un compte d'audit et des contrôles préventifs, détectifs ou proactifs. Account Factory crée les comptes, et sa variante Account Factory for Terraform (AFT) le fait depuis un pipeline.
SCP, RCP et politiques déclaratives
Trois types de garde-fous chez AWS. Les SCP plafonnent ce que les identités d'un compte peuvent faire, les RCP plafonnent l'accès aux ressources, même pour un appelant extérieur. Les politiques déclaratives fixent la configuration d'un service, par exemple le blocage de l'accès public aux VPC. Aucune de ces politiques n'accorde de droit.
Azure Landing Zones
Le modèle de Microsoft dans le Cloud Adoption Framework. Des groupes d'administration séparent la plateforme (sécurité, gestion, identité, connectivité) des charges applicatives, rangées en Corp, Online ou Local, avec un bac à sable et une branche pour les abonnements à fermer. L'accélérateur déploie l'ensemble en Terraform ou en Bicep à partir des Azure Verified Modules.
Azure Policy
Le moteur de règles d'Azure, assigné au niveau des groupes d'administration. Une policy peut refuser (deny), auditer ou corriger après coup (deployIfNotExists, modify). Les exemptions et le passage de l'audit au deny se gèrent ici, et c'est souvent là que naissent les frictions avec les équipes projet.
Hiérarchie GCP et organization policies
Chez Google, l'organisation contient des dossiers, qui contiennent des projets. Les organization policies, y compris les contraintes personnalisées, restreignent les régions, les clés de comptes de service ou les IP publiques. Cloud Foundation Fabric et ses étapes FAST fournissent un socle en Terraform, de l'organisation jusqu'à la fabrique de projets.
Réseau central
La connectivité est le plus souvent centralisée dans un compte ou un abonnement dédié : hub avec pare-feu, sorties internet, liens vers le datacenter, DNS privé. Transit Gateway ou Cloud WAN chez AWS, hub-and-spoke ou Virtual WAN chez Azure, Shared VPC et Network Connectivity Center chez Google. Le plan d'adressage IP se décide à ce stade, avant le premier compte.
Journalisation et sécurité centralisées
Trail CloudTrail d'organisation, Security Hub et GuardDuty chez AWS, journaux d'activité et Defender for Cloud chez Azure, Security Command Center et journaux agrégés chez Google. Les journaux partent vers un compte que les équipes projet ne peuvent pas modifier, avec une durée de conservation fixée.
Vending et landing zone as code
La création d'un compte ou d'un abonnement à la demande, livré avec son réseau, ses droits, son budget et ses tags. Elle passe par un pipeline (AFT, module de subscription vending, project factory) et un état Terraform. Le reste du socle suit le même chemin, avec revue de code et tests des policies avant déploiement.
Le poste existe surtout, au sein d'une équipe plateforme ou d'un centre d'excellence cloud (CCoE), dans les organisations qui gèrent des dizaines ou des centaines de comptes cloud, et chez les ESN et cabinets qui y conduisent des programmes d'adoption. L'architecte landing zone travaille avec le RSSI sur les garde-fous, avec l'équipe réseau sur la connectivité au datacenter, avec la finance sur les budgets et les tags, et avec les équipes projet, qui sont ses clients. Certaines missions partent d'un socle vierge, d'autres reprennent une organisation construite à la main au fil des projets. Les certifications AWS Solutions Architect Professional, AZ-305 ou Google Professional Cloud Architect attestent la connaissance d'un cloud. La conduite d'un socle dans la durée se vérifie en entretien.
Ce que l'architecte landing zone doit savoir faire
- Découpage des comptes et hiérarchie
- Garde-fous préventifs et détectifs
- Réseau central et plan d'adressage
- Identité et accès à l'échelle de l'organisation
- Journalisation et détection centralisées
- Vending et landing zone as code
Cinq questions sur le socle commun
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Vous reprenez une organisation AWS de 40 comptes, tous rangés à la racine. Comment les répartissez-vous en OU ?
Une bonne réponsePar type de contrôle à appliquer plutôt que par organigramme : une OU Security pour les comptes de journaux et d'audit, une OU Infrastructure pour le réseau partagé, des OU Workloads séparées entre production et hors production, une Sandbox à budget plafonné, une OU Suspended pour les comptes à fermer. Il déplace les comptes par lots, après avoir vérifié l'effet des SCP de chaque OU sur les comptes déplacés.
Signal d'alerteUne OU par direction ou par filiale, qui oblige à dupliquer les mêmes règles partout. Ou tout laisser à la racine avec des règles posées compte par compte.
Question 2 · senior
Quelle différence faites-vous entre une SCP, une RCP et une politique déclarative sur AWS ?
Une bonne réponseLa SCP plafonne les actions des identités du compte (utilisateurs et rôles). La RCP plafonne l'accès aux ressources du compte, y compris pour un appelant d'une autre organisation. Aucune des deux n'accorde de droit, et ni l'une ni l'autre ne s'applique au compte de gestion ou aux rôles liés aux services. La politique déclarative fixe la configuration d'un service, comme le blocage de l'accès public aux VPC ou la liste des AMI autorisées, et reste appliquée quand le service ajoute de nouvelles API.
Signal d'alerte« Une SCP donne des droits aux comptes », ou ne connaître que les SCP en 2026.
Question 3 · senior
Le réseau central doit être prêt avant le premier compte. Que décidez-vous à ce stade, et qu'est-ce qui sera difficile à changer ensuite ?
Une bonne réponseLe plan d'adressage IP global, sans chevauchement avec le datacenter et réservé par région et par environnement ; la topologie (Transit Gateway ou Cloud WAN, hub-and-spoke ou Virtual WAN, Shared VPC) ; le compte ou l'abonnement de connectivité ; le modèle de sortie internet ; les régions retenues ; le DNS privé. Le plan d'adressage et la topologie sont les plus coûteux à changer une fois des dizaines de comptes raccordés, alors il les fixe en premier.
Signal d'alerteLaisser chaque équipe choisir ses plages IP et décider de la topologie plus tard.
Question 4 · confirmé
Une équipe attend trois semaines pour obtenir un compte cloud. Comment ramenez-vous ce délai à une journée ?
Une bonne réponseUn vending automatisé : une demande sous forme de fichier dans un dépôt Git ou de formulaire (nom, environnement, budget, propriétaire, besoin réseau), puis un pipeline qui crée le compte ou l'abonnement, le range dans la bonne branche, attribue une plage IP, raccorde le réseau, pose les droits des groupes, le budget et les tags. Sur AWS, Account Factory for Terraform ; sur Azure, le module de subscription vending ; sur GCP, une project factory. L'approbation reste humaine quand le réseau ou le budget sort du standard.
Signal d'alerteUn ticket traité à la main par l'équipe cloud, avec une checklist dans un wiki.
Question 5 · confirmé
Une nouvelle Azure Policy en deny bloque le déploiement d'une équipe en pleine mise en production. Que faites-vous, et qu'auriez-vous dû faire avant ?
Une bonne réponseSur le moment, une exemption tracée, limitée dans le temps et au périmètre de l'équipe, plutôt que le retrait de la policy pour tout le monde. Avant, il aurait déployé la policy en mode audit pour mesurer les ressources non conformes, prévenu les équipes concernées avec une date de bascule, puis passé en deny. Il ajoute des tests de policies dans le pipeline du socle.
Signal d'alerteDésactiver la policy à la racine sans date de remise en place, ou croire qu'un rôle Owner suffit à passer outre un deny.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Architecte landing zone, les questions fréquentes
Architecte landing zone et architecte cloud, est-ce le même poste ?
Les deux titres se recouvrent souvent dans les offres. L'architecte cloud conçoit en général l'architecture d'applications : choix des services, haute disponibilité, coût d'une charge. L'architecte landing zone travaille sur ce que toutes les applications partagent : comptes, hiérarchie, garde-fous, réseau central, identité et journaux. Ses clients sont les équipes projet. La description de mission tranche : si elle parle de vending, de policies et de CCoE, c'est le second profil.
Un candidat doit-il connaître AWS, Azure et GCP ?
Rarement les trois en profondeur. Les principes se transposent bien d'un cloud à l'autre : découpage en comptes ou abonnements, héritage des règles, réseau en étoile, journaux centralisés. Les outils changent beaucoup, et une erreur dans une SCP ou une Azure Policy se paie vite. La maîtrise du cloud principal de l'organisation est attendue, avec la capacité à expliquer ce qui change sur un second. Un profil multicloud superficiel est plus risqué qu'un expert d'un seul cloud.
Quel test technique est donné à un architecte landing zone ?
Un exercice de conception de 30 à 45 minutes apprend plus qu'un QCM. Le candidat reçoit une organisation existante, avec ses comptes et ses contraintes, et propose la hiérarchie cible, les garde-fous posés à chaque niveau et le parcours d'un nouveau compte. Une SCP ou une Azure Policy à relire, avec une erreur volontaire, complète l'exercice. Un candidat expérimenté repère l'erreur et pose des questions sur les exceptions avant de proposer une solution.
Quelles certifications regarder sur un CV d'architecte landing zone ?
AWS Solutions Architect Professional, Azure Solutions Architect Expert (AZ-305) ou Google Professional Cloud Architect attestent la connaissance d'un cloud. AWS Security Specialty et les certifications Terraform de HashiCorp complètent bien le profil. Aucune ne prouve que la personne a fait vivre un socle plusieurs années, avec des équipes qui demandent des exceptions. Le nombre de comptes gérés, le rythme des changements du socle et un incident causé par une policy en disent davantage.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
