Terraform 1.17 ajoute -minimal-refresh pour accélérer les plans et fait passer Policy en GA
Le 7 octobre 2026, HashiCorp publie Terraform 1.17.0-rc1 avec une option de planification -minimal-refresh qui ne rafraîchit que les ressources ayant des changements proposés, la prise en charge des variables dans les exigences de providers et la disponibilité générale de Terraform Policy. Une release candidate à tester sur les gros parcs, pas encore à déployer partout.
Le 7 octobre 2026, HashiCorp publie Terraform 1.17.0-rc1, la première release candidate de la version 1.17. Au menu : une option de planification -minimal-refresh qui ne rafraîchit que les ressources ayant des changements proposés, la prise en charge des variables dans les exigences de providers, et le passage en disponibilité générale de Terraform Policy. Pourquoi c’est important : la lenteur de terraform plan sur les gros parcs est une plainte récurrente, et cette release candidate s’attaque directement à ce goulot.
Ce que change -minimal-refresh
Le comportement historique de terraform plan est de rafraîchir l’état de toutes les ressources avant de calculer le diff. Sur un parc de plusieurs centaines de ressources, cette phase de refresh domine le temps d’exécution, alors que l’essentiel des ressources n’a pas bougé depuis le dernier apply.
L’option -minimal-refresh inverse la logique : elle ne rafraîchit que les ressources qui ont des changements proposés. En pratique, quand vous modifiez une seule ressource dans un plan qui en compte des centaines, le refresh se concentre sur ce qui est réellement concerné au lieu de réinterroger l’ensemble du fournisseur cloud. C’est une optimisation ciblée sur le cas le plus courant — le petit changement dans un grand état.
La nuance à comprendre : -minimal-refresh est un opt-in qui modifie le périmètre du refresh, pas la sémantique du plan. Un plan produit avec cette option peut ignorer des dérives extérieures sur les ressources non concernées, puisqu’elles ne sont pas rafraîchies. C’est un compromis entre vitesse et exhaustivité, à évaluer selon que votre parc tolère ou non un refresh partiel.
Pourquoi le refresh pèse autant
Le refresh est la phase où Terraform interroge chaque provider pour connaître l’état réel des ressources, afin de détecter les dérives entre l’état déclaré et la réalité. Ce travail est indispensable à un plan fiable, mais il est coûteux : chaque appel d’API vers un cloud provider prend du temps, et sur un parc large, le cumul de ces appels domine largement le temps de plan.
Le problème est aggravé par un fait simple : la plupart du temps, rien n’a changé. Quand vous modifiez une seule ressource sur un parc de cinq cents, le refresh des quatre cent quatre-vingt-dix-neuf autres ne sert qu’à confirmer qu’elles n’ont pas bougé. C’est précisément ce gaspillage que -minimal-refresh élimine, en concentrant le travail là où le plan propose un changement.
Le gain dépend du parc. Sur un état où les changements sont rares et localisés, la différence peut être spectaculaire ; sur un parc où tout bouge à chaque itération, l’option n’apporte presque rien, puisque tout serait rafraîchi de toute façon. C’est une optimisation pour le cas courant, pas une baguette magique — et elle suppose d’accepter que les dérives extérieures sur les ressources non rafraîchies restent invisibles jusqu’à leur prochain refresh.
Les variables dans les exigences de providers
La deuxième nouveauté de fond est la prise en charge des variables et des locals dans les exigences de providers. Jusqu’ici, le bloc required_providers imposait des valeurs littérales : la source et la version d’un provider étaient figées dans le code, ce qui compliquait la réutilisation d’un même module dans des contextes où la version ou l’origine du provider devait varier.
Désormais, on peut paramétrer ces exigences, ce qui débloque deux scénarios. Le premier est la réutilisation de modules : un module peut exiger un provider dont la version est injectée par l’appelant plutôt que codée en dur. Le second est la gestion multi-environnements : une même configuration peut pointer vers une version de provider différente selon l’environnement, sans dupliquer le code. C’est une demande de longue date de la communauté, référencée par l’issue #39153.
Terraform Policy passe en GA
Le troisième pilier de la version est la disponibilité générale de Terraform Policy. Le drapeau -policies des commandes plan, apply et query ne nécessite plus de build expérimental ni du drapeau -allow-experimental-features. Concrètement, les équipes peuvent désormais évaluer leurs ressources contre des politiques pendant le plan et l’apply, sans activer un mode expérimental.
La commande terraform query évalue les ressources découvertes par les list blocks et produit des résultats lisibles en clair ou en JSON. C’est la brique qui manquait pour faire de la policy-as-code native dans Terraform, sans dépendre d’un outil tiers : les règles de conformité vivent au même endroit que l’infrastructure qu’elles contrôlent.
Le reste de la release est plus discret mais utile : les journaux de terraform init s’enrichissent des versions de providers, ce qui facilite le diagnostic des écarts de version entre environnements.
Les tests et les ressources éphémères progressent
Deux améliorations moins visibles méritent l’attention des équipes qui automatisent. La première : terraform test gagne le support de mock_provider pour les ressources éphémères. Concrètement, on peut tester une configuration qui utilise ces ressources sans les créer réellement, en simulant le provider. C’est un pas de plus vers des tests d’infrastructure reproductibles et rapides, plutôt que des validations qui exigent un vrai compte cloud.
La seconde concerne la gestion des ressources éphémères elles-mêmes. Terraform affiche désormais les diagnostics émis lors du renouvellement d’une ressource éphémère, des avertissements qui étaient auparavant perdus silencieusement. Une erreur de renouvellement qui passait sous silence pouvait produire des échecs en aval difficiles à expliquer ; la rendre visible simplifie le diagnostic. À cela s’ajoute un correctif de robustesse : pow et log ne font plus paniquer Terraform quand leur résultat n’est pas un nombre.
Ces changements sont discrets, mais ils renforcent la même idée que le reste de la version : rendre Terraform plus prévisible et plus observable dans les scénarios réels, où les ressources éphémères et les tests automatisés sont devenus la norme.
Un changement de contrat à surveiller
La release candidate introduit aussi un détail à noter pour les intégrations : la sortie JSON de la commande version inclut désormais un champ format_version. HashiCorp l’annonce comme un garde-fou pour de futures évolutions du format JSON, en supposant que les outils existants ignorent les champs inconnus. C’est un signal pour les équipes qui parsent cette sortie : prévoyez de suivre format_version plutôt que de supposer la structure figée.
Le statut de release candidate doit aussi calmer les ardeurs. 1.17.0-rc1 n’est pas une version stable : elle sert à tester les nouvelles fonctionnalités avant la sortie définitive. Les correctifs de la branche 1.16 continuent en parallèle — 1.16.5 est sorti le 30 septembre 2026 avec deux correctifs de crash. Les équipes en production doivent rester sur 1.16 et réserver la 1.17 aux environnements de test.
Verdict
Si vos terraform plan sont lents sur un gros parc, la -minimal-refresh de la 1.17 est la fonctionnalité à tester en priorité : elle attaque directement la phase de refresh qui domine vos temps de plan, à condition d’accepter un refresh partiel sur les ressources non concernées. Si vous attendiez une policy-as-code native, la GA de Terraform Policy est le signal pour commencer à écrire vos politiques et à les brancher sur plan et apply. Mais ne généralisez pas en production sur une release candidate : validez le comportement en préproduction, surveillez le champ format_version si vous parsez la sortie JSON, et basculez seulement quand la version stable de 1.17 sera publiée.