OpenTofu 1.13 : le chiffrement de state face à Terraform

Le 29 septembre 2026, OpenTofu a publié sa version 1.13. Le changelog tient en quatre fonctionnalités mises en avant et quatre changements cassants — rien de spectaculaire sur le papier. Sauf qu’en creusant la partie chiffrement du state, maintenue depuis plusieurs versions mais étendue ici, on retombe sur l’argument le plus concret en faveur d’OpenTofu face à Terraform depuis le fork lui-même : Terraform ne chiffre toujours pas nativement le contenu de son state. Voici ce qui change avec cette version, et pourquoi ça pèse dans la balance si tu hésites encore entre les deux outils.

Ce qui change avec la 1.13

Le chiffrement du state gagne trois mécanismes de contexte

Le bloc encryption dans terraform { } existe depuis plusieurs versions. Sa structure reste la même : un ou plusieurs key_provider, une method qui référence ces clés, puis un bloc state et un bloc plan qui pointent vers cette méthode.

terraform {
  encryption {
    key_provider "pbkdf2" "mykey" {
      passphrase = var.state_passphrase  # minimum 16 caractères
    }
    method "aes_gcm" "mymethod" {
      keys = key_provider.pbkdf2.mykey
    }
    state {
      method = method.aes_gcm.mymethod
    }
    plan {
      method = method.aes_gcm.mymethod
    }
  }
}

Les fournisseurs de clés supportés couvrent la quasi-totalité des cas réels : passphrase dérivée via PBKDF2, AWS KMS, GCP KMS, Azure Key Vault, le moteur Transit d’OpenBao (compatible HashiCorp Vault 1.14), et un provider générique external qui exécute ton propre programme — OVHcloud maintient d’ailleurs son propre provider KMS basé sur ce mécanisme.

La vraie nouveauté de la 1.13 porte sur le contexte de déchiffrement. GCP KMS reçoit un champ additional_authenticated_data, AWS KMS un champ encryption_context, OpenBao un argument associated_data. Dans les trois cas, le principe est identique : la clé seule ne suffit plus à déchiffrer un state. Il faut aussi que le contexte (nom du projet, environnement, équipe…) corresponde. Concrètement, une clé AWS KMS volée ou mal cloisonnée entre deux comptes ne permet plus de déchiffrer le state d’un environnement qui n’est pas le sien.

Le reste du changelog, en bref

Windows ARM64 passe en support officiel, avec des binaires publiés directement (certains providers tiers ne suivent pas encore). La fonction convert permet de déclarer explicitement le type attendu d’une valeur inconnue au moment du plan — utile pour calmer le bruit des diffs quand un module retourne une valeur qui ne sera connue qu’à l’apply. Dans le même esprit, les fonctions assume... laissent l’auteur d’un module affirmer une propriété sur une valeur inconnue (non nulle, préfixe donné…) : si l’affirmation est fausse à l’apply, l’opération échoue plutôt que de produire un résultat silencieusement incohérent.

Deux fonctionnalités expérimentales complètent la liste : un linter activable via le flag -lint sur les commandes qui le supportent, et des « Symbol Libraries », des artefacts réutilisables de valeurs, de fonctions et de types importables depuis les mêmes sources que les modules.

Ce qui casse en mettant à jour

Quatre points à vérifier avant de passer en 1.13 :

• Le provisioner WinRM disparaît complètement pour remote-exec et file — un bloc connection avec type = "winrm" devient une erreur. OpenTofu recommande de migrer vers OpenSSH côté Windows.
• La sortie de base64gzip change : elle reste équivalente, mais plus identique octet par octet, à cause d’une compression DEFLATE optimisée. Tu peux voir apparaître des diffs sur des arguments qui en dépendent — un ignore_changes temporaire fait l’affaire en attendant.
• macOS 13 Ventura devient la version minimale supportée pour les builds macOS.
• La 1.13 est la dernière série à publier des binaires 32 bits (386, arm) officiels — un avertissement s’affiche déjà sur tofu init sur ces plateformes, et la 1.14 ne les inclura plus.

Et côté Terraform, qu’est-ce qui existe d’équivalent ?

Rien. C’est la différence structurelle la plus nette entre les deux outils aujourd’hui. La documentation officielle de HashiCorp le dit sans détour : « tu peux chiffrer ton state au repos, mais la méthode de chiffrement dépend de ton backend spécifique ». Sur S3, ça veut dire activer l’option encrypt du backend. Sur GCS, utiliser des clés gérées par le client. Sur HCP Terraform, le chiffrement est automatique. En stockage local, le state reste un fichier en clair, point final — HashiCorp recommande juste de ne jamais le committer et de le traiter comme sensible.

Ça fonctionne, mais ça reste un chiffrement de transport ou de stockage externe à l’outil, pas un chiffrement du contenu piloté par Terraform lui-même. Si ton backend est mal configuré, ou si quelqu’un récupère une copie du fichier state hors backend (un export, un backup oublié sur un poste), le contenu est lisible — secrets inclus, puisque le state contient souvent des valeurs sensibles en clair malgré les bonnes pratiques.

On avait déjà creusé la question du choix entre les deux outils dans notre comparatif OpenTofu vs Terraform en 2026, à l’époque surtout sous l’angle licence et écosystème de providers. Un an plus tard, l’écart sur le chiffrement du state mérite d’être ajouté à la liste — pas comme argument décisif à lui seul, mais comme point concret si la sensibilité de ton state (comptes de service, mots de passe de bases de données, clés d’API) te pèse déjà.

Migrer un projet existant vers le chiffrement OpenTofu

La bascule n’a rien d’instantané ni d’automatique, et c’est volontaire. Ajoute le bloc encryption à ta configuration, génère une passphrase d’au moins 16 caractères (ou configure ton KMS), passe-la via une variable jamais committée — un coffre de secrets, pas un fichier .tfvars versionné. Au tofu plan suivant, OpenTofu re-chiffre le state existant selon la méthode déclarée ; garde une copie de l’ancien state en lieu sûr avant de lancer l’opération, histoire de pouvoir revenir en arrière si la configuration du provider de clé a un défaut que tu n’as pas vu venir.

Pour des équipes qui partagent un seul backend entre plusieurs environnements — un cas plus courant qu’il ne devrait l’être, faute de temps pour en séparer les accès — ajouter encryption_context ou additional_authenticated_data dès cette migration coûte une ligne de configuration et change concrètement qui peut lire quoi en cas de fuite de clé.

FAQ

Faut-il absolument chiffrer son state si on utilise déjà un backend S3 avec encrypt = true ?

Ça dépend de ce que tu veux couvrir. Le chiffrement du backend protège le fichier stocké sur S3. Le chiffrement OpenTofu protège le contenu lui-même, y compris s’il sort du backend — une copie locale, un export, un transfert. Les deux ne sont pas redondants, ils couvrent des scénarios de fuite différents.

Le chiffrement ralentit-il les commandes plan et apply ?

Le surcoût vient uniquement du chiffrement et du déchiffrement AES-GCM du fichier state, qui reste de taille modeste pour l’écrasante majorité des projets. Sur un state de plusieurs centaines de ressources, la différence n’est pas perceptible à l’usage.

Est-ce que je peux migrer progressivement, environnement par environnement ?

Oui, rien n’empêche d’activer le chiffrement sur un seul environnement d’abord — staging, par exemple — pour valider la configuration du key provider avant de la généraliser à la prod.

OpenTofu 1.13 reste-t-il compatible avec un state produit par Terraform ?

Oui pour la lecture d’un state existant non chiffré. La bascule vers le chiffrement OpenTofu est une étape volontaire que tu déclenches toi-même, pas un changement de format imposé à l’import.

Si ton état actuel repose sur un simple encrypt = true côté backend et que tu veux passer à l’étape suivante, la note de version officielle 1.13.0 et le changelog complet sur GitHub listent tout le détail technique nécessaire avant de te lancer. Si tu es encore sur Terraform et que cet article te fait hésiter, on a aussi de quoi suivre ce que la 1.17 bêta de Terraform apporte de son côté avant de trancher.