Terraform AzureRM 5.0 : zéro Resource Provider enregistré par défaut — le runbook de migration sans détruire vos states

Passer de azurerm 4.x à 5.0 ressemble, sur le papier, à un changement d’une ligne dans un bloc required_providers. En pratique, c’est une opération sur l’état : le comportement par défaut du provider change, des ressources disparaissent du schéma, et certains attributs changent de type. Voici ce qu’il faut avoir compris — et testé — avant que la pipeline de production ne le découvre pour vous.

Ce que change réellement la 5.0

La branche 5.0 du provider AzureRM est disponible en version stable depuis fin juillet 2026, première majeure depuis la 4.x. Trois ruptures dominent, et une seule d’entre elles est un changement de schéma classique :

1. resource_provider_registrations passe de legacy à none : le provider n’enregistre plus automatiquement les Resource Providers (RP) de l’abonnement.
2. enhanced_validation quitte le niveau racine du provider pour rejoindre le bloc features, et la validation des régions et des noms de RP est désactivée par défaut.
3. Les ressources dépréciées depuis la 3.x/4.x sont supprimées — azurerm_app_service, azurerm_app_service_plan, azurerm_function_app et compagnie.

Les points 1 et 2 ne modifient pas le state : ils modifient ce que le provider fait avant de lire le state. Le point 3, lui, rend le state illisible pour le provider si des ressources supprimées y figurent encore. C’est cette combinaison qui transforme un bump de version en chantier.

Rupture n°1 — l’enregistrement des Resource Providers

Historiquement, azurerm enregistrait à l’initialisation une soixantaine de RP jugés « courants » sur l’abonnement ciblé. Ce comportement, exposé sous le nom l…