Terraform 1.17 fait sortir la politique-as-code de l’expérimental

21 octobre 2026. HashiCorp publie Terraform 1.17.0, qui fait passer Terraform Policy en disponibilité générale — le drapeau -policies devient utilisable sur plan, apply et query sans build expérimental. 28 octobre 2026. La version de correctif 1.17.1 suit. 1.17. La ligne est recompilée avec Go 1.26.10, qui cesse de faire confiance à des autorités intermédiaires eMudhra compromises. Pourquoi c’est important : la politique-as-code entre dans le chemin du plan par défaut, et c’est une décision d’architecture autant qu’une mise à jour de CLI.

La nouveauté de fond : la politique rejoint le plan

Terraform Policy n’est pas une fonctionnalité inédite — elle existait en expérimental. Ce qui change, c’est le statut. Jusqu’ici, pour évaluer une politique, il fallait une build expérimentale et le drapeau -allow-experimental-features. Terraform 1.17 supprime cette contrainte : -policies est directement disponible sur plan, apply et query.

La conséquence est concrète pour une équipe d’infrastructure. Une politique s’écrit en HCL, le même langage que le reste de la configuration, et s’évalue au moment du plan. Une règle qui interdit les buckets S3 publics, ou qui impose un tag de coût sur chaque ressource, se transforme en échec de plan avant que l’infrastructure ne change. Le cadre et le langage sont documentés sur developer.hashicorp.com/terraform/policy.

# Évaluer une politique au moment du plan (GA, sans drapeau expérimental)
terraform plan -policies=./policies

# Interroger les ressources découvertes par des blocs list
terraform query -policies=./policies

Les politiques de query peuvent évaluer des ressources découvertes par des blocs list et restituer le résultat en forme lisible ou en JSON — ce qui les rend automatisables dans un pipeline.

Un levier de performance : -minimal-refresh

La deuxième nouveauté utile n’a rien à voir avec la politique, mais elle répond à une plainte récurrente des équipes qui gèrent de grands fichiers d’état. L’option -minimal-refresh limite le rafraîchissement aux seules ressources qui ont des changements proposés, au lieu de rafraîchir chaque ressource de l’état.

Sur un état de plusieurs dizaines de milliers de ressources, la différence se mesure en minutes de plan économisées. C’est un levier simple, sans migration, à tester en premier pour les équipes dont les plans traînent.

# Réduire le temps de plan sur les grands états
terraform plan -minimal-refresh

Les fournisseurs deviennent paramétrables

Le troisième changement touche la structuration du code. Terraform 1.17 accepte désormais des variables et des locals dans le bloc required_providers. On peut ainsi paramétrer une contrainte de version ou une adresse source sans la coder en dur.

locals {
  aws_provider_version = ">= 5.0.0, < 6.0.0"
}

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = local.aws_provider_version
    }
  }
}

C’est un gain de maintenabilité pour les organisations qui pilotent un grand nombre de modules depuis un fichier central : la politique de version se définit à un seul endroit, et se propage.

Ce qui se cache dans les correctifs : une confiance CA retirée

Les notes de version portent un détail que les titres ne montrent pas. Terraform 1.17 est recompilé avec Go 1.26.10, qui retire la confiance accordée à des certificats émis par un ensemble d’autorités intermédiaires eMudhra compromises, référencé CVE-2026-111943.

La portée est étroite mais réelle : si un endpoint de registre de fournisseurs ou une API de fournisseur de votre environnement s’appuyait sur ces autorités, la connexion échouera après la mise à jour. C’est le genre de changement qui ne se voit pas dans le diff fonctionnel et qui se révèle en production — d’où l’intérêt de lire la ligne Go autant que la ligne HCL.

Deux correctifs discrets complètent le tableau. Les fonctions pow et log ne déclenchent plus de panic quand le résultat n’est pas un nombre : elles lèvent désormais une erreur explicite au lieu de renvoyer un infini que rien ne pouvait exploiter en aval. Et les diagnostics émis pendant le renouvellement d’une ressource éphémère sont maintenant remontés à l’utilisateur au lieu d’être silencieusement avalés — des équipes découvriront des avertissements qui étaient jusque-là masqués.

Le framework de test suit le mouvement : mock_provider accepte désormais les ressources éphémères, ce qui permet de tester des configurations qui s’appuient sur ce mécanisme sans infrastructure réelle. C’est un détail pour l’auteur de modules plus que pour l’opérateur, mais il signale la direction prise par la ligne 1.17 : consolider les fonctionnalités récentes plutôt qu’en introduire de nouvelles.

La question de fond : où mettre la politique, désormais ?

La disponibilité générale de Terraform Policy relance une question d’architecture que beaucoup d’équipes croyaient tranchée. Trois options coexistent, et elles ne font pas le même travail.

Terraform Policy évalue la politique dans la CLI, au moment du plan, dans le même langage que l’infrastructure. Son avantage est l’immédiateté : pas de service tiers, pas de moteur séparé. Sa limite est le périmètre : elle ne voit que ce que Terraform voit.

OPA/Conftest évalue des politiques sur n’importe quelle donnée — du Rego, appliqué aux plans au format JSON. Son avantage est la généralité et l’écosystème : les mêmes règles peuvent servir à la fois pour Terraform, Kubernetes et d’autres formats. Sa limite est l’intégration : il faut câbler le pipeline.

Sentinel, la politique historique de HashiCorp, vit surtout dans Terraform Cloud et Enterprise — pas dans la CLI open source. C’est la différence à retenir : Terraform Policy apporte à la CLI libre une capacité qui était jusqu’ici réservée à l’offre commerciale.

Le choix dépend de la taille du parc et de l’endroit où la politique doit vivre. Une équipe mono-Cloud, mono-outil, trouvera dans Terraform Policy une politique native sans pièce en mouvement. Une organisation qui gouverne plusieurs outils et plusieurs formats gardera OPA/Conftest comme couche unique de politique, et utilisera Terraform Policy au plus comme contrôle de premier niveau.

Le contexte du fork : OpenTofu n’a pas attendu

Impossible de parler de Terraform en 2026 sans le contrepoint OpenTofu. Le fork est né en 2023 de la décision de HashiCorp de passer Terraform sous Business Source License (BSL). Ce blog a déjà documenté la montée d’OpenTofu en alternative, y compris sa ligne 1.13 et son approche de l’état.

Terraform Policy est un argument de différenciation de HashiCorp : une capacité de gouvernance intégrée au plan, là où OpenTofu mise sur la compatibilité et le chiffrement d’état natif. Pour un décideur, la question n’est pas seulement technique — elle est aussi de savoir de quel côté les fonctionnalités de gouvernance s’accumulent à l’avenir. Une politique-as-code GA dans la CLI libre est un signal clair que HashiCorp veut garder la gouvernance dans son giron, même en open source.

Verdict

Terraform 1.17 est une mise à jour mineure en numéro, majeure en signal : la politique-as-code entre dans la CLI par défaut, et la mise à jour est à faible risque — aucun breaking change n’est annoncé dans le changelog.

Si vous tournez déjà sous Terraform, montez vers 1.17 sans attendre : la mise à jour est bénigne (terraform init -upgrade puis relancez votre pipeline plan/apply), et vous récupérez au passage -minimal-refresh et la correction Go des autorités eMudhra. Si la gouvernance est votre sujet, testez Terraform Policy sur un plan réel avant de choisir : écrivez une règle simple (interdiction d’un bucket public, tag de coût obligatoire) et mesurez si la politique native couvre votre besoin ou si OPA/Conftest reste la couche unique dont vous avez besoin. Si vous êtes en OpenTofu, cette version n’est pas pour vous, mais elle est à suivre : elle montre où HashiCorp concentre ses efforts de gouvernance, et ce décalage se creuse à chaque release. La règle à retenir : une politique qui s’évalue dans le plan vaut mieux qu’une politique qui s’évalue après coup — et le plan, désormais, sait le faire sans caveat.

Références

• HashiCorp — Terraform 1.17.0 release notes (21 octobre 2026)
• HashiCorp Developer — Terraform Policy
• Terraform Pilot — « Terraform 1.17.0: Policy GA, Minimal Refresh, and Variables in Provider Requirements » (2026)
• Mango Developer — « Terraform 1.17: -minimal-refresh and Policy GA » (2026)
• Releasebytes — « Terraform v1.17.0: Policy General Availability and Core Updates » (2026)