Un petit rappel : c'est quoi l'Infrastructure as Code ?

Avant de parler drama, remettons les bases à plat. L'Infrastructure as Code (IaC), c'est le fait de décrire son infrastructure (serveurs, réseaux, bases de données, buckets S3...) dans des fichiers texte plutôt que de cliquer manuellement dans des consoles cloud pendant des heures. Vous versionnez ça dans Git, vous relisez les changements comme du code, et hop, votre infra devient reproductible, traçable et beaucoup moins sujette aux erreurs humaines du vendredi 17h.

Terraform, développé par HashiCorp depuis 2014, est devenu l'outil de référence dans ce domaine. Multi-cloud, syntaxe déclarative en HCL (HashiCorp Configuration Language), un écosystème de providers énorme... Bref, un vrai standard de l'industrie.

Le coup de tonnerre de 2023

En août 2023, HashiCorp annonce qu'elle change la licence de Terraform (et de tous ses autres outils comme Vault ou Consul), en passant de la licence open source MPL 2.0 à la BSL (Business Source License). Concrètement, cette licence interdit aux entreprises de vendre des produits qui concurrencent directement les offres commerciales de HashiCorp.

Sur le papier, ça ne change rien pour 95% des utilisateurs qui utilisent Terraform pour gérer leur propre infra. Mais pour tout l'écosystème qui s'était construit autour (outils SaaS, plateformes de gestion IaC, alternatives managées...), c'était un coup dur. Des boîtes comme Spacelift, env0 ou Scalr se sont retrouvées dans une zone grise juridique.

La communauté a mal pris ce changement, perçu comme une trahison des valeurs open source qui avaient fait le succès de l'outil. Résultat : moins d'un mois après, un consortium d'une cinquantaine d'entreprises (dont Harness, Spacelift, Env0, Gruntwork) annonce le fork officiel : OpenTofu, hébergé par la Linux Foundation.

OpenTofu, le fils rebelle

OpenTofu repart de la dernière version de Terraform sous licence MPL 2.0 (la 1.5.6 pour les puristes) et continue son développement en licence open source classique. L'idée : garder un outil 100% compatible avec l'existant, sans les contraintes de la BSL.

Concrètement, si vous avez des fichiers .tf écrits pour Terraform, ils fonctionnent tel quel avec OpenTofu. Le binaire s'appelle tofu au lieu de terraform, mais la syntaxe HCL reste identique.

# Exemple de configuration compatible Terraform ET OpenTofu
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

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

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  tags = {
    Name = "youonline-server"
  }
}

Pour migrer, c'est presque déprimant de simplicité :

# On installe OpenTofu
brew install opentofu

# On lance exactement les mêmes commandes
tofu init
tofu plan
tofu apply

Qu'est-ce qui a réellement changé depuis ?

Depuis le fork fin 2023, OpenTofu a pris son envol de manière assez impressionnante. La version 1.7 a même introduit des fonctionnalités que Terraform n'avait pas encore, comme le state encryption natif (chiffrement du fichier d'état sans passer par un backend tiers) ou des boucles for_each plus flexibles sur les providers.

C'est une petite révolution dans le monde IaC : pour la première fois, le fork dépasse fonctionnellement l'original sur certains points. HashiCorp, de son côté, continue son développement de Terraform, avec l'appui de sa récente acquisition par IBM (finalisée en 2025), qui a rassuré une partie du marché sur la pérennité de l'outil.

Les vraies différences en 2025

  • Licence : BSL pour Terraform (usage commercial concurrent restreint) vs MPL 2.0 pour OpenTofu (open source pur)
  • Gouvernance : HashiCorp/IBM d'un côté, Linux Foundation avec gouvernance communautaire de l'autre
  • State encryption : natif dans OpenTofu, nécessite des solutions tierces dans Terraform
  • Compatibilité : quasi totale, la majorité des providers et modules fonctionnent sur les deux
  • Écosystème SaaS : les plateformes comme Spacelift ou Scalr supportent désormais les deux, sans discrimination

Alors, on choisit quoi pour un projet ?

Chez YouOnline, on a suivi ce dossier de près parce qu'on utilise l'IaC quasi systématiquement pour nos infras clients (serveurs, CDN, bases de données managées, etc.). Voici notre grille de lecture, sans langue de bois :

Partez sur Terraform si : vous êtes déjà dans l'écosystème HashiCorp (Vault, Consul, Nomad), que vous utilisez Terraform Cloud/Enterprise pour vos pipelines, ou que la stabilité et le support d'une grande entreprise (IBM derrière) vous rassure.

Partez sur OpenTofu si : vous démarrez un nouveau projet, que la philosophie open source compte pour vous, ou que vous voulez profiter des nouvelles fonctionnalités qui sortent parfois en avant-première (comme le chiffrement de state natif).

Pour un projet from scratch en 2025, on aurait tendance à recommander OpenTofu par défaut, sauf contrainte spécifique liée à l'écosystème HashiCorp existant. La compatibilité étant quasi parfaite, le risque de "mauvais choix" reste minime : migrer d'un outil à l'autre plus tard reste largement faisable.

Et niveau bonnes pratiques, ça change quoi ?

Peu importe l'outil choisi, les fondamentaux de l'IaC restent les mêmes. Quelques rappels qu'on martèle à nos clients :

  • Stockez toujours votre state dans un backend distant (S3 + DynamoDB, ou équivalent chez votre provider cloud), jamais en local sur votre laptop
  • Utilisez des modules réutilisables plutôt que de dupliquer du code HCL partout
  • Séparez vos environnements (dev, staging, prod) avec des workspaces ou des répertoires distincts
  • Passez systématiquement par une pull request et un plan avant tout apply en production
# Exemple de backend distant sécurisé
terraform {
  backend "s3" {
    bucket         = "youonline-terraform-states"
    key            = "prod/network/terraform.tfstate"
    region         = "eu-west-3"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

Le mot de la fin

Cette petite guerre de licences aura au moins eu un mérite : rappeler à toute l'industrie que la gouvernance des outils open source qu'on utilise au quotidien n'est jamais totalement gravée dans le marbre. Ça vaut le coup de garder un œil sur ces sujets, même quand on n'est "que" utilisateur final.

En attendant, que vous soyez Team Terraform ou Team OpenTofu, l'essentiel reste le même : arrêtez de cliquer manuellement dans la console AWS et codez votre infrastructure. Votre futur vous (et votre équipe) vous remerciera.

TerraformOpenTofuInfrastructure as CodeDevOpsCloud
Partager