OpenTofu : L'Alternative Open-Source à Terraform après le Fork

Introduction : Pourquoi OpenTofu existe-t-il ?

En août 2023, HashiCorp a déclenché un véritable séisme dans le monde de l'Infrastructure as Code (IaC) en annonçant le changement de licence de Terraform. L'outil phare, jusqu'alors distribué sous Mozilla Public License 2.0 (MPL 2.0), passait sous Business Source License 1.1 (BSL 1.1). Ce changement, perçu par une grande partie de la communauté comme une trahison de l'esprit open-source, a provoqué une réaction en chaîne qui a abouti à la création d'OpenTofu, un fork communautaire hébergé sous l'égide de la Linux Foundation.

Début 2026, OpenTofu a considérablement mûri. Avec plusieurs versions majeures publiées, des fonctionnalités exclusives comme le chiffrement natif du state, et un écosystème en pleine expansion, il s'impose comme une alternative crédible — voire supérieure sur certains points — à Terraform. Cet article propose un tour d'horizon complet, objectif et factuel de cette alternative, en présentant les deux points de vue.

Architecture en un coup d'œil

Diagramme - OpenTofu : L'Alternative Open-Source à Terraform après le Fork

Le contexte : la bataille des licences

La licence MPL 2.0 : l'âge d'or de l'open-source Terraform

Pendant près de dix ans, Terraform a été distribué sous la licence Mozilla Public License 2.0. Cette licence permissive permettait à quiconque d'utiliser, modifier et redistribuer le code, y compris dans des produits commerciaux. C'est cette ouverture qui a permis l'émergence d'un écosystème riche : des centaines de providers communautaires, des outils tiers comme Terragrunt, Atlantis, Spacelift, env0, et des milliers de modules partagés sur le Terraform Registry.

Le passage à BSL 1.1 : les motivations de HashiCorp

Du point de vue de HashiCorp, le changement de licence était une question de survie économique. L'entreprise a argumenté que des concurrents directs utilisaient le code source de Terraform pour proposer des services managés concurrents de Terraform Cloud et Terraform Enterprise, sans contribuer en retour. La BSL 1.1 interdit spécifiquement l'utilisation du logiciel pour proposer un produit concurrent, tout en permettant l'usage interne et la contribution communautaire.

« La BSL n'est pas une licence propriétaire. Elle permet l'utilisation en production, la modification du code, et la contribution. Elle interdit simplement de créer un produit concurrent basé sur notre travail. » — HashiCorp, communiqué officiel, août 2023.

La réponse de la communauté : le manifeste OpenTF

La réaction a été immédiate et massive. En quelques jours, un manifeste OpenTF a recueilli des milliers de signatures de développeurs, d'entreprises et d'organisations. Les signataires demandaient à HashiCorp de revenir sur sa décision ou, à défaut, soutenaient la création d'un fork véritablement open-source. Parmi les signataires, on trouvait des entreprises comme Gruntwork, Spacelift, env0, Scalr et des centaines d'autres acteurs de l'écosystème.

Face au refus de HashiCorp, le fork a été officiellement lancé sous le nom OpenTofu en septembre 2023, avec un hébergement sous la Linux Foundation garantissant une gouvernance neutre et ouverte.

Qu'est-ce qu'OpenTofu ?

OpenTofu est un outil d'Infrastructure as Code open-source, distribué sous licence MPL 2.0. Il permet de définir, provisionner et gérer des infrastructures cloud et on-premise de manière déclarative, à l'aide de fichiers de configuration écrits en HCL (HashiCorp Configuration Language) ou en JSON.

Concrètement, OpenTofu est un fork direct de Terraform v1.5.x, la dernière version publiée sous licence MPL. Cela signifie que le code de base est identique, et que la compatibilité avec les configurations Terraform existantes est quasi totale.

Les principes fondateurs d'OpenTofu

Véritablement open-source : licence MPL 2.0, pas de restrictions d'usage commercial
Gouvernance communautaire : sous la Linux Foundation, avec un steering committee élu
Compatibilité maximale : les configurations Terraform existantes fonctionnent avec OpenTofu
Innovation ouverte : les nouvelles fonctionnalités sont développées en concertation avec la communauté
Neutralité : aucune entreprise unique ne contrôle le projet

Différences clés entre OpenTofu et Terraform

Bien qu'OpenTofu soit né d'un fork de Terraform, les deux projets ont divergé significativement depuis 2023. Voici les principales différences en 2026.

1. Le chiffrement natif du state

C'est probablement la fonctionnalité exclusive la plus marquante d'OpenTofu. Le state file contient souvent des informations sensibles : mots de passe de bases de données, clés API, adresses IP internes. Avec Terraform, le chiffrement du state dépend du backend utilisé (S3 avec KMS, par exemple). Avec OpenTofu, le chiffrement est natif et indépendant du backend.

# Configuration du chiffrement du state dans OpenTofu
# Fichier : main.tf

terraform {
  encryption {
    method "aes_gcm" "default" {
      keys = key_provider.pbkdf2.mykey
    }

    key_provider "pbkdf2" "mykey" {
      passphrase = var.state_passphrase
    }

    state {
      method   = method.aes_gcm.default
      enforced = true
    }

    plan {
      method   = method.aes_gcm.default
      enforced = true
    }
  }
}

Cette fonctionnalité permet de chiffrer le state et les fichiers de plan avec AES-GCM, en utilisant différents fournisseurs de clés : PBKDF2, AWS KMS, GCP KMS ou Azure Key Vault. Le chiffrement est transparent et ne nécessite aucune modification des ressources existantes.

2. Early variable et provider evaluation

OpenTofu a introduit l'évaluation anticipée des variables et des providers, une fonctionnalité très demandée par la communauté. Elle permet d'utiliser des variables et des expressions dans les blocs terraform et provider, là où Terraform exige des valeurs statiques.

# Exemple : utilisation de variables dans la configuration du backend
# Impossible avec Terraform, possible avec OpenTofu

variable "environment" {
  type    = string
  default = "production"
}

variable "region" {
  type    = string
  default = "eu-west-1"
}

terraform {
  backend "s3" {
    bucket = "tfstate-${var.environment}"
    key    = "infra/${var.environment}/terraform.tfstate"
    region = var.region
  }
}

Cette fonctionnalité élimine le besoin de solutions de contournement comme les fichiers .tfbackend partiels ou les wrappers comme Terragrunt pour la configuration dynamique des backends.

3. Le bloc removed

OpenTofu a introduit le bloc removed pour gérer proprement la suppression de ressources du state sans les détruire dans l'infrastructure réelle. Terraform a fini par implémenter une fonctionnalité similaire, mais l'approche d'OpenTofu est apparue en premier et diffère sur certains aspects.

# Supprimer une ressource du state sans la détruire
removed {
  from = aws_instance.legacy_server

  lifecycle {
    destroy = false
  }
}

# Déplacer une ressource vers un autre module
moved {
  from = aws_instance.web
  to   = module.web.aws_instance.main
}

4. Tableau comparatif détaillé

Fonctionnalité	OpenTofu	Terraform
Licence	MPL 2.0	BSL 1.1
Gouvernance	Linux Foundation	HashiCorp / IBM
Chiffrement natif du state	Oui (AES-GCM)	Non (dépend du backend)
Early variable evaluation	Oui	Non
Bloc removed	Oui	Oui (ajouté après)
Registry	registry.opentofu.org	registry.terraform.io
CLI	tofu	terraform
Compatibilité providers	Quasi totale	Native
Support commercial	Via partenaires (Spacelift, env0…)	Terraform Cloud / Enterprise
for_each sur providers	En développement	Non

Installation d'OpenTofu

OpenTofu est disponible sur toutes les plateformes majeures. Voici les méthodes d'installation les plus courantes.

macOS (Homebrew)

# Installation via Homebrew
brew install opentofu

# Vérification
tofu --version

Linux (Debian/Ubuntu via APT)

# Ajout du dépôt officiel
curl -fsSL https://get.opentofu.org/install-opentofu.sh -o install-opentofu.sh
chmod +x install-opentofu.sh
./install-opentofu.sh --install-method deb

# Vérification
tofu --version

Linux (RHEL/Fedora via RPM)

# Installation via le script officiel
curl -fsSL https://get.opentofu.org/install-opentofu.sh -o install-opentofu.sh
chmod +x install-opentofu.sh
./install-opentofu.sh --install-method rpm

# Vérification
tofu --version

Installation manuelle (binaire)

# Télécharger la dernière version depuis GitHub
OPENTOFU_VERSION="1.9.0"
curl -LO "https://github.com/opentofu/opentofu/releases/download/v${OPENTOFU_VERSION}/tofu_${OPENTOFU_VERSION}_linux_amd64.zip"

# Extraire et installer
unzip "tofu_${OPENTOFU_VERSION}_linux_amd64.zip" -d /tmp/opentofu
sudo mv /tmp/opentofu/tofu /usr/local/bin/
sudo chmod +x /usr/local/bin/tofu

# Vérification
tofu --version

Docker

# Utilisation via Docker
docker run --rm -v $(pwd):/workspace -w /workspace ghcr.io/opentofu/opentofu:latest init
docker run --rm -v $(pwd):/workspace -w /workspace ghcr.io/opentofu/opentofu:latest plan

Migration de Terraform vers OpenTofu : guide pas à pas

L'un des grands atouts d'OpenTofu est sa compatibilité quasi totale avec Terraform. La migration est généralement simple et peu risquée. Voici un guide détaillé.

Étape 1 : Évaluer la compatibilité

Avant de migrer, vérifiez les points suivants :

Version de Terraform : OpenTofu est compatible avec les configurations Terraform jusqu'à la version 1.5.x. Si vous utilisez des fonctionnalités introduites dans Terraform 1.6+ (sous BSL), vérifiez qu'elles ont un équivalent dans OpenTofu.
Providers : la quasi-totalité des providers Terraform fonctionnent avec OpenTofu sans modification. Le registre OpenTofu les référence automatiquement.
Modules : les modules Terraform sont compatibles. Seule la source peut nécessiter un ajustement si elle pointe vers le registre Terraform.
State backend : tous les backends Terraform standard (S3, GCS, Azure Blob, Consul, etc.) sont supportés par OpenTofu.

Étape 2 : Installer OpenTofu

# Installer OpenTofu (voir section précédente)
brew install opentofu

# Vérifier que tofu est disponible
tofu --version

Étape 3 : Adapter la configuration (si nécessaire)

Dans la plupart des cas, aucune modification n'est nécessaire. La commande tofu remplace simplement terraform. Cependant, si vous utilisez le bloc cloud de Terraform Cloud, vous devrez passer à un backend classique ou à une solution compatible comme Spacelift ou env0.

# Avant (Terraform Cloud)
terraform {
  cloud {
    organization = "mon-org"
    workspaces {
      name = "mon-workspace"
    }
  }
}

# Après (backend S3 pour OpenTofu)
terraform {
  backend "s3" {
    bucket         = "mon-tfstate"
    key            = "infra/terraform.tfstate"
    region         = "eu-west-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

Étape 4 : Initialiser avec OpenTofu

# Se placer dans le répertoire du projet
cd /chemin/vers/mon-projet-iac

# Initialiser OpenTofu (télécharge les providers et configure le backend)
tofu init

# En cas de migration depuis un state Terraform existant, le state est lu tel quel
# OpenTofu utilise le même format de state que Terraform

Étape 5 : Vérifier avec un plan

# Exécuter un plan pour vérifier qu'il n'y a pas de différences
tofu plan

# Le plan ne devrait montrer aucun changement si l'infrastructure est à jour
# "No changes. Your infrastructure matches the configuration."

Étape 6 : Mettre à jour la CI/CD

# Exemple de pipeline GitLab CI migré vers OpenTofu
stages:
  - validate
  - plan
  - apply

variables:
  OPENTOFU_VERSION: "1.9.0"

.tofu_template: &tofu_template
  image: ghcr.io/opentofu/opentofu:${OPENTOFU_VERSION}
  before_script:
    - tofu --version

validate:
  <<: *tofu_template
  stage: validate
  script:
    - tofu init -backend=false
    - tofu validate
    - tofu fmt -check -recursive

plan:
  <<: *tofu_template
  stage: plan
  script:
    - tofu init
    - tofu plan -out=tfplan
  artifacts:
    paths:
      - tfplan

apply:
  <<: *tofu_template
  stage: apply
  script:
    - tofu init
    - tofu apply tfplan
  when: manual
  only:
    - main

Étape 7 : Créer un alias (optionnel)

# Pour faciliter la transition, vous pouvez créer un alias
echo 'alias terraform="tofu"' >> ~/.zshrc
source ~/.zshrc

# Ainsi, les scripts existants utilisant "terraform" appelleront "tofu"

Fonctionnalités exclusives d'OpenTofu en détail

Chiffrement du state : configuration avancée

Le chiffrement du state dans OpenTofu supporte plusieurs fournisseurs de clés. Voici des exemples concrets pour les principaux clouds.

# Chiffrement avec AWS KMS
terraform {
  encryption {
    key_provider "aws_kms" "production" {
      kms_key_id = "arn:aws:kms:eu-west-1:123456789:key/abcd-1234"
      region     = "eu-west-1"
      key_spec   = "AES_256"
    }

    method "aes_gcm" "secure" {
      keys = key_provider.aws_kms.production
    }

    state {
      method   = method.aes_gcm.secure
      enforced = true
    }
  }
}

# Chiffrement avec GCP KMS
terraform {
  encryption {
    key_provider "gcp_kms" "production" {
      kms_encryption_key = "projects/mon-projet/locations/europe-west1/keyRings/tofu/cryptoKeys/state"
      key_length         = 32
    }

    method "aes_gcm" "secure" {
      keys = key_provider.gcp_kms.production
    }

    state {
      method   = method.aes_gcm.secure
      enforced = true
    }
  }
}

Registre OpenTofu

OpenTofu maintient son propre registre à l'adresse registry.opentofu.org. Ce registre est compatible avec le registre Terraform et référence automatiquement les providers publiés sur GitHub. Vous pouvez aussi configurer des registres privés de la même manière qu'avec Terraform.

# Utilisation du registre OpenTofu (par défaut)
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = "~> 2.25"
    }
  }
}

# Le préfixe "hashicorp/" est résolu par le registre OpenTofu
# qui redirige vers les providers officiels

État de l'écosystème en 2026

Compatibilité des providers

La quasi-totalité des providers Terraform fonctionnent avec OpenTofu sans aucune modification. Les providers les plus utilisés — AWS, Azure, Google Cloud, Kubernetes, Helm, Cloudflare, Datadog, GitHub — sont tous compatibles. Cela s'explique par le fait que les providers utilisent le Terraform Plugin Protocol, qui est identique entre Terraform et OpenTofu.

Outils tiers compatibles

Terragrunt : support natif d'OpenTofu depuis la version 0.53+. Il suffit de configurer terraform_binary = "tofu" dans le fichier terragrunt.hcl.
Atlantis : support d'OpenTofu via configuration du binaire.
Spacelift : support natif d'OpenTofu comme runtime alternatif.
env0 : support natif d'OpenTofu.
Scalr : support natif d'OpenTofu.
tflint : compatible avec les configurations OpenTofu.
Infracost : compatible avec OpenTofu pour l'estimation des coûts.
Checkov / tfsec : compatibles pour l'analyse de sécurité.

Modules

Les modules du Terraform Registry sont utilisables avec OpenTofu. Le registre OpenTofu permet aussi de les référencer directement. Pour les modules hébergés sur Git, aucune modification n'est nécessaire :

# Module depuis le registre
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.5.0"

  name = "mon-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["eu-west-1a", "eu-west-1b", "eu-west-1c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]

  enable_nat_gateway = true
  single_nat_gateway = true
}

# Module depuis Git (fonctionne identiquement)
module "custom" {
  source = "git::https://gitlab.com/mon-org/modules/custom.git?ref=v1.2.0"
}

Communauté et gouvernance

La Linux Foundation comme garant

L'hébergement d'OpenTofu sous la Linux Foundation offre plusieurs garanties importantes :

Neutralité : aucune entreprise ne peut prendre le contrôle unilatéral du projet.
Pérennité : la Linux Foundation héberge des projets critiques comme Linux, Kubernetes, Node.js ou Let's Encrypt.
Gouvernance transparente : un steering committee élu, des réunions publiques, et un processus de décision documenté.
Protection juridique : la fondation protège les contributeurs et le projet contre les poursuites liées à la propriété intellectuelle.

Contribution et développement

OpenTofu est développé de manière ouverte sur GitHub. Les contributions sont les bienvenues, avec un processus de revue de code structuré. En 2026, le projet compte plusieurs centaines de contributeurs actifs et une communauté grandissante sur Discord et les forums.

Le développement suit un cycle de release régulier, avec des versions mineures tous les quelques mois et des patches de sécurité publiés rapidement.

Roadmap d'OpenTofu

La roadmap d'OpenTofu est publique et définie en concertation avec la communauté. Parmi les fonctionnalités prévues ou en cours de développement :

for_each sur les providers : permettre d'itérer sur une liste de providers, simplifiant la gestion multi-régions et multi-comptes.
Amélioration du langage : nouvelles fonctions, meilleure gestion des types complexes.
Performances : optimisation du graphe de dépendances et parallélisation accrue.
Meilleure intégration CI/CD : outputs structurés, meilleure gestion des plans sauvegardés.
Provider development kit amélioré : faciliter le développement de nouveaux providers.

Le point de vue de HashiCorp / IBM

Il est important de présenter le point de vue de HashiCorp, racheté par IBM fin 2023 pour 6,4 milliards de dollars. Depuis l'acquisition :

HashiCorp maintient que la BSL protège l'innovation et le modèle commercial nécessaire au développement continu de Terraform.
Terraform continue de recevoir des mises à jour régulières avec de nouvelles fonctionnalités.
Terraform Cloud et Terraform Enterprise offrent des fonctionnalités avancées de collaboration, de gouvernance et de gestion des coûts qui n'ont pas d'équivalent direct dans OpenTofu.
Le support commercial officiel reste un avantage pour les grandes entreprises soumises à des exigences réglementaires.

Il convient de reconnaître que le changement de licence n'affecte pas l'usage interne en entreprise. La BSL 1.1 interdit uniquement la création de produits concurrents. Pour la majorité des utilisateurs de Terraform, le changement de licence n'a aucun impact pratique sur leur utilisation quotidienne.

Quand choisir OpenTofu vs Terraform ?

Choisir OpenTofu si :

Vous avez une politique stricte sur les licences open-source (administration publique, organisations à but non lucratif, projets open-source).
Vous avez besoin du chiffrement natif du state sans dépendre du backend.
Vous voulez utiliser des variables dans les blocs backend sans Terragrunt ou wrappers.
Vous souhaitez une gouvernance neutre, non dépendante d'une entreprise unique.
Vous êtes un fournisseur de services IaC et la BSL vous interdit d'utiliser Terraform.
Vous voulez contribuer au développement dans un cadre véritablement communautaire.

Choisir Terraform si :

Vous utilisez Terraform Cloud ou Enterprise et êtes satisfait des fonctionnalités de collaboration et de gouvernance.
Vous avez besoin du support commercial officiel de HashiCorp / IBM.
Votre équipe est habituée à Terraform et le changement de licence ne vous affecte pas.
Vous utilisez des fonctionnalités spécifiques à Terraform 1.6+ qui n'ont pas d'équivalent OpenTofu.
Vous préférez un écosystème plus mature avec une documentation plus abondante.

Dans tous les cas

La bonne nouvelle est que la migration dans un sens ou dans l'autre reste relativement simple. Les configurations HCL sont compatibles, les providers sont les mêmes, et le format du state est identique. Vous n'êtes donc pas enfermé dans un choix irrévocable.

Exemple complet : infrastructure AWS avec OpenTofu

Pour conclure, voici un exemple complet d'une infrastructure AWS déployée avec OpenTofu, utilisant le chiffrement du state et l'évaluation anticipée des variables.

# variables.tf
variable "environment" {
  type        = string
  description = "Environnement de déploiement"
  validation {
    condition     = contains(["dev", "staging", "production"], var.environment)
    error_message = "L'environnement doit être dev, staging ou production."
  }
}

variable "region" {
  type    = string
  default = "eu-west-1"
}

variable "state_passphrase" {
  type      = string
  sensitive = true
}

# main.tf
terraform {
  required_version = ">= 1.9.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.40"
    }
  }

  backend "s3" {
    bucket         = "tofu-state-${var.environment}"
    key            = "infra/main.tfstate"
    region         = var.region
    dynamodb_table = "tofu-locks"
    encrypt        = true
  }

  encryption {
    key_provider "pbkdf2" "main" {
      passphrase = var.state_passphrase
    }

    method "aes_gcm" "default" {
      keys = key_provider.pbkdf2.main
    }

    state {
      method   = method.aes_gcm.default
      enforced = true
    }
  }
}

provider "aws" {
  region = var.region

  default_tags {
    tags = {
      Environment = var.environment
      ManagedBy   = "OpenTofu"
      Project     = "codeclan-infra"
    }
  }
}

# VPC
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.5.0"

  name = "${var.environment}-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["${var.region}a", "${var.region}b"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24"]

  enable_nat_gateway = var.environment == "production"
  single_nat_gateway = true
}

# outputs.tf
output "vpc_id" {
  value = module.vpc.vpc_id
}

output "private_subnets" {
  value = module.vpc.private_subnets
}

# Déploiement
tofu init
tofu plan -var="environment=production" -var="state_passphrase=mon-secret"
tofu apply -var="environment=production" -var="state_passphrase=mon-secret"

Conclusion

OpenTofu a parcouru un chemin remarquable depuis son lancement en 2023. Ce qui a commencé comme une réaction à un changement de licence est devenu un projet mature, innovant et soutenu par une communauté active. Les fonctionnalités exclusives comme le chiffrement natif du state et l'évaluation anticipée des variables apportent une réelle valeur ajoutée par rapport à Terraform.

Pour autant, Terraform reste un outil solide, bien documenté et soutenu par les ressources considérables d'IBM. Le choix entre les deux dépend avant tout de vos contraintes de licence, de vos besoins fonctionnels et de votre vision de l'open-source.

Ce qui est certain, c'est que la concurrence entre OpenTofu et Terraform profite à l'ensemble de l'écosystème IaC. Les deux projets s'influencent mutuellement, et les utilisateurs disposent désormais d'un véritable choix — ce qui est, en soi, une victoire pour la communauté.