Les améliorations d’interopérabilité apportées par Pulumi en 2026 permettent aux organisations de conserver leurs flux de travail Terraform, de partager des modules d’infrastructure entre langages et d’exécuter du HCL avec le moteur Pulumi. Ces options lèvent certains obstacles à la migration, mais chacune a des conséquences différentes pour l’état, l’exécution et la propriété des ressources.
Une équipe d’infrastructure peut avoir investi des années de travail dans des modules Terraform, des pipelines de déploiement et un état (state) de production. Passer à une autre plateforme d’infrastructure as code peut signifier réécrire la configuration, modifier les processus de livraison et valider des ressources qui fonctionnent déjà.
La version publiée par Pulumi en août 2026 élargit les façons dont les équipes peuvent utiliser ensemble Terraform, OpenTofu (une implémentation open source compatible avec Terraform) et Pulumi, sans tout remplacer d’un coup. Cette version réunit trois capacités : l’état et l’exécution Terraform via Pulumi Cloud, l’interopérabilité des modules Terraform entre langages, et HCL (HashiCorp Configuration Language, le langage des fichiers de configuration Terraform) comme langage de programmation Pulumi. Ce sont des approches différentes. Comprendre cette distinction est plus utile que de traiter cette version comme une fonctionnalité de migration unique.
Trois capacités, trois changements différents
| Capacité | Ce qui change | Ce qui reste important |
|---|---|---|
| Backend Terraform et exécution à distance | L’état Terraform et, en option, l’exécution passent dans Pulumi Cloud | Les flux de travail Terraform ou OpenTofu demeurent, l’exécution à distance étant soumise au modèle d’exécution de Pulumi Cloud |
| Interopérabilité des modules Terraform | Les modules existants peuvent être publiés, consommés et réutilisés dans les langages pris en charge | L’exécution des modules, les dépendances et la compatibilité doivent toujours être validées |
| Runtime HCL de Pulumi | La configuration HCL s’exécute sur le moteur Pulumi | L’état Pulumi et la propriété des ressources remplacent le modèle d’exécution Terraform |
La différence tient d’abord à deux notions. La configuration décrit l’infrastructure qu’une équipe souhaite obtenir. L’état enregistre les ressources réelles associées à un flux de gestion de l’infrastructure.
Déplacer le stockage de l’état ne change pas nécessairement le moteur qui applique la configuration. En revanche, exécuter le même HCL avec un autre moteur change davantage que l’emplacement d’un fichier d’état.
Source : Pulumi, Full Support for Terraform State, Modules and HCL, août 2026.
1. Conserver Terraform et utiliser Pulumi Cloud pour l’état
Une équipe peut continuer à écrire du HCL et à lancer les commandes Terraform ou OpenTofu habituelles tout en stockant l’état dans Pulumi Cloud. Le backend offre une gestion centralisée de l’état, le verrouillage, des contrôles d’accès, un historique des mises à jour et une visibilité sur les ressources gérées. Ce dispositif ne transforme pas des ressources gérées par Terraform en ressources gérées par le moteur Pulumi. Le flux de travail existant peut rester en grande partie intact.
Pulumi Cloud propose aussi l’exécution à distance (remote execution), mais il faut la distinguer d’une utilisation comme simple backend d’état. Avec l’exécution locale, la CLI Terraform ou OpenTofu exécute les opérations dans l’environnement propre à l’équipe, tandis que Pulumi Cloud stocke l’état. Avec l’exécution à distance, la CLI envoie la configuration à Pulumi Cloud, où une infrastructure gérée effectue le plan ou l’apply.
Un détail de mise en œuvre important : l’exécuteur distant (runner) de Pulumi Cloud utilise OpenTofu comme moteur d’exécution, même lorsque l’opération a été lancée depuis la CLI Terraform. La version d’OpenTofu gérée est actuellement contrôlée par Pulumi Cloud et non choisie par le client.
L’exécution à distance présente aussi des limites précises, notamment l’absence de prise en charge des options -var et l’impossibilité de configurer des images d’exécuteur personnalisées. Ces différences comptent pour les équipes dont les pipelines existants dépendent de versions particulières de Terraform, d’arguments de ligne de commande ou d’une personnalisation de l’exécuteur.
En local
Une équipe peut continuer à écrire du HCL et à lancer les commandes Terraform ou OpenTofu habituelles tout en stockant l’état dans Pulumi Cloud. Avec l’exécution locale, la CLI Terraform ou OpenTofu exécute les opérations dans l’environnement propre à l’équipe, tandis que Pulumi Cloud stocke l’état.
À distance
Avec l’exécution à distance, la CLI envoie la configuration à Pulumi Cloud, où une infrastructure gérée effectue le plan ou l’apply. Un détail de mise en œuvre important : l’exécuteur distant de Pulumi Cloud utilise OpenTofu comme moteur d’exécution, même lorsque l’opération a été lancée depuis la CLI Terraform.
Limites à voir
La version d’OpenTofu gérée est actuellement contrôlée par Pulumi Cloud et non choisie par le client. L’exécution à distance présente aussi des limites précises, notamment l’absence de prise en charge des options -var et l’impossibilité de configurer des images d’exécuteur personnalisées.
Sources : Pulumi, Store Terraform State in Pulumi Cloud et Remote Execution for Terraform and OpenTofu.
2. Partager des modules Terraform entre langages
Les modules Terraform représentent souvent des standards d’infrastructure établis. Une équipe plateforme peut maintenir des modules pour les réseaux, les bases de données, le stockage ou les contrôles d’accès. Réécrire ces composants uniquement parce qu’une autre équipe souhaite utiliser Python ou TypeScript crée du travail et introduit des écarts potentiels. Les fonctions d’interopérabilité de Pulumi offrent deux approches liées.
Registre de modules et composants générés. Les équipes peuvent publier des modules Terraform dans le registre privé de Pulumi Cloud. La plateforme peut les mettre à disposition des utilisateurs de Terraform et d’OpenTofu et générer des composants typés pour les langages pris en charge par Pulumi.
Intégration Any HCL Module. Les programmes Pulumi peuvent utiliser des modules Terraform existants grâce à une intégration qui exécute le module avec OpenTofu, associe les entrées fournies aux variables Terraform et expose les résultats sous forme de sorties Pulumi.
Le mécanisme Any HCL Module gère les ressources de ses modules via le backend d’état de Pulumi. Ce n’est pas la même chose que d’exécuter de manière indépendante une configuration racine Terraform existante avec son état d’origine. Les SDK générés peuvent fournir des entrées et des sorties typées, tandis que le chargement dynamique des modules offre plus de souplesse au prix d’une partie de la sûreté de typage.
L’avantage pratique est de réutiliser des définitions d’infrastructure éprouvées entre des équipes aux préférences de programmation différentes. La responsabilité qui demeure est le test de compatibilité. Les modules qui ont des dépendances complexes envers des fournisseurs (providers) ou des hypothèses d’exécution doivent toujours être validés dans leur environnement cible.
Registre privé
Les équipes peuvent publier des modules Terraform dans le registre privé de Pulumi Cloud. La plateforme peut les mettre à disposition des utilisateurs de Terraform et d’OpenTofu et générer des composants typés pour les langages pris en charge par Pulumi.
Any HCL Module
Les programmes Pulumi peuvent utiliser des modules Terraform existants grâce à une intégration qui exécute le module avec OpenTofu, associe les entrées fournies aux variables Terraform et expose les résultats sous forme de sorties Pulumi. Le mécanisme Any HCL Module gère les ressources de ses modules via le backend d’état de Pulumi.
Reste à tester
La responsabilité qui demeure est le test de compatibilité. Les modules qui ont des dépendances complexes envers des fournisseurs ou des hypothèses d’exécution doivent toujours être validés dans leur environnement cible.
Source : Pulumi, Use Terraform Modules in Pulumi.
3. Exécuter du HCL avec le moteur Pulumi
La troisième capacité change le modèle d’exécution de l’infrastructure. Pulumi prend en charge HCL comme langage pour son moteur. Les équipes peuvent conserver la syntaxe de configuration .tf qu’elles connaissent tout en utilisant le cycle de vie des ressources et la gestion de l’état de Pulumi. Cela peut réduire l’effort nécessaire pour évaluer Pulumi sans réécrire toute une configuration dans un autre langage de programmation.
Cependant, l’état Terraform ne devient pas automatiquement un état Pulumi. Les ressources existantes doivent être placées sous la gestion de Pulumi au moyen d’un processus d’importation explicite.
Pulumi documente le mécanisme suivant pour les migrations HCL :
pulumi import --from hcl <statefile>
L’importation lit un fichier d’état Terraform existant et associe les ressources à la stack Pulumi. Il s’agit d’une opération de migration, et non d’une instruction pour faire tourner deux moteurs indépendants sur les mêmes ressources d’infrastructure.
Avant d’utiliser cette approche, les équipes doivent valider les correspondances de fournisseurs, les identités des ressources, les dépendances et l’aperçu (preview) obtenu. Elles doivent éviter que les mêmes ressources soient gérées simultanément par des systèmes d’état indépendants.
Il existe aussi des différences de compatibilité. Par exemple, le bloc Terraform backend et certains autres paramètres de configuration sont acceptés mais ignorés avec des avertissements, car Pulumi gère l’état de manière indépendante. Un bloc Terraform cloud n’est pas accepté. La prise en charge des connexions des provisioners est limitée, sans aucune prise en charge de WinRM.
HCL sur le moteur Pulumi
Pulumi prend en charge HCL comme langage pour son moteur. Les équipes peuvent conserver la syntaxe de configuration .tf qu’elles connaissent tout en utilisant le cycle de vie des ressources et la gestion de l’état de Pulumi.
Import requis
Cependant, l’état Terraform ne devient pas automatiquement un état Pulumi. Les ressources existantes doivent être placées sous la gestion de Pulumi au moyen d’un processus d’importation explicite. L’importation lit un fichier d’état Terraform existant et associe les ressources à la stack Pulumi.
Vérifier avant bascule
Avant d’utiliser cette approche, les équipes doivent valider les correspondances de fournisseurs, les identités des ressources, les dépendances et l’aperçu obtenu. Elles doivent éviter que les mêmes ressources soient gérées simultanément par des systèmes d’état indépendants.
L’équipe d’ingénierie de Pulumi a indiqué dans Emulating Terraform on Pulumi’s Engine que son interpréteur HCL avait exécuté 56 des 58 modules Terraform AWS les plus utilisés, soit 96 %, et que les échecs étaient dus aux ressources éphémères. Il s’agit d’un résultat communiqué par l’éditeur pour un ensemble particulier de modules AWS, et non de la preuve que 96 % des configurations Terraform de toute organisation migreront avec succès.
Sources : Pulumi, HCL Documentation, HCL Language Reference et Emulating Terraform on Pulumi’s Engine.
Que doivent choisir les équipes ?
Revenons à l’équipe d’infrastructure du début, et supposons qu’elle exploite un environnement Terraform établi mais souhaite introduire Pulumi pour de nouvelles infrastructures applicatives. Il s’agit d’une équipe hypothétique, utilisée ici pour comparer les options. Rien n’oblige à tout migrer d’un coup.
| Besoin existant | Approche à évaluer |
|---|---|
| Une meilleure gestion centralisée de l’état | Backend Terraform de Pulumi Cloud |
| Une exécution Terraform ou OpenTofu gérée | Exécution à distance de Pulumi Cloud, après validation de son exécuteur basé sur OpenTofu |
| Des modules Terraform partagés entre écosystèmes de langages | Registre de modules et composants générés de Pulumi Cloud |
| Des modules Terraform dans des programmes Pulumi | Intégration Any HCL Module |
| Une configuration HCL gérée par le moteur Pulumi | Pulumi HCL avec importation explicite de l’état et des ressources |
| Une infrastructure existante stable, sans besoin impérieux de migration | Conserver le flux de travail Terraform actuel |
Le bon choix dépend du problème opérationnel. Un nouveau backend d’état peut aider une équipe qui a besoin de contrôles centralisés. Des modules partagés peuvent aider les organisations qui prennent en charge plusieurs langages de programmation. Un autre moteur d’exécution peut avoir du sens lorsqu’une équipe souhaite le modèle de programmation plus large de Pulumi.
Aucun de ces avantages ne justifie automatiquement la migration d’un parc d’infrastructure établi et fonctionnel.
Les limites opérationnelles qui comptent toujours
Trois domaines méritent une attention particulière avant une adoption en production.
Propriété des ressources. Chaque ressource doit avoir un seul chemin de gestion clairement défini. Les équipes doivent savoir quel moteur applique les modifications et quel système d’état enregistre la ressource.
Politiques et détection de dérive. Pulumi Cloud peut appliquer des politiques d’audit aux stacks gérées par Terraform, ce que sa documentation indique pour les éditions Essentials, Pro et Enterprise. Les politiques préventives, qui bloquent un apply non conforme, sont disponibles via l’exécution à distance et documentées pour les éditions Pro et Enterprise. En revanche, la détection automatique de dérive (drift detection) n’est pas disponible actuellement pour les stacks gérées par Terraform. Les organisations peuvent avoir besoin de plans programmés ou d’un autre processus de surveillance existant.
Coûts et contraintes d’exécution. Les ressources Terraform stockées dans Pulumi Cloud sont comptées dans les ressources sous gestion. L’exécution à distance consomme des minutes de workflow facturables. Les équipes doivent aussi tenir compte des versions des fournisseurs, des limites de l’exécuteur et des exigences d’intégration aux déploiements existants. Les mises à niveau de fournisseurs sont une source fréquente de ces contraintes, comme l’explique The Terraform AWS Provider Keeps Growing: Is Your Upgrade Process Ready?.
Ce ne sont pas des raisons de rejeter l’interopérabilité. Elles font partie de l’évaluation visant à déterminer si une intégration donnée améliore le modèle opérationnel actuel de l’organisation.
Sources : Pulumi, Remote Execution for Terraform and OpenTofu et Store Terraform State in Pulumi Cloud.
Une démarche d’adoption pragmatique
Les équipes peuvent évaluer l’interopérabilité sans lancer de migration de grande ampleur. Si l’objectif est la gestion de l’état, testez le backend avec une stack Terraform représentative hors production. Vérifiez que l’initialisation, la migration de l’état, le verrouillage et la planification fonctionnent comme prévu.
Si l’objectif est la réutilisation de modules, choisissez un module aux dépendances significatives et vérifiez son comportement avec l’intégration retenue. Si l’objectif est l’adoption du moteur Pulumi, testez le runtime HCL avec une importation de ressources contrôlée et vérifiez que l’aperçu obtenu ne contient aucune modification involontaire.
Ces tests répondent à des questions différentes. Une migration de backend réussie ne prouve pas la compatibilité du runtime HCL. Un module réutilisable ne prouve pas que l’ensemble du parc Terraform peut migrer sans refonte. L’objectif doit être une amélioration vérifiée du flux de travail actuel, et non la simple adoption d’un outil de plus.
Ce que cette version change vraiment
Les améliorations d’interopérabilité publiées par Pulumi en août 2026 donnent aux équipes d’infrastructure davantage de moyens de préserver leurs investissements Terraform existants tout en adoptant certaines capacités de Pulumi. Elles ne rendent pas Terraform, OpenTofu et Pulumi identiques.
La distinction importante porte sur l’endroit où l’état est stocké, la manière dont les modules sont réutilisés et le moteur qui gère les ressources. Les organisations qui comprennent ces limites peuvent adopter l’interopérabilité progressivement, tout en gardant une propriété plus claire et des modifications d’infrastructure plus prévisibles.
Références et lectures complémentaires
- Pulumi, Full Support for Terraform State, Modules and HCL. Août 2026.
- Pulumi, Now Generally Available: Store Terraform State in Pulumi Cloud. 5 mars 2026.
- Pulumi, Store Terraform State in Pulumi Cloud. Documentation technique officielle.
- Pulumi, Remote Execution for Terraform and OpenTofu. Comportement d’exécution et limites officiels.
- Pulumi, Use Terraform Modules in Pulumi. Interopérabilité des modules.
- Pulumi, HCL Language Documentation. Compatibilité du moteur et de l’état.
- Pulumi, HCL Language Reference. Fonctionnalités non prises en charge et exigences de migration.
- Pulumi, Emulating Terraform on Pulumi’s Engine. 4 août 2026.
Vérification des sources : 5 novembre 2026. Les capacités et les affirmations de compatibilité reposent sur la documentation publiée par Pulumi et sur ses rapports d’ingénierie. TechiesJournal n’a pas testé de manière indépendante ces migrations en production. Le chiffre de 96 % a été vérifié par rapport à la note de bas de page du billet de Pulumi lui-même.