Vous venez d’entendre parler de Terraform et vous voulez comprendre ce que c’est concrètement. Les scripts shell que vous utilisez aujourd’hui fonctionnent, mais ils n’ont pas de mémoire : lancer le script deux fois crée deux fois la ressource — ou échoue. Chaque environnement finit par diverger.
Analogie : un script shell est un touriste qui demande des directions à chaque fois (pas de mémoire). Terraform, c’est un GPS avec historique : il « se souvient » où il a créé les ressources, et si vous relancez la même commande, il vérifie que tout correspond, puis ajuste seulement ce qui a changé. C’est l’idempotence par conception.
Terraform est l’outil qui résout ce problème à son niveau
fondamental. C’est un outil d’Infrastructure as Code (IaC) :
vous décrivez dans des fichiers HCL l’état voulu de votre
infrastructure — VMs, réseaux, DNS — et Terraform compare cet
état avec son state (sa mémoire des ressources créées), mis à
jour depuis l’infrastructure réelle via les providers, puis
applique uniquement les changements nécessaires. Si la configuration,
le state et l’infrastructure réelle sont déjà alignés, un nouvel
terraform apply ne change rien : c’est l’idempotence par
conception. C’est pourquoi Terraform s’est imposé comme référence
dans l’écosystème DevOps pour provisionner n’importe quelle
infrastructure cloud ou on-premise.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Ce qu’est Terraform : définition simple et positionnement dans l’écosystème DevOps
- Quel problème il résout : pourquoi les scripts et les clics ne suffisent plus
- Ce qu’il fait et ne fait pas : périmètre de l’outil et limites à connaître
- Les concepts clés : provider, resource, state, plan — les quatre piliers
- Quand choisir Terraform : comparaison avec les scripts shell
Pourquoi Terraform existe
Section intitulée « Pourquoi Terraform existe »Avant les outils IaC, créer une infrastructure ressemblait à ceci :
- Se connecter à la console du cloud.
- Cliquer pour créer une VM, configurer le réseau, attacher un disque.
- Documenter les étapes, espérer que le collègue suive le même processus.
- Recommencer pour chaque environnement (dev, staging, prod).
Le résultat : des environnements divergents, des erreurs humaines, des infrastructures impossibles à recréer fidèlement.
Terraform résout ces problèmes en rendant l’infrastructure déclarative, versionnable et idempotente.
Ce que Terraform fait
Section intitulée « Ce que Terraform fait »
Terraform prend en charge le cycle de vie complet d’une infrastructure :
- Créer : provisionner de nouvelles ressources (VMs, réseaux, DNS…).
- Modifier : mettre à jour des ressources existantes en changeant leur configuration.
- Détruire : supprimer des ressources de manière contrôlée.
- Planifier : afficher les changements prévus avant de les appliquer.
- Mémoriser l’état : conserver la correspondance entre votre code et l’infrastructure réelle dans un fichier de state.
Ce que Terraform ne fait pas
Section intitulée « Ce que Terraform ne fait pas »Terraform ne remplace pas :
- Ansible : pour la configuration des serveurs après provisionnement.
- Kubernetes : pour l’orchestration des conteneurs.
- Docker : pour la création des images.
- CI/CD : pour le déploiement des applications.
Il s’intègre avec tous ces outils, mais n’a pas vocation à les remplacer.
Les concepts clés en bref
Section intitulée « Les concepts clés en bref »Terraform repose sur quatre concepts fondamentaux :
| Concept | Définition courte |
|---|---|
| Provider | Plugin qui connecte Terraform à une API (AWS, libvirt, Kubernetes…) |
| Resource | Objet géré par Terraform (une VM, un réseau, un bucket…) |
| State | Fichier qui mappe les ressources réelles à la configuration |
| Plan | Aperçu des changements avant application |
Ces concepts sont détaillés dans Providers, resources et data sources.
Exemples concrets de ce qu’on peut gérer avec Terraform
Section intitulée « Exemples concrets de ce qu’on peut gérer avec Terraform »- Libvirt/KVM : créer des VMs locales, réseaux virtuels, volumes disque.
- AWS : provisionner des instances EC2, VPCs, buckets S3, bases RDS.
- Kubernetes : déployer des namespaces, des
ConfigMap, desService. - GitHub : gérer des dépôts, des équipes, des règles de protection de branches.
- DNS : créer des entrées DNS chez Cloudflare, OVH, ou Route 53.
Un seul outil, des centaines de providers disponibles sur le Terraform Registry.
Terraform vs scripts shell
Section intitulée « Terraform vs scripts shell »On peut légitimement se demander pourquoi utiliser Terraform plutôt que des scripts shell ou de l’Ansible.
| Critère | Script shell | Terraform |
|---|---|---|
| Reproductible | Rarement | Toujours |
| Idempotent | À implémenter manuellement | Natif |
| Détection des changements | Non | Oui (plan) |
| Destroy intégré | Non | Oui |
| Gestion des dépendances | Manuelle | Automatique |
| Suivi d’état des ressources | Non | Via le state |
Un script shell crée une VM mais ne sait pas si elle existe déjà. Terraform le sait, grâce au state.
Historique rapide
Section intitulée « Historique rapide »| Année | Événement |
|---|---|
| 2014 | Première version publique par HashiCorp |
| 2017 | Terraform 0.10 : séparation des providers |
| 2021 | Terraform 1.0 : promesse de compatibilité v1.x (langage, workflow CLI, protocole provider) |
| 2023 | Changement de licence (BSL 1.1) → création d’OpenTofu |
| 2024 | Terraform 1.8 : fonctions de provider |
| 2026 | Terraform 1.14.x : branche stable actuelle |
À retenir
Section intitulée « À retenir »- Terraform décrit l’infrastructure souhaitée dans des fichiers
.tf. - Il planifie les changements, les applique, et mémorise l’état résultant.
- Il ne configure pas l’intérieur des serveurs — préférez Ansible, cloud-init ou Packer pour cela.
- Un provider connecte Terraform à chaque technologie (libvirt, AWS, GCP…).
- Le state est le fichier qui mappe votre code à l’infrastructure réelle.