Prendre RDV
Lexique · DevOps / Cloud / Data

Terraform : définition, fonctionnement et exemple HCL

L'outil d'Infrastructure as Code de HashiCorp qui crée et fait évoluer des ressources Cloud à partir de fichiers HCL : providers, fichier d'état, plan et apply, exemple, licence BSL et fork OpenTofu.

Par Équipe Blent· Mis à jour le · 13 min de lecture· Niveau intermédiaire

Terraform en bref

Type
Outil d'Infrastructure as Code
Éditeur
HashiCorp, filiale d'IBM depuis 2025
Lancement
2014 (version 1.0 en 2021)
Langage de description
HCL, déclaratif
Licence
BSL 1.1 depuis la version 1.6
Écrit en
Go
Fork open source
OpenTofu

Définition : Terraform

Terraform est un outil d'Infrastructure as Code créé par HashiCorp, qui permet de décrire des ressources Cloud (réseaux, machines, bases de données, clusters, droits d'accès) dans des fichiers écrits en HCL, un langage déclaratif. Un moteur compare ce code à un fichier d'état et aux ressources réelles, affiche un plan des changements prévus, puis appelle les API des fournisseurs par l'intermédiaire de plugins appelés providers. Le même outil et le même workflow couvrent AWS, Google Cloud, Azure, Kubernetes ou GitHub. Publié en 2014, Terraform est devenu la référence du provisionnement multi-cloud.

En une phrase : Terraform décrit votre infrastructure dans des fichiers HCL, calcule un plan des changements, puis les applique sur n'importe quel fournisseur Cloud via ses providers.

Dans cette définition

Qu'est-ce que Terraform ?

Terraform est l'outil le plus répandu pour appliquer l'Infrastructure as Code au Cloud. On y décrit dans des fichiers l'infrastructure souhaitée, et l'outil se charge de la créer, de la modifier ou de la supprimer en appelant les API des fournisseurs.

Il se distingue par son approche déclarative et son modèle de plugins. Le langage HCL (HashiCorp Configuration Language) exprime le résultat attendu, jamais la suite d'opérations. Les providers, des plugins distribués par un registre public, traduisent ces descriptions en appels d'API pour AWS, Azure, Google Cloud, Kubernetes et de nombreux services. Terraform n'est donc pas lié à un fournisseur, ce qui explique son adoption en entreprise.

Créé par Mitchell Hashimoto et publié par HashiCorp en 2014, Terraform a atteint la version 1.0 en 2021. En août 2023, HashiCorp a remplacé sa licence open source par la Business Source License, ce qui a conduit la communauté à créer le fork OpenTofu. HashiCorp a ensuite été rachetée par IBM, opération finalisée en 2025. Le code de Terraform s'intègre naturellement dans une démarche DevOps et dans les pipelines CI/CD.

À retenir : Terraform ne configure pas des serveurs, il provisionne des ressources. Il crée le réseau, la machine ou la base ; installer et configurer le logiciel dessus relève plutôt d'un outil comme Ansible.

Comment fonctionne Terraform ?

Un projet Terraform suit toujours le même cycle, quel que soit le fournisseur Cloud visé.

  1. Écrire la configuration

    L'ingénieur décrit dans des fichiers .tf les providers, les ressources, les variables et les sorties. Les blocs réutilisables sont regroupés en modules.

  2. Initialiser le projet

    La commande terraform init télécharge les providers et les modules nécessaires et configure le backend où sera stocké le fichier d'état.

  3. Planifier les changements

    La commande terraform plan compare le code, l'état enregistré et les ressources réelles, puis liste les créations, modifications et suppressions prévues.

  4. Appliquer le plan

    La commande terraform apply appelle les API des fournisseurs dans l'ordre des dépendances, calculé à partir du graphe des ressources.

  5. Enregistrer l'état

    Terraform met à jour le fichier d'état, qui associe chaque ressource du code à son identifiant réel chez le fournisseur, pour préparer le plan suivant.

Sous le capot : providers, état et graphe de dépendances

Les providers

Un provider est un binaire séparé du moteur, téléchargé à l'initialisation. Il déclare les types de ressources qu'il gère (par exemple aws_s3_bucket) et sait les créer, lire, modifier et supprimer. La version du provider se verrouille dans le fichier .terraform.lock.hcl, à versionner dans Git pour que toute l'équipe utilise les mêmes.

Le fichier d'état

Terraform conserve un fichier d'état qui associe chaque ressource du code à son identifiant réel. C'est grâce à lui qu'il sait ce qu'il doit créer, modifier ou détruire. Ce fichier peut contenir des valeurs sensibles : il se stocke dans un backend distant, chiffré et verrouillé pendant chaque exécution, jamais dans Git.

Le graphe de dépendances

Quand une ressource en référence une autre, par exemple l'identifiant d'un réseau utilisé par une machine, Terraform en déduit un ordre de création. Il construit un graphe de dépendances, puis parallélise tout ce qui est indépendant.

Exemple : un bucket versionné avec Terraform

Voici une configuration minimale qui crée un bucket S3 versionné sur AWS, paramétré par une variable, avec un état distant partagé.

hcl
terraform {
  required_version = ">= 1.6"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }

  # État partagé et verrouillé pour toute l'équipe
  backend "s3" {
    bucket = "acme-terraform-state"
    key    = "production/donnees.tfstate"
    region = "eu-west-3"
  }
}

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

variable "environnement" {
  type    = string
  default = "production"
}

resource "aws_s3_bucket" "donnees" {
  bucket = "acme-${var.environnement}-donnees"
}

resource "aws_s3_bucket_versioning" "donnees" {
  bucket = aws_s3_bucket.donnees.id

  versioning_configuration {
    status = "Enabled"
  }
}

output "nom_du_bucket" {
  value = aws_s3_bucket.donnees.bucket
}

Le cycle d'exécution tient en quelques commandes :

bash
terraform init                    # télécharge le provider et configure le backend
terraform fmt -check              # vérifie le format du code
terraform validate                # vérifie la cohérence de la configuration
terraform plan -out=plan.tfplan   # affiche et enregistre les changements prévus
terraform apply plan.tfplan       # applique exactement le plan relu

Le code ne dit jamais « crée » : il décrit le résultat. La ressource de versionnement référence le bucket par aws_s3_bucket.donnees.id, ce qui crée une dépendance et impose l'ordre de création. Relancer terraform plan sans changement n'annonce rien à faire ; si quelqu'un désactive le versionnement à la main, le plan suivant le détecte et propose de le réactiver.

Les principaux cas d'usage de Terraform

Terraform sert dès qu'une ressource Cloud doit être créée de façon répétable, relue et auditée.

  • Socle Cloud

    Déployer comptes, réseaux, droits et règles de sécurité communs à toutes les équipes.

  • Environnements multiples

    Créer développement, préproduction et production à partir du même code et de variables distinctes.

  • Clusters Kubernetes

    Provisionner un cluster managé et ses dépendances de réseau, de stockage et d'identité.

  • Environnements éphémères

    Monter un environnement complet pour tester une branche, puis le détruire.

  • Multi-cloud

    Piloter AWS, Azure, Google Cloud et des services SaaS avec un seul langage.

  • Migration et reprise

    Reconstruire une infrastructure dans une autre région ou importer des ressources existantes.

Quels sont les avantages de Terraform ?

Terraform doit son succès à un langage lisible, à un écosystème très large et à un workflow prévisible.

  • Un seul workflow et un seul langage pour des centaines de fournisseurs, publics ou privés.
  • Un plan d'exécution relisible avant toute modification de l'infrastructure.
  • Un langage déclaratif, plus lisible qu'un script pour décrire un état cible.
  • Une très large communauté, avec de nombreux providers et modules partagés.
  • Un graphe de dépendances qui ordonne et parallélise automatiquement les opérations.
  • Une intégration naturelle dans les pipelines CI/CD et les revues de code.

Quelles sont les limites de Terraform ?

Terraform n'est pas une garantie automatique de bonne infrastructure : l'outil exécute fidèlement le code, y compris ses erreurs.

  • Un fichier d'état sensible, à partager, verrouiller, sauvegarder et protéger.
  • Une licence BSL qui n'est plus open source, avec des restrictions pour certains usages commerciaux.
  • Une dérive possible dès que des ressources sont modifiées à la main dans la console.
  • Un HCL limité pour la logique complexe, malgré les boucles et les expressions conditionnelles.
  • Des erreurs à fort impact : une suppression mal relue dans un plan peut toucher la production.
  • Une dépendance aux providers, dont la couverture des nouveautés suit celle des API.

Terraform vs OpenTofu vs Pulumi : quelles différences ?

Ces trois outils répondent au même besoin de provisionnement, avec des choix différents de licence et de langage.

CritèreTerraformOpenTofuPulumi
Éditeur ou gouvernanceHashiCorp (IBM)Linux Foundation, communautéPulumi
LicenceBSL 1.1Open source (MPL 2.0)Apache 2.0 pour le moteur
LangageHCLHCLTypeScript, Python, Go, C#, Java
ProvidersRegistre TerraformCompatibles, registre OpenTofuProviders Pulumi, dont des ponts vers Terraform
Fichier d'étatBackend au choixBackend au choix, chiffrement natifService managé ou backend au choix
ÉcosystèmeLe plus largeHérité de Terraform, en croissancePlus restreint, orienté développeurs

OpenTofu a été annoncé en septembre 2023, puis publié en version stable début 2024. Pour un projet existant, la migration est le plus souvent simple, car le langage et les providers sont communs, mais les deux outils divergent peu à peu sur les nouvelles fonctionnalités.

Ce n'est pas un choix binaire. Le choix dépend moins de la technique que de la licence et des compétences : HCL pour les équipes d'exploitation, langage généraliste pour les équipes de développement.

Bonnes pratiques pour un projet Terraform en équipe

Pour passer d'un premier essai à un usage en équipe, quelques règles évitent la plupart des incidents :

  • État distant : un backend partagé, verrouillé et chiffré, avec un état séparé par environnement.
  • Modules : factoriser les blocs répétés, avec des versions explicites.
  • Pipeline : exécuter plan dans la pull request, apply seulement après fusion, dans un pipeline CI/CD aux droits limités.
  • Contrôles : formater, valider, analyser avec Checkov ou Trivy, puis tester l'infrastructure.
  • Dérive : lancer un plan planifié pour détecter les modifications manuelles, et limiter les droits d'écriture dans la console.

Pour aller plus loin, une approche GitOps applique le même principe : Git reste l'unique source de vérité, et l'application est automatique. Les ressources Cloud peuvent aussi se piloter depuis un cluster avec Crossplane.

Quand utiliser Terraform ?

Terraform convient bien au provisionnement de ressources Cloud. Il est moins adapté à la configuration fine de systèmes ou à des besoins très dynamiques.

Pertinent si

Le besoin relève du provisionnement

  • Vous créez des ressources Cloud qui doivent être reproductibles.
  • Vous travaillez sur plusieurs fournisseurs ou plusieurs comptes.
  • Vous voulez relire un plan avant chaque changement.
  • Votre équipe a besoin d'une communauté et de modules éprouvés.
Moins adapté si

Un autre outil sera plus adapté

  • Vous configurez surtout des serveurs existants, ce que fait mieux Ansible.
  • Vous préférez écrire l'infrastructure dans un langage généraliste.
  • Vous voulez piloter les ressources Cloud depuis Kubernetes.
  • La licence BSL est incompatible avec votre usage ou votre politique open source.

Technologies et outils associés à Terraform

Autour du moteur, un écosystème d'outils couvre l'orchestration, les tests, la sécurité et l'automatisation.

Les concepts à connaître autour de Terraform

Ces notions reviennent dans tout projet Terraform et dans les pratiques qui s'appuient dessus.

Ressources pour approfondir Terraform

Trois articles du blog Blent pour écrire, tester et comparer son infrastructure en code.

Questions fréquentes

Questions fréquentes

Terraform est un outil d'Infrastructure as Code de HashiCorp. Il lit des fichiers HCL décrivant les ressources voulues, calcule les différences avec l'existant, puis crée, modifie ou supprime les ressources chez les fournisseurs Cloud. Il sert à rendre l'infrastructure reproductible, relue et versionnée.

Expertise

À propos de l'auteur

Équipe Blent

Les ingénieurs et mentors Blent conçoivent, automatisent et mettent en production des infrastructures Cloud, et forment chaque année des centaines de professionnels au Cloud et au DevOps.

Sources et méthodologie

  • Documentation officielle de Terraform, HashiCorp
  • Annonce du changement de licence de HashiCorp vers la BSL 1.1, août 2023
  • Documentation officielle d'OpenTofu, Linux Foundation
  • Retours d'expérience des projets et formations Blent
Lexique

Explorer le lexique

Voir toutes les définitions