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.
Laisser un commentaire