Landing zone Azure pour ETI et PME : par où commencer

Beaucoup d'environnements Azure d'ETI et de PME ont commencé de la même façon : un abonnement créé pour un premier projet, puis un deuxième, des droits accordés au cas par cas, un réseau construit au fil de l'eau. Tant que le périmètre reste modeste, cela tient. Puis arrivent une migration plus ambitieuse, un audit de sécurité ou une exigence NIS2 — et l'on découvre qu'il faut reprendre les fondations.

Une landing zone est précisément cela : l'ensemble des fondations (organisation, identité, réseau, sécurité, gouvernance) préparées avant d'y déployer les applications. Microsoft en décrit l'architecture de référence dans le Cloud Adoption Framework sous le nom d'Azure Landing Zones. Bonne nouvelle : pour une ETI, il n'est ni nécessaire ni souhaitable de tout déployer d'emblée.

Les décisions qui structurent tout le reste

Certains choix sont difficiles à défaire une fois les applications installées. Ce sont eux qu'il faut prendre en premier, et par écrit :

la hiérarchie des groupes d'administration et le découpage en abonnements ;
le modèle réseau (hub-and-spoke ou Virtual WAN) et le plan d'adressage IP ;
le modèle d'identité et d'accès : qui administre quoi, avec quels privilèges ;
les régions autorisées et les contraintes de localisation des données ;
l'outillage d'infrastructure as code et le mode de déploiement.

Le reste — nombre de spokes, services de sécurité additionnels, automatisations — peut évoluer progressivement.

Groupes d'administration et abonnements

Les groupes d'administration permettent d'appliquer droits et politiques à des ensembles d'abonnements. Une hiérarchie simple, inspirée de l'architecture de référence, suffit dans la plupart des cas :

un groupe racine propre à l'organisation (pas directement le Tenant Root Group) ;
Platform : abonnements de connectivité, d'identité et de gestion (journaux, supervision) ;
Landing zones : abonnements applicatifs, souvent séparés en corp (applications internes, connectées au réseau de l'entreprise) et online (applications exposées sur Internet) ;
Sandbox : expérimentation, isolée du réseau de l'entreprise, avec des budgets plafonnés ;
Decommissioned : abonnements en cours de fermeture.

Côté abonnements, la règle utile est de considérer l'abonnement comme une unité de responsabilité et de facturation : un par application ou domaine fonctionnel, avec séparation production / hors production. C'est plus simple à sécuriser, à refacturer et à décommissionner qu'un grand abonnement partagé.

Azure Policy : les garde-fous dès le premier jour

Les politiques appliquées au niveau des groupes d'administration sont ce qui transforme une architecture sur le papier en règles effectivement respectées. Un socle raisonnable pour démarrer : régions autorisées, tags obligatoires, interdiction des IP publiques dans les zones corp, paramètres de diagnostic vers l'espace de journaux central, activation de Defender for Cloud.

Voici, en Bicep, l'affectation de la politique intégrée Allowed locations sur un groupe d'administration :

targetScope = 'managementGroup'

resource allowedLocations 'Microsoft.Authorization/policyAssignments@2022-06-01' = {
  name: 'allowed-locations'
  properties: {
    displayName: 'Régions autorisées'
    policyDefinitionId: tenantResourceId('Microsoft.Authorization/policyDefinitions', 'e56962a6-4747-49cd-b67b-bf8b01975c4c')
    parameters: {
      listOfAllowedLocations: {
        value: [ 'francecentral', 'westeurope' ]
      }
    }
  }
}

Conseil pratique : commencez les politiques restrictives en mode audit sur l'existant, mesurez les écarts, puis basculez en deny une fois les exceptions traitées.

Réseau : hub-and-spoke ou Virtual WAN ?

Les deux modèles centralisent la connectivité (vers le site, vers Internet, entre applications) dans un hub, avec des réseaux applicatifs (spokes) appairés. Ils diffèrent surtout par le degré de gestion déléguée à Microsoft.

Critère	Hub-and-spoke classique	Azure Virtual WAN
Contrôle	Complet : vous gérez le hub, le routage et les appliances	Hub géré par Microsoft, routage largement automatisé
Cas typique	Une ou deux régions, quelques sites	Nombreuses régions ou nombreux sites, SD-WAN, VPN utilisateurs à grande échelle
Complexité opérationnelle	Plus de configuration manuelle (tables de routage, peerings)	Moins de configuration, mais moins de finesse
Coût	Plus facile à maîtriser à petite échelle	Composants du hub facturés même avec peu de trafic

Pour la plupart des ETI présentes dans une ou deux régions, un hub-and-spoke bien conçu reste le choix le plus lisible. Quel que soit le modèle, le plan d'adressage IP mérite une vraie réflexion : il doit éviter tout chevauchement avec les sites, les partenaires et les futures acquisitions.

Identité : Entra ID comme plan de contrôle

Dans Azure, l'identité est le véritable périmètre. Avant le premier déploiement applicatif :

définir les rôles RBAC par groupe d'administration et par abonnement, attribués à des groupes Entra ID plutôt qu'à des personnes ;
activer Privileged Identity Management pour les rôles à privilèges, avec une élévation limitée dans le temps ;
protéger les administrateurs par une MFA résistante au phishing et l'accès conditionnel ;
prévoir des comptes de secours (break-glass) exclus de l'accès conditionnel, surveillés et testés ;
privilégier les identités managées pour les applications plutôt que des secrets.

Infrastructure as code : Bicep ou Terraform, avec AVM et ALZ

Une landing zone construite à la main dans le portail dérive vite et ne se reproduit pas. Elle doit être décrite en code, versionnée et déployée par pipeline.

Le choix entre Bicep et Terraform dépend surtout du contexte : Bicep est natif Azure et ne nécessite pas de gestion d'état ; Terraform convient mieux aux équipes déjà outillées ou multi-cloud. Les deux sont pleinement pris en charge.

Inutile de partir de zéro : Microsoft maintient les Azure Verified Modules (AVM), une bibliothèque de modules Bicep et Terraform maintenus et testés, et un accélérateur Azure Landing Zones qui s'appuie sur ces modules pour déployer la hiérarchie, les politiques et la connectivité. Ces accélérateurs couvrent beaucoup de terrain ; le travail consiste à les paramétrer au juste niveau pour votre organisation, sans activer tout ce qu'ils proposent.

Les erreurs les plus fréquentes

Tout mettre dans un seul abonnement, puis devoir déplacer des ressources sous contrainte.
Recopier l'architecture de référence complète pour une organisation qui n'en a pas l'usage : coûts et complexité inutiles.
Un plan d'adressage IP improvisé, qui chevauche le réseau des sites ou d'une filiale.
Des droits Owner distribués largement, sans PIM ni revue périodique.
Des politiques passées directement en deny sur un existant, qui bloquent les équipes et finissent désactivées.
Des modifications manuelles dans le portail à côté de l'IaC, qui font diverger l'état réel du code.
Oublier la journalisation centrale au démarrage : on ne reconstitue pas a posteriori des journaux jamais collectés.

Pour démarrer

Une landing zone adaptée à une ETI se construit en quelques semaines si les décisions structurantes sont prises tôt et si le périmètre initial reste raisonnable. Le plus important n'est pas de tout couvrir, mais de poser des fondations qui pourront évoluer sans être reprises.

Pour situer votre environnement actuel, faites notre autodiagnostic de maturité : l'axe « Plateforme & réseau » couvre précisément ces sujets. Pour concevoir ou remettre à plat votre landing zone, parlons-en.