# ADR-001 — Choix de l'outil Infrastructure-as-Code : Terraform vs Pulumi

**Date :** 2026-02-19
**Statut :** ACCEPTÉ
**Décideurs :** CTO, DevOps
**Sprint :** Sprint 1 (Spike de 4h)

---

## Contexte

Veylant IA requiert un outil IaC pour provisionner et gérer :
- Cluster EKS AWS (eu-west-3), 3 nodes
- VPC, subnets, security groups, NAT gateway
- Services managés futurs (RDS, ElastiCache)
- Ingress Traefik, certificats TLS

Le spike Sprint 1 avait pour objectif d'évaluer Terraform et Pulumi afin de choisir l'outil avant que l'infra ne soit créée.

---

## Options évaluées

### Option A — Terraform / OpenTofu

**Pour :**
- Module `terraform-aws-eks` v20.x (LTS) — EKS provisionné en <100 lignes HCL, testé par des milliers d'équipes
- HCL : déclaratif, diff lisible en PR, facile à code-reviewer
- Plan d'exécution (`terraform plan`) explicite et déterministe — pas de side-effects dans le code IaC
- Gestion d'état mature : S3 + DynamoDB lock (zéro lock cassé en prod)
- Documentation AWS exhaustive, Stack Overflow dense
- OpenTofu (fork open-source BSL → MPL) : pas de vendor lock-in HashiCorp

**Contre :**
- HCL limité pour la logique complexe (boucles `for_each` peuvent être verbeux)
- Pas de typage fort — erreurs découvertes à l'apply, pas à la compilation

### Option B — Pulumi (TypeScript)

**Pour :**
- TypeScript natif → réutilisable avec le reste du projet
- Logique complexe (conditions, boucles, fonctions réutilisables) en code natif
- Typage fort avec vérification à la compilation

**Contre :**
- Runtime intermédiaire (Pulumi engine) → debugging moins transparent qu'un plan HCL
- Communauté plus petite, moins de modules AWS prêts à l'emploi pour EKS
- Stack d'état hébergée par Pulumi Cloud par défaut (alternative self-hosted plus complexe)
- Courbe d'apprentissage pour le DevOps habitué à Terraform

---

## Décision

**Terraform / OpenTofu est retenu.**

### Raisons

1. **Risque réduit story E1-04** : Le module `terraform-aws-eks` est stable et documenté → réduit le risque principal de la story (EKS peut prendre 3+ jours sans outil mature).
2. **Expérience équipe** : Le profil DevOps a de l'expérience Terraform existante — pas de courbe d'apprentissage en Sprint 1.
3. **Lisibilité des PR** : Le `terraform plan` en HCL est lisible par tous (CTO, Backend) lors des reviews de changements infra.
4. **État sécurisé** : S3 + DynamoDB lock est éprouvé et simple à opérer.
5. **OpenTofu** : Le fork open-source est désormais stable (v1.7+) et évite le risque de changement de licence HashiCorp.

---

## Conséquences

- Créer un bucket S3 `veylant-terraform-state-eu-west-3` + table DynamoDB `veylant-terraform-lock` avant le premier `terraform apply`
- Structure : `deploy/terraform/` avec modules séparés (`vpc/`, `eks/`, `monitoring/`)
- Utiliser `terraform-aws-eks` v20.x
- Pinning des versions providers dans `versions.tf` (pas de `~>` ouvert)
- OpenTofu CLI installé via Homebrew : `brew install opentofu`

---

## Révision

Cette décision sera réexaminée si :
- La logique IaC devient significativement plus complexe (>500 lignes par module)
- L'équipe passe à TypeScript pour l'ensemble du stack (SDK natif V2)