8 min de lecture

Depuis que Terraform est passé sous une licence plus restrictive et que HashiCorp appartient à IBM, toute équipe utilisant du code Terraform doit sérieusement envisager OpenTofu : open source sous MPL 2.0, géré par la Linux Foundation. En 2026, il ne s’agit donc pas d’un outil globalement meilleur, mais de trouver le juste équilibre entre exploitation, conformité et chaîne d’approvisionnement.

Les points clés en bref

• La licence est le déclencheur, pas une fonctionnalité : Depuis la version 1.6, Terraform est soumis à la Business Source License, et OpenTofu à la MPL 2.0 sous l’égide de la Linux Foundation. Pour la grande majorité des configurations existantes, le changement est un simple Binary-Swap.
• En 2026, les outils divergent : OpenTofu intègre la State-Verschlüsselung native et des fonctions définies par le provider, alors que Terraform propose des valeurs éphémères et des HCP Stacks. La parité est maintenue pour la syntaxe HCL et le State-Format.
• La décision dans la région DACH relève de la gouvernance, pas de la CLI : La chaîne d’approvisionnement NIS2, le risque lié aux tiers DORA et la Vendor-Konzentration pèsent pour beaucoup plus lourd qu’une simple fonctionnalité en ligne de commande.

À lire aussi :La souveraineté de l’IA commence par l’infrastructure  /  Le cloud-native gagne en maturité avec Kubernetes 1.34

Comment une licence est devenue une question d’architecture

En août 2023, HashiCorp a fait passer la licence de Terraform de la Mozilla Public License à la Business Source License. La BSL interdit toute utilisation en concurrence directe avec les propres produits de HashiCorp et ne redevient véritablement open source que quatre ans après chaque version. Pour les simples utilisateurs finaux, cela ressemble d’abord à une note de bas de page. Mais pour quiconque intègre Terraform dans un produit, une plateforme ou un Managed Service, un risque juridique apparaît.

La réaction a été rapide. Une alliance de fournisseurs et de la communauté a forké Terraform 1.5, la dernière version sous MPL. OpenTF est devenu OpenTofu, placé sous l’égide de la Linux Foundation en septembre 2023, et a rejoint la CNCF en avril 2025. En parallèle, IBM a racheté HashiCorp pour environ 5,9 milliards d’euros, une opération finalisée fin 2024. Ainsi, un seul grand fournisseur se cache aujourd’hui derrière Terraform, tandis qu’une fondation dotée d’une gouvernance multipartite soutient OpenTofu. Pour les équipes soumises à des exigences de gouvernance, cette structure porteuse constitue un critère de décision central.

Qu’est-ce qu’OpenTofu ? OpenTofu est un fork open source de Terraform sous licence MPL 2.0, dérivé de la dernière version de Terraform sous licence libre. Le projet est piloté par un Technical Steering Committee au sein de la Linux Foundation ; aucune entreprise ne contrôle seule la Roadmap. La ligne de commande, le langage HCL et le State-Format sont largement compatibles avec Terraform.

Là où OpenTofu et Terraform divergent

Jusqu’en 2025, OpenTofu pouvait surtout être décrit comme une alternative à Terraform irréprochable en matière de licence. Depuis, les deux projets ont divergé sur le plan fonctionnel. Chacun publie ses propres versions à son propre rythme, et leurs profils fonctionnels s’éloignent. OpenTofu en est actuellement à la version 1.9, Terraform à la 1.14. Toute prise de décision doit s’appuyer sur des fonctionnalités concrètes, les implications des licences et les dépendances opérationnelles.

La différence majeure réside dans le chiffrement du State. OpenTofu chiffre les fichiers de State et de Plan côté client avant qu’ils ne quittent la machine, avec une option vers un fournisseur KMS. Terraform s’en remet traditionnellement au backend, par exemple au chiffrement côté serveur d’un bucket S3. Ceux qui gèrent des données réglementées dans le State bénéficient avec OpenTofu d’une couche de protection supplémentaire. C’est un point crucial, car en pratique, les secrets s’y retrouvent plus souvent que prévu. S’ajoutent à cela des fonctions définies par le provider et une évaluation plus précoce des variables du côté d’OpenTofu. Terraform mise quant à lui sur les valeurs éphémères et une intégration étroite avec HCP Stacks.

Ce tableau trace la ligne de démarcation : OpenTofu l’emporte en matière d’ouverture et de sécurité du State, tandis que Terraform se distingue par sa propre plateforme cloud. Il n’en découle aucune recommandation générale. Ceux qui n’utilisent pas HCP Stacks ne perdront aucune fonctionnalité en migrant. En revanche, ceux qui l’utilisent font face à une dépendance qu’il faudra d’abord résorber.

Migration : ce que coûte concrètement le changement

Le changement est techniquement généralement gérable. Le format State, HCL et le protocole Provider sont compatibles ; dans de nombreuses configurations existantes, le remplacement du binaire suffit. terraform init devient tofu init ; de nombreux processus restent inchangés. Le risque ne réside pas dans le code, mais dans les marges : dans les dépendances vis-à-vis de Terraform Cloud, HCP Stacks ou de wrappers internes conçus pour la stack HashiCorp.

Qui migre ne devrait pas basculer tout le parc d’un coup. D’abord un module, puis un state, ensuite un diff de plan propre avant et après le swap. Cet ordre réduit le risque qu’un changement d’outil pourtant mineur devienne un problème opérationnel. Le volet coûts est rarement le moteur ; les deux outils sont disponibles gratuitement ; les coûts proviennent surtout des plateformes et intégrations autour.

La décision DACH : NIS2, DORA et la chaîne d’approvisionnement

Dans la région DACH, la question passe de la technique à la gouvernance. NIS2 exige un devoir de diligence documenté sur la chaîne d’approvisionnement logicielle, DORA adresse pour le secteur financier le risque lié aux tiers et explicitement le risque de concentration chez les prestataires ICT. Un outil d’infrastructure sous gouvernance d’une fondation, open source et sans propriétaire commercial unique, est dans cette logique plus facile à défendre qu’un produit dont la licence et la feuille de route dépendent d’un seul éditeur.

Cela ne signifie pas qu’OpenTofu soit automatiquement le choix conforme. Cela signifie que la question de la licence et du contrôle se pose dans un audit NIS2 ou DORA et doit être répondue. Le mouvement du marché reste modéré : environ 12 % des praticiens IaC utilisent déjà OpenTofu, environ un quart de plus étudie ou étend son utilisation. Ce n’est pas un raz-de-marée, mais un mouvement régulier dans une direction.

Inversement, il existe des raisons claires de rester sur Terraform. Ceux qui s’appuient sur HCP Stacks, travaillent dans un environnement IBM Cloud Pak ou ont une procédure d’achat qui impose explicitement HashiCorp comme fournisseur, font plus simplement avec Terraform. La décision n’est pas une question de foi. C’est une pesée entre risque de licence, gouvernance de la chaîne d’approvisionnement et dépendances concrètes à des plateformes, et elle varie selon les organisations.

Foire aux questions

Terraform peut-il être remplacé par OpenTofu sans refonte ?

Pour la grande majorité des configurations, oui. Le format State, la syntaxe HCL et le protocole Provider sont compatibles ; en pratique, il suffit généralement de remplacer le binaire. Les frictions apparaissent au niveau des dépendances envers Terraform Cloud, les stacks HCP ou les wrappers propriétaires. Une migration modulaire avec une comparaison des plans (plan-diff) avant et après le changement permet de couvrir les cas limites.

Que s’est-il exactement passé avec la licence de Terraform ?

HashiCorp a basculé Terraform de la MPL 2.0 à la Business Source License 1.1 en août 2023. La BSL restreint l’utilisation en concurrence avec les produits d’HashiCorp et ne redevient open source libre que quatre ans après chaque version. Cela a été le déclencheur du fork OpenTofu.

Quelles fonctionnalités OpenTofu offre-t-il qui manquent à Terraform ?

La plus visible est le chiffrement natif côté client des fichiers State et Plan. S’y ajoutent les fonctions définies par les providers et une évaluation plus précoce des variables. En contrepartie, Terraform dispose de ses propres fonctions, telles que les valeurs éphémères et son intégration étroite avec les stacks HCP. La syntaxe de base reste identique des deux côtés.

Quand Terraform est-il le meilleur choix ?

Lorsque l’exploitation repose sur des stacks HCP, fonctionne dans un environnement IBM Cloud Pak ou lorsque la procédure d’achat impose HashiCorp comme fournisseur. Dans ces cas, un changement génère plus de coûts qu’il ne rapporte en avantages de licence et de gouvernance.

Quelle est l’incidence de ce choix sur la conformité NIS2 et DORA ?

NIS2 exige une diligence raisonnable documentée concernant la chaîne d’approvisionnement logicielle, tandis que DORA traite des risques liés aux tiers et de concentration chez les prestataires de services TIC. Un outil open source sous contrôle de fondation est plus facile à justifier lors d’un audit qu’un produit à fournisseur unique. La question doit être tranchée dans les deux cas, indépendamment de l’outil choisi.

Source image : Image de titre générée par IA (juin 2026), certificat C2PA intégré à l’image

Source de l’image : image de couverture générée par IA (juin 2026), certificat C2PA intégré à l’image