terraform workspace sélectionne une clé de state différente dans le même backend, pour la même configuration. default / dev / prod sur un seul dossier : un terraform workspace select prod oublié, et le plan de « test » vise la prod. Les variables restent à injecter (tfvars, -var-file), souvent avec un fichier par workspace — donc vous avez déjà la complexité des dossiers, plus un piège de contexte.
HashiCorp a longtemps montré les workspaces pour des isolations légères (un développeur, un sandbox). Pour des environnements durables, leurs guides poussent plutôt des configurations séparées : dossiers envs/dev, envs/prod, ou dépôts / pipelines distincts, chacun avec son backend, ses providers, ses droits IAM.
count acrobatique.destroy dans envs/dev n’a même pas les credentials de la prod.Le coût : un peu de duplication ou un module enfant partagé. C’est le bon coût.
Pas « workspaces c’est mal ». La nuance : workspaces pour des copies homogènes et peu risquées ; roots séparés dès que le rayon d’impact ou les comptes diffèrent. Dire « on utilise default pour la prod » est un signal d’alarme.
« HCP Terraform a des workspaces : contradiction ? »
Non. Là, « workspace » est un objet produit (un run, un state, des variables, des permissions), pas seulement un sélecteur CLI local. Le nom est le même, le contrat de sécurité n’est pas celui de terraform workspace select.