OpenTofu vs Terraform en 2026 : faut-il vraiment migrer ?

OpenTofu vs Terraform en 2026 : faut-il vraiment migrer ? — illustration Ctrl+Alt+Prod (OpenTofu Terraform)

Depuis que HashiCorp a fait basculer Terraform sous licence BSL fin 2023, puis a été racheté par IBM début 2025, la question revient régulièrement en équipe infra : est-ce qu’on migre vers OpenTofu, le fork open source ? Trois ans après le fork, le projet a mûri, gagné des fonctionnalités que Terraform n’a pas, et l’adoption progresse — mais pas de façon uniforme. Voici où en sont vraiment les choses en 2026, sans survendre, pour t’aider à trancher sereinement.

Pourquoi ce fork existe (rappel rapide)

La licence Business Source License (BSL) 1.1 adoptée par HashiCorp restreint l’usage commercial de Terraform pour tout produit qui viendrait concurrencer directement les offres HashiCorp (Terraform Cloud, Terraform Enterprise). En réaction, la Linux Foundation a lancé OpenTofu, un fork sous licence réellement open source (Mozilla Public License 2.0), porté par une communauté incluant des poids lourds comme Gruntwork, Spacelift, Scalr, Harness ou env0. Le code source complet est disponible sur le dépôt GitHub officiel du projet. Le rachat de HashiCorp par IBM début 2025 a accéléré le mouvement : plusieurs plateformes majeures, dont GitLab, ont depuis fait d’OpenTofu leur moteur recommandé par défaut pour éliminer toute dépendance à un éditeur propriétaire unique.

Où en est l’adoption, vraiment, en 2026 ?

C’est là qu’il faut être honnête plutôt que de reprendre les chiffres les plus flatteurs. Il existe en réalité trois niveaux de lecture bien différents :

  • Sur des plateformes qui ont fait le choix éditorial de pousser OpenTofu par défaut, comme le montre l’analyse de Scalr, la bascule est massive : environ 63 % des exécutions compatibles Terraform tournent désormais sous OpenTofu sur leur plateforme, et jusqu’à 72 % des nouveaux espaces de travail créés.
  • À l’échelle du marché global, les études indépendantes (CodeOxi, avril 2026) situent l’adoption d’OpenTofu autour de 12 % — un chiffre bien plus modeste.
  • Et surtout, le nombre d’organisations ayant réellement terminé une migration complète reste faible, de l’ordre de 5 % selon une étude Firefly.

Autrement dit : beaucoup d’équipes testent, certaines plateformes poussent fort dans cette direction, mais la migration effective en production reste encore minoritaire. Ce n’est pas une raison pour l’ignorer — c’est une raison de l’évaluer avec les bons critères plutôt que par effet de mode.

Les vrais avantages techniques d’OpenTofu aujourd’hui

Indépendamment du débat de licence, OpenTofu a ajouté plusieurs fonctionnalités concrètes que Terraform n’a pas (ou pas encore) :

  • Chiffrement natif de l’état (depuis la v1.7) : le fichier .tfstate peut être chiffré nativement, sans dépendre d’un backend spécifique déjà chiffré côté stockage.
  • Itération de providers avec for_each : tu peux désormais configurer plusieurs instances d’un même provider dynamiquement, utile pour du multi-région ou multi-compte géré en boucle.
  • Le flag -exclude sur plan/apply, pour exclure précisément certaines ressources d’une exécution — le complément logique du -target déjà existant.
  • Support des registres OCI pour distribuer modules et providers, ce qui te permet de réutiliser l’infrastructure de registre de conteneurs que tu as probablement déjà (Azure Container Registry, par exemple).
  • Verrouillage d’état S3 natif, sans dépendance à une table DynamoDB séparée — une simplification bienvenue si ton backend est S3-compatible.

Exemple de bloc de chiffrement d’état, une fonctionnalité qui n’existe pas nativement côté Terraform :

terraform {
  encryption {
    key_provider "pbkdf2" "monkey" {
      passphrase = var.state_encryption_passphrase
    }
    method "aes_gcm" "monmethode" {
      keys = key_provider.pbkdf2.monkey
    }
    state {
      method = method.aes_gcm.monmethode
    }
  }
}

Et côté Azure ? La compatibilité avec les Azure Verified Modules

Si tu déploies sur Azure, tu utilises probablement déjà (ou tu devrais) les Azure Verified Modules (AVM), les modules IaC officiels maintenus par Microsoft pour Bicep et Terraform. Ces modules sont testés et « vérifiés » spécifiquement pour Terraform — pas explicitement pour OpenTofu. Dans la pratique, grâce à la compatibilité de syntaxe HCL et de format d’état, la très grande majorité des modules AVM Terraform fonctionnent tels quels sous OpenTofu. Mais comme ce n’est pas une garantie officielle de Microsoft, teste systématiquement en environnement non-critique avant de généraliser, surtout sur les modules qui utilisent des fonctionnalités provider récentes.

Faut-il migrer ? Une grille de décision simple

  • Tu es en infrastructure auto-hébergée, sensible aux coûts de licence, et tu veux éliminer toute dépendance à un éditeur unique : OpenTofu a du sens.
  • Tu utilises fortement Terraform Cloud/Enterprise ou l’intégration HCP : le bénéfice immédiat est plus faible, sauf si tu prévois justement de t’en détacher.
  • Tu débutes un nouveau projet : c’est le moment le plus simple pour trancher, sans dette de migration à gérer.

Bonne nouvelle technique : la migration reste globalement peu douloureuse. Le format d’état est compatible, la syntaxe HCL ne change pas, et le binaire tofu se comporte comme un remplacement quasi direct de terraform dans la plupart des pipelines CI/CD.

FAQ

OpenTofu est-il 100 % compatible avec mes fichiers Terraform existants ?

Dans l’immense majorité des cas, oui — la syntaxe HCL et le format d’état sont compatibles. Les divergences apparaissent surtout sur les fonctionnalités ajoutées après le fork (chiffrement d’état, registres OCI), qui n’ont pas d’équivalent côté Terraform.

Puis-je utiliser des providers Terraform officiels avec OpenTofu ?

Oui, OpenTofu reste compatible avec le protocole de providers Terraform : tu continues à utiliser les providers du registre public sans modification.

Terraform va-t-il disparaître ?

Rien ne l’indique. Terraform reste largement utilisé et activement développé par HashiCorp/IBM. La question n’est pas « lequel va survivre » mais « lequel correspond le mieux à tes contraintes de licence et à ton besoin d’indépendance vis-à-vis d’un éditeur ».

Si le choix de l’outil IaC en général te travaille encore, notre comparatif Terraform ou Bicep en 2026 complète bien cette réflexion côté Azure, et notre guide de migration vers AzureRM 5.0 reste valable que tu restes sur Terraform ou que tu passes à OpenTofu, puisque le provider ne change pas.

Commentaires

3 réponses à « OpenTofu vs Terraform en 2026 : faut-il vraiment migrer ? »

  1. […] La 1.17 est déjà en alpha (build 1.17.0-alpha20260827), donc ne t’étonne pas de voir passer de nouvelles fonctions dans les prochains mois. Si tu es en train de te demander s’il faut rester sur Terraform ou passer à OpenTofu, j’ai fait le point dans OpenTofu vs Terraform en 2026. […]

  2. […] de basculer ta gouvernance de prod sur un outil encore en bêta. OpenTofu, pour rappel, n’a pas d’équivalent annoncé à ce jour — un point à peser si la gouvernance par policy fait partie de tes critères de choix […]

  3. […] avait déjà creusé la question du choix entre les deux outils dans notre comparatif OpenTofu vs Terraform en 2026, à l’époque surtout sous l’angle licence et écosystème de providers. Un an plus […]

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *