fix(ci): applique aussi le chmod du fichier d'authentification DAST via sudo

fix(ci): corrige les permissions du fichier d'authentification qui bloquait le scan DAST 10 minutes
Merge remote-tracking branch 'origin/dev' into feat/scan-dast-owasp-zap
2026-09-22 14:57:29 +02:00 · 2026-09-22 14:31:29 +02:00 · 2026-09-22 14:11:31 +02:00 · 2026-09-22 14:08:51 +02:00 · 2026-09-22 12:39:12 +02:00 · 2026-09-22 12:36:38 +02:00
46 changed files with 1150 additions and 241 deletions
@@ -70,7 +70,7 @@ PUBLIC_ORIGIN=
 PROXY_HTTP_PORT=
 PROXY_HTTPS_PORT=
 # Réglages mémoire de la stack déployée. Sans eux, timescaledb-tune réserve 25 % de la RAM de la
-# machine à chaque base au premier démarrage, et le webserver Airflow lance 4 workers gunicorn.
+# machine à chaque base au premier démarrage. L'api-server Airflow 3 n'a rien à régler ici : son
+# nombre de workers vaut 1 par défaut, contre 4 pour le webserver d'Airflow 2.
 TS_TUNE_MEMORY=2GB
 TS_TUNE_NUM_CPUS=2
-AIRFLOW_WEBSERVER_WORKERS=2
@@ -0,0 +1,325 @@
+name: DAST
+
+# Scan dynamique OWASP ZAP de l'API (issue #41). Il attaque une API qui tourne : le job démarre
+# la base et le backend sur le runner, sème un site et quelques relevés (sans ça le scan ne
+# frappe que des gestionnaires d'erreur), crée un compte `lecteur` jetable
+# (scripts/dast-token.sh), puis lance ZAP sur le contrat OpenAPI avec le jeton de ce compte.
+#
+# Non bloquant pour l'instant sur les alertes (`continue-on-error` sur la seule étape du scan) :
+# le volume d'un premier passage trié est inconnu. Deux étapes suivantes, elles, bloquent si le
+# scan n'a rien testé (import du contrat, absence de toute réponse de succès) : un job vert doit
+# vouloir dire qu'un scan a eu lieu.
+#
+# Piège : ce scan tape la configuration par défaut du backend (`APP_ENV=local`, pas de TLS, pas
+# de reverse proxy). Il ne dit rien des en-têtes ni du TLS posés par le proxy en production, et
+# remontera des alertes (HSTS absent...) qui n'existent pas derrière lui.
+
+on:
+  workflow_dispatch:
+  schedule:
+    # Un scan actif est long : hebdomadaire plutôt qu'à chaque PR.
+    - cron: "0 3 * * 1"
+  pull_request:
+    # Ne se lance sur une PR que si le scan lui-même change.
+    paths:
+      - ".github/workflows/dast.yml"
+      - "scripts/dast-token.sh"
+
+permissions:
+  contents: read
+
+concurrency:
+  group: dast-${{ github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  zap:
+    name: Scan OWASP ZAP de l'API
+    runs-on: ubuntu-latest
+    # Généreux face aux ~2 minutes observées de bout en bout : le vrai plafond est
+    # `scanner.maxScanDurationInMins` (étape Scan ZAP), sous le TTL du jeton. Une annulation par
+    # ce timeout-ci n'exécute pas les étapes `always()` : mieux vaut ne jamais l'atteindre.
+    timeout-minutes: 30
+
+    # Même image que docker-compose.yml : la première migration refuse de s'appliquer sans
+    # l'extension TimescaleDB (cf. backend.yml).
+    services:
+      db:
+        image: timescale/timescaledb-ha:pg17
+        env:
+          POSTGRES_USER: enervision
+          POSTGRES_PASSWORD: change_me
+          POSTGRES_DB: enervision_dast
+        ports:
+          - "5433:5432"
+        options: >-
+          --health-cmd "pg_isready -U enervision -d enervision_dast"
+          --health-interval 10s
+          --health-timeout 5s
+          --health-retries 12
+          --health-start-period 40s
+
+    env:
+      # Base jetable : ZAP y écrira et le script y crée deux comptes.
+      DATABASE_URL: postgresql+asyncpg://enervision:change_me@localhost:5433/enervision_dast
+      APP_SECRET_KEY: secret-de-scan-assez-long-pour-le-validateur
+      APP_ENV: local
+      # Le jeton du lecteur doit survivre à toute la durée du scan (15 minutes par défaut).
+      # 3600 est le plafond accepté par la configuration ; `scanner.maxScanDurationInMins`
+      # (étape Scan ZAP) reste très en dessous, marge comprise pour les étapes qui l'entourent.
+      APP_ACCESS_TOKEN_TTL_SECONDS: "3600"
+      PGPASSWORD: change_me
+
+    steps:
+      - name: Récupère le dépôt
+        uses: actions/checkout@v7
+
+      - name: Installe uv
+        # Épinglé sur le commit du tag v7 (règle Sonar githubactions:S7637 : dépendance tierce,
+        # contrairement à actions/checkout ou actions/upload-artifact, premières parties).
+        uses: astral-sh/setup-uv@37802adc94f370d6bfd71619e3f0bf239e1f3b78 # v7
+        with:
+          enable-cache: true
+          cache-dependency-glob: apps/backend/uv.lock
+          # `prune-cache` vaut `true` par défaut (encore sur ce commit) : l'étape de post-job
+          # « Pruning cache » est restée bloquée 5 minutes avant d'échouer (exit code 2) sur un
+          # run où les 16 étapes précédentes passaient, sans lien avec le scan. Le prune n'est
+          # qu'une optimisation de taille de cache entre deux runs, pas une garantie : le
+          # désactiver retire le blocage sans rien changer au comportement du job.
+          prune-cache: false
+
+      - name: Installe l'interpréteur déclaré par .python-version
+        run: uv python install
+        working-directory: apps/backend
+
+      # `--no-build` : aucune dépendance n'est construite depuis ses sources, donc aucun script de
+      # build exécuté (règle Sonar S8541). Le projet lui-même n'est pas installé : il tourne depuis
+      # `apps/backend`, comme dans son Dockerfile. Les `uv run` suivants portent `--frozen
+      # --no-sync` pour ne rien résoudre ni reconstruire (règle S8544).
+      - name: Synchronise les dépendances sans dévier du verrou
+        run: uv sync --frozen --no-dev --no-install-project --no-build
+        working-directory: apps/backend
+
+      - name: Active TimescaleDB sur la base du scan
+        run: psql -h localhost -p 5433 -U enervision -d enervision_dast -c "CREATE EXTENSION IF NOT EXISTS timescaledb"
+
+      - name: Applique les migrations
+        run: uv run --frozen --no-sync --no-build alembic upgrade head
+        working-directory: apps/backend
+
+      # Sans données, `GET /sites` rend `[]`, chaque `/{site_id}` rend 404 et le scan actif ne
+      # frappe que des gestionnaires d'erreur plutôt que la logique métier. `db/seeds/` est vide
+      # (pas encore d'outillage de jeu de données pour la CI) : un site et deux relevés à la main,
+      # juste assez pour que les routes de lecture aient quelque chose à rendre.
+      - name: Insère un site et des relevés minimaux pour le scan
+        run: |
+          psql -h localhost -p 5433 -U enervision -d enervision_dast <<'SQL'
+          INSERT INTO site (site_id, site_name, site_type, location, capacity_kw, status)
+          VALUES ('dast-site', 'Site du scan DAST', 'bureau', 'CI', 50, 'actif')
+          ON CONFLICT (site_id) DO NOTHING;
+
+          INSERT INTO reading (site_id, timestamp, source, consumption_kw, consumption_kwh, is_working_hours, data_quality, raw_data)
+          VALUES
+            ('dast-site', now() - interval '2 hours', 'api_current', 12.5, 12.5, true, 'good', '{}'),
+            ('dast-site', now() - interval '1 hour',  'api_current', 13.0, 13.0, true, 'good', '{}')
+          ON CONFLICT DO NOTHING;
+          SQL
+
+      - name: Démarre l'API
+        run: |
+          nohup uv run --frozen --no-sync --no-build uvicorn app.main:create_app --factory \
+            --host 0.0.0.0 --port 8000 > "$RUNNER_TEMP/api.log" 2>&1 &
+          for _ in $(seq 1 30); do
+            curl -fsS http://localhost:8000/api/v1/health/ready >/dev/null 2>&1 && exit 0
+            sleep 2
+          done
+          echo "L'API ne répond pas sur /health/ready" >&2
+          cat "$RUNNER_TEMP/api.log" >&2
+          exit 1
+        working-directory: apps/backend
+
+      - name: Crée le compte lecteur du scan
+        id: jeton
+        run: |
+          jeton="$(../../scripts/dast-token.sh)"
+          echo "::add-mask::$jeton"
+          echo "jeton=$jeton" >> "$GITHUB_OUTPUT"
+        working-directory: apps/backend
+
+      # Étape distincte du scan lui-même, et sans `continue-on-error` : un `curl` qui échoue ici
+      # (API tombée juste après la sonde de readiness, par exemple) doit rester un échec visible,
+      # pas se travestir en « ZAP n'a importé aucune URL » à l'étape de garde suivante.
+      - name: Prépare le contrat pour ZAP
+        run: |
+          mkdir -p zap-out zap-logs
+          curl -fsS http://localhost:8000/openapi.json -o zap-out/openapi.json
+          # Le dossier passe à l'uid 1000 (utilisateur du conteneur ZAP) : le runner n'y écrit
+          # plus après ce chown, d'où `zap-logs/` (uid du runner) pour les journaux ci-dessous.
+          # Pas de `chmod 777` (règle Sonar S2612).
+          sudo chown -R 1000:1000 zap-out
+
+      # `--network host` : ZAP atteint l'API sur le localhost du runner.
+      #
+      # Piège vécu : la clé du nom d'en-tête est `matchstr`, pas `matchstring`. ZAP accepte
+      # n'importe quelle clé `-config` sans erreur ; avec la mauvaise, il ajoutait à TOUTES les
+      # requêtes un en-tête au nom vide (`: Bearer <jeton>`), qu'uvicorn refuse par un 400
+      # (« Invalid HTTP request received »), y compris sur les routes publiques.
+      #
+      # Le jeton ne passe ni par `${{ }}` dans ce script (il finirait en clair dans le fichier de
+      # commande que GitHub écrit sur le disque du runner pour toute la durée de l'étape), ni par
+      # l'argv de `docker run` (visible par `ps aux` et par `docker inspect zap` tant que le
+      # conteneur existe) : il est écrit dans un fichier de configuration ZAP séparé, monté en
+      # lecture seule hors de `/zap/wrk` pour ne jamais atterrir dans l'artefact publié.
+      #
+      # Les routes d'authentification qui changent l'état du compte du scan sont exclues : un
+      # scan actif y déclencherait la limitation de débit du login, la réinitialisation de mots de
+      # passe et la fermeture des sessions, sans rien apprendre de plus.
+      #
+      # `scanner.maxScanDurationInMins`/`maxRuleDurationInMins` bornent le scan actif, que `-T` ne
+      # couvre pas (il ne borne que le démarrage et le scan passif) : sans ça, une règle qui
+      # traîne peut dépasser le TTL du jeton (401 muets en fin de scan) ou le timeout du job (qui
+      # annule sans exécuter les étapes `always()`, rapport et journaux perdus).
+      - name: Scan ZAP
+        id: zap
+        continue-on-error: true
+        env:
+          JETON: ${{ steps.jeton.outputs.jeton }}
+        run: |
+          set -o pipefail
+          printf 'replacer.full_list(0).description=auth\nreplacer.full_list(0).enabled=true\nreplacer.full_list(0).matchtype=REQ_HEADER\nreplacer.full_list(0).matchstr=Authorization\nreplacer.full_list(0).regex=false\nreplacer.full_list(0).replacement=Bearer %s\n' "$JETON" > "$RUNNER_TEMP/zap-auth.conf"
+          # Piège vécu : `chmod 600` seul rend le fichier illisible pour le conteneur, qui lit un
+          # montage bind avec son propre uid (1000), distinct de celui du runner qui l'a écrit.
+          # ZAP échoue alors dès le lancement (« File not readable: /zap/auth.conf »), et
+          # `zap-api-scan.py` attend `-T` minutes complètes avant d'abandonner : dix minutes qui
+          # ressemblent à un scan actif, pour un daemon mort depuis le début.
+          #
+          # Piège vécu (numéro deux) : une fois le fichier passé à l'uid 1000 par `sudo chown`,
+          # l'utilisateur du runner n'en est plus propriétaire et un `chmod` sans `sudo` échoue
+          # (« Operation not permitted »). Avec le `-e` implicite de bash sur les étapes GitHub
+          # Actions, cette erreur arrêtait toute l'étape avant même `docker run` : scan « réussi »
+          # en une fraction de seconde, sans le moindre journal ni rapport produit.
+          sudo chown 1000:1000 "$RUNNER_TEMP/zap-auth.conf"
+          sudo chmod 644 "$RUNNER_TEMP/zap-auth.conf"
+          docker run --name zap --network host \
+            -v "$PWD/zap-out:/zap/wrk:rw" \
+            -v "$RUNNER_TEMP/zap-auth.conf:/zap/auth.conf:ro" \
+            ghcr.io/zaproxy/zaproxy:stable zap-api-scan.py \
+            -t /zap/wrk/openapi.json -f openapi -O http://localhost:8000 \
+            -T 10 \
+            -r zap-report.html -J zap-report.json -w zap-report.md \
+            -z "-configfile /zap/auth.conf \
+                -config globalexcludeurl.url_list.url(0).description=auth-etat \
+                -config globalexcludeurl.url_list.url(0).enabled=true \
+                -config globalexcludeurl.url_list.url(0).regex='.*/api/v1/auth/(login|password|logout-all|forgot-password|reset-password).*' \
+                -config scanner.maxScanDurationInMins=15 \
+                -config scanner.maxRuleDurationInMins=5" \
+            2>&1 | tee "$RUNNER_TEMP/zap-stdout.log"
+
+      - name: Récupère les journaux de ZAP
+        if: always()
+        run: |
+          mkdir -p zap-logs
+          # ZAP journalise la valeur de chaque `-config`/`-configfile` chargé, y compris le jeton,
+          # à un niveau visible sans `-d` : les copies publiées en artefact sont donc caviardées,
+          # même si `::add-mask::` (posé à la création du jeton) protège déjà le journal du job.
+          masque() { sed -E 's/(Bearer )[A-Za-z0-9._-]+/\1[MASQUE]/Ig'; }
+          [ -f "$RUNNER_TEMP/zap-stdout.log" ] && masque < "$RUNNER_TEMP/zap-stdout.log" > zap-logs/zap-stdout.log
+          docker cp zap:/home/zap/.ZAP/zap.log "$RUNNER_TEMP/zap-internal.log" 2>/dev/null || true
+          [ -f "$RUNNER_TEMP/zap-internal.log" ] && masque < "$RUNNER_TEMP/zap-internal.log" > zap-logs/zap.log
+          [ -f "$RUNNER_TEMP/api.log" ] && masque < "$RUNNER_TEMP/api.log" > zap-logs/api.log
+          rm -f "$RUNNER_TEMP/zap-auth.conf"
+          docker rm -f zap >/dev/null 2>&1 || true
+
+      # `continue-on-error` sur le scan ne doit pas faire passer pour vert un scan qui n'a rien
+      # testé. Constaté une première fois : 2 URL importées sur 26 opérations, ZAP n'avait envoyé
+      # que des requêtes vouées au 404. Le seuil est dérivé du contrat plutôt que d'un nombre fixe
+      # : un contrat qui grossit ne doit pas rendre la garde plus permissive qu'elle ne l'était.
+      - name: Vérifie que le contrat a bien été importé
+        run: |
+          attendu="$(python3 -c "
+          import json
+          d = json.load(open('zap-out/openapi.json'))
+          methodes = ('get', 'post', 'put', 'patch', 'delete', 'head', 'options')
+          print(sum(1 for chemin in d['paths'].values() for m in chemin if m in methodes))
+          ")"
+          minimum=$((attendu * 80 / 100))
+          importees="$(sed -n 's/.*Number of Imported URLs: \([0-9]*\).*/\1/p' "$RUNNER_TEMP/zap-stdout.log" | tail -1)"
+          echo "URL importées depuis le contrat OpenAPI : ${importees:-aucune} (contrat : $attendu opérations, minimum accepté : $minimum)"
+          if [ "${importees:-0}" -lt "$minimum" ]; then
+            echo "::error::ZAP n'a importé que ${importees:-0} URL sur $attendu opérations du contrat OpenAPI (minimum attendu : $minimum, soit 80%). Le scan n'a pas testé l'API, voir zap-logs/zap.log dans l'artefact zap-report."
+            exit 1
+          fi
+
+      # Deuxième garde-fou : le contrat peut être importé et ZAP n'obtenir que des erreurs
+      # (constaté : base sans données, toutes les routes de site répondaient 404).
+      #
+      # Piège de conception, trouvé en répétant ce job en local avant de l'écrire ici : borner le
+      # pourcentage de 4xx ne marche pas. Un scan actif fuzze délibérément un grand nombre
+      # d'entrées invalides (identifiants inventés, méthodes non supportées...), donc même un scan
+      # sain, contre l'API seedée juste au-dessus, reste à 98% de 4xx avec seulement 1% de 2xx :
+      # c'est la forme normale d'un scan actif, pas un signe d'échec. Le signal qui distingue
+      # vraiment un scan cassé (0% de 2xx, `insight.code.2xx` absent du rapport dans le premier
+      # incident) d'un scan sain (2xx non nul, aussi faible soit-il) est donc l'absence de succès,
+      # pas la part d'échecs. Dérivé de `zap-report.json` (champ structuré `insights[]`) plutôt
+      # que du texte libre du rapport Markdown, qui aurait le même défaut de conception en plus
+      # d'être fragile au format.
+      - name: Vérifie que le scan a obtenu au moins une réponse de succès
+        run: |
+          python3 - <<'PY'
+          import json
+          import sys
+
+          try:
+              rapport = json.load(open("zap-out/zap-report.json"))
+          except FileNotFoundError:
+              print("::error::Aucun rapport ZAP produit : le scan n'a rien testé.")
+              sys.exit(1)
+
+          pourcentage_2xx = 0.0
+          for insight in rapport.get("insights", []):
+              if insight.get("key") == "insight.code.2xx":
+                  pourcentage_2xx = float(insight.get("statistic", 0))
+                  break
+
+          print(f"Pourcentage de réponses 2xx : {pourcentage_2xx}%")
+          if pourcentage_2xx <= 0:
+              print(
+                  "::error::Aucune réponse 2xx (succès) reçue : le scan n'a atteint aucune route "
+                  "réelle de l'API. Voir zap-logs/api.log et zap-logs/zap.log dans l'artefact "
+                  "zap-report."
+              )
+              sys.exit(1)
+          PY
+
+      # Uniquement la synthèse (jusqu'à « Alert Detail » exclu) : `$GITHUB_STEP_SUMMARY` est
+      # limité à 1 Mio, et cette étape tourne sous `always()` - son échec ferait échouer le job
+      # après le passage des deux garde-fous, pour une simple raison de mise en forme. Le rapport
+      # complet reste dans l'artefact `zap-report`.
+      - name: Publie le résumé
+        if: always()
+        run: |
+          if [ -f zap-out/zap-report.md ]; then
+            awk '/^## Alert Detail/{exit} {print}' zap-out/zap-report.md >> "$GITHUB_STEP_SUMMARY"
+            echo "" >> "$GITHUB_STEP_SUMMARY"
+            echo "Rapport complet (HTML/JSON/Markdown) dans l'artefact \`zap-report\`." >> "$GITHUB_STEP_SUMMARY"
+          else
+            echo "Aucun rapport ZAP produit, voir le journal du job." >> "$GITHUB_STEP_SUMMARY"
+          fi
+
+      - name: Publie les rapports
+        if: always()
+        uses: actions/upload-artifact@v7
+        with:
+          name: zap-report
+          path: |
+            zap-out/
+            zap-logs/
+          if-no-files-found: warn
+
+      # Diagnostic de dernier recours : les journaux de l'API sont déjà dans l'artefact
+      # (zap-logs/api.log) via l'étape « Récupère les journaux de ZAP » (always()), mais les
+      # afficher directement dans le journal du job évite d'avoir à le télécharger pour un échec
+      # évident (l'API n'a jamais démarré, par exemple).
+      - name: Journal de l'API en cas d'échec
+        if: failure() || steps.zap.outcome == 'failure'
+        run: cat "$RUNNER_TEMP/api.log" || true
@@ -52,6 +52,7 @@ jobs:
          done
          echo "L'API ne répond pas après 3 minutes" >&2
          cd "/srv/enervision/${ENVIRONNEMENT}"
-          docker compose ps
-          docker compose logs --tail=50 backend proxy
+          compose="docker compose -f docker-compose.yml -f docker-compose.prod.yml"
+          $compose ps
+          $compose logs --tail=50 backend proxy
          exit 1
@@ -0,0 +1,52 @@
+name: Infra
+
+# Pourquoi : le Terraform du dépôt est resté cassé sans que rien ne le dise, faute de job qui le
+# joue. Ce workflow n'applique rien : il vérifie le formatage et la validité de chaque racine.
+# Piège : la boucle parcourt `environments/*`, pour qu'une racine ajoutée soit couverte sans
+# toucher à ce fichier.
+
+on:
+  push:
+    paths:
+      - "infra/terraform/**"
+      - ".github/workflows/infra.yml"
+  pull_request:
+    paths:
+      - "infra/terraform/**"
+      - ".github/workflows/infra.yml"
+
+permissions:
+  contents: read
+
+concurrency:
+  group: infra-${{ github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  terraform:
+    name: Formatage et validation Terraform
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Récupère le dépôt
+        uses: actions/checkout@v7
+
+      # Action tierce, donc epinglee sur un SHA de commit et pas sur un tag mobile : un tag se
+      # redeplace, et ce workflow tourne avec les droits du depot (regle Sonar githubactions:S7637).
+      - name: Installe Terraform
+        uses: hashicorp/setup-terraform@dfe3c3f87815947d99a8997f908cb6525fc44e9e # v4.0.1
+        with:
+          terraform_version: 1.16.3
+          terraform_wrapper: false
+
+      - name: Vérifie le formatage
+        run: terraform fmt -check -recursive infra/terraform
+
+      - name: Valide chaque racine
+        run: |
+          for racine in infra/terraform/environments/*/; do
+            echo "::group::${racine}"
+            terraform -chdir="${racine}" init -backend=false -input=false
+            terraform -chdir="${racine}" validate
+            echo "::endgroup::"
+          done
@@ -40,7 +40,6 @@ kubeconfig
 # Airflow
 etl/airflow/logs/
 airflow.db
-airflow-webserver.pid
 standalone_admin_password.txt

 # Environnement et secrets
@@ -64,8 +63,7 @@ ml/models/*
 !ml/models/.gitkeep
 ml/mlruns/
 ml/mlartifacts/
-ml/mlflow.db*
-ml/.env
+ml/mlflow.db

 # Airflow : base sqlite locale generee par les tests d'integrite des DAGs (etl/airflow/tests)
 etl/airflow/tests/.airflow_home/
@@ -20,8 +20,6 @@ PG_USER := $(or $(strip $(call env-val,POSTGRES_USER)),enervision)
 PG_PASSWORD := $(or $(strip $(call env-val,POSTGRES_PASSWORD)),change_me)
 PG_DB := $(or $(strip $(call env-val,POSTGRES_DB)),enervision)
 PG_PORT := $(or $(strip $(call env-val,POSTGRES_PORT)),5433)
-ml-env-val = $(shell sed -n 's/^$(1)=//p' ml/.env 2>/dev/null | tail -1)
-ML_ENV_DB_PASSWORD := $(call ml-env-val,MLFLOW_DB_PASSWORD)
 AIRFLOW_PORT := $(or $(strip $(call env-val,AIRFLOW_PORT)),8080)
 MAILPIT_UI_PORT := $(or $(strip $(call env-val,MAILPIT_UI_PORT)),8025)
 ML_DATABASE_URL ?= postgresql+psycopg://$(PG_USER):$(PG_PASSWORD)@localhost:$(PG_PORT)/$(PG_DB)
@@ -37,7 +35,7 @@ DEMO_NOW ?= 2024-12-31T00:00:00Z
        lint format typecheck test test-cov test-integration check \
        openapi docker-build db-up db-down db-reset db-logs db-psql db-wait db-ensure-airflow \
        migrate bootstrap-admin services-up demo-data demo-data-force \
-        ml-lint ml-typecheck ml-test ml-check ml-train ml-score mlflow-up detect-alerts recommendations \
+        ml-lint ml-typecheck ml-test ml-check ml-train ml-score detect-alerts recommendations \
        airflow-lint airflow-test airflow-check airflow-up airflow-down airflow-logs \
        tls-selfsigned tls-acme tls-renew stack-up stack-down stack-logs

@@ -69,7 +67,7 @@ services-up: ## Démarre les services conteneurisés dont `make dev` dépend (ba
 	docker compose up -d db mailpit
 	@$(MAKE) --no-print-directory db-wait
 	@$(MAKE) --no-print-directory db-ensure-airflow
-	docker compose up -d airflow-init airflow-webserver airflow-scheduler
+	docker compose up -d airflow-init airflow-apiserver airflow-scheduler airflow-dag-processor

 dev-backend: ## Lance l'API seule en rechargement à chaud
 	@echo "backend  -> http://localhost:8000 (docs sur /docs)"
@@ -120,14 +118,6 @@ ml-train: ## Entraine le modele LightGBM. CSV=chemin optionnel, sinon lit ML_DAT
 ml-score: ## Score le prochain pas horaire et l'ecrit dans `prediction`. CSV= et NOW= optionnels
 	cd $(ML) && uv run python -m enervision_ml.score $(if $(CSV),--csv $(CSV),) $(if $(NOW),--now $(NOW),)

-mlflow-up: ## Démarre le serveur MLflow (tracking + registry) en conteneur. ml/.env requis
-	@test -n "$(strip $(ML_ENV_DB_PASSWORD))" \
-		|| { echo "MLFLOW_DB_PASSWORD absente de ml/.env (copier ml/.env.example)"; exit 1; }
-	@echo "$(ML_ENV_DB_PASSWORD)" | grep -qE '^[A-Za-z0-9]+$$' \
-		|| { echo "MLFLOW_DB_PASSWORD doit contenir uniquement lettres et chiffres (interpolee dans l'URI postgresql://)"; exit 1; }
-	cd $(ML) && docker compose -f docker-compose.mlflow.yml up -d --build
-	@echo "mlflow   -> http://localhost:5000"
-
 detect-alerts: ## Détecte les alertes internes depuis les lectures en base. SITE= et NOW= optionnels
 	cd $(BACKEND) && uv run python -m app.detection.internal_alerts $(if $(SITE),--site-id $(SITE),) $(if $(NOW),--now $(NOW),)

@@ -94,8 +94,9 @@ et frontend en rechargement a chaud sur le poste.
 | Mailpit | <http://localhost:8025> |

 Le `.env` doit porter les cles Airflow avant le premier `make dev` : `AIRFLOW_FERNET_KEY`,
-`AIRFLOW_WEBSERVER_SECRET_KEY`, `AIRFLOW_APP_SECRET_KEY` et `AIRFLOW_ADMIN_PASSWORD`. Sans elles
-`airflow-init` refuse de demarrer, et `airflow-webserver` comme `airflow-scheduler` avec lui.
+`AIRFLOW_API_SECRET_KEY`, `AIRFLOW_JWT_SECRET`, `AIRFLOW_APP_SECRET_KEY` et
+`AIRFLOW_ADMIN_PASSWORD`. Sans elles `airflow-init` refuse de demarrer, et `airflow-apiserver`,
+`airflow-scheduler` et `airflow-dag-processor` avec lui.

 Les cibles d'origine restent disponibles pour ne demarrer qu'une partie : `make db-up`,
 `make airflow-up`, `make dev-backend`, `make dev-frontend`.
@@ -48,7 +48,9 @@ SettingsDep = Annotated[Settings, Depends(get_settings)]

 CODE_CHANGEMENT_REQUIS = "password_change_required"

-_porteur = HTTPBearer(auto_error=False, scheme_name="Jeton d'accès")
+# Nom ASCII : un outillage tiers (ZAP, cf. .github/workflows/dast.yml) peut mal analyser un nom
+# de schéma accentué dans le contrat OpenAPI. Piège vécu, pas anticipé.
+_porteur = HTTPBearer(auto_error=False, scheme_name="JetonAcces")
 CredentialsDep = Annotated[HTTPAuthorizationCredentials | None, Depends(_porteur)]


@@ -94,7 +94,9 @@ TAGS: Final[list[dict[str, Any]]] = [

 cookie_de_rafraichissement = APIKeyCookie(
    name=REFRESH_COOKIE_DEFAUT,
-    scheme_name="Cookie de rafraîchissement",
+    # Nom ASCII : un outillage tiers (ZAP, cf. .github/workflows/dast.yml) peut mal analyser un
+    # nom de schéma accentué dans le contrat OpenAPI. Piège vécu, pas anticipé.
+    scheme_name="CookieRafraichissement",
    description=(
        "Cookie `HttpOnly` posé par `/auth/login` et tourné par `/auth/refresh`. Il prend le "
        "préfixe `__Secure-` dès que l'API tourne derrière TLS, et n'est émis que vers "
@@ -213,7 +213,7 @@
        },
        "security": [
          {
-            "Cookie de rafraîchissement": []
+            "CookieRafraichissement": []
          }
        ]
      }
@@ -252,7 +252,7 @@
        },
        "security": [
          {
-            "Cookie de rafraîchissement": []
+            "CookieRafraichissement": []
          }
        ]
      }
@@ -301,7 +301,7 @@
        },
        "security": [
          {
-            "Jeton d'accès": []
+            "JetonAcces": []
          }
        ]
      }
@@ -347,7 +347,7 @@
        },
        "security": [
          {
-            "Jeton d'accès": []
+            "JetonAcces": []
          }
        ]
      }
@@ -423,7 +423,7 @@
        },
        "security": [
          {
-            "Jeton d'accès": []
+            "JetonAcces": []
          }
        ]
      }
@@ -673,7 +673,7 @@
        },
        "security": [
          {
-            "Jeton d'accès": []
+            "JetonAcces": []
          }
        ]
      },
@@ -757,7 +757,7 @@
        },
        "security": [
          {
-            "Jeton d'accès": []
+            "JetonAcces": []
          }
        ]
      }
@@ -771,7 +771,7 @@
        "operationId": "update_user_api_v1_users__user_id__patch",
        "security": [
          {
-            "Jeton d'accès": []
+            "JetonAcces": []
          }
        ],
        "parameters": [
@@ -889,7 +889,7 @@
        "operationId": "reset_password_api_v1_users__user_id__password_reset_post",
        "security": [
          {
-            "Jeton d'accès": []
+            "JetonAcces": []
          }
        ],
        "parameters": [
@@ -1023,7 +1023,7 @@
        },
        "security": [
          {
-            "Jeton d'accès": []
+            "JetonAcces": []
          }
        ]
      }
@@ -1037,7 +1037,7 @@
        "operationId": "get_site_api_v1_sites__site_id__get",
        "security": [
          {
-            "Jeton d'accès": []
+            "JetonAcces": []
          }
        ],
        "parameters": [
@@ -1124,7 +1124,7 @@
        "operationId": "get_current_api_v1_sites__site_id__current_get",
        "security": [
          {
-            "Jeton d'accès": []
+            "JetonAcces": []
          }
        ],
        "parameters": [
@@ -1211,7 +1211,7 @@
        "operationId": "list_alerts_api_v1_alerts_get",
        "security": [
          {
-            "Jeton d'accès": []
+            "JetonAcces": []
          }
        ],
        "parameters": [
@@ -1361,7 +1361,7 @@
        },
        "security": [
          {
-            "Jeton d'accès": []
+            "JetonAcces": []
          }
        ]
      }
@@ -1375,7 +1375,7 @@
        "operationId": "get_recommendation_api_v1_recommendations__recommendation_id__get",
        "security": [
          {
-            "Jeton d'accès": []
+            "JetonAcces": []
          }
        ],
        "parameters": [
@@ -1462,7 +1462,7 @@
        "operationId": "generate_recommendations_api_v1_recommendations_generate_post",
        "security": [
          {
-            "Jeton d'accès": []
+            "JetonAcces": []
          }
        ],
        "parameters": [
@@ -1588,7 +1588,7 @@
        },
        "security": [
          {
-            "Jeton d'accès": []
+            "JetonAcces": []
          }
        ]
      }
@@ -1602,7 +1602,7 @@
        "operationId": "list_readings_api_v1_readings_get",
        "security": [
          {
-            "Jeton d'accès": []
+            "JetonAcces": []
          }
        ],
        "parameters": [
@@ -1799,7 +1799,7 @@
        },
        "security": [
          {
-            "Jeton d'accès": []
+            "JetonAcces": []
          }
        ]
      }
@@ -1855,7 +1855,7 @@
        },
        "security": [
          {
-            "Jeton d'accès": []
+            "JetonAcces": []
          }
        ]
      }
@@ -3225,13 +3225,13 @@
      }
    },
    "securitySchemes": {
-      "Cookie de rafraîchissement": {
+      "CookieRafraichissement": {
        "type": "apiKey",
        "description": "Cookie `HttpOnly` posé par `/auth/login` et tourné par `/auth/refresh`. Il prend le préfixe `__Secure-` dès que l'API tourne derrière TLS, et n'est émis que vers `/api/v1/auth`.",
        "in": "cookie",
        "name": "ev_refresh"
      },
-      "Jeton d'accès": {
+      "JetonAcces": {
        "type": "http",
        "scheme": "bearer"
      }
@@ -104,8 +104,8 @@ def test_the_rate_limit_documents_the_delay_header(schema: dict[str, Any]) -> No
 def test_the_refresh_cookie_appears_in_the_security_schemes(schema: dict[str, Any]) -> None:
    schemes = schema["components"]["securitySchemes"]

-    assert schemes["Cookie de rafraîchissement"]["in"] == "cookie"
-    assert schemes["Cookie de rafraîchissement"]["name"] == "ev_refresh"
+    assert schemes["CookieRafraichissement"]["in"] == "cookie"
+    assert schemes["CookieRafraichissement"]["name"] == "ev_refresh"


 def test_each_tag_used_by_a_route_is_described(schema: dict[str, Any]) -> None:
@@ -25,8 +25,6 @@ services:
  airflow-apiserver:
    ports: !override
      - "127.0.0.1:${AIRFLOW_PORT:-8080}:8080"
-    environment:
-      AIRFLOW__WEBSERVER__WORKERS: ${AIRFLOW_WEBSERVER_WORKERS:-2}

  backend:
    ports: !reset null
@@ -16,3 +16,4 @@
 | [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 |
@@ -63,8 +63,9 @@ secret.

 - Deux TimescaleDB sur une machine de 8 Go : sans réglage, chacune se réserverait 25 % de la
  RAM au premier démarrage. L'overlay fixe `TS_TUNE_MEMORY` à 2 Go et `TS_TUNE_NUM_CPUS` à 2 par
-  base, et 2 workers gunicorn par webserver Airflow. La montée à 32 Go prévue par les
-  consignes est à demander.
+  base. Airflow 3 n'a rien à régler de ce côté : son api-server lance un seul worker par défaut,
+  là où le webserver d'Airflow 2 en lançait quatre. La montée à 32 Go prévue par les consignes
+  est à demander.
 - Un runner auto-hébergé sur un dépôt public exécute le code qu'on lui envoie. `deploy.yml` ne
  se déclenche jamais sur `pull_request`, le runner tourne sous un utilisateur dédié, et le
  dépôt doit exiger une approbation pour les workflows des PR externes.
@@ -75,6 +76,7 @@ secret.
  à chaque push : plusieurs minutes par déploiement, acceptable pour la cadence du projet.
 - `environments/prod` de Terraform reste vide. Le provisionnement de la machine est porté par
  `scripts/provision-host.sh`, que Terraform pourra appeler par `remote-exec` le jour où une
-  racine visant la VM existera.
+  racine visant la VM existera. Cette racine existe depuis l'[ADR 0010](0010-terraform-provisionne-github-actions-deploie.md),
+  sous le nom `environments/vm-eni`, et `environments/prod` a disparu avec elle.
 - L'image frontend quitte `dhi.io/nginx`, registre authentifié dont personne n'a l'accès, pour
  `nginx:1.28-alpine`, la même image que le proxy. Elle n'avait jamais été construite.
@@ -0,0 +1,77 @@
+# 0010 - Terraform provisionne la machine, GitHub Actions déploie l'application
+
+- Statut : accepté
+- Date : 2026-09-22
+
+## Contexte
+
+L'[ADR 0009](0009-deux-environnements-compose-sur-la-vm-eni.md) a posé la livraison : deux
+projets Compose sur la VM ENI, alignés sur `dev` et sur `main` par un runner auto-hébergé. Elle
+ne dit pas qui prépare la machine. C'est `scripts/provision-host.sh`, lancé à la main en SSH.
+
+La grille d'évaluation attend en C22 que l'infrastructure soit « provisionnée via du code
+(Terraform, Ansible…) ». Le seul Terraform du dépôt installe un cluster k3s que rien ne
+consomme, qui n'a jamais été appliqué, et dont la racine ne passait même pas `terraform init`
+depuis que Terraform refuse les provisioners `destroy` dont la connexion lit autre chose que
+`self`. Sa racine s'appelait `environments/dev`, nom qui laissait croire à un environnement
+applicatif alors que les deux environnements réels sont `rec` et `prod`, sur la même machine.
+
+La branche `feat/deploy` (PR #141) proposait la réponse inverse : Terraform construit les
+images, lance les conteneurs et copie les sources par SSH. La revue a relevé deux racines sur
+trois qui ne passent pas `terraform validate`, le mot de passe SSH écrit en clair dans le state,
+un backend lancé sans base ni variables d'environnement, et trois architectures différentes pour
+trois environnements.
+
+## Décision
+
+**Terraform provisionne la machine, GitHub Actions déploie l'application.** La frontière est
+nette et vérifiable : `infra/terraform/environments/vm-eni` installe Docker et le plugin
+Compose, exécute `scripts/provision-host.sh`, enregistre le runner. Il ne construit aucune
+image, ne lance aucun conteneur, et un `apply` n'interrompt pas la stack qui tourne.
+
+**Le déploiement continu ne change pas.** `deploy.yml` reste le seul chemin de livraison : push
+sur `dev` ou `main`, alignement du clone, `make stack-up`, sonde `/api/v1/health/ready`.
+
+**Le Bash reste la mécanique, Terraform devient le point d'entrée.** `provision-host.sh` connaît
+les deux environnements, leurs ports décalés, leurs secrets et leurs certificats. Le réécrire en
+HCL créerait une seconde source de vérité qui divergerait au premier changement de port.
+
+**Aucun secret dans le state.** Authentification SSH par clé seulement, pas de variable de mot
+de passe. Le jeton d'enregistrement du runner est une variable `sensitive` fournie à l'`apply`,
+jamais un `trigger` : les `triggers` sont la seule partie d'un `null_resource` que Terraform
+persiste.
+
+**Les racines portent le nom de ce qu'elles provisionnent**, pas d'un environnement applicatif :
+`vm-eni` pour la machine, `k3s-cible` pour le cluster resté en cible. `environments/prod`,
+dossier vide, disparaît.
+
+## Alternatives écartées
+
+- **Ansible à la place du Bash** : plus idiomatique pour de la configuration de machine, et le
+  jury le reconnaîtrait immédiatement comme de l'IaC. Mais c'est un outil de plus à installer et
+  à faire tourner, pour réécrire un script qui fonctionne, à trois jours du gel technique.
+- **Provisioners applicatifs de `feat/deploy`** : voir la revue sur #141. Terraform y devenait un
+  orchestrateur concurrent de Compose, sans base de données ni migrations.
+- **Terraform appelle aussi `make stack-up`** : le premier démarrage serait plus court d'une
+  commande, mais Terraform se mettrait à porter la livraison, que le runner rejoue à chaque
+  push. Deux chemins pour le même acte, c'est précisément ce que #141 montre qu'il ne faut pas.
+- **k3s tout de suite** : le cluster serait vide, sans manifeste, sans registre et sans stockage
+  persistant. Le module reste, documenté comme cible.
+- **State Terraform distant** : un seul opérateur, pas d'exécution concurrente. Le backend local
+  suffit, comme pour `k3s-cible`.
+
+## Conséquences
+
+- Le premier `apply` exige un jeton d'enregistrement du runner, valable une heure et pour une
+  seule inscription, que seul un administrateur du dépôt peut créer. L'`apply` n'est donc pas
+  rejouable sans intervention humaine, ce qui est acceptable : il ne se joue qu'à l'installation.
+- L'utilisateur propriétaire de `/srv/enervision` doit exister sur la machine avant l'`apply`.
+  Terraform vérifie et échoue tôt plutôt que de le créer : décider d'un compte système est une
+  décision d'administration, pas un effet de bord de déploiement.
+- Terraform ne sait rien de l'état de la stack. `terraform plan` ne dira jamais que la recette
+  est tombée ; c'est la sonde de `deploy.yml` qui le dit.
+- Pas de provisioner `destroy` sur le runner : il imposerait de mettre le chemin de la clé SSH
+  dans le state, et `svc.sh uninstall` ne désinscrit pas le runner côté GitHub. Le retrait reste
+  manuel, depuis les paramètres du dépôt.
+- C22 cesse de reposer sur `docker-compose.prod.yml` seul. C23 reste porté par les scripts, que
+  Terraform appelle désormais au lieu de les remplacer.
@@ -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 |
@@ -1,15 +1,15 @@
 # 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` |
-| MLflow (`ml/`) | Tracker les expériences et le registre de modèles en local | `Fait`, non relié aux autres topologies |

 ## Poste de développement

@@ -148,34 +148,6 @@ est minimale et n'embarque pas la runtime OpenMP dont LightGBM a besoin, sans qu
 (`OSError: libgomp.so.1`) n'apparaît qu'à la première tâche réellement exécutée, pas à la
 construction de l'image.

-### MLflow (`ml/`)
-
-Statut : `Fait`, en local uniquement. Défini par `ml/docker-compose.mlflow.yml`, indépendant
-du `docker-compose.yml` principal (réseau, volumes et démarrage séparés).
-
-| Service | Image | Points notables |
-|---|---|---|
-| `mlflow-db` | `postgres:17` | Stocke le tracking store MLflow. Mot de passe obligatoire via `MLFLOW_DB_PASSWORD` |
-| `mlflow` | Construite depuis `ml/` | Expose l'UI et l'API MLflow sur `127.0.0.1:5000`. Artefacts sur volume `mlflow-artifacts`, tracking store sur `mlflow-db` |
-
-Portée actuelle : environnement de tracking et de registre de modèles pour le développement
-local uniquement. Ce compose n'est relié ni à `docker-compose.prod.yml`, ni aux deux
-environnements Compose de la VM ENI, ni à la cible k3s. Le magasin utilisé par Airflow pour
-`ml_train`/`ml_score` (SQLite, volume `airflow_ml_state`) en est distinct — les deux MLflow ne
-se voient pas tant que `MLFLOW_TRACKING_URI` n'est pas posé côté Airflow.
-
-Limite connue : le DAG Airflow `ml_train` enregistre lui aussi une version a chaque execution
-via `registered_model_name` (magasin SQLite du volume `airflow_ml_state`, distinct de ce
-serveur). Versions et artefacts s'y accumulent sans politique de nettoyage -- fonctionne en
-l'etat, mais a surveiller si les entrainements deviennent frequents.
-
-Pour relier les runs Airflow (`ml_train`, magasin SQLite local) a ce serveur MLflow, positionner
-`MLFLOW_TRACKING_URI=http://mlflow:5000` dans l'environnement du service `airflow-scheduler` (ou
-`http://host.docker.internal:5000` si le serveur MLflow tourne hors du reseau Compose principal),
-et s'assurer que le conteneur Airflow peut joindre le service `mlflow` -- ce qui suppose de les
-rapprocher sur le meme reseau Docker ou d'exposer MLflow autrement qu'en `127.0.0.1` uniquement
-(cf. point 1 sur l'exposition du port). Non fait a ce jour : aucun besoin de centraliser les runs
-d'entrainement Airflow et locaux n'a encore ete identifie.
 ## Machine cible, exécution Docker

 Statut : `Fait`. Défini par l'overlay `docker-compose.prod.yml`, appliqué par-dessus le
@@ -238,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
@@ -289,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) |
@@ -333,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`.
@@ -331,8 +331,10 @@ pas prise :
 | `license_info` | Aucune licence n'est choisie |
 | `contact` | Aucun canal de support n'existe |

-Deux schémas de sécurité sont déclarés : `Jeton d'accès` pour le porteur JWT, et
-`Cookie de rafraîchissement` pour `/auth/refresh` et `/auth/logout`. **Le second est purement
+Deux schémas de sécurité sont déclarés : `JetonAcces` pour le porteur JWT, et
+`CookieRafraichissement` pour `/auth/refresh` et `/auth/logout`, des noms ASCII délibérés (issue
+#41 : un outillage tiers comme ZAP peut mal analyser un nom de schéma accentué dans le contrat).
+**Le second est purement
 documentaire** : son `auto_error=False` garantit qu'il ne décide d'aucun refus. Le passer à vrai
 ferait répondre 403 avant d'atteindre `lit_le_cookie()`, et `/auth/refresh` cesserait de rendre le
 401 sur lequel le frontend déclenche sa déconnexion.
@@ -287,10 +287,6 @@ Chaque table remplit un rôle précis dans le traitement et l'exploitation des d
 | `alert` | Enregistrer les alertes, leur type, leur gravité et leur message | API Mock `/alerts` et détections EnerVision |
 | `recommendation` | Proposer des actions et expliquer la règle qui les motive | Règles métier d'EnerVision |

-Le scoring (`ml_score`) charge le modèle depuis un fichier local (`models/lightgbm-consumption.txt`)
-et trace son empreinte SHA-256 dans `prediction.model_reference`. Il ne lit aucune version depuis
-le Model Registry MLflow (`ml/`) : ce registre sert aujourd'hui à la traçabilité des
-entraînements, pas au déploiement du modèle de scoring.
 Les anomalies historiques décrites dans les JSON sont conservées dans `dataset.metadata`.

 Elles servent à l'analyse des données et ne sont pas considérées comme des alertes actuelles.
@@ -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,22 +67,36 @@ flowchart TB
  push --> fd
  push --> mv & ms
  push --> av & ab
-  push --> sb1 & sb2 --> sscan
+  push --> it
+  push --> sb1 & sb2 & sb3 --> sscan

  subgraph cd["Déploiement · deploy.yml"]
    dep["deploy<br/>runner eni-g3, environnement rec ou prod"]
  end

  push -->|"push sur dev ou main"| dep
+
+  planifie["chaque lundi 3h UTC,<br/>ou à la main"]
+  subgraph dastw["DAST · dast.yml"]
+    zscan["zap<br/>seed + scan actif OWASP ZAP"]
+  end
+
+  planifie --> zscan
+  push -->|"PR sur dast.yml<br/>ou dast-token.sh"| zscan
 ```

 ## 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 qui vérifient le code 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.
+
+`dast.yml` s'en écarte volontairement (détail dans sa propre section plus bas) : aucun
+déclenchement sur `push`, seulement `workflow_dispatch`, une planification hebdomadaire, et
+`pull_request` restreint à ses deux seuls fichiers. Un scan actif est trop long pour tourner à
+chaque commit.

 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 +121,8 @@ 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 huitième workflow (`backend`, `frontend`, `ml`, `infra`, `airflow`,
+`sonarqube`, `dast`, plus lui-même), 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 +176,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 :

@@ -242,12 +268,112 @@ Ils ne transitent ni par git ni par GitHub, et le runner, qui travaille dans ce
 à recevoir. Le revers : ils ne sont sauvegardés nulle part ailleurs. Un `.env` perdu se
 régénère, ce qui invalide les sessions et les connexions chiffrées par Airflow.

+## Scan DAST (OWASP ZAP)
+
+Statut : `En cours`. Le workflow `dast.yml` attaque l'API **en fonctionnement**, ce que ni Bandit,
+ni `pip-audit`, ni Sonar ne font. Il se lance à la main (`workflow_dispatch`), chaque lundi à 3h
+UTC, et sur une PR qui modifie le scan lui-même. Pas à chaque PR : un scan actif dure plusieurs
+minutes.
+
+Le job démarre sur le runner la base (même image TimescaleDB que `docker-compose.yml`, base
+jetable), applique les migrations, y sème un site et deux relevés (`db/seeds/` est vide, pas
+encore d'outillage de jeu de données pour la CI ; sans données, `GET /sites` rend `[]`, chaque
+`/{site_id}` rend 404, et le scan actif ne frappe que des gestionnaires d'erreur), démarre le
+backend, puis `scripts/dast-token.sh` crée un compte **`lecteur`** et rend son jeton.
+
+ZAP charge le contrat `/openapi.json` depuis un fichier (`zap-api-scan.py -f openapi -t
+/zap/wrk/openapi.json`) et en importe les 26 opérations **quel que soit le jeton** : c'est le
+contrat qui décide de ce qui est exploré, pas l'authentification. Le jeton ne change que les
+réponses obtenues sur les routes gardées : sans lui, elles répondraient toutes `401` plutôt que
+de dérouler leur logique. Huit routes n'exigent aucun jeton porteur (les deux sondes, `login`,
+`refresh`, `logout`, `forgot-password`, `reset-password` et `reset-password/validate`) et
+répondent donc pareil avec ou sans lui.
+
+Décisions à savoir défendre :
+
+- **Le compte du scan est `lecteur`, jamais `admin`.** Un scan actif avec un jeton admin frapperait
+  `POST /users` et la réinitialisation de mots de passe pour de bon. Le script passe par un admin
+  jetable pour créer le lecteur (l'API n'a pas d'inscription publique) puis ne s'en sert plus.
+- **Un compte neuf est en `must_change_password`**, et toute route gardée le refuse tant que le
+  mot de passe n'est pas changé. Le script fait ce changement et vérifie `GET /sites` = 200 avant
+  de rendre le jeton ; sans cela, tout le scan authentifié ne testerait que des `403`.
+  `POST /auth/password` rend déjà un nouveau jeton valide (l'`iat` tronqué documenté dans
+  `app/api/deps.py` ne le rejette pas comme antérieur à la session) : le script s'en sert
+  directement plutôt que de se reconnecter, deux hachages Argon2id (19456 Kio chacun) et deux
+  allers-retours de refresh-token de moins sur le chemin critique de la CI.
+- **`APP_ACCESS_TOKEN_TTL_SECONDS=3600`** (plafond de la configuration) : le jeton par défaut
+  dure 15 minutes. `scanner.maxScanDurationInMins=15` (ci-dessous) borne le scan actif très en
+  dessous, marge comprise pour les étapes qui l'entourent.
+- **Le jeton ne transite ni par `${{ }}` dans le script de l'étape, ni par l'argv de `docker
+  run`.** Le premier finirait en clair dans le fichier de commande que GitHub écrit sur le disque
+  du runner pour toute la durée de l'étape ; le second serait visible par `ps aux` et par
+  `docker inspect zap` tant que le conteneur existe. Il est écrit dans un fichier de
+  configuration ZAP séparé (`-configfile`), monté en lecture seule hors de `/zap/wrk` pour ne
+  jamais atterrir dans l'artefact publié. ZAP journalise malgré tout la valeur de chaque
+  `-config`/`-configfile` chargé à un niveau visible sans `-d` : les copies de `zap.log` et
+  `zap-stdout.log` publiées en artefact sont donc caviardées avant publication.
+
+**Deux pièges d'autorisation** sur ce fichier de configuration (`zap-auth.conf`), tous les deux
+propres au montage bind Docker : le conteneur y lit avec son propre uid (1000), distinct de celui
+du runner qui l'a écrit, sans remappage automatique.
+
+- Un `chmod 600` seul rend le fichier illisible pour le conteneur (« File not readable :
+  /zap/auth.conf »). ZAP échoue dès le lancement, mais `zap-api-scan.py` attend les `-T` minutes
+  complètes avant d'abandonner : dix minutes qui ressemblent à un scan actif, pour un daemon mort
+  depuis le début. Corrigé par `sudo chown 1000:1000` du fichier avant de le passer à `644`.
+- Ce `chown` déplace la propriété du fichier hors de l'utilisateur du runner : un `chmod` qui
+  suit sans `sudo` échoue alors (« Operation not permitted »), et le `-e` implicite des étapes
+  bash de GitHub Actions arrête toute l'étape avant même `docker run` — un scan « réussi » en une
+  fraction de seconde, sans le moindre journal ni rapport produit. Les deux commandes doivent
+  passer par `sudo`.
+
+Les routes d'authentification qui changent l'état du compte (`login`, `password`, `logout-all`,
+`forgot-password`, `reset-password`) sont exclues du scan actif : elles y déclencheraient la
+limitation de débit et fermeraient les sessions sans rien apprendre de plus.
+
+**Un scan vert n'est pas un scan qui a testé quelque chose.** Deux garde-fous, eux, **bloquent** :
+
+- **Moins de 80% des opérations du contrat importées.** Constaté une première fois : 2 URL sur 26
+  opérations importées, ZAP n'avait envoyé que des requêtes vouées au 404 (l'analyseur de ZAP
+  refusait alors le nom accentué d'un des deux schémas de sécurité du contrat, corrigé depuis en
+  ASCII côté backend). Le seuil est dérivé du contrat (`zap-out/openapi.json`, présent à cette
+  étape) plutôt que d'un nombre fixe : un contrat qui grossit ne doit pas rendre la garde plus
+  permissive qu'elle ne l'était.
+- **Aucune réponse 2xx.** Constaté une deuxième fois, cause différente : la clé de configuration
+  du nom d'en-tête pour la règle Replacer est `matchstr`, pas `matchstring` (celui-ci n'existe que
+  pour le job d'automatisation ZAP, pas pour `-config`) ; ZAP acceptait la mauvaise clé sans
+  erreur et laissait le nom d'en-tête vide, qu'uvicorn refusait par un `400` sur **toute** requête,
+  y compris les routes publiques. Piège de conception rencontré en corrigeant cette garde : borner
+  le *pourcentage* de 4xx ne marche pas, un scan actif fuzze délibérément un grand nombre
+  d'entrées invalides, si bien qu'un scan sain contre l'API seedée reste à 98% de 4xx avec
+  seulement 1% de 2xx. C'est la forme normale d'un scan actif. Le signal qui distingue vraiment un
+  scan cassé (2xx nul, absent du rapport dans les deux incidents) d'un scan sain (2xx non nul,
+  aussi faible soit-il) est l'absence de succès, pas la part d'échecs. Les deux gardes lisent
+  `zap-out/zap-report.json` (champs structurés `insights[]`), pas le texte libre du rapport
+  Markdown.
+
+Le journal interne de ZAP (`zap.log`) et sa sortie complète (`zap-stdout.log`) sont publiés dans
+l'artefact `zap-report` (dossier `zap-logs/`, propriété du runner : `zap-out/` bascule sous l'uid
+1000 du conteneur ZAP dès que le contrat y est copié, le runner n'y écrit plus ensuite) pour
+diagnostiquer un futur import raté.
+
+**Non bloquant pour l'instant** (`continue-on-error`, sur la seule étape du scan) pour ce qui est
+des alertes elles-mêmes. Le volume d'un premier passage trié est inconnu ; le rapport
+HTML/JSON/Markdown est publié en artefact `zap-report`, et sa synthèse (jusqu'aux tableaux
+d'alertes, sans le détail par alerte) dans le résumé du job. Fixer un seuil viendra une fois les
+alertes triées.
+
+**Limite à ne pas oublier :** le scan tape la configuration par défaut du backend (`APP_ENV=local`,
+pas de TLS, pas de reverse proxy). Il remontera des alertes qui n'existent pas derrière le proxy
+(HSTS absent...) et ne dit **rien** des en-têtes ni du TLS que le proxy pose en production. Un
+second passage sur la stack complète reste à faire.
+
 ## Ce qui manque, et pourquoi

 | Manque | Issue | Conséquence assumée |
 |---|---|---|
 | Images publiées et promues par digest (GHCR) | aucune | Chaque environnement reconstruit ses images : la production n'exécute pas l'artefact validé en recette, mais un second build du même commit |
-| DAST (OWASP ZAP) | #41 | Aucune vérification sur l'application en fonctionnement, seulement sur le code et les dépendances |
+| DAST bloquant | #41 | Le scan ZAP existe mais ne bloque rien : aucun seuil n'est fixé tant que les alertes du premier passage ne sont pas triées |
 | Tests end to end | #46 | Les parcours utilisateur ne sont pas vérifiés en CI |
 | Tests de charge | #47 | Aucun garde-fou de performance |
 | Scan d'image de conteneur | aucune | Les `Dockerfile` sont construits en local, pas analysés |
@@ -38,6 +38,7 @@ lecture seule ; plusieurs lignes resteront à compléter une fois les endpoints
 | Caviardage des jetons, empreintes, mots de passe et cookies dans les journaux | `app/core/logging.py` | A09, A02 |
 | Cinq gardes de configuration qui refusent le démarrage plutôt que de dégrader silencieusement | `app/core/config.py` | A05 |
 | Documentation interactive fermée hors développement, `/metrics` derrière un jeton, sonde qui ne publie plus de version | `app/main.py`, `app/api/security.py` | A05 |
+| Scan dynamique OWASP ZAP de l'API authentifiée (compte `lecteur` jetable), non bloquant, configuration par défaut du backend uniquement (ni TLS ni en-têtes du reverse proxy) | `.github/workflows/dast.yml`, `scripts/dast-token.sh` | A05, API8 Security Misconfiguration |
 | En-têtes `nosniff`, `DENY`, `no-referrer`, et `no-store` sur les routes d'authentification | `app/api/middleware.py` | A05 |
 | Refus de rétrograder ou désactiver le dernier administrateur actif | `app/services/user.py` | A04 Insecure Design |
 | Amorçage du premier administrateur hors dépôt, mot de passe jamais dans `argv` ni dans Git | `app/cli.py` | A02, A05 |
@@ -1,18 +1,48 @@
 # Infrastructure

-Provisionnement Terraform de la machine on-premise (serveur physique, accessible en SSH).
+Provisionnement Terraform des machines on-premise. Terraform prepare la machine, GitHub Actions
+deploie l'application : voir l'[ADR 0010](../docs/adr/0010-terraform-provisionne-github-actions-deploie.md).
+Rien ici ne construit d'image ni ne lance de conteneur.

 - `terraform/modules` : modules reutilisables.
  - `k3s` : installe un cluster k3s single-node sur une machine distante via SSH
    (script officiel `get.k3s.io`) et rapatrie le kubeconfig en local.
- `terraform/environments/<env>` : racines Terraform, une par environnement.
-  - `dev` : instancie le module `k3s` sur le serveur de l'ecole.
-  - `prod` : non initialise, voir le ticket dedie.
+- `terraform/environments/<racine>` : une racine par machine provisionnee.
+  - `vm-eni` : la VM `eadl-2025-nantes-g3`, qui porte les environnements `rec` et `prod`
+    ([ADR 0009](../docs/adr/0009-deux-environnements-compose-sur-la-vm-eni.md)). Installe Docker,
+    execute `scripts/provision-host.sh`, enregistre le runner GitHub Actions.
+  - `k3s-cible` : le cluster k3s, cible a terme de `docs/architecture/10-infra.md`. Jamais
+    applique.

-## Usage (environments/dev)
+## Usage (environments/vm-eni)

 ```bash
-cd infra/terraform/environments/dev
+cd infra/terraform/environments/vm-eni
+cp terraform.tfvars.example terraform.tfvars
+terraform init
+terraform apply
+```
+
+`terraform.tfvars` est ignore par git. Trois valeurs sont a renseigner avant l'apply :
+
+- `proprietaire` : l'utilisateur qui possede `/srv/enervision` et fait tourner le runner. Il doit
+  deja exister sur la machine.
+- `runner_version` : a epingler depuis <https://github.com/actions/runner/releases>.
+- `runner_token` : jeton d'enregistrement, valable une heure et pour une seule inscription.
+  Parametres du depot, Actions, Runners, New self-hosted runner. Seul un administrateur du depot
+  peut le creer.
+
+Apres l'apply, la machine porte `/srv/enervision/rec` et `/srv/enervision/prod`, chacun avec son
+`.env` et son certificat. Le premier demarrage reste manuel, `make stack-up` dans chaque dossier ;
+les suivants sont joues par le runner a chaque push sur `dev` et sur `main`.
+
+Retirer le runner se fait a la main, depuis les parametres du depot : `terraform destroy` ne le
+desinscrit pas.
+
+## Usage (environments/k3s-cible)
+
+```bash
+cd infra/terraform/environments/k3s-cible
 cp terraform.tfvars.example terraform.tfvars   # renseigner ssh_host / ssh_private_key_path
 terraform init
 terraform apply
@@ -0,0 +1,23 @@
+# This file is maintained automatically by "terraform init".
+# Manual edits may be lost in future updates.
+
+provider "registry.terraform.io/hashicorp/null" {
+  version     = "3.3.2"
+  constraints = "~> 3.2"
+  hashes = [
+    "h1:IQ1qrkht1sC1nibUR+AJ3ulryyhVDHfCHZhoJi0sg2Y=",
+    "zh:10ec43b8b7b18d5639238c7fb9e111f6a4b038523dd66c7a426bf27b25fa4c08",
+    "zh:60beb9cc2ad5b871c710860cee75b42850cc6acd43db0d77cb5e00fda7288b55",
+    "zh:62538582d0a4a2f10ad8a8d9a6c3cd3f05af6c6d91c6641ffc78d4f0e8e69b27",
+    "zh:64a8f9ce7852d9efc5b464c12306c946366d59f5e2757def97969c9fd64bd1d6",
+    "zh:78d5eefdd9e494defcb3c68d282b8f96630502cac21d1ea161f53cfe9bb483b3",
+    "zh:92a374fb736a52f465283326d0a5bf4f495132eb99be209dfb4c75ec803fe8db",
+    "zh:98da9c42785d27a50f0604758bcb61a30f6278b9f2acd92bb3b2046e0e71916c",
+    "zh:b0f7896fae554729cdf4a24ac06359a050cff5817e6cd8597cba8a4ae01a7409",
+    "zh:bc8179ee35d67c72fb03012e7023b9f9816f033a7ec4109c001dd6d29752e812",
+    "zh:d23a598f713bfb6098bc003571d7de90b5a33b78f9be240488252fe5f3c2a60d",
+    "zh:d2855b922ea345dbd89ea287e4c6c4757e38bc0aaffeb2b79aa0b8004f9c53ff",
+    "zh:d3a60422bc6a2f9244d076c5222c07060c826ef91bdbaf4634cb752b86057473",
+    "zh:faa01928c25d2a6ecd9c7eb8b88134cb08de55a6b11ca6c703ac0092845344ba",
+  ]
+}
@@ -0,0 +1,23 @@
+# This file is maintained automatically by "terraform init".
+# Manual edits may be lost in future updates.
+
+provider "registry.terraform.io/hashicorp/null" {
+  version     = "3.3.2"
+  constraints = "~> 3.2"
+  hashes = [
+    "h1:IQ1qrkht1sC1nibUR+AJ3ulryyhVDHfCHZhoJi0sg2Y=",
+    "zh:10ec43b8b7b18d5639238c7fb9e111f6a4b038523dd66c7a426bf27b25fa4c08",
+    "zh:60beb9cc2ad5b871c710860cee75b42850cc6acd43db0d77cb5e00fda7288b55",
+    "zh:62538582d0a4a2f10ad8a8d9a6c3cd3f05af6c6d91c6641ffc78d4f0e8e69b27",
+    "zh:64a8f9ce7852d9efc5b464c12306c946366d59f5e2757def97969c9fd64bd1d6",
+    "zh:78d5eefdd9e494defcb3c68d282b8f96630502cac21d1ea161f53cfe9bb483b3",
+    "zh:92a374fb736a52f465283326d0a5bf4f495132eb99be209dfb4c75ec803fe8db",
+    "zh:98da9c42785d27a50f0604758bcb61a30f6278b9f2acd92bb3b2046e0e71916c",
+    "zh:b0f7896fae554729cdf4a24ac06359a050cff5817e6cd8597cba8a4ae01a7409",
+    "zh:bc8179ee35d67c72fb03012e7023b9f9816f033a7ec4109c001dd6d29752e812",
+    "zh:d23a598f713bfb6098bc003571d7de90b5a33b78f9be240488252fe5f3c2a60d",
+    "zh:d2855b922ea345dbd89ea287e4c6c4757e38bc0aaffeb2b79aa0b8004f9c53ff",
+    "zh:d3a60422bc6a2f9244d076c5222c07060c826ef91bdbaf4634cb752b86057473",
+    "zh:faa01928c25d2a6ecd9c7eb8b88134cb08de55a6b11ca6c703ac0092845344ba",
+  ]
+}
@@ -0,0 +1,137 @@
+# Pourquoi : Terraform provisionne la machine, GitHub Actions la deploie (ADR 0010). Rien ici ne
+# construit d'image ni ne lance de conteneur : la livraison reste portee par `deploy.yml` et
+# `make stack-up`, et un `apply` n'interrompt pas la stack qui tourne.
+# Piege : seul le bloc `triggers` d'un `null_resource` atterrit dans le state. Ni le jeton du
+# runner ni la cle SSH n'y figurent, et ne doivent jamais y etre ajoutes pour forcer un rejeu.
+# Contrainte : pas de provisioner `destroy` sur le runner. Il imposerait une connexion ne lisant
+# que `self`, donc le chemin de la cle SSH dans le state, et `svc.sh uninstall` ne desinscrit pas
+# le runner cote GitHub : le retrait reste manuel, depuis les parametres du depot.
+# Ref : ADR 0009 pour les deux environnements, `scripts/provision-host.sh` pour leur contenu.
+
+locals {
+  sudo           = var.ssh_user == "root" ? "" : "sudo "
+  en_tant_que    = "${var.ssh_user == "root" ? "" : "sudo "}runuser -u ${var.proprietaire} --"
+  provisionneur  = "${path.root}/../../../../scripts/provision-host.sh"
+  runner_archive = "actions-runner-linux-x64-${var.runner_version}.tar.gz"
+  # Substitution shell, evaluee par le sh -c distant : un nom de runner doit etre unique dans
+  # le depot, le nom d'hote l'est deja et le reste si cette racine sert a une autre machine.
+  runner_nom = var.runner_nom != "" ? var.runner_nom : "$(hostname -s)"
+}
+
+resource "null_resource" "docker_engine" {
+  triggers = {
+    hote = var.ssh_host
+    user = var.proprietaire
+  }
+
+  connection {
+    type        = "ssh"
+    host        = var.ssh_host
+    port        = var.ssh_port
+    user        = var.ssh_user
+    private_key = file(pathexpand(var.ssh_private_key_path))
+    timeout     = "5m"
+  }
+
+  provisioner "remote-exec" {
+    inline = [
+      <<-EOT
+        set -eu
+        id ${var.proprietaire} >/dev/null 2>&1 || {
+          echo "l'utilisateur ${var.proprietaire} n'existe pas sur la machine" >&2
+          exit 1
+        }
+        command -v docker >/dev/null || ${local.sudo}sh -c 'curl -fsSL https://get.docker.com | sh'
+        ${local.sudo}systemctl enable --now docker
+        ${local.sudo}usermod -aG docker ${var.proprietaire}
+        ${local.sudo}docker compose version
+      EOT
+    ]
+  }
+}
+
+# `provision-host.sh` verifie lui-meme docker, compose et la sortie HTTPS, puis prepare un clone
+# par environnement, son `.env` et son certificat. Il est rejouable : un `.env` existant n'est
+# jamais reecrit, un certificat present jamais regenere.
+resource "null_resource" "environnements" {
+  depends_on = [null_resource.docker_engine]
+
+  triggers = {
+    script = filesha256(local.provisionneur)
+    racine = var.racine
+    depot  = var.depot_url
+  }
+
+  connection {
+    type        = "ssh"
+    host        = var.ssh_host
+    port        = var.ssh_port
+    user        = var.ssh_user
+    private_key = file(pathexpand(var.ssh_private_key_path))
+    timeout     = "5m"
+  }
+
+  provisioner "file" {
+    source      = local.provisionneur
+    destination = "/tmp/provision-host.sh"
+  }
+
+  provisioner "remote-exec" {
+    inline = [
+      <<-EOT
+        set -eu
+        ${local.sudo}env RACINE='${var.racine}' \
+          REPO_URL='${var.depot_url}' \
+          PROPRIETAIRE='${var.proprietaire}' \
+          PUBLIC_IP='${var.adresse_publique}' \
+          bash /tmp/provision-host.sh
+        rm -f /tmp/provision-host.sh
+      EOT
+    ]
+  }
+}
+
+# Piege : le jeton d'enregistrement expire en une heure. Un `apply` rejoue cette ressource des
+# que `runner_version`, `runner_labels` ou `runner_nom` change, et redemande donc un jeton frais.
+resource "null_resource" "runner_github" {
+  depends_on = [null_resource.environnements]
+
+  triggers = {
+    version = var.runner_version
+    labels  = var.runner_labels
+    nom     = local.runner_nom
+    dossier = var.runner_dossier
+  }
+
+  connection {
+    type        = "ssh"
+    host        = var.ssh_host
+    port        = var.ssh_port
+    user        = var.ssh_user
+    private_key = file(pathexpand(var.ssh_private_key_path))
+    timeout     = "5m"
+  }
+
+  provisioner "remote-exec" {
+    inline = [
+      <<-EOT
+        set -eu
+        ${local.sudo}install -d -o ${var.proprietaire} -g ${var.proprietaire} ${var.runner_dossier}
+        if [ ! -x ${var.runner_dossier}/config.sh ]; then
+          curl -fsSL -o /tmp/${local.runner_archive} \
+            https://github.com/actions/runner/releases/download/v${var.runner_version}/${local.runner_archive}
+          ${local.sudo}tar -xzf /tmp/${local.runner_archive} -C ${var.runner_dossier}
+          ${local.sudo}chown -R ${var.proprietaire}:${var.proprietaire} ${var.runner_dossier}
+          rm -f /tmp/${local.runner_archive}
+        fi
+        if [ ! -f ${var.runner_dossier}/.runner ]; then
+          ${local.en_tant_que} sh -c 'cd ${var.runner_dossier} && ./config.sh --unattended --replace \
+            --url ${var.runner_url} --token ${var.runner_token} \
+            --labels ${var.runner_labels} --name ${local.runner_nom} --work _work'
+          ${local.sudo}${var.runner_dossier}/svc.sh install ${var.proprietaire}
+        fi
+        ${local.sudo}${var.runner_dossier}/svc.sh start
+      EOT
+    ]
+  }
+}
@@ -0,0 +1,9 @@
+output "machine" {
+  description = "Machine provisionnee et racine qui porte un clone par environnement."
+  value       = "${var.ssh_user}@${var.ssh_host}:${var.racine}"
+}
+
+output "runner" {
+  description = "Dossier d'installation du runner et libelles supplementaires annonces a GitHub."
+  value       = "${var.runner_dossier} (${var.runner_labels})"
+}
@@ -0,0 +1,22 @@
+ssh_host             = "10.101.200.37"
+ssh_port             = 22
+ssh_user             = "root"
+ssh_private_key_path = "~/.ssh/id_ed25519"
+
+# Utilisateur qui possede la racine et fait tourner le runner. Il doit deja exister sur la
+# machine : git refuse les depots appartenant a un autre utilisateur, et un .env en 600 lui
+# echapperait.
+proprietaire = "enervision"
+
+# Epingler une version reelle : https://github.com/actions/runner/releases
+runner_version = "2.330.0"
+
+# Jeton d'enregistrement du runner, valable une heure et pour une seule inscription :
+# Parametres du depot > Actions > Runners > New self-hosted runner. Seul un administrateur du
+# depot peut le creer. terraform.tfvars est ignore par git, mais le jeton ne doit pas y rester
+# apres l'apply.
+runner_token = "A_RENSEIGNER"
+
+# Nom du runner cote GitHub. Vide par defaut : le nom d'hote de la machine. A renseigner
+# seulement si deux runners doivent tourner sur la meme machine, leurs noms devant differer.
+# runner_nom = "eni-g3-bis"
@@ -0,0 +1,90 @@
+variable "ssh_host" {
+  type        = string
+  description = "Adresse de la VM ENI qui porte les deux environnements (ADR 0009)."
+}
+
+variable "ssh_port" {
+  type        = number
+  description = "Port SSH de la VM."
+  default     = 22
+}
+
+variable "ssh_user" {
+  type        = string
+  description = "Utilisateur SSH du provisionnement. Different de root, les commandes privilegiees sont prefixees par sudo."
+  default     = "root"
+}
+
+variable "ssh_private_key_path" {
+  type        = string
+  description = "Chemin local vers la cle privee SSH. L'authentification par mot de passe n'est volontairement pas prise en charge : une variable de mot de passe finit en clair dans le state ou dans les triggers."
+  sensitive   = true
+}
+
+variable "proprietaire" {
+  type        = string
+  description = "Utilisateur qui possede la racine et fait tourner le runner. Il doit exister sur la machine : git refuse les depots appartenant a un autre utilisateur, et un .env en 600 lui echapperait."
+
+  validation {
+    condition     = can(regex("^[a-z_][a-z0-9_-]*$", var.proprietaire))
+    error_message = "proprietaire doit etre un nom d'utilisateur Unix valide."
+  }
+}
+
+variable "racine" {
+  type        = string
+  description = "Dossier qui porte un clone du depot par environnement."
+  default     = "/srv/enervision"
+}
+
+variable "depot_url" {
+  type        = string
+  description = "URL de clonage du depot, passee a provision-host.sh."
+  default     = "https://github.com/ineszang/ProjetPiscine_EnerVision.git"
+}
+
+variable "adresse_publique" {
+  type        = string
+  description = "Adresse annoncee dans les certificats auto-signes. Vide : la premiere adresse de la VM."
+  default     = ""
+}
+
+variable "runner_url" {
+  type        = string
+  description = "Depot GitHub auquel le runner s'enregistre."
+  default     = "https://github.com/ineszang/ProjetPiscine_EnerVision"
+}
+
+variable "runner_version" {
+  type        = string
+  description = "Version d'actions-runner a installer, sans le v initial (ex: 2.330.0). Voir https://github.com/actions/runner/releases."
+
+  validation {
+    condition     = can(regex("^[0-9]+\\.[0-9]+\\.[0-9]+$", var.runner_version))
+    error_message = "runner_version doit etre epinglee explicitement (ex: 2.330.0), sinon l'installation cesse d'etre reproductible."
+  }
+}
+
+variable "runner_token" {
+  type        = string
+  description = "Jeton d'enregistrement du runner. Expire au bout d'une heure et ne vaut que pour une inscription : Parametres du depot > Actions > Runners > New self-hosted runner. Seul un administrateur du depot peut le creer."
+  sensitive   = true
+}
+
+variable "runner_labels" {
+  type        = string
+  description = "Libelles supplementaires du runner. deploy.yml cible [self-hosted, linux, eni-g3], les deux premiers etant poses par GitHub."
+  default     = "eni-g3"
+}
+
+variable "runner_nom" {
+  type        = string
+  description = "Nom du runner cote GitHub, unique dans le depot. Vide : le nom d'hote de la machine, qui reste unique si cette racine est reprise pour une seconde VM. A renseigner pour faire tourner deux runners sur la meme machine."
+  default     = ""
+}
+
+variable "runner_dossier" {
+  type        = string
+  description = "Dossier d'installation du runner sur la machine."
+  default     = "/opt/actions-runner"
+}
@@ -0,0 +1,14 @@
+terraform {
+  required_version = ">= 1.7"
+
+  required_providers {
+    null = {
+      source  = "hashicorp/null"
+      version = "~> 3.2"
+    }
+  }
+
+  backend "local" {
+    path = "terraform.tfstate"
+  }
+}
@@ -5,19 +5,26 @@ locals {
  kubeconfig_cmd = "${local.sudo_prefix}cat /etc/rancher/k3s/k3s.yaml"
 }

+# Piege : un provisioner `destroy` impose que tout le bloc `connection` ne lise que `self`, sinon
+# `terraform init` refuse le module. D'ou la connexion batie sur `triggers`, ou ne figurent que
+# l'adresse, le port, l'utilisateur et le chemin de la cle : jamais la cle ni un mot de passe.
 resource "null_resource" "k3s_install" {
  triggers = {
    ssh_host           = var.ssh_host
+    ssh_port           = tostring(var.ssh_port)
+    ssh_user           = var.ssh_user
+    ssh_key_path       = var.ssh_private_key_path
+    sudo_prefix        = local.sudo_prefix
    k3s_version        = var.k3s_version
    disable_components = join(",", var.k3s_disable_components)
  }

  connection {
    type        = "ssh"
-    host        = var.ssh_host
-    port        = var.ssh_port
-    user        = var.ssh_user
-    private_key = file(var.ssh_private_key_path)
+    host        = self.triggers.ssh_host
+    port        = tonumber(self.triggers.ssh_port)
+    user        = self.triggers.ssh_user
+    private_key = file(pathexpand(self.triggers.ssh_key_path))
  }

  provisioner "remote-exec" {
@@ -33,7 +40,7 @@ resource "null_resource" "k3s_install" {
    when       = destroy
    on_failure = continue
    inline = [
-      "${local.sudo_prefix}sh -c 'test -x /usr/local/bin/k3s-uninstall.sh && /usr/local/bin/k3s-uninstall.sh || true'",
+      "${self.triggers.sudo_prefix}sh -c 'test -x /usr/local/bin/k3s-uninstall.sh && /usr/local/bin/k3s-uninstall.sh || true'",
    ]
  }
 }
@@ -1,6 +0,0 @@
-.venv
-data
-mlruns
-mlflow.db*
-models
-.env
@@ -1 +0,0 @@
-MLFLOW_DB_PASSWORD=change-me
@@ -1,7 +0,0 @@
-FROM python:3.14-slim
-RUN pip install --no-cache-dir --only-binary :all: mlflow==3.16.1 psycopg2-binary==2.9.13
-RUN useradd --create-home --uid 1000 mlflow \
-    && mkdir /mlartifacts \
-    && chown mlflow /mlartifacts
-USER mlflow
-EXPOSE 5000
@@ -57,50 +57,6 @@ validation. La coupure est **chronologique**, jamais un tirage aleatoire de lign
 aleatoire laisserait des lignes de validation "voir" des lignes d'entrainement via leurs
 lags/moyennes glissantes, une fuite qui masquerait un surapprentissage.

-## Serveur MLflow (conteneur)
-
-Premiere utilisation : copier `.env.example` en `.env` et y choisir un mot de passe PostgreSQL
-(lettres et chiffres uniquement). Le fichier `.env` est ignore par git.
-
-```bash
-cp .env.example .env
-```
-
-Un serveur MLflow (PostgreSQL pour les metadonnees, volume pour les artefacts) se lance avec
-Docker. Prerequis : Docker Desktop demarre.
-
-```bash
-make mlflow-up
-```
-
-La cible vérifie que `MLFLOW_DB_PASSWORD` (définie dans `ml/.env`) ne contient que des lettres et
-des chiffres avant de démarrer le serveur : ce mot de passe est interpolé directement dans l'URI
-PostgreSQL (`postgresql://mlflow:${MLFLOW_DB_PASSWORD}@...`), un caractère spécial la rendrait
-invalide sans message d'erreur clair.
-
-Interface : http://localhost:5000. Entrainer vers ce serveur :
-
-```
-uv run python -m enervision_ml.train --csv data/all_sites_combined.csv --mlflow-tracking-uri http://localhost:5000
-```
-
-Arreter : `docker compose -f docker-compose.mlflow.yml down` (ajouter `-v` pour effacer aussi les
-runs et les modeles).
-
-Pour voir les runs dans l'interface (MLflow 3.x) :
-
- Passer le selecteur en haut a gauche sur **Model training**. Le mode **GenAI** affiche des
-  traces LLM et reste vide pour un entrainement LightGBM.
- **Runs** liste les entrainements, **Models** les artefacts de modele de chaque run (tous nommes
-  `model`), et **Model registry** les versions numerotees de `consumption-forecast-lightgbm`.
-
-Limites : l'identifiant PostgreSQL du compose est fixe a `mlflow`, le mot de passe vient de la
-variable obligatoire `MLFLOW_DB_PASSWORD` (aucune valeur par defaut, le compose refuse de
-demarrer sans elle) -- ce mot de passe est choisi lors de la copie de `.env.example`, il ne
-convient donc qu'au developpement local tel quel. Un deploiement partage demandera des secrets,
-de l'authentification et un stockage d'artefacts dedie (S3/MinIO). Le port 5000 doit etre libre : arreter `mlflow ui` avant,
-ou changer le mapping (`"5001:5000"`) dans le compose.
-
 ## Scoring

 ```bash
@@ -127,13 +83,6 @@ section 2 :
 fichier : `train.py` reecrit toujours le meme chemin a chaque entrainement, donc le nom seul ne
 distinguerait pas deux versions du modele.

-**Le scoring ne lit pas le Model Registry.** Le fichier charge par `--model` est local
-(`models/lightgbm-consumption.txt`), independant des versions enregistrees dans le
-**Model registry** MLflow (`consumption-forecast-lightgbm`). `train.py` enregistre bien une
-version a chaque entrainement (tracabilite), mais aucun alias (`champion` par exemple) n'est
-pose, et `enervision_ml.score` ne les lit pas. Le registre sert aujourd'hui a la tracabilite des
-entrainements, pas au deploiement du modele utilise en scoring.
-
 En mode `--csv`, rien n'est ecrit en base : c'est un instantane historique fige (l'heure "future"
 calculee a partir de la fin du CSV n'existe dans aucune base reelle), utile pour valider le
 pipeline sans base joignable.
@@ -1,32 +0,0 @@
-services:
-  mlflow-db:
-    image: postgres:17
-    environment:
-      POSTGRES_USER: mlflow
-      POSTGRES_PASSWORD: ${MLFLOW_DB_PASSWORD:?definir MLFLOW_DB_PASSWORD dans ml/.env}
-      POSTGRES_DB: mlflow
-    volumes:
-      - mlflow-db-data:/var/lib/postgresql/data
-    healthcheck:
-      test: ["CMD-SHELL", "pg_isready -U mlflow"]
-      interval: 5s
-      retries: 10
-
-  mlflow:
-    build: .
-    depends_on:
-      mlflow-db:
-        condition: service_healthy
-    ports:
-      - "127.0.0.1:5000:5000"
-    volumes:
-      - mlflow-artifacts:/mlartifacts
-    environment:
-      MLFLOW_DB_PASSWORD: ${MLFLOW_DB_PASSWORD}
-    entrypoint: [ "/bin/sh", "-c" ]
-    command:
-      - exec mlflow server --host 0.0.0.0 --port 5000 --backend-store-uri "postgresql://mlflow:$$MLFLOW_DB_PASSWORD@mlflow-db:5432/mlflow" --artifacts-destination /mlartifacts --serve-artifacts
-
-volumes:
-  mlflow-db-data:
-  mlflow-artifacts:
@@ -181,11 +181,7 @@ def _log_to_mlflow(
        )
        mlflow.log_metrics({f"model_{cle}": valeur for cle, valeur in model_metrics.items()})
        mlflow.log_metrics({f"baseline_{cle}": valeur for cle, valeur in baseline_metrics.items()})
-        mlflow.lightgbm.log_model(
-            booster,
-            name="model",
-            registered_model_name="consumption-forecast-lightgbm",
-        )
+        mlflow.lightgbm.log_model(booster, name="model")
        mlflow.log_artifact(str(model_output))


@@ -3,7 +3,6 @@ from pathlib import Path

 import numpy as np
 import pandas as pd
-import pytest

 from enervision_ml.features import TARGET_COLUMN, build_features, feature_columns
 from enervision_ml.train import chronological_split, prepare_dataset, train
@@ -75,19 +74,3 @@ def test_train_runs_end_to_end_on_synthetic_data_and_beats_a_dummy_baseline(
    assert model_metrics["n_observations"] > 0
    assert model_metrics["mae"] >= 0
    assert baseline_metrics["n_observations"] == model_metrics["n_observations"]
-    assert model_metrics["mae"] < baseline_metrics["mae"]
-
-
-def test_train_raises_when_the_validation_window_is_empty(tmp_path: Path) -> None:
-    depart = datetime(2026, 1, 1, tzinfo=UTC)
-    frame = make_frame("site-a", heures=50, depart=depart)  # trop court pour un lag de 168h
-    csv_path = tmp_path / "trop_court.csv"
-    frame.to_csv(csv_path, index=False)
-
-    with pytest.raises(ValueError, match="Fenetre d'entrainement ou de validation vide"):
-        train(
-            csv_path=csv_path,
-            model_output=tmp_path / "model.txt",
-            test_fraction=0.2,
-            tracking_uri=f"sqlite:///{tmp_path / 'mlflow.db'}",
-        )
@@ -1,3 +1,11 @@
 # Scripts

 Outillage local du monorepo. Les taches courantes passent par le `Makefile` racine.
+
+## dast-token.sh
+
+Prépare le scan DAST (`.github/workflows/dast.yml`) : sur une API déjà démarrée, crée un compte
+`lecteur` jetable, lui fait passer le changement de mot de passe obligatoire et écrit son jeton
+d'accès sur la sortie standard. À lancer depuis `apps/backend`, contre une base **jetable** (il y
+crée deux comptes) : `BASE_URL=http://localhost:8000 ../../scripts/dast-token.sh`. Nécessite `curl`,
+`jq` et `openssl`.
@@ -0,0 +1,78 @@
+#!/usr/bin/env bash
+# Prépare le scan DAST : crée un compte `lecteur` sur une API déjà démarrée, lui fait passer le
+# changement de mot de passe obligatoire, et écrit son jeton d'accès sur la sortie standard.
+#
+# Piège : un compte neuf est en `must_change_password`, et toute route gardée le refuse tant que
+# le mot de passe n'a pas été changé. Sans cette étape, ZAP ne verrait que 403 sur les routes
+# gardées et le scan ne testerait rien de l'API authentifiée.
+#
+# Contrainte : le compte du scan est `lecteur`, jamais `admin`. Un scan actif avec un jeton admin
+# frapperait POST /users ou la réinitialisation de mots de passe pour de bon.
+#
+# L'administrateur n'existe que pour créer ce compte (l'API n'a pas d'inscription publique).
+# À lancer depuis apps/backend, dans un environnement où DATABASE_URL et APP_SECRET_KEY visent
+# une base JETABLE : le script y crée deux comptes.
+
+set -euo pipefail
+
+BASE_URL="${BASE_URL:-http://localhost:8000}"
+API="$BASE_URL/api/v1"
+SUFFIXE="$(openssl rand -hex 4)"
+EMAIL_ADMIN="dast-admin-$SUFFIXE@enervision.fr"
+EMAIL_LECTEUR="dast-lecteur-$SUFFIXE@enervision.fr"
+
+# Classes exigées par le validateur : majuscule, minuscule, chiffre, caractère spécial.
+nouveau_mot_de_passe() { echo "Dast-$(openssl rand -hex 12)-Aa1!"; }
+
+# Tout ce qui n'est pas la sortie finale part sur stderr : la sortie standard ne porte que le jeton.
+journal() { echo "dast-token: $*" >&2; }
+
+connexion() {
+    local email="$1" mot_de_passe="$2"
+    curl -fsS -X POST "$API/auth/login" -H 'Content-Type: application/json' \
+        -d "$(jq -n --arg e "$email" --arg p "$mot_de_passe" '{email:$e, password:$p}')" \
+        | jq -r '.access_token'
+}
+
+# Rend le nouveau jeton d'accès : `/auth/password` en émet un (avec l'`iat` de la session en
+# cours, cf. le piège documenté dans `app/api/deps.py`), pas seulement une confirmation. S'y fier
+# évite une reconnexion, donc un second hachage Argon2id (19456 Kio) et un aller-retour de
+# refresh-token superflus sur le chemin critique de la CI.
+changer_mot_de_passe() {
+    local jeton="$1" ancien="$2" nouveau="$3"
+    curl -fsS -X POST "$API/auth/password" \
+        -H "Authorization: Bearer $jeton" -H 'Content-Type: application/json' \
+        -d "$(jq -n --arg a "$ancien" --arg n "$nouveau" '{current_password:$a, new_password:$n}')" \
+        | jq -r '.access_token'
+}
+
+journal "création de l'administrateur $EMAIL_ADMIN"
+if ! SORTIE="$(uv run --frozen --no-sync --no-build python -m app.cli create-admin --email "$EMAIL_ADMIN" --generate)"; then
+    journal "la création de l'administrateur a échoué :"
+    journal "$SORTIE"
+    exit 1
+fi
+MDP_ADMIN="$(sed -n 's/^Mot de passe généré, il ne sera plus affiché : //p' <<<"$SORTIE")"
+[[ -n "$MDP_ADMIN" ]] || { journal "mot de passe administrateur introuvable dans la sortie :"; journal "$SORTIE"; exit 1; }
+
+JETON="$(connexion "$EMAIL_ADMIN" "$MDP_ADMIN")"
+NOUVEAU_ADMIN="$(nouveau_mot_de_passe)"
+JETON="$(changer_mot_de_passe "$JETON" "$MDP_ADMIN" "$NOUVEAU_ADMIN")"
+
+journal "création du lecteur $EMAIL_LECTEUR"
+REPONSE="$(curl -fsS -X POST "$API/users" -H "Authorization: Bearer $JETON" \
+    -H 'Content-Type: application/json' \
+    -d "$(jq -n --arg e "$EMAIL_LECTEUR" '{email:$e, role:"lecteur"}')")"
+MDP_TEMPORAIRE="$(jq -r '.temporary_password // empty' <<<"$REPONSE")"
+[[ -n "$MDP_TEMPORAIRE" ]] || { journal "mot de passe temporaire introuvable dans la réponse de POST /users :"; journal "$REPONSE"; exit 1; }
+
+JETON="$(connexion "$EMAIL_LECTEUR" "$MDP_TEMPORAIRE")"
+NOUVEAU_LECTEUR="$(nouveau_mot_de_passe)"
+JETON="$(changer_mot_de_passe "$JETON" "$MDP_TEMPORAIRE" "$NOUVEAU_LECTEUR")"
+
+# Vérifie que le jeton ouvre bien une route gardée avant de le rendre.
+CODE="$(curl -sS -o /dev/null -w '%{http_code}' "$API/sites" -H "Authorization: Bearer $JETON")"
+[[ "$CODE" == "200" ]] || { journal "GET /sites répond $CODE avec le jeton du lecteur, attendu 200"; exit 1; }
+
+journal "jeton du lecteur prêt"
+echo "$JETON"
@@ -47,13 +47,15 @@ preparer() {
    fi

    if [[ ! -f "$dossier/.env" ]]; then
+        local brouillon="$dossier/.env.brouillon" oubliees
        sed -e "s|^POSTGRES_PASSWORD=.*|POSTGRES_PASSWORD=$(secret)|" \
            -e "s|^POSTGRES_PORT=.*|POSTGRES_PORT=$port_pg|" \
            -e "s|^APP_SECRET_KEY=.*|APP_SECRET_KEY=$(secret)|" \
            -e "s|^MAILPIT_UI_PORT=.*|MAILPIT_UI_PORT=$port_mailpit|" \
            -e "s|^AIRFLOW_PORT=.*|AIRFLOW_PORT=$port_airflow|" \
            -e "s|^AIRFLOW_FERNET_KEY=.*|AIRFLOW_FERNET_KEY=$(fernet)|" \
-            -e "s|^AIRFLOW_WEBSERVER_SECRET_KEY=.*|AIRFLOW_WEBSERVER_SECRET_KEY=$(secret)|" \
+            -e "s|^AIRFLOW_API_SECRET_KEY=.*|AIRFLOW_API_SECRET_KEY=$(secret)|" \
+            -e "s|^AIRFLOW_JWT_SECRET=.*|AIRFLOW_JWT_SECRET=$(secret)|" \
            -e "s|^AIRFLOW_ADMIN_PASSWORD=.*|AIRFLOW_ADMIN_PASSWORD=$(secret | cut -c1-20)|" \
            -e "s|^AIRFLOW_APP_SECRET_KEY=.*|AIRFLOW_APP_SECRET_KEY=$(secret)|" \
            -e "s|^PUBLIC_HOST=.*|PUBLIC_HOST=$hote|" \
@@ -61,13 +63,21 @@ preparer() {
            -e "s|^COMPOSE_PROJECT_NAME=.*|COMPOSE_PROJECT_NAME=enervision-$env|" \
            -e "s|^PROXY_HTTP_PORT=.*|PROXY_HTTP_PORT=$port_http|" \
            -e "s|^PROXY_HTTPS_PORT=.*|PROXY_HTTPS_PORT=$port_https|" \
-            "$dossier/.env.example" > "$dossier/.env"
+            "$dossier/.env.example" > "$brouillon"
        # Branche antérieure à l'ADR 0009 : ces clés manquent alors dans .env.example.
        for cle in "COMPOSE_PROJECT_NAME=enervision-$env" "PUBLIC_ORIGIN=$origine" \
                   "PROXY_HTTP_PORT=$port_http" "PROXY_HTTPS_PORT=$port_https"; do
-            grep -q "^${cle%%=*}=" "$dossier/.env" || echo "$cle" >> "$dossier/.env"
+            grep -q "^${cle%%=*}=" "$brouillon" || echo "$cle" >> "$brouillon"
        done
-        chmod 600 "$dossier/.env"
+        # Piège : une clé renommée en amont garde sa valeur d'exemple, que le `:?` du compose ne
+        # voit pas puisqu'elle n'est pas vide. Cas vécu : AIRFLOW_WEBSERVER_SECRET_KEY, Airflow 3.
+        oubliees="$(grep '=change_me$' "$brouillon" | grep -v '^APP_MOCK_API_' | cut -d= -f1 | tr '\n' ' ' || true)"
+        if [[ -n "$oubliees" ]]; then
+            rm -f "$brouillon"
+            erreur "$env : secrets non générés, .env non écrit : $oubliees"
+        fi
+        chmod 600 "$brouillon"
+        mv "$brouillon" "$dossier/.env"
        echo "$env : .env généré. Reste à renseigner APP_MOCK_API_USERNAME et APP_MOCK_API_PASSWORD."
    fi
Author	SHA1	Message	Date
Dorian	ea8f9d0a3a	fix(ci): applique aussi le chmod du fichier d'authentification DAST via sudo	2026-09-22 14:57:29 +02:00
Dorian	f58fc4ba81	fix(ci): corrige les permissions du fichier d'authentification qui bloquait le scan DAST 10 minutes	2026-09-22 14:31:29 +02:00
Dorian	2c7ee2c064	Merge remote-tracking branch 'origin/dev' into feat/scan-dast-owasp-zap	2026-09-22 14:11:31 +02:00
Dorian	e220f8f0c6	fix(ci,backend): securise le jeton du scan DAST, seme des donnees et refait ses garde-fous	2026-09-22 14:08:51 +02:00
Johan LEROYandGitHub	fb4235df3a	Merge pull request #144 from ineszang/feat/terraform-provisionnement feat(infra): Terraform provisionne la VM, GitHub Actions continue de déployer	2026-09-22 12:39:12 +02:00
Johan LEROYandClaude Opus 5	357cf996ed	fix(infra): donne au runner un nom distinct de son label Infra / Formatage et validation Terraform (push) Successful in 9s Details --name reprenait runner_labels : un runner et son label portaient le meme eni-g3. Deux machines qui reprendraient cette racine s'enregistreraient sous le meme nom, ce que GitHub refuse. Le nom vaut desormais celui de l'hote, resolu sur la machine, et runner_nom permet de le forcer. Point 2 de la revue de la PR #144. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 12:36:38 +02:00
PhyriosandGitHub	4fb8b5a784	Merge pull request #143 from ineszang/fix/deploiement-airflow-3 fix(infra,ci): aligne le provisionnement et le déploiement sur Airflow 3	2026-09-22 11:44:16 +02:00
Johan LEROYandClaude Opus 5	c1f9dec5fe	chore(git): retire le motif airflow-webserver.pid du .gitignore Airflow 3 n'a plus de webserver : le fichier n'est plus produit. Dernier point de la revue de la PR #143. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 11:42:25 +02:00
Dorian	d9103ee4ed	fix(ci): prune-cache set false	2026-09-22 11:29:54 +02:00
Johan LEROY	fca36649f9	ci(infra): épingle setup-terraform sur un SHA de commit Action tierce sur un workflow qui tourne avec les droits du dépôt : un tag mobile se redéplace. Constat SonarCloud githubactions:S7637, seul écart de la quality gate sur la PR.	2026-09-22 11:29:24 +02:00
Johan LEROY	0db69fd023	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.	2026-09-22 11:27:21 +02:00
Johan LEROY	be6be42947	fix(infra,ci): aligne le provisionnement et le déploiement sur Airflow 3 La migration Airflow 3 est arrivée sur `dev` après l'écriture du chemin de déploiement, qui en a gardé quatre traces fausses, invisibles en CI puisque aucun job ne joue ce chemin. `provision-host.sh` substituait `AIRFLOW_WEBSERVER_SECRET_KEY`, clé disparue. `AIRFLOW_API_SECRET_KEY` et `AIRFLOW_JWT_SECRET` restaient donc à `change_me` dans le `.env` posé sur la machine, et le `:?` d'`airflow-init` ne voit pas une valeur d'exemple : la stack aurait démarré avec un secret de session et un secret JWT prévisibles. Le `.env` est maintenant écrit après contrôle, et le script refuse de le poser s'il reste un `change_me` hors `APP_MOCK_API_*`. `make services-up` démarrait `airflow-webserver`, service supprimé par la migration ; seul `airflow-up` avait été aligné. L'overlay posait `AIRFLOW__WEBSERVER__WORKERS`, sans effet en Airflow 3 où la section est `[api]`. Le réglage disparaît plutôt que d'être renommé : le défaut y vaut un worker, moins que les deux qu'on visait. Le diagnostic d'échec de `deploy.yml` lisait les journaux sans l'overlay, donc sans service `proxy` : il échouait avant d'imprimer quoi que ce soit.	2026-09-22 11:17:02 +02:00
Dorian	3ddeb24207	Merge remote-tracking branch 'origin/dev' into feat/scan-dast-owasp-zap	2026-09-22 11:16:51 +02:00
Dorian	6d741e45fb	fix(ci): corrige la cle matchstr de l'en-tete Authorization dans le scan DAST et retire le diagnostic socat	2026-09-21 16:59:13 +02:00
Dorian	1bec2c1376	fix(ci): diagnostique les 400 du scan DAST avec socat et echoue si toutes les reponses sont des 4xx	2026-09-21 16:49:44 +02:00
Dorian	00fab49d80	fix(ci): charge le contrat OpenAPI depuis un fichier dans le scan DAST et publie les journaux ZAP	2026-09-21 16:42:25 +02:00
Dorian	de88c4f156	fix(ci): corrige les issues Sonar du scan DAST et fait echouer un scan qui n'importe pas le contrat	2026-09-21 16:26:29 +02:00
Dorian	67dcf506e9	ci(backend): ajoute un scan DAST OWASP ZAP de l'API avec un compte lecteur jetable*	2026-09-21 16:11:36 +02:00