Terraform 1.9 apporte des fonctionnalités attendues depuis longtemps. Tour d'horizon des nouveautés — variables éphémères, tests améliorés, stack references — et comment les adopter.
Terraform 1.9 : une version de maturité
Terraform 1.9, sorti en juin 2025, est l'une des versions les plus significatives depuis la 1.0. HashiCorp a répondu à des demandes de la communauté qui dataient de plusieurs années : gestion native des secrets sans fuite dans le state, framework de test intégré plus puissant, et meilleure gestion des dépendances entre stacks. Pour les équipes IaC sérieuses, c'est une mise à jour qui justifie une planification de migration rapide.
Variables éphémères : fini les secrets dans le state
C'est la fonctionnalité la plus attendue de Terraform 1.9. Jusqu'à présent, toute valeur utilisée dans une resource était persistée dans le fichier de state — y compris les mots de passe, clés API, et certificats. Les variables éphémères ne sont jamais écrites dans le state et sont masquées dans les plans et les logs.
variable "db_password" {
type = string
sensitive = true
ephemeral = true # Jamais écrit dans le state
description = "Mot de passe RDS, fourni via secrets manager"
}
variable "db_master_username" {
type = string
ephemeral = true
}
resource "aws_db_instance" "main" {
identifier = "prod-postgres"
engine = "postgres"
instance_class = "db.t4g.medium"
username = var.db_master_username
password = var.db_password # Ne sera pas dans le state
# Outputs contenant ces valeurs sont aussi éphémères
}
# Utilisation d'une ephemeral resource pour récupérer dynamiquement
ephemeral "aws_secretsmanager_secret_version" "db_creds" {
secret_id = "prod/rds/credentials"
}
locals {
db_password = jsondecode(ephemeral.aws_secretsmanager_secret_version.db_creds.secret_string).password
}
Cette fonctionnalité change fondamentalement la posture de sécurité de l'IaC : plus besoin de chiffrer manuellement le state S3 pour protéger les secrets (même si le chiffrement reste recommandé), et plus de risque de fuite lors du partage de plans.
Framework de test Terraform : tests de bout en bout
Terraform 1.9 étend significativement le framework de test introduit en 1.6. Les tests peuvent maintenant tester des ressources réelles créées dans un compte AWS éphémère, avec cleanup automatique après le test.
# tests/vpc_module.tftest.hcl
variables {
vpc_cidr = "10.0.0.0/16"
env_name = "test"
aws_region = "eu-west-1"
}
run "vpc_creation" {
command = apply
assert {
condition = aws_vpc.main.cidr_block == var.vpc_cidr
error_message = "Le CIDR du VPC ne correspond pas au paramètre"
}
assert {
condition = aws_vpc.main.enable_dns_hostnames == true
error_message = "DNS hostnames doit être activé"
}
}
run "subnets_in_different_azs" {
command = apply
assert {
condition = length(distinct([
aws_subnet.private[0].availability_zone,
aws_subnet.private[1].availability_zone,
aws_subnet.private[2].availability_zone
])) == 3
error_message = "Les sous-réseaux privés doivent être dans 3 AZs différentes"
}
}
# Cleanup automatique après les tests
Check blocks améliorés : validation continue
Les check blocks permettent de valider des conditions post-apply qui ne bloquent pas le déploiement mais émettent des warnings. En Terraform 1.9, ils peuvent référencer des data sources et effectuer des assertions complexes.
check "rds_backup_enabled" {
data "aws_db_instance" "check" {
db_instance_identifier = aws_db_instance.main.id
}
assert {
condition = data.aws_db_instance.check.backup_retention_period >= 7
error_message = "La rétention de backup RDS doit être d'au moins 7 jours"
}
}
check "s3_versioning_enabled" {
data "aws_s3_bucket" "check" {
bucket = aws_s3_bucket.data.id
}
assert {
condition = data.aws_s3_bucket.check.versioning[0].enabled == true
error_message = "Le versioning S3 doit être activé sur ce bucket"
}
}
Structure recommandée des modules en 2025
modules/
terraform-aws-ecs-service/ # Convention de nommage: terraform-PROVIDER-RESOURCE
├── main.tf # Ressources principales
├── variables.tf # Variables avec validation + éphémères si secrets
├── outputs.tf # Outputs (éphémères si données sensibles)
├── versions.tf # Contraintes providers
├── README.md # Généré par terraform-docs
└── tests/
├── basic.tftest.hcl # Tests minimaux (plan seul)
└── complete.tftest.hcl # Tests complets (apply + assertions)
Pipeline CI/CD avec GitHub Actions
name: Terraform CI
on: [push, pull_request]
jobs:
terraform:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: hashicorp/setup-terraform@v3
with:
terraform_version: "~1.9"
- name: Terraform Format
run: terraform fmt -check -recursive
- name: Terraform Validate
run: terraform validate
- name: Terraform Test (plan only on PR)
if: github.event_name == 'pull_request'
run: terraform test -filter=tests/basic.tftest.hcl
- name: Terraform Plan
run: terraform plan -out=tfplan
- name: Terraform Apply (main branch only)
if: github.ref == 'refs/heads/main'
run: terraform apply tfplan
Conclusion
Terraform 1.9 est une version qui renforce simultanément la sécurité (variables éphémères), la fiabilité (tests enrichis), et la gouvernance (check blocks). Pour les équipes IaC qui gèrent des infrastructures critiques, la migration vaut largement l'effort. Notre recommandation : adoptez les variables éphémères immédiatement pour tout nouveau code gérant des secrets, et planifiez la migration des modules existants sur 2 sprints.
