En 2026, l'Infrastructure as Code repose toujours majoritairement sur le langage HCL, mais avec deux outils distincts : Terraform, désormais dans le portefeuille d'IBM, et OpenTofu, le fork communautaire hébergé par la CNCF. Les deux sont des choix défendables. Le bon critère n'est pas idéologique : il dépend de votre usage au regard de la licence, de votre besoin de support éditeur, des fonctionnalités qui vous importent et de votre capacité à suivre deux trajectoires qui s'éloignent progressivement.
Surtout, le choix d'outil pèse moins que la discipline qui l'entoure. Un état non chiffré, des modules non versionnés ou des applications manuelles hors pipeline créent plus de risques qu'un mauvais choix entre Terraform et OpenTofu. Cet article fait le point sur la situation des licences à la date de rédaction, sur l'état des deux projets, puis sur les pratiques à appliquer dans tous les cas.
Licence de Terraform : ce qui a changé depuis 2023
En août 2023, HashiCorp a annoncé que les versions futures de ses produits, dont Terraform, passeraient de la licence open source MPL 2.0 à la Business Source License 1.1 (BSL) ; les API, SDK et la plupart des bibliothèques restaient sous MPL 2.0 1. Pour un utilisateur final, la copie, la modification et la redistribution du code restent possibles. La restriction vise principalement les fournisseurs qui proposent des services concurrents : ils ne peuvent plus intégrer les nouvelles versions 1.
En réaction, un manifeste soutenu par une communauté d'éditeurs et d'utilisateurs a conduit à la création d'un fork, devenu OpenTofu. Le projet a été accepté par la CNCF le 23 avril 2025, au niveau Sandbox, et se présente comme un fork communautaire de Terraform visant à rester rétrocompatible 3. De son côté, IBM a annoncé le 27 février 2025 la finalisation de l'acquisition de HashiCorp ; Terraform et Vault sont depuis proposés au sein du portefeuille d'automatisation d'IBM 2.
Concrètement, pour une ETI ou un grand compte qui utilise Terraform pour son propre SI, la BSL ne change pas l'usage quotidien. La question devient sensible si vous intégrez Terraform dans une offre commerciale proposée à des tiers, ou si votre politique interne exige des composants sous licence approuvée par l'Open Source Initiative. Dans ces deux cas, faites valider votre situation par votre service juridique plutôt que de vous fier à une lecture générale.
OpenTofu en 2026 : un projet qui suit sa propre trajectoire
OpenTofu n'est plus une simple copie. Ses versions successives ont introduit des fonctionnalités propres :
- OpenTofu 1.7 (avril 2024) : chiffrement de bout en bout du fichier d'état, quel que soit le backend de stockage, avec des clés issues de services comme AWS KMS, GCP KMS ou OpenBao 4.
- OpenTofu 1.10 (juin 2025) : distribution des providers et modules via des registres OCI, utile dans les environnements isolés, verrouillage natif de l'état sur S3 sans DynamoDB, et traçage OpenTelemetry local 5.
- OpenTofu 1.13 (29 septembre 2026) : linting de base et bibliothèques de symboles à titre expérimental, prise en charge officielle de Windows sur ARM64 ; la branche 1.13 est maintenue jusqu'au 1er août 2027 67.
Côté Terraform, la branche 1.14, publiée le 19 novembre 2025, a introduit les list resources et les actions 8. Chaque outil ajoute donc des fonctionnalités que l'autre n'a pas, ou pas sous la même forme. La compatibilité reste large pour le code HCL courant, mais elle n'est plus garantie pour les fonctionnalités récentes : utiliser le chiffrement d'état d'OpenTofu ou les actions de Terraform vous ancre dans l'un des deux écosystèmes.
Le vrai risque n'est pas de choisir le mauvais outil, mais d'utiliser les deux sans le savoir dans des dépôts différents.
Terraform ou OpenTofu : les critères de choix
Plutôt qu'un comparatif de fonctionnalités, qui vieillit vite, appuyez la décision sur des critères stables :
- Usage au regard de la licence : utilisation interne, intégration dans une offre commerciale, exigences de votre politique open source.
- Support et services gérés : besoin d'un contrat éditeur, d'une plateforme d'exécution gérée, d'une intégration avec un outillage existant.
- Fonctionnalités structurantes : chiffrement natif de l'état, distribution OCI pour des environnements déconnectés, fonctionnalités récentes de Terraform.
- Gouvernance du projet : fondation neutre (CNCF) ou éditeur unique, et poids que vous accordez à ce critère.
- Compatibilité de l'écosystème : providers et modules dont vous dépendez, outils d'orchestration et de contrôle de politiques que vous utilisez.
- Coût de sortie : capacité à revenir en arrière si la divergence s'accentue.
Dans la plupart des organisations, la décision la plus importante est de standardiser : un outil par périmètre, une version figée par dépôt, et une règle explicite sur l'usage des fonctionnalités propres à l'un ou l'autre.
Cette décision gagne à être formalisée dans un court document d'architecture : outil retenu par périmètre, versions autorisées, fonctionnalités propres admises ou proscrites, conditions de réexamen. Ce document évite que chaque équipe tranche seule, et donne une base factuelle le jour où la stratégie d'un éditeur ou d'une fondation évoluera.
Bonnes pratiques d'Infrastructure as Code, quel que soit l'outil
Protéger l'état
Le fichier d'état décrit votre infrastructure et peut contenir des valeurs sensibles. Il doit résider dans un backend distant, avec verrouillage pour éviter les modifications concurrentes, chiffrement au repos et accès restreint. Avec OpenTofu, le chiffrement côté client ajoute une protection indépendante du stockage 4. Évitez autant que possible de faire transiter des secrets par l'état : préférez des références vers un gestionnaire de secrets.
Structurer le code et les environnements
Découpez l'infrastructure en unités indépendantes (réseau, socle, applications) avec des états séparés, pour limiter le rayon d'impact d'une erreur. Publiez des modules versionnés dans un registre interne, figez les versions des providers avec le fichier de verrouillage et faites évoluer les modules par versions explicites plutôt que par branches mouvantes.
Séparer les identités et les droits
Le pipeline d'Infrastructure as Code dispose souvent de droits très étendus sur les environnements : c'est une cible de choix. Utilisez des identités de pipeline distinctes pour la génération du plan, en lecture seule, et pour son application, avec des droits limités au périmètre concerné. Préférez des identifiants de courte durée obtenus par fédération d'identité plutôt que des clés statiques stockées dans l'outil de CI. Enfin, conditionnez l'application en production à une approbation humaine tracée, distincte de l'auteur de la modification.
Industrialiser le cycle de modification
- Aucune application manuelle en production : tout passe par un pipeline qui génère le plan, l'archive et l'applique après revue.
- Revue systématique du plan, pas seulement du code : c'est le plan qui montre ce qui sera détruit ou recréé.
- Contrôles automatisés avant revue : formatage, validation, analyse de sécurité statique, règles de politique (policy as code).
- Tests des modules : les frameworks de test natifs (tofu test côté OpenTofu, qui accepte désormais des surcharges de ressources plus fines 7) vérifient le comportement d'un module avant sa publication.
- Détection de dérive planifiée : un plan exécuté régulièrement révèle les modifications faites hors code.
- Refactorisation déclarative : les blocs moved, removed et import permettent de réorganiser le code ou de reprendre des ressources existantes sans les recréer 45.
Migrer de Terraform vers OpenTofu, ou rester : une démarche en étapes
Si vous envisagez une migration, procédez par périmètre et non par décret. Commencez par un inventaire des versions utilisées dans chaque dépôt et des fonctionnalités récentes déjà employées. Choisissez ensuite un périmètre pilote non critique, sauvegardez les états, exécutez un plan avec le nouvel outil et vérifiez qu'il n'annonce aucun changement. Ce n'est qu'après plusieurs cycles sans écart que la bascule peut être généralisée, avec une règle claire pour les nouveaux projets.
Si vous restez sur Terraform, la démarche reste utile : figer les versions, documenter les fonctionnalités propres utilisées et formaliser la position de l'entreprise sur la licence vous donneront de la marge de manœuvre si votre contexte change.
Conclusion
La question Terraform ou OpenTofu mérite une décision documentée, mais elle ne doit pas éclipser l'essentiel : un état protégé, des modules versionnés, un pipeline unique et une revue du plan systématique. En tant que partenaire intégrateur IBM sur l'offre HashiCorp, DATASWING aide ses clients à cadrer ce choix au regard de leurs contraintes réelles, quel que soit l'outil retenu.
— Questions fréquentes
Ce qu'on nous demande souvent
Terraform est-il encore gratuit en 2026 ?+
Oui pour la plupart des usages internes. Depuis août 2023, les nouvelles versions de Terraform sont distribuées sous Business Source License 1.1. Les utilisateurs finaux peuvent toujours l'utiliser, le modifier et le redistribuer ; la restriction vise surtout les fournisseurs proposant des services concurrents. Faites valider votre cas par votre service juridique si vous intégrez Terraform dans une offre commerciale.
OpenTofu est-il compatible avec Terraform ?+
OpenTofu est un fork de Terraform qui vise la rétrocompatibilité, et le code HCL courant fonctionne généralement avec les deux. Mais les projets divergent : chiffrement de l'état et distribution OCI côté OpenTofu, list resources et actions côté Terraform 1.14. Utiliser ces fonctionnalités propres vous lie à l'un des deux outils ; vérifiez-le avant toute migration.
Comment migrer de Terraform vers OpenTofu sans risque ?+
Inventoriez les versions et fonctionnalités utilisées, sauvegardez les fichiers d'état, puis choisissez un périmètre pilote non critique. Exécutez un plan avec OpenTofu et vérifiez qu'il n'annonce aucun changement d'infrastructure. Répétez sur plusieurs cycles avant de généraliser, et fixez une règle claire pour les nouveaux projets afin d'éviter un parc hybride non maîtrisé.
Faut-il chiffrer le fichier d'état Terraform ou OpenTofu ?+
Oui. Le fichier d'état décrit toute l'infrastructure et peut contenir des valeurs sensibles. Stockez-le dans un backend distant chiffré, avec verrouillage et droits d'accès restreints. OpenTofu propose depuis la version 1.7 un chiffrement côté client indépendant du backend. Dans tous les cas, limitez la présence de secrets dans l'état en utilisant un gestionnaire de secrets.
— Sources
Références citées
Les textes réglementaires et documentations évoluent : vérifiez la version en vigueur avant toute décision. Cet article n'est pas un avis juridique.
-
[1]
HashiCorp Adopts Business Source License ↗InfoQ · 2023-08
- [2]
-
[3]
OpenTofu – project page ↗CNCF · 2025-04
-
[4]
OpenTofu 1.7.0 ↗OpenTofu · 2024-04
-
[5]
OpenTofu 1.10.0 ↗OpenTofu · 2025-06
-
[6]
OpenTofu blog archive ↗OpenTofu · 2026-09
-
[7]
OpenTofu v1.13 CHANGELOG ↗OpenTofu (GitHub) · 2026
-
[8]
Terraform v1.14.0 released ↗HashiCorp Discuss · 2025-11
