Terraform 1.9 : les nouveautés et best practices 2025
← Retour au blogIaC

Terraform 1.9 : les nouveautés et best practices 2025

25 juin 20258 min de lectureTerraformIaCDevOps

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.

← Retour au blog