OpenTofu atteint sa maturité 2.0 et devient l’alternative raisonnable à Terraform

En août 2023, HashiCorp bascule la licence de Terraform de la MPL 2.0 (open source) vers la Business Source License 1.1 (source disponible). En février 2025, IBM finalise le rachat de HashiCorp pour 6,4 milliards de dollars. En mai 2026, OpenTofu publie sa version 1.12 avec du chiffrement natif du state, le flag -exclude, provider for_each et l’early variable evaluation — quatre fonctionnalités que le CLI open source de Terraform ne propose toujours pas.

Trois ans après le fork, le verdict est clair : OpenTofu n’est plus le fork du ressentiment — c’est le fork de la raison.

Pourquoi le fork existe encore — et pourquoi il gagne

Le débat OpenTofu vs Terraform a changé de nature. En 2023, le fork était un réflexe défensif : une communauté qui refuse de travailler sous une licence qui interdit la concurrence commerciale. En 2026, c’est un projet qui a dépassé Terraform sur plusieurs fronts techniques.

OpenTofu est aujourd’hui hébergé par la CNCF sous la Linux Foundation, gouverné par un Technical Steering Committee multi-entreprises. Aucune société ne peut en changer la licence ou la feuille de route. Terraform, lui, est un produit IBM sous licence BSL 1.1 — le code source est visible, mais chaque release ne repasse en MPL que quatre ans après sa publication. Pour un SaaS ou une plateforme qui embarque de l’IaC, c’est un risque juridique réel.

La compatibilité est quasi totale. OpenTofu a été forké depuis Terraform 1.5.x, la dernière version MPL, et lit le même format de state (.tfstate JSON). Les providers du registry Terraform fonctionnent sans modification. La syntaxe HCL est identique. Le binaire s’appelle tofu au lieu de terraform — c’est le seul changement visible au quotidien.

Ce qu’OpenTofu a que Terraform n’a toujours pas

La divergence ne porte pas sur la syntaxe : elle porte sur des fonctionnalités que la communauté réclamait depuis des années et que HashiCorp a dépriorisées au profit de HCP Terraform (ex-Terraform Cloud).

Chiffrement natif du state

Le fichier de state contient tout : identifiants de ressources, outputs sensibles, parfois des clés d’API. Par défaut, il est en clair dans votre backend. Si quelqu’un lit votre bucket S3, il lit votre state.

OpenTofu 1.7 a introduit le chiffrement natif au repos, y compris pour le state distant et les plans. Vous configurez un key provider — AWS KMS, GCP KMS, Vault ou une passphrase — et OpenTofu chiffre automatiquement.

terraform {
  encryption {
    key_provider "aws_kms" "main" {
      kms_key_id = "arn:aws:kms:us-east-1:111122223333:key/abcd-1234"
      region     = "us-east-1"
      key_spec   = "AES_256"
    }

    method "aes_gcm" "main" {
      keys = key_provider.aws_kms.main
    }

    state {
      method = method.aes_gcm.main
    }

    plan {
      method = method.aes_gcm.main
    }
  }
}

Le CLI open source de Terraform n’a pas d’équivalent. Pour obtenir du chiffrement, il faut passer par HCP Terraform — un produit payant.

provider for_each et -exclude

OpenTofu permet de définir plusieurs instances d’un provider et d’itérer dessus. C’est la réponse propre au vieux problème de gestion multi-région ou multi-compte sans dupliquer des blocs entiers. Le flag -exclude fait l’inverse de -target : il permet de planifier ou appliquer tout sauf une ressource.

# Appliquer tout sauf la base de données, gérée séparément
tofu apply -exclude=aws_db_instance.primary

Early variable evaluation

OpenTofu évalue les variables plus tôt que Terraform, ce qui permet de les utiliser dans les module source et les backend — deux endroits où Terraform les rejette encore. Une classe d’astuces et de workarounds disparaît.

Bloc removed avec destroy = false

Introduit en v1.12 (mai 2026), le bloc removed permet de retirer une ressource du state sans la détruire, de manière déclarative. Avant, il fallait un terraform state rm manuel.

removed {
  from = aws_instance.legacy_server

  lifecycle {
    destroy = false
  }
}

Aucune de ces fonctionnalités, prise isolément, ne justifie une migration. Ensemble, elles montrent que le fork livre — et pas seulement sur la compatibilité.

La migration est un non-événement

C’est le point que la plupart des équipes comprennent à l’envers. Elles traitent la migration comme le risque principal. Ce n’est pas le cas.

Terraform et OpenTofu partagent le même format de state. Migrer, c’est échanger le binaire terraform contre tofu, lancer tofu init, puis tofu plan. Si le plan affiche zéro changement, la migration est propre.

# 1. Sauvegarder le state
terraform state pull > terraform.tfstate.backup

# 2. Installer OpenTofu
curl -fsSL https://get.opentofu.org/install-opentofu.sh | bash

# 3. Initialiser
tofu init

# 4. Vérifier — un plan propre ne montre aucun changement
tofu plan

# 5. Mettre à jour la CI/CD : remplacer terraform par tofu

La migration est réversible tant que vous n’adoptez pas de fonctionnalités exclusives à OpenTofu. Le vrai lock-in commence quand vous activez le chiffrement natif du state : à ce moment-là, revenir à Terraform nécessite de déchiffrer et de migrer le state à la main.

Le vrai coût de rester sur Terraform

Rester sur Terraform en 2026 n’est pas gratuit non plus. Le coût se mesure sur trois axes.

Premièrement, le licensing. La licence BSL 1.1 interdit d’utiliser Terraform pour construire un produit concurrent de HashiCorp. La formulation est volontairement large. Si votre entreprise construit une plateforme qui expose de l’IaC à ses clients, le risque juridique est réel. OpenTofu, sous MPL 2.0, n’a pas cette restriction.

Deuxièmement, le chiffrement. Sans HCP Terraform, votre state est en clair. Chiffrer le bucket S3 ne suffit pas : le state reste lisible par quiconque a accès au bucket. Le chiffrement applicatif d’OpenTofu protège même contre un accès compromis au backend.

Troisièmement, la gouvernance. IBM contrôle la roadmap de Terraform. L’historique récent montre que les fonctionnalités communautaires (state encryption, -exclude) sont dépriorisées au profit de l’intégration HCP Terraform. Avec OpenTofu, la gouvernance est ouverte et multi-entreprises.

Remplacer Terraform Cloud sans perdre de fonctionnalités

Migrer vers OpenTofu coupe l’accès à HCP Terraform (ex-Terraform Cloud). Voici ce qui le remplace, selon votre taille.

Pour une équipe de 5 à 20 personnes, la stack S3 + DynamoDB + GitHub Actions + Atlantis coûte moins de 50 $ par mois et couvre 90 % des besoins pour lesquels les équipes paient HCP Terraform. Spacelift et env0 montent en gamme avec du drift detection, des politiques OPA et des workflows d’approbation — pour un tarif compétitif face à HCP Terraform.

# Backend S3 + DynamoDB — zero coût récurrent au-delà du stockage
terraform {
  backend "s3" {
    bucket         = "my-tofu-state"
    key            = "production/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "tofu-state-lock"
    encrypt        = true
  }
}

Verdict

OpenTofu est aujourd’hui le choix rationnel pour tout nouveau projet d’IaC — et un objectif de migration légitime pour les parcs Terraform existants.

La décision dépend de trois critères :

• Vous démarrez un nouveau projet. Prenez OpenTofu. Le chiffrement natif, l’absence de restrictions de licence et la gouvernance ouverte n’ont pas d’équivalent côté Terraform. Vous n’aurez jamais à vous poser la question du fork.
• Vous avez un parc Terraform existant sans dépendance à HCP Terraform. Migrez par lot. Commencez par les environnements de staging, validez avec tofu plan, puis basculez la production. La migration est un simple swap de binaire.
• Vous êtes lié à HCP Terraform par contrat ou par des fonctionnalités non substituables. Restez, mais auditez votre dépendance. Chaque fonctionnalité exclusive à HCP est un coût de sortie futur. Évaluez Spacelift ou env0 pour les nouveaux projets.

OpenTofu n’est plus le fork du ressentiment. Avec la v1.12 de mai 2026, le CNCF derrière lui, et trois ans de releases qui dépassent Terraform sur des fonctionnalités concrètes, c’est devenu le fork de la raison.

Références

• OpenTofu v1.12 Release Notes — mai 2026
• OpenTofu in 2026: Should You Switch from Terraform — DevOps Daily, juin 2026
• OpenTofu and the Future of Infrastructure as Code After Terraform’s License Change — Dev Note, mai 2026
• OpenTofu vs Terraform: The 2026 Comparison for Linux Admins — FOSS Linux, avril 2026
• OpenTofu official documentation — consulté en mai 2026
• HashiCorp License Change (BSL) — août 2023
• IBM Completes Acquisition of HashiCorp — février 2025