Quand tu ouvres Slack le matin, les serveurs qui te répondent n'ont pas été créés à la main dans une console. Ils ont été décrits dans des fichiers texte, relus dans une demande de fusion, puis construits par Terraform. Même chose chez GitHub, chez Decathlon, et dans des milliers d'équipes plus petites. Voici quatre faits publics, vérifiables, avec leur source.
| Qui | Ce qu'ils font avec Terraform | Source |
|---|---|---|
| Slack | Une seule syntaxe pour AWS, DigitalOcean, NS1 et Google Cloud. Près de 1 400 fichiers de state, chacun détenu par l'équipe qui possède le service. State stocké dans S3 avec versionnage, verrouillé par DynamoDB. Un outil maison poste le terraform plan dans chaque pull request avant la fusion. | How We Use Terraform At Slack, billet d'ingénierie de Slack, 25 octobre 2022 |
| GitHub | « Presque tous nos hôtes, y compris ceux du centre de données, sont gérés par Terraform et construits de la même façon, que ce soit sur Azure, AWS ou une autre plateforme. » Prototyper un nouveau service prenait plusieurs jours ; avec Terraform, moins d'une heure. | Étude de cas HashiCorp — GitHub, propos d'Aaron Brown, ingénieur infrastructure |
| Decathlon | Avant : plus d'une semaine pour obtenir une infrastructure, le temps de passer par plusieurs équipes et une CMDB. Après : « ce qui prenait plus d'une semaine se fait maintenant en moins de 30 minutes », et chaque marque construit ce dont elle a besoin, seule. | Étude de cas HashiCorp — Decathlon, propos de Kévin Defives, ingénieur systèmes d'information |
| Toute la communauté | Le Terraform Registry compte plus de 7 200 providers (les plugins qui parlent aux API) et plus de 24 000 modules réutilisables. Le seul provider AWS a dépassé 5 milliards de téléchargements : huit ans pour le premier milliard, deux ans pour les quatre suivants. | Terraform Registry (compteur de l'API du Registry, relevé le 15 septembre 2026) · HashiCorp, 24 novembre 2025 |
Ce que ces équipes ont en commun : elles ont toujours une console cloud, et elles s'en servent pour regarder. Mais la source de vérité, ce qui dit ce qui doit exister, c'est le code. Personne ne crée un serveur en cliquant. C'est exactement ce que tu vas faire dans ce cours, en petit : d'abord un fichier texte sur ta machine, puis un bucket S3, puis quatre plateformes à la fois.
Six mots reviendront dans chaque leçon. Ils sont donnés ici avec la définition que HashiCorp en fait, traduite, et le lien vers la page officielle.
| Terme | Ce que c'est | Référence officielle |
|---|---|---|
| Infrastructure as Code (IaC) | Gérer l'infrastructure dans un ou plusieurs fichiers plutôt qu'en la configurant à la main dans une interface. Machines virtuelles, groupes de sécurité, interfaces réseau, buckets, dépôts Git : tout ce qui a une API peut se décrire dans un fichier. | Glossaire Terraform — Infrastructure as Code |
| Déclaratif (contre impératif) | Un fichier déclaratif décrit le résultat attendu : « ce bucket doit exister, avec ces étiquettes ». Un script impératif décrit les étapes : « appelle create-bucket, puis put-bucket-tagging… ». Les fichiers Terraform sont déclaratifs : tu n'écris pas les étapes, Terraform les déduit. | What is Terraform — configuration déclarative |
| Idempotence | Relancer la même opération plusieurs fois donne le même résultat qu'une seule fois. Si l'infrastructure correspond déjà au code, terraform plan annonce qu'aucune action n'est nécessaire (No changes. Your infrastructure matches the configuration.) et apply ne touche à rien. Un script qui enchaîne des appels create-…, relancé, échoue sur ce qui existe déjà ou crée un doublon. | Référence de terraform plan |
| Dérive (drift) | L'écart entre ce que le state croit et ce qui existe vraiment, parce que quelqu'un a modifié une ressource en dehors de Terraform (dans la console, par un script, à la main). Terraform la détecte au moment du plan en relisant l'infrastructure réelle. | Tutoriel — Manage resource drift |
| State | Le fichier (terraform.tfstate) où Terraform note quel bloc du code correspond à quel objet réel (avec son identifiant, ses attributs). Sans lui, Terraform ne saurait pas qu'un bucket qui existe déjà est « le sien » et le recréerait. Il est sensible : il peut contenir des mots de passe et des adresses. | Terraform state |
| Provider | Un plugin qui connaît l'API d'une plateforme (AWS, Azure, Google Cloud, GitHub, ou même le disque local) et expose ses objets sous forme de types de ressources. Terraform les télécharge au terraform init. C'est le provider qui fait les appels d'API, pas Terraform lui-même. | Providers |
Imagine un architecte chargé d'un bâtiment. Il a trois choses sous la main.
.tf.Chaque fois qu'on lui demande d'intervenir, l'architecte fait la même chose. Il relit le plan. Il ouvre son relevé. Il va voir le bâtiment. Puis il compare les trois et il écrit un devis de travaux : ce mur manque, il faut le construire ; cette porte n'est pas au plan, il faut la retirer ; cette fenêtre est au bon endroit, on n'y touche pas. Le devis est signé par le client, et seulement ensuite les corps de métier (les providers) exécutent chaque ligne. Rien de plus, rien de moins que le devis.
Cette image revient dans tout le cours. Quand une leçon parle du plan, du relevé et du bâtiment, elle parle du code, du state et de l'infrastructure réelle.
La différence essentielle entre « le plan » et
terraform plan. Dans l'image, le plan est le dessin de l'architecte, c'est-à-dire ton code. La commandeterraform plan, elle, produit le devis de travaux : la liste de ce qui va changer pour que le bâtiment rejoigne le plan. Deux sens pour un même mot. Dans le cours, on écrit « le plan (le code) » ou « le devis (la sortie deterraform plan) » quand il y a un risque de confusion.
Tu peux créer un bucket S3 de trois façons sans Terraform : en cliquant, en lançant un script, ou en suivant une procédure écrite. Chacune a sa place. Aucune ne fait le travail de l'architecte.
| Méthode | Ce qu'elle fait bien | Ce qu'elle ne fait pas |
|---|---|---|
| La console (AWS, Azure, GCP dans le navigateur) | Explorer, comprendre un service, regarder un objet précis, dépanner vite. | Reproduire à l'identique. Deux personnes qui cliquent « pareil » obtiennent deux résultats. Pas d'historique lisible de qui a changé quoi. Rien à relire avant de valider. |
Un script bash ou PowerShell (aws ec2 run-instances …, aws s3api create-bucket …) | Rejouer une création à l'identique, l'enchaîner dans un pipeline. | Savoir ce qui existe déjà. Relancé une deuxième fois, il essaie de recréer et s'arrête sur une erreur, ou crée un doublon. Il ne compare rien, ne détecte pas qu'une règle a été changée à la main, et ne sait pas détruire ce qu'il a créé sans un second script écrit à la main. |
| Un runbook (procédure écrite, captures d'écran) | Transmettre une intention, former quelqu'un, garder une trace de la décision. | Prouver que l'infrastructure correspond encore au texte. Le lendemain d'une modification en console, le runbook est faux et personne ne le sait. |
Terraform fait ce que ces trois méthodes ne font pas, et le fait dans cet ordre : il lit l'existant, il compare au code, il annonce ce qui va changer, il applique seulement ce qui manque, il note ce qu'il a fait dans le state, et il sait tout détruire proprement avec terraform destroy. Chaque projet du cours se termine par cette destruction : rien ne reste actif, rien ne reste facturé.
Imagine qu'une entreprise doive lancer une application web. Il faut peut-être créer :
Tu peux tout créer à la main dans une console AWS, Azure ou Google Cloud. Ça fonctionne pour un premier essai. Ça devient fragile dès que l'environnement grandit.
Relis le tableau des exemples réels : Decathlon décrit le coût de la méthode manuelle (plus d'une semaine, plusieurs équipes et une CMDB à remplir pour un seul serveur), GitHub répond à la difficulté 1 (des hôtes construits « de la même façon » partout), Slack à la difficulté 5 (le devis relu dans la pull request avant toute fusion).
L'Infrastructure as Code, abrégée IaC, consiste à décrire l'infrastructure dans des fichiers traités comme du code. HashiCorp définit Terraform comme un outil d'IaC qui permet de définir des ressources cloud et sur site dans des fichiers de configuration lisibles, que tu peux versionner, réutiliser et partager. Référence officielle — Introduction à Terraform
Au lieu d'écrire une longue procédure comme « clique ici, choisis cette région, crée ensuite ce réseau », tu décris l'état souhaité :
resource "aws_s3_bucket" "documents" {
bucket = "entreprise-documents-exemple"
}Ce bloc ne décrit pas chaque appel d'API. Il dit : « ce bucket doit exister avec cette configuration ». C'est le plan de l'architecte. Terraform détermine ensuite les travaux nécessaires.
Le même code sert à créer un environnement de développement, de test ou de production. Les valeurs qui changent sont placées dans des variables plutôt que copiées à la main.
terraform plan présente les créations, modifications et destructions prévues : c'est le devis de travaux. L'équipe révise l'intention avant que Terraform touche à l'infrastructure. Les symboles sont fixés par la documentation officielle. Référence officielle — terraform plan
+ création
~ modification sur place
-/+ remplacement (détruire, puis recréer)
- destructionAttention : un plan réduit le risque, il ne garantit pas l'absence d'impact. Une modification de réseau, de base de données ou d'identité reste dangereuse et doit être examinée ligne par ligne.
Les fichiers .tf vivent dans Git. Chaque changement est associé à une branche, une demande de fusion, une révision et un auteur. C'est ce que fait Slack : le devis est posté dans la pull request, et personne ne fusionne sans l'avoir lu.
Une organisation encapsule ses règles dans des modules réutilisables : chiffrement obligatoire, étiquettes de coûts, journaux activés, réseau approuvé et versions contrôlées. Les modules permettent de réutiliser des collections configurables de ressources. Référence officielle — Modules Terraform
Terraform ne sert pas seulement à créer. Il compare la configuration, le state et l'infrastructure réelle pour déterminer quoi ajouter, modifier ou supprimer. C'est le geste de l'architecte : relire le plan, ouvrir le relevé, aller voir le bâtiment.
Terraform demande un investissement initial : apprendre HCL, écrire les modules, sécuriser le state et construire une chaîne d'approbation. Cet investissement devient rentable dès que l'équipe doit répéter, auditer ou faire évoluer l'infrastructure.
Exemple : une entreprise possède 30 applications et quatre environnements par application. À la main, c'est 120 environnements à maintenir. Des modules communs permettent de décrire le modèle une fois et de fournir les valeurs propres à chaque application.
Terraform automatise une intention. Si le code demande une mauvaise architecture, Terraform reproduit cette mauvaise architecture très efficacement, et partout. Il faut toujours :
L'architecte ne construit pas ce qu'il veut. Il construit ce qui est dessiné. Si le dessin est mauvais, le bâtiment le sera aussi.
Lis le schéma de gauche à droite. Le plan et le relevé entrent chez l'architecte. Il va voir le bâtiment. Il produit un devis. Tu le signes. Les corps de métier exécutent, et l'architecte met son relevé à jour. Au prochain tour, si rien n'a bougé, le devis est vide : No changes.
terraform plan est-il utile avant une mise en production ?