Terraform : gérer plusieurs environnements avec workspaces ou modules

Gérer plusieurs environnements (dev, staging, prod) avec Terraform est un des sujets les plus débattus de la communauté. Il n’y a pas une seule bonne réponse, mais des compromis clairs.

Approche 1 : Terraform Workspaces

terraform workspace new staging
terraform workspace new production
terraform workspace select staging

# Dans le code, accéder au workspace courant
locals {
  env = terraform.workspace
  instance_type = {
    default    = "t3.micro"
    staging    = "t3.small"
    production = "t3.xlarge"
  }
}

resource "aws_instance" "api" {
  instance_type = local.instance_type[local.env]
}

Avantages : un seul backend state, simple. Inconvénients : un seul state pour tous les envs (une erreur peut impacter tous), difficile de voir quelle version est déployée où.

Approche 2 : dossiers séparés par environnement

infrastructure/
├── modules/
│   └── app/         # module réutilisable
├── environments/
│   ├── dev/
│   │   ├── main.tf  # instancie le module avec des vars dev
│   │   └── terraform.tfvars
│   ├── staging/
│   └── production/

Chaque environnement a son propre state. C’est l’approche recommandée pour les équipes avec des exigences de séparation strictes.

Approche 3 : modules instanciés depuis la racine

module "staging" {
  source        = "./modules/app"
  env           = "staging"
  instance_type = "t3.small"
  replicas      = 1
}

module "production" {
  source        = "./modules/app"
  env           = "production"
  instance_type = "t3.xlarge"
  replicas      = 3
}

Les deux environnements coexistent dans le même state — pratique pour les petites équipes, risqué pour les grandes.

Notre recommandation

Pour des équipes de moins de 5 personnes avec des environments peu critiques : workspaces. Pour des équipes plus grandes avec de la prod critique : dossiers séparés par environnement, un state par environnement, des pipelines CI/CD distincts.

Notre formation Terraform couvre les trois approches avec leurs compromis réels.