Quand utiliser (ou éviter) les workspaces Terraform

Les workspaces Terraform permettent de gérer plusieurs states avec un seul jeu de fichiers .tf. Ils sont simples à utiliser — un terraform workspace new prod et vous avez un environnement séparé. Mais cette simplicité masque des limites qui deviennent problématiques à mesure que le projet grandit. Ce guide vous aide à décider quand les workspaces sont le bon choix, et quand il vaut mieux utiliser une autre approche.

Prérequis : avoir lu le guide Les workspaces Terraform pour comprendre les commandes et le fonctionnement.

Ce que vous allez apprendre

Identifier les cas d’usage où les workspaces sont adaptés
Reconnaître les limites qui rendent les workspaces inadaptés
Choisir entre workspaces et alternatives selon votre contexte
Comprendre pourquoi l’industrie déconseille souvent les workspaces en production

Les cas d’usage légitimes

Les workspaces fonctionnent bien quand l’infrastructure est identique entre les environnements, avec seulement des variations de paramètres (taille, nombre, adresses).

Test rapide d’une configuration

Vous développez une nouvelle configuration Terraform et vous voulez la tester sans toucher à l’existant. Créez un workspace temporaire, déployez, validez, détruisez :

terraform workspace new test-nouvelle-config
terraform apply -auto-approve
# ... vérification ...
terraform destroy -auto-approve
terraform workspace select default
terraform workspace delete test-nouvelle-config

Le workspace par défaut reste intact pendant toute la durée du test.

Environnements avec des variations légères

Si la seule différence entre dev et prod est la taille des ressources ou les adresses réseau, les workspaces couplés à une map locale fonctionnent bien :

locals {
  config = {
    default = {
      network_address = "10.10.60.1"
      disk_size_gb    = 4
    }
    staging = {
      network_address = "10.10.61.1"
      disk_size_gb    = 4
    }
    prod = {
      network_address = "10.10.62.1"
      disk_size_gb    = 8
    }
  }

  env = lookup(local.config, terraform.workspace, local.config["default"])
}

Ce pattern garde un code lisible et centralisé. Un terraform workspace select staging suivi d’un apply déploie la variante staging automatiquement.

Développement solo ou petite équipe

En solo ou en binôme, les workspaces sont un moyen rapide de gérer 2-3 environnements sans infrastructure supplémentaire. Il n’y a pas de problème de permissions, pas de conflits d’accès, pas de coordination complexe.

Les limites concrètes

Pas d’isolation des permissions

Tous les workspaces partagent le même backend et les mêmes credentials. Concrètement :

Toute personne qui peut faire un apply dans le workspace dev peut aussi faire un apply dans le workspace prod
Il n’y a pas de mécanisme intégré pour restreindre l’accès à un workspace spécifique
Un terraform workspace select prod && terraform destroy -auto-approve par erreur détruit la production

En environnement professionnel, disposer d’une isolation stricte entre dev et prod est une exigence de sécurité fondamentale. Les workspaces ne la fournissent pas.

Pas de visibilité sur le workspace actif

Le workspace actif est stocké localement dans le fichier .terraform/environment. Rien dans votre terminal ni dans vos fichiers .tf ne vous rappelle en permanence dans quel workspace vous êtes :

# Rien n'indique que vous êtes dans le workspace prod...
terraform apply -auto-approve
# ...sauf si vous pensez à vérifier avant :
terraform workspace show

Le risque d’appliquer un changement dans le mauvais workspace est réel et difficile à prévenir automatiquement.

Un seul code pour tous les environnements

Avec les workspaces, dev et prod utilisent exactement le même code. Cela devient un problème quand :

La prod a besoin d’un load balancer que le dev n’a pas
La prod requiert du monitoring et des alertes absentes en dev
Le dev utilise des instances spot mais pas la prod
Les modules ou les providers doivent être à des versions différentes

Vous finissez par écrire des conditions partout :

# Ceci devient vite illisible et fragile
resource "libvirt_domain" "monitoring" {
  count = terraform.workspace == "prod" ? 1 : 0
  # ...
}

resource "libvirt_domain" "alerting" {
  count = terraform.workspace == "prod" ? 1 : 0
  # ...
}

resource "libvirt_volume" "monitoring_disk" {
  count = terraform.workspace == "prod" ? 1 : 0
  # ...
}

Quand plus de 20–30 % de vos ressources sont conditionnées sur le workspace, le code est devenu plus complexe que deux configurations séparées.

Pas de state séparé en backend distant

Avec un backend S3 par exemple, les workspaces créent des sous-dossiers dans le même bucket avec les mêmes credentials. Impossible de :

Chiffrer le state de prod avec une clé différente de celle du dev
Mettre le state de prod dans un compte AWS séparé
Appliquer des politiques IAM différentes par environnement

Risque de prolifération

Les workspaces se créent en une commande. Sans convention stricte, vous vous retrouvez rapidement avec :

terraform workspace list
  default
  dev
  staging
* prod
  test-feature-x
  test-migration
  ancien-format
  debug-reseau

Chaque workspace oublié est potentiellement un ensemble de ressources toujours en cours d’exécution et qui coûtent de l’argent.

L’arbre de décision

Question	Si oui	Si non
L’infrastructure est-elle identique entre les environnements ?	Workspaces possibles	Répertoires séparés
Faut-il des permissions différentes par environnement ?	Répertoires séparés	Workspaces possibles
Plus de 3 personnes travaillent sur le projet ?	Répertoires séparés	Workspaces possibles
Plus de 30 % des ressources sont conditionnées sur l’environnement ?	Répertoires séparés	Workspaces possibles
Le state doit être dans des comptes/buckets séparés ?	Répertoires séparés	Workspaces possibles
C’est un test temporaire d’une configuration ?	Workspaces	—

Les alternatives

Répertoires séparés

La stratégie la plus courante : un répertoire par environnement, chacun avec son propre backend, ses propres variables et son propre state :

mon-projet/
├── modules/
│   └── infra/           # Code commun factorisé en module
├── envs/
│   ├── dev/
│   │   ├── main.tf      # Appelle le module avec les paramètres dev
│   │   ├── backend.tf   # Backend S3 dédié dev
│   │   └── terraform.tfvars
│   ├── staging/
│   │   ├── main.tf
│   │   ├── backend.tf   # Backend S3 dédié staging
│   │   └── terraform.tfvars
│   └── prod/
│       ├── main.tf
│       ├── backend.tf   # Backend S3 avec chiffrement renforcé
│       └── terraform.tfvars

Avantages :

Isolation complète des states et des backends
Permissions différentes par environnement (comptes AWS séparés, clés différentes)
Chaque environnement peut avoir des ressources spécifiques
Pas de risque de apply dans le mauvais environnement — vous êtes dans le bon répertoire

Fichiers tfvars par environnement

Si le code est vraiment identique, utilisez un seul répertoire avec des fichiers .tfvars distincts :

terraform apply -var-file="envs/dev.tfvars"
terraform apply -var-file="envs/prod.tfvars"

Plus simple que les répertoires séparés, mais le state reste partagé (sauf si vous configurez des backends différents avec -backend-config).

Comparaison des approches

Critère	Workspaces	Répertoires séparés	tfvars
Facilité de mise en place	Simple	Moyenne	Simple
Isolation du state	Même backend	Complète	Même sauf `-backend-config`
Isolation des permissions	Non	Oui	Non
Code spécifique par env	Conditions uniquement	Oui (natif)	Conditions uniquement
Risque d’erreur humaine	Élevé	Faible	Moyen
Adapté à la production	Déconseillé	Oui	Selon le contexte
Traçabilité en CI/CD	Fragile	Naturelle (chemin = env)	Variable

Dépannage

Symptôme	Cause probable	Solution
`apply` sur le mauvais workspace	Oubli de `workspace select`	Ajouter `terraform workspace show` dans vos scripts/alias
Prolifération de workspaces	Pas de convention de nommage	Documenter les workspaces autorisés, supprimer les temporaires
Code illisible avec `count` partout	Trop de différences entre environnements	Migrer vers des répertoires séparés avec un module commun
Collègue a détruit la prod	Pas d’isolation des permissions	Séparer les backends et les credentials par environnement

À retenir

Les workspaces sont adaptés aux tests temporaires et aux petits projets avec des variations minimes entre environnements
Dès que vous avez besoin de permissions différentes, de ressources spécifiques par environnement, ou que vous travaillez à plus de 3 personnes, préférez les répertoires séparés
Le principal danger des workspaces est l’absence de garde-fou : rien n’empêche un apply accidentel dans le mauvais workspace
La stratégie répertoires séparés + module commun est le standard pour les projets professionnels
Les fichiers .tfvars par environnement sont un bon compromis pour les projets moyens

Prochaines étapes

Séparer dev, staging et prod Mettre en place la stratégie répertoires séparés avec un module commun.

Variables par environnement Fichiers .tfvars et -var-file pour paramétrer sans modifier le code.

Organiser un dépôt Terraform Structure de fichiers et conventions pour un projet maintenable.