Commencer et apprendre Terraform : ce qui n'est pas dans le tutoriel

La syntaxe HCL de Terraform s'apprend en une heure : déclarer une ressource, un provider, une variable. Ce qui prend beaucoup plus de temps à comprendre vraiment, et que la plupart des tutoriels effleurent à peine, c'est le state : le fichier qui fait le lien entre la déclaration et la réalité.

Ce que Terraform fait, en une phrase

Terraform compare trois choses à chaque exécution : ce que vous avez déclaré (le code), ce qu'il pense avoir déjà créé (le state), et ce qui existe réellement chez le fournisseur cloud. Un terraform plan calcule la différence entre ces trois sources ; un terraform apply l'applique.

resource "aws_s3_bucket" "frontend" {
  bucket = "my-app-frontend"
}

Ce bloc ne crée rien tout seul : il déclare une intention. C'est le state qui transforme cette intention en un suivi de ce qui existe vraiment.

   code (.tf)              state (.tfstate)           fournisseur cloud
  ┌─────────────┐         ┌─────────────────┐         ┌─────────────────┐
  │ intention    │  plan  │ dernier suivi    │         │ ressources      │
  │ déclarée     │◄──────►│ connu par        │◄───────►│ réellement      │
  │              │        │ Terraform        │  apply  │ existantes      │
  └─────────────┘         └─────────────────┘         └─────────────────┘

plan compare les trois colonnes et affiche l'écart ; apply fait converger le state et le cloud vers ce que dit le code.

Le vrai sujet : le state, pas la syntaxe

Le state est un fichier JSON qui mappe chaque ressource déclarée à son identifiant réel chez le fournisseur cloud. Le problème n'est pas de le comprendre en théorie, c'est de comprendre ce qui se passe quand il diverge de la réalité : quelqu'un modifie une ressource manuellement dans la console AWS, et le state ne le sait pas. Au prochain plan, Terraform propose de « corriger » cette modification manuelle, potentiellement en la détruisant.

C'est pour ça que le state ne doit jamais rester en local sur un poste de développeur, même sur un projet solo : un disque qui plante, un fichier oublié dans un commit, et l'historique de l'infrastructure est perdu ou incohérent.

Un stockage distant dès le premier jour

terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "env/prod/terraform.tfstate"
    region         = "eu-west-3"
    dynamodb_table = "terraform-locks"
  }
}

Le bucket S3 stocke le state ; la table DynamoDB gère le verrou (lock) qui empêche deux exécutions simultanées de corrompre le même state. Sur MissionMatch, j'ai mis en place cette configuration dès le premier jour, même en solo : ce n'est pas une question d'échelle, c'est une question de discipline. Ça retire le « ça marche sur ma machine » de l'équation dès qu'on touche à l'infrastructure.

Ce qui reste un vrai piège pour un débutant

Le piège le plus fréquent n'est pas la syntaxe, c'est la confusion entre plan et apply sous pression : appliquer un changement sans avoir lu attentivement le plan affiché, en particulier les lignes qui indiquent une destruction plutôt qu'une simple modification.

Symbole	Signification	Niveau de vigilance
+	Création d'une nouvelle ressource	Faible, généralement sans risque
~	Modification en place, sans recréation	Moyen, dépend de l'attribut modifié
-/+	Destruction puis recréation (souvent un changement d'attribut immuable)	Élevé, la ressource est éphémère le temps du remplacement
-	Suppression pure	Maximal, surtout sur une ressource stateful

Le cas -/+ est celui qui surprend le plus en apprenant Terraform : un changement qui semble anodin dans le code (par exemple, l'identifiant d'AMI d'une instance EC2) peut forcer une destruction-recréation complète si cet attribut ne peut pas être modifié en place chez le fournisseur cloud, sans que rien dans le code ne le signale avant de lire le plan.

Sur une ressource stateful (une base de données, un bucket avec des données), une destruction non anticipée n'est pas récupérable comme un rollback de code.

Ce que j'en retiens en apprenant

Apprendre Terraform sérieusement, ce n'est pas mémoriser la syntaxe des providers : c'est comprendre que chaque apply modifie un système partagé et persistant, contrairement à un déploiement d'application qu'on peut recommencer à volonté. C'est cette différence de nature qui justifie de lire chaque plan avant de l'appliquer, même sur un projet personnel où « ça n'a pas d'importance ». Sur MissionMatch, tous les modules et les deux environnements passent terraform validate, mais rien n'a encore été apply, précisément parce que je préfère valider la structure avant de faire tourner quoi que ce soit contre un vrai compte cloud.