Pulumi exécute désormais votre Terraform tel quel et fait de HCL un langage de première classe

4 août 2026. Janvier 2026, beta privée. Août 2026, disponibilité générale. Pulumi annonce que son moteur exécute désormais le HCL et l’état Terraform comme des citoyens de première classe, et convertit les modules Terraform en composants multilingues. Aucune différence syntaxique avec Terraform et OpenTofu. Pourquoi c’est important : l’argument historique de Pulumi — « écrivez votre infrastructure dans un vrai langage » — s’inverse. Le nouveau message est « apportez votre parc Terraform tel quel ». La guerre de l’IaC ne se joue plus sur la syntaxe, mais sur qui exécute l’état et l’automatisation autour.

Le pivot stratégique

Depuis sa création, Pulumi a construit son identité contre Terraform : là où ce dernier imposait le DSL HCL, Pulumi proposait TypeScript, Python, Go, .NET, Java et YAML. L’argument tenait — boucles, typage, bibliothèques standard — mais il avait un coût : toute migration depuis Terraform exigeait une réécriture, et le vaste écosystème de modules Terraform restait à portée de pont, jamais natif.

La version d’août 2026 referme cet écart par le haut. Le billet de lancement, signé Daniel Perlovsky et intitulé « Bring Your Terraform Estate Into the Agentic Era », ne parle plus de remplacer Terraform : il parle de l’absorber. Le produit est construit autour de trois piliers qu’il faut lire comme un seul mouvement stratégique.

Trois piliers, une seule direction

Premier pilier : l’état Terraform dans Pulumi Cloud. Le Pulumi Cloud devient un backend Terraform complet, compatible Terraform et OpenTofu. Les plan et les apply s’exécutent à distance sur des runners hébergés, avec les journaux renvoyés vers le terminal et persistés dans la console, et un support des approbations manuelles. La configuration et les secrets passent par ESC, qui injecte des identifiants OIDC au moment de l’apply et expose les sorties aux stacks en aval. S’y ajoutent des politiques préventives, qui bloquent une ressource non conforme avant qu’elle atteigne la production, et les revues de code Neo, l’agent d’infrastructure qui juge si une pull request est sûre à merger — compatible Terraform et OpenTofu.

Deuxième pilier : les modules Terraform pour tout le monde. Le registre privé de Pulumi Cloud accepte désormais les modules Terraform nativement et les convertit automatiquement en composants Pulumi typés, exploitables depuis TypeScript, Python, Go, .NET, Java ou YAML. Un module écrit une fois devient consommable par n’importe quelle équipe, dans n’importe quel langage — la frontière de langage disparaît au niveau du module, pas seulement de la configuration.

Troisième pilier : HCL rejoint la famille. Le HCL devient un langage Pulumi entièrement supporté, au même titre que les six autres. Les programmes HCL accèdent à l’écosystème complet — milliers de providers, Pulumi Cloud, ESC, politiques, Neo — et le runtime est compatible OpenTofu avec des tests de compatibilité publiés, sans différence syntaxique.

# Un programme HCL exécuté nativement par le moteur Pulumi
resource "aws_s3_bucket" "assets" {
  bucket = "assets-acme-prod"
  tags = {
    owner = "platform"
  }
}

output "bucket_arn" {
  value = aws_s3_bucket.assets.arn
}

La portée technique est double. D’un côté, Pulumi émule le modèle de données de Terraform sur son propre moteur — un article d’ingénierie signé Ian Wahbe détaille cette cartographie. De l’autre, il teste la compatibilité de son runtime HCL contre OpenTofu. Le résultat est un moteur qui prétend exécuter du Terraform sans en être un fork.

Ce que ça change pour qui utilise déjà Terraform

La proposition est d’abord destinée aux organisations lourdement investies dans Terraform. Au lieu de réécrire, elles pointent Pulumi Cloud vers leur état existant et récupèrent immédiatement trois choses que le Terraform historique leur facture cher : l’exécution distante (fini les apply sur un laptop), les politiques préventives sur le plan, et les revues de code automatisées par Neo. Le state reste le leur, mais l’infrastructure d’exécution autour change de main.

La bascule n’est pas neutre pour autant. L’état est la pièce la plus sensible d’une chaîne IaC : il contient les identifiants implicites, la topologie exacte du parc, parfois des secrets mal filtrés. Le confier à Pulumi Cloud est un choix de plateforme, avec les mêmes questions de souveraineté, de disponibilité et de coût que tout passage chez un éditeur. C’est précisément le calcul que l’annonce cherche à faire pencher : en échange d’un backend hébergé, l’équipe délègue l’exécution, les politiques et la revue IA.

Ce que ça change pour qui ne l’utilise pas encore

Pour un projet greenfield, l’annonce efface la principale objection à Pulumi : « je préfère le HCL ». Cette préférence n’oblige plus à rester chez Terraform. Une équipe peut écrire du HCL compatible OpenTofu, tourner sur le moteur Pulumi, consommer les modules Terraform de la communauté, et basculer vers TypeScript ou Go quand le besoin de boucles et de typage se fera sentir — sans changer de plateforme d’état ni de moteur.

C’est aussi une réponse à la question posée depuis le fork : après la licence BSL de Terraform et le rachat de HashiCorp par IBM, où va la communauté ? OpenTofu a offert la gouvernance ouverte ; Pulumi offre désormais un moteur alternatif qui accepte le HCL et l’état Terraform sans en dépendre. Les deux trajectoires ne s’excluent plus : un backend Pulumi peut exécuter du OpenTofu.

Ce que l’annonce ne règle pas

Il faut garder les pieds sur terre sur deux points. Premièrement, exécuter du Terraform sur le moteur Pulumi ne change rien à la question de la licence : les configurations HCL existantes restent ce qu’elles sont, et le sujet BSL ne disparaît pas parce qu’un moteur tiers les exécute. La garantie de gouvernance ouverte reste l’apanage d’OpenTofu, pas d’un backend propriétaire hébergé.

Deuxièmement, le runtime HCL de Pulumi est jeune. Sa compatibilité est annoncée et testée contre OpenTofu, mais l’écart entre « compatible » et « éprouvé en production sur des milliers de stacks » se comble en mois, pas en communiqués. Une équipe qui bascule un parc sensible le découvrira sur des cas limites — un provider exotique, un bloc dynamique tordu, une dépendance d’état héritée. La prudence veut qu’on migre un périmètre non critique d’abord, qu’on mesure, puis qu’on étende.

Verdict

Si vous exploitez déjà Terraform et que la réécriture vous bloquait, testez la bascule de l’état vers Pulumi Cloud sur un parc non critique : vous récupérez l’exécution distante, les politiques sur le plan et les revues Neo sans toucher à votre code. Mesurez avant d’étendre — le coût et la souveraineté d’un backend hébergé se calculent, ils ne se supposent pas.

Si vous démarrez un projet et que votre équipe préfère le HCL, Pulumi est désormais une option complète : runtime HCL compatible OpenTofu, modules Terraform consommables, et un chemin de croissance vers les langages généralistes si le besoin apparaît. La préférence de syntaxe n’est plus un critère discriminant.

Si vous êtes une équipe Pulumi existante, le gain est l’écosystème : le registre privé importe les modules Terraform et les convertit en composants typés, ce qui comble l’écart de couverture sur les providers de niche sans abandonner vos langages.

Références

• Full support for Terraform state, modules, and HCL — Pulumi Releases, août 2026
• Bring Your Terraform Estate Into the Agentic Era — Pulumi Blog, Daniel Perlovsky, 4 août 2026
• Emulating Terraform on Pulumi’s Engine — Pulumi Blog, Ian Wahbe, 4 août 2026
• Compatibility Testing Pulumi HCL — Pulumi Blog, Ian Wahbe, 14 août 2026
• Pulumi Adds Native Support for Terraform and HCL — InfoQ, janvier 2026