OpenTofu : migrer depuis Terraform sans douleur

Le 10 août 2023, HashiCorp a annoncé le passage de Terraform de la licence MPL 2.0 (open source) à la Business Source License v1.1, fermant ainsi l'usage commercial concurrentiel. La réaction de la communauté a été immédiate : un manifeste signé par des dizaines d'entreprises et un fork sous le nom de OpenTF, vite renommé OpenTofu et rapidement intégré à la Linux Foundation. Deux ans plus tard, OpenTofu est en production chez de nombreuses organisations et constitue la voie open source crédible pour ce qui était Terraform.

Cet article fait le point sur OpenTofu, ses différences avec Terraform, et la procédure concrète de migration.

• Pourquoi OpenTofu existe
• Compatibilité avec Terraform
• Fonctionnalités exclusives à OpenTofu
• Procédure de migration depuis Terraform 1.5
• Comparaison OpenTofu vs Terraform vs Pulumi
• Cas d'usage et limites

Terraform a été open source sous MPL 2.0 jusqu'à la version 1.5.x. À partir de la 1.6 (août 2023), HashiCorp a basculé sous Business Source License (BSL) : utilisation gratuite et libre, sauf pour des entreprises proposant des produits commerciaux concurrents (typiquement les SaaS d'IaC, ce qui visait Spacelift, env0, Terragrunt SaaS, etc.).

La communauté s'est mobilisée. Un manifeste a été publié, signé par des entreprises majeures (Spacelift, env0, Gruntwork, Harness, Scalr, etc.). Un fork de Terraform 1.5.7 a été démarré sous le nom OpenTF, puis renommé OpenTofu. La Linux Foundation a accepté de l'héberger, créant une gouvernance ouverte et neutre.

Aujourd'hui, OpenTofu :

• Est sous licence Mozilla Public License v2.0 (la licence d'origine de Terraform).
• Est gouverné par un Technical Steering Committee multi-entreprises sous Linux Foundation.
• Publie ses propres releases avec des fonctionnalités exclusives.
• Maintient une compatibilité forte avec les versions Terraform jusqu'à 1.5.x.

La dernière version stable au moment de la rédaction est la v1.11.6, publiée le 8 avril 2026.

OpenTofu se présente comme un drop-in replacement pour Terraform 1.5.x et inférieur. Concrètement :

• Configurations HCL existantes : compilent et s'exécutent sans modification.
• Modules de la registry HashiCorp : continuent de fonctionner via la OpenTofu Registry (miroir maintenu).
• Providers AWS / Azure / GCP / etc. : fonctionnent à l'identique.
• State files : compatibles dans les deux sens, sauf pour OpenTofu si le state utilise des fonctionnalités exclusives (chiffrement, par exemple).
• Backends (S3, Azure Storage, GCS, Consul, etc.) : tous supportés.

Le fork s'appuyant sur Terraform 1.5.7 comme base, les nouveautés Terraform 1.6+ (post-BSL) ne sont pas reprises automatiquement. OpenTofu réimplémente ou choisit ses propres équivalents pour les fonctionnalités utiles.

Quelques points d'écart connus en 2026 :

• Certaines fonctionnalités Terraform 1.6/1.7 (test framework, import blocks avancés) ont été réimplémentées différemment ou avec une autre syntaxe.
• HCP Terraform (Terraform Cloud) reste propriétaire HashiCorp ; OpenTofu n'a pas d'équivalent unique mais s'intègre avec les SaaS communautaires (Scalr, Spacelift, env0, Terramate Cloud).

OpenTofu a livré plusieurs fonctionnalités absentes de Terraform open source.

State encryption native

Probablement la fonctionnalité la plus attendue. Permet de chiffrer le state file et les plans de manière transparente, avec rotation des clés et providers de clés multiples (AWS KMS, GCP KMS, Azure Key Vault, OpenBao/HashiCorp Vault, PBKDF2, OpenPGP).

terraform {
  encryption {
    key_provider "aws_kms" "prod_kms" {
      kms_key_id = "arn:aws:kms:eu-west-3:123456789012:key/abcd-efgh"
      region     = "eu-west-3"
      key_spec   = "AES_256"
    }

    method "aes_gcm" "prod" {
      keys = key_provider.aws_kms.prod_kms
    }

    state {
      method = method.aes_gcm.prod
    }

    plan {
      method = method.aes_gcm.prod
    }
  }
}

Le state stocké dans le backend (S3, GCS, Azure Storage) est désormais chiffré par OpenTofu lui-même, en plus du chiffrement éventuel côté backend. La clé de chiffrement reste sous le contrôle de l'utilisateur.

Provider for_each natif

provider "aws" {
  alias    = "regional"
  for_each = var.regions
  region   = each.value
}

resource "aws_s3_bucket" "regional" {
  for_each = var.regions
  provider = aws.regional[each.key]
  bucket   = "logs-${each.key}"
}

Permet d'instancier dynamiquement plusieurs configurations de provider sans script externe. Particulièrement utile pour les déploiements multi-region, multi-account ou multi-cluster.

Early evaluation des variables

Permet d'utiliser des variables dans le bloc terraform {} lui-même (par exemple pour le backend). Évite l'éternel problème de paramétriser le bucket S3 du backend selon l'environnement.

Conditional and dynamic exclusion

Différents idioms pour exclure des ressources, des modules ou des outputs selon des conditions, sans recourir aux astuces classiques (count = condition ? 1 : 0).

La migration est volontairement triviale pour les configurations Terraform 1.5.x ou inférieures :

# 1. Installer OpenTofu (binaire `tofu`)
brew install opentofu       # macOS
# ou via le repo officiel pour Linux

# 2. Vérifier la version Terraform actuelle
terraform version
# Terraform v1.5.7

# 3. Tester avec OpenTofu sans modifier le state
cd infra/
tofu init -upgrade
tofu plan -out=tfplan

# 4. Si le plan est cohérent, basculer le state file
tofu apply tfplan

Pour des configurations Terraform 1.6+, vérifier en amont les fonctionnalités utilisées :

• terraform test (test framework) : équivalent OpenTofu existe mais syntaxe différente.
• import {} blocks avancés : présents dans OpenTofu, légère divergence selon les versions.
• Stacks (Terraform Cloud) : non équivalents, à reconfigurer si utilisés.

Pour un parc important, la stratégie type :

1. Inventaire : lister tous les workspaces et leurs versions Terraform.
2. Pinning : forcer Terraform 1.5.7 sur les workspaces 1.6+ (downgrade documenté par HashiCorp).
3. Migration progressive : workspace par workspace, avec tests tofu plan en parallèle.
4. Bascule : changer la binary CI de terraform à tofu.

L'effort par workspace est typiquement de quelques minutes si la config est standard, plus long si elle utilise des fonctionnalités Terraform 1.6+.

OpenTofu est l'option par défaut pour les organisations qui veulent rester sur HCL et garantir la pérennité open source de leur IaC. Terraform reste pertinent pour celles qui sont déjà investies dans HCP Terraform et qui acceptent les conditions BSL. Pulumi s'adresse aux équipes qui préfèrent un langage généraliste à HCL.

Cas d'usage où OpenTofu est le choix naturel

• Migration depuis Terraform 1.5 ou inférieur : zéro friction.
• Organisations qui exigent une licence open source stricte (compliance, contraintes contractuelles).
• State avec données sensibles : la state encryption native est un game-changer.
• Multi-vendor SaaS IaC : Scalr, Spacelift, env0, Terramate, Terraform Cloud Run UI sont tous compatibles OpenTofu.

Limites à connaître

Pas de feature parity 100 % avec Terraform récent. Les nouveautés HashiCorp post-1.5.7 ne sont pas reprises automatiquement. OpenTofu a son propre roadmap.

HCP Terraform pas remplacé par un produit unique. Pour la collaboration en équipe (state remote, run UI, policies), il faut combiner OpenTofu avec un SaaS (Scalr, Spacelift, etc.) ou self-host (Terramate, Atlantis).

Écosystème de modules. La OpenTofu Registry mirrore la registry HashiCorp ; pour la majorité des modules, c'est transparent. Mais si un module utilise des nouveautés Terraform 1.7+, il peut nécessiter des ajustements.

Documentation et formation. La majorité des ressources de formation existantes parlent de "Terraform". Le contenu est applicable à 95 % à OpenTofu, mais l'effort de mise à jour des supports internes est à prévoir.

• Terraform pour l'IaC
• Terraform et Ansible côté cloud
• Terragrunt et Terraform en production 2026
• Pulumi en 2026
• Configuration Management 2026

• OpenTofu (dépôt GitHub) code, releases, version v1.11.6
• Site officiel opentofu.org, documentation, blog
• Manifesto OpenTF, historique du fork
• Linux Foundation : OpenTofu, gouvernance
• Migration depuis Terraform, guide officiel

OpenTofu n'est pas une révolution technique : c'est la suite logique de Terraform 1.5 sous gouvernance ouverte, avec des fonctionnalités utiles ajoutées (state encryption native, provider for_each, early evaluation). Pour une organisation qui veut sécuriser sa pile IaC contre une évolution de licence et bénéficier d'une gouvernance multi-vendor, c'est aujourd'hui la voie naturelle. La migration depuis Terraform 1.5 est triviale, depuis 1.6+ demande un peu plus d'attention.