Pourquoi l'IaC ? Introduction à Terraform

Gérer des serveurs à la main, c’est comme écrire du code sans Git : ça marche jusqu’au jour où tout explose et que personne ne sait ce qui a changé. L’Infrastructure as Code résout ce problème. Terraform est l’outil qui l’a démocratisé. Ce premier chapitre pose les bases — du concept à ton premier serveur déployé en quelques lignes de code.

L’Infrastructure as Code, c’est quoi concrètement ?

Tu veux créer un serveur cloud. Sans IaC, tu te connectes à la console web, tu cliques sur “Créer”, tu choisis la taille, la région, l’OS… et tu recommences à chaque fois. Six mois plus tard, personne ne sait comment l’infra a été construite.

L’Infrastructure as Code (IaC) inverse cette logique : au lieu de cliquer, tu décris ton infrastructure dans des fichiers texte. Ces fichiers vivent dans Git, se versionnent, se partagent et se rejouent à l’identique.

💡 L’analogie qui marche : cuisiner “au feeling” donne un résultat différent à chaque fois. Écrire la recette — ingrédients, quantités, étapes — permet à n’importe qui de reproduire le même plat. Terraform, c’est la recette de ton infrastructure.

Les bénéfices sont immédiats :

• Reproductible — Le même fichier crée la même infra, à chaque fois
• Versionné — Chaque changement est tracé dans Git, réversible, auditable
• Automatisable — Un terraform apply remplace 45 minutes de clics
• Documenté — Le code est la documentation, pas un wiki obsolète
• Collaboratif — Branches, reviews, merge requests… comme du code applicatif

Déclaratif vs impératif

Terraform utilise une approche déclarative : tu décris l’état souhaité, pas les étapes pour y arriver.

# Impératif (script shell) — tu gères l'ordre, les erreurs, l'idempotence
hcloud server create --name web-1 --type cx22 --image ubuntu-24.04
hcloud volume create --name data --size 50 --server web-1

# Déclaratif (Terraform) — tu décris ce que tu veux, Terraform gère le reste
resource "hcloud_server" "web" {
  name        = "web-1"
  server_type = "cx22"
  image       = "ubuntu-24.04"
}

Avec l’approche déclarative, Terraform calcule lui-même ce qu’il faut créer, modifier ou supprimer. Tu n’as pas à gérer l’ordre des opérations ni le cas “la ressource existe déjà”.

Pourquoi Terraform plutôt qu’un autre outil ?

Il existe d’autres outils d’IaC — Pulumi, CloudFormation, Ansible, OpenTofu. Terraform reste le standard de facto pour plusieurs raisons :

• Multi-cloud — Un seul langage pour AWS, GCP, Azure, Hetzner, Cloudflare et 4 000+ providers
• HCL — Un langage dédié, lisible, ni trop verbeux (YAML) ni trop complexe (Python)
• Plan avant exécution — terraform plan montre exactement ce qui va changer avant de toucher à quoi que ce soit
• State management — Terraform maintient un état de ton infra pour ne modifier que le nécessaire
• Écosystème massif — Documentation partout, communauté énorme, modules réutilisables

🔥 OpenTofu : fork open-source de Terraform né après le changement de licence HashiCorp (BSL, 2023). La syntaxe est identique — tout ce que tu apprends ici s’applique aux deux outils.

Installation et premier contact

# macOS
brew tap hashicorp/tap && brew install hashicorp/tap/terraform

# Linux (Ubuntu/Debian)
wget -O- https://apt.releases.hashicorp.com/gpg | \
  sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] \
  https://apt.releases.hashicorp.com $(lsb_release -cs) main" | \
  sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install terraform

# Vérification + autocomplétion
terraform version          # Terraform v1.11.x
terraform -install-autocomplete  # Recharge ton shell ensuite

La syntaxe HCL : les blocs essentiels

HCL (HashiCorp Configuration Language) organise tout en blocs. Un bloc a un type, des labels optionnels et un corps entre accolades.

Les 4 blocs que tu utiliseras tout le temps

Le bloc terraform configure l’outil lui-même — versions requises, providers nécessaires :

terraform {
  required_version = ">= 1.5"
  required_providers {
    hcloud = {
      source  = "hetznercloud/hcloud"
      version = "~> 1.49"
    }
  }
}

Le bloc provider configure la connexion à une API cloud :

provider "hcloud" {
  token = var.hcloud_token
}

Le bloc resource déclare une ressource à créer — c’est le cœur de Terraform. Le premier label est le type (défini par le provider), le second est le nom logique (tu choisis) :

resource "hcloud_server" "web" {
  name        = "web-1"
  server_type = "cx22"
  image       = "ubuntu-24.04"
  location    = "fsn1"
}

Le bloc data lit des données existantes sans les créer ni les modifier :

data "hcloud_ssh_key" "default" {
  name = "my-key"
}

Les références entre ressources

Terraform comprend les dépendances automatiquement. Quand tu écris hcloud_ssh_key.default.id dans une ressource serveur, Terraform sait qu’il doit d’abord créer la clé SSH, puis le serveur. Pas besoin de gérer l’ordre manuellement.

Cas entreprise : de 3 serveurs manuels à 30 en IaC

Une startup SaaS gère 3 serveurs créés à la main dans la console Hetzner. Problèmes classiques :

• Le serveur de staging n’a pas la même config que la prod (personne ne sait pourquoi)
• Un dev a créé un volume de 100 Go “pour tester” — il tourne depuis 8 mois
• Impossible de recréer l’environnement complet après un incident

Avec Terraform, l’équipe décrit ses 3 environnements (dev, staging, prod) dans des fichiers .tf versionnés. Chaque environnement est identique par construction. Un terraform plan détecte immédiatement les drifts. Les nouveaux devs comprennent l’infra en lisant le code, pas en fouillant la console.

🎯 Le vrai gain : quand l’équipe passe de 3 à 30 serveurs pour le Black Friday, c’est un changement de variable, pas 3 heures de clics.

Les pièges classiques du débutant

⚠️ Token en dur dans le code — Ne fais jamais ça. Utilise une variable d’environnement :

export HCLOUD_TOKEN="ton-token-ici"

Terraform le détecte automatiquement. Ton token ne finit pas dans Git.

⚠️ Ignorer le plan — Toujours lancer terraform plan avant apply. C’est ton filet de sécurité. Un destroy accidentel de ta base de données prod, ça arrive plus vite qu’on croit.

⚠️ Modifier les ressources à la main — Si tu changes un serveur dans la console web après l’avoir créé avec Terraform, tu crées un drift. Au prochain apply, Terraform va écraser tes changements manuels pour revenir à l’état décrit dans le code.

⚠️ Committer le state — Le fichier terraform.tfstate contient des données sensibles (IPs, tokens…). Ajoute-le à ton .gitignore. On verra dans un chapitre suivant comment stocker le state de manière sécurisée.

💡 Règle d’or : si c’est dans Terraform, ne touche pas à la console. Si c’est dans la console, ne le mets pas dans Terraform sans importer d’abord.

Résumé

L’Infrastructure as Code transforme la gestion d’infrastructure en pratique d’ingénierie logicielle. Terraform est l’outil de référence pour ça — multi-cloud, déclaratif, avec un écosystème massif.

Ce qu’on a couvert :

• IaC = décrire son infra dans des fichiers texte versionnés
• Terraform = outil déclaratif, multi-cloud, avec plan avant exécution
• HCL = langage structuré en blocs (terraform, provider, resource, data)
• Providers = plugins qui connectent Terraform aux APIs cloud
• Workflow de base = init → plan → apply

Dans le prochain chapitre, on maîtrise le workflow complet : init, plan, apply, destroy — et on découvre le rôle central du state Terraform.