Aller au contenu principal

Le state file : le fichier qui rend Terraform intelligent

Résumé : le state file (terraform.tfstate) est le cœur battant de Terraform. Sans lui, aucun plan ne fonctionnerait. Cette leçon explique pourquoi il existe, ce qu'il contient, pourquoi il ne doit surtout pas rester en local dans une équipe, et comment le sécuriser via un backend distant avec verrouillage — un pattern devenu standard en 2026.

1. Pourquoi Terraform a besoin d'un state — le problème sans état​

Rappel du fonctionnement de Terraform : vous lancez terraform plan, il vous dit « 1 à créer, 0 à modifier, 0 à détruire ». Question : comment Terraform sait-il ce qui existe déjà et ce qu'il doit changer ?

Trois options théoriques :

Le state file est le pont entre :

  • Le code HCL (ce que vous voulez).
  • La réalité cloud (ce qui existe vraiment).

Sans lui, chaque plan serait catastrophiquement lent et fragile.

2. À quoi ressemble un state file​

Un state file est un fichier JSON. Voici un extrait simplifié.

{
  "version": 4,
  "terraform_version": "1.6.0",
  "serial": 42,
  "lineage": "d2c7b9c3-4e50-4f81-b7b2-6b9a0c8d1e2f",
  "resources": [
    {
      "mode": "managed",
      "type": "aws_instance",
      "name": "serveur_web",
      "provider": "provider[\"registry.terraform.io/hashicorp/aws\"]",
      "instances": [
        {
          "attributes": {
            "id": "i-0abc123def456",
            "ami": "ami-0c55b159cbfafe1f0",
            "instance_type": "t3.micro",
            "public_ip": "52.4.123.45",
            "private_ip": "10.0.1.20",
            "tags": {
              "Name": "serveur-web-production",
              "Environment": "prod"
            }
          }
        }
      ]
    }
  ]
}

Décodage :

  • serial — numéro de version qui incrémente à chaque changement.
  • lineage — identifiant unique du state, pour éviter les fusions accidentelles.
  • resources — la liste de toutes les ressources gérées, avec leurs attributs réels récupérés du cloud.

Le state contient donc :

Point crucial : le state contient toutes les valeurs sensibles (mots de passe, clés API, tokens) qui apparaissent dans vos ressources. C'est pourquoi il ne doit jamais rester en clair.

3. Le drame du state local — pourquoi on ne peut pas rester en local​

Par défaut, terraform init crée un fichier terraform.tfstate dans le dossier de travail — sur votre disque local. C'est pratique pour apprendre, mais inutilisable en équipe.

Résultat : en équipe, il faut un backend distant — un endroit sécurisé, partagé, verrouillé, chiffré, où le state vit.

4. Le backend distant — la solution moderne​

Un backend Terraform est le mécanisme qui définit où le state est stocké et comment il est manipulé.

4.1 · Les backends les plus utilisés​

Le choix par défaut en 2026 :

  • Vous êtes sur AWS → S3 + DynamoDB + KMS (pattern éprouvé).
  • Vous êtes sur GCP → Google Cloud Storage (simple et natif).
  • Vous êtes sur Azure → Azure Blob Storage (simple et natif).
  • Vous voulez zéro infra → Terraform Cloud (SaaS gratuit jusqu'à 500 ressources).
  • Vous êtes chez GitLab → backend GitLab natif (workflow CI/CD unifié).

4.2 · Configuration d'un backend S3​

Voici à quoi ressemble la configuration du backend S3, avec verrouillage DynamoDB :

terraform {
  backend "s3" {
    bucket         = "mon-entreprise-terraform-states"
    key            = "production/us-east-1.tfstate"
    region         = "us-east-1"
    encrypt        = true
    kms_key_id     = "alias/aws/s3"
    dynamodb_table = "terraform-state-lock"
  }
}

Décodage :

  • bucket — le bucket S3 où le state est stocké.
  • key — le chemin dans le bucket (permet plusieurs states dans un même bucket).
  • encrypt = true — chiffrement côté serveur activé.
  • kms_key_id — clé KMS pour le chiffrement.
  • dynamodb_table — table DynamoDB utilisée pour le verrouillage.

Ce que vous ne voyez pas ici — mais qui est essentiel — c'est que le bucket S3 lui-même doit :

  • Avoir le versionning activé (pour revenir en arrière en cas de corruption).
  • Bloquer tout accès public.
  • Avoir un cycle de vie pour supprimer les versions trop anciennes.
  • Avoir un rôle IAM strict — seuls les CI et les admins ont accès.

Ces pratiques élémentaires protègent votre infrastructure. Elles sont détaillées dans le Cours Premium Terraform.

5. Le verrouillage — éviter les catastrophes concurrentes​

Sans verrouillage, deux apply simultanés peuvent corrompre irrémédiablement votre state.

Avec verrouillage (DynamoDB, GCS, Azure Blob, Terraform Cloud) :

Règle absolue : jamais de Terraform en équipe sans backend distant avec verrouillage. Cette règle est aussi importante que « toujours utiliser Git ».

6. Le drift — quand la réalité diverge du code​

Le drift (« dérive » en français) est le phénomène où une ressource gérée par Terraform est modifiée en dehors de Terraform — par exemple, un admin qui change un paramètre à la main dans la console AWS pour un correctif urgent.

Le drift est ennemi de la reproductibilité. Pour l'éviter :

  • Interdire les modifications manuelles — le code Terraform est la seule source de vérité.
  • Utiliser un outil de détection — driftctl (open source) ou Terraform Cloud (payant) scannent régulièrement pour détecter les écarts.
  • Réagir immédiatement — si un drift est détecté, soit on met à jour le code pour refléter le changement, soit on rétablit l'état voulu.

7. Terraform import — apprivoiser l'existant​

Un cas fréquent : vous héritez d'une infrastructure créée à la main et vous voulez la placer sous gestion Terraform sans tout recréer.

Solution : terraform import.

terraform import aws_instance.serveur_web i-0abc123def456

Cette commande :

  1. Interroge l'API AWS pour récupérer les attributs actuels de la ressource i-0abc123def456.
  2. Écrit ces attributs dans le state, en les associant à la ressource logique aws_instance.serveur_web.
  3. Ensuite, vous devez écrire à la main le bloc resource "aws_instance" "serveur_web" {} correspondant, avec des valeurs cohérentes.
  4. Un terraform plan doit alors dire « 0 change » — sinon vous avez un mismatch à corriger.

Bonne nouvelle depuis Terraform 1.5 : la nouvelle syntaxe import en HCL permet d'importer de manière déclarative, versionnée dans Git, plus reproductible.

Cas d'usage typiques d'import :

C'est une compétence essentielle dans les grandes entreprises qui adoptent Terraform sur une infrastructure existante — sujet approfondi dans le Cours Premium Terraform.

8. Workspaces et environnements multiples​

Un même code Terraform peut créer plusieurs environnements (dev, staging, prod). Deux approches principales :

Règle d'or : prod et dev ne partagent jamais le même state. Un terraform destroy mal ciblé peut alors ne détruire qu'un environnement, jamais tous à la fois.

9. La règle d'or du state — jamais dans Git​

RÈGLE ABSOLUE : le fichier terraform.tfstate ne doit jamais être commité dans Git.

Pourquoi :

  • Il contient des secrets en clair (mots de passe, tokens, clés).
  • Il contient l'état complet de votre infrastructure, précieux pour un attaquant.
  • Il crée des conflits Git insolubles à chaque changement.

Toujours ajouter dans votre .gitignore :

# Terraform state files
*.tfstate
*.tfstate.*
*.tfstate.backup

# Terraform environment files
.terraform/
.terraform.lock.hcl

# Sensitive .tfvars
*.tfvars
!example.tfvars

Le state doit vivre dans un backend distant sécurisé. Point.

Retenir en 30 secondes​

  • Le state file est le cœur battant de Terraform — il fait le pont entre le code HCL et la réalité cloud.
  • Sans state, Terraform ne peut ni détecter les changements, ni orchestrer les dépendances, ni faire de plan.
  • En équipe, le state doit vivre dans un backend distant (S3, GCS, Azure Blob, Terraform Cloud, GitLab).
  • Le verrouillage (DynamoDB, GCS lock, Terraform Cloud) empêche les corruptions par apply concurrent.
  • Le drift est la divergence entre le code et la réalité — à surveiller avec driftctl ou Terraform Cloud.
  • terraform import permet d'apprivoiser une infrastructure existante sans downtime.
  • RÈGLE ABSOLUE : le state n'est jamais dans Git.

Suivant : Écosystème et alternatives : OpenTofu, Pulumi, CloudFormation →