La BSL n’est pas une licence open source au sens de l’Open Source Initiative : elle restreint les usages commerciaux jugés concurrents des offres HashiCorp. Du jour au lendemain, des milliers d’organisations qui avaient structuré leur infrastructure autour de Terraform se sont retrouvées dans une zone d’incertitude juridique inconfortable.
La réponse n’a pas tardé. Moins d’un mois après l’annonce, un manifeste réclamant le retour à une licence open source avait réuni 33 000 étoiles sur GitHub et le soutien de près de 140 entreprises. HashiCorp n’a pas bougé. Le fork a été publié en septembre 2023, intégré à la Linux Foundation, et renommé OpenTofu. Depuis janvier 2024, il est en production stable. Depuis avril 2025, il fait partie du Cloud Native Computing Foundation (CNCF).
Notre provider Terraform est entièrement compatible avec OpenTofu. Aucune modification de vos configurations n’est nécessaire pour l’utiliser.
Qu’est-ce qu’OpenTofu ?
OpenTofu est un outil d’infrastructure as code (IaC) open source, fork du dernier Terraform sous licence MPL 2.0 (version 1.5.x), distribué sous cette même licence Mozilla Public License 2.0. Il permet de décrire, provisionner et gérer des infrastructures cloud via des fichiers de configuration déclaratifs écrits en Hashicorp Configuration Language.
Il est développé sous la gouvernance de la Linux Foundation, avec un Technical Steering Committee composé de représentants de plusieurs organisations — Gruntwork, Spacelift, Harness, Env0, Scalr — afin qu’aucune entreprise ne puisse en contrôler seule la direction. C’est précisément ce modèle de gouvernance qui a convaincu beaucoup d’équipes de franchir le pas : la garantie que l’outil restera vraiment open source, quelle que soit l’évolution commerciale de ses contributeurs.
En pratique, OpenTofu fonctionne avec les mêmes fichiers .tf, les mêmes providers, les mêmes modules et le même workflow CLI que Terraform — init, plan, apply, destroy. Pour la grande majorité des équipes, migrer se résume à remplacer le binaire.
Quelle différence concrète avec Terraform ?
La différence principale est la licence, et tout ce qu’elle implique sur le long terme.
Terraform est aujourd’hui distribué sous BSL, qui restreint les usages commerciaux pouvant être considérés comme concurrents de HashiCorp — une notion délibérément floue, et que HashiCorp (désormais filiale d’IBM) peut interpréter différemment à l’avenir. OpenTofu est distribué sous MPL 2.0, une vraie licence open source sans restriction commerciale.
Au-delà de la licence, les deux projets ont commencé à diverger techniquement depuis le fork. Les différences les plus notables à ce jour :
- Chiffrement du state : OpenTofu supporte nativement le chiffrement côté client des fichiers d’état, une fonctionnalité longtemps réclamée par la communauté et que Terraform n’a toujours pas implémentée.
- Gouvernance : OpenTofu est piloté par un comité technique multi-organisations au sein de la Linux Foundation. Terraform est sous contrôle d’IBM via HashiCorp, avec une feuille de route dictée par des priorités commerciales.
- Compatibilité : OpenTofu maintient la compatibilité syntaxique et fonctionnelle avec Terraform. Providers, modules et configurations existants fonctionnent sans modification pour la quasi-totalité des cas d’usage.
- Extension
.tofu: OpenTofu supporte cette extension en complément de.tf, ce qui permet aux auteurs de modules de fournir des variantes spécifiques à OpenTofu tout en restant compatibles avec Terraform. - Actions Terraform : HashiCorp a récemment introduit les “actions” dans Terraform, une fonctionnalité permettant de déclencher des comportements personnalisés lors du cycle de vie des ressources. OpenTofu ne la supporte pas encore — c’est le revers inhérent à tout fork : les nouvelles fonctionnalités propriétaires de Terraform ne sont pas automatiquement disponibles, et leur implémentation dans OpenTofu dépend des priorités du comité technique.
Pourquoi des équipes migrent vers OpenTofu
Trois raisons reviennent systématiquement.
Le risque juridique. La BSL interdit l’usage de Terraform dans des produits pouvant entrer en concurrence avec les offres HashiCorp. Pour les équipes qui construisent des plateformes internes, des produits cloud ou des services managés, cette incertitude est un risque opérationnel réel — d’autant que la définition de “compétitif” appartient à HashiCorp, et peut évoluer. À cela s’ajoute une réalité moins visible mais tout aussi structurante : dans le registry Terraform, les providers open source ne bénéficient d’aucune mise en avant particulière. Obtenir un badge “officiel” nécessite de négocier directement avec HashiCorp — et de payer. Dans le registry OpenTofu, tous les providers sont traités à égalité, quelle que soit la taille ou les moyens de leurs mainteneurs.
L’autonomie stratégique sur l’outillage. Votre infrastructure as code est le socle de tout le reste. En dépendre d’un outil contrôlé par une entreprise américaine soumise au Cloud Act, c’est introduire une dépendance supplémentaire que beaucoup d’organisations préfèrent éviter. OpenTofu, sous gouvernance Linux Foundation / CNCF, offre une continuité indépendante de tout acteur commercial.
Les fonctionnalités que Terraform ne livre pas. Le chiffrement natif des fichiers d’état est l’exemple le plus cité : réclamé pendant des années, implémenté en quelques mois par OpenTofu. C’est aussi un signal sur la vitesse à laquelle une gouvernance communautaire peut répondre à des besoins réels, par rapport à une roadmap pilotée par des intérêts commerciaux.
Migrer de Terraform vers OpenTofu
Pour la grande majorité des équipes, la migration est une opération de quelques minutes. Il suffit de s’assurer que le state est propre, d’installer OpenTofu, et de remplacer terraform par tofu dans ses commandes.
# Vérifier que votre state est propre avant de migrer
terraform plan
# → "No changes. Your infrastructure matches the configuration."
# Installer OpenTofu sur macOS
brew install opentofu
# Installer OpenTofu sur Linux
curl –proto ‘=https’ –tlsv1.2 -fsSL https://get.opentofu.org/install-opentofu.sh | sh
# Reprendre son workflow normalement
tofu init
tofu plan
tofu apply
OpenTofu sur Clever Cloud : rien à changer
Notre provider officiel (CleverCloud/clevercloud, actuellement en version 1.10) fonctionne de façon identique avec Terraform et OpenTofu. La source du provider, la syntaxe HCL et l’ensemble des ressources disponibles sont exactement les mêmes. Un exemple minimal pour déployer une application Node.js avec sa base PostgreSQL :
terraform {
required_providers {
clevercloud = {
source = “CleverCloud/clevercloud”
version = “~> 1.10”
}
}
}
provider “clevercloud” {organisation}
resource “clevercloud_node” “app” {
name = “mon-app-node”
region = “par”
min_flavor = “XS”
max_flavor = “M”
}
resource “clevercloud_postgresql” “db” {
name = “ma-base-postgres”
region = “par”
plan = “dev”
}
tofu init
tofu plan
tofu apply
La combinaison OpenTofu + Clever Cloud constitue une stack IaC entièrement souveraine : outillage open source sous gouvernance Linux Foundation / CNCF, infrastructure hébergée dans nos propres datacenters en France, hors de portée du Cloud Act américain. C’est le choix que font de plus en plus d’équipes qui veulent garder la main sur l’ensemble de leur chaîne d’outillage, pas seulement sur leurs données.
Le provider Clever Cloud est disponible sur le Terraform Registry et entièrement open source sur GitHub.
FAQ
OpenTofu est-il compatible avec mes configurations Terraform existantes ?
Pour la quasi-totalité des cas d’usage, oui. OpenTofu maintient la compatibilité syntaxique et fonctionnelle avec Terraform. Fichiers .tf, providers et modules existants fonctionnent sans modification. Il est recommandé de tester dans un environnement non-production avant de basculer des workloads critiques.
OpenTofu est-il prêt pour la production ?
Oui. La première version stable d’OpenTofu a été publiée en janvier 2024. Le projet a depuis dépassé 10 millions de téléchargements et est utilisé en production par des organisations de toutes tailles, y compris des entreprises du Fortune 500. Son intégration au CNCF en avril 2025 a renforcé sa crédibilité pour les environnements enterprise.
Quelle est l’alternative open source à Terraform ?
OpenTofu est la principale alternative open source à Terraform. Distribué sous MPL 2.0, maintenu par la Linux Foundation et membre du CNCF, il est la continuité directe de Terraform dans son état open source d’origine.
Le provider Terraform Clever Cloud est-il compatible avec OpenTofu ?
Oui, sans aucune modification de configuration. Notre provider officiel (CleverCloud/clevercloud) fonctionne identiquement avec Terraform et OpenTofu.
Comment fonctionne OpenTofu ?
De façon identique à Terraform : vous décrivez l’état cible de votre infrastructure en HCL, OpenTofu calcule les changements nécessaires (tofu plan) et les applique (tofu apply). Il gère les dépendances entre ressources, le state et le cycle de vie complet de chaque ressource. C’est aussi là que le rachat de HashiCorp par IBM introduit une incertitude supplémentaire : certains projets gravitant autour de Terraform, comme CDK for Terraform, pourraient être déprioritisés ou abandonnés en fonction des arbitrages commerciaux d’IBM. Avec OpenTofu, la feuille de route est publique, discutée en RFC ouverte, et ne dépend d’aucune décision prise en coulisses par un acteur unique.