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