OpenTofu vs Terraform : l’acquisition IBM

IBM a acquis HashiCorp pour 6,4 milliards de dollars américains. Terraform est désormais soumis à la Business Source License (BSL). Et OpenTofu, le fork open source, enregistre une croissance annuelle de 300 %, avec désormais 9,8 millions de téléchargements. Pour les architectes cloud et les équipes DevOps des entreprises DACH, la question n’est plus « si », mais « quand » elles devront réévaluer leur stratégie d’Infrastructure-as-Code (IaC). Ce bilan pratique explique concrètement ce que cette acquisition change, à quoi ressemble une migration et dans quels cas elle s’avère pertinente.

L’essentiel

• IBM a finalisé l’acquisition de HashiCorp pour 6,4 milliards de dollars américains le 27 février 2025 (The Register).
• 38 % des utilisateurs de Terraform évaluent déjà OpenTofu ou ont entamé une migration vers celui-ci (enquête Spacelift, T4 2024).
• OpenTofu : 9,8 millions de téléchargements, croissance annuelle de 300 %, membre de la CNCF (Cloud Native Computing Foundation) depuis avril 2025.
• Fidelity a migré plus de 50 000 fichiers d’état contenant plus de 4 millions de ressources de Terraform vers OpenTofu.
• La BSL ne s’applique pas à l’usage interne, mais concerne les services gérés (Managed Services), la revente (Reselling) et l’intégration de fonctionnalités Terraform dans des produits tiers.

Ce que l’acquisition par IBM implique pour les utilisateurs de Terraform

Le 27 février 2025, IBM a finalisé l’acquisition de HashiCorp pour 6,4 milliards de dollars américains. Terraform, Vault, Consul et Nomad appartiennent désormais à un groupe industriel qui, traditionnellement, mise sur des contrats à long terme et sur le verrouillage technologique (platform lock-in).

À court terme, peu de choses changent pour un usage strictement interne. Terraform reste pleinement fonctionnel, et l’édition communautaire (Community Edition) demeure disponible. Toutefois, la Business Source License (BSL), introduite par HashiCorp en août 2023, a profondément modifié les règles du jeu : toute entreprise intégrant des fonctionnalités de Terraform dans ses propres produits, proposant Terraform sous forme de service géré ou le revendant doit désormais souscrire une licence commerciale. Sous la direction d’IBM, cette orientation risque de se renforcer plutôt que de s’assouplir.

La conséquence pour les responsables informatiques : ceux qui utilisent aujourd’hui Terraform doivent connaître précisément leur exposition aux risques liés à la licence. Quelles équipes utilisent Terraform, et comment ? Existe-t-il des plateformes internes qui fournissent des exécutions Terraform en tant que service ? Des modules Terraform sont-ils distribués à des clients ? Chacune de ces questions peut devenir pertinente au regard des dispositions de la BSL.

OpenTofu : du fork à un concurrent sérieux

OpenTofu a vu le jour en septembre 2023 comme réponse directe à la modification de la licence BSL. Ce qui avait commencé comme une protestation communautaire s’est transformé en un projet viable. Les chiffres parlent d’eux-mêmes : 9,8 millions de téléchargements, une croissance annuelle de 300 %, et depuis avril 2025, un projet officiel de la CNCF (Cloud Native Computing Foundation) au niveau « Sandbox ».

Son socle technique est identique : OpenTofu utilise la même syntaxe HCL (HashiCorp Configuration Language), la même structure de fichiers d’état (state files) et est compatible avec la plupart des providers Terraform. Dans de nombreux cas, le passage au niveau du code se résume à une simple opération de recherche et remplacement de « terraform » par « tofu » dans les pipelines CI/CD.

Mais OpenTofu va au-delà du simple fork. Il intègre des fonctionnalités propres, telles que le chiffrement côté client des fichiers d’état (Client-Side State Encryption – permettant de chiffrer le fichier d’état sans recourir à des outils externes), un registre de providers indépendant de tout fournisseur spécifique (provider-agnostic registry) et une structure de modules améliorée, ce qui distingue progressivement le projet de son origine.

Qui a déjà migré – et pourquoi

La liste des premiers adopteurs ressemble à un « Who’s Who » des secteurs fortement réglementés. Fidelity Investments a migré plus de 50 000 fichiers d’état couvrant plus de 2 000 applications et 4 millions de ressources gérées. La raison principale ? Des préoccupations réglementaires liées à la BSL et une dépendance excessive vis-à-vis d’un unique fournisseur pour une infrastructure critique.

Chez Spacelift, l’une des plus grandes plateformes de gestion d’IaC, 50 % de tous les déploiements s’exécutent désormais sur OpenTofu plutôt que sur Terraform. La tendance est claire : les entreprises soumises à des exigences strictes en matière de conformité (compliance), ainsi que celles qui développent leurs propres services de plateforme reposant sur des outils d’IaC, sont les premières à migrer.

Pour les entreprises DACH, c’est particulièrement l’aspect souveraineté qui revêt une importance cruciale. Un outil open source sous licence MPL 2.0 offre un contrôle accru par rapport à un produit soumis à la licence BSL, détenu par un conglomérat américain. Dans les secteurs réglementés tels que les services financiers ou la santé, cela peut faire la différence.

”

// Propos

L’engagement d’OpenTofu en faveur des principes open source reflète une vision partagée : fournir des outils accessibles et fiables capables de renforcer la communauté technologique.

Migration : ce qu’elle coûte réellement

La bonne nouvelle : migrer de Terraform vers OpenTofu est techniquement assez simple. Les fichiers d’état sont compatibles. La syntaxe HCL est identique. La plupart des providers fonctionnent sur les deux plateformes.

Les difficultés résident dans les détails :

Registre des providers : OpenTofu utilise son propre registre, qui ne contient pas l’intégralité des providers Terraform. Avant la migration, il convient de comparer la liste des providers utilisés avec le registre OpenTofu. Les providers absents doivent être configurés manuellement ou référencés depuis le registre HashiCorp.

Pipelines CI/CD : Terraform Cloud et Terraform Enterprise ne sont pas compatibles avec OpenTofu. Les utilisateurs de ces services doivent choisir une alternative : Spacelift, env0, Scalr ou une plateforme interne. C’est souvent la partie la plus complexe de la migration.

Formation des équipes : Minimale. La syntaxe étant identique, les différences d’outillage sont légères. Une demi-journée de formation suffit généralement à la plupart des équipes.

Charge globale : Pour une équipe gérant entre 20 et 50 fichiers d’état : 2 à 4 semaines. Pour des configurations d’entreprise à grande échelle comme celle de Fidelity (plus de 50 000 fichiers d’état) : 3 à 6 mois, avec une équipe dédiée à la migration.

Terraform, OpenTofu ou Pulumi ? Une matrice décisionnelle

Le choix dépend de trois facteurs : le risque lié à la licence, les besoins en matière d’écosystème et les compétences de l’équipe.

Terraform reste pertinent si : Votre usage interne relève bien des droits d’utilisation définis par la BSL, votre équipe est profondément intégrée à l’écosystème HashiCorp (Vault, Consul), et vous utilisez Terraform Cloud ou Terraform Enterprise. IBM ne laissera pas mourir Terraform – il est trop précieux.

OpenTofu est le bon choix si : Vous proposez des services gérés basés sur l’IaC, vous êtes soumis à des exigences réglementaires exigeant une transparence open source, vous êtes inquiets des clauses de la BSL ou vous souhaitez réduire au maximum le verrouillage technologique (vendor lock-in).

Pulumi mérite d’être étudié si : Votre équipe préfère coder en TypeScript, Python ou Go plutôt qu’en HCL, vous privilégiez l’approche « Infrastructure-as-Software » plutôt que « Infrastructure-as-Code », et vous démarrez de zéro. La migration depuis Terraform ou OpenTofu vers Pulumi est, en revanche, très contraignante.

Source : IDE.com / Fidelity, 2025

Ce que les responsables informatiques doivent faire dès maintenant

1. Réaliser un audit des licences. Comment vos équipes utilisent-elles Terraform ? Usage interne uniquement, service de plateforme, projets clients ? Comprendre précisément les limites imposées par la BSL.

2. Établir un inventaire des fichiers d’état. Combien de fichiers d’état ? Combien de ressources ? Quels providers sont utilisés ? C’est la base indispensable pour estimer la charge de travail.

3. Tester OpenTofu dans une sandbox. Migrer une charge de travail non critique et laisser l’équipe travailler avec pendant deux semaines. Vérifier soi-même la compatibilité.

4. Évaluer une alternative CI/CD. Si vous utilisez Terraform Cloud : tester Spacelift, env0 ou Scalr comme alternatives. C’est souvent le véritable frein à la migration.

5. Documenter la décision. Que vous restiez sur Terraform ou migriez vers OpenTofu, la décision doit être justifiée et traçable. Les autorités de régulation demandent des explications.

Fazit

L’acquisition d’HashiCorp par IBM a divisé le paysage de l’Infrastructure-as-Code. OpenTofu n’est plus un simple fork de protestation, mais une alternative crédible, soutenue par la CNCF, dotée de références en entreprise et d’un écosystème en pleine expansion. Pour les entreprises DACH soumises à des exigences réglementaires ou exposées aux risques liés à la BSL, une évaluation s’impose dès aujourd’hui. La migration est techniquement maîtrisable ; la charge réelle réside dans la refonte des pipelines CI/CD. Celui qui connaît aujourd’hui son exposition aux risques liés à la licence et a testé OpenTofu dans une sandbox est prêt – quelle que soit la direction qu’IBM donnera à Terraform à l’avenir.

Questions fréquentes

OpenTofu est-il vraiment compatible avec Terraform ?

Oui, au niveau des fichiers d’état et de la syntaxe HCL. La plupart des providers Terraform fonctionnent sans modification. Des incompatibilités existent toutefois avec les fonctionnalités spécifiques à Terraform Cloud/Enterprise, ainsi qu’avec certaines versions récentes de providers disponibles uniquement dans le registre HashiCorp.

Dois-je craindre la BSL si j’utilise Terraform uniquement en interne ?

Non : la BSL ne pose aucun problème pour un usage strictement interne. Elle devient critique si vous proposez Terraform sous forme de service, si vous intégrez ses fonctionnalités dans vos propres produits ou si vous le revendez à des clients. Les frontières ne sont pas toujours nettes, ce qui rend un audit des licences particulièrement utile.

Combien de temps prend une migration vers OpenTofu ?

Pour de petites équipes gérant entre 20 et 50 fichiers d’état : 2 à 4 semaines. Pour des configurations d’entreprise : 3 à 6 mois. Le principal effort ne réside pas dans la modification du code (souvent une simple opération de recherche et remplacement), mais dans la refonte des pipelines CI/CD et la vérification de la compatibilité avec le registre des providers.

Que deviennent Vault et Consul sous la gouvernance d’IBM ?

Vault et Consul sont également soumis à la BSL. IBM continuera de développer ces produits, mais sa politique tarifaire devrait évoluer vers des modèles de licence orientés entreprise. Pour Vault, un fork open source existe sous le nom d’OpenBao ; pour Consul, la situation est moins claire.

Pulumi constitue-t-il une alternative valable aux deux autres ?

Pulumi utilise des langages de programmation réels (et non une DSL comme HCL). C’est un avantage pour les équipes dotées d’une forte culture de développement, mais un inconvénient pour les équipes Ops sans compétences en programmation. Migrer depuis Terraform ou OpenTofu vers Pulumi est très contraignant, car l’ensemble des définitions d’infrastructure doit être réécrit. Il s’agit donc surtout d’une option pertinente pour les nouveaux projets (Greenfield).

Plus d’articles du réseau média MBF Media

• NIS2 et chaînes logistiques SaaS – SecurityToday
• Sortir du nuage américain : un guide pour les PME – MyBusinessFuture
• Les écosystèmes de plateforme au conseil d’administration – Digital Chiefs

Source de l’image : Pexels / Lukas (px:546819)