OpenTofu : l'alternative open-source à Terraform

Le changement de licence HashiCorp : un tournant historique

En août 2023, HashiCorp a annoncé le passage de Terraform (et de plusieurs autres produits) de la licence MPL 2.0 (Mozilla Public License) à la BSL 1.1 (Business Source License). Cette nouvelle licence interdit l'utilisation commerciale de Terraform pour des produits concurrents de HashiCorp — notamment les offres de Terraform managé proposées par des tiers comme Spacelift, Env0, ou Scalr.

La réaction de la communauté a été immédiate et massive. En quelques semaines, plusieurs grandes entreprises et acteurs open-source ont créé la OpenTofu Initiative, rapidement rejointe par Gruntwork, Spacelift, Env0, Scalr, Harness et d'autres. Le projet a été placé sous la gouvernance de la Linux Foundation et soumis comme projet sandbox auprès de la CNCF.

Naissance d'OpenTofu

OpenTofu est un fork de Terraform 1.5.x, créé à partir du dernier commit sous licence MPL 2.0. Le projet maintient une compatibilité totale avec Terraform 1.x tout en ajoutant de nouvelles fonctionnalités indépendantes. En 2024, OpenTofu a atteint la parité fonctionnelle avec Terraform 1.8 et a commencé à innover de façon autonome.

• Licence : MPL 2.0 — véritablement open-source, pour toujours
• Gouvernance : Linux Foundation Technical Advisory Council, vote par les contributeurs
• Registry : OpenTofu maintient son propre registry de providers et modules, compatible avec le registry Terraform
• CLI : commande tofu en remplacement de terraform

Parité fonctionnelle avec Terraform 1.8+

OpenTofu supporte l'ensemble des fonctionnalités de Terraform jusqu'à la version 1.8 :

• Backends S3, GCS, Azure Blob, Consul, HTTP
• Workspaces, modules, remote state
• Import de ressources existantes (import block)
• Test framework (tofu test)
• Check blocks pour les assertions post-apply
• Moved blocks pour les refactorisations

Fonctionnalités exclusives à OpenTofu

OpenTofu innove au-delà de Terraform avec des fonctionnalités qui n'existent pas dans la version HashiCorp :

Provider-defined Functions

Les providers peuvent désormais exposer des fonctions appelables depuis le code HCL, sans passer par des ressources data. Par exemple, un provider AWS peut exposer une fonction pour calculer dynamiquement des ARN :

output "bucket_arn" {
  value = provider::aws::arn(
    partition = "aws",
    service   = "s3",
    region    = "",
    account   = "",
    resource  = var.bucket_name
  )
}

Early Variable Evaluation

OpenTofu permet d'utiliser des variables dans les blocs backend et provider, ce qui était impossible avec Terraform. Cela facilite considérablement la configuration de backends dynamiques :

variable "environment" {
  type = string
}

terraform {
  backend "s3" {
    bucket = "tfstate-${var.environment}"    # Désormais possible avec OpenTofu
    key    = "terraform.tfstate"
    region = "eu-west-1"
  }
}

Chiffrement du state

OpenTofu supporte le chiffrement natif des fichiers state côté client, avec support de KMS AWS, GCP, Azure, ou d'une passphrase locale. Les state files chiffrés sont illisibles sans la clé, même avec un accès direct au bucket S3.

Guide de migration depuis Terraform

La migration de Terraform vers OpenTofu est conçue pour être non-destructive et réversible. Les fichiers state sont 100 % compatibles.

Étape 1 : Installer OpenTofu

# macOS via Homebrew
brew install opentofu

# Linux
curl --proto '=https' --tlsv1.2 -fsSL https://get.opentofu.org/install-opentofu.sh | sh

# Vérifier l'installation
tofu version

Étape 2 : Renommer les blocs terraform

Le seul changement syntaxique obligatoire est de renommer les blocs terraform {} en terraform {} — en réalité, OpenTofu accepte les deux. Le bloc required_providers fonctionne identiquement.

# Avant (Terraform)
terraform {
  required_version = ">= 1.5"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

# Après (OpenTofu) — identique, aucun changement nécessaire
terraform {
  required_version = ">= 1.5"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

Étape 3 : Mettre à jour les pipelines CI/CD

# GitHub Actions — avant
- name: Terraform Apply
  run: terraform apply -auto-approve

# Après
- name: OpenTofu Apply
  run: tofu apply -auto-approve

# Alternative : utiliser l'action officielle OpenTofu
- uses: opentofu/setup-opentofu@v1
  with:
    tofu_version: "1.8.0"

Compatibilité des providers et du state

Les providers du registry Terraform (registry.terraform.io) sont directement compatibles avec OpenTofu via le registry opentofu.org. Les fichiers state au format JSON sont identiques. Vous pouvez alterner entre terraform et tofu sur le même state sans conversion.

Quand migrer maintenant vs attendre ?

Migrez maintenant si vous utilisez Terraform dans un produit commercial concurrent de HashiCorp (obligation légale), si vous voulez bénéficier des fonctionnalités exclusives (chiffrement state, provider functions), ou si votre organisation a une politique open-source stricte.

Vous pouvez attendre si vous êtes sous contrat Terraform Cloud/Enterprise (respectez les termes du contrat), si votre usage est interne et non commercial, ou si votre organisation n'a pas encore décidé de sa stratégie IaC.

Conclusion

OpenTofu est aujourd'hui une alternative mature et feature-complete à Terraform. La migration est triviale pour la grande majorité des projets. Le choix entre OpenTofu et Terraform se résume à une question de gouvernance et de confiance : voulez-vous dépendre d'une entreprise dont la stratégie de monétisation peut changer, ou d'un projet sous gouvernance neutre de la Linux Foundation ?