OpenTofu franchit le point de bascule comme moteur par défaut des nouveaux workspaces d’infrastructure
Sur la plateforme Scalr, OpenTofu exécute désormais 63 % des runs Terraform-compatibles et 72 % des workspaces nouvellement créés, un signal qui ne décrit pas le marché mondial mais le sens de l’histoire. La version 1.12 ajoute le prevent_destroy dynamique et des checksums de fournisseurs complets. Pour les équipes qui provisionnent de l’infrastructure, les nouveaux projets devraient défaut sur OpenTofu.
Août 2023. HashiCorp fait basculer Terraform de la licence MPL 2.0 vers la Business Source License 1.1, et le fork communautaire devient OpenTofu sous l’égide de la Linux Foundation. 14 mai 2026. La version 1.12 sort avec le prevent_destroy dynamique et des checksums de fournisseurs complets. Mi-2026. Sur la plateforme Scalr, OpenTofu exécute 63 % des runs Terraform-compatibles et 72 % des nouveaux workspaces. Le point de bascule n’est plus une prédiction, c’est une mesure — à condition de lire les chiffres pour ce qu’ils disent.
Des chiffres qu’il faut lire précisément
La prudence s’impose, et les chiffres la récompensent. Les 63 % de runs et 72 % de nouveaux workspaces viennent de la télémétrie de Scalr, publiée dans son guide 2026 : ils décrivent la plateforme Scalr, pas le marché mondial de l’infrastructure as code.
À l’échelle globale, le tableau est plus nuancé. CodeOxi estime en avril 2026 l’adoption d’OpenTofu à 12 %, avec 27 % d’équipes supplémentaires en évaluation ; Terraform conserve entre un tiers et trois cinquièmes du marché selon la méthode de mesure. Et Firefly, en septembre 2025, ne trouvait que 5 % d’organisations ayant entièrement migré leurs charges Terraform existantes.
Ces trois chiffres peuvent être vrais en même temps : le parc installé est massivement Terraform, la direction du nouveau travail est OpenTofu, et les migrations achevées traînent derrière les deux. Le 72 % de nouveaux workspaces est le chiffre le plus important des deux, parce qu’il mesure des choix faits ce trimestre, pas l’héritage des applis planifiées du passé.
Ce que la 1.12 change concrètement
La version 1.12 sortie le 14 mai 2026 n’est pas spectaculaire, et c’est sa force. Elle apporte :
- Le prevent_destroy dynamique : l’argument
prevent_destroyd’un bloclifecyclepeut désormais référencer une variable du module, ce qui rend la protection d’une base de production conditionnelle à l’environnement ; - Des checksums de fournisseurs complets :
tofu initenregistre automatiquement les empreinteszh:eth1:pour toutes les plateformes, supprimant le besoin de lancertofu providers lockà la main ; - Le -json-into=FILENAME : la sortie machine peut aller dans un fichier pendant que l’interface humaine reste sur la sortie standard ;
- Le destroy = false : retirer un objet de l’état sans détruire l’objet distant ;
- Une installation concurrente des fournisseurs pour accélérer
tofu init.
Un exemple du premier point, qui illustre l’esprit du projet :
variable "prevent_destroy_database" {
type = bool
default = true
}
resource "example_database" "example" {
# ...
lifecycle {
prevent_destroy = var.prevent_destroy_database
}
}Le même module protège la base en production et la laisse supprimable en développement. OpenTofu a aussi annoncé la dépréciation de WinRM pour les provisioners et l’arrêt progressif des builds 32 bits à partir de la série 1.13.
Pourquoi la bascule n’est pas un pari
La bascule d’OpenTofu repose sur un point que les comparaisons de fonctionnalités oublient souvent : les fournisseurs. OpenTofu consomme les mêmes binaires de fournisseurs que Terraform — un seul format, aucune action requise des mainteneurs. Changer de moteur ne coûte donc rien en disponibilité de modules. Passer à Pulumi, en revanche, impose de reconstruire ou d’envelopper sa bibliothèque de modules.
Cette asymétrie explique la forme de la courbe de migration : plate pendant des années, puis raide. Il n’y a pas de taxe d’écosystème de l’autre côté.
La preuve à l’échelle est Fidelity Investments : plus de 2 000 applications, 50 000 fichiers d’état, plus de 4 millions de ressources cloud, et 70 % des projets migrés vers OpenTofu en deux trimestres — sans conversion d’état, parce que le format d’état est partagé. Une institution financière régulée qui déplace quatre millions de ressources sans réécrire l’état, c’est la fin de l’objection « risque de migration ».
La chronologie qui a transformé un grief en stratégie
L’histoire tient en cinq dates. En août 2023, HashiCorp bascule Terraform vers la BSL 1.1 — source disponible, pas open source — et le fork naît en quelques semaines. En février 2025, IBM boucle le rachat d’HashiCorp pour 6,4 milliards de dollars ; la licence ne change pas, et Terraform rejoint le portefeuille d’automatisation d’IBM aux côtés d’Ansible. En avril 2025, la CNCF accepte OpenTofu comme projet Sandbox, ce qui lui donne la neutralité de gouvernance qui compte pour les acheteurs régulés.
Le point qui a tout changé, c’est GitLab 18.0 : l’hébergeur a retiré ses templates Terraform intégrés et le helper gitlab-terraform, parce qu’il ne pouvait plus livrer des binaires Terraform mis à jour sous la BSL. Le chemin officiellement recommandé est désormais le composant CI/CD OpenTofu. Quand le deuxième plus grand hébergeur Git vous dit de changer de binaire, le fork cesse d’être un pari de couverture.
L’avance fonctionnelle qui rend la bascule crédible
La bascule s’appuie aussi sur une avance réelle. Le chiffrement d’état de bout en bout est arrivé en v1.7, après cinq ans de demandes ; Terraform n’y a répondu que par les ressources éphémères, qui sortent des secrets individuels de l’état sans jamais chiffrer le fichier entier. L’évaluation anticipée des variables (v1.8), le for_each sur les fournisseurs (v1.9), le flag -exclude (v1.9), le registre OCI (v1.10) et le verrouillage S3 natif sans DynamoDB (v1.10+) ont tous été livrés par OpenTofu d’abord. Le chiffrement d’état, en particulier, est une exigence de conformité dans les secteurs régulés — exactement là où l’adoption entreprise se concentre.
Ce que ça change pour vos choix
La décision se résume désormais à une règle simple : le nouveau travail d’infrastructure as code devrait défaut sur OpenTofu, et Terraform doit rester exactement là où quelque chose vous y attache — HCP Terraform / Terraform Enterprise, Stacks, ou un contrat de support.
Le chemin de migration est lui aussi trivial, ce qui est un compliment :
# 1. Vérifier un état propre
terraform plan
# 2. Sauvegarder l'état et la configuration distante
# 3. Installer le binaire et pointer le CI dessus
tofu init -upgradeLes fournisseurs se résolvent depuis registry.opentofu.org au lieu de registry.terraform.io — les mêmes binaires dessous. Une seule précaution : éviter les fonctionnalités exclusives d’un camp (le chiffrement d’état OpenTofu d’un côté, les fonctionnalités post-fork de Terraform de l’autre) dans une configuration qui doit tourner sous les deux moteurs pendant la transition. Choisissez un moteur par workspace, migrez le workspace, et la contrainte disparaît.
Verdict
OpenTofu n’est plus un « panic fork » : c’est le moteur que le nouveau travail choisit par défaut, là où les équipes ont la liberté de choisir. Le 72 % de nouveaux workspaces sur Scalr ne dit pas que Terraform est mort — il dit que la charge de la preuve a changé de camp. Et comme le format d’état et les fournisseurs sont partagés, la bascule se fait sans réécriture — ce qui retire le dernier argument d’attente.
Si vous provisionnez de l’infrastructure avec des outils Terraform-compatibles, faites défaut sur OpenTofu pour tout nouveau projet, et migrez les workspaces existants au fil de l’eau quand vous les touchez. Gardez Terraform uniquement là où un contrat, Stacks ou HCP vous y attache.
Si vous êtes encore sur Terraform sans contrainte de support, vous ne perdez rien à basculer — même format d’état, mêmes fournisseurs — et vous gagnez le chiffrement d’état natif et une gouvernance ouverte sous la Linux Foundation.