OpenTofu expliqué : le fork de Terraform, la migration et faut-il changer

Ouvrez un module Terraform aujourd'hui et vous êtes face à une question qui n'existait pas il y a trois ans : le binaire qui exécute ce code est-il terraform, ou bien tofu? IBM a finalisé son acquisition de HashiCorp le 27 février 2025, pour 6,4 milliards de dollars, OpenTofu est devenu un projet CNCF Sandbox le 23 avril 2025, et le chemin de migration entre les deux outils est désormais documenté officiellement. La décision n'est plus hypothétique.

Cet article est écrit du point de vue des opérations d'infrastructure, pas de celui d'une plateforme Terraform managée. L'objectif est de distinguer les vrais coûts de migration du bruit lié à la licence et à la gouvernance. Cela me permet d'être direct sur ce qui casse pendant la migration, sur les vraies questions de gouvernance, et sur les cas où rester sur Terraform est le bon choix.

Cet article couvre quatre points : ce qu'est OpenTofu en 2026, les fonctionnalités que Terraform n'a pas, à quoi ressemble la migration en pratique, et une recommandation claire pour les cas de décision les plus courants.

La version courte

• OpenTofu est un fork open source de Terraform, sous licence MPL 2.0, hébergé par la Linux Foundation, et projet CNCF Sandbox depuis le 23 avril 2025. Il a été forké depuis Terraform 1.5.x après le passage de Terraform à la Business Source License en août 2023.
• Au 26 juillet 2026, la version de maintenance actuelle est v1.12.5; le dépôt GitHub compte plus de 29 000 étoiles, et le site officiel du projet OpenTofu recense plus de 3 900 providers et plus de 23 600 modules.
• Il embarque des capacités exclusives à OpenTofu ou dans lesquelles OpenTofu est en avance, que Terraform n'égale pas actuellement de la même façon : le chiffrement côté client du state et des plans, le provider for_each, l'évaluation anticipée des variables, le méta-argument enabled et dynamique prevent_destroy. Les ressources éphémères ne sont pas exclusives à OpenTofu ; Terraform les prend en charge depuis la 1.10.
• Pour un petit projet Terraform 1.5.x avec un state local ou S3, le chemin simple peut être une migration courte et réversible. Ce sont les références CI/CD, les workflows spécifiques à HCP et les changements du fichier de verrouillage des dépendances qui font gonfler le travail.
• Pour un nouveau projet IaC en 2026, commencez avec OpenTofu. Pour un déploiement Terraform existant, basculez quand la BSL vous freine, quand vous avez besoin d'une fonctionnalité qu'OpenTofu a et que Terraform n'a pas, ou quand la feuille de route détenue par IBM est une réelle préoccupation. Sinon, le rapport coût-bénéfice reste faible.

Ce qu'est OpenTofu en 2026

OpenTofu est un fork open source de Terraform, hébergé par la Linux Foundation, accepté au sein de la CNCF en tant que projet Sandbox le 23 avril 2025, et distribué sous licence Mozilla Public License 2.0. Le binaire est tofu. Le langage de configuration est HCL, le même HCL que celui utilisé par Terraform. Pour la plupart des projets simples à moyens, une base de code Terraform existante s'exécute sans modification sur OpenTofu.

Le fork a débuté en août 2023, après le passage de Terraform par HashiCorp de la MPL 2.0 vers la Business Source License 1.1 le 10 août 2023. La BSL est "source-available" plutôt qu'approuvée par l'OSI, et restreint l'usage en production qui "concurrence les offres commerciales de HashiCorp". Cinq jours plus tard, l'OpenTF Manifesto était publié et un fork était annoncé. L'annonce de la Linux Foundation a officiellement présenté OpenTofu le 20 septembre 2023.

L'annonce de la Linux Foundation citait Harness, Gruntwork, Spacelift, env0, Scalr, Digger, Terrateam, Massdriver et Terramate parmi les soutiens fondateurs, avec au moins 18 ingénieurs engagés à temps plein pour un minimum de cinq ans. OpenTofu a été forké depuis Terraform 1.5.x, la dernière version sous MPL 2.0.

Où en est le projet aujourd'hui : v1.12.5 est la version de maintenance actuelle, et le site officiel recense plus de 3 900 providers et plus de 23 600 modules. Les signaux d'adoption ne se limitent plus à l'élan initial du fork contestataire : une étude de cas sur la migration de Fidelity décrit un programme portant sur plus de 50 000 fichiers state et quatre millions de ressources.

Le contexte commercial pertinent : IBM a finalisé son acquisition de HashiCorp le 27 février 2025, pour 6,4 milliards de dollars. La feuille de route de Terraform est désormais définie au sein d'un éditeur bien plus grand. Ce n'est pas automatiquement bon ou mauvais pour les utilisateurs, mais cela fait partie du calcul que font les équipes en 2026.

En quoi OpenTofu diffère de Terraform

Depuis le fork, les deux projets ont suivi des trajectoires de fonctionnalités différentes. Le tableau ci-dessous en est la version courte ; les notes qui suivent expliquent ce que chaque différence change concrètement pour les praticiens.

Le chiffrement côté client du state (v1.7.0, 30 avril 2024). OpenTofu peut chiffrer les fichiers de state et de plan directement dans l'outil avec PBKDF2, AWS KMS, GCP KMS ou OpenBao. Terraform délègue en général le chiffrement au repos au backend choisi, tandis que le state local reste en clair. Le chiffrement côté client d'OpenTofu peut protéger un objet state volé ou un plan mis en cache, à condition que la clé de déchiffrement ne soit pas exposée avec lui. Il ne remplace ni TLS, ni les contrôles d'accès du backend, ni la discipline de gestion des secrets.

La configuration ressemble à peu près à ceci :

terraform {
  encryption {
    key_provider "pbkdf2" "passphrase" {
      passphrase = var.tofu_state_passphrase
    }
    method "aes_gcm" "default" {
      keys = key_provider.pbkdf2.passphrase
    }
    state {
      method = method.aes_gcm.default
    }
  }
}

Fournisseur for_each (v1.9). Vous pouvez itérer sur les configurations de provider comme vous itérez sur des ressources. Pour les configurations multi-régions ou multi-comptes, cela élimine toute une classe de contournements qui traînait depuis longtemps. Vous n'avez plus besoin de créer à la main un provider aliasé par région ; un seul bloc piloté par une map suffit.

Évaluation anticipée des variables (v1.8). Les variables peuvent désormais être référencées à des endroits auparavant restreints, y compris dans les arguments de backend et de source de module. C'est utile quand un module racine unique pilote plusieurs environnements qui ne diffèrent que par un petit nombre de variables.

Les ressources éphémères et le enabled méta-argument (v1.11.0, 9 décembre 2025). OpenTofu 1.11 a ajouté les ressources éphémères et le méta-argument enabled . Les ressources éphémères n'existent que le temps d'un seul cycle plan/apply et ne persistent pas dans le state, ce qui est utile pour les identifiants de courte durée. Elles ne sont pas exclusives à OpenTofu : Terraform les a introduites en 1.10 et a ajouté les arguments write-only en 1.11. La capacité propre à OpenTofu ici est enabled, qui permet d'activer ou désactiver un bloc de ressource à partir d'une expression, sans recourir à la gymnastique du count conditionnel.

Dynamique prevent_destroy (v1.12). de Terraform prevent_destroy n'accepte que des valeurs littérales. OpenTofu 1.12 permet de le calculer, de sorte qu'un même module peut laisser staging destructible tout en protégeant la production.

La ligne sur la licence est la différence structurelle qui n'apparaît pas comme une fonctionnalité. La MPL 2.0 est approuvée par l'OSI et copyleft au niveau du fichier. La licence BSL 1.1 de Terraform est "source-available", inclut une restriction d'usage supplémentaire, et bascule vers la MPL 2.0 quatre ans après la publication de chaque œuvre concernée. Pour la plupart des équipes, l'effet pratique est minime ; pour les éditeurs qui construisent quelque chose de proche des offres commerciales de HashiCorp, c'est la raison même pour laquelle le fork existe.

Migration : ce qui casse réellement

Le guide de migration officiel est volontairement court et réversible : sauvegardez le state et le code, installez OpenTofu, exécutez tofu init, comparez le résultat de tofu plan, et testez un petit changement. Les parties difficiles ne sont pas les commandes. Ce sont les références CI/CD environnantes, les workflows spécifiques à HCP, les changements du fichier de verrouillage des dépendances, et la revue organisationnelle qui accompagne l'adoption d'un fork.

Le chemin simple

Pour un projet qui n'utilise pas HCP Terraform et qui n'a pas des milliers de références à terraform dans ses pipelines, la migration est simple.

# Back up state first, non-negotiable.
cp terraform.tfstate terraform.tfstate.bak

# Install OpenTofu (Linux example).
curl --proto '=https' --tlsv1.2 -fsSL \
  https://get.opentofu.org/install-opentofu.sh | sh -s -- --install-method standalone

# Re-initialize against the OpenTofu registry.
tofu init -upgrade

# Verify parity with what Terraform was doing.
tofu plan

tofu plan devrait correspondre au plan produit par Terraform. En cas de diff inattendu, vérifiez les versions des providers, les paramètres de backend et toute fonctionnalité Terraform postérieure à la 1.5.x avant d'appliquer.

Deux nuances comptent avant d'exécuter quoi que ce soit. D'abord, OpenTofu est globalement compatible en configuration avec le HCL de style Terraform pour les cas décrits dans ce guide, mais les fonctionnalités ajoutées après Terraform 1.5.x nécessitent tout de même une vérification de compatibilité. Ensuite, tofu init -upgrade peut mettre à jour .terraform.lock.hcl, y compris les adresses source des providers et les entrées de checksum. Passez en revue ces métadonnées séparément de la dérive d'infrastructure.

Les vrais obstacles

Trois éléments peuvent transformer une migration CLI rapide en un projet de plateforme bien plus vaste. Aucun d'eux n'est un bug.

Les workspaces HCP Terraform. OpenTofu inclut des intégrations cloud et remote pour les services remote compatibles, y compris HCP Terraform dans des scénarios d'exécution locale et de stockage du state. La partie la plus difficile concerne l'exécution remote spécifique à HCP et les fonctionnalités de plateforme : Sentinel, les run triggers, les identifiants dynamiques, Stacks, et tout comportement de service qu'OpenTofu ne peut pas entièrement tester ou prendre en charge. Si ces éléments sont centraux, pilotez d'abord un seul workspace ; si vous quittez HCP, migrez le state et recréez ces contrôles de plateforme.

Astuce : quitter HCP Terraform peut représenter le coût caché le plus important lorsque le parc dépend de workflows spécifiques à HCP. Avant de décider, exécutez terraform state pull > state.json et examinez la taille ainsi que le nombre de ressources. Un workspace avec 200 ressources est un projet bien différent d'un parc de 50 workspaces avec des run triggers et des policy sets. Ce second cas est une migration de platform engineering, pas un simple changement d'outil.

Les pipelines CI/CD codés en dur pour terraform. Chaque référence à terraform plan, terraform apply, au chemin du binaire, à l'image Docker, et à l'étape GitHub Actions ou GitLab CI doit être revue. Pour GitHub Actions, le remplacement ressemble à peu près à ceci :

# Before
- name: Setup Terraform
  uses: hashicorp/setup-terraform@v3
  with:
    terraform_version: 1.5.7

- run: terraform init
- run: terraform plan

# After
- name: Setup OpenTofu
  uses: opentofu/setup-opentofu@v2
  with:
    tofu_version: 1.12.5

- run: tofu init
- run: tofu plan

C'est le cas trivial : un workflow, un dépôt. Dans un monorepo avec des composite actions partagées, plusieurs pipelines et une bibliothèque de workflows réutilisables, la surface de revue est bien plus large. Le travail est mécanique, mais peut prendre plus de temps que le simple changement de CLI.

Revue du fichier de verrouillage des dépendances. tofu init peut mettre à jour .terraform.lock.hcl, y compris les adresses source des providers et les entrées de checksum. OpenTofu 1.12 peut aussi ajouter des jeux complets de checksums h1: . Traitez le diff comme des métadonnées de dépendances à examiner et committer séparément, pas comme une dérive d'infrastructure.

Astuce : le diff du fichier de verrouillage peut sembler bruyant lors du premier commit. Exécutez tofu init -upgrade sur une branche propre, ne validez que le fichier de verrouillage avec un message clair du type « revoir les changements du fichier de verrouillage OpenTofu », puis rebasez le travail de fonctionnalité par-dessus. Mélanger les métadonnées de dépendances dans une PR de fonctionnalité rend les deux changements plus difficiles à relire.

La résistance des parties prenantes. « Nous utilisons désormais un fork » n'est pas reçu de la même façon dans toutes les organisations. La réponse honnête est qu'OpenTofu reste globalement compatible en configuration avec le HCL de style Terraform pour les cas décrits dans ce guide, donc le changement est généralement réversible. Si OpenTofu disparaissait demain, de nombreuses équipes pourraient réinstaller Terraform, revoir le fichier de verrouillage, et continuer à utiliser les mêmes .tf fichiers .tf. Validez d'abord les fonctionnalités post-fork ; cette réserve est plus crédible que de promettre une interchangeabilité parfaite.

Quand la migration est réellement difficile

Ce chemin simple ne s'applique pas à tous les parcs Terraform.

La migration devient nettement plus difficile quand :

• Le state est volumineux (des milliers de ressources, des dizaines de workspaces) et vit dans HCP Terraform.
• La base de code utilise en profondeur des fonctionnalités exclusives à HCP : des policies Sentinel intégrées aux workspaces, des run triggers, des identifiants de provider dynamiques gérés par HCP. Terraform Stacks est exclusif à HCP et n'a aucun équivalent chez OpenTofu, ce qui est hors sujet ici.
• Un audit d'entreprise ou un référentiel de conformité désigne nommément « Terraform » comme l'outil IaC de référence, ce qui ajoute un problème d'achats et de documentation au problème technique.
• Une bibliothèque de modules volumineuse comporte des contraintes de version internes qui se résolvaient en s'appuyant sur un comportement de registry propre à Terraform.

Toutes les équipes ne devraient pas migrer. Le rapport coût-bénéfice n'a de sens que si les restrictions de la BSL affectent réellement votre cas d'usage, si une fonctionnalité précise d'OpenTofu débloque quelque chose de concret, ou si la feuille de route contrôlée par IBM est une réelle préoccupation pour votre organisation. Si rien de tout cela ne s'applique, rester sur Terraform est un choix parfaitement défendable.

Faut-il changer ?

Il n'y a pas de réponse unique ici. Quand je dessine l'arbre de décision pour une équipe, quatre cas de figure reviennent souvent, et le bon choix dépend de celui dans lequel vous vous trouvez.

Nouvelle adoption de l'IaC (greenfield). Commencez avec OpenTofu. La licence est la MPL 2.0, la gouvernance relève de la Linux Foundation et de la CNCF, et le projet a un rythme de publication actif. Ses éléments différenciateurs incluent le chiffrement du state côté client, provider for_each, enabled, et prevent_destroy. Il n'y a aucune friction liée à la BSL à anticiper. C'est la recommandation la plus forte de cet article.

Utilisateur Terraform existant, projet petit à moyen. Basculez si l'un de ces trois déclencheurs se produit. Un : vous vendez ou pourriez vendre un produit susceptible d'être visé par la clause d'exclusion « concurrence HashiCorp » de la BSL ; le calcul juridique est plus clair avec la MPL 2.0. Deux : vous avez besoin du chiffrement du state côté client, provider for_each, enabled, ou prevent_destroy , et que le contournement Terraform ne vaut plus la peine d'être maintenu. Trois : vous préférez une gouvernance multipartite à une feuille de route contrôlée par un seul éditeur. Si rien de tout cela ne s'applique et que Terraform fonctionne proprement, restez. La migration est réversible dans de nombreux parcs, mais pas gratuite.

Utilisateur intensif de HCP Terraform. Considérez cela comme une décision de plateforme, pas automatiquement comme une simple migration de backend. OpenTofu peut utiliser des backends remote compatibles, mais l'exécution remote spécifique à HCP, Sentinel, les run triggers, les identifiants dynamiques et Stacks nécessitent encore une évaluation fonctionnalité par fonctionnalité. Si ces contrôles sont centraux, pilotez d'abord. Si vous quittez HCP pour des raisons de licence, de coût ou de gouvernance, planifiez le travail comme une migration de plateforme.

Vous envisagez Pulumi ou une autre alternative non-HCL. OpenTofu est le chemin le plus proche si vous voulez conserver HCL et la plupart de vos workflows existants. Pulumi est un choix de plateforme et de langage plus large : TypeScript, Python, Go ou .NET pilotant des API cloud. Y migrer peut impliquer une conversion ou une réécriture, évaluez-le donc séparément d'un simple changement de binaire Terraform vers OpenTofu.

Un dernier point mérite d'être abordé directement : la critique légitime selon laquelle OpenTofu serait en partie une couverture pour des éditeurs SaaS. Un fil Hacker News sur le changement de la BSL a fait remonter la préoccupation que les membres fondateurs du projet sont des plateformes Terraform commerciales ayant leur propre motivation de flexibilité de licence. Je prends cette préoccupation au sérieux. L'atténuation vient de la structure de gouvernance, de l'hébergement par la Linux Foundation, du statut CNCF Sandbox, de la MPL 2.0 sur chaque fichier, ce qui rend un futur changement de licence bien plus difficile qu'il ne l'a été pour un seul éditeur. Cela ne le rend pas impossible. Mais cela le rend assez coûteux pour constituer un véritable garde-fou.

Verdict rapide. Pour tout nouveau projet IaC en 2026, commencez avec OpenTofu. Sa licence, sa gouvernance, son développement actif et son ensemble de fonctionnalités en font un choix par défaut solide. Pour les déploiements Terraform existants, basculez quand l'un des trois déclencheurs ci-dessus s'applique ; sinon, le rapport coût-bénéfice reste faible et rester en place convient très bien.

Une fois le choix de l'outil clarifié, la question pratique suivante est de savoir où OpenTofu doit s'exécuter. Cette décision affecte la gestion des secrets, le coût, la répétabilité, et le niveau de contrôle de votre équipe sur l'environnement d'exécution.

Exécuter OpenTofu vous-même

OpenTofu est un binaire en ligne de commande. L'endroit où vous l'exécutez détermine en grande partie le coût, la sécurité et ce que vous pouvez en faire. Il y a globalement trois emplacements raisonnables où le placer.

Ordinateur portable ou machine de développement. Convient pour des plans ponctuels, du prototypage et de petits projets personnels. C'est un mauvais choix par défaut pour des workflows de production partagés, sauf si le state remote, le verrouillage et la discipline de revue sont déjà appliqués. Les équipes bénéficient généralement d'un environnement d'exécution canonique plutôt que de dépendre du dernier ordinateur portable ayant exécuté tofu apply.

Runner CI managé (GitHub Actions, GitLab CI, etc.). Le chemin le plus courant. L' opentofu/setup-opentofu action est un remplacement direct de hashicorp/setup-terraform. Cela fonctionne bien pour la plupart des équipes et des projets. Compromis : les secrets transitent par un service CI tiers, les minutes du plan gratuit peuvent s'épuiser sur de grosses opérations de state, et l'environnement du runner est éphémère, ce qui est généralement un atout mais parfois une contrainte. Voir GitHub vs GitLab si vous hésitez encore entre plusieurs options de CI hébergées, et Best CI/CD Tools pour une vue d'ensemble plus large.

Runner auto-hébergé sur un VPS. Utile quand les compromis d'un CI managé ne fonctionnent plus : les secrets doivent rester hors d'un service tiers, les minutes de CI deviennent coûteuses, ou vous voulez des caches de providers persistants. La mise en place est simple : un VPS Linux, le binaire OpenTofu, un agent GitHub Actions ou GitLab Runner, et Docker pour l'isolation des jobs. Voir Install Docker on VPS si cette partie est nouvelle pour vous. Pour un runner d'une petite équipe, 4 Go de RAM, 2 vCPU et 60 Go de NVMe constituent un point de départ raisonnable ; augmentez le CPU, la mémoire et le stockage pour des plans plus lourds et une concurrence plus élevée.

Pour les équipes qui ont besoin d'un contrôle plus strict sur les secrets du runner, de caches de providers persistants, ou de coûts CI prévisibles, un runner auto-hébergé sur un VPS peut avoir du sens. Dans cette configuration, privilégiez l'accès root, un stockage NVMe rapide, un redimensionnement facile, et suffisamment de CPU/RAM pour les grandes opérations de plan.

VPS Linux Cloudzy correspondent bien à ce modèle de runner auto-hébergé, avec accès root, stockage NVMe et dimensionnement flexible, pour démarrer petit et faire évoluer le runner à mesure que vos charges OpenTofu croissent.

Foire aux questions

OpenTofu est-il identique à Terraform ?

Pas tout à fait. OpenTofu a démarré comme un fork de Terraform 1.5.x et reste globalement compatible en configuration avec le HCL de style Terraform : les mêmes .tf fichiers, les mêmes providers, et le même workflow plan/apply pour de nombreux projets. Ils diffèrent par la licence et par les fonctionnalités ajoutées après le fork. OpenTofu dispose du chiffrement du state côté client, provider for_each, enabled, et prevent_destroy ; Terraform a ses propres fonctionnalités post-fork, y compris les ressources éphémères.

OpenTofu prendra-t-il en charge tous mes providers Terraform ?

Pour les principaux providers comme AWS, GCP, Azure, Kubernetes et Helm, généralement oui. Le OpenTofu Registry recense plus de 3 900 providers en date de juillet 2026. tofu init peut mettre à jour .terraform.lock.hcl peut mettre à jour les métadonnées. Pour les providers de niche, propres à un éditeur, ou récemment publiés, vérifiez directement la disponibilité et la prise en charge des versions avant de basculer.

OpenTofu elle-même pourrait-elle un jour changer de licence ?

Un futur changement de licence est plus difficile qu'il ne l'a été pour Terraform, mais pas impossible. OpenTofu est sous MPL 2.0, hébergé par la Linux Foundation, et projet CNCF Sandbox depuis le 23 avril 2025. La gouvernance est multipartite et la licence est approuvée par l'OSI. Un changement de licence unilatéral par un seul fondateur entrerait en conflit avec la charte de la fondation et avec les contributions existantes sous MPL 2.0, qu'il faudrait retirer ou réécrire. La préoccupation est légitime ; les barrières structurelles sont réelles.

Que signifie l'acquisition de HashiCorp par IBM pour l'avenir de Terraform ?

IBM a finalisé l'acquisition de HashiCorp le 27 février 2025, pour 6,4 milliards de dollars. La feuille de route de Terraform se trouve désormais au sein d'un éditeur d'entreprise plus large. L'acquisition seule ne préjuge en rien de l'orientation future en matière de licence ou de produit ; évaluez les notes de version actuelles, les orientations de licence et les évolutions des produits HCP plutôt que de traiter la propriété comme une prédiction.

OpenTofu est-il prêt pour la production en 2026 ?

Oui. v1.12.5 est la version de maintenance actuelle, le projet est dans le CNCF Sandbox, et Fidelity a décrit une adoption en production sur un parc IaC de plus de 50 000 fichiers state et quatre millions de ressources. Prêt pour la production ne signifie pas identique en fonctionnalités : les équipes qui dépendent de capacités exclusives à HCP comme Terraform Stacks ont encore besoin d'une décision de compatibilité distincte.