Le choix d’un outil d’infrastructure as code se discute souvent comme une préférence de syntaxe (HCL contre un vrai langage de programmation), ce qui passe à côté des deux critères qui pèsent réellement sur le long terme : la licence sous laquelle l’outil est distribué, et le coût réel d’en changer une fois que des centaines de fichiers de configuration en dépendent.

Terraform et le tournant de la licence

Terraform est resté open source (licence Mozilla Public License) pendant près d’une décennie, l’outil de référence de facto pour l’IaC déclaratif. En 2023, HashiCorp est passé à la Business Source License (BSL), qui restreint l’usage commercial concurrent de HashiCorp lui-même, tout en restant utilisable sans restriction pour la très grande majorité des cas d’usage internes. Le changement n’empêche pas d’utiliser Terraform aujourd’hui ; il change la trajectoire de gouvernance du projet, désormais entièrement contrôlée par une entreprise, pas une fondation neutre.

OpenTofu : le fork sous gouvernance neutre

En réponse directe à ce changement de licence, un groupe de contributeurs et d’entreprises (Gitpod, Spacelift, Harness, entre autres) a forké la dernière version MPL de Terraform pour créer OpenTofu, désormais hébergé sous la Linux Foundation. La compatibilité est quasi totale au niveau du langage HCL et des providers existants :

# La migration technique tient en une commande pour la majorité des projets
tofu init   # remplace terraform init, lit les mêmes fichiers .tf

La vraie question n’est pas technique mais organisationnelle : une gouvernance neutre (Linux Foundation) élimine le risque qu’un futur changement de licence unilatéral impose à nouveau une migration forcée, au prix d’un écosystème de contributeurs encore plus jeune que celui de Terraform et de fonctionnalités enterprise (HCP Terraform, Sentinel) qui restent propriétaires HashiCorp.

Pulumi : sortir du DSL pour un vrai langage

Pulumi prend un chemin différent : au lieu d’un langage de configuration dédié (HCL), l’infrastructure se décrit dans un langage de programmation généraliste (TypeScript, Python, Go, Java) déjà connu de l’équipe.

// Pulumi : les boucles, conditions et fonctions du langage
// hôte sont directement utilisables, pas besoin d'un DSL séparé
const buckets = environments.map(env =>
  new aws.s3.Bucket(`data-${env}`, { acl: "private" })
);

Le bénéfice réel : les tests unitaires, la composition de fonctions et les abstractions du langage hôte s’appliquent directement à l’infrastructure, sans les limitations d’un DSL déclaratif pur. Le coût réel, symétrique : l’expressivité d’un vrai langage permet aussi d’écrire de l’infrastructure impérative et peu prévisible si l’équipe n’impose pas sa propre discipline, ce que la contrainte du HCL de Terraform impose par construction.

Le vrai coût d’un changement d’outil

Migrer d’outil ne se limite jamais à la conversion syntaxique. Le state (l’inventaire que l’outil tient de ce qu’il gère réellement, couvert en détail dans l’article sur le state Terraform distant et le verrouillage) doit être importé ou recréé dans le nouvel outil, provider par provider, ressource par ressource. Sur une infrastructure de plusieurs centaines de ressources, cette migration est un projet à part entière, pas une commande. C’est la raison structurelle pour laquelle le choix initial pèse plus lourd que la comparaison de fonctionnalités du jour : le coût de sortie dépasse rapidement le coût d’apprentissage initial.

Un critère de décision, pas une préférence

Trois questions, dans l’ordre, tranchent la plupart des cas : l’équipe a-t-elle déjà une expertise forte dans un langage de programmation que Pulumi exploiterait directement, plutôt que d’apprendre HCL depuis zéro ? La gouvernance du projet (BSL propriétaire ou fondation neutre) est-elle un critère contractuel ou réglementaire dans votre secteur ? Et l’écosystème de providers et de modules communautaires déjà mature de Terraform (largement compatible avec OpenTofu) compte-t-il plus que la nouveauté d’un outil pour votre cas d’usage ? Un changement de préférence esthétique ne justifie presque jamais de rouvrir cette décision une fois l’outil en production.

À retenir

Le choix d’un outil IaC se joue sur la licence et le coût de sortie, pas sur des préférences de syntaxe qui s’oublient après deux semaines d’usage. OpenTofu offre une continuité quasi transparente avec Terraform sous une gouvernance neutre ; Pulumi échange un DSL contraint contre un vrai langage de programmation, au prix de la discipline que ce DSL imposait par défaut. Le state migré est le vrai coût de tout changement ultérieur : c’est le critère qui doit peser le plus lourd dès le premier choix, dans le cadre d’une industrialisation CI/CD qui tient sur la durée.