Transformer l'Infrastructure avec Terraform et Automation

Introduction

Terraform est mon outil d'Infrastructure as Code depuis 2018. De la gestion de VPC simples à l'architecture AWS Multi-Compte de 25 modules chez F2R2, en passant par le multi-cloud chez Bloomflow (AWS, Outscale, OVH) et la migration GCP vers AWS chez Earny SA, Terraform a prouvé sa valeur sur chaque projet. En 7 ans de pratique intensive, j'ai développé des patterns et des convictions fortes sur la bonne manière d'utiliser cet outil. Voici un retour d'expérience approfondi.

Les modules Terraform : l'art de la réutilisation à grande échelle

Chez F2R2, j'ai conçu 25 modules Terraform organisés par responsabilité. Le module vpc crée le réseau complet avec subnets publics et privés dans 3 AZ, NAT Gateway avec Elastic IP, flow logs vers CloudWatch, et les routes tables associées. Le module eks crée le cluster Fargate avec les profils de compute, les addons (CoreDNS, VPC CNI, kube-proxy), et les IAM roles pour le service account. Le module aurora crée le cluster PostgreSQL multi-AZ avec chiffrement au repos, paramètre group optimisé et snapshots automatiques quotidiens.

Chaque module est autonome : il ne dépend que de ses inputs (variables) et expose ses outputs. Les inputs sont documentés avec des descriptions et des validations (variable "instance_class" { validation { condition = ... } }). Les outputs permettent de connecter les modules entre eux : l'output vpc_id du module VPC est l'input du module EKS. Pour créer un nouvel environnement complet, il suffit d'instancier ces 25 modules avec les variables appropriées dans un fichier main.tf de 200 lignes. Temps de provisionnement : 45 minutes au lieu de 3 jours en configuration manuelle dans la console AWS.

Le state : la source de vérité qu'il faut protéger

Le state Terraform est le coeur du système. Il enregistre l'état réel de l'infrastructure et permet à Terraform de calculer les diffs entre l'état actuel et l'état désiré. Mal géré, c'est la première source de problèmes avec Terraform. Ma configuration standard, appliquée sur chaque projet depuis 2019 : le state dans S3 avec versioning activé (pour récupérer un state corrompu), DynamoDB pour le locking (pour empêcher les apply concurrents), et chiffrement côté serveur SSE-S3.

Chez Bloomflow, un développeur avait un jour lancé un terraform apply en local pendant qu'un pipeline GitHub Actions en faisait un autre. Sans le locking DynamoDB, les deux apply auraient modifié le state simultanément, créant une corruption quasi-impossible à résoudre. Le lock a bloqué l'apply local avec un message clair : "Error: Error locking state. Another terraform apply is in progress." Chez F2R2, chaque environnement (dev, staging, prod) avait son propre bucket S3 et sa propre table DynamoDB, dans des comptes AWS séparés. Un apply sur l'environnement dev ne pouvait physiquement pas corrompre le state de production.

Terraform dans la CI/CD : le GitOps de l'infrastructure

Terraform dans GitHub Actions suit un pattern que j'ai affiné sur une dizaine de projets. Le job "plan" s'exécute sur chaque pull request et poste le plan en commentaire pour review par l'équipe. Le reviewer voit exactement quelles ressources seront créées, modifiées ou détruites, et peut demander des ajustements avant le merge. Le job "apply" s'exécute après merge sur main, récupère le plan exact qui a été reviewé et l'applique.

Chez F2R2, j'ai ajouté trois étapes de validation avant le plan : tflint pour détecter les mauvaises pratiques HCL (variables inutilisées, types de ressources dépréciées), tfsec pour l'analyse de sécurité statique (security groups trop permissifs, buckets S3 sans chiffrement, IAM policies trop larges), et terraform-docs pour la génération automatique de documentation à partir des commentaires du code. Un changement d'infrastructure suit exactement le même processus qu'un changement de code : branche, PR, review, merge, apply. C'est du GitOps pour l'infrastructure, et c'est la seule manière de gérer l'IaC en équipe.

Multi-cloud : la promesse tenue de Terraform

Terraform est l'un des rares outils qui tient vraiment sa promesse de multi-cloud. Chez Bloomflow, pendant mes 5 ans, je gérais des ressources sur AWS (la majorité), Outscale (pour les clients SecNumCloud DGE) et OVH Cloud (pour le cluster Kubernetes Metronome). Chaque provider a son module Terraform avec ses ressources spécifiques, mais la syntaxe HCL, le workflow plan/apply et le state management sont identiques.

Chez Earny SA, la migration GCP vers AWS a été facilitée par Terraform de manière décisive. J'ai d'abord écrit les modules Terraform pour la nouvelle infrastructure AWS. Le terraform plan a généré un inventaire complet des ressources à créer : VPC, EKS, Aurora, S3, CloudFront. Ce plan a été présenté au client dans une réunion technique : ils ont pu voir exactement l'infrastructure cible, poser des questions, demander des ajustements -- tout ça avant de créer une seule ressource AWS. Le plan validé, j'ai exécuté terraform apply. L'infrastructure cible était prête en 45 minutes. La migration des données et des workloads a pris 2 jours supplémentaires, sans downtime grâce au dual-write temporaire. Zero surprise.

Les pièges courants : leçons apprises à mes dépens

Premier piège : le drift. Si quelqu'un modifie une ressource dans la console AWS, le state Terraform diverge de la réalité. Chez Bloomflow, un terraform plan quotidien dans la CI (cron GitHub Actions à 8h) détectait les drifts et envoyait une alerte Discord. La règle absolue : toute modification en console doit être réimportée dans le state avec terraform import ou annulée. Pas de demi-mesure.

Deuxième piège : les modules trop couplés. Un module qui dépend de 5 autres modules crée un spaghetti de dépendances impossible à maintenir. Chez F2R2, chaque module est autonome : il prend des IDs en input, pas des data sources qui requêtent l'API AWS. Troisième piège : ne pas verrouiller les versions des providers. Chez un client avant ma mission, un upgrade automatique du provider AWS de 4.x à 5.x a changé le comportement d'une ressource et créé un plan de destruction/recréation d'un cluster EKS en production. Toujours épingler les versions dans required_providers et les monter consciemment.

Conclusion

Terraform a transformé ma pratique de l'infrastructure en la rendant reproductible, traçable et collaborative. L'Infrastructure as Code n'est pas un buzzword : c'est une discipline qui réduit les coûts de 19% (F2R2), accélère le provisionnement de 3 jours à 45 minutes, et élimine les erreurs de configuration manuelle. Les modules réutilisables, le state management rigoureux, l'intégration CI/CD et les bonnes pratiques de sécurité font de Terraform un outil indispensable dans la boîte à outils DevOps.