OpenTofu a été créé il y a moins de trois ans en réponse au changement de licence de Terraform, mais il devient difficile de le définir simplement comme un fork ouvert. L’arrivée de OpenTofu 1.12 confirme que le projet conserve une compatibilité élevée avec Terraform tout en développant ses propres fonctionnalités telles que destroy = false, prevent_destroy dynamique ou le chiffrement des fichiers d’état et de planification. En conséquence, les équipes travaillant avec Infrastructure as Code (IaC) disposent désormais de deux chemins différenciés sur le plan technique, commercial et de gouvernance.

Les points clés d’OpenTofu 1.12 face à Terraform en 20 secondes

• OpenTofu a été lancé en 2023 suite au passage de HashiCorp de la licence MPL 2.0 à la Business Source License (BSL).
• Il est géré par la Linux Foundation et maintient une licence MPL 2.0.
• OpenTofu 1.12 intègre prevent_destroy dynamique et destroy = false.
• Il propose également un chiffrement natif des états et plans.
• Sa compatibilité avec Terraform réduit significativement le travail nécessaire pour tester une migration.

Pour un administrateur habitué à Terraform, la première chose qui surprend en installant OpenTofu est justement sa proximité :

Les fichiers .tf, le langage de configuration HashiCorp (HCL), les modules, les providers et une grande partie du flux de travail restent familiers. Là où l’on utilisait auparavant terraform init, terraform plan ou terraform apply, OpenTofu emploie tofu init, tofu plan et tofu apply.

Ce n’est pas un hasard. Le projet se présente comme un remplacement direct de Terraform et revendique actuellement un écosystème de plus de 3 900 providers et 23 600 modules. Cependant, la compatibilité ne signifie pas que les deux projets évolueront toujours de la même façon.

Pourquoi est né OpenTofu ?

Pour comprendre cette évolution, il faut revenir à août 2023.

Jusqu’alors, Terraform était distribué sous la licence libre Mozilla Public License 2.0 (MPL 2.0). HashiCorp a décidé de changer la licence de plusieurs de ses produits, y compris Terraform, pour adopter la Business Source License 1.1.

Terraform restait utilisable gratuitement dans de nombreux cas. HashiCorp précisait que l’utilisation interne au sein d’une organisation était autorisée, y compris pour gérer l’infrastructure via des processus d’intégration et de déploiement continus.

La modification concerne surtout certains usages commerciaux.

La licence limite l’emploi du logiciel pour créer des produits concurrents à ceux de HashiCorp, hébergés ou intégrés, par des tiers. Une simple description du changement comme « Terraform est devenu payant » serait incorrecte. La vraie question tourne autour des conditions dans lesquelles des tiers peuvent construire certains business avec leur code.

Il est utile aussi de distinguer cette évolution de l’acquisition ultérieure de HashiCorp par IBM, annoncée en avril 2024. Le changement de licence a été annoncé en août 2023, tandis que l’accord d’achat par IBM n’a été révélé que plus tard.

Une partie de la communauté a répondu en créant OpenTF, un fork basé sur la dernière version de Terraform sous MPL.

En septembre 2023, le projet a rejoint la Linux Foundation et a adopté le nom OpenTofu. Sa première version stable en production, OpenTofu 1.6, a été publiée en janvier 2024.

Depuis lors, les deux projets ont suivi des chemins distincts.

Terraform reste dans l’écosystème commercial de HashiCorp, actuellement propriété d’IBM, tandis qu’OpenTofu maintient une gouvernance communautaire sous la Linux Foundation et continue à être distribué sous MPL 2.0.

OpenTofu 1.12 intègre désormais des fonctionnalités propres

La compatibilité reste l’un de ses atouts majeurs, mais OpenTofu ne se limite plus à reproduire les fonctionnalités héritées de Terraform.

La version 1.12.0, publiée le 14 mai 2026, apporte plusieurs améliorations clés pour les administrateurs systèmes, les équipes DevOps et gestionnaires de plateformes.

Parmi elles, prevent_destroy dynamique.

Jusqu’à présent, cette protection impliquait une décision statique dans la configuration. Avec OpenTofu 1.12, il est possible d’utiliser des variables et autres valeurs dynamiques dans le module.

variable "prevent_destroy_database" {
  type    = bool
  default = true
}

resource "example_database" "database" {
  lifecycle {
    prevent_destroy = var.prevent_destroy_database
  }
}

Ce qui permet, par exemple, de créer un module unique pour les bases de données qui empêche la suppression en production par défaut, tout en autorisant la suppression en environnement de développement.

Cela permet à un même module d’adopter un comportement différent selon l’environnement sans avoir à maintenir plusieurs variantes.

Une autre fonctionnalité particulièrement pratique est :

destroy = false

Cette option modifie ce qui se passe lorsqu’OpenTofu cesse de gérer une ressource.

Normalement, la suppression d’une ressource dans la configuration peut entraîner la planification de sa suppression de l’infrastructure associée. Avec destroy = false, OpenTofu peut retirer l’objet de son état sans détruire la ressource réelle.

C’est une différence majeure.

La VM, la base de données, le volume ou la ressource cloud continue d’exister, mais OpenTofu ne la gère plus.

Cela peut être utile lors de migrations, réorganisations d’infrastructure ou dans des situations où certains éléments doivent sortir du contrôle de l’IaC sans être supprimés.

Attention cependant : une fois la ressource oubliée, OpenTofu ne la connaît plus. Si elle est réimportée plus tard avec la même adresse, il pourrait tenter de la recréer, ce qui nécessiterait peut-être de l’importer à nouveau.

OpenTofu 1.12 améliore également la gestion des checksums des providers, permet de générer simultanément des sorties lisibles et JSON via -json-into, et parallélise certaines requêtes lors de l’installation des providers pour accélérer tofu init.

Le chiffrement de l’état est une caractéristique particulièrement intéressante

L’une des capacités propres les plus importantes est arrivée avec OpenTofu 1.7 : Chiffrement de l’état et des plans.

L’état (state) est une pièce critique dans toute infrastructure gérée via Terraform ou OpenTofu.

Il peut contenir adresses IP, identifiants de ressources, configurations, voire des données sensibles selon la plateforme et la conception de l’infrastructure.

OpenTofu offre la possibilité de chiffrer ces fichiers, que ce soit en repos ou lors de leur stockage dans un backend compatible.

Il peut aussi utiliser le chiffrement avec terraform_remote_state.

Cependant, cette fonctionnalité ne remplace pas une gestion adéquate des permissions, secrets, ou la protection du backend. Perdre les clés de chiffrement peut rendre l’état impossible à récupérer.

Cela étant, l’intégration native du chiffrement dans l’outil constitue une couche supplémentaire qui peut être avantageuse pour les organisations aux exigences strictes en matière de sécurité.

OpenTofu vs Terraform : les principales différences en 2026

Bien qu’ayant une origine commune, la comparaison commence à révéler deux philosophies distinctes.

Ce tableau ne doit pas faire penser qu’OpenTofu est automatiquement supérieur.

Terraform conserve une immense base installée, une documentation riche, une expérience accumulée, ainsi que des intégrations d’entreprise et une plateforme commerciale développées par HashiCorp au fil des années.

De plus, IBM a finalisé l’acquisition de HashiCorp en 2025, ce qui rend Terraform partie intégrante d’un groupe technologique avec une forte présence commerciale.

OpenTofu, quant à lui, se positionne différemment : compatibilité, licence ouverte, gouvernance indépendante de tout constructeur unique.

La migration chez Fidelity montre que ce n’est plus réservé aux laboratoires

L’un des exemples illustrant la maturité d’OpenTofu provient de Fidelity Investments.

L’organisation a expliqué son expérience dans une interview publiée par OpenTofu.

Les chiffres de leur infrastructure donnent une idée :

Fidelity a expliqué que le changement de licence de Terraform a lancé une réflexion interne sur les alternatives et que la gouvernance ouverte d’OpenTofu correspondait à leur stratégie.

Une condition essentielle était la compatibilité technique.

Migrer une organisation avec des millions de ressources serait beaucoup plus complexe si cela impliquait de tout réécrire. Fidelity a souligné que considérer OpenTofu comme un remplaçant technique direct rendait la migration envisageable.

Cela ne signifie pas que toutes les entreprises doivent migrer, mais cela démontre que l’idée qu’OpenTofu est seulement une alternative expérimentale pour les passionnés open source n’est plus valable.

OpenTofu est-il vraiment compatible avec Terraform ?

En pratique, la compatibilité reste très élevée, notamment pour les configurations classiques.

Un projet existant peut être testé avec :

tofu init
tofu plan

avant toute modification.

Mais « remplacement « prêt à l’emploi » n’est pas une garantie de compatibilité à vie.

Depuis le fork, chaque projet implémente ses propres fonctionnalités. Plus une infrastructure utilise de fonctionnalités exclusives ou de versions avancées, plus la divergence peut augmenter avec le temps.

C’est pourquoi une migration en entreprise doit examiner au moins :

• version de Terraform utilisée ;
• proveurs et versions ;
• modules internes et externes ;
• backend de l’état ;
• automatisations CI/CD ;
• Terraform Cloud / HCP Terraform ;
• fonctions spécifiques utilisées ;
• outils externes dépendants du CLI ou de ses sorties.

Pour les projets s’appuyant principalement sur Terraform CLI, HCL, providers classiques et backends standards, le passage à OpenTofu peut être assez simple.

Une entreprise fortement intégrée à HCP Terraform ou à d’autres produits HashiCorp aura davantage d’éléments à analyser.

Alors, Terraform ou OpenTofu ?

Il n’y a pas de réponse universelle.

Terraform reste pertinent pour les organisations déjà standardisées sur HashiCorp, notamment si elles utilisent HCP Terraform et apprécient une plateforme d’entreprise intégrée, un support commercial et un écosystème mature.

OpenTofu est particulièrement attractif lorsque la priorité est de maintenir la couche Infrastructure as Code sous une licence open source, de réduire la dépendance à un fournisseur unique ou de bénéficier de fonctionnalités propres comme le chiffrement de l’état.

Il existe aussi une troisième situation fréquente : les entreprises qui n’ont pas besoin de prendre une décision immédiate.

Une organisation peut continuer à utiliser Terraform pour son infrastructure existante et commencer à tester OpenTofu sur de nouveaux projets ou dans des laboratoires. Sa compatibilité élevée facilite les essais sans obligation de migration immédiate.

C’est probablement l’un des plus grands succès d’OpenTofu.

En 2023, la question était de savoir si une communauté serait capable de maintenir un fork viable de Terraform. En 2026, il s’agit de déterminer quelle solution correspond le mieux à chaque stratégie d’Infrastructure as Code.

Terraform demeure l’un des standards majeurs de l’IaC et bénéficie désormais du soutien d’IBM. OpenTofu a su construire une alternative gouvernée par la Linux Foundation, reposant sur une expérience connue et en train d’intégrer ses propres capacités.

La compétition ne consiste plus forcément à ce qu’un remplace l’autre. Le fait d’avoir deux projets avec des modes de gouvernance et d’évolution différents offre aux administrateurs, équipes DevOps et responsables de plateforme une véritable liberté de choix, rare dans ce domaine depuis de nombreuses années.

Questions fréquentes

Qu’est-ce qu’OpenTofu ?

OpenTofu est un outil open source d’Infrastructure as Code, initialement issu d’un fork de Terraform. Il est géré par la Linux Foundation, utilise la licence MPL 2.0 et maintient une compatibilité élevée avec les configurations et providers de l’écosystème Terraform.

OpenTofu peut-il utiliser les fichiers Terraform ?

Dans de nombreux projets, oui. OpenTofu conserve une compatibilité avec HCL, les modules et une grande partie des providers. Cependant, une migration doit être testée avant déploiement en production, notamment lorsqu’il existe des intégrations spécifiques avec des produits HashiCorp.

Terraform reste-t-il gratuit ?

Oui, pour de nombreux usages. HashiCorp autorise explicitement l’utilisation interne sous la licence Business Source License. Les restrictions concernent surtout certains produits commerciaux qui proposent Terraform hébergé ou intégré, en concurrence avec l’offre payante de HashiCorp.

Quelles nouveautés pour OpenTofu 1.12 ?

Parmi ses principales nouveautés : prevent_destroy dynamique, destroy = false, améliorations des checksums, installation de providers, et génération simultanée de sorties humaines et JSON. OpenTofu inclut aussi le chiffrement natif des fichiers d’état et de plan depuis ses premières versions.