feat(infra): Terraform provisionne la VM, GitHub Actions continue de déployer

Le seul Terraform du dépôt installait un cluster k3s que rien ne consomme, et
sa racine ne passait même pas `terraform init` : depuis Terraform 1.x, un
provisioner `destroy` impose que tout le bloc `connection` ne lise que `self`,
et celui du module k3s lisait `var.*`. Il est corrigé en batissant la connexion
sur `triggers`, où ne figurent que l'adresse, le port, l'utilisateur et le
chemin de la clé : jamais la clé ni un mot de passe.

`environments/vm-eni` provisionne la machine qui porte la recette et la
production : Docker et le plugin Compose, `scripts/provision-host.sh`, puis
l'enregistrement du runner. Rien n'y construit d'image ni ne lance de
conteneur, et un `apply` n'interrompt pas la stack qui tourne. Le déploiement
continu ne bouge pas : `deploy.yml` reste le seul chemin de livraison.

`environments/dev` devient `k3s-cible`, parce qu'il provisionnait un cluster et
pas un environnement applicatif, et que `rec` et `prod` vivent sur la même
machine. `environments/prod`, dossier vide, disparaît.

`infra.yml` formate et valide chaque racine à chaque push : c'est l'absence
d'un tel job qui a laissé ce Terraform cassé sans que rien ne le dise. La
boucle parcourt `environments/*`, une racine ajoutée est couverte sans y
toucher.

ADR 0010 pour la frontière entre provisionnement et livraison, et la doc
d'architecture alignée dessus.

docs/architecture/00-vue-ensemble.md

@@ -87,10 +87,10 @@ collecteur ne vient le lire.
 | Frontend | Angular 22, Node 24 | `apps/frontend` | `En cours` | Tableau de bord sur route `/dashboard`, authentification complète (garde de route, intercepteur de jeton), cinq services HTTP, graphiques Chart.js. `stats`/`alerts` sur fixtures, `predictions` branché sur l'API réelle |
 | Base | PostgreSQL 17 + TimescaleDB | `db` | `Fait` | Bootstrap de l'extension, base de test, chaîne Alembic. Schéma applicatif créé (`site`, `dataset`, `reading` en hypertable, `prediction`, `alert`, `recommendation`) |
 | ML | LightGBM, MLflow | `ml` | `En cours` | Pipeline d'entraînement et de scoring (`enervision_ml.train`/`.score`, features par lags/moyennes glissantes partagées entre les deux, baseline de persistance saisonnière, suivi MLflow local), exposé en lecture via `GET /predictions`, orchestré par Airflow (`ml_train`/`ml_score`). Voir [ADR 0005](../adr/0005-modele-prediction-lightgbm.md) et [ML-START.md](../ML-START.md). Surveillance de dérive (EC06, #44/#45) pas encore construite |
-| Infra | Docker Compose, Nginx, Terraform, k3s single-node | `infra`, `docker-compose.prod.yml` | `En cours` | Reverse proxy et overlay de déploiement écrits et validés, jamais lancés sur le serveur ([ADR 0007](../adr/0007-terminaison-tls-et-reverse-proxy-nginx.md)). Module d'installation k3s jamais appliqué, aucune ressource Kubernetes déclarée |
+| Infra | Docker Compose, Nginx, Terraform, k3s single-node | `infra`, `docker-compose.prod.yml` | `En cours` | Reverse proxy et overlay de déploiement écrits et validés, jamais lancés sur le serveur ([ADR 0007](../adr/0007-terminaison-tls-et-reverse-proxy-nginx.md)). Provisionnement de la VM par Terraform, qui installe Docker, prépare les deux environnements et enregistre le runner, jamais appliqué ([ADR 0010](../adr/0010-terraform-provisionne-github-actions-deploie.md)). Module d'installation k3s jamais appliqué, aucune ressource Kubernetes déclarée |
 | Monitoring | Prometheus, Grafana, Alertmanager | `monitoring` | `Cible` | Rien, hors le `/metrics` exposé par l'API |
 | ETL | Apache Airflow | `etl/airflow` | `En cours` | Webserver + scheduler (LocalExecutor) tournent via docker-compose, base de métadonnées Postgres dédiée. Quatre DAGs en sous-processus `uv run` : `ml_train`, `ml_score`, `alertes` et `historical_import`. Le DAG historique orchestre `app.etl.historical_import` et charge `dataset`, `site` et `reading`. L'orchestration API Mock reste à compléter dans #15 |
-| CI/CD | GitHub Actions | `.github/workflows` | `En cours` | 6 workflows, 18 jobs : lint, typage, tests avec seuil de couverture bloquant, tests d'intégration sur TimescaleDB réel, audit de dépendances, SAST Bandit, quality gate SonarCloud, intégrité des DAGs Airflow. Déploiement continu vers la VM ENI écrit par `deploy.yml`, `dev` en recette et `main` en production après approbation ([ADR 0009](../adr/0009-deux-environnements-compose-sur-la-vm-eni.md)), mais jamais exécuté : la machine n'est pas provisionnée et le runner n'y est pas enregistré. Détail dans [50-cicd.md](50-cicd.md) |
+| CI/CD | GitHub Actions | `.github/workflows` | `En cours` | 7 workflows, 19 jobs : lint, typage, tests avec seuil de couverture bloquant, tests d'intégration sur TimescaleDB réel, audit de dépendances, SAST Bandit, quality gate SonarCloud, intégrité des DAGs Airflow, formatage et validation du Terraform. Déploiement continu vers la VM ENI écrit par `deploy.yml`, `dev` en recette et `main` en production après approbation ([ADR 0009](../adr/0009-deux-environnements-compose-sur-la-vm-eni.md)), mais jamais exécuté : la machine n'est pas provisionnée et le runner n'y est pas enregistré. Détail dans [50-cicd.md](50-cicd.md) |
 
 ## Flux bout en bout
 
@@ -189,3 +189,4 @@ Elles vivent dans `../adr/`, pas ici.
 | [0007](../adr/0007-terminaison-tls-et-reverse-proxy-nginx.md) | Terminaison TLS par un reverse proxy Nginx, en Docker Compose |
 | [0008](../adr/0008-airflow-execute-le-code-du-backend.md) | Airflow exécute le code du backend en sous-processus, dans son propre environnement |
 | [0009](../adr/0009-deux-environnements-compose-sur-la-vm-eni.md) | Deux environnements sur la VM ENI, un projet Compose chacun, déployés par un runner auto-hébergé |
+| [0010](../adr/0010-terraform-provisionne-github-actions-deploie.md) | Terraform provisionne la machine, GitHub Actions déploie l'application |

docs/architecture/10-infra.md

@@ -1,13 +1,14 @@
 # Infrastructure
 
-Trois topologies coexistent et ne servent pas la même chose. Ce document dit laquelle vaut dans
-quel contexte, quelles décisions sont arrêtées, et ce qui manque encore entre elles.
+Plusieurs topologies coexistent et ne servent pas la même chose. Ce document dit laquelle vaut
+dans quel contexte, quelles décisions sont arrêtées, et ce qui manque encore entre elles.
 
 | Topologie | Sert à | Statut |
 |---|---|---|
 | Docker Compose | Développer et recetter sur le poste | `Fait` |
 | Docker Compose plus reverse proxy | Déployer sur la machine on-premise | `Fait` |
 | Deux projets Compose sur la VM ENI, recette et production | Déploiement continu depuis GitHub | `En cours` |
+| Provisionnement Terraform de la VM | Préparer la machine et enregistrer le runner | `En cours` |
 | k3s single-node | Cible à terme | `En cours` |
 
 ## Poste de développement
@@ -209,10 +210,38 @@ Nginx renvoie vers `https://$host` sans port, c'est-à-dire vers la production.
 Le déploiement est décrit dans [50-cicd.md](50-cicd.md) : un runner GitHub Actions installé sur
 la VM aligne le dossier sur la branche poussée et lance `make stack-up`.
 
+### Provisionnement de la machine
+
+Statut : `En cours`. Décision et frontière dans
+l'[ADR 0010](../adr/0010-terraform-provisionne-github-actions-deploie.md) : **Terraform
+provisionne la machine, GitHub Actions déploie l'application**. La racine
+`infra/terraform/environments/vm-eni/` fait trois choses, et rien d'autre.
+
+```mermaid
+sequenceDiagram
+  participant TF as terraform apply
+  participant VM as VM eadl-2025-nantes-g3
+  participant GH as GitHub
+
+  TF->>VM: SSH, get.docker.com puis docker compose version
+  TF->>VM: copie et exécute scripts/provision-host.sh
+  VM->>VM: deux clones, deux .env, deux certificats
+  TF->>VM: installe actions-runner, config.sh, svc.sh
+  VM->>GH: le runner s'enregistre avec le label eni-g3
+```
+
+Aucune image n'y est construite, aucun conteneur lancé : un `apply` n'interrompt pas la stack qui
+tourne. Le premier démarrage reste manuel, `make stack-up` dans chaque dossier ; les suivants
+sont joués par le runner à chaque push. Terraform ne sait rien de l'état de la stack, c'est la
+sonde de `deploy.yml` qui le dit.
+
+Le jeton d'enregistrement du runner est valable une heure et ne vaut que pour une inscription :
+l'`apply` n'est pas rejouable sans qu'un administrateur du dépôt en crée un nouveau.
+
 ## Cible à terme, k3s
 
-Statut : `En cours`. Le module `infra/terraform/modules/k3s/` installe le cluster. Il n'a jamais
-été appliqué.
+Statut : `En cours`. Le module `infra/terraform/modules/k3s/` installe le cluster, depuis la
+racine `infra/terraform/environments/k3s-cible/`. Il n'a jamais été appliqué.
 
 ```mermaid
 flowchart LR
@@ -260,11 +289,13 @@ Ces arbitrages sont pris. Ils ne vivaient jusqu'ici que dans des commentaires de
 | `k3s_version` obligatoire, valeur vide refusée | Sans épinglage, `get.k3s.io` installe la dernière version à chaque exécution : le déploiement cesse d'être reproductible | `validation` dans `modules/k3s/variables.tf` |
 | Traefik désactivé | Le choix d'ingress reste ouvert, on ne veut pas en subir un par défaut | `k3s_disable_components`, défaut `["traefik"]` |
 | Kubeconfig laissé en `600/root`, lu par `sudo` | `--write-kubeconfig-mode 644` exposerait `cluster-admin` à tout utilisateur local de la machine | Commentaire et `fetch_kubeconfig` dans `modules/k3s/main.tf` |
-| State Terraform en backend `local` | Un seul opérateur, pas d'exécution concurrente, pas de dépendance à un stockage distant | `environments/dev/versions.tf` |
+| State Terraform en backend `local` | Un seul opérateur, pas d'exécution concurrente, pas de dépendance à un stockage distant | `versions.tf` de chaque racine |
 | `.terraform.lock.hcl` versionné | Fige les versions de provider entre contributeurs et future CI | Commentaire dans `.gitignore` |
 | `*.tfvars` ignoré, `*.tfvars.example` versionné | Les tfvars portent l'adresse du serveur et le chemin de la clé | `.gitignore` |
 | Désinstallation gérée au `destroy` | `k3s-uninstall.sh` en `on_failure = continue` : un serveur injoignable ne bloque pas le `destroy` | `modules/k3s/main.tf` |
-| Deux racines, `dev` et `prod` | Séparation des états et des variables par environnement | `environments/` |
+| Une racine Terraform par machine provisionnée, nommée d'après elle | `environments/dev` laissait croire à un environnement applicatif, alors que `rec` et `prod` vivent sur la même machine et ne sont pas provisionnés par Terraform | `environments/vm-eni`, `environments/k3s-cible` |
+| Terraform provisionne, GitHub Actions déploie | Deux chemins pour le même acte de livraison, c'est ce que la revue de #141 relève sur la VM | [ADR 0010](../adr/0010-terraform-provisionne-github-actions-deploie.md) |
+| Connexion SSH par clé, jamais par mot de passe | Une variable de mot de passe finit en clair dans le state, ou dans les `triggers` qui y sont persistés | `environments/vm-eni/variables.tf`, `modules/k3s/main.tf` |
 | Terminaison TLS par un reverse proxy Nginx en Compose | L'ingress k3s supposait un registre et des manifestes qui n'existent pas, à quatre jours du rendu | `docker-compose.prod.yml`, [ADR 0007](../adr/0007-terminaison-tls-et-reverse-proxy-nginx.md) |
 | Certificat auto-signé par défaut, chemin ACME câblé | Aucun domaine public ne résout vers la machine : le défi HTTP-01 ne peut pas aboutir | `scripts/tls-selfsigned.sh`, `infra/proxy/acme-deploy-hook.sh` |
 | Un projet Compose par environnement, sur la même machine | Une seule VM, et l'isolation par nom de projet ne demande ni cluster ni registre | `.env` de chaque dossier, [ADR 0009](../adr/0009-deux-environnements-compose-sur-la-vm-eni.md) |
@@ -304,4 +335,3 @@ question à trancher, avant toute ressource Kubernetes.
 - **Quel stockage persistant** côté Kubernetes pour PostgreSQL, et si la base tourne dans le
   cluster ou à côté.
 - **Quelle stratégie de sauvegarde et de restauration** des données de mesure.
-- **Que devient `environments/prod/`**, aujourd'hui réduit à un `.gitkeep`.

docs/architecture/50-cicd.md

@@ -16,6 +16,12 @@ basculer sur `Fait` au premier déploiement vert. Sa limite, nommée ici plutôt
 soutenance : les images sont construites sur la machine à chaque déploiement, aucun artefact
 n'est publié puis promu d'un environnement à l'autre.
 
+Ce que ce workflow ne fait pas, et ne fera pas : préparer la machine. Installation de Docker,
+clones, `.env`, certificats et enregistrement du runner sont provisionnés par
+`infra/terraform/environments/vm-eni`
+([ADR 0010](../adr/0010-terraform-provisionne-github-actions-deploie.md)). Terraform provisionne,
+GitHub Actions déploie ; aucun des deux ne fait le travail de l'autre.
+
 ## Vue d'ensemble
 
 ```mermaid
@@ -45,6 +51,10 @@ flowchart TB
     ab["image<br/>construction de l'image"]
   end
 
+  subgraph infw["Infra · infra.yml"]
+    it["terraform<br/>fmt -check, init et validate par racine"]
+  end
+
   subgraph sq["SonarQube · sonarqube.yml"]
     sb1["build-front / test-front"]
     sb2["build-back / test-back"]
@@ -57,6 +67,7 @@ flowchart TB
   push --> fd
   push --> mv & ms
   push --> av & ab
+  push --> it
   push --> sb1 & sb2 --> sscan
 
   subgraph cd["Déploiement · deploy.yml"]
@@ -68,11 +79,11 @@ flowchart TB
 
 ## Déclenchement
 
-Les cinq workflows se déclenchent sur `push` **et** sur `pull_request`, filtrés par **chemin** :
-`backend.yml` sur `apps/backend/**`, `frontend.yml` sur `apps/frontend/**`, `ml.yml` sur `ml/**`,
-`airflow.yml` sur `etl/airflow/**` **plus des chemins de `ml/` et de `apps/backend/`**, chacun
-incluant son propre fichier de workflow dans le filtre pour qu'une modification du pipeline
-déclenche le pipeline.
+Les six workflows hébergés par GitHub se déclenchent sur `push` **et** sur `pull_request`,
+filtrés par **chemin** : `backend.yml` sur `apps/backend/**`, `frontend.yml` sur
+`apps/frontend/**`, `ml.yml` sur `ml/**`, `infra.yml` sur `infra/terraform/**`, `airflow.yml` sur
+`etl/airflow/**` **plus des chemins de `ml/` et de `apps/backend/`**, chacun incluant son propre
+fichier de workflow dans le filtre pour qu'une modification du pipeline déclenche le pipeline.
 
 Le filtre d'`airflow.yml` mérite un mot : il inclut `ml/pyproject.toml`, `ml/uv.lock`,
 `ml/enervision_ml/**`, `apps/backend/pyproject.toml`, `apps/backend/uv.lock` et
@@ -97,7 +108,7 @@ environnement.
 
 ## Déploiement
 
-`deploy.yml` est le sixième workflow, et le seul qui ne tourne pas chez GitHub : il s'exécute sur
+`deploy.yml` est le septième workflow, et le seul qui ne tourne pas chez GitHub : il s'exécute sur
 un runner auto-hébergé installé sur la VM ENI, label `eni-g3`, parce que les runners hébergés ne
 joignent pas une adresse privée d'école. Le runner se connecte en sortie vers GitHub, aucun port
 entrant n'est ouvert.
@@ -151,6 +162,7 @@ dans [10-infra.md](10-infra.md).
 | Build `npm run build` | frontend | compilation | Bloque |
 | Intégrité des DAGs | airflow | chargement des DAGs sans erreur d'import | Bloque |
 | Construction de l'image Airflow | airflow | `docker build` de `etl/airflow/Dockerfile` | Bloque |
+| Formatage et validité Terraform | infra | `fmt -check -recursive`, puis `init` et `validate` par racine | Bloque |
 
 Deux seuils portent une décision qu'il faut savoir défendre :