Leçon 1 / 6
Leçon 01 · Terraform

C'est quoi Terraform ?

Le problème : gérer l'infra à la main

Imagine que tu dois créer une infrastructure cloud pour ton application : une VM sur AWS, un bucket S3, une base de données RDS, un load balancer, des règles de pare-feu… Tu ouvres la console AWS, tu cliques, tu remplis des formulaires, tu cliques encore. Deux heures plus tard, c'est en place.

Maintenant imagine devoir reproduire exactement la même infrastructure pour un environnement de staging. Ou la recréer après une fausse manipulation. Ou expliquer à ton collègue ce que tu as fait exactement. Le clic-clic dans les consoles cloud, ça ne scale pas.

⚠️

Sans code pour décrire ton infrastructure, chaque environnement devient unique et fragile. Une ressource supprimée par erreur, et tu passes des heures à reconstituer ce qui existait — si tant est que tu t'en souviens.

Terraform : déclarer l'état désiré en HCL

Terraform est un outil d'Infrastructure as Code (IaC) créé par HashiCorp en 2014. Son principe est simple : tu décris dans des fichiers texte l'infrastructure que tu veux, et Terraform se charge de la créer, modifier ou supprimer pour correspondre à cet état.

Ces fichiers utilisent le HCL (HashiCorp Configuration Language), un langage déclaratif lisible par un humain, conçu pour décrire des ressources d'infrastructure. Pas besoin d'être développeur — HCL ressemble à du JSON amélioré, avec des commentaires et une syntaxe plus souple.

💡

Terraform est open source (jusqu'à la version 1.5, sous licence MPL 2.0 — les versions suivantes utilisent la licence BSL). Il existe aussi OpenTofu, un fork communautaire entièrement open source, compatible avec les fichiers Terraform.

Le cycle plan / apply / destroy

Travailler avec Terraform, c'est suivre un cycle en trois commandes principales :

Les trois commandes fondamentales de Terraform
# 1. Voir ce que Terraform va faire (sans rien toucher)
terraform plan

# 2. Appliquer les changements (créer / modifier / supprimer)
terraform apply

# 3. Détruire toute l'infrastructure décrite dans les fichiers
terraform destroy

terraform plan est ta boîte de sécurité : il te montre exactement ce qui sera créé, modifié ou supprimé avant de toucher quoi que ce soit. C'est la commande que tu exécutes toujours en premier pour valider que ton code fait bien ce que tu penses.

Multi-cloud : un seul outil pour tout

L'une des grandes forces de Terraform, c'est son système de providers. Un provider est un plugin qui sait comment parler à une API : AWS, Azure, GCP, DigitalOcean, Cloudflare, GitHub, Kubernetes… il en existe des centaines.

Concrètement, tu peux gérer dans un même projet Terraform :

  • des VMs et des bases de données chez AWS
  • un domaine DNS chez Cloudflare
  • un cluster Kubernetes (et ses déploiements)
  • un dépôt GitHub avec ses secrets et ses webhooks
💡

Le registre officiel des providers Terraform (registry.terraform.io) en recense plus de 3 000. Si un service a une API, il y a probablement un provider Terraform pour le gérer.

Terraform vs Ansible : qui fait quoi ?

On confond souvent Terraform et Ansible. Voici la distinction clé :

Outil Rôle Langage Exemple concret
Terraform Provisioning — créer l'infra HCL Créer une VM EC2, un VPC, un bucket S3
Ansible Configuration — configurer l'infra YAML Installer Nginx, déployer une app sur la VM créée

Les deux outils sont complémentaires. Un pipeline typique : Terraform crée la VM chez AWS, Ansible la configure ensuite avec les bons services.

L'idempotence

Comme Ansible, Terraform est idempotent : si tu exécutes terraform apply plusieurs fois avec le même code, le résultat est toujours le même. Si la ressource existe déjà et correspond à l'état désiré, Terraform ne fait rien.

Terraform maintient un fichier d'état (terraform.tfstate) qui mémorise ce qu'il a créé. C'est grâce à ce fichier qu'il sait comparer l'état actuel du cloud avec ce que tu as décrit dans ton code.

⚠️

Le fichier terraform.tfstate peut contenir des données sensibles (mots de passe, clés d'API). Ne le committe jamais dans un dépôt public. En équipe, on le stocke dans un backend distant (S3, Terraform Cloud…).

Un exemple HCL concret : créer une instance EC2

Voici à quoi ressemble un fichier Terraform pour créer une instance EC2 (serveur virtuel) sur AWS avec une configuration minimale :

main.tf — Créer une instance EC2 sur AWS
# Déclarer le provider AWS
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "eu-west-3"  # Paris
}

# Créer une instance EC2
resource "aws_instance" "mon_serveur" {
  ami           = "ami-0d3c032f5934e1b41"  # Ubuntu 22.04 LTS (Paris)
  instance_type = "t3.micro"

  tags = {
    Name        = "mon-serveur-web"
    Environment = "production"
  }
}

Avec ces quelques lignes, terraform apply va créer un serveur Ubuntu sur AWS en région Paris. Pour le supprimer entièrement : terraform destroy. Pour savoir ce qu'il va faire avant d'agir : terraform plan.

// À retenir
  • Terraform permet de provisionner l'infrastructure en déclarant l'état désiré dans des fichiers HCL.
  • Le cycle de base : terraform plan (aperçu) → terraform apply (créer/modifier) → terraform destroy (supprimer).
  • Grâce aux providers, Terraform gère AWS, Azure, GCP, Cloudflare, Kubernetes et des centaines d'autres.
  • Terraform est idempotent : appliquer plusieurs fois le même code produit toujours le même résultat.
  • Terraform provisionne, Ansible configure — ils sont complémentaires.
  • Le fichier terraform.tfstate est la mémoire de Terraform — à protéger et à partager via un backend distant en équipe.