Pulumi vs Terraform : quand changer

À la fin de ce tutoriel, vous saurez comparer Pulumi et Terraform sur le même problème IaC, lire un tableau multi-critères, déployer le même bucket S3 en ca-central-1 avec les deux outils, et décider quand rester sur Terraform, quand adopter Pulumi, ou faire coexister les deux sans big-bang.

Niveau : Intermédiaire · Temps estimé : 50–70 min · Versions cibles : Terraform ≥ 1.9 (ex. 1.16.x) · AWS provider Terraform ~> 5.0 · Pulumi CLI 3.x · Pulumi AWS · AWS CLI v2 · Dernière vérification : 2026-09-11 · Region : ca-central-1

Slug : wow-pulumi-vs-terraform · Série : WOW (6/50) · Mot-clé SEO : Pulumi vs Terraform · Publish : prêt (feu vert Maître)

← : Crossplane AWS · → : Terragrunt scale · Terraform overview

Prérequis

Coût estimé : 0 € si vous créez un bucket vide puis destroy / pulumi destroy immédiatement (quelques cents max si oubli de nettoyage). Region forcée : ca-central-1.

export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1
aws sts get-caller-identity
terraform version
# pulumi version   # après installation

Ce que nous allons construire

Lab Pulumi vs Terraform (WOW 6/50) — ca-central-1
  ├── Clarifier : même cloud, deux modèles de langage
  ├── Tableau comparatif (langage, state, test, CI, courbe)
  ├── Même intent : bucket S3 tagué (Terraform HCL)
  ├── Même intent : bucket S3 tagué (Pulumi TypeScript)
  ├── Guide de décision + coexistence + migration réaliste
  ├── Pièges fréquents (state, drift, polyglot teams)
  └── FAQ + quiz + maillage Terraform / Terragrunt / Crossplane

(Schéma — alt : « Deux chemins IaC vers le même bucket S3 en ca-central-1 : à gauche Terraform HCL + state ; à droite Pulumi TypeScript + stack ».)

La question n’est pas « lequel est objectivement meilleur ? ». C’est quel modèle de langage et d’équipe vous voulez porter pendant 3–5 ans.

Étape 1 — Deux philosophies, un même cloud

Terraform (HashiCorp) décrit l’infrastructure en HCL : déclaratif, lisible par ops et devs, écosystème immense de modules et de providers. Le state (souvent S3 + DynamoDB lock) est le cœur du workflow init → plan → apply. Voir aussi state backend S3.

Pulumi décrit la même infra dans un langage général (TypeScript, Python, Go, C#, Java) : boucles, packages npm/PyPI, tests unitaires familiers, IDE autocomplete natif. Sous le capot : un moteur + un state de stack (Pulumi Cloud ou backend DIY), des providers cloud équivalents, et une CLI pulumi up qui montre un preview avant d’appliquer.

Points communs essentiels :

  • Providers AWS/Azure/GCP/K8s matures des deux côtés
  • Preview avant mutation (plan / preview)
  • Import de ressources existantes, workspaces/stacks multi-env
  • Politique « secrets hors Git »

Différence structurante : HCL dédié vs code applicatif réutilisable. Ce choix change le recrutement, les revues de PR et la façon de tester.

Étape 2 — Tableau : en un coup d’œil

Critère Terraform Pulumi
Langage HCL (+ JSON) TS / Python / Go / C# / Java
Courbe ops Faible si vous connaissez déjà TF Plus haute si l’équipe est 100 % HCL
Courbe dev HCL à apprendre Faible si déjà TypeScript/Python
State Fichier / remote backend Stack (Pulumi Service ou self-host)
Preview terraform plan pulumi preview / up
Modules Registry + modules maison Packages npm/PyPI + Component Resources
Tests terraform test, Terratest, OPA Tests unitaires natifs + policy packs
CI Très documenté (GitHub Actions, GitLab) Idem ; SDK dans le même langage que l’app
Secrets Sensibles dans state ; Vault/SOPS à côté Secrets chiffrés côté stack + mêmes patterns
Licence / offre Terraform (BSL HashiCorp) ; OpenTofu fork Apache-2.0 core ; Pulumi Cloud optionnel
Usage typique Standard de facto IaC multi-cloud Équipes polyglottes, IDP, logique complexe

Lecture 2026 : Terraform reste le socle de marché. Pulumi brille quand la logique IaC devient trop verbeuse en HCL (générateurs, abstractions type SDK, tests dans le même langage que le produit).

Si vous évaluez aussi OpenTofu : OpenTofu vs Terraform 2026. Pour scaler du HCL multi-env sans changer d’outil : Terragrunt.

Étape 3 — Lab Terraform : bucket S3 en ca-central-1

Créez un dossier lab-tf-pulumi-compare/terraform/ :

# versions.tf
terraform {
  required_version = ">= 1.9.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "ca-central-1"
  default_tags {
    tags = {
      Project   = "deh-wow-pulumi-vs-tf"
      ManagedBy = "terraform"
      Env       = "lab"
    }
  }
}

# main.tf
resource "aws_s3_bucket" "lab" {
  bucket_prefix = "deh-wow-tf-"
}

resource "aws_s3_bucket_public_access_block" "lab" {
  bucket = aws_s3_bucket.lab.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

output "bucket_name" {
  value = aws_s3_bucket.lab.bucket
}

cd lab-tf-pulumi-compare/terraform
terraform init
terraform plan -out=tfplan
terraform apply tfplan
aws s3api get-bucket-location --bucket "$(terraform output -raw bucket_name)"
# Nettoyage
terraform destroy -auto-approve

Vous venez de poser la baseline : même region, tags, public access block. C’est l’intent à reproduire avec Pulumi.

Étape 4 — Lab Pulumi : même bucket en TypeScript

Installez la CLI Pulumi (méthode officielle), authentifiez un backend (compte Pulumi gratuit OK pour le lab, ou backend local documenté), puis :

mkdir -p lab-tf-pulumi-compare/pulumi && cd lab-tf-pulumi-compare/pulumi
pulumi new aws-typescript --name deh-wow-pulumi --yes
# Choisir stack lab ; region ca-central-1 dans la config
pulumi config set aws:region ca-central-1

Remplacez le corps de index.ts par une version minimale équivalente :

import * as aws from "@pulumi/aws";

const lab = new aws.s3.BucketV2("deh-wow-pulumi", {
  bucketPrefix: "deh-wow-pu-",
  tags: {
    Project: "deh-wow-pulumi-vs-tf",
    ManagedBy: "pulumi",
    Env: "lab",
  },
});

new aws.s3.BucketPublicAccessBlock("deh-wow-pulumi-pab", {
  bucket: lab.id,
  blockPublicAcls: true,
  blockPublicPolicy: true,
  ignorePublicAcls: true,
  restrictPublicBuckets: true,
});

export const bucketName = lab.bucket;

pulumi preview
pulumi up --yes
pulumi stack output bucketName
pulumi destroy --yes

Critère de succès du lab : les deux outils créent un bucket privé tagué en ca-central-1, exposent le nom en output, et se détruisent proprement. Aucune clé AWS dans les fichiers.

Étape 5 — Guide de décision : rester, migrer, coexister

Situation Recommandation Pourquoi
Équipe déjà forte en Terraform, modules stables Rester Terraform (+ Terragrunt si multi-env) ROI migration faible
Beaucoup de logique conditionnelle / générateurs douloureux en HCL Évaluer Pulumi sur un domaine borné Langage général = moins de HCL « creatif »
Plateforme / IDP où l’IaC est du code produit (tests, packages) Pulumi (ou Crossplane) Alignement SDK + CI app
Besoin d’un standard industrie + embauche large Terraform / OpenTofu Vivier, docs, modules
Migration « tout réécrire » Non — coexistence Importer progressivement, jamais big-bang

Coexistence saine (pattern DEH) :

  1. Nouveau produit / compte sandbox → expérimenter Pulumi
  2. Cœur prod historique → Terraform inchangé
  3. Contrats clairs : tags, naming, region ca-central-1 pour labs, backends séparés
  4. Pas de double gestion de la même ressource sans ownership unique

Migration réaliste : pulumi import / terraform import ressource par ressource ; commencer par un service non critique (S3 lab, IAM roles de lecture) ; mesurer le temps de revue PR avant d’élargir.

Pour une autre voie « infra comme API K8s » : Crossplane AWS. Pour durcir Terraform sans changer d’outil : Tests Terraform 2026 et Policy-as-Code OPA.

Étape 6 — Pièges fréquents

  1. Comparer les logos, pas les workflows — mesurez plan/preview, temps de revue, onboarding junior.
  2. State oublié — deux stacks qui gèrent le même bucket = drift et destructions surprises.
  3. Secrets dans le code — ni HCL ni TypeScript ne justifient des clés en clair ; profils IAM / OIDC CI.
  4. Réécrire 50 000 lignes HCL pour « moderniser » — coût humain > bénéfice outil.
  5. Ignorer OpenTofu / licences — documentez la posture légale de votre org avant un standard unique.
  6. Lab hors region — ici on ancre ca-central-1 pour coller aux labs DEH Canada.

FAQ

Pulumi remplace-t-il Terraform en 2026 ?
Non comme remplacement universel. C’est une alternative mature quand le langage général apporte plus que HCL. Terraform reste le standard le plus répandu.

Peut-on utiliser Pulumi et Terraform dans la même organisation ?
Oui, c’est même le cas le plus fréquent en transition. Séparez les domaines et les states ; un ownership clair par ressource.

Faut-il connaître TypeScript pour Pulumi ?
Non : Python et Go sont très utilisés. TypeScript est populaire pour l’autocomplete et les packages npm.

Et le state Pulumi vs backend S3 Terraform ?
Les deux nécessitent un backend fiable, du lock, et des sauvegardes. Pulumi Cloud simplifie l’ops ; un backend DIY est possible. Terraform + S3 est documenté ici : backend S3.

OpenTofu change-t-il le duel Pulumi vs Terraform ?
OpenTofu adresse surtout la question licence/communauté autour de HCL. Le choix Pulumi reste un choix de paradigme langage, pas seulement de licence.

Mini-quiz

  1. Quel critère pousse le plus vers Pulumi plutôt que Terragrunt ?
    a) Multi-env Terraform · b) Logique IaC mieux exprimée en langage général · c) Besoin d’un provider AWS
    Réponse : b

  2. Dans le lab DEH, quelle region utilise-t-on ?
    a) us-east-1 · b) eu-west-3 · c) ca-central-1
    Réponse : c

  3. Quelle stratégie de migration est la plus saine ?
    a) Big-bang week-end · b) Coexistence + import progressif · c) Dupliquer chaque ressource dans les deux outils
    Réponse : b

Suite du parcours

Besoin d’aller plus loin sur un parcours structuré ? Les e-books et cours DevOps Elastic Hayway prolongent ces labs IaC avec des checklists d’entretien et des architectures multi-compte.

Récap : Terraform = standard HCL et vivier ; Pulumi = IaC en langage général et tests natifs. Labinez le même bucket en ca-central-1, mesurez le friction équipe, puis choisissez rester / coexister / migrer par îlots — jamais un podium absolu.

← Catalogue Tutoriels

Pour aller plus loin — hubs live

Retour parcours Catalogue Tutoriels — hub de la série et leçons sœurs.

© 2023 devopelastichayway.com All rights reserved.