Terraform 1.17 : ce qu'apporte la version candidate
Terraform 1.17 passe en release candidate : Terraform Policy en disponibilité générale, option -minimal-refresh et variables dans les providers.
Terraform 1.17 approche de sa version finale. HashiCorp a publié le 7 octobre 2026 la première release candidate (v1.17.0-rc1) de son outil d'infrastructure as code, après une version alpha fin août et deux bêtas en septembre. Au menu : la disponibilité générale de Terraform Policy, une nouvelle option de planification plus économe et davantage de souplesse dans la déclaration des providers.
Terraform Policy sort du statut expérimental
C'est la nouveauté la plus visible. Selon les notes de version, le drapeau -policies des commandes plan, apply et query ne nécessite plus de build expérimental ni l'option -allow-experimental-features. Les équipes peuvent donc évaluer des règles de conformité directement dans leur flux Terraform standard.
La fonctionnalité s'étend aussi à terraform query : les politiques peuvent évaluer les ressources découvertes par les blocs list. Plusieurs correctifs accompagnent ce passage en disponibilité générale, notamment l'affichage des résultats « Unknown » et « N/A » lors de l'évaluation des ressources découvertes, et le rejet d'un chemin -policies qui n'est pas un répertoire.
Un refresh limité aux ressources modifiées
La nouvelle option -minimal-refresh de la planification ne rafraîchit que les ressources pour lesquelles des changements sont proposés. Sur des états volumineux, où le refresh complet interroge chaque ressource auprès des API du fournisseur cloud, l'option vise à réduire le travail effectué à chaque plan. Elle reste facultative : le comportement par défaut ne change pas.
Variables et locals dans les exigences de providers
Terraform 1.17 autorise désormais l'usage de variables et de valeurs locals dans les exigences de providers. Jusqu'ici, ces déclarations devaient être écrites en dur, ce qui compliquait la factorisation de configurations partagées entre plusieurs environnements.
Les autres changements
Les notes de version listent plusieurs améliorations plus ciblées :
terraform initaffiche les versions des providers dans ses messages de journal ;- le framework de test accepte
mock_providerpour les ressources éphémères, et l'ordre de nettoyage des tests devient déterministe ; terraform loginavertit l'utilisateur après connexion s'il est soumis à une politique de durée de vie des jetons définie par son organisation ;- les fonctions
powetlogne provoquent plus de panique lorsque le résultat n'est pas un nombre ; - les diagnostics émis lors du renouvellement d'une ressource éphémère sont désormais affichés, ce qui peut faire apparaître des avertissements auparavant masqués.
HashiCorp signale enfin un point d'attention pour l'outillage : la sortie JSON de terraform version comporte un nouveau champ format_version. Les outils existants peuvent l'ignorer, mais il est appelé à évoluer.
Où en est la branche 1.16
La version stable actuelle reste Terraform 1.16.5, publiée le 2 octobre 2026. La branche 1.16, sortie le 26 août, avait notamment introduit les blocs import à l'intérieur des modules, l'option destroy = false dans les blocs lifecycle et une sortie Mermaid pour terraform graph. Ses versions correctives ont surtout corrigé des paniques et des cas limites d'import.
Tester avant la version finale
Comme pour toute release candidate, l'usage en production n'est pas recommandé : c'est le moment de tester ses modules et pipelines CI/CD sur un environnement isolé et de remonter les anomalies. Les équipes qui ont migré vers le fork libre peuvent comparer avec les évolutions récentes d'OpenTofu 1.13, et celles qui pilotent des clusters avec Terraform garderont un œil sur Kubernetes 1.37.