🧱 OpenTofu : décrire son infrastructure en code (le fork libre de Terraform)

📚 Introduction

Un homelab commence toujours de la même façon : on clique dans une interface web, on ouvre trois SSH, on installe un paquet ici, on ajuste un fichier là. Puis six mois passent, un disque lâche, et personne, pas même moi, ne sait remonter la machine à l’identique. C’est le problème que résout l’Infrastructure as Code (IaC) : décrire l’infrastructure dans des fichiers versionnés, au lieu de la construire à la main.

L’outil de référence a longtemps été Terraform. Depuis 2023, il a un jumeau open source : OpenTofu, un fork sous licence MPL 2.0 gouverné par la Linux Foundation. La version 1.12.5 est sortie en juillet 2026. C’est celui que j’utilise pour piloter mon homelab Proxmox, et c’est le sujet du jour.

🔎 OpenTofu ou Terraform, quelle différence ?

OpenTofu est né d’une bascule de licence. En août 2023, HashiCorp a fait passer Terraform sous BSL (Business Source License) : une licence qui autorise beaucoup d’usages mais restreint le commercial et n’est plus open source. En réaction, la communauté a forké la dernière version MPL de Terraform. Le projet a rejoint la Linux Foundation en septembre 2023 sous le nom d’OpenTofu, et sa première version stable (1.6, janvier 2024) était compatible avec Terraform 1.5.x.

Concrètement, pour qui débute, la différence est faible : même langage HCL, mêmes blocs terraform {}, mêmes providers, même ligne de commande, à ceci près que la commande s’appelle tofu au lieu de terraform. La vraie différence est juridique et politique : OpenTofu reste open source, sous gouvernance ouverte. Pour un projet perso comme pour une boîte, c’est une garantie de pérennité qui compte.

🚀 Le cycle : write, plan, apply

L’installation tient en une ligne via Homebrew, ou via le script officiel :

# via Homebrew (macOS / Linux)
brew install opentofu
 
# ou le script d'installation 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
rm -f install-opentofu.sh

Ensuite, tout tourne autour d’une boucle de trois commandes. On écrit l’état souhaité dans un fichier .tf, on prévoit les changements, on applique.

Voici le plus petit exemple qui tourne vraiment. Il crée un simple fichier local, mais la mécanique est identique pour une VM ou un bucket :

terraform {
  required_providers {
    local = {
      source = "hashicorp/local"
    }
  }
}
 
resource "local_file" "hello" {
  content  = "Bonjour depuis OpenTofu\n"
  filename = "${path.module}/hello.txt"
}

tofu init      # télécharge le provider déclaré
tofu plan      # montre ce qui va changer, sans rien toucher
tofu apply     # applique, après confirmation
tofu destroy   # supprime tout ce qui a été créé

Le plan est le cœur du modèle : il te montre exactement ce qui va être créé, modifié ou détruit avant d’agir. Plus de mauvaise surprise, plus de « je croyais que… ».

🧱 Providers et state

Deux notions à comprendre pour aller plus loin.

Un provider est le plugin qui parle à une plateforme donnée. Le fichier ci-dessus utilise hashicorp/local ; pour du concret, on branchera plutôt kreuzwerker/docker pour des conteneurs, bpg/proxmox pour des VMs Proxmox, ou hashicorp/aws, éventuellement contre un LocalStack en local pour tester sans facture. Le code change à peine : c’est toujours des blocs resource.

Le state est le fichier où OpenTofu note ce qu’il a réellement créé. C’est sa source de vérité : au prochain plan, il compare ton code au dernier état connu pour calculer le diff. C’est aussi le fichier le plus sensible du projet.

⚠️ Quelques précautions

• Le state contient des secrets en clair. Mots de passe, clés générées : ils atterrissent dans le fichier d’état. On ne le commite jamais tel quel dans Git. Pour un usage à plusieurs, on passe à un backend distant (S3, un stockage compatible, etc.) avec verrouillage, pour éviter que deux apply se marchent dessus.
• On ne modifie pas le state à la main. Il se manipule via les commandes (tofu state …), jamais à l’éditeur.
• Attention au drift. Si tu modifies une ressource à la main après l’avoir créée avec OpenTofu, le code et le réel divergent. La règle d’or : une fois qu’une ressource est gérée en IaC, on ne la touche plus que par le code.

🎉 Conclusion

OpenTofu, c’est la discipline de l’IaC sans le risque de licence : ton infrastructure décrite dans des fichiers versionnés, un plan qui te dit la vérité avant d’agir, et un écosystème de providers immense hérité de Terraform. Pour un homelab, commence petit (un fichier local, puis une VM Proxmox) et laisse la boucle write/plan/apply devenir un réflexe. Le jour où un disque lâchera, tu remonteras tout d’un tofu apply.

🔗 Liens utiles

• OpenTofu — site officiel
• OpenTofu — installation
• OpenTofu sur GitHub
• Linux Foundation — annonce d’OpenTofu