Meta description : OpenTofu vs Terraform 2026 : licence MPL vs BSL, registry, state, migration douce et CI. Comparaison FR neutre pour choisir sans guerre de camps.

À la fin de ce tutoriel, vous saurez pourquoi OpenTofu existe (fork MPL après le BSL Terraform d’août 2023), ce qui reste compatible (HCL, providers, state), comment migrer doucement (tofu init / plan / apply), brancher la CI, et quand rester sur Terraform pour la continuité des labs DEH — sans polarisation.

Niveau : Intermédiaire · Temps estimé : 40–50 min · Versions cibles : Terraform ≥ 1.9 · OpenTofu (CLI tofu, vérifier release courante) · AWS provider 5.x · Dernière vérification : 2026-09-11

Slug proposé : opentofu-vs-terraform-2026 · Série : Terraform · Focus SEO : opentofu vs terraform

Statut : densifié P0 — prêt publication Tutoriels

Prérequis

La série DEH reste sur Terraform pour la continuité des labs. OpenTofu entre en jeu quand licence OSI, gouvernance Linux Foundation ou options CLI spécifiques comptent vraiment.

Ce que nous allons construire

Comparaison OpenTofu vs Terraform (2026)
  ├── Historique : BSL (août 2023) → fork OpenTofu (MPL 2.0)
  ├── Différences : licence, registry, state, features CLI / HCP
  ├── Tableau + versions.tf (AWS 5.x, ca-central-1)
  ├── Migration douce : backup → tofu init -upgrade → plan → apply
  ├── CI GitHub Actions : setup-terraform vs setup-opentofu
  ├── Verdict pédagogique DEH (neutre)
  └── Erreurs fréquentes + FAQ + Quiz + maillage /terraform/

(Schéma à remplacer par une image locale Excalidraw / draw.io, alt : « OpenTofu vs Terraform 2026 : licence MPL/BSL, registry, state et workflow init/plan/apply ».)

Historique

Août 2023 : Terraform passe en Business Source License

Le 10 août 2023, HashiCorp annonce le passage de Terraform (et d’autres produits) de la MPL 2.0 à la Business Source License 1.1 (BSL / BUSL). Les versions jusqu’à 1.5.x restent sous MPL ; les suivantes sont source-available sous BSL.

Usage interne (votre infra) : généralement permis. La BSL restreint surtout l’offre à des tiers (hébergé / embarqué) qui concurrence HashiCorp/IBM, avec conversion vers MPL après délai (quatre ans/release — texte officiel).

BSL n’est pas open source OSI : source-available + clause commerciale.

OpenTofu : fork sous Linux Foundation

Réaction communautaire → OpenTofu sous Linux Foundation (sept. 2023). Fork du dernier Terraform MPL (~1.5.x), licence MPL 2.0, binaire tofu (init/plan/apply/destroy/fmt/validate).

En 2026, roadmap et features divergent un peu ; un root AWS HCL classique reste largement interchangeable.

Différences

Licence, gouvernance, compatibilité

Critère Terraform OpenTofu
Licence (releases récentes) BSL 1.1 MPL 2.0 (OSI)
Gouvernance HashiCorp / IBM Linux Foundation
Usage interne d’infra Autorisé Autorisé
Offre concurrente hébergée / embarquée Restreinte (BSL) Autorisée (MPL)
Binaire terraform tofu
Registry registry.terraform.io registry.opentofu.org
HCL / state JSON Référence Large compatibilité (à tester)
  • HCL : resources, modules, variables, backend S3 — souvent sans réécriture.
  • Providers : hashicorp/aws reste usuel ; tofu init -upgrade régénère le .terraform.lock.hcl (checksums du registry cible).
  • State : un seul moteur par state ; backup avant le premier tofu apply ; bascule plutôt forward-only sans snapshot.

Écarts de features (vérifier la doc officielle)

Sujet Terraform (CLI / HCP) OpenTofu
Encryption state côté client (CLI) Pas d’équivalent natif open CLI Chiffrement natif documenté (GA historique ~1.7 — vérifier syntaxe)
Lock S3 DynamoDB historique ; suivre doc Terraform use_lockfile (lock natif S3) — vérifier version avant prod
Plateforme managée HCP Terraform (Stacks, Sentinel…) Pas d’équivalent 1:1 ; outils tiers
terraform {
  required_version = ">= 1.9.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "ca-central-1"
  # Auth : AWS_PROFILE / SSO / env — jamais de clés en dur
}

Même HCL pour un essai tofu : changez le binaire d’abord.

Migration

Étape 1 — Inventaire et backup

terraform version
aws s3 cp s3://VOTRE-BUCKET/chemin/terraform.tfstate \
  ./backup-terraform.tfstate.$(date +%Y%m%d) \
  --region ca-central-1

Versioning S3 activé ; documentez quel workspace bascule.

Étape 2 — Installer OpenTofu à côté

Gardez les deux binaires (opentofu.org) :

tofu version
which tofu && which terraform

Étape 3 — tofu init -upgrade puis plan

cd ~/lab-opentofu-migration
tofu init -upgrade
tofu fmt -check && tofu validate
tofu plan

Cible : No changes (ou diff compris). Destroys massifs → stop. Le -upgrade évite les erreurs de checksum sur le lock.

Étape 4 — apply non prod, puis CI

tofu apply
tofu plan   # No changes attendu

Chiffrement de state sur un state encore en clair : suivre le fallback unencrypted de la doc OpenTofu — ne pas improviser.

Caveats : features HCP-only (Stacks, Sentinel) ; terraform_remote_state multi-stacks (ordre de migration) ; pas d’encryption OpenTofu + lecture Terraform sans rollback ; providers / registres privés à valider.

Checklist HowTo migration (résumé opérable)

  • Inventaire des roots (versions.tf, backends, modules distants) et backup du state (versioning S3).
  • Installer tofu à côté de terraform, jamais en écrasant le binaire CI du jour J sans rollback.
  • tofu init -upgrade sur un root de lab, puis tofu plan jusqu’à « No changes » ou diff expliqué ligne à ligne.
  • Brancher la CI via opentofu/setup-opentofu sur une branche dédiée ; garder l’action HashiCorp sur main jusqu’au feu vert.
  • Documenter le moteur choisi dans le README et interdire deux CLI sur le même state (erreur fréquente n°1 en dual-run).

Cette checklist complète les étapes détaillées plus haut et le maillage state S3 · providers · modules.

CI

# Terraform (extrait)
- uses: hashicorp/setup-terraform@v3
  with:
    terraform_version: "1.9.8"
- uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
    aws-region: ca-central-1
- run: terraform init -input=false
- run: terraform plan -input=false -no-color
# OpenTofu (extrait)
- uses: opentofu/setup-opentofu@v2
  with:
    tofu_version: "1.9.0"   # adaptez après tofu version en lab
- uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
    aws-region: ca-central-1
- run: tofu init -input=false
- run: tofu plan -input=false -no-color

Commun : OIDC AWS, pin de version, plan sur PR / apply sur branche protégée, concurrency pour sérialiser les applies.

Critères de décision (quand OpenTofu, quand Terraform)

Posez quatre questions dans le RFC interne :

  1. Licence : OSI (MPL 2.0) exigée, ou BSL Terraform déjà validée pour usage interne non concurrentiel ?
  2. Plateforme : HCP Terraform / Stacks / Sentinel ? Le coût de sortie peut dépasser le gain licence.
  3. Compatibilité : plan OpenTofu identique (ou compris) sur un state de lab après backup ? Sinon, pas de cut-over.
  4. CI / compétences : l’équipe maîtrise-t-elle hashicorp/setup-terraform et les labs DEH (install, workflow, backend S3) ? Dual-run lab OK ; dual-run prod sur le même state = dangereux.

DEH : rester sur Terraform ≥ 1.9 pour la série ; OpenTofu si politique MPL ou feature CLI (encryption state), après inventaire → backup → tofu init -upgradeplan → apply non-prod — overview, hub Terraform.

Verdict

Position DEH (neutre, pratique) :

  1. Série et labs : rester sur Terraform ≥ 1.9 + AWS provider 5.x.
  2. OpenTofu si politique OSI (MPL), zone grise BSL (offre concurrente), ou feature CLI réelle (ex. encryption de state) — après un plan propre.
  3. Terraform / HCP si Stacks, Sentinel ou écosystème managé sont structurants et que la BSL est validée en interne.

Pas de guerre de camps : même ADN HCL. Décision 2026 = licence + plateforme + coût de migration.

Erreurs fréquentes

Symptôme Cause probable Correctif
Lock / checksum au tofu init Lock Terraform Registry tofu init -upgrade ; commit du lock
Recreates massifs au plan Drift, Region, feature non supportée Stop ; comparez les deux plan ; ca-central-1
State illisible après chiffrement Encryption sans fallback / mauvaise clé Doc encryption ; restaurer backup
CI : tofu: command not found Action / PATH opentofu/setup-opentofu avant les steps
Deux outils sur le même state Apply croisés Un moteur par state ; backup
« BSL = interdit en entreprise » Sur-interprétation Usage interne souvent OK — juridique

FAQ

OpenTofu remplace-t-il Terraform pour tout le monde en 2026 ?
Non. Alternative crédible pour beaucoup de workloads HCL. Terraform reste fort en doc, HCP et pédagogie.

Puis-je réutiliser les mêmes .tf ?
Oui dans la majorité des cas. tofu plan avant tout apply. Exceptions : features récentes / HCP-only.

Faut-il migrer mon backend S3 ?
En général non : même bucket/key, nouveau binaire, lock régénéré, plan validé. Adaptez use_lockfile / DynamoDB selon la doc de votre outil.

La série DEH passera-t-elle à OpenTofu ?
Labs sur Terraform. OpenTofu quand licence / features / politique l’exigent ; dual-run possible en lab perso.

BSL m’empêche-t-il d’apprendre Terraform ?
Non pour un usage pédagogique / interne classique. Offre concurrente managée → analyse juridique.

Mixer modules Terraform Registry et OpenTofu ?
Oui en général. Régénérez le lockfile avec votre CLI (tofu/terraform init -upgrade) et committez-le. Checksum mismatch : ne forcez pas à la main.

workspaces Terraform ≡ OpenTofu ?
Concept proche des deux côtés ; revalidez backends (use_lockfile, DynamoDB). Préférez souvent envs/workspaces.

plan OpenTofu veut recréer la moitié du parc ?
Stop. Restaurez le backup, comparez provider (~> 5.0), Region (ca-central-1), features HCP-only. Recreate massif ≠ migration réussie.

Quiz (5 questions)

1. Passage de Terraform en BSL (août 2023) pour un usage interne d’infra ?
– A. Interdiction totale en entreprise
– B. Source-available avec restriction sur offres concurrentes ; usage interne généralement permis
– C. Obligation de migrer vers CloudFormation

2. Première validation sûre après tofu init sur un state existant ?
– A. tofu apply -auto-approve
– B. tofu destroy
– C. tofu plan (No changes ou diff compris)

3. Posture pédagogique DEH ?
– A. Guerre de camps, un seul outil
– B. Labs sur Terraform ; OpenTofu selon licence / features / politique
– C. Abandonner HCL pour du bash uniquement

4. Danger principal du dual-run Terraform + OpenTofu ?
– A. Les fichiers .tf deviennent binaires
– B. Deux moteurs qui appliquent sur le même state
– C. Le registry refuse HTTPS

5. Première action si tofu plan montre des recreates massifs ?
– A. apply -auto-approve
– B. Stop, restaurer backup, analyser provider/Region/features
– C. Supprimer le bucket S3 du state

Réponses : 1‑B · 2‑C · 3‑B · 4‑B · 5‑B

Pour aller plus loin

Maillage série Terraform (P2)

← Contexte Overview · Install
Workflow Workflow init/plan/apply
State State & backend S3 + lock
Landing Terraform
Aussi Providers · Modules · Workspaces — même HCL, quel que soit le binaire plus tard

Meta publication (Rank Math / SEO) — HOLD

  • Title SEO : OpenTofu vs Terraform 2026 : licence MPL/BSL, migration, CI
  • Meta description (≤ 155) : OpenTofu vs Terraform 2026 : MPL vs BSL, compatibilité HCL/state/providers, migration douce et CI GitHub Actions. Guide FR neutre DEH.
  • Focus keyword : opentofu vs terraform
  • Slug : opentofu-vs-terraform-2026
  • Image mise en avant : assets/web/devopelastichayway/cover-opentofu-vs-terraform-2026-1200x630.webp (alt : OpenTofu vs Terraform 2026 — licence et compatibilité)
  • Catégorie : Terraform · Niveau : Intermédiaire
  • Statut publication : densifié P0 — publish page Tutoriels parent 5463

Sources vérifiées (2026-09-11) : blog HashiCorp BSL (2023-08-10), page licence BSL HashiCorp, docs OpenTofu (migration, registry, backend S3 / use_lockfile), marketplace opentofu/setup-opentofu. Releases mineures évolutives : revalidez la doc officielle avant cut-over prod.