Ce que révèle un audit Azure Landing Zone

Dans cet article

• Des hiérarchies de Management Groups qui ont grandi sans plan
• Des Policy Assignments que personne ne maintient
• Un DNS de Private Endpoint qui ne fonctionne pas correctement
• Une Identity Architecture qui a cessé d’évoluer
• Network Over-Engineering
• Du Cost Tagging qui ne produit pas de rapports exploitables
• Calendrier de remédiation typique
• Ce que produit un Platform Health Check

En résumé : Après avoir examiné des dizaines d’environnements Azure d’entreprise, les mêmes six problèmes reviennent systématiquement : des management groups trop complexes, des policies non maintenues, un DNS de private endpoint cassé, des configurations identity obsolètes, un network sprawl et des cost tags auxquels personne ne fait confiance. La plupart sont corrigeables en 3 à 5 semaines avec un plan de remédiation structuré.

Nous passons en revue des environnements Azure au quotidien. Des plateformes de production qui tournent depuis deux, trois, parfois cinq ans. Les architectes d’origine sont partis, trois équipes différentes ont empilé leurs décisions les unes sur les autres, et la documentation a cessé d’être mise à jour quelque part autour du sixième mois.

Après avoir fait cet exercice de manière répétée dans des entreprises de taille moyenne et grande, les constats tombent dans les mêmes catégories. Les Azure landing zones sont faussement faciles à déployer et véritablement difficiles à maintenir. Le déploiement initial reçoit de l’attention, du budget et une équipe projet. Les années qui suivent reçoivent le temps que le platform team peut y consacrer.

Voici ce que nous trouvons de manière systématique.

Constat	Sévérité typique	Fréquence
Management group over-engineering	Moyen	70%+ des audits
Policy assignments non maintenues	Élevé	Quasi universel
Pannes DNS de private endpoint	Critique	60%+ des audits
Lacunes dans l’identity architecture	Élevé	80%+ des audits
Network sprawl et règles obsolètes	Moyen	70%+ des audits
Cost tagging que la finance ignore	Moyen	Quasi universel

Des hiérarchies de Management Groups qui ont grandi sans plan

L’architecture de référence Azure Landing Zone recommande trois à quatre niveaux de management groups. C’est suffisant pour pratiquement toute organisation. Nous en avons parlé dans nos premières leçons sur les landing zones et à nouveau lorsque nous avons couvert ce qui compte dans les environnements matures.

Ce que nous trouvons en pratique : six, sept, parfois huit niveaux. Des couches supplémentaires pour les business units, puis des sous-couches pour les régions, puis des sous-sous-couches pour les environnements. Chaque niveau avait du sens pour celui qui l’a ajouté. Le résultat cumulé est une hiérarchie que personne ne peut dessiner de mémoire.

Les dégâts réels ne sont pas cosmétiques. Le policy inheritance devient imprévisible. Les assignations RBAC à un niveau contredisent celles d’un autre. Quand un déploiement échoue parce qu’une policy au quatrième niveau écrase une exemption au sixième, le chemin de débogage traverse chaque groupe parent. Nous passons régulièrement des journées entières à tracer des policy evaluation chains qui devraient prendre quelques minutes.

Les management groups orphelins sont fréquents aussi. Une division a été restructurée, les subscriptions ont été déplacées, mais le management group vide et ses policy assignments sont restés. Personne ne l’a supprimé parce que personne n’était sûr que c’était sans risque.

La solution est presque toujours d’aplatir. Supprimez les niveaux qui existent pour la vanité organisationnelle plutôt que pour des exigences concrètes de gouvernance. Si un management group ne porte pas de policy assignment ou de frontière RBAC différente de son parent, il ne devrait probablement pas exister.

Des Policy Assignments que personne ne maintient

Une landing zone fraîchement déployée est livrée avec un ensemble sélectionné d’Azure Policy assignments : deny public IPs, enforce encryption, require tags, deploy diagnostic settings. Elles sont correctes et précieuses. Le problème commence vers le huitième mois.

De nouvelles exigences de conformité arrivent. Quelqu’un ajoute une custom policy pour les naming conventions. Une autre équipe crée une policy pour les region restrictions. Une troisième personne copie une policy definition depuis un article de blog. Des exemptions sont accordées pour des workloads qui ne peuvent pas encore se conformer. D’autres exemptions suivent. Des dates d’expiration sont fixées mais jamais suivies.

Après deux ans, un environnement typique compte 150 à 300 policy assignments réparties dans la hiérarchie, 30 à 60 exemptions (dont un tiers ont des dates expirées que personne n’a remarquées), et 20+ custom policy definitions, dont certaines dupliquent des built-in policies que Microsoft a publiées après l’écriture des versions custom.

Le compliance dashboard raconte l’histoire. Nous voyons régulièrement des management groups à 55-65% de compliance. Quand nous demandons quand quelqu’un a consulté les chiffres de compliance pour la dernière fois, la réponse est généralement un regard vide ou “on regarde quand quelque chose casse.”

L’hygiène des policies exige la même discipline que l’hygiène du code. Des revues trimestrielles, la déduplication par rapport à la bibliothèque built-in en expansion, la suppression des exemptions obsolètes, et un processus documenté pour en accorder de nouvelles. La plupart des organisations n’ont rien de tout cela.

Schéma récurrent : Les management groups et les policies sont de l’infrastructure de gouvernance. Ils sont construits une fois et jamais maintenus. L’écart entre la gouvernance voulue et la gouvernance réelle se creuse chaque trimestre.

Un DNS de Private Endpoint qui ne fonctionne pas correctement

Les private endpoints sont partout dans Azure moderne. Chaque storage account, key vault, SQL database et container registry qui doit rester hors de l’internet public reçoit un private endpoint. Chacun a besoin d’un enregistrement DNS dans la bonne private DNS zone pour que les clients résolvent le nom du service vers l’IP privée plutôt que publique.

Le schéma recommandé est clair : des private DNS zones centralisées dans la connectivity subscription, liées à tous les VNets concernés, avec Azure Policy qui crée automatiquement les enregistrements DNS quand des private endpoints sont créés.

Ce que nous trouvons en réalité tombe dans trois catégories.

Zones manquantes. Quelqu’un a créé un private endpoint pour un compte Cosmos DB mais la zone privatelink.documents.azure.com n’existe pas dans la connectivity subscription. L’endpoint fonctionne depuis les machines qui utilisent le DNS du VNet, mais la résolution retombe sur le DNS public pour tout ce qui est en dehors de ce VNet. Le chemin de données passe de toute façon par le backbone Microsoft, mais l’équipe sécurité ignore que leur endpoint “privé” résout publiquement depuis la moitié du réseau.

Échecs de split-horizon. La private DNS zone existe et est liée à certains VNets mais pas à d’autres. Les équipes du VNet A résolvent le storage account vers son IP privée. Les équipes du VNet B obtiennent l’IP publique. Les deux équipes pensent que tout fonctionne. Personne n’a testé la résolution cross-VNet.

Lacunes de policy. La policy DeployIfNotExists censée créer les enregistrements DNS est assignée, mais sa managed identity n’a pas les droits Contributor sur le resource group de la private DNS zone. La policy évalue comme compliant (l’assignment existe) mais ne crée jamais les enregistrements. Ce cas est étonnamment fréquent et difficile à repérer sans tester la résolution de noms réelle.

L’audit DNS est souvent la partie la plus chronophage d’une revue de landing zone, et elle produit les constats les plus urgents. Une configuration DNS cassée peut signifier que du trafic que l’équipe sécurité croit privé résout en réalité via des endpoints publics.

Une Identity Architecture qui a cessé d’évoluer

Les schémas d’identity Azure ont considérablement changé depuis le déploiement de la plupart des landing zones. Privileged Identity Management (PIM), Conditional Access et workload identity federation sont tous des prérequis en 2025. Nous avons couvert ces évolutions dans notre mise à jour landing zone 2026.

Ce que nous trouvons dans les audits, c’est que la configuration identity reflète l’année où elle a été mise en place, pas l’état de l’art actuel.

Des assignations permanentes Contributor et Owner sur les subscriptions de production constituent le constat le plus fréquent. Pas de PIM, pas d’activation just-in-time, pas de workflow d’approbation. L’équipe sécurité sait que PIM existe mais “n’a pas encore eu le temps” parce que le déploiement nécessite de toucher chaque subscription.

Les comptes de service partagés avec des client secrets stockés dans des key vaults sont le deuxième constat le plus fréquent. Les pipelines CI/CD s’authentifient avec des secrets à longue durée de vie créés il y a deux ans et jamais renouvelés. Le workload identity federation éliminerait complètement ces secrets, mais la migration exige des modifications dans chaque pipeline.

Les workload identities sont un autre angle mort. Les app registrations et service principals s’accumulent au fil du temps sans suivi de propriété. Nous trouvons des dizaines d’app registrations dont le créateur d’origine a quitté l’organisation, personne ne sait ce que fait l’application, et les credentials sont toujours actifs. Les applications qui tournent sur du compute Azure mais s’authentifient vers d’autres services Azure avec des client secrets au lieu de managed identity ajoutent une surcharge inutile de gestion de credentials et un risque de rotation. Managed identity élimine complètement le secret, mais la migration nécessite d’identifier chaque flux d’authentification.

Les lacunes Conditional Access complètent le tableau. Des policies existent pour les utilisateurs finaux mais pas pour l’accès administratif. Ou elles existent mais ne couvrent pas le device compliance, de sorte qu’un administrateur peut activer un rôle Global Admin depuis un laptop personnel non géré.

Aucun de ces constats n’est exotique. Ce sont des best practices bien documentées qui nécessitent un effort dédié pour être mises en oeuvre. Cet effort est rarement priorisé quand le platform team est occupé à éteindre des incendies ailleurs.

Schéma récurrent : Le DNS et l’identity sont les deux domaines où l’écart entre “c’était correctement configuré à l’origine” et “ça fonctionne encore correctement aujourd’hui” est le plus grand. Les deux nécessitent une validation périodique, pas seulement une configuration initiale.

Network Over-Engineering

Hub-spoke est la topologie par défaut correcte, et la plupart des entreprises que nous auditons l’ont déployée. Le problème n’est pas la topologie. C’est ce qui s’est passé après le déploiement initial.

Les spokes inutilisés sont courants. Un projet était planifié, un spoke VNet a été provisionné et peeré vers le hub, mais le projet a été annulé ou a pris une autre direction. Le peering reste, l’espace d’adressage est alloué, et le hub firewall a des règles pour du trafic qui n’arrivera jamais.

Les peering meshes sont pires. Quelqu’un avait besoin de communication spoke-to-spoke et, au lieu de router via le hub firewall, a ajouté des peerings directs. Puis une autre équipe a fait pareil. Après quelques tours, le diagramme réseau ressemble à un plat de spaghetti et personne ne peut répondre à la question “est-ce que VNet A peut communiquer avec VNet B ?” sans tracer chaque peering et route table.

Les règles de firewall s’accumulent de la même manière que les policy assignments. Des règles sont ajoutées pour de nouveaux workloads mais jamais supprimées quand les workloads sont décommissionnés. Nous trouvons régulièrement des Azure Firewall rule collections avec 200+ règles, dont un tiers référence des adresses IP qui n’existent plus. La date de dernière revue des règles est soit “jamais” soit “quand on l’a déployé.”

L’audit réseau ne vise pas à trouver la mauvaise topologie. Il vise à trouver l’écart entre le design prévu et ce qui existe réellement après deux ans de changements incrémentaux sans nettoyage.

Du Cost Tagging qui ne produit pas de rapports exploitables

Chaque landing zone impose des tags. Cost centre, environment, owner, application. La policy est en place, les tags existent sur les resources, et l’équipe FinOps a des dashboards dans Cost Management. Sur le papier, l’allocation des coûts fonctionne.

En pratique, trois problèmes reviennent.

Des tags sur les resources mais pas sur les resource groups. Azure Policy peut imposer des tags au niveau resource group et utiliser l’effet Modify pour les faire hériter vers les resources, mais beaucoup d’organisations n’imposent qu’au niveau resource. Les rapports Cost Management qui groupent par resource group montrent alors des valeurs de tags incohérentes entre les resources qu’il contient, rendant l’allocation des coûts peu fiable.

Pas de tag inheritance activé. Azure supporte des tag inheritance policies qui copient les tags des resource groups ou subscriptions vers les resources. La plupart des organisations ne les utilisent pas. Le résultat est qu’un resource group tagué avec le cost centre “CC-5678” contient des resources taguées “CC-1234” parce que la resource a été déplacée depuis un autre groupe et ses tags n’ont jamais été mis à jour.

Des valeurs obsolètes. Les départements se restructurent, les projets se terminent, les cost centres changent. Les tags restent. Après quelques années, 15 à 20% des tags de cost centre référencent des codes qui n’existent plus dans le système financier. Les rapports FinOps montrent des dépenses contre des départements fantômes, et l’équipe financière cesse de faire confiance aux chiffres.

La précision des tags est un problème de qualité de données, pas un problème de policy. La policy peut imposer la présence de tags et appliquer des schémas d’héritage, mais elle ne peut pas valider si un cost centre existe encore dans votre système financier ou si le propriétaire indiqué travaille encore dans l’entreprise. L’application à la création est nécessaire mais pas suffisante. Il faut une réconciliation périodique avec la source faisant autorité (et cette source est généralement en dehors d’Azure), une correction automatisée quand c’est possible, et un processus pour gérer les discordances.

Calendrier de remédiation typique

Corriger une landing zone prend plus qu’un seul sprint. Sur la base de ce que nous voyons dans nos missions, un calendrier réaliste ressemble à ceci :

• Semaine 1 : Assessment d’architecture et rapport de constats. Parcourir l’environnement, documenter les lacunes et prioriser par sévérité et effort.
• Semaine 2 : Baseline de gouvernance. Aplatir la hiérarchie de management groups, supprimer les policy assignments obsolètes, consolider les définitions en double.
• Semaines 3-4 : Remédiation identity et policy. Déployer PIM pour les accès privilégiés permanents, migrer les workload identities vers managed identity ou federated credentials, combler les lacunes Conditional Access.
• Semaine 5 et au-delà : Simplification réseau et optimisation des coûts. Nettoyer les peerings inutilisés, consolider les règles de firewall, corriger la couverture des DNS zones et traiter la précision des tags.

Chaque phase s’appuie sur la précédente. Le nettoyage de la gouvernance rend la remédiation des policies plus propre, et les correctifs identity réduisent le blast radius avant que les changements réseau ne commencent.

Ce que produit un Platform Health Check

Un audit structuré de landing zone produit des livrables concrets et actionnables :

• Assessment de la hiérarchie de management groups avec des recommandations spécifiques pour aplatir ou restructurer, incluant une analyse d’impact pour chaque changement
• Revue de la santé des policies : définitions en double, exemptions obsolètes, lacunes de compliance par management group, et un backlog de remédiation priorisé
• Audit DNS des private endpoints : inventaire des zones, couverture des VNet links, tests d’efficacité des policies, et une liste des endpoints qui résolvent publiquement alors qu’ils ne le devraient pas
• Rapport de posture identity : inventaire des accès privilégiés permanents, assessment de maturité PIM, candidats à la migration workload identity, et analyse des lacunes Conditional Access
• Revue de la topologie réseau : spokes et peerings inutilisés, hygiène des règles de firewall, et un diagramme de l’état actuel comparé au design prévu
• Assessment du cost tagging : taux de couverture et de précision des tags, valeurs de tags orphelines, et recommandations pour l’héritage et la réconciliation

Chaque constat est accompagné d’un niveau de sévérité et d’un chemin de remédiation. L’objectif est un backlog sur lequel le platform team peut travailler, pas une liste d’observations.

Si vos landing zones tournent depuis plus d’un an sans revue structurée, des constats vous attendent. La question est de savoir si vous les trouvez de manière proactive ou si vous les découvrez lors d’un incident.

Mission typique : Lors de la revue de plateformes Azure, nous commençons généralement par un assessment d’architecture Azure structuré couvrant la structure de la landing zone, la hiérarchie des management groups, la santé des policies, la posture identity, la topologie réseau et le cost tagging. L’assessment produit un rapport de constats priorisé avec des niveaux de sévérité et une feuille de route de remédiation. La plupart des revues prennent 2 à 3 semaines.

En lien : Azure Landing Zones en 2026 et ce qui compte vraiment défis opérationnels day-2 · Azure Policy Guardrails que les développeurs ne détestent pas application sans friction · Pourquoi votre facture Azure est élevée même quand vos resources sont correctement dimensionnées fuites de coûts que les audits ratent · Azure DNS Private Resolver remplacer les VMs DNS du hub