Terraform AzureRM 5.0 : ce qui change et comment migrer sans casse

Terraform AzureRM 5.0 est disponible : pourquoi ce n’est pas une montée de version comme les autres

Si tu gères de l’infra Azure avec Terraform, tu as sans doute déjà vu passer l’annonce : le provider hashicorp/azurerm vient de passer en version majeure 5.0, officiellement disponible en General Availability. Et contrairement aux montées de version mineures que tu appliques d’un terraform init -upgrade sans trop y réfléchir, celle-ci mérite que tu t’arrêtes cinq minutes avant de foncer.

Pourquoi ? Parce que cette version 5.0 change des comportements par défaut qui touchent quasiment tous les projets Terraform sur Azure, même les plus simples. Si tu appliques la montée de version en production sans préparation, tu risques un terraform plan qui explose de partout — ou pire, un apply qui échoue en plein déploiement. Dans cet article, on regarde ensemble ce qui change concrètement, comment migrer sans y laisser ta soirée, et comment éviter les pièges classiques.

Ce qui casse vraiment avec AzureRM 5.0

HashiCorp a publié un guide de migration officiel, mais voici les points qui vont te concerner en priorité.

1. Plus aucun Resource Provider enregistré par défaut

C’est le changement le plus lourd de conséquences. En version 4.x, le provider enregistrait automatiquement une soixantaine de Resource Providers Azure (Microsoft.Compute, Microsoft.Network, etc.) au premier apply. Cette magie disparaît totalement en 5.0 : plus rien n’est enregistré automatiquement.

Concrètement, si ton abonnement Azure n’a pas déjà ces providers enregistrés (ce qui est fréquent sur un abonnement neuf ou une souscription bien nettoyée), tes déploiements vont échouer avec des erreurs du type MissingSubscriptionRegistration. Deux options s’offrent à toi :

• Lister explicitement les providers dont tu as besoin dans le bloc provider "azurerm"
• Restaurer temporairement le comportement historique avec resource_provider_registrations = "legacy", le temps de migrer proprement

provider "azurerm" {
  features {}
  resource_provider_registrations = "core"
  resource_providers_to_register   = [
    "Microsoft.ContainerService",
    "Microsoft.KeyVault"
  ]
}

Ça t’évite de découvrir le problème en pleine CI/CD un vendredi après-midi.

2. La validation renforcée change de camp

Le bloc enhanced_validation déménage à l’intérieur de features, et surtout, la validation des régions et des providers passe à désactivée par défaut. Résultat : les erreurs qui remontaient auparavant pendant le plan (une région mal orthographiée, par exemple) ne se déclenchent maintenant qu’au moment de l’apply. Si tu veux garder ce filet de sécurité en amont, réactive-le explicitement :

provider "azurerm" {
  features {}
  enhanced_validation {
    locations = true
  }
}

3. Validation Preflight, mais seulement pour six ressources

Nouveauté intéressante : le provider peut désormais valider certaines charges utiles directement contre l’API Preflight d’Azure, avant même de tenter le déploiement. Le hic, c’est que ça ne couvre pour l’instant que six types de ressources : App Service Environment v3, Service Plan, Grafana, Redis, NGINX et Event Grid. Pour tout le reste, cette protection ne s’applique pas — ne compte pas dessus comme filet universel.

4. Les ressources App Service et Function App historiques disparaissent

Si ton code utilise encore azurerm_app_service ou azurerm_function_app, il va falloir migrer vers les variantes typées par OS : azurerm_linux_web_app, azurerm_windows_web_app, azurerm_linux_function_app, azurerm_windows_function_app. Ce n’est pas qu’un renommage : ça implique une migration d’état Terraform (terraform state mv ou import) puisque le schéma des ressources change.

5. Des changements de schéma plus discrets, mais tout aussi cassants

En plus des gros titres, attends-toi à des surprises plus subtiles : des propriétés renommées avec parfois une inversion de polarité (par exemple disable_automatic_rollback devient automatic_rollback_enabled — attention au sens inverse du booléen), des attributs autrefois optionnels devenus obligatoires, des types qui passent de liste à set, et des blocs imbriqués promus en ressources autonomes. Ce sont typiquement les erreurs qui ne sautent pas aux yeux en relisant le changelog en diagonale.

Comment migrer sans casser ta prod

Voici la méthode que je te recommande, plutôt que de foncer tête baissée :

• Épingle la version avant de migrer : version = "= 4.x.x" le temps de préparer le terrain, puis bascule sur = 5.0.0 de façon contrôlée plutôt que d’utiliser une contrainte ouverte comme ~> 5.0 dès le départ.
• Teste sur une souscription non-production. Si tu n’en as pas, crée un abonnement Azure dédié aux tests d’infra — ça coûte moins cher qu’un incident en prod.
• Lance un terraform plan complet et lis-le en entier, pas juste le résumé. C’est là que tu repères les changements de schéma silencieux.
• Traite les migrations d’état séparément des autres changements, pour isoler les risques (App Service/Function App notamment).
• Automatise la vérification dans ta pipeline CI/CD : un job qui bloque le merge si le plan détecte un destroy non attendu te sauve la mise plus d’une fois.

Et si tu n’es pas encore prêt à migrer ?

Rien ne t’oblige à sauter sur la 5.0 le jour de sa sortie. Tu peux tout à fait rester sur la branche 4.x le temps de planifier la migration — HashiCorp continue de publier des correctifs sur les anciennes versions majeures pendant une période de transition. Consulte le registre officiel du provider pour suivre les releases et leur statut de support.

Si c’est l’outil lui-même que tu remets en question plutôt que la version du provider, regarde mon comparatif OpenTofu vs Terraform.

Ce qui compte, c’est que la migration soit un choix planifié et testé, pas une surprise découverte parce qu’une contrainte de version trop permissive a tiré la 5.0 automatiquement dans ta CI.

Automatise la détection des breaking changes avant qu’ils ne te surprennent

Une bonne pratique que je te recommande, au-delà de cette migration précise : intègre un contrôle statique dans ta pipeline CI/CD pour repérer les changements risqués avant même d’arriver au plan. Des outils comme tflint ou checkov peuvent te signaler l’usage de ressources dépréciées ou de mauvaises pratiques directement dans ta merge request, avant que ça n’atteigne l’environnement de test.

# Exemple minimal d'étape CI
- name: Lint Terraform
  run: |
    tflint --init
    tflint
- name: Terraform plan
  run: terraform plan -out=tfplan

Combine ça avec une revue systématique du plan par un humain avant tout apply en production, même si ta pipeline est largement automatisée. Les changements de schéma silencieux comme ceux qu’AzureRM 5.0 introduit sont justement le genre de choses qu’un œil attentif repère, mais qu’un pipeline purement automatisé peut laisser passer si tu n’as pas configuré les bons garde-fous.

FAQ

Dois-je migrer immédiatement vers AzureRM 5.0 ?

Non, pas dans l’urgence. Prends le temps de tester en environnement isolé. Fixe une version explicite dans tes fichiers Terraform pour éviter qu’une mise à jour automatique te bascule en 5.0 sans préparation.

Le comportement « legacy » d’enregistrement des providers va-t-il disparaître ?

HashiCorp le présente comme une option de transition. Ne construis pas ta stratégie long terme dessus : c’est fait pour t’aider à migrer en douceur, pas pour rester en place indéfiniment.

Comment je repère les ressources dépréciées dans mon code existant ?

Le guide de migration officiel liste les ressources et attributs concernés. Un passage par terraform plan avec la 5.0 activée en environnement de test te montrera aussi les erreurs de schéma directement.

Est-ce que ça concerne aussi Bicep ou seulement Terraform ?

Uniquement Terraform et le provider AzureRM. Bicep, qui parle directement à l’API Azure Resource Manager, n’est pas concerné par ces changements côté provider tiers.

Si tu hésites encore entre les deux outils, j’ai comparé Terraform et Bicep pour Azure.

Que faire si je découvre un breaking change non documenté ?

Ouvre une issue sur le dépôt GitHub du provider. La communauté et l’équipe HashiCorp sont réactives, et ça évite à d’autres admins de tomber dans le même piège.

En résumé

AzureRM 5.0 apporte de vraies améliorations — moins de magie cachée, plus de contrôle explicite sur ce que Terraform fait dans ton abonnement Azure. Mais ça se paie par une migration qui demande de la méthode. Prends le temps de tester, épingle tes versions, et lis vraiment tes plan avant de les appliquer. Ton futur toi (et ton équipe d’astreinte) t’en remerciera.

Tu as déjà migré et rencontré un cas particulier pas couvert ici ? Partage-le, ça aide toute la communauté Azure/Terraform à anticiper.