Terraform 1.16 autorise les blocs import dans les modules et préserve les secrets entre plan et apply

12 août 2026. HashiCorp publie Terraform 1.16.0-rc1, et le même jour une 1.17.0-alpha. Deux changements dominent le lot : les blocs import fonctionnent désormais à l’intérieur des modules, et le nouveau bloc store de terraform_data conserve les valeurs éphémères et sensibles entre le plan et l’apply.

Pour une équipe qui gère de l’infrastructure existante, la première nouveauté est celle qui manquait depuis des années : adopter Terraform sans réécrire toute l’histoire de son infrastructure.

Les blocs import entrent dans les modules

Depuis Terraform 1.5, sorti en 2023, les blocs import permettent d’importer une ressource existante dans l’état sans la détruire. La syntaxe est simple :

import {
  to = aws_vpc.main
  id = "vpc-0abcd1234ef567890"
}

Mais ils avaient une limitation structurelle : ils n’étaient autorisés qu’à la racine de la configuration. En pratique, cela forçait une danse pénible — importer la ressource au niveau racine, puis la déplacer manuellement dans un module, en déplaçant l’état au passage. Pour une base de code modulaire, c’était l’équivalent d’un déménagement à la main.

Terraform 1.16 lève la restriction. Un bloc import peut désormais cibler une ressource à l’intérieur d’un module :

module "networking" {
  source = "./modules/networking"
}

import {
  to = module.networking.aws_vpc.main
  id = "vpc-0abcd1234ef567890"
}

La conséquence est directe pour l’adoption. Adopter Terraform sur une infrastructure déjà en production, c’est toujours la même séquence : générer la configuration, puis importer chaque ressource. Jusqu’ici, l’import à la racine obligeait à casser la modularité au moment précis où on essaie de l’instaurer. Désormais, on écrit la configuration modulaire d’emblée, et les blocs import s’insèrent là où vivent réellement les ressources. C’est un changement de méthode, pas une simple commodité.

Pour mesurer le chemin parcouru, il faut se souvenir de l’état antérieur. Avant les blocs import de la 1.5, l’import se faisait à la main : la commande terraform import d’un côté, l’écriture du bloc de configuration de l’autre, avec une correspondance d’identifiants fragile et aucune génération automatique. Les blocs import ont automatisé cette génération, mais en la cantonnant à la racine. Déplacer ensuite une ressource vers un module imposait un bloc moved et une manipulation d’état à risque, souvent faite à la main. La 1.16 supprime cette dernière étape manuelle — et c’est elle qui produisait le plus d’erreurs.

terraform_data et le bloc store : des secrets qui survivent au plan

La seconde nouveauté majeure tient en un bloc. terraform_data — la ressource managée introduite en 1.5 pour remplacer les triggers du null_resource — reçoit un bloc store capable de conserver des valeurs éphémères et sensibles entre le plan et l’apply.

Le problème qu’il résout est concret. Terraform distingue deux phases : le plan, qui calcule un graphe d’actions, et l’apply, qui l’exécute. Une valeur calculée pendant le plan — un mot de passe généré, un jeton éphémère, un secret dérivé — devait jusqu’ici être recalculée à l’apply, avec tous les risques de divergence que cela implique. Le bloc store permet de la capturer au plan et de la réutiliser à l’apply, sans la réexposer en clair dans l’état.

C’est le pendant, côté ressources managées, de la nouvelle gestion des données privées planifiées : Terraform 1.16 conserve désormais les données privées propres à chaque provider entre le plan et l’apply, là où elles étaient perdues entre les deux phases. Pour les providers qui s’appuient sur des secrets ou des identifiants internes, c’est une fiabilisation silencieuse mais réelle du cycle plan/apply.

Le scénario concret qui illustre le mieux l’intérêt est celui d’un mot de passe généré. Un provider crée une base de données, et le mot de passe administrateur est produit pendant le plan, stocké dans un service de secrets, puis référencé par une autre ressource à l’apply. Sans mécanisme de conservation, ce mot de passe devait être recalculé — et rien ne garantissait que les deux calculs coïncident. Avec le bloc store, la valeur capturée au plan est celle qui est réutilisée à l’apply, ce qui rend le cycle déterministe.

Des déclencheurs plus fins et des blocs imbriqués calculés

Deux autres ajouts méritent l’attention d’une équipe plateforme, même s’ils sont moins spectaculaires.

• Les déclencheurs d’action de ressource acceptent désormais un mode on_failure — halt, taint ou continue. Autrement dit, on peut décider finement du sort d’une ressource dont le déclencheur échoue : arrêter le run, marquer la ressource comme corrompue pour la recréer, ou poursuivre malgré l’échec. C’est le niveau de contrôle qui manquait pour les pipelines sensibles.
• Les blocs imbriqués peuvent être utilisés comme valeurs calculées par les providers. Une souplesse de plus pour les providers qui modélisent des structures hiérarchiques, sans que l’utilisateur ait à les déclarer intégralement.

Ajoutons, pour être complet, que Terraform est désormais distribué en binaire pré-compilé pour Linux s390x (zLinux), une plateforme encore présente dans la banque et l’assurance.

Ce qui reste expérimental

La 1.17.0-alpha, publiée le même jour, esquisse la direction suivante avec une fonctionnalité à surveiller : les actions différées. Activées par l’option -allow-deferral au plan, elles autorisent des count et des for_each dont la valeur est inconnue au moment du plan — par exemple une liste d’instances fournie par une autre ressource non encore créée.

C’est expérimental, réservé aux versions alpha, et cela ne doit pas guider une migration. Mais c’est un signal : HashiCorp travaille à rendre Terraform capable de planifier dans l’incertitude, là où aujourd’hui une valeur inconnue dans un count bloque le plan. À suivre, pas à adopter.

La séquence d’adoption, concrètement

Pour une équipe qui bascule une infrastructure existante sous Terraform avec la 1.16, l’ordre des opérations devient nettement plus simple.

• Écrire la configuration modulaire telle qu’elle devrait être, sans passer par une structure racine temporaire. Les ressources vivent dans les modules où elles appartiendront à terme.
• Placer un bloc import dans chaque module, pointant vers la ressource réelle via son identifiant. La génération de configuration n’est plus un préalable manuel.
• Exécuter terraform plan pour vérifier que chaque import correspond à l’état réel, puis terraform apply pour acter l’import. Aucun terraform state mv manuel n’est requis.
• Supprimer les blocs import une fois l’état en place, ou les conserver comme documentation explicite de l’origine de chaque ressource.

Ce qui disparaît, c’est l’étape la plus risquée : le déplacement manuel d’état entre racine et modules, source classique de moved blocks erronés et de ressources dupliquées. La 1.16 rend l’adoption aussi modulaire que l’exploitation qui la suit.

Verdict

Terraform 1.16 n’est pas une refonte, et c’est précisément sa force. Elle comble deux trous qui gênaient les équipes au quotidien depuis des années, sans rien casser.

Si vous adoptez Terraform sur une infrastructure existante, la levée de la restriction sur les import dans les modules change votre méthode : écrivez la configuration modulaire directement, et placez les blocs import dans les modules. Vous cessez de maintenir une structure racine artificielle juste pour importer.

Si vos pipelines reposent sur des secrets calculés au plan, le bloc store de terraform_data et les données privées planifiées valent la mise à niveau à eux seuls : ils éliminent une classe de divergences plan/apply sur les valeurs sensibles.

Pour tout le reste, la 1.16.0-rc1 étant une release candidate, la prudence s’impose : validez-la sur un environnement non critique avant de généraliser, et gardez un œil sur les actions différées de la 1.17 pour planifier la suite. La mise à niveau, elle, n’a aucune raison d’attendre la sortie stable si les import modulaires vous concernent.

Références

• HashiCorp — Terraform v1.16.0-rc1 release notes, 12 août 2026
• HashiCorp — Terraform v1.17.0-alpha20260812 release notes, 12 août 2026
• HashiCorp — Terraform Releases