OpenTofu 1.13 : ce qui change pour l'infra as code

OpenTofu 1.13, la nouvelle version de l'outil d'infrastructure as code né d'un fork de Terraform, est disponible depuis le 30 septembre. Au programme : un support officiel de Windows sur ARM64, de nouvelles fonctions pour réduire les valeurs inconnues lors de la planification et deux fonctionnalités expérimentales. La version apporte aussi plusieurs changements de compatibilité qui méritent une vérification avant de mettre à jour les pipelines. Un premier correctif, la 1.13.1, a suivi le 1er octobre.

Moins d'inconnues au moment du plan

C'est l'une des nouveautés les plus attendues par les auteurs de modules. Lorsqu'OpenTofu ne peut pas déterminer une valeur avant l'application, il l'affiche comme « connue après l'apply », ce qui peut bloquer certaines expressions ou rendre un plan difficile à relire. La 1.13 introduit une série de fonctions préfixées par assume... qui permettent de donner à l'outil des indications supplémentaires sur ces valeurs.

Le changelog mentionne aussi une nouvelle fonction convert, qui convertit une valeur vers une contrainte de type donnée. Autre amélioration pratique : les fichiers de plan enregistrés embarquent désormais les schémas de fournisseurs nécessaires à leur affichage.

Deux expérimentations : linting et bibliothèques de symboles

OpenTofu amorce un linting intégré, activable avec l'option -lint sur les commandes compatibles. Les mainteneurs le présentent comme une première étape, avec une possible extension future vers l'application de politiques.

Les Symbol Libraries constituent la seconde expérimentation : un nouveau type d'artefact, décrit comme une collection réutilisable de valeurs, de fonctions et d'alias de types, importable depuis les sources de modules. Elles s'activent via la liste experiments du bloc de langage. Comme toute fonctionnalité expérimentale, leur syntaxe peut encore évoluer : mieux vaut les tester hors production.

Chiffrement d'état et tests

Le chiffrement de l'état, l'un des arguments historiques du fork, progresse côté fournisseurs de clés. aws_kms accepte un champ encryption_context, gcp_kms une donnée authentifiée additionnelle optionnelle, et openbao un nouvel argument associated_data. Côté tests, tofu test prend désormais en charge les instances dans les surcharges de ressources, jokers compris.

Les points de vigilance avant de migrer

Les notes de mise à jour listent plusieurs ruptures :

• WinRM n'est plus pris en charge pour les provisioners. Les équipes concernées doivent basculer vers SSH.
• base64gzip produit un résultat équivalent mais pas identique à celui des versions précédentes, conséquence d'une mise à jour de Go. Les ressources qui l'utilisent peuvent afficher une modification, voire un remplacement, au prochain plan.
• macOS 13 Ventura devient la version minimale sur Mac.
• La série 1.13 est la dernière à proposer des binaires officiels 32 bits.
• Certains analyseurs de formats ont été durcis et peuvent rejeter des entrées invalides auparavant tolérées.

Le cas de base64gzip est le plus piégeux : un plan qui propose de remplacer une ressource après la mise à jour doit être relu avant d'être appliqué, pas validé par réflexe.

Comment aborder la mise à jour

La démarche classique reste la bonne : épingler la version dans la CI, lancer un tofu plan sur chaque environnement avec la 1.13.1 et comparer les écarts avant tout apply. Les équipes qui utilisent encore WinRM ou des agents 32 bits ont intérêt à traiter ces dépendances dès maintenant, puisque la prochaine série ne les couvrira plus.

Pour celles qui orchestrent aussi des conteneurs, cette mise à jour peut être planifiée en même temps que la migration vers Kubernetes 1.37, en gardant des fenêtres de changement distinctes pour isoler les régressions.