Depuis que HashiCorp a placé Terraform sous licence BSL en 2023, une partie de la communauté cloud a basculé vers OpenTofu, le fork open source hébergé par la Cloud Native Computing Foundation. Mi-août 2026, la branche stable d’OpenTofu est passée en version 1.12, avec un correctif 1.12.6 publié le 19 août. Ce tutoriel vous montre comment migrer un projet Terraform existant vers OpenTofu, étape par étape, en gardant votre state intact et en ajoutant au passage des contrôles FinOps-as-Code : tagging obligatoire, policies OPA, et protection dynamique contre les suppressions accidentelles. À la fin, vous aurez un dépôt d’infrastructure as code fonctionnel, chiffré, et prêt pour un pipeline CI/CD.

Pourquoi migrer de Terraform vers OpenTofu en 2026

OpenTofu a rejoint la Cloud Native Computing Foundation aux côtés de Kubernetes et Prometheus, ce qui change la donne pour les équipes qui hésitaient à s’engager sur un fork. Le projet revendique aujourd’hui plus de 29 000 étoiles sur GitHub, un registre de plus de 3 900 providers et plus de 23 600 modules publiés, selon les chiffres relevés fin juillet 2026. Plusieurs grands comptes, dont Boeing, Capital One et AMD, auraient déjà basculé une partie de leur infrastructure en production, d’après des retours d’expérience publiés cet été.

De son côté, Terraform continue d’évoluer sous licence BSL. La version 1.15, sortie en juin 2026, a ajouté des sources de modules dynamiques, un mécanisme formel de dépréciation pour les variables et les outputs, une fonction de conversion de type inline, des contraintes de type pour les blocs output, et le support natif de Windows ARM64. Techniquement solide, mais la licence reste le point de friction : toute entreprise qui revend un produit concurrent de Terraform ne peut plus l’utiliser librement. C’est précisément ce vide qu’OpenTofu comble, avec une licence Mozilla Public License 2.0 sans restriction commerciale.

Deux nouveautés d’OpenTofu justifient à elles seules la migration côté FinOps. D’abord, le prevent_destroy dynamique : contrairement à Terraform, où cet attribut reste figé au moment du plan, OpenTofu permet de le piloter via une policy, donc de le durcir automatiquement sur les ressources en production sans toucher au code. Ensuite, le chiffrement natif du state, introduit dès la version 1.8 avec un framework de tests amélioré, des contrôles de policy basés sur OPA et plus de quarante nouvelles fonctions intégrées. Pour une équipe qui gère des budgets cloud à six chiffres, ce sont des garde-fous concrets, pas des arguments marketing.

Il y a aussi un argument de gouvernance pure. Une gouvernance CNCF signifie un processus de décision ouvert, des mainteneurs issus de plusieurs entreprises concurrentes (pas d’une seule société qui peut changer sa licence du jour au lendemain), et une feuille de route publique votée par un comité technique. Pour une équipe qui doit justifier un choix d’outil devant un comité d’architecture ou un service achats, ce point pèse autant que les fonctionnalités techniques. C’est également ce qui a convaincu certaines équipes DevOps françaises interrogées dans des retours de fin 2026 : le risque de dépendance à une seule entreprise commerciale devient un critère d’audit à part entière, au même titre que la résilience technique.

Ce tutoriel part du principe que vous gérez déjà un projet Terraform fonctionnel et que vous voulez basculer sans interruption de service ni perte de state. Il ne couvre pas la réécriture d’une infrastructure legacy en ClickOps vers l’IaC, ce qui est un projet à part entière et beaucoup plus long.

Prérequis techniques et versions

Avant de commencer, vérifiez que votre environnement correspond aux versions suivantes. Le tutoriel a été testé sur macOS, Linux (Ubuntu 24.04) et Windows avec WSL2.

OutilVersion testéeRôle dans le projet
OpenTofu1.12.6 (19 août 2026)Moteur IaC principal
Terraform1.15.xProjet source à migrer
AWS CLIv2, dernière versionAuthentification et backend S3
Dockerdernière versionExécution locale d’OPA (Conftest)
Git2.40 ou supérieurVersionnage du code IaC
Compte AWSavec droits IAM sur S3 et DynamoDBBackend d’état partagé

Vous aurez aussi besoin d’un projet Terraform existant, même modeste (un bucket S3 et un rôle IAM suffisent pour suivre l’exercice). Si vous partez de zéro, clonez n’importe quel exemple public de la documentation Terraform et adaptez-le. Comptez environ 45 minutes pour dérouler l’ensemble des douze étapes, backup compris.

Côté droits IAM, prévoyez un utilisateur ou un rôle avec accès en lecture-écriture sur le bucket S3 de state, sur les ressources que vous provisionnez (S3, IAM dans cet exemple), et sur Secrets Manager ou SSM Parameter Store si vous suivez l’étape de chiffrement. Évitez d’utiliser des identifiants root AWS pendant l’exercice, même en environnement de test : prenez l’habitude d’un rôle dédié dès le départ, cela évite de devoir tout reconfigurer plus tard pour le pipeline CI/CD.

Vue d’ensemble du projet que vous allez construire

À la fin de ce guide, votre dépôt contiendra : un fichier de configuration OpenTofu fonctionnel pour provisionner un bucket S3 taggé, un state chiffré, une policy OPA qui refuse tout déploiement sans tag cost-center, un backend distant sur S3 avec verrouillage natif (sans DynamoDB, grâce au lock file S3 natif introduit récemment), et un workflow GitHub Actions qui exécute tofu plan à chaque pull request. C’est un squelette FinOps-as-Code minimal mais réutilisable pour n’importe quel projet cloud plus large.

Estimer l’impact FinOps avant de migrer

Avant de toucher au code, prenez cinq minutes pour chiffrer ce que la migration va réellement changer sur votre facture cloud. La plupart des coûts ne viennent pas d’OpenTofu lui-même (l’outil est gratuit) mais de ce que vous ajoutez autour : une table DynamoDB en moins grâce au lock natif S3, un appel Secrets Manager supplémentaire pour la passphrase de chiffrement, et éventuellement une exécution CI/CD un peu plus longue à cause du scan OPA.

# Avec Infracost, comparez le coût avant/après sur le plan généré
infracost breakdown --path . --format table

# Puis comparez deux plans (avant et après migration)
infracost diff --path . --compare-to infracost-base.json

Dans la pratique, la suppression de la table DynamoDB de verrouillage fait économiser quelques dollars par mois sur un petit projet, ce qui semble anecdotique. Mais à l’échelle d’une organisation avec plusieurs centaines de dépôts d’infrastructure, ce sont des dizaines de tables DynamoDB en moins à surveiller, à sauvegarder et à sécuriser. C’est un gain opérationnel plus qu’un gain financier direct, mais un gain qui compte dans un audit FinOps.

Documentez ce chiffrage dans le ticket ou la pull request qui accompagne la migration. Un comité d’architecture ou un responsable FinOps qui voit un delta de coût explicite, même minime, approuve plus vite un changement d’outil qu’une demande justifiée uniquement par des arguments techniques ou de licence.

Étape 1 : sauvegarder l’état Terraform actuel

Ne migrez jamais sans filet. Commencez par exporter une copie complète du state Terraform en cours, même si vous utilisez déjà un backend distant.

cd mon-projet-iac
terraform state pull > backup_$(date +%Y%m%d_%H%M).tfstate
cp -r . ../mon-projet-iac-backup-terraform

Versionnez cette sauvegarde en dehors du dépôt Git principal, idéalement dans un bucket S3 séparé avec versioning activé. Si la migration tourne mal, ce fichier est votre seul moyen de revenir en arrière sans tout reconstruire à la main.

Profitez-en aussi pour documenter l’état exact de votre infrastructure au moment T : exportez la liste des ressources gérées avec terraform state list et gardez ce fichier texte à côté du backup. En cas de doute pendant la migration, ce simple inventaire permet de vérifier rapidement qu’aucune ressource n’a disparu du state, sans avoir à comparer deux fichiers JSON volumineux à la main.

Étape 2 : installer OpenTofu 1.12

Sur macOS et Linux, le plus simple reste le script d’installation officiel ou Homebrew.

# macOS / Linux via Homebrew
brew install opentofu

# Ou via le script officiel
curl --proto '=https' --tlsv1.2 -fsSL \
  https://get.opentofu.org/install-opentofu.sh -o install-opentofu.sh
chmod +x install-opentofu.sh
./install-opentofu.sh --install-method standalone

tofu version

Sortie attendue :

OpenTofu v1.12.6
on linux_amd64

Ne désinstallez pas Terraform tout de suite. Gardez les deux binaires en parallèle le temps de valider la migration, ils peuvent cohabiter sans conflit puisque leurs noms de commandes diffèrent (terraform contre tofu).

Sur Windows sans WSL2, l’installation passe par Chocolatey (choco install opentofu) ou par le téléchargement direct du binaire signé depuis les releases GitHub officielles. Vérifiez systématiquement la signature avec la clé de vérification publiée par le projet avant d’exécuter le binaire sur un poste de développement en entreprise, surtout si votre politique de sécurité interne impose une vérification de provenance sur les outils en ligne de commande.

Étape 3 : adapter la configuration et le backend

Bonne nouvelle : OpenTofu est un fork au niveau syntaxique, donc l’essentiel de votre HCL fonctionne sans modification. Seuls deux points méritent une vérification. D’abord le bloc required_providers, qui doit pointer vers le registre OpenTofu ou rester compatible avec le registre Terraform (les deux coexistent). Ensuite le champ required_version, à adapter pour accepter les deux binaires si vous gardez une période de transition.

terraform {
  required_version = ">= 1.12.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.60"
    }
  }

  backend "s3" {
    bucket       = "mon-entreprise-tfstate"
    key          = "finops-demo/terraform.tfstate"
    region       = "eu-west-3"
    use_lockfile = true
  }
}

Le paramètre use_lockfile = true active le verrouillage natif sur S3, une fonctionnalité désormais stable qui évite de maintenir une table DynamoDB séparée pour le lock. C’est une simplification appréciable pour les petites équipes qui géraient jusqu’ici deux ressources AWS juste pour le state.

Si votre projet utilise encore l’ancien mécanisme de verrouillage DynamoDB (dynamodb_table dans le bloc backend), vous n’êtes pas obligé de migrer les deux en même temps. Gardez la table existante pendant la transition, testez le nouveau lock natif sur un projet secondaire, puis basculez la table de production une fois le comportement validé sur plusieurs semaines. C’est le genre de changement qui, mal testé, provoque un verrouillage bloqué en pleine urgence de production.

Étape 4 : migrer le state vers OpenTofu

OpenTofu lit nativement les fichiers state produits par Terraform, aucune conversion de format n’est nécessaire. Il suffit de réinitialiser le backend avec le binaire tofu.

tofu init -migrate-state

# Si le backend n'a pas changé de configuration, une simple
# réinitialisation suffit :
tofu init

OpenTofu détecte que le state existant provient de Terraform et vous demande une confirmation avant de continuer. Répondez yes uniquement après avoir vérifié que la sauvegarde de l’étape 1 est bien accessible.

Étape 5 : valider avec tofu plan

C’est l’étape de vérité. Un plan qui ne montre aucun changement confirme que la migration n’a rien cassé.

tofu plan -out=migration.tfplan

Sortie attendue sur un projet correctement migré :

No changes. Your infrastructure matches the configuration.

OpenTofu has compared your real infrastructure against your
configuration and found no differences, so no changes are needed.

Si des changements apparaissent alors que vous n’avez rien modifié dans le code, arrêtez-vous. Le problème vient presque toujours d’une version de provider différente entre les deux outils. Verrouillez la version exacte dans required_providers plutôt que d’utiliser une contrainte large.

Gardez une trace de ce plan de validation. Exportez-le en JSON et archivez-le à côté de votre sauvegarde de state, il servira de preuve en cas d’audit interne ou si un collègue vous demande plus tard de confirmer que la migration n’a rien modifié sur l’infrastructure réelle.

tofu show -json migration.tfplan > migration-preuve.json

Étape 6 : chiffrer le state

Le chiffrement du state, disponible depuis les premières versions 1.8 d’OpenTofu, protège les secrets qui transitent souvent en clair dans les fichiers state (mots de passe générés, clés d’accès temporaires, ARN sensibles). Ajoutez un bloc encryption au niveau racine de votre configuration.

terraform {
  encryption {
    key_provider "pbkdf2" "state_key" {
      passphrase = var.state_encryption_passphrase
    }

    method "aes_gcm" "state_method" {
      keys = key_provider.pbkdf2.state_key
    }

    state {
      method = method.aes_gcm.state_method
    }
  }
}

Stockez la passphrase dans un gestionnaire de secrets (AWS Secrets Manager ou SSM Parameter Store en SecureString), jamais dans le dépôt Git. Une fois activé, le fichier state reste chiffré au repos et en transit, même si votre bucket S3 est mal configuré par erreur.

Un point souvent oublié : le chiffrement du state ne dispense pas de chiffrer aussi le bucket S3 qui l’héberge. Ce sont deux couches indépendantes. La première protège le contenu du fichier même si quelqu’un accède directement au bucket. La seconde protège le stockage physique côté AWS. Activez les deux, elles ne se substituent pas l’une à l’autre et répondent à des scénarios de compromission différents.

Étape 7 : mettre en place le tagging FinOps-as-Code

Le principe du FinOps-as-Code consiste à coder les règles de gouvernance des coûts directement dans l’infrastructure, plutôt que de les documenter dans un wiki que personne ne lit. Première brique : forcer un tag cost-center et environment sur chaque ressource facturable, via les default_tags du provider AWS.

provider "aws" {
  region = "eu-west-3"

  default_tags {
    tags = {
      ManagedBy   = "OpenTofu"
      CostCenter  = var.cost_center
      Environment = var.environment
      Repository  = "mon-projet-iac"
    }
  }
}

variable "cost_center" {
  type        = string
  description = "Centre de coût FinOps obligatoire"

  validation {
    condition     = length(var.cost_center) > 0
    error_message = "Le tag cost-center est obligatoire pour toute ressource."
  }
}

Ce bloc validation fait échouer le tofu plan avant même que la ressource ne soit envisagée, si la variable est vide. C’est nettement plus efficace qu’un contrôle a posteriori dans votre outil FinOps, qui découvrirait le problème après coup, une fois la facture déjà générée.

Étape 8 : ajouter des contrôles de policy avec OPA

OpenTofu 1.8 a introduit des contrôles de policy natifs basés sur Open Policy Agent. Écrivez une règle Rego simple qui bloque tout plan contenant une instance surdimensionnée sans justification.

# policies/instance-size.rego
package finops

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_instance"
  size := resource.change.after.instance_type
  contains(size, "xlarge")
  not resource.change.after.tags.JustificationCoutEleve
  msg := sprintf("Instance %s en xlarge sans justification FinOps", [resource.address])
}
# Exécution locale via Conftest, avant tout apply
tofu show -json migration.tfplan > plan.json
conftest test plan.json -p policies/

Ce genre de garde-fou coûte une heure à écrire et évite des dérapages de facture bien plus coûteux. C’est exactement le type de politique que les équipes FinOps matures automatisent en 2026, plutôt que de compter sur une revue manuelle du code IaC en pull request.

Vous pouvez étendre cette même logique à d’autres signaux de dérapage budgétaire : instances lancées en dehors des régions autorisées, volumes EBS non attachés depuis plus de sept jours, ou bases de données provisionnées sans tag AutoShutdown sur les environnements de développement. Chaque règle Rego supplémentaire s’ajoute simplement dans le dossier policies/ et s’exécute automatiquement au prochain plan, sans modifier le pipeline CI/CD lui-même.

Étape 9 : configurer le prevent_destroy dynamique

C’est la fonctionnalité qui distingue le plus nettement OpenTofu 1.12 de Terraform sur ce sujet précis. Sur Terraform, prevent_destroy est une valeur statique fixée dans le code. Sur OpenTofu, elle peut être pilotée par une variable, donc changer automatiquement selon l’environnement sans modifier le fichier source.

resource "aws_s3_bucket" "donnees_production" {
  bucket = "mon-entreprise-donnees-prod"

  lifecycle {
    prevent_destroy = var.environment == "production" ? true : false
  }
}

Résultat concret : le même module protège automatiquement les ressources en production tout en laissant les environnements de test et de développement librement détruits, sans dupliquer le code ni maintenir deux branches de configuration séparées.

Étape 10 : configurer le backend d’état partagé

Pour une équipe de plus d’une personne, le state doit vivre sur un backend distant avec verrouillage. Créez le bucket S3 dédié avant de pointer votre configuration dessus.

aws s3api create-bucket \
  --bucket mon-entreprise-tfstate \
  --region eu-west-3 \
  --create-bucket-configuration LocationConstraint=eu-west-3

aws s3api put-bucket-versioning \
  --bucket mon-entreprise-tfstate \
  --versioning-configuration Status=Enabled

aws s3api put-bucket-encryption \
  --bucket mon-entreprise-tfstate \
  --server-side-encryption-configuration \
  '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms"}}]}'

Le versioning S3 agit comme une seconde ligne de défense en plus du chiffrement du state configuré à l’étape 6, même en cas d’écrasement accidentel du fichier, vous pouvez restaurer une version antérieure directement depuis la console AWS.

Ajoutez également une politique de cycle de vie sur ce bucket pour ne pas accumuler indéfiniment des versions de state obsolètes, ce qui a un coût de stockage réel sur un projet actif depuis plusieurs années. Une rétention de 90 jours sur les versions non courantes suffit dans la plupart des cas, tout en gardant assez d’historique pour un rollback tardif.

Étape 11 : automatiser avec GitHub Actions

Le pipeline CI/CD exécute un tofu plan à chaque pull request, applique les policies OPA, puis attend une validation humaine avant l’apply.

name: opentofu-plan
on:
  pull_request:
    branches: [main]

jobs:
  plan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: opentofu/setup-opentofu@v1
        with:
          tofu_version: "1.12.6"

      - name: Init
        run: tofu init

      - name: Plan
        run: tofu plan -out=plan.tfplan

      - name: Export JSON et verification OPA
        run: |
          tofu show -json plan.tfplan > plan.json
          conftest test plan.json -p policies/

L’action officielle opentofu/setup-opentofu installe le binaire exact demandé et le met en cache entre les exécutions, ce qui garde le pipeline rapide même sur des dépôts avec beaucoup de pull requests par jour.

Étape 12 : tester le rollback et la protection contre la destruction

Avant de considérer la migration terminée, testez volontairement un scénario d’échec sur un environnement de développement, jamais en production.

tofu workspace select dev
tofu destroy -target=aws_s3_bucket.donnees_production

# Resultat attendu si prevent_destroy fonctionne :
# Error: Instance cannot be destroyed
#   Resource aws_s3_bucket.donnees_production has
#   lifecycle.prevent_destroy set, but the plan calls for this
#   resource to be destroyed.

Si la commande échoue avec ce message, votre protection fonctionne. Testez ensuite un vrai rollback en restaurant la sauvegarde de l’étape 1 sur une copie du projet, pour vérifier que la procédure de secours fonctionne réellement et pas seulement sur le papier.

Gérer plusieurs environnements avec les workspaces OpenTofu

La plupart des projets réels ne se limitent pas à un seul environnement. Les workspaces OpenTofu permettent d’exécuter la même configuration contre plusieurs states isolés (développement, staging, production) sans dupliquer le code. La commande fonctionne exactement comme sous Terraform, ce qui simplifie encore la migration.

tofu workspace new dev
tofu workspace new staging
tofu workspace new production

tofu workspace list
# * dev
#   staging
#   production

tofu workspace select production
tofu plan

Combinez les workspaces avec la variable terraform.workspace pour piloter automatiquement le tagging FinOps et le prevent_destroy dynamique vus aux étapes 7 et 9, sans avoir à passer une variable manuellement à chaque exécution.

locals {
  environment = terraform.workspace
  is_production = terraform.workspace == "production"
}

Attention toutefois à un piège classique : un seul bucket S3 backend peut héberger plusieurs states de workspaces différents, mais chaque state reste un fichier séparé sous un préfixe env:/. Vérifiez toujours avec tofu workspace show avant un apply sensible, pour vous assurer que vous ne modifiez pas la production en pensant travailler sur le développement.

Cinq pièges courants lors d’une migration Terraform vers OpenTofu

  • Oublier de verrouiller les versions de providers. Terraform et OpenTofu peuvent résoudre une contrainte ~> vers des versions de provider légèrement différentes selon la date d’exécution du init, ce qui génère un plan avec des changements fantômes qui font perdre du temps en revue de code. Fixez toujours une version exacte pendant la période de transition, puis élargissez la contrainte une fois la migration stabilisée sur plusieurs semaines.
  • Migrer directement en production. Testez systématiquement sur un workspace de développement avant de toucher au state de production, même si le projet semble simple. Un plan qui semble neutre sur un petit projet peut révéler un comportement différent sur une infrastructure plus large avec des dépendances entre ressources.
  • Supprimer Terraform trop tôt. Gardez le binaire installé au moins deux semaines après la migration, le temps de confirmer qu’aucun script ou pipeline oublié ne l’appelle encore. Grep votre codebase pour la chaîne terraform dans les scripts CI/CD avant la désinstallation finale.
  • Ignorer la dépréciation des connexions WinRM. Les blocs connection de type winrm génèrent désormais des avertissements et disparaîtront complètement en OpenTofu 1.13. Migrez ces provisioners vers SSH ou un outil de configuration dédié comme Ansible plutôt que de reporter le problème à la prochaine montée de version majeure.
  • Ne pas mettre à jour la documentation interne. Les runbooks d’astreinte qui référencent encore terraform apply créent de la confusion en pleine urgence à 3h du matin, quand l’ingénieur d’astreinte n’a pas suivi la migration en détail. Mettez-les à jour dans la foulée de la migration, pas six mois après, et faites relire le runbook par quelqu’un qui n’a pas participé au projet.

Dépannage : neuf problèmes fréquents et leurs solutions

1. Erreur “Backend configuration changed” au premier init. Lancez tofu init -reconfigure plutôt que -migrate-state si seule la clé du backend a changé, pas son type.

2. Le plan affiche des changements sur des ressources non modifiées. Comparez les versions de providers résolues avec tofu providers et terraform providers. Une différence de patch version suffit à provoquer un diff.

3. Verrouillage S3 natif qui ne se libère pas. Vérifiez qu’aucun processus tofu plan zombie ne tourne encore côté CI. Le lock natif via use_lockfile se supprime automatiquement en fin d’exécution, mais un job interrompu brutalement (kill -9) peut le laisser en place. Supprimez manuellement l’objet .tflock dans le bucket si besoin.

4. Erreur de déchiffrement du state après activation du chiffrement. Vérifiez que la passphrase est bien identique entre tous les membres de l’équipe et dans le pipeline CI. Une variable d’environnement mal propagée est la cause la plus fréquente.

5. Les policies OPA bloquent un plan légitime. Ajoutez un mécanisme d’exception documenté (par exemple un tag PolicyException avec une justification obligatoire) plutôt que de désactiver la policy entièrement.

6. GitHub Actions échoue avec “command not found: tofu”. Vérifiez la version de l’action opentofu/setup-opentofu utilisée et que le tofu_version déclaré existe bien dans les releases officielles.

7. Modules tiers incompatibles. Certains modules publiés uniquement sur le registre Terraform ne sont pas encore répliqués sur le registre OpenTofu. Pointez-les directement vers leur source Git avec une référence de tag figée en attendant la publication officielle, plutôt que d’attendre une synchronisation qui peut prendre plusieurs semaines.

8. Le prevent_destroy dynamique ne se déclenche pas. Vérifiez que la variable utilisée dans la condition n’est pas elle-même calculée à partir d’un output, ce qui empêche OpenTofu d’évaluer la protection avant le apply. Utilisez une variable simple, résolue au moment du plan, plutôt qu’une valeur dérivée d’une ressource déjà provisionnée.

9. Le pipeline CI/CD dépasse le quota d’appels API du registre. Sur des dépôts avec beaucoup de pull requests simultanées, l’action setup-opentofu et le téléchargement des providers peuvent solliciter fortement le registre officiel. Mettez en cache le répertoire .terraform entre les exécutions GitHub Actions pour réduire le nombre d’appels et accélérer chaque run de plusieurs dizaines de secondes.

Astuces avancées pour aller plus loin

Si votre organisation utilise déjà Pulumi sur d’autres projets, la sortie d’août 2026 change la donne : Pulumi supporte désormais nativement le state Terraform et le langage HCL comme langage de première classe, au même titre que TypeScript, Python, Go, .NET et Java. Concrètement, vous pouvez héberger le state OpenTofu dans Pulumi Cloud et exécuter du code HCL existant à travers le moteur Pulumi, sans réécriture complète. C’est une option intéressante pour les équipes qui migrent progressivement vers des langages de programmation généralistes tout en gardant une partie du parc en HCL.

Autre piste pour les environnements multi-cloud : combinez le tagging FinOps-as-Code de l’étape 7 avec un module réutilisable partagé entre AWS, Azure et GCP, en normalisant les noms de tags (CostCenter, Environment, Owner) au niveau d’un module racine commun. Cela simplifie considérablement l’agrégation des coûts dans un outil FinOps centralisé, plutôt que de devoir mapper des conventions de tags différentes par fournisseur cloud.

Enfin, surveillez le calendrier de fin de support. La branche 1.11 d’OpenTofu a atteint sa fin de support de sécurité le 19 août 2026. La branche 1.12 reste couverte jusqu’au 1er février 2027. Planifiez votre prochaine mise à jour majeure avant cette date pour rester dans la fenêtre de correctifs de sécurité.

Sur la conduite du changement côté équipe, ne sous-estimez pas la phase de formation. Même si la syntaxe HCL ne change pas, les habitudes de commande (tofu au lieu de terraform) demandent un temps d’adaptation réel, surtout pour les équipes qui ont des alias shell ou des scripts internes construits autour du binaire Terraform depuis des années. Prévoyez une session de trente minutes avec toute l’équipe DevOps pour présenter les nouvelles commandes, les nouveaux garde-fous FinOps, et le calendrier de désinstallation de Terraform. Un changement d’outil mal communiqué génère plus d’incidents qu’un bug technique dans la migration elle-même.

Le projet complet : structure finale du dépôt

Une fois les douze étapes terminées, votre dépôt d’infrastructure as code ressemble à ceci.

mon-projet-iac/
├── main.tf                  # provider, backend S3, chiffrement du state
├── variables.tf              # cost_center, environment, validations
├── outputs.tf
├── policies/
│   └── instance-size.rego    # regles OPA FinOps
├── .github/
│   └── workflows/
│       └── opentofu-plan.yml # pipeline CI/CD
└── README.md                 # runbook mis a jour, plus de mention Terraform

Ce squelette tient sur moins de 200 lignes de HCL et de Rego combinées, mais couvre les quatre piliers du FinOps-as-Code : tagging forcé, policies de coût, protection dynamique contre les suppressions accidentelles, et automatisation du contrôle en pull request. C’est suffisant pour démarrer un vrai projet en production et l’étendre module par module.

Pour l’étendre, la prochaine étape logique consiste à découper main.tf en modules réutilisables dès que le dépôt dépasse une dizaine de ressources : un module réseau, un module de calcul, un module de stockage, chacun avec ses propres variables et sa propre validation FinOps. Cette structuration évite de retomber dans un fichier monolithique de plusieurs milliers de lignes, difficile à relire en pull request et encore plus difficile à faire auditer par une équipe de sécurité externe.

Terraform, OpenTofu, Pulumi : quel outil pour quel usage

CritèreTerraformOpenTofuPulumi
Version courante (août 2026)1.15.x1.12.63.249.0
LicenceBSLMozilla Public License 2.0Apache 2.0
GouvernanceHashiCorp / IBMCloud Native Computing FoundationPulumi Corporation
Langage principalHCLHCLTypeScript, Python, Go, .NET, Java, HCL
Chiffrement du state natifNonOui (depuis 1.8)Oui (Pulumi Cloud)
prevent_destroy dynamiqueNon (statique)OuiSelon le langage utilisé

Dans la pratique, ce choix n’a rien d’exclusif. Une équipe peut très bien garder Terraform sur des modules stables déjà validés, migrer les nouveaux projets vers OpenTofu pour bénéficier du chiffrement et des policies natives, et expérimenter Pulumi sur les cas où un vrai langage de programmation apporte une valeur ajoutée (boucles complexes, tests unitaires natifs, intégration avec du code applicatif existant).

Le facteur décisif reste souvent la taille de l’équipe et sa culture technique. Une petite équipe DevOps qui maîtrise déjà HCL a peu d’intérêt à réapprendre un langage de programmation complet juste pour gérer de l’infrastructure. À l’inverse, une équipe de plateforme qui code déjà en TypeScript ou en Go au quotidien gagnera du temps avec Pulumi, notamment pour écrire des tests unitaires sur la logique de provisioning, ce que HCL ne permet pas nativement même avec le framework de tests amélioré d’OpenTofu.

Questions fréquentes

OpenTofu est-il totalement compatible avec mon code Terraform existant ?
Dans la grande majorité des cas oui, puisqu’OpenTofu est un fork qui a conservé la syntaxe HCL et le format de state. Les divergences apparaissent surtout sur les fonctionnalités ajoutées après le fork, comme le chiffrement natif ou le prevent_destroy dynamique, qui n’ont pas d’équivalent côté Terraform.

Faut-il migrer tout le dépôt d’un coup ou module par module ?
Module par module est plus sûr. Commencez par un environnement de développement isolé, validez le comportement pendant une à deux semaines, puis élargissez progressivement aux environnements de production.

Le registre OpenTofu contient-il tous les providers dont j’ai besoin ?
Le registre recense plus de 3 900 providers, ce qui couvre la quasi-totalité des cas d’usage courants (AWS, Azure, GCP, Kubernetes, GitHub). Pour un provider très spécifique et récent, vérifiez sa disponibilité avant de vous engager sur un calendrier de migration serré.

Peut-on utiliser OpenTofu et Terraform sur le même state ?
Techniquement oui pendant une phase de transition courte, puisque le format de state reste compatible. Ce n’est cependant pas recommandé sur la durée, car les deux outils peuvent diverger progressivement sur certaines fonctionnalités.

Le chiffrement du state ralentit-il les commandes plan et apply ?
L’impact reste marginal sur des states de taille courante (quelques mégaoctets), le chiffrement AES-GCM étant conçu pour être rapide. Sur des states très volumineux dépassant plusieurs centaines de mégaoctets, testez la performance avant un déploiement à grande échelle.

Qu’advient-il de mes modules privés hébergés sur Terraform Cloud ?
Ils continuent de fonctionner avec Terraform. Pour les utiliser depuis OpenTofu, référencez-les directement via leur URL Git ou migrez-les vers un registre compatible OpenTofu, comme un registre privé sur GitHub Packages ou Artifactory.

Combien de temps faut-il prévoir pour migrer un projet de taille moyenne ?
Pour un projet d’une trentaine de ressources, comptez une demi-journée pour la migration technique décrite dans ce guide, plus une à deux semaines de période d’observation avant de désinstaller Terraform définitivement.

OpenTofu fonctionne-t-il avec Terraform Enterprise ou Terraform Cloud ?
Non directement. Terraform Cloud et Terraform Enterprise sont des produits propriétaires de HashiCorp conçus pour orchestrer des runs Terraform. Si vous migrez vers OpenTofu, vous devrez remplacer ces briques d’orchestration par une alternative comme un pipeline GitHub Actions autohébergé, Spacelift, ou Scalr, qui supportent nativement les deux moteurs.

Que se passe-t-il si je dois revenir en arrière après la migration ?
Restaurez le fichier de sauvegarde produit à l’étape 1 dans votre backend, puis réinitialisez avec terraform init -reconfigure en utilisant à nouveau le binaire Terraform. Comme OpenTofu n’altère pas le format du state, cette opération reste réversible tant que vous n’avez pas activé de fonctionnalité propre à OpenTofu, comme le chiffrement natif ou le prevent_destroy dynamique, qui n’ont pas d’équivalent lisible par Terraform.