Aller au contenu principal

HCL, plan, apply : le cycle déclaratif

Résumé : Terraform s'articule autour d'un langage (HCL, le HashiCorp Configuration Language) et d'un cycle en quatre commandes (init, plan, apply, destroy). Cette leçon montre à quoi ressemble un vrai fichier .tf, décortique ligne par ligne, explique la différence cruciale entre l'approche déclarative de Terraform et l'approche impérative d'un script shell, et démontre pourquoi la commande terraform plan a sauvé des milliers de productions.

1. HCL — l'ADN de Terraform​

HCL (HashiCorp Configuration Language) est le langage propriétaire utilisé par tous les outils HashiCorp — Terraform, Vault, Consul, Packer, Nomad. Il a été conçu spécifiquement pour décrire des configurations d'infrastructure.

HCL n'est pas :

  • Un langage de programmation général — vous ne pouvez pas écrire une application web ou un algorithme.
  • Du JSON pur — même si HCL peut être exporté en JSON, on écrit rarement du JSON à la main.
  • Du YAML — la syntaxe est différente et volontairement plus lisible pour l'humain.

HCL est : un langage déclaratif hybride entre JSON et YAML, optimisé pour l'infrastructure.

1.1 · À quoi ressemble un fichier .tf​

Voici un vrai fichier Terraform qui crée une machine virtuelle sur AWS. N'essayez pas de le retenir — on regarde juste la forme.

# Bloc 1 : configuration du provider AWS
provider "aws" {
  region = "us-east-1"
}

# Bloc 2 : ressource - une machine virtuelle EC2
resource "aws_instance" "serveur_web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  tags = {
    Name        = "serveur-web-production"
    Environment = "prod"
    ManagedBy   = "terraform"
  }
}

# Bloc 3 : sortie - récupérer l'adresse IP publique
output "adresse_ip_publique" {
  value = aws_instance.serveur_web.public_ip
}

Décodage bloc par bloc :

BlocCe qu'il fait
provider "aws"Dit à Terraform qu'on travaille avec AWS, région us-east-1
resource "aws_instance" "serveur_web"Déclare la création d'une VM EC2 nommée serveur_web
ami = "ami-0c55b159cbfafe1f0"L'image disque à utiliser (Ubuntu 22.04 dans cet exemple)
instance_type = "t3.micro"Le gabarit de la VM (2 vCPU, 1 Go RAM)
tags = { ... }Des étiquettes pour classer la ressource
output "adresse_ip_publique"Une valeur à afficher après la création — ici l'IP publique

Quelques observations importantes :

  • La syntaxe est très lisible. Un non-technique comprend approximativement ce que fait le fichier.
  • Aucune commande impérative. Il n'y a pas de « lance ceci puis fais cela ». On décrit l'état voulu.
  • Les blocs peuvent être répartis dans plusieurs fichiers .tf — Terraform les lit tous ensemble.

2. Déclaratif vs impératif — la différence fondamentale​

C'est le concept qu'il faut absolument comprendre pour saisir la magie de Terraform.

L'analogie du GPS est parlante :

  • Impératif : « tourne à droite dans 200 mètres, puis à gauche, puis au troisième feu à droite ». Si un embouteillage bloque une rue, tout le plan tombe à l'eau.
  • Déclaratif : « je veux aller à cette adresse ». Le GPS recalcule tout seul en cas de blocage.

Terraform est un GPS pour votre cloud. Vous lui dites où vous voulez arriver, il calcule le meilleur chemin, et il recalcule si l'état réel diverge de l'état voulu.

3. Le cycle complet — les quatre commandes essentielles​

Terraform s'utilise principalement via quatre commandes dans un ordre précis.

En pratique quotidienne, votre boucle de travail ressemble à ceci :

  1. Éditer un fichier .tf pour ajouter/modifier une ressource.
  2. Lancer terraform plan pour voir ce qui va changer.
  3. Vérifier le plan attentivement — c'est là que se joue la sécurité.
  4. Lancer terraform apply pour appliquer.
  5. Committer le changement dans Git.

4. La commande qui a sauvé des milliers de productions : terraform plan​

terraform plan est probablement la commande la plus importante de tout l'écosystème Infrastructure as Code.

4.1 · Ce qu'affiche un plan​

Voici à quoi ressemble le résultat d'un terraform plan (simplifié).

Terraform will perform the following actions:

  # aws_instance.serveur_web will be created
  + resource "aws_instance" "serveur_web" {
      + ami                          = "ami-0c55b159cbfafe1f0"
      + arn                          = (known after apply)
      + associate_public_ip_address  = (known after apply)
      + availability_zone            = (known after apply)
      + cpu_core_count               = (known after apply)
      + cpu_threads_per_core         = (known after apply)
      + instance_type                = "t3.micro"
      + tags                         = {
          + "Environment" = "prod"
          + "ManagedBy"   = "terraform"
          + "Name"        = "serveur-web-production"
        }
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Décodage :

  • Le + vert devant chaque ligne signifie « création ».
  • Les valeurs (known after apply) sont celles qu'AWS attribuera dynamiquement (adresse IP, ARN).
  • La dernière ligne résume tout : 1 à créer, 0 à modifier, 0 à détruire.

Ce format existe aussi avec ~ pour les modifications, et - pour les destructions.

4.2 · Pourquoi c'est révolutionnaire​

Avant Terraform, faire un changement dans le cloud signifiait découvrir sur le tas si on cassait quelque chose. Avec terraform plan, on voit tout avant d'appliquer.

Règle absolue en équipe : jamais un terraform apply sans un terraform plan revu par un humain avant. Cette discipline évite 95 % des incidents d'infrastructure.

5. Les fondamentaux syntaxiques du HCL​

Vous n'avez pas besoin de mémoriser HCL pour ce cours découverte. Mais voici les 4 constructions fondamentales à reconnaître au premier coup d'œil.

5.1 · Le bloc — l'unité de base​

type "nom_du_type" "nom_utilisateur" {
  attribut = valeur
}

Exemples réels :

  • provider "aws" {} — configure un provider.
  • resource "aws_instance" "web" {} — déclare une ressource.
  • variable "region" {} — déclare une variable.
  • output "ip" {} — déclare une sortie.

5.2 · Les variables — pour rendre le code paramétrable​

variable "region" {
  description = "Région AWS à utiliser"
  type        = string
  default     = "us-east-1"
}

resource "aws_instance" "web" {
  ami           = "ami-..."
  instance_type = "t3.micro"

  # On utilise la variable ici
  # Note : les guillemets doubles entourent la référence
}

Les variables permettent de séparer la configuration statique (les .tf) des valeurs qui changent selon l'environnement (dev, staging, prod). C'est la clé de la reproductibilité multi-environnements.

5.3 · Les références — comment relier les ressources entre elles​

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "web" {
  # Référence à l'ID du VPC créé au-dessus
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"
}

Terraform utilise ces références pour construire un graphe de dépendances et créer les ressources dans le bon ordre — d'abord le VPC, ensuite le subnet qui en dépend.

5.4 · Les outputs — pour exposer des valeurs après création​

output "ip_publique" {
  description = "Adresse IP publique du serveur web"
  value       = aws_instance.web.public_ip
}

Après un apply, Terraform affiche les outputs — utile pour récupérer les valeurs à passer à d'autres outils (Ansible, scripts de test…).

6. Un exemple complet — un site web statique en 20 lignes de HCL​

Pour montrer la puissance de Terraform, voici un exemple qui crée un site web statique complet sur AWS S3.

# Bucket S3 qui contient les fichiers du site
resource "aws_s3_bucket" "site" {
  bucket = "mon-super-site-2026"
}

# Activer l'hébergement web sur le bucket
resource "aws_s3_bucket_website_configuration" "site" {
  bucket = aws_s3_bucket.site.id

  index_document {
    suffix = "index.html"
  }
}

# Politique publique pour rendre les fichiers lisibles par tous
resource "aws_s3_bucket_policy" "site" {
  bucket = aws_s3_bucket.site.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Sid       = "PublicReadGetObject"
      Effect    = "Allow"
      Principal = "*"
      Action    = "s3:GetObject"
      Resource  = "${aws_s3_bucket.site.arn}/*"
    }]
  })
}

output "url_du_site" {
  value = "http://${aws_s3_bucket.site.bucket_regional_domain_name}"
}

En 20 lignes de HCL, vous avez :

  • Un bucket S3.
  • L'hébergement web activé.
  • Une politique publique de lecture.
  • Une sortie qui vous donne l'URL du site.

Un terraform apply crée tout ça en une trentaine de secondes. Un terraform destroy supprime tout aussi vite. Répéter n fois = n sites identiques dans n régions différentes.

C'est là toute la magie de Terraform.

7. Ce que vous ne verrez que dans le cours Premium​

Ce cours découverte s'arrête volontairement à ce niveau conceptuel. Le Cours Premium Terraform approfondit :

  • Comment structurer vraiment un projet Terraform en production.
  • Les loops (for_each, count) pour créer 10 ressources similaires en une seule fois.
  • Les conditions (dynamic, ternaires) pour rendre le code adaptatif.
  • Les fonctions HCL (jsonencode, templatefile, lookup).
  • Les data sources pour récupérer des valeurs existantes.
  • La gestion des secrets avec Vault et les variables sensibles.
  • Le workflow CI/CD avec GitHub Actions ou GitLab CI.

Retenir en 30 secondes​

  • HCL (HashiCorp Configuration Language) est le langage déclaratif de Terraform, hybride entre JSON et YAML.
  • Le cycle Terraform : terraform init → terraform plan → terraform apply → (terraform destroy en fin de vie).
  • Terraform est déclaratif : vous dites quoi, pas comment. Terraform calcule le chemin.
  • terraform plan est la commande la plus importante — elle montre ce qui va changer avant d'appliquer.
  • Règle absolue en équipe : jamais d'apply sans un plan revu par un humain.
  • La syntaxe HCL repose sur 4 constructions : blocs, variables, références, outputs.

Suivant : Providers, ressources, modules : la trinité Terraform →