Gérer l'état Terraform en équipe : les pièges à éviter

Le fichier d’état Terraform (terraform.tfstate) est probablement le fichier le plus important — et le plus dangereux — de votre infrastructure. Il mappe vos ressources réelles à votre code HCL. Le gérer correctement n’est pas optionnel dès qu’on travaille à plusieurs.

Pourquoi l’état local est une mauvaise idée en équipe

Par défaut, Terraform stocke l’état en local dans terraform.tfstate. Ce qui semble pratique pour un développeur seul devient un problème en équipe :

Conflits silencieux : deux personnes appliquent des changements sans voir l’état de l’autre
Perte d’état : un laptop perdu = état perdu = reconstruction manuelle de l’infrastructure
Impossibilité d’automatiser : un pipeline CI/CD ne peut pas accéder à un fichier local

Remote state : la solution standard

La solution est d’utiliser un backend distant pour stocker l’état. Les options les plus courantes :

terraform {
  backend "s3" {
    bucket         = "mon-tfstate-bucket"
    key            = "prod/terraform.tfstate"
    region         = "eu-west-1"
    dynamodb_table = "terraform-state-lock"
    encrypt        = true
  }
}

Le dynamodb_table est crucial : il gère le verrou d’état (state locking). Sans lui, deux terraform apply simultanés peuvent corrompre l’état.

L’équivalent Azure

terraform {
  backend "azurerm" {
    resource_group_name  = "tfstate-rg"
    storage_account_name = "tfstate12345"
    container_name       = "tfstate"
    key                  = "prod.terraform.tfstate"
  }
}

Isolation par workspace ou par dossier ?

Deux approches coexistent pour gérer plusieurs environnements (dev/staging/prod) :

Workspaces Terraform : un seul backend, plusieurs états. Simple à mettre en place, mais les variables ne peuvent pas varier entre workspaces par défaut. Adapté aux environnements homogènes.

Dossiers séparés : un dossier par environnement, chacun avec son propre state. Plus de duplication de code (atténuée par les modules), mais isolation totale et variabilisation complète. C’est l’approche recommandée pour les environnements significativement différents.

Les commandes à connaître pour récupérer une situation dégradée

# Lister les ressources dans l'état
terraform state list

# Inspecter une ressource spécifique
terraform state show aws_instance.web

# Importer une ressource existante dans l'état
terraform import aws_instance.web i-1234567890abcdef0

# Retirer une ressource de l'état sans la détruire
terraform state rm aws_instance.web

Attention : terraform state rm ne détruit pas la ressource dans le cloud — elle reste là mais Terraform ne la gère plus. C’est un outil de chirurgie, pas de suppression.

Sécuriser l’accès à l’état

L’état Terraform contient souvent des données sensibles en clair (mots de passe, clés SSH, tokens). Activez le chiffrement côté bucket S3 ou Storage Account Azure, et restreignez les accès via IAM au strict nécessaire. Ne commitez jamais un fichier .tfstate dans Git — ajoutez-le à votre .gitignore.

Ces pratiques sont approfondies dans notre formation Terraform, avec des ateliers sur la mise en place d’un backend S3 et la gestion des workspaces.