Azure Landing Zones : ce que j'aurais voulu savoir avant de déployer Enterprise-Scale

Microsoft vient de publier l’architecture Enterprise-Scale dans le cadre du Cloud Adoption Framework. C’est la fondation Azure la plus aboutie et la plus opiniâtre qu’ils aient jamais publiée. Une hiérarchie complète de Management Groups, une gouvernance pilotée par les policies, un réseau hub-spoke, une centralisation des logs et une isolation de l’identité, le tout câblé ensemble et soutenu par des implémentations de référence que vous pouvez déployer dès aujourd’hui.

Après avoir implémenté cette architecture pour plusieurs organisations ces derniers mois (nous avions un accès anticipé via le programme de partenaires de conception), voici ce que j’aurais aimé qu’on me dise avant le premier déploiement.

Ce qu’Enterprise-Scale vous apporte concrètement

L’architecture n’est pas un schéma à admirer. C’est un framework déployable qui provisionne :

• Une hiérarchie de Management Groups qui sépare les préoccupations de plateforme (identité, gestion, connectivité) des landing zones applicatives
• Des assignments Azure Policy qui imposent des garde-fous de gouvernance depuis la racine : interdire les IP publiques sur les NIC, forcer le chiffrement des disques, exiger le tagging des ressources
• Un réseau hub-spoke avec DNS centralisé, firewall et infrastructure de gateway
• Une centralisation des logs via un workspace Log Analytics de plateforme, avec des diagnostic settings qui remontent depuis chaque subscription
• Des patterns de subscription vending qui vous permettent de distribuer des subscriptions préconfigurées aux équipes applicatives

Ce n’est pas un livre blanc. C’est de l’infrastructure as code que vous déployez, et ça fonctionne. Mais “ça fonctionne” et “ça fonctionne pour votre organisation” sont deux choses différentes.

Azure docs : Enterprise-Scale architecture · Design principles

La hiérarchie de Management Groups : suivez-la jusqu’à ce que vous ayez une raison de ne pas le faire

La hiérarchie recommandée ressemble à ceci :

Tenant Root Group
└── Votre Organisation
    ├── Platform
    │   ├── Identity
    │   ├── Management
    │   └── Connectivity
    ├── Landing Zones
    │   ├── Corp (workloads internes)
    │   └── Online (workloads exposés à Internet)
    ├── Sandbox
    └── Decommissioned

Chaque fois que j’ai vu quelqu’un essayer d‘“améliorer” cette hiérarchie dès le premier jour, en ajoutant des niveaux supplémentaires pour les business units, les régions géographiques ou les centres de coûts, il l’a regretté en quelques mois. Les Management Groups sont des frontières de gouvernance, pas des organigrammes. Si vous empilez six niveaux parce que votre entreprise a six divisions, vous vous retrouvez avec des chaînes d’héritage de policies que personne ne peut déboguer et des assignments RBAC qui se contredisent.

Commencez avec la hiérarchie de référence. N’ajoutez un niveau que lorsque vous avez une exigence concrète de policy ou de RBAC qui ne peut pas être résolue autrement. La plupart des organisations n’ont besoin que d’un seul niveau supplémentaire sous Landing Zones, et même celui-là est souvent superflu.

Le Management Group Sandbox mérite une mention. Il se situe en dehors de la branche Landing Zones, ce qui signifie qu’il hérite d’un minimum de policies. C’est intentionnel. Donnez aux développeurs une subscription sous Sandbox avec une alerte de budget et des garde-fous assouplis. Ils peuvent expérimenter librement sans déclencher de violations de policies. Quand le workload est prêt pour la production, il migre vers une subscription Landing Zone avec une gouvernance complète. Ce pattern élimine 80 % des plaintes “Azure Policy bloque mon déploiement”.

Azure docs : Management Group hierarchy · Subscription organisation

Azure Policy : votre outil le plus puissant et votre plus grand piège

Enterprise-Scale est livré avec un ensemble sélectionné d’assignments de policies. Les plus importantes :

• Interdire les adresses IP publiques sur les interfaces réseau, ce qui force le trafic à passer par le réseau centralisé
• Imposer le chiffrement au repos pour les storage accounts et les managed disks
• Exiger des tags spécifiques sur les resource groups (centre de coûts, environnement, propriétaire)
• Déployer automatiquement les diagnostic settings vers le workspace Log Analytics central
• Auditer ou interdire les SKU non conformes pour contrôler les coûts et la posture de sécurité

Ces policies sont correctes sur le principe. Le problème, c’est le timing. Si vous activez toutes les policies au niveau du Management Group racine dès le premier jour, vous allez bloquer des déploiements légitimes d’équipes en pleine migration. Un développeur qui essaie de déployer une preuve de concept va se heurter à un mur de refus, escalader vers l’équipe plateforme, et votre framework de gouvernance soigneusement conçu sera perçu comme un obstacle plutôt qu’un garde-fou.

L’approche pragmatique : déployez les policies en mode Audit d’abord. Laissez-les remonter les non-conformités pendant deux à quatre semaines. Consultez le tableau de bord de conformité. Identifiez quelles violations sont de vrais risques et lesquelles sont des patterns attendus qui nécessitent des exemptions. Ensuite, passez en mode Deny, avec les exemptions déjà en place.

Les exemptions de policies ne sont pas un signe de faiblesse. C’est le mécanisme qui rend la gouvernance viable. Un storage account qui a besoin d’un accès blob public pour servir d’origine CDN n’est pas une défaillance de policy, c’est une exception documentée avec une justification métier. Intégrez le processus d’exemption dans votre modèle opérationnel dès le départ.

Azure docs : Policy-driven governance · Azure Policy exemption structure

Réseau : Hub-Spoke vs Virtual WAN

Enterprise-Scale supporte les deux topologies. Le choix compte plus qu’on ne le pense.

Hub-spoke avec Azure Firewall est le bon choix par défaut pour la plupart des organisations. Vous gardez le contrôle total sur le routage, vous pouvez faire du peering direct entre les spokes si nécessaire, et le modèle réseau est compris par tous les ingénieurs. Le hub VNet est le vôtre : vous décidez de ce qui s’y trouve.

Virtual WAN est le bon choix quand vous avez plusieurs régions Azure avec une connectivité branch complexe (intégration SD-WAN, des dizaines de sites VPN) et que vous voulez que Microsoft gère le maillage de routage. Virtual WAN simplifie le transit multi-régions, mais vous échangez du contrôle contre de la commodité. Vous ne pouvez pas déployer de ressources arbitraires dans le hub Virtual WAN, et le troubleshooting du routage devient plus difficile parce que l’infrastructure sous-jacente est managée.

L’erreur que je vois le plus souvent : choisir Virtual WAN parce que ça sonne plus “enterprise” sans avoir les besoins multi-régions et multi-branches qui le justifient. Si vous avez une seule région Azure et un seul circuit ExpressRoute, le hub-spoke est plus simple, moins cher et plus flexible.

Quel que soit la topologie choisie, prenez la décision avant de déployer Enterprise-Scale. Passer du hub-spoke au Virtual WAN (ou l’inverse) après coup implique de redéployer l’intégralité de la subscription de connectivité. Ce n’est pas un paramètre qu’on bascule.

Azure docs : Network topology and connectivity · Virtual WAN overview

La subscription Identity n’est pas optionnelle

La subscription Platform > Identity héberge vos contrôleurs de domaine (si vous faites tourner Active Directory dans Azure), vos forwarders DNS et toute l’infrastructure d’identité dont les workloads dépendent. Il est tentant de la fusionner avec la subscription Connectivity ou de la sauter complètement en se disant “on utilise uniquement Azure AD.”

Ne la sautez pas. Même dans un environnement purement Azure AD, vous aurez un jour besoin de zones Private DNS pour les private endpoints, de forwarders conditionnels pour la résolution hybride, ou d’un service de domaine managé. Avoir une subscription dédiée avec sa propre frontière RBAC signifie que l’équipe identité peut opérer indépendamment de l’équipe réseau. Cette séparation compte quand vous avez 50 subscriptions et trois équipes qui gèrent la plateforme.

Azure docs : Identity and access management

Les implémentations de référence sont des points de départ

Microsoft fournit des implémentations de référence en Bicep et en Terraform. Elles sont excellentes pour démarrer. Ce ne sont pas des produits finis.

Chaque organisation avec laquelle j’ai travaillé a dû personnaliser les implémentations de référence de manière significative :

• Des définitions de policies personnalisées pour des exigences propres à l’organisation (conventions de nommage, régions approuvées, catégories de diagnostics obligatoires)
• L’intégration avec les pipelines CI/CD existants : les implémentations de référence supposent un modèle de déploiement spécifique qui correspond rarement à ce que les équipes utilisent déjà
• La gestion de l’état : les backends d’état Terraform, les deployment stacks Bicep et la stratégie de branching pour les changements de plateforme nécessitent tous des décisions de conception
• La structure des modules : découper le déploiement monolithique en modules composables que différentes équipes peuvent posséder et faire évoluer indépendamment

Considérez les implémentations de référence comme un outil d’apprentissage et une source de patterns. Extrayez ce dont vous avez besoin, adaptez-le à votre modèle opérationnel et appropriez-vous le résultat. Forker le repository en entier et essayer de rester synchronisé avec les changements upstream est une voie vers la frustration.

Azure docs : ALZ Bicep modules · ALZ Terraform module

Les erreurs courantes que je continue de voir

Trop de Management Groups. Chaque niveau supplémentaire ajoute de la charge cognitive et de la complexité de débogage des policies. Si vous ne pouvez pas expliquer en une phrase pourquoi un Management Group existe, supprimez-le.

Des policies qui bloquent sans proposer d’alternative. Interdire les IP publiques est une bonne gouvernance. Interdire les IP publiques sans fournir un chemin documenté vers les private endpoints, Private Link et le NAT centralisé, c’est juste bloquer le travail. Chaque policy de type Deny doit s’accompagner d’un guide “voici comment faire correctement”.

Pas de processus d’exemption. Les équipes auront besoin d’exceptions. Si le seul chemin est “ouvrez un ticket et attendez deux semaines”, elles contourneront votre gouvernance au lieu de la suivre. Mettez en place un workflow d’exemption léger et auditable.

Tout déployer d’un coup. Enterprise-Scale est modulaire par conception. Commencez par les Management Groups et les policies. Ajoutez le réseau quand vous êtes prêts. Onboardez les workloads une subscription à la fois. Les organisations qui réussissent sont celles qui traitent cela comme un déploiement progressif, pas comme une migration big-bang.

Ignorer le tableau de bord de conformité. La conformité Azure Policy n’est utile que si quelqu’un la consulte. Assignez un responsable au tableau de bord de conformité et passez-le en revue chaque semaine. Une non-conformité qui persiste pendant des mois, c’est de la dette de gouvernance, et elle s’accumule.

Ce que je ferais différemment la prochaine fois

Les Enterprise-Scale Landing Zones sont le meilleur point de départ que Microsoft ait jamais fourni pour la gouvernance Azure. Elles encodent des années de leçons durement acquises dans un framework déployable. Mais un framework n’est pas une solution. Les décisions que vous prenez concernant le timing des policies, la topologie réseau, les processus d’exemption et la propriété de l’IaC sont ce qui détermine si votre landing zone accélère vos équipes ou les freine.

Commencez avec l’architecture de référence. Résistez à l’envie de tout personnaliser dès le premier jour. Déployez les policies en mode Audit. Construisez le processus d’exemption avant d’en avoir besoin. Et souvenez-vous qu’une landing zone n’est jamais terminée : elle évolue avec votre organisation.

L’objectif n’est pas une landing zone parfaite dès le premier jour. L’objectif est une fondation qui s’améliore chaque mois.

Plus sur le blog

1 juin 2022 | 11 min de lecture

Container Apps vs AKS vs App Service : un cadre de decision

Azure Containers AKS

12 novembre 2025 | 8 min de lecture

Pourquoi chaque entreprise Azure a besoin d'une méthodologie d'analyse WAF

Azure WAF Security

5 septembre 2024 | 6 min de lecture

Terraform AzureRM 4.0 : ce qui casse et comment migrer

Azure Terraform DevOps