📍 Article principal : Terraform Associate 004 — guide complet. Ce tutoriel construit un premier projet IaC complet sur Hetzner Cloud — provider hcloud, VPS, network privé, firewall, instance opérationnelle.

Hetzner est l’hébergeur idéal pour pratiquer Terraform à coût réduit : VPS à partir de 4,51 EUR par mois, API REST mature, provider Terraform officiel maintenu par Hetzner. Ce tutoriel guide pas à pas la construction d’un projet IaC complet : configuration du provider hcloud, déclaration de ressources VPS et network, application de firewall, vérification de l’état Terraform, destruction propre. À la fin, l’apprenant maîtrise les concepts fondamentaux nécessaires à la Terraform Associate et dispose d’un projet portfolio démontrable.

Prérequis

Compte Hetzner Cloud avec carte bancaire validée et solde minimal (5 à 10 EUR suffisent)
Token API Hetzner Cloud (généré dans la console projet)
Terraform 1.7+ installé localement
Notions de ligne de commande Linux et SSH
Niveau : débutant à intermédiaire
Temps estimé : 2 à 3 heures

Étape 1 — Préparer le projet et configurer le provider

Créer un dossier terraform-hetzner-projet avec une structure standard : fichier main.tf pour les ressources principales, variables.tf pour les variables d’entrée, outputs.tf pour les valeurs de sortie, providers.tf pour la configuration des providers. Cette séparation par fichier améliore la lisibilité et facilite la maintenance — pratique attendue dès les premiers projets en production.

terraform {
  required_version = ">= 1.7.0"
  required_providers {
    hcloud = {
      source  = "hetznercloud/hcloud"
      version = "~> 1.45"
    }
  }
}

provider "hcloud" {
  token = var.hcloud_token
}

Le bloc required_providers verrouille la version du provider à la dernière majeure compatible — bonne pratique qui évite les surprises lors d’upgrades involontaires. Le token Hetzner passe par variable au lieu d’être hardcodé : jamais de secret dans le code Git. Définir la variable dans variables.tf sans valeur par défaut, et la fournir via terraform.tfvars non versionné ou via la variable d’environnement TF_VAR_hcloud_token.

Étape 2 — Initialiser et valider le projet

Lancer terraform init dans le dossier projet. Terraform télécharge le provider hcloud, crée le dossier .terraform qui contient les binaires, et génère le fichier .terraform.lock.hcl qui verrouille les versions exactes des providers. Ce lockfile doit être versionné dans Git pour garantir des builds reproductibles entre développeurs et environnements.

Lancer ensuite terraform validate pour vérifier la syntaxe HCL et la cohérence des références entre ressources. Lancer terraform fmt pour formater automatiquement les fichiers selon les conventions HashiCorp — espacement, alignement, indentation. Cette commande devrait être exécutée à chaque modification, idéalement via un hook Git pre-commit qui automatise la vérification.

Étape 3 — Déclarer le réseau et les firewalls

Sur Hetzner, créer d’abord un Network privé qui isolera les VPS du trafic public. Puis un Firewall qui définit les règles d’entrée et de sortie autorisées. Enfin attacher ces ressources aux VPS qui seront créés. Cette structure modulaire est la base de toute infrastructure cloud sérieuse — pratiquée dès le premier projet, elle devient un automatisme.

resource "hcloud_network" "main" {
  name     = "tf-network"
  ip_range = "10.0.0.0/16"
}

resource "hcloud_network_subnet" "main" {
  network_id   = hcloud_network.main.id
  type         = "cloud"
  network_zone = "eu-central"
  ip_range     = "10.0.1.0/24"
}

resource "hcloud_firewall" "ssh" {
  name = "tf-fw-ssh"
  rule {
    direction = "in"
    protocol  = "tcp"
    port      = "22"
    source_ips = ["0.0.0.0/0"]
  }
}

Cette configuration crée un Network avec un sous-réseau dans la zone eu-central de Hetzner (Falkenstein), et un Firewall qui autorise SSH depuis n’importe où. En production réelle, restreindre la source SSH à des IPs spécifiques. La référence inter-ressources via hcloud_network.main.id illustre le graphe de dépendances que Terraform résout automatiquement.

Étape 4 — Créer un VPS attaché aux ressources réseau

La ressource hcloud_server représente un VPS Hetzner. Configurer le type d’instance (cx22 pour le moins cher), l’image (ubuntu-24.04), la zone de disponibilité, la clé SSH pour l’accès initial, l’attachement au network privé, et le firewall associé. Le cloud-init permet de personnaliser le serveur dès le premier boot — installer un package, configurer un service, déposer un fichier.

resource "hcloud_ssh_key" "default" {
  name       = "tf-key"
  public_key = file("~/.ssh/id_ed25519.pub")
}

resource "hcloud_server" "web" {
  name         = "tf-web"
  server_type  = "cx22"
  image        = "ubuntu-24.04"
  location     = "fsn1"
  ssh_keys     = [hcloud_ssh_key.default.id]
  firewall_ids = [hcloud_firewall.ssh.id]
  network {
    network_id = hcloud_network.main.id
  }
  user_data = file("cloud-init.yaml")
}

Le fichier cloud-init.yaml en regard contient la configuration de bootstrap : #cloud-config en première ligne puis les directives standards (packages à installer, fichiers à créer, commandes à exécuter). Cette approche garantit que le VPS est immédiatement opérationnel sans intervention manuelle, principe IaC fondamental.

Étape 5 — Plan, apply et vérification

Lancer terraform plan pour visualiser le plan d’exécution : Terraform liste les ressources à créer, modifier, détruire avec leur impact estimé. Examiner attentivement la sortie — la maîtrise de la lecture du plan est testée à l’examen. Pour les modifications complexes, ajouter -out=tfplan qui sauvegarde le plan pour réutilisation, garantissant que le apply correspond exactement au plan validé.

Lancer terraform apply. Terraform crée les ressources dans l’ordre du graphe de dépendances — d’abord le network, puis le subnet, puis le firewall, enfin le server. L’opération prend deux à trois minutes au total. À la fin, le state local terraform.tfstate contient l’état complet des ressources créées avec leurs IDs, IPs, attributs.

Vérifier : terraform state list affiche les ressources gérées, terraform state show hcloud_server.web détaille l’état complet du VPS. Tester aussi la connexion SSH avec l’IP publique retournée. Une fois la validation complète, supprimer proprement avec terraform destroy qui détruit les ressources dans l’ordre inverse de la création.

Étape 6 — Variables, outputs et bonnes pratiques

Pour rendre le projet réutilisable, paramétrer via variables. Les variables typiques : nom du projet, taille de VPS, image, location, clé SSH path. Définir dans variables.tf avec types et valeurs par défaut. Surcharger via terraform.tfvars pour les valeurs spécifiques au déploiement. Pour l’examen, mémoriser que la précédence est : CLI -var → tfvars → auto.tfvars → variables d’environnement → defaults.

Les outputs exposent les valeurs intéressantes après apply : IP publique du serveur, hostname, ID du network. Définis dans outputs.tf, ils s’affichent à la fin de l’apply et sont récupérables via terraform output. Pour les outputs sensibles (mots de passe, tokens), ajouter sensitive = true qui masque la valeur dans les logs.

Patterns avancés à pratiquer

Au-delà du provisioning de base, plusieurs patterns avancés méritent d’être pratiqués. Premier : count et for_each pour créer plusieurs instances. Le for_each itère sur une map et permet de créer N ressources avec des configurations spécifiques : idéal pour déployer un cluster web de plusieurs frontaux. Deuxième : data sources pour lire l’état de ressources externes — par exemple lire le dernier ID d’image Ubuntu disponible chez Hetzner sans le hardcoder.

Troisième pattern : locals pour calculer des valeurs intermédiaires lisibles. Au lieu de répéter une expression complexe plusieurs fois, la stocker dans un local et la référencer. Quatrième : dynamic blocks pour générer dynamiquement des blocs de configuration imbriqués selon une variable d’entrée — utile pour les rules de firewall ou les ports d’un load-balancer dont le nombre varie. Pratiquer ces quatre patterns sur le projet Hetzner construit l’aisance technique attendue par l’examen.

Workflow Git et collaboration

En production réelle, Terraform s’utilise en équipe. Quelques règles de discipline collaborative. Premier : ne jamais committer terraform.tfstate ni terraform.tfvars (qui contiennent des secrets) — ajouter ces fichiers à .gitignore dès le début. Deuxième : utiliser un backend remote (S3, Consul, HCP) qui stocke le state de manière partagée et avec locking — sujet du tutoriel suivant. Troisième : structurer le code en modules qui exposent des variables d’entrée et des outputs clairs.

Quatrième règle : chaque modification passe par une pull request avec terraform plan automatiquement exécuté en CI. La revue se fait sur le plan plus que sur le code, car c’est l’effet réel qui compte. Cinquième : les apply en production se font uniquement depuis la CI/CD, jamais depuis le laptop d’un développeur — discipline qui prévient les modifications non documentées et garantit la traçabilité complète des changements infrastructure.

Coût et optimisation

Pour minimiser les coûts pendant la pratique, deux disciplines. Première : terraform destroy systématique à la fin de chaque session de travail — un VPS oublié peut faire grimper la facture en quelques jours. Deuxième : utiliser uniquement les types d’instance les moins chers (cx22 à 4,51 EUR/mois, facturé à l’heure soit 0,006 EUR par heure de pratique). Pour un mois entier de préparation Terraform Associate, le coût total Hetzner reste sous 5 EUR si la discipline est respectée.

Pour les apprenants qui veulent encore réduire, alternative gratuite : utiliser le simulateur Killercoda qui propose des environnements Terraform interactifs en navigateur, gratuits et limités à 1 heure par session. Moins flexible que Hetzner mais zero coût et zéro setup. Combiner les deux selon le budget et le besoin : Killercoda pour les exercices simples, Hetzner pour les projets complets multi-ressources.

Erreurs fréquentes

Erreur	Cause	Solution
Token Hetzner refusé	Token expiré ou portée insuffisante	Régénérer dans la console projet avec scope read+write
Provider non trouvé au init	Bloc required_providers manquant	Toujours déclarer source et version explicites
Plan différent à chaque exécution	Resource avec dépendances dynamiques mal modélisées	Utiliser depends_on explicite si Terraform ne détecte pas la dépendance
Ressource orpheline après destroy partiel	Erreur en cours de destruction	Vérifier la console Hetzner, supprimer manuellement et terraform state rm

Adaptation au contexte ouest-africain

Pour les apprenants ouest-africains, Hetzner est l’hébergeur le plus accessible pour pratiquer Terraform — comptes ouverts en quelques minutes, paiement par carte Mastercard locale, support email réactif. La latence vers Falkenstein reste autour de 80 ms depuis Dakar ou Abidjan, parfaitement acceptable pour les opérations Terraform qui ne sont pas latence-sensibles. Pour ceux qui préfèrent un hébergement local, le provider Wagaden Cloud est en cours de développement — vérifier sa disponibilité au moment de la pratique.

Évolution vers les modules

Une fois ce projet maîtrisé, transformer le code en module réutilisable. Créer un dossier modules/web-server qui encapsule la logique de déploiement d’un VPS web complet (server + firewall + DNS). Le module expose des variables d’entrée (nom, taille, image) et des outputs (IP, hostname). L’utilisation devient : module "site_principal" { source = "./modules/web-server"; name = "prod" }. Cette modularisation facilite la duplication d’environnements (dev, staging, prod) et constitue le pattern de référence en production.

Pour aller plus loin, publier le module sur le HCP Terraform Registry privé ou sur GitHub. Cette publication permet à toute l’équipe d’utiliser le module avec versioning. Le tutoriel dédié aux modules réutilisables détaille cette progression et les bonnes pratiques de design des modules pour PME ouest-africaines.

Provisionner aussi le DNS et les certificats

Pour aller plus loin que le simple VPS, automatiser aussi le DNS et les certificats. Le provider Cloudflare permet de gérer la zone DNS du domaine : créer un record A qui pointe vers l’IP publique du VPS, un record CNAME pour les sous-domaines, configurer les enregistrements MX, SPF si nécessaire. Cette intégration multi-provider démontre la puissance de Terraform — orchestrer plusieurs services indépendants depuis le même fichier de configuration.

Pour les certificats Let’s Encrypt automatisés, utiliser le provider acme avec le DNS challenge via Cloudflare. Le certificat est généré, validé, et déposé dans un fichier local utilisable par Nginx. À chaque terraform apply, Terraform vérifie l’expiration et renouvelle si nécessaire. Cette automatisation complète, du DNS au certificat, illustre la valeur de l’IaC : en 100 lignes de HCL, on gère ce qui demanderait des heures de configuration manuelle.

Documentation et schémas d’architecture

Un projet Terraform sérieux mérite une documentation. Créer un README qui explique le projet, les ressources créées, les variables à configurer, les commandes pour démarrer. Pour les projets multi-ressources, ajouter un schéma d’architecture généré automatiquement avec terraform graph et converti en image via Graphviz. Ce schéma visuel facilite la compréhension par les nouveaux arrivants et constitue un atout marketing lors des entretiens.

L’outil terraform-docs génère automatiquement la documentation des modules à partir des commentaires HCL et des descriptions de variables. Intégrer cette génération dans un hook Git pre-commit garantit que la documentation reste alignée avec le code. Cette discipline simple distingue les projets professionnels des prototypes amateurs et démontre la maturité opérationnelle de l’auteur.

Cette discipline professionnelle de documentation et de versioning transforme l’apprentissage Terraform en savoir-faire transmissible et durable, condition essentielle pour évoluer du statut d’apprenant au statut de référent technique reconnu dans l’organisation.

Pour les apprenants ITSkillsCenter, ce premier projet Hetzner constitue le rite de passage vers la maîtrise opérationnelle réelle de Terraform et ouvre la voie à des constructions plus ambitieuses dans les semaines suivantes.

Cette progression méthodique et documentée fait toute la différence sur le marché professionnel ouest-africain où la concurrence technique se renforce chaque année avec l’émergence de nouveaux talents formés.

Investir dans cette discipline reste l’un des leviers les plus efficaces pour faire émerger durablement son profil professionnel.

Pour aller plus loin

🔝 Retour à l’article principal : Terraform Associate 004. Documentation provider hcloud : registry.terraform.io/providers/hetznercloud/hcloud. Cette première pratique pose les fondations — la suite logique consiste à externaliser le state vers un backend remote pour permettre le travail en équipe et la production réelle.

Documenter ce premier projet dans un dépôt Git public permet aussi de le mettre en avant lors des entretiens d’embauche. Un README détaillé qui explique le projet, l’architecture, les choix techniques fait souvent la différence entre deux candidats avec la même certification. Cet investissement marketing simple constitue l’un des leviers les plus rentables pour valoriser sa préparation au-delà du simple papier.

Provisioning Hetzner avec Terraform — premier projet IaC pour PME 2026