Terraform en équipe : backend S3 et verrou DynamoDB

Terraform stocke dans un fichier terraform.tfstate la carte de ce qu’il a créé. Tant que vous êtes seul sur une machine, ce fichier peut vivre à côté du code. Le jour où un collègue lance terraform apply depuis son laptop, vous avez deux vérités — et bientôt une infrastructure qui ne correspond à aucune des deux.

Le backend distant n’est pas une optimisation. C’est la condition minimale pour travailler à plus d’une personne.

Ce qui casse sans backend

Sans state partagé :

• A crée un VPC ; B ne le voit pas et en crée un second
• A et B appliquent en même temps et écrasent des ressources
• le state contient parfois des secrets — et traîne dans des dossiers locaux

Le trio S3 + DynamoDB + encryption

Sur AWS, le pattern standard est :

terraform {
  backend "s3" {
    bucket         = "mon-org-terraform-state"
    key            = "prod/network/terraform.tfstate"
    region         = "ca-central-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

Le key est le chemin logique du state. Un projet multi-comptes utilise en général un state par environnement (ou par composant), jamais un seul fichier géant pour tout.

Bootstrap : l’œuf et la poule

Le bucket et la table doivent exister avant le premier terraform init qui les utilise. Deux approches propres :

1. Un petit projet « bootstrap » dont le state reste local (ou dans un compte admin), qui crée uniquement le bucket, la table et les politiques.
2. Création manuelle une fois, documentée, puis jamais retouchée à la main.

Ce qu’il ne faut pas faire : créer le bucket dans le même root module que l’infra applicative. Terraform ne peut pas stocker son state dans une ressource qu’il est en train de créer.

resource "aws_s3_bucket" "state" {
  bucket = "mon-org-terraform-state"
}

resource "aws_s3_bucket_versioning" "state" {
  bucket = aws_s3_bucket.state.id
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_dynamodb_table" "locks" {
  name         = "terraform-locks"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }
}

Le verrou, concrètement

Quand vous lancez terraform apply :

1. Terraform écrit un item dans DynamoDB (LockID)
2. personne d’autre ne peut appliquer tant que le verrou existe
3. à la fin (succès ou échec propre), le verrou est retiré

Si un apply est tué au milieu (kill -9, laptop qui s’éteint), le verrou peut rester. La commande terraform force-unlock <ID> existe — et ne doit être utilisée qu’après avoir vérifié qu’aucun collègue n’applique vraiment.

Ce qu’il faut retenir

Avant les modules élégants et les workspaces, posez le backend. Un state local est un prototype. Un state S3 versionné, chiffré, verrouillé par DynamoDB, c’est le début d’une infrastructure que plusieurs personnes peuvent faire évoluer sans se marcher dessus.