Fiche mémo Terraform (HCL, état, plan et apply, modules, backends, import, OpenTofu)

Avant tout (dans l'ordre)

Dossier de travail jetable ou compte d'essai ; vérifier le workspace actif (terraform workspace show).
terraform init, puis terraform validate, puis terraform plan -out=plan.tfplan : lire le plan en entier.
Appliquer le plan relu (terraform apply plan.tfplan), pas un apply à l'aveugle.
Après coup : terraform plan ne doit plus annoncer de changement.

Attention : l'état contient des données sensibles en clair. Jamais dans Git, un message, une capture ni un prompt à un assistant IA. sensitive = true masque l'affichage, pas l'état. Un fichier de plan peut aussi contenir des valeurs sensibles.

Schéma de repère

Écrire (.tf), planifier (plan, lecture), appliquer (apply, effet) ; l'état relie la configuration aux objets réels.

Vocabulaire

Terme	En bref
IaC	infrastructure décrite en fichiers, versionnable, déclarative
HCL	langage de configuration : blocs et arguments
Provider	plugin qui parle à l'API d'une plateforme (registre Terraform)
Resource	objet géré ; adresse `type.nom`
Data source	lecture d'un objet existant (non étudié)
Variable, output, locals	entrée, sortie, valeur calculée
État (tfstate)	correspondance configuration / objets réels ; secret
Module	ensemble de fichiers réutilisable ; module racine = dossier de travail
Backend	où l'état est stocké (local par défaut, ou distant)
Workspace	état supplémentaire pour une même configuration ; isolation légère
Dérive	écart entre la réalité et l'état/la configuration

Blocs HCL

Bloc	Exemple de forme
`terraform`	`required_providers`, `backend`, version requise
`provider "nom"`	configuration du fournisseur
`resource "type" "nom"`	objet géré
`variable "nom"`	`type`, `description`, `default`, `sensitive`, `validation`
`output "nom"`	`value`, `description`
`locals`	valeurs calculées, lues avec `local.<nom>`
`module "nom"`	`source`, `version`, entrées
`import`	`to`, `id`

Références : var.<nom>, local.<nom>, <type>.<nom>.<attribut>, module.<nom>.<sortie>.

Priorité des valeurs de variables (forte vers faible)

-var, -var-file · 2. *.auto.tfvars · 3. terraform.tfvars.json · 4. terraform.tfvars · 5. TF_VAR_<nom> · 6. default

Commandes

Commande	Rôle	Prudence
`terraform init`	télécharge providers et modules, configure le backend	réseau ; relancer si backend/provider/module change
`terraform fmt -check`	signale le mauvais formatage	lecture
`terraform validate`	vérifie la cohérence de la configuration	sans effet sur les objets
`terraform plan`	prévisualise	lecture ; `-out=FILE` enregistre (peut contenir des secrets)
`terraform plan -destroy`	prévisualise la destruction totale	lecture
`terraform plan -refresh-only`	montre ce que mettrait à jour l'état	lecture
`terraform plan -detailed-exitcode`	0 rien, 1 erreur, 2 changements	pratique pour détecter la dérive
`terraform apply FILE`	exécute exactement le plan enregistré	effet ; plan relu, compte d'essai
`terraform apply`	planifie puis demande confirmation	effet ; lire avant de confirmer
`terraform destroy`	détruit tous les objets de l'état courant	destructif, vérifier le workspace, accord de Stéphane hors essai
`terraform output [-json]`	affiche les sorties	peut montrer des secrets
`terraform workspace list/new/select/show/delete`	gère les workspaces	`delete` et `destroy` visent l'espace courant
`terraform state ...`	manipule l'état (ne jamais l'éditer à la main)	sous-commandes non vérifiées ici

Contexte : dossier d'essai initialisé. Droits : ceux de l'identité du fournisseur (moindre privilège). Vérification : terraform plan sans changement après un apply. Retour arrière : corriger la configuration puis planifier et appliquer ; une suppression d'objet n'est pas annulable.

Symboles du plan : + création · - suppression · ~ modification sur place · -/+ remplacement (détruit puis recrée).

Fichiers à exclure de Git

Fichier ou dossier	Pourquoi
`terraform.tfstate`, `.tfstate.`	état : secrets en clair
`.terraform/`	providers et modules téléchargés
`*.tfvars` (avec valeurs secrètes)	valeurs sensibles
fichiers de plan (`*.tfplan`)	peuvent contenir des valeurs sensibles
`.terraform.lock.hcl`	en général versionné : à confirmer (non vérifié)

Liste de bon sens, non relue sur une page officielle.

Backend, workspaces, modules

Sujet	Repère
Backend local	défaut : `terraform.tfstate` sur disque, usage personnel
Backend distant	S3, azurerm, gcs, Consul, HTTP, Kubernetes, PostgreSQL... ; verrouillage selon le backend
Changer de backend	relancer `terraform init` ; l'état peut être migré : le sauvegarder avant
Identifiants du backend	variables d'environnement, jamais dans la configuration
Workspace	`default` non supprimable ; pas d'isolation forte (droits et identifiants communs)
Module	`source` + `version` ; relire le code d'un module tiers et figer sa version

Import et dérive

Dérive : terraform plan la révèle ; soit réaligner la réalité (apply), soit mettre la configuration à jour. Ne pas laisser de modifications manuelles.
Import : bloc import (to, id) + bloc resource, puis apply ; ou terraform plan -generate-config-out pour générer la configuration. L'id dépend du fournisseur : ne pas le deviner. Vérifier ensuite qu'aucun changement n'est planifié sur l'objet importé.

Exercices sans cloud

Ressource	Usage
`terraform_data` (intégrée)	stocke `input`, expose `output` ; aucun provider à télécharger
`local_file` (`hashicorp/local`)	crée un fichier ; `filename` obligatoire, `content` ; `file_permission` 0777 par défaut : fixer des droits restrictifs
`local_sensitive_file`	même idée pour un contenu sensible (remplace `sensitive_content`, obsolète)

Toujours dans un dossier neuf hors dépôt, supprimé en fin d'exercice.

Licence et OpenTofu

Sujet	Repère
Licence de Terraform	2023-08-10 : HashiCorp passe de MPL 2.0 à BSL 1.1 pour les versions futures (billet officiel)
BSL	restreint les services concurrents ; API, SDK et presque toutes les bibliothèques restent en MPL 2.0
OpenTofu	fork de Terraform, MPL 2.0, Linux Foundation, commande `tofu`
Fournisseurs	OpenTofu réutilise les providers existants via son propre registre
Compatibilité	états créés jusqu'à Terraform 1.5.x (FAQ) ; migrer = sauvegarder état et code d'abord

Conséquences juridiques et comparaison de fonctionnalités : non vérifiées.

Bonnes pratiques

Fichiers .tf versionnés sans secret · état distant verrouillé, chiffré, à accès restreint · plan relu et appliqué tel quel · pas de secret en clair dans la configuration · versions figées (Terraform, providers, modules) · moindre privilège · fmt et validate avant commit · aucune modification manuelle des objets gérés · budget et étiquettes sur un compte cloud.

Sources

Consultées le 18 octobre 2026 (Terraform documentation v1.16.x ; OpenTofu 1.13.x ; version de Stéphane inconnue).