Catégorie : Azure

372 vCPU et 2,8 Tio de mémoire sur une seule machine virtuelle : c’est désormais une taille Azure disponible en production, pas une démo de salon. Depuis le 25 août 2026, les tailles à 248 et 372 vCPU des séries D/E v7 sont passées en disponibilité générale, et elles changent la donne pour tout ce qui ne se découpe pas facilement en petits morceaux — grosses bases en mémoire, workloads d’IA à contexte large, applications sensibles à la latence inter-nœuds.

Ce qui change avec ces nouvelles tailles

Les séries concernées sont Dsv7, Ddsv7, Esv7 et Edsv7, toutes bâties sur un processeur Intel Xeon 6 6973P-C (Granite Rapids) cadencé à 3,6 GHz en turbo tous cœurs, avec AVX-512 et Advanced Matrix Extensions. Microsoft annonce jusqu’à 20 % de performance de calcul en plus par rapport à la génération v6 précédente. Les deux tailles phares à retenir :

• Esv7 / Edsv7, 372 vCPU — jusqu’à 2 832 Gio de RAM, jusqu’à 400 Gbps réseau, et jusqu’à 800 000 IOPS / 20 Gio/s vers du stockage distant Premium SSD v2 ou Ultra Disk.
• Ddsv7 / Edsv7, 372 vCPU — avec disque NVMe local, jusqu’à 9,6 millions d’IOPS et 53,76 Gio/s de débit sur le disque temporaire local, d’après la fiche Edsv7-series de Microsoft Learn.

Pour fixer un repère : Standard_E372ids_v7 monte à 500 000 IOPS / 16 000 Mo/s en Premium SSD non mis en cache, et jusqu’à 800 000 IOPS / 20 000 Mo/s en Ultra Disk ou Premium SSD v2 — le haut du tableau des tailles Edsv7, documenté précisément sur la page de la famille D. Ces chiffres n’ont plus grand-chose à voir avec ce qu’on pouvait attendre d’une VM Azure il y a encore deux ans.

Côté disponibilité, la mise à jour couvre huit régions pour l’instant : Central US, East US, East US 2, Germany West Central, South Central US, Sweden Central, West US 2 et West US 3 — à vérifier avant de planifier un déploiement si tu n’es pas déjà dans une de ces zones.

Pour quels workloads ça change vraiment quelque chose

Microsoft cible explicitement les grosses bases en mémoire (SQL Server, SAP HANA, Redis en mode in-memory), les moteurs d’analytique et de data warehousing, et — sans surprise en 2026 — les workloads d’IA agentique à fenêtre de contexte large. Le point commun entre tous ces cas : ce sont des charges qui perdent en performance dès qu’elles doivent se répartir sur plusieurs nœuds et traverser le réseau pour chaque requête. Une base SAP HANA en mémoire qui tenait auparavant sur un cluster de plusieurs VM E v6 moyennes peut désormais tenir sur une seule E372ids_v7, ce qui supprime purement et simplement la latence de sharding inter-nœuds.

Ça a aussi une conséquence qu’on mentionne rarement dans les annonces marketing : moins de VM pour le même volume de calcul, c’est moins de licences par cœur à gérer si tu es sous licensing SQL Server Enterprise par cœur physique, et une surface d’administration réduite. Le revers de la médaille, c’est la concentration du risque — une seule VM de cette taille qui tombe, c’est potentiellement toute ta base qui part avec elle, pas un nœud sur quatre. Le Live Migration et les Memory Preserving Updates restent supportés sur ces séries, ce qui limite l’exposition aux redémarrages de maintenance planifiée, mais ça ne protège pas d’une panne applicative.

Le piège à connaître avant de migrer

Ces séries fonctionnent uniquement sur des VM de génération 2 (Gen2) et nécessitent une image qui supporte NVMe — un prérequis déjà posé par la bascule Trusted Launch par défaut sur les VM Gen2 dont on parlait en septembre. Si tu tentes de redéployer une image personnalisée ancienne, sans pilote NVMe, sur une taille Ddsv7 ou Edsv7, le déploiement échoue avec un message d’erreur explicite plutôt qu’un démarrage silencieusement dégradé — ce n’est pas un bug, c’est documenté comme un comportement attendu. Vérifie le support NVMe de ton image avant de migrer, pas après.

Autre point à ne pas laisser de côté : la variante Dsv7 « sans suffixe d » n’a aucun stockage local, contrairement à Ddsv7. Si ton workload a besoin du disque NVMe local — par exemple pour profiter du Full Caching des Ephemeral OS Disks passé en GA en septembre — c’est Ddsv7 ou Edsv7 qu’il te faut, pas Dsv7. Avec un disque local pouvant atteindre plusieurs téraoctets sur ces tailles, la contrainte « stockage local ≥ 2× la taille du disque OS + 1 Gio » exigée par le Full Caching devient triviale à satisfaire, même avec une image OS volumineuse.

Comment déployer une de ces tailles

Rien de nouveau côté outillage — ces tailles se créent comme n’importe quelle autre VM Azure, à condition de cibler une des régions disponibles :

az vm create \
  --resource-group mon-groupe-ressources \
  --name vm-sap-hana-01 \
  --image Ubuntu2404 \
  --size Standard_E372ids_v7 \
  --location swedencentral \
  --generation V2 \
  --admin-username azureuser \
  --generate-ssh-keys

Avant de lancer ce genre de déploiement en production, passe par la calculatrice de prix Azure — une VM à 372 vCPU n’a pas le même ticket d’entrée qu’une D4s_v5, et le coût du stockage Ultra Disk ou Premium SSD v2 associé se facture à part.

FAQ

Ces tailles remplacent-elles les séries v6 existantes ?
Non, les tailles v6 restent disponibles et ne sont pas annoncées en retrait. Les v7 s’ajoutent en haut de gamme, avec un plafond de vCPU et de débit nettement supérieur, pas comme un remplacement généralisé du catalogue existant.

Faut-il forcément du NVMe pour utiliser ces tailles ?
Oui pour le stockage local des variantes Ddsv7/Edsv7 — l’image OS doit supporter NVMe, sous peine d’échec de déploiement. Les variantes Dsv7/Esv7 sans stockage local n’ont pas cette contrainte puisqu’elles n’exposent pas de disque NVMe du tout.

Ces tailles sont-elles disponibles partout ?
Non, seulement dans huit régions pour l’instant (Central US, East US, East US 2, Germany West Central, South Central US, Sweden Central, West US 2, West US 3). Vérifie la disponibilité régionale avant d’engager un projet dessus.

En pratique

Si tu gères une base en mémoire ou un moteur d’analytique qui souffre aujourd’hui du sharding entre plusieurs VM, c’est le moment de recalculer le coût d’une consolidation sur une seule instance E372ids_v7 ou D372 — moins de nœuds à patcher, moins de licences par cœur à suivre, et une latence inter-nœuds qui disparaît purement et simplement. Vérifie juste le support NVMe de tes images avant de lancer le premier test, et commence par une région où ces tailles sont déjà disponibles.

Tu as configuré ton scale set sur trois zones de disponibilité, tu as vérifié la répartition le jour du déploiement, et tout allait bien : cinq VMs par zone. Six mois de scale-in et scale-out plus tard, sans que personne ne s’en aperçoive, la répartition réelle est devenue 2 / 4 / 7. Une panne sur la zone qui en concentre sept, et c’est près de la moitié de ta capacité qui disparaît d’un coup — alors que le scale set avait été pensé, à l’origine, pour tenir une perte de zone sans broncher.

C’est exactement le problème que la fonctionnalité Automatic zone balance pour les Virtual Machine Scale Sets vient corriger, passée en disponibilité générale le 15 octobre 2026. Elle ne remplace pas une stratégie de reprise après sinistre, mais elle règle un angle mort que beaucoup d’équipes découvrent seulement au pire moment.

Le déséquilibre de zone : un problème qui ne se voit pas

Quand tu déploies un scale set sur plusieurs zones de disponibilité, Azure tente de répartir les VMs aussi uniformément que possible à la création. Mais les contraintes de capacité et les opérations de scaling qui s’enchaînent ensuite peuvent faire dériver cette répartition dans le temps, sans qu’aucune alerte ne se déclenche — rien ne casse, rien ne tombe en erreur. Microsoft définit un scale set comme « équilibré » si chaque zone compte le même nombre de VMs à plus ou moins une instance près. En dessous de ce seuil, il est considéré en déséquilibre.

Prends un scale set avec 1 VM en zone 1, 3 en zone 2 et 3 en zone 3 : la zone 1 est sous-provisionnée, les zones 2 et 3 sont sur-provisionnées. Le risque, concrètement, c’est qu’une panne sur une seule zone sur-provisionnée affecte une part disproportionnée de ton application — l’inverse exact de ce que la répartition multi-zone est censée t’apporter.

Comment fonctionne le rééquilibrage

Le mécanisme repose sur une approche « create-before-delete » : Azure crée une nouvelle VM dans la zone sous-provisionnée, attend qu’elle devienne saine, puis supprime une VM de la zone sur-provisionnée. Une seule VM est déplacée à la fois, et les nouvelles instances utilisent toujours le SKU le plus récent défini dans le modèle du scale set.

Le délai d’attente de santé est fixé à 90 minutes. Si la nouvelle VM devient saine dans ce délai, l’ancienne VM de la zone sur-provisionnée est supprimée. Si elle ne le devient pas mais que la VM source, elle, reste saine, c’est la nouvelle VM qui est supprimée — le rééquilibrage échoue proprement plutôt que de dégrader ton application. Si la VM source devient elle-même défaillante pendant l’attente, elle est supprimée et la nouvelle VM est conservée.

Les garde-fous avant qu’un rééquilibrage ne démarre

• Le scale set ne doit pas être marqué pour suppression.
• Aucune opération PUT, PATCH ou POST en cours ou terminée depuis moins de 60 minutes (ajout de VM, suppression, mise à niveau en cours).
• Les VMs sous instance protection policy ne sont jamais déplacées, ni celles déjà désallouées ou en attente de suppression.
• Un scale-in déclenché par l’autoscale pendant un rééquilibrage est différé jusqu’à la fin de l’opération ; un scale-out ou un changement de capacité manuel, lui, annule le rééquilibrage en cours et applique directement la nouvelle capacité.

Détail qui compte en exploitation : le comptage des VMs pour détecter un déséquilibre inclut les instances actives, désallouées et éteintes. Mais le rééquilibrage ne se déclenche que si déplacer une VM active améliore réellement la répartition des VMs actives — une zone qui a le plus de VMs au total mais le moins de VMs actives n’est pas considérée comme sur-provisionnée pour autant.

Ce qu’il faut préparer avant d’activer la fonctionnalité

Trois prérequis, non négociables :

• Le monitoring de santé applicative doit être actif, via l’Application Health Extension ou les health probes du Load Balancer (les deux sont mutuellement exclusifs — un seul des deux mécanismes à la fois).
• Le scale set doit s’étendre sur au moins deux zones de disponibilité, avec toutes les VMs assignées à une zone — les scale sets avec des VMs régionales (non zonales) ne sont pas éligibles.
• Utiliser la version d’API Compute 2024-07-01 ou ultérieure.

Pense aussi à la marge de capacité : le rééquilibrage augmente temporairement ta capacité d’une VM pendant l’opération. Si tu utilises l’autoscale, vérifie que ton instance count maximum et tes règles de scale-in laissent cette marge, et que ton abonnement dispose du quota nécessaire — sans ça, le rééquilibrage ne démarre simplement pas.

Activer automatic zone balance

Dans le portail, c’est une case à cocher dans l’onglet Santé, sous la section Résilience, une fois le monitoring de santé configuré. En API REST ou via Azure CLI/PowerShell, ça passe par la propriété resiliencyPolicy du modèle du scale set :

PUT /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Compute/virtualMachineScaleSets/{vmScaleSetName}?api-version=2024-07-01

{
  "properties": {
    "resiliencyPolicy": {
      "AutomaticZoneRebalancingPolicy": {
        "Enabled": true,
        "RebalanceStrategy": "Recreate",
        "RebalanceBehavior": "CreateBeforeDelete"
      }
    }
  }
}

Activer automatic zone balance active aussi, par défaut, les automatic instance repairs — les deux mécanismes se complètent (l’un répare les VMs individuellement défaillantes, l’autre rééquilibre la répartition entre zones). Si tu as une raison précise de vouloir l’un sans l’autre, un paramètre automaticRepairsPolicy.enabled: false séparé permet de désactiver les instance repairs tout en gardant le rééquilibrage de zone actif.

Pour vérifier qu’un rééquilibrage a bien eu lieu, filtre les Activity Logs du scale set sur l’opération BalanceVMsAcrossZones, ou interroge l’Instance View API : le tableau orchestrationServices de la réponse contient l’état du service AutomaticZoneRebalancing et l’horodatage de son dernier changement de statut.

Les limites à connaître avant de l’activer partout

Le point le plus important : automatic zone balance détruit et recrée des VMs. Les ID d’instance, la configuration réseau spécifique à l’instance et les disques ne sont pas préservés dans cette opération. C’est pensé pour des charges stateless — un tiers web ou API derrière un load balancer, typiquement — pas pour des VMs avec un état local qui compte.

Ajoute à ça que le rééquilibrage reste une opération « best-effort » : s’il n’y a pas de capacité disponible dans la zone sous-provisionnée, l’opération est simplement retardée, sans garantie de délai. Et si une VM utilise un SKU différent du modèle actuel du scale set, elle perd ce SKU particulier une fois déplacée, puisque les nouvelles instances créées reprennent toujours le SKU le plus récent défini dans le modèle.

Faut-il l’activer par défaut ?

Pour un tier stateless derrière un Load Balancer ou une Application Gateway, oui, sans hésiter — c’est exactement le type de résilience passive qu’on voudrait avoir sans y penser, dans la même logique que le passage de Trusted Launch en option par défaut sur les VMs Gen2 : une protection qui ne coûte rien à l’usage et qu’on n’a plus besoin de se souvenir d’activer. Pour des scale sets avec des VMs qui portent un état local — cache applicatif réchauffé, disques de données attachés avec des données spécifiques à l’instance, configuration post-démarrage coûteuse à refaire — c’est une autre histoire : active plutôt une instance protection policy sur les instances concernées avant d’allumer le rééquilibrage automatique, pour éviter qu’Azure ne les recycle au mauvais moment. Et si tu veux un contrôle plus strict qu’un simple best-effort, la fonctionnalité complémentaire de placement de zone automatique (encore en préversion) permet d’imposer un équilibrage strict via zoneBalance et maxZoneCount — au prix d’un taux d’allocation potentiellement plus faible en cas de contrainte de capacité.

FAQ

Automatic zone balance protège-t-il contre une panne de zone en cours ?

Non. La documentation Microsoft est explicite sur ce point : la fonctionnalité ne surveille pas la santé des VMs en cas de panne de zone et ne doit pas être utilisée comme mécanisme de reprise après panne de zone. Elle corrige un déséquilibre de répartition en amont, pas une panne en cours.

Est-ce compatible avec des VMs de SKU différents dans le même scale set ?

Partiellement. Le rééquilibrage fonctionne, mais toute VM déplacée perd son SKU d’origine au profit du SKU le plus récent défini dans le modèle du scale set — à anticiper si tu fais cohabiter plusieurs générations de VMs intentionnellement.

Ça marche aussi sur les scale sets en mode Flexible orchestration ?

La documentation Microsoft présente la fonctionnalité pour les scale sets zone-spanning en général ; le suivi de l’état du service d’orchestration via l’Instance View API est en revanche spécifiquement documenté pour le mode Uniform. Vérifie le comportement exact sur le mode Flexible avant de t’appuyer dessus en production.

En pratique

Si tu as des scale sets zone-spanning qui tournent depuis plusieurs mois sans qu’on ait jamais revérifié leur répartition, c’est probablement le bon moment de regarder l’Activity Log ou l’onglet Résilience du portail. La dérive ne fait pas de bruit — jusqu’au jour où une zone tombe et où tu découvres, dans le mauvais ordre, à quel point la répartition s’était faite inégale. Ça rejoint une logique déjà vue avec le passage en GA d’Ephemeral OS Disk avec Full Caching : Azure muscle petit à petit la résilience par défaut de ses VMs, sans attendre que tu ailles la chercher toi-même.

Le 14 septembre 2026, Microsoft Dev Box est entré dans sa période de fermeture. Tu peux encore créer des dev box aujourd’hui, mais la date de retrait complet — le 18 septembre 2028 — est désormais fixée dans la documentation officielle. Cinq mois plus tôt, Azure Deployment Environments (ADE) a reçu son propre avis de retrait, pour le 22 février 2027. Deux services complémentaires, souvent déployés ensemble sur le même dev center, deux calendriers totalement différents. Le risque : traiter les deux comme un seul problème et rater l’une des deux échéances.

Dev Box : la fermeture a déjà commencé

Dev Box retire officiellement le 18 septembre 2028 à 17h00 UTC. Mais la phase qui compte pour toi a démarré le 14 septembre 2026 à 16h00 UTC : c’est le début de la « closing-down period ». Concrètement, tu peux continuer à utiliser tes dev box existantes pendant toute la transition, mais Microsoft est clair sur un point — n’ajoute pas de nouvelles dépendances de long terme sur un service qui ferme.

Le remplacement recommandé est Windows 365, avec des Cloud PC persistants pilotés par Intune et Entra ID. Mais la documentation Microsoft elle-même insiste : ce n’est pas un remplacement en un clic. L’architecture change (provisioning par politique plutôt que self-service par projet), la gestion du réseau change, et il n’existe aucun outil de migration automatisé. Tu dois reprovisionner les postes, recréer les politiques et transférer les données utilisateur (y compris WSL et les identifiants locaux) par les voies classiques.

Azure Deployment Environments : une fenêtre plus courte, un remplacement moins évident

ADE retire le 22 février 2027 — moins d’un an et demi après l’annonce. À cette date, les opérations d’écriture (création, déploiement, redéploiement) seront bloquées ; les opérations de lecture et de suppression resteront disponibles pour une période de nettoyage limitée dans le temps.

Ici, pas de solution unique recommandée. Microsoft Learn propose trois pistes selon ton contexte :

• Azure Resource Manager / Bicep en direct, si tes équipes gèrent déjà souscriptions, identités et policies via leurs propres process de plateforme.
• Azure Verified Modules (AVM), pour des briques Azure standardisées et gouvernées — à valider sur la couverture, le versioning et la politique associée.
• Azure DevOps / GitHub Actions, pour intégrer le provisionnement d’environnement directement dans les pipelines CI/CD existants.

Et la documentation est honnête sur un point qu’on voit rarement écrit aussi franchement par un éditeur : « aucune des solutions tierces identifiées ne prend en charge directement un cycle de vie Bicep ou ARM ». Si tu comptais sur un partenaire pour faire la bascule à ta place, il va falloir regarder ailleurs — ou repasser par l’IaC natif.

Le piège : les deux services partagent les mêmes dev centers

Dev Box et ADE s’organisent tous les deux autour de la notion de dev center. C’est pratique au quotidien, ça devient un piège au moment du nettoyage : si tu commences à démanteler tes ressources ADE en février 2027, ne supprime pas les dev centers ou projets partagés avant d’avoir vérifié qu’aucun pool Dev Box n’en dépend encore — Dev Box, lui, continue de tourner jusqu’en 2028.

Pour objectiver l’inventaire plutôt que de le faire à la main, commence par une requête Azure Resource Graph sur les ressources concernées :

az graph query -q "
Resources
| where type in (
    'microsoft.devcenter/devcenters',
    'microsoft.devcenter/projects',
    'microsoft.devcenter/devcenters/pools',
    'microsoft.devcenter/devcenters/environmenttypes'
)
| project name, type, resourceGroup, subscriptionId
"

Complète ensuite avec le workbook Azure Advisor « Service Retirement », qui recense les abonnements et ressources concernés par les retraits annoncés — Dev Box et ADE y figurent désormais tous les deux.

Ce qui ne figure pas dans l’inventaire ARM

Point à ne pas manquer : les environnements ADE déployés n’ont pas d’ID de ressource Azure Resource Manager classique. Resource Graph ne les verra pas. Pour les lister, il faut passer par le portail développeur, l’Azure CLI dédié à ADE, les API data-plane, ou ta télémétrie opérationnelle existante. Et supprimer un environnement ADE ne supprime pas forcément toutes les ressources Azure qu’il a déployées hors de son groupe de ressources géré — vérifie Azure Cost Management après coup pour confirmer que la facturation s’est bien arrêtée.

FAQ

Le retrait d’ADE entraîne-t-il aussi celui de Dev Box ?

Non. Ce sont deux retraits indépendants, avec deux dates différentes (février 2027 pour ADE, septembre 2028 pour Dev Box), même s’ils partagent une partie de l’infrastructure.

Puis-je encore créer de nouvelles dev box aujourd’hui ?

Oui, la création reste possible pendant la période de fermeture. Mais évite d’en faire un socle durable : chaque nouvelle dépendance créée maintenant devra être migrée de toute façon avant 2028.

Existe-t-il un outil de migration automatique vers Windows 365 ?

Non. Microsoft le précise explicitement : il faut provisionner les Cloud PC cibles, recréer les politiques et applications, puis transférer les données utilisateur par les processus validés par ton organisation.

Ce qu’il faut retenir

Deux échéances, deux ressources partagées, un seul inventaire à faire — mais surtout, ne traite pas ADE et Dev Box comme un bloc unique sous prétexte qu’ils cohabitent dans le même dev center. Commence par la requête Resource Graph ci-dessus, croise-la avec le workbook Advisor, et découpe ton plan de migration en deux chantiers distincts avec deux dates butoir. Si tu veux la vue d’ensemble des autres retraits Azure du mois, on a fait le point sur les retraits d’octobre 2026 — et si Bicep/AVM devient ta cible de remplacement pour ADE, notre article sur la bascule vers les Azure Verified Modules te donnera une base concrète pour démarrer.

Le 1er octobre 2026, trois choses ont cessé de fonctionner sans prévenir grand monde : la prise en charge de Python 3.10 sur Azure Functions, et deux services Cognitive Services entiers, Azure Anomaly Detector et Azure Personalizer. Pas de bandeau rouge dans le portail qui saute aux yeux, pas d’e-mail individuel pour la plupart des abonnements concernés — juste une ligne de plus dans une page de retraits que personne ne consulte avant que ça morde. Si tu gères de l’infra Azure au quotidien, voici ce qui tombe ce mois-ci, pourquoi c’est facile à rater, et comment vérifier en dix minutes si tu es concerné.

Ce qui a déjà basculé le 1er octobre

Quatre retraits sont entrés en vigueur le même jour, sans lien entre eux si ce n’est le calendrier :

• Azure Functions : le runtime Python 3.10 n’est plus supporté. Les fonctions existantes continuent de tourner, mais sans correctif de sécurité ni support Microsoft — ce n’est pas une coupure immédiate, c’est une dette qui s’accumule silencieusement.
• Azure Cognitive Service — Anomaly Detector : service retiré intégralement. Impossible de créer une nouvelle ressource, et les ressources existantes cessent de répondre.
• Azure Cognitive Service — Personalizer : même sort. Si tu t’en servais pour un moteur de recommandation, il faut basculer vers un modèle sur mesure ou un service Azure AI Foundry équivalent — il n’existe pas de migration automatique.
• Azure SQL Database : la génération de calcul Fsv2 n’est plus proposée pour les nouvelles bases ni les mises à l’échelle.

Rien de tout ça n’empêche ton infra de tourner aujourd’hui. C’est justement le piège : un retrait de service Azure est rarement un arrêt brutal, et c’est pour ça qu’il finit dans la colonne « on verra plus tard » jusqu’à ce qu’un audit de sécurité ou un ticket de support bloqué le remette sur la table.

Le 13 octobre, le vrai morceau : la fin des comptes de stockage historiques

C’est le retrait le plus susceptible de te concerner sans que tu le saches. Les comptes de stockage de type Storage (dits « legacy Blob ») et General-Purpose v1 (GPv1) — les tout premiers formats de compte de stockage Azure, antérieurs à 2016 — sont retirés à partir du 13 octobre 2026. Ces comptes n’ont jamais eu accès aux fonctionnalités arrivées depuis : gestion du cycle de vie, niveaux Archive, certaines options de redondance zone-redondante. Si tu en as encore en production, ils tournent probablement depuis longtemps sans que personne n’y touche — ce qui est précisément le profil de ressource qu’on oublie de vérifier.

La commande la plus rapide pour les repérer sur un abonnement :

az storage account list \
  --query "[?kind=='Storage' || kind=='BlobStorage'].[name,resourceGroup,kind]" \
  -o table

Si la commande retourne des lignes, il faut planifier une migration vers un compte StorageV2 avant l’échéance — la documentation officielle de migration détaille la procédure, qui se fait sans interruption de service dans la plupart des cas.

Et le 31 octobre : AKS Arc sur Windows Server 2022

Dernier point du mois pour ceux qui exploitent des clusters AKS Azure Arc : le SKU Windows Server 2022 n’est plus supporté à partir du 31 octobre. C’est un périmètre plus restreint — essentiellement les environnements hybrides avec des node pools Windows sur Arc — mais si ça te concerne, c’est une mise à jour de node pool à planifier avant la fin du mois, pas après.

Comment arrêter de se faire surprendre

La page officielle des mises à jour Azure liste tout, mais personne ne la lit en continu. La bonne surface à surveiller, c’est Azure Advisor : dans l’onglet Fiabilité, le filtre Service Upgrade and Retirement ne remonte que ce qui touche réellement tes ressources déployées, pas la liste générale de tout ce qui se retire dans le monde. C’est documenté dans le guide Advisor sur les recommandations de retrait, qui couvre aussi les retraits à venir en novembre et décembre si tu veux anticiper plus loin.

Pour un audit plus poussé à l’échelle de plusieurs abonnements, l’outil open source Azure Retirement Impact Analyzer, publié par Microsoft, croise Azure Resource Graph avec la liste des retraits planifiés pour sortir un rapport exploitable — plus pratique qu’un passage manuel abonnement par abonnement.

On avait déjà vu ce schéma avec le retrait d’Azure Virtual Desktop (classic) : l’échéance était connue des mois à l’avance, affichée dans Advisor, et pourtant une partie des migrations s’est faite dans les derniers jours. Les retraits d’octobre suivent exactement le même calendrier de visibilité — la seule variable, c’est qui prend le temps de regarder avant la date butoir.

FAQ

Mes fonctions Python 3.10 vont-elles s’arrêter net le 1er octobre ?

Non. Elles continuent de s’exécuter, mais sans support ni correctif de sécurité Microsoft. Le risque n’est pas une panne immédiate, c’est de tourner avec un runtime non maintenu pendant que personne ne s’en soucie — jusqu’au jour où une vulnérabilité touche spécifiquement cette version.

Comment savoir si j’ai encore des comptes de stockage legacy Blob ou GPv1 ?

La commande Azure CLI donnée plus haut (az storage account list avec le filtre sur kind) les repère en quelques secondes sur un abonnement donné. Pour plusieurs abonnements d’un coup, passe par Azure Resource Graph ou l’outil Retirement Impact Analyzer cité ci-dessus.

Est-ce que Microsoft prévient individuellement avant un retrait ?

En général oui, via Azure Service Health, mais seulement si les bons contacts d’administration sont renseignés sur l’abonnement. Ne compte pas uniquement là-dessus : un abonnement avec un contact technique obsolète ou une boîte mail partagée jamais relevée ne recevra l’alerte que dans les faits, pas dans l’intention.

Que faire si je ne peux pas migrer à temps ?

Ça dépend du service, mais la règle générale est qu’il n’y a pas de délai de grâce automatique pour la plupart de ces retraits précis. Pour un cas bloquant (migration complexe, dépendance tierce), ouvrir un ticket de support Azure avant l’échéance reste la seule option — après la date, c’est trop tard pour négocier.

Prochaine étape

Aucun de ces retraits n’est une surprise de dernière minute : la liste est publique depuis des mois sur la page Azure Updates. Le seul vrai réflexe à prendre, c’est de caler un rendez-vous récurrent — premier lundi du mois, par exemple — pour repasser Azure Advisor sur tes abonnements. Le prochain lot à surveiller tombe le 10 novembre 2026, avec le retrait du modèle in-process pour Azure Functions et la fin du support .NET 8 LTS sur App Service : autant le mettre dans l’agenda maintenant plutôt que de le découvrir à la dernière semaine d’octobre.

Une VM Azure Gen2 que tu déploies aujourd’hui via Terraform, sans rien préciser dans ton securityProfile, n’a plus le même comportement qu’il y a six mois. Secure Boot et vTPM s’activent tout seuls. Pas de case à cocher, pas de paramètre à ajouter — juste un changement silencieux de comportement par défaut qui peut surprendre si tu génères des images personnalisées ou si tu exploites une VM en hibernation.

Trusted Launch as Default, disponible en production

Trusted Launch as Default (TLaD) est passé en disponibilité générale cet été. Le principe : toute nouvelle VM ou tout nouveau scale set Gen2 que tu crées — que ce soit via le portail Azure, PowerShell, l’Azure CLI, un template ARM, Bicep ou Terraform — bascule automatiquement en Trusted Launch avec Secure Boot et vTPM activés, sans que tu aies à ajouter le moindre bloc securityProfile à ton code de déploiement.

Concrètement, ça combine trois briques : Secure Boot, qui n’autorise que des systèmes d’exploitation et des pilotes signés à démarrer ; un vTPM conforme à la spec 2.0, qui sert de coffre-fort dédié pour tes clés et mesures d’intégrité ; et la surveillance d’intégrité du démarrage via Microsoft Defender for Cloud, qui déclenche une alerte si la chaîne de boot a été altérée. Rien de nouveau en soi — Trusted Launch existe depuis plusieurs années — mais jusqu’ici, il fallait le demander explicitement. Ce n’est plus le cas.

Ce qui change vraiment côté déploiement

Avant TLaD, l’absence de bloc securityProfile dans ton template créait une VM Gen2 « standard », sans Secure Boot ni vTPM. Depuis la bascule, avec une API en version 2025-11-01 ou supérieure, l’absence de ce même bloc produit désormais une VM Trusted Launch. Ton code ne change pas — c’est l’interprétation par défaut de son absence qui s’inverse. Si tu passais explicitement securityType: "Standard", rien ne bouge : ton intention reste respectée.

La bascule automatique ne s’applique que si quatre conditions sont réunies : l’image source du Marketplace supporte Trusted Launch, une image issue d’une Azure Compute Gallery est elle aussi validée pour Trusted Launch, le disque source le supporte, et la taille de VM choisie fait partie des familles compatibles. Si une seule de ces conditions manque, le déploiement continue normalement — tu obtiens une VM Gen2 sans Trusted Launch, pas une erreur.

Zéro surcoût, mais une vraie limite à connaître

Premier point rassurant : Trusted Launch ne coûte rien de plus. C’est une couche de sécurité fondamentale incluse dans le prix de la VM, ce qui rend la question « faut-il le désactiver pour économiser » sans objet. Microsoft déconseille d’ailleurs explicitement de le désactiver sur de nouveaux déploiements, sauf cas précis.

La vraie limite technique concerne le redimensionnement. Une fois une VM créée en Trusted Launch, tu ne peux plus la redimensionner vers une famille de taille qui ne le supporte pas — les séries M, notamment. Si ton scénario impose de basculer un jour vers une taille incompatible, la seule voie de sortie documentée consiste à désallouer la ressource, puis repasser explicitement securityType à Standard via l’API 2025-11-01 ou une version ultérieure, avec un outil client autre que le portail — cette opération n’est pas disponible dans l’interface graphique Azure.

Trois cas où il faut désactiver la bascule explicitement

Microsoft documente précisément les scénarios où contourner TLaD n’est pas optionnel :

• tu utilises une VM Gen2 pour générer des images de type TrustedLaunchSupported, TrustedLaunchAndConfidentialVMSupported ou ConfidentialVMSupported dans une Azure Compute Gallery, via Azure Image Builder ou Packer ;
• tu captures une image managée classique (managed image) à partir d’une VM Gen2 — cette fonctionnalité n’est tout simplement pas compatible avec Trusted Launch, Microsoft recommandant de migrer vers Azure Compute Gallery ;
• tu exploites l’hibernation sur une VM Linux Gen2 — Trusted Launch et hibernation Linux restent mutuellement exclusifs à ce jour.

Dans ces trois cas, le contournement passe par l’enregistrement de la fonctionnalité preview TrustedLaunchByDefaultPreview sous l’espace de noms Microsoft.Compute, désactivée pour ta souscription, ou par un securityType: "Standard" explicite VM par VM.

Et les VM existantes ?

Aucun changement. TLaD ne touche que les nouvelles créations — une VM ou un scale set déjà en production garde exactement le comportement pour lequel il a été déployé, TLaD ou pas. Si tu veux faire monter en sécurité un parc existant, la bascule reste manuelle : désallouer la VM, passer le type de sécurité à Trusted Launch, cocher Secure Boot et vTPM, puis redémarrer. Une VM Gen1 doit d’abord être mise à niveau vers Gen2, ce qui implique de valider au préalable le volume système invité — cette étape ne peut pas être ignorée, même en ligne de commande.

FAQ

TLaD s’applique-t-il à mes VM Gen1 ?

Non, uniquement aux VM et scale sets Generation 2. Une VM Gen1 doit d’abord être migrée vers Gen2 — avec validation du volume système invité — avant de pouvoir bénéficier de Trusted Launch, par défaut ou manuellement.

Est-ce que ça change mes scripts d’automatisation existants ?

Si tes templates ARM ou modules Terraform utilisaient déjà l’API 2021-11-01 ou une version plus récente sans bloc securityProfile explicite, le comportement change sans que tu aies à toucher au code — c’est justement le point. Si tu veux garder le comportement pré-TLaD, ajoute securityType: "Standard" explicitement.

Faut-il l’activer manuellement sur ma souscription ?

Non. Le portail Azure, PowerShell et l’Azure CLI appliquent Trusted Launch par défaut sur les VM Gen2, indépendamment de tout enregistrement de fonctionnalité. L’enregistrement de TrustedLaunchByDefaultPreview ne concerne que les déploiements via SDK, Terraform ou d’autres outils tiers.

Ce qu’il faut retenir

Pour l’écrasante majorité des déploiements de VM Windows ou Linux standards, TLaD est une bonne nouvelle qui ne demande aucune action : la sécurité de base progresse sans effort de ta part, sans facture supplémentaire. La vigilance à avoir concerne surtout les pipelines de fabrication d’images (Packer, Azure Image Builder) et les environnements qui dépendent encore de managed images classiques plutôt que d’Azure Compute Gallery — ce sont eux qui ont le plus de chances de voir un déploiement automatisé changer de comportement sans prévenir. Si la résilience de tes VM Azure t’intéresse au-delà du boot sécurisé, notre article sur la GA de l’Ephemeral OS Disk avec Full Caching et celui sur le passage aux Azure Verified Modules complètent bien ce sujet.

Une panne de stockage distant qui fait tomber tes VM stateless, ça n’a rien de théorique — les coupures liées aux intempéries ou aux incidents d’alimentation en ont fait l’expérience à plus d’un admin. Azure vient de rendre généralement disponible une option qui change la donne pour ce scénario précis : le full caching pour les disques OS éphémères. Voyons ce que ça change concrètement, pour qui, et comment l’activer.

Un rappel rapide : à quoi sert un disque OS éphémère

Un disque OS éphémère (Ephemeral OS Disk) est créé directement sur le stockage local de la VM plutôt que sur le stockage Azure distant. Résultat : latence de lecture/écriture plus faible, réimagage bien plus rapide, et aucun coût de disque managé associé. La contrepartie logique, c’est que ces disques sont pensés pour des charges de travail sans état (stateless) : pas de déallocation possible, pas de snapshot, pas d’Azure Backup ni d’Azure Site Recovery dessus. Si ta VM doit survivre à un redémarrage avec ses données intactes, ce n’est pas l’outil qu’il te faut.

Jusqu’ici, le mode par défaut — le partial caching — répartissait le disque OS entre un disque de différences en local (qui reçoit toutes les écritures) et un disque de base sur le stockage managé (qui sert les lectures des fichiers d’origine). Ça fonctionne bien, mais ça garde une dépendance résiduelle au stockage distant pour les lectures.

Ce que change le full caching (désormais GA)

Avec le full caching, l’intégralité du disque OS est mise en cache sur le stockage local : la dépendance au stockage distant disparaît complètement en régime stabilisé. Concrètement, à la création de la VM, l’espace de stockage local disponible est réduit de deux fois la taille du disque OS, cet espace servant à stocker la copie complète du disque. La mise en cache se fait en arrière-plan après le démarrage de la VM, donc sans impact sur le temps de création.

Le bénéfice est double : de meilleures performances (plus aucune latence de lecture/écriture distante en régime stabilisé) et une résilience accrue face aux coupures de stockage distant, puisque le disque OS reste disponible même si Azure Storage rencontre un incident dans la région. C’est exactement le scénario visé par Microsoft : limiter les interruptions de service causées par des événements externes (intempéries, coupures d’alimentation) plutôt que par une panne applicative.

Prérequis et VM compatibles

Avant de te lancer, vérifie ces points :

• Le disque OS doit être stateless (c’est déjà une condition du mode éphémère en général).
• La taille du stockage local de la taille de VM choisie doit être supérieure à 2 fois la taille du disque OS + 1 Gio.
• Il faut utiliser la version d’API 2025-04-01 ou ultérieure.
• Seules les tailles de VM avec 8 vCPU ou plus sont éligibles pour l’instant (le support des tailles à 2 et 4 vCPU est prévu pour une version future) : toutes les séries N, L, M et H, ainsi que les séries D, DC, E, Eb et EC en v5/v6/v7, et les séries F en v6/v7.

Autre bonne nouvelle côté budget : le full caching ne coûte rien de plus que les tarifs standards de VM et de disque — un point confirmé explicitement dans la FAQ officielle Microsoft Learn. Si tu suis de près tes coûts Azure comme on en parlait dans notre article FinOps sur Cost Management, c’est un gain de résilience qui ne vient pas grignoter ton budget.

Comment l’activer

Avec Azure CLI

az vm create \
  --resource-group monGroupeRessources \
  --name maVM \
  --image imageChoisie \
  --size Standard_D8ds_v6 \
  --ephemeral-os-disk true \
  --ephemeral-os-disk-placement NvmeDisk \
  --ephemeral-os-disk-enable-full-caching true \
  --os-disk-caching ReadOnly \
  --admin-username azureuser \
  --generate-ssh-keys

Le paramètre clé est --ephemeral-os-disk-enable-full-caching true. Pour un scale set, le même paramètre s’applique avec az vmss create.

Avec un template ARM

Ajoute la propriété diffDiskSettings à la ressource Microsoft.Compute/virtualMachines (ou virtualMachineScaleSets), en définissant enableFullCaching à true et en utilisant la version d’API 2025-04-01 ou ultérieure. Si tu déploies tes VM via des modules standardisés — comme les Azure Verified Modules abordés dans notre article sur les Azure Landing Zones — c’est le genre de paramètre à intégrer directement dans ton module de VM réutilisable plutôt qu’à activer VM par VM.

Pour quelles charges de travail ça change vraiment la donne

Le full caching a un intérêt particulier pour les charges IO-intensives et stateless : entraînement et inférence IA, bases de données à quorum, analytique de données, traitement temps réel. Ce sont des workloads où éliminer la latence de lecture/écriture distante en régime stabilisé se traduit directement par un gain de débit mesurable, pas juste un confort théorique.

FAQ

Puis-je activer le full caching sur une VM existante ?

Non. Comme pour le mode éphémère en général, le full caching ne peut être configuré qu’à la création de la VM ou du scale set, pas appliqué après coup.

Quelle différence avec le mode partiel (par défaut) ?

En mode partiel, les écritures vont sur un disque local et les lectures des fichiers d’origine viennent d’un disque de base distant. En full caching, tout le disque OS — lectures et écritures en régime stabilisé — reste local, ce qui élimine la dépendance résiduelle au stockage distant.

Le full caching fonctionne-t-il sur les VM à 2 ou 4 vCPU ?

Pas encore : seules les tailles à 8 vCPU ou plus sont éligibles aujourd’hui. Le support des plus petites tailles est prévu pour une version future, sans date précise communiquée.

Est-ce compatible avec Azure Kubernetes Service ?

Une version équivalente pour les node pools AKS existe, mais elle est encore en préversion (et uniquement à la création d’un node pool, pas en mise à jour d’un pool existant) — à ne pas confondre avec la disponibilité générale sur les VM et VMSS classiques.

Ce qu’il faut retenir

Le full caching pour les disques OS éphémères est l’un de ces changements peu spectaculaires mais concrètement utiles : zéro coût additionnel, configuration à la création de VM, et un vrai gain de résilience pour tes workloads stateless les plus sensibles à la latence. Si tu déploies des VM ou des scale sets IO-intensifs sur des tailles éligibles, c’est une case à cocher qui ne coûte rien à essayer dès ton prochain déploiement.

Si ton organisation utilise encore Azure Virtual Desktop (classic), la date à cocher dans ton calendrier est le 30 septembre 2026. Passé ce délai, Microsoft arrête le support de ce modèle de service — celui qui existait avant l’intégration ARM d’Azure Virtual Desktop. Il te reste deux semaines pour migrer proprement ; voici ce qui change, pourquoi c’est important, et comment t’y prendre selon la taille de ton déploiement.

Pourquoi AVD (classic) disparaît

Azure Virtual Desktop (classic) — parfois appelé RDmi — est l’ancien modèle de service de bureau virtuel de Microsoft, antérieur à l’intégration native avec Azure Resource Manager. Depuis le 30 septembre 2023, il n’est déjà plus possible d’y créer de nouveaux tenants : seuls les déploiements existants continuaient d’être gérés et supportés. Cette période de transition de trois ans se termine officiellement le 30 septembre 2026, date à laquelle Microsoft retire définitivement le support d’AVD (classic).

La version actuelle d’Azure Virtual Desktop, elle, s’appuie entièrement sur Azure Resource Manager : tes host pools, groupes d’applications et workspaces deviennent des ressources Azure à part entière, gérables via le portail, Bicep/Terraform ou Azure RBAC — plutôt que via les cmdlets RDInfra propriétaires d’origine.

Ce que tu perds si tu ne migres pas à temps

Une fois la date de retrait passée, Microsoft ne garantit plus le support des ressources AVD (classic) restantes. Concrètement : plus d’assistance technique dédiée, plus de correctifs, et un risque de disruption de service pour tes utilisateurs si un composant sous-jacent évolue. Ce n’est pas une bascule automatique côté Microsoft — c’est à toi de migrer avant l’échéance.

Une exception existe : si ton environnement dépasse 500 groupes d’applications ou couvre plusieurs tenants, tu peux demander une exemption via un ticket de support Azure (type de problème « Tenant creation exemption request »). Ça ne dispense pas de migrer à terme, ça donne juste un délai supplémentaire pour les cas les plus complexes.

Les deux chemins de migration

Migration automatique (le cas le plus courant)

Microsoft fournit un module PowerShell dédié qui recrée automatiquement tes objets de service (tenants, host pools, groupes d’applications) côté ARM. Grandes lignes du processus :

# Preparer les modules necessaires
Install-Module -Name Microsoft.RDInfra.RDPowershell -RequiredVersion 1.0.3414.0 -Force
Install-Module -Name Az.DesktopVirtualization -Force
Install-Module -Name Az.Resources -Force

# Se connecter aux deux environnements
Add-RdsAccount -DeploymentUrl "https://rdbroker.wvd.microsoft.com"
Connect-AzAccount

# Lancer la migration via le module de migration dedie
Start-RdsOnboarding -TenantGroupName "<nom-tenant-group>"

Attention à deux limites documentées par Microsoft : la migration automatique ne fonctionne que pour des ressources créées dans la géographie US, et elle échoue au-delà de 500 groupes d’applications (c’est justement l’un des cas qui justifie une demande d’exemption). Le détail complet de la procédure est dans la documentation officielle de migration automatique.

Migration manuelle

Si ton environnement sort du cadre de l’outil automatique (géographie hors US, structure trop complexe, ou tu veux en profiter pour repartir sur une architecture plus propre), la migration manuelle consiste à recréer tes host pools et groupes d’applications directement dans le portail Azure ou en infrastructure as code, puis à rebasculer tes utilisateurs. C’est plus de travail, mais ça te donne l’occasion de nettoyer une architecture historique et d’appliquer les bonnes pratiques actuelles — y compris via une landing zone dédiée, comme on en parlait dans notre article sur les Azure Verified Modules pour tes landing zones.

Profites-en pour vérifier tes licences

La bascule est aussi un bon moment pour revoir ton modèle de licensing AVD/Windows 365, surtout si tu as des utilisateurs qui basculent entre bureau virtuel classique et Cloud PC. Les évolutions récentes du bundling M365 E3/E5 changent la donne sur ce terrain — on en détaille les implications dans notre article sur Microsoft Intune et le bundling M365 en 2026.

Et le client Remote Desktop classique dans tout ça ?

Ne confonds pas deux échéances distinctes : le retrait d’AVD (classic) côté service, dont on parle ici, et la fin de support du client Remote Desktop pour Windows, déjà effective depuis le 27 mars 2026. Ce client historique a été remplacé par Windows App, l’application unifiée de Microsoft pour se connecter à AVD, Windows 365, Microsoft Dev Box et les postes RDP classiques. Si tes utilisateurs sont encore sur l’ancien client, c’est une deuxième bascule à planifier en parallèle.

FAQ

Que se passe-t-il concrètement le 1er octobre 2026 si je n’ai pas migré ?

Tes ressources AVD (classic) restent en place mais ne sont plus supportées par Microsoft. Aucun correctif, aucune assistance technique dédiée, et un risque réel de disruption si un composant sous-jacent (agent, broker) évolue sans compatibilité assurée avec l’ancien modèle.

Puis-je demander un délai supplémentaire ?

Seulement si tu dépasses 500 groupes d’applications ou gères un environnement multi-tenant : dans ce cas, une exemption est possible via une demande de support Azure dédiée.

La migration automatique a-t-elle un impact pour les utilisateurs finaux ?

Elle recrée les objets de service côté ARM, mais planifie-la quand même en dehors des heures de forte utilisation et teste-la d’abord sur un host pool non critique — Microsoft documente des cas où une intervention manuelle reste nécessaire après la migration automatique.

En résumé

Il te reste deux semaines pour migrer d’Azure Virtual Desktop (classic) vers la version actuelle avant le retrait de support du 30 septembre 2026. Commence par vérifier si ton environnement est éligible à la migration automatique, prépare une fenêtre de test, et profite de la bascule pour revoir ton architecture et tes licences plutôt que de migrer à l’identique dans l’urgence.

Si tu déploies ou maintiens une landing zone Azure — la structure de base (management groups, policies, réseau hub, identité) sur laquelle repose toute ton organisation Azure — tu es probablement passé par du code Bicep ou Terraform artisanal, réécrit projet après projet. Les Azure Verified Modules (AVM) pour les landing zones changent la donne : ce sont des modules officiels, maintenus par Microsoft, prêts à l’emploi. On regarde ce que c’est concrètement, pourquoi ça compte, et comment démarrer.

C’est quoi, une Azure landing zone ?

Une landing zone Azure, c’est l’environnement de base sur lequel tu déploies tes charges de travail : hiérarchie de management groups, stratégies de gouvernance (Azure Policy), architecture réseau (hub-and-spoke ou virtual WAN), gestion des identités et rôles, journalisation centralisée. C’est le socle du Cloud Adoption Framework de Microsoft, pensé pour que chaque nouvelle application ou équipe atterrisse (d’où le nom) dans un environnement déjà sécurisé et conforme, sans repartir de zéro.

Le problème historique : chaque organisation finissait par coder sa propre version de cette landing zone, avec ses propres bugs, ses propres angles morts de sécurité, et une maintenance qui reposait entièrement sur l’équipe interne.

Les Azure Verified Modules, en bref

Les Azure Verified Modules (AVM) sont des modules d’infrastructure as code réutilisables, développés et maintenus par Microsoft, disponibles aussi bien en Bicep qu’en Terraform. Chaque module suit un processus de qualité strict : conception alignée sur le Well-Architected Framework, tests automatisés (unitaires et d’intégration), documentation générée automatiquement, revue par les équipes Azure avant publication. Concrètement, ça veut dire que tu n’écris plus de code Bicep/Terraform « à la main » pour déployer un réseau virtuel, une politique ou une identité managée : tu appelles un module versionné et testé, et tu passes juste tes paramètres.

Pour les landing zones spécifiquement, Microsoft publie une famille de modules pattern (avm/ptn/alz/*) qui couvrent la plateforme complète : gestion, connectivité, identité, monitoring, jusqu’à des modules « sandbox » pour tester rapidement une configuration.

Deux façons de les utiliser

Via l’accélérateur IaC Azure Landing Zones

L’accélérateur IaC officiel automatise le déploiement complet d’une landing zone plateforme en s’appuyant sur les AVM, que tu choisisses Bicep ou Terraform. Il fonctionne en quatre phases : choix du langage IaC et du système de contrôle de version, configuration des identifiants et abonnements, bootstrap de l’environnement (pipeline CI/CD, dépôt de code), puis personnalisation et déploiement continu. Il s’intègre nativement avec Azure DevOps et GitHub pour la partie pipelines.

En modules indépendants

Tu n’es pas obligé de passer par l’accélérateur complet : les modules AVM sont utilisables individuellement, dans ton propre code Bicep ou Terraform existant. Si tu as déjà une landing zone en place, tu peux migrer progressivement — module par module — plutôt que de tout réécrire d’un coup.

Pourquoi c’est le bon moment pour s’y mettre

Trois raisons concrètes de regarder les AVM landing zones maintenant plutôt que de continuer avec du code maison :

• Moins de dette de maintenance — les correctifs de sécurité et les nouvelles bonnes pratiques Azure sont intégrés par Microsoft dans les modules, tu n’as qu’à monter de version
• Cohérence architecturale — tous les modules suivent le même standard de nommage, de tagging et de structure, ce qui facilite l’onboarding d’une nouvelle personne dans l’équipe infra
• Portabilité entre Bicep et Terraform — les deux familles de modules visent la même architecture cible, utile si ton organisation change d’outil IaC ou fait cohabiter les deux

Points de vigilance avant de migrer une landing zone existante

Passer à AVM sur une landing zone déjà en production n’est pas anodin :

• Compare d’abord l’état actuel de tes ressources avec ce que produirait le module AVM équivalent, pour repérer les écarts de configuration avant tout déploiement
• Teste la migration dans un abonnement sandbox avant de toucher à la plateforme de production — le module avm/ptn/alz/sandbox existe justement pour ça
• Prévois une fenêtre de changement, même si les modules sont conçus pour être idempotents : une landing zone touche des management groups et des policies qui peuvent impacter plusieurs équipes

FAQ

Les Azure Verified Modules sont-ils gratuits ?

Oui, les modules eux-mêmes sont open source et gratuits (disponibles sur le Bicep Registry et le Terraform Registry). Tu paies uniquement les ressources Azure qu’ils déploient, comme pour n’importe quel déploiement manuel.

Faut-il choisir entre Bicep et Terraform pour utiliser AVM ?

Les deux familles de modules existent en parallèle et visent la même architecture. Le choix dépend surtout de ton écosystème existant : reste sur Terraform si tu gères déjà du multi-cloud ou si ton équipe le maîtrise, privilégie Bicep si tu es 100% Azure et que tu veux un outil natif sans état à gérer côté backend.

Les AVM landing zones supportent-ils les clouds souverains (Azure Government, 21Vianet) ?

Non pour l’instant : le déploiement via portail Azure et les modules AVM ciblent les régions Azure publiques. Sur les clouds souverains, il faut partir du code Bicep/Terraform de l’accélérateur comme base et l’adapter aux contraintes spécifiques de ces environnements.

Pour aller plus loin

Si tu gères déjà tes ressources Azure en Terraform, notre article sur la migration vers Terraform AzureRM 5.0 couvre les changements du provider à connaître avant d’adopter des modules AVM en Terraform. Et si ta landing zone doit s’appuyer sur des pipelines Azure DevOps, jette aussi un œil à notre article sur les Managed DevOps Pools, pensés pour justement héberger ce type de pipeline d’infrastructure sans te soucier de la maintenance des agents.

Que tu partes d’une landing zone vierge ou que tu migres une plateforme existante, commence petit : déploie un module AVM isolé dans un abonnement sandbox, compare le résultat avec ton architecture cible, et élargis progressivement. C’est la meilleure façon d’adopter ces modules sans y perdre une semaine de debug.

Sources

• Platform landing zone implementation options — Microsoft Learn
• Azure Verified Modules — site officiel
• Deploy Azure landing zones — Microsoft Learn
• Release of Bicep Azure Verified Modules for Platform Landing Zone — Microsoft Community Hub