Si vous avez déjà écrit quelques fichiers .tf, vous savez qu’un projet Terraform commence souvent très bien. Mais il se transforme vite en forêt de modules, de dossiers et de pipelines CI/CD. On ajoute un environnement de plus, puis un deuxième cloud, puis un cluster Kubernetes. Et soudain, plus personne ne sait vraiment où commence et où finit l’infrastructure.
C’est exactement ce problème que Terraform Stacks vient résoudre. HashiCorp présente les Stacks comme une nouvelle couche de configuration, qui permet de découper votre infrastructure en composants, puis de les déployer et de les gérer de manière cohérente sur plusieurs environnements.
Dans cet article, nous allons voir ensemble ce que sont les Stacks, ce que ça change concrètement pour les équipes cloud.
Terraform Stacks, c’est quoi au juste ?
Dans la documentation officielle d’HashiCorp, HashiCorp décrit Terraform Stacks comme un moyen de scinder votre configuration en composants (network, base de données, application, monitoring…). Vous pouvez ensuite déployer ces composants sur plusieurs environnements tout en les gérant comme une seule unité logique
Concrètement, vous continuez à écrire des modules et des ressources Terraform comme avant. La différence, c’est qu’au dessus de ces modules, vous ajoutez une configuration de Stack qui décrit :
- de quels composants votre système est constitué ;
- comment ces composants dépendent les uns des autres ;
- sur quels environnements ou compte cloud ils doivent être déployés ;
- comment vous voulez gérer leur cycle de vie.
Le Stack devient un peu la « carte du territoire » de votre infrastructure. Avant, cette carte vivait dans un mélange de scripts Bash, de README et de jobs GitLab ou GitHub Actions. Désormais, vous la déclarez directement dans Terraform.
Depuis 2025, HashiCorp propose Terraform Stacks en version stable (GA) dans HCP Terraform et dans l’écosystème Terraform. Vous bénéficiez en plus de fonctionnalités comme les Linked Stacks et la gestion de cycle de vie des modules.
Envie de passer au niveau supérieur sur l’Infrastructure as Code ?
L’équipe Ambient IT
Notre formation Terraform avancée vous aide à structurer vos projets, exploiter les providers, construire une librairie de modules réutilisables et poser les bases d’une plateforme cloud maintenable.
Pourquoi Terraform Stacks change votre manière de fare de l’IaC
Pendant longtemps, l’orchestration d’infrastructure autour de Terraform reposait surtout sur du bricolage : Terragrunt pour certains, des scripts internes pour d’autres, u encore des pipeline CI/CD qui enchaînent des dossiers Terraform dans un ordre bien précis. Ça fonctionne, mais la logique reste souvent dispersée, difficile à documenter, et encore plus difficile à faire évoluer.
Avec Terraform Stacks, cette orchestration devient une partie officielle du langage. Vous décrivez des composants et vous indiquez comment les combiner. Terraform gère ensuite le reste : ordre d’exécution, dépendances, mise à jour progressive des environnements.
L’autre changement majeur concerne la gestion des environnements. Sans Stacks, beaucoup d’équipes dupliquent des dossiers (ou même des dépôts Git) pour dev, recette, pré-prod et prod. Avec le temps, chaque environnement dérive doucement des autres et on se retrouve avec des « presque la même chose, sauf… ». Les Stacks, eux, encouragent une approche inverse : définir une architecture une seule fois, puis la rejouer sur plusieurs environnements via des déploiements paramétrés, mais structurés de la même manière, comme l’explique HashiCorp.
Ainsi, vous cachez moins de configuration dans les pipelines et vous obtenez une infrastructure plus prévisible.
Un exemple concret du rangement de votre infra
Imaginez une équipe qui gère une plateforme assez classique dans le cloud :
- un socle réseau (VPC, sous-réseaux, gateways),
- un module sécurité (IAM, policies, règles),
- des bases de données managées,
- plusieurs applications,
- du monitoring et de l’observabilité.
Dans le modèle historique, on voit souvent un dépôt par grande brique, voire par environnement. On se retrouve avec des dizaines de pipelines et des backends Terraform partout. La documentation se résume trop souvent à « demande à untel, c’est lui qui sait dans quel ordre lancer les jobs ».
Avec Terraform Stacks, cette même équipe conserve ses modules, mais introduit un Stack qui les assemble.
- quels composants existent,
- dans quel ordre ils doivent être déployés,
- comment ils sont répliqués sur les différents environnements.
Pour un nouveau membre qui arrive dans l’équipe, la courbe d’apprentissage change complètement. Au lieu de parcourir quatre dépôts et trois fichiers CI, il peut commencer par la définition du Stack, qui sert de point d’entrée unique pour l’infrastructure
C’est aussi un excellent support pédagogique car, dans Terraform, il est possible de partir d’un projet mono-module, puis montrer comment on le découpe en composants. Enfin comment on crée un Stack qui décrit l’architecture globale. On visualise ainsi le passage de “quelques ressources” à “une plateforme entière” sans perdre la lisibilité.
Terraform Stacks, OpenTofu et la stratégie à long terme
Depuis le changement de licence de Terraform et la naissance d’OpenTofu, beaucoup d’équipes se posent logiquement la question : où investir pour les prochaines années ? OpenTofu est un fork communautaire soutenu par la Linux Foundation, présenté comme un successeur open source et compatible avec l’écosystème Terraform existant.
Aujourd’hui, les Terraform Stacks sont une innovation portée par HashiCorp dans HCP Terraform et l’écosystème Terraform officiel. De son côté, OpenTofu se concentre plutôt sur la stabilité, la compatibilité et la gouvernance ouverte.
Les deux approches restent proches sur le plan fonctionnel. En revanche, leur vision diffère légèrement :
- Terraform pousse vers une plateforme intégrée, avec des Stacks, de la gestion de cycle de vie des modules, des tags avancés et des fonctionnalités orientées grandes organisations.
- OpenTofu met l’accent sur une alternative open source pérenne, alignée avec l’écosystème CNCF et les besoins des entreprises qui veulent limiter leur dépendance à un seul éditeur.
Ces deux approches sont détaillées dans notre article dédié : Terraform VS OpenTofu : l’avenir du DevOps se joue maintenant.
Terraform Stacks et la maturité de vos pratiques Iac
Terraform Stacks, ce n’est pas juste une nouvelle option dans Terraform. C’est aussi un bon indicateur de maturité IaC. Tant qu’on a un seul projet et deux environnements, quelques dossiers et quelques pipelines suffisent. Mais dès qu’on multiplie les produits, les équipes, les environnements ou les clouds, la collection de petits projets Terraform isolés montre vite ses limites : plus de cohérence, plus de vision globale et beaucoup de dépendance à “ceux qui savent”.
Avec les Stacks, vous changez de niveau de lecture : au lieu de raisonner en dossiers et en fichiers, vous commencez à raisonner en systèmes. On identifie des blocs d’infrastructure (réseau, sécurité, data, applicatif…), on explicite leurs dépendances et on définit une façon standard de les rejouer sur plusieurs environnements. Ça facilite la collaboration entre équipes, limite les variantes locales “faites maison” et met en lumière la dette IaC quand l’existant est trop compliqué à représenter en Stack; En ce sens adopter une Terraform Stacks, c’est autant une évolution technique qu’un pas vers des pratiques IaC plus structurées et plus lisibles.
Conclusion
En pratique, Terraform Stacks marque une étape importante dans l’évolution de Terraform. Au lieu d’additionner des projets et des scripts d’orchestration autour de l’outil, vous pouvez désormais vous appuyer sur une couche dédiée pour décrire l’architecture globale, organiser les composants et piloter plusieurs environnements de manière cohérente.
Pour les équipes cloud et DevOps, c’est l’occasion de revoir la façon dont l’infrastructure as Code est structurée, de réduire la complexité opérationnelle et de rendre l’infrastructure pus lisible, même lorsqu’elle s’étend sur plusieurs cloud et plusieurs équipes.
Comprendre et adopter Terraform Stacks, c’est donc à la fois suivre l’évolution naturelle de l’outil et se donner les moyens de faire évoluer son infrastructure de manière plus cohérente, plus prévisible et plus durable.
