fix(deploy): rejoue la synchronisation dynv6 quand l'API ne répond pas

L'API dynv6 laisse par intermittence une écriture sans réponse, parfois appliquée malgré tout. La synchronisation est rejouée jusqu'à trois fois et relit l'état avant chaque écriture : une création aboutie malgré le délai n'est jamais dupliquée. Délai par appel porté à 60 s. Validé contre le vrai dynv6 depuis la VM : zone, rec et dev visent 10.101.200.37, et un certificat de test Let's Encrypt a été émis par DNS-01 pour dev.enervision-g3.dynv6.net.
fix(deploy): passe à dynv6 et rend le défi DNS-01 indépendant du fournisseur
2026-09-23 11:56:33 +02:00 · 2026-09-23 11:47:07 +02:00 · 2026-09-23 11:38:44 +02:00 · 2026-09-23 11:21:12 +02:00 · 2026-09-23 10:57:32 +02:00 · 2026-09-23 10:51:42 +02:00
124 changed files with 6584 additions and 705 deletions
@@ -69,8 +69,27 @@ PUBLIC_ORIGIN=
 # l'extérieur. Décaler aussi POSTGRES_PORT, MAILPIT_UI_PORT et AIRFLOW_PORT (5434, 8026, 8082).
 PROXY_HTTP_PORT=
 PROXY_HTTPS_PORT=
+# Écouteur PROXY protocol du proxy, que seul le frontal de la VM joint (infra/front, ADR 0018).
+# Vide : port aléatoire sur 127.0.0.1. VM : 127.0.0.1:10444 en prod, 8444 en recette, 9444 en dev.
+PROXY_FRONT_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. 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
+
+# Supervision (ADR 0016) : `monitoring` la démarre avec `make stack-up`, réglage de la prod.
+# Vide ailleurs, où `make monitoring-up` la lance à la demande.
+COMPOSE_PROFILES=
+# Jeton présenté par Prometheus sur `/metrics`, exigé par l'API dès qu'il est posé. Requis dès
+# que la supervision tourne ; même générateur que APP_SECRET_KEY.
+APP_METRICS_TOKEN=change_me
+# Compte `admin` de Grafana. Sans lui, le conteneur refuse de démarrer.
+GRAFANA_ADMIN_PASSWORD=change_me
+# Rôle PostgreSQL `supervision`, en lecture seule, de Grafana et de postgres-exporter
+# (db/roles/supervision.sql, posé par `make db-ensure-supervision`).
+SUPERVISION_DB_PASSWORD=change_me
+# Interfaces publiées sur 127.0.0.1 seulement, par tunnel SSH. 3000 est pris par le frontend.
+GRAFANA_PORT=3001
+PROMETHEUS_PORT=9090
+ALERTMANAGER_PORT=9093
@@ -0,0 +1,3 @@
+self-hosted-runner:
+  labels:
+    - eni-g3
@@ -20,6 +20,17 @@ updates:
      - dependency-name: "@vitest/coverage-v8"
        update-types: ["version-update:semver-major"]

+  # Tests de bout en bout, paquet npm distinct du frontend
+  - package-ecosystem: "npm"
+    directory: "/tests/e2e"
+    schedule:
+      interval: "weekly"
+    open-pull-requests-limit: 2
+    groups:
+      e2e-dependencies:
+        patterns:
+          - "*"
+
  # Backend — uv (lit pyproject.toml / uv.lock)
  - package-ecosystem: "uv"
    directory: "/apps/backend"
@@ -6,42 +6,20 @@ name: Airflow
 # Docker, dans son propre environnement (cf. etl/airflow/Dockerfile).
 #
 # Piège : l'image COPY les fichiers de dépendances et le code de ml/ et de apps/backend/. Une
-# modification de l'un ou de l'autre peut donc casser sa construction, d'où ces chemins dans
-# les déclencheurs, alors même que ce workflow ne teste ni le modèle ni l'API.
+# modification de l'un ou de l'autre peut donc casser sa construction : le filtre `airflow` de
+# ci.yml, qui appelle ce workflow, inclut ces chemins alors qu'il ne teste ni le modèle ni l'API.

 on:
-  push:
-    paths:
-      - "etl/airflow/**"
-      - "ml/pyproject.toml"
-      - "ml/uv.lock"
-      - "ml/enervision_ml/**"
-      - "apps/backend/pyproject.toml"
-      - "apps/backend/uv.lock"
-      - "apps/backend/app/**"
-      - ".github/workflows/airflow.yml"
-  pull_request:
-    paths:
-      - "etl/airflow/**"
-      - "ml/pyproject.toml"
-      - "ml/uv.lock"
-      - "ml/enervision_ml/**"
-      - "apps/backend/pyproject.toml"
-      - "apps/backend/uv.lock"
-      - "apps/backend/app/**"
-      - ".github/workflows/airflow.yml"
+  workflow_call:

 permissions:
  contents: read

-concurrency:
-  group: airflow-${{ github.ref }}
-  cancel-in-progress: true
-
 jobs:
  verification:
    name: Lint et intégrité des DAGs
    runs-on: ubuntu-latest
+    timeout-minutes: 15
    defaults:
      run:
        working-directory: etl/airflow
@@ -50,17 +28,19 @@ jobs:
      - name: Récupère le dépôt
        uses: actions/checkout@v7

+      # Action tierce, épinglée sur le commit du tag (règle Sonar githubactions:S7637).
      - name: Installe uv
-        uses: astral-sh/setup-uv@v7
+        uses: astral-sh/setup-uv@37802adc94f370d6bfd71619e3f0bf239e1f3b78 # v7
        with:
          enable-cache: true
          cache-dependency-glob: etl/airflow/uv.lock
+          prune-cache: false

      - name: Installe l'interpréteur déclaré par .python-version
        run: uv python install

-      - name: Synchronise les dépendances sans dévier du verrou
-        run: uv sync --all-groups --frozen
+      - name: Synchronise les dépendances sur le verrou
+        run: uv sync --all-groups --locked

      - name: Vérifie le formatage
        run: uv run ruff format --check .
@@ -76,6 +56,7 @@ jobs:
  image:
    name: Construction de l'image
    runs-on: ubuntu-latest
+    timeout-minutes: 25

    steps:
      - name: Récupère le dépôt
@@ -93,11 +74,11 @@ jobs:

      # `--help` sort par argparse avant `get_settings()` : ni base ni secret requis, et
      # l'import des modules prouve que l'environnement /opt/backend est complet.
-      # Les deux commandes du DAG `alertes` et la commande du DAG historique sont couvertes.
-      - name: Vérifie que les trois commandes backend s'importent sans réseau
+      - name: Vérifie que les quatre commandes backend s'importent sans réseau
        run: >
          docker run --rm --network none enervision-airflow:ci
          bash -c "cd /opt/backend
          && env -u VIRTUAL_ENV uv run --no-sync python -m app.detection.internal_alerts --help
          && env -u VIRTUAL_ENV uv run --no-sync python -m app.cli generate-recommendations --help
-          && env -u VIRTUAL_ENV uv run --no-sync python -m app.etl.historical_import --help"
+          && env -u VIRTUAL_ENV uv run --no-sync python -m app.etl.historical_import --help
+          && env -u VIRTUAL_ENV uv run --no-sync python -m app.etl.mock_api_import --help"
@@ -2,28 +2,20 @@ name: Backend

 # Piège : la version de Python vient de apps/backend/.python-version, et elle doit rester
 # en 3.14. Le code utilise le PEP 758, qu'un interpréteur 3.13 refuse de compiler.
+# Pourquoi : aucun déclencheur propre. ci.yml appelle ce workflow quand le backend change, et
+# Sonar y reprend la couverture versée par le job `verification` (ADR 0014).

 on:
-  push:
-    paths:
-      - "apps/backend/**"
-      - ".github/workflows/backend.yml"
-  pull_request:
-    paths:
-      - "apps/backend/**"
-      - ".github/workflows/backend.yml"
+  workflow_call:

 permissions:
  contents: read

-concurrency:
-  group: backend-${{ github.ref }}
-  cancel-in-progress: true
-
 jobs:
  verification:
    name: Lint, typage et tests
    runs-on: ubuntu-latest
+    timeout-minutes: 15
    defaults:
      run:
        working-directory: apps/backend
@@ -32,17 +24,20 @@ jobs:
      - name: Récupère le dépôt
        uses: actions/checkout@v7

+      # Action tierce, épinglée sur le commit du tag (règle Sonar githubactions:S7637).
      - name: Installe uv
-        uses: astral-sh/setup-uv@v7
+        uses: astral-sh/setup-uv@37802adc94f370d6bfd71619e3f0bf239e1f3b78 # v7
        with:
          enable-cache: true
          cache-dependency-glob: apps/backend/uv.lock
+          prune-cache: false

      - name: Installe l'interpréteur déclaré par .python-version
        run: uv python install

-      - name: Synchronise les dépendances sans dévier du verrou
-        run: uv sync --all-groups --frozen
+      # `--locked` et non `--frozen` : un verrou qui ne suit plus pyproject.toml doit casser ici.
+      - name: Synchronise les dépendances sur le verrou
+        run: uv sync --all-groups --locked

      - name: Vérifie le formatage
        run: uv run ruff format --check .
@@ -55,14 +50,21 @@ jobs:

      # Le marqueur `integration` est exclu par défaut, donc aucune base n'est nécessaire ici.
      - name: Tests et couverture
-        run: uv run pytest --cov-fail-under=85
+        run: uv run pytest --cov-fail-under=85 --cov-report=xml

-  # Piège : l'image est celle de docker-compose.yml, pas une image `postgres` nue. La première
-  # migration (`5353c0e4f094`) échoue volontairement si l'extension TimescaleDB manque, et un
-  # écart d'image entre la CI et le poste rendrait ce job vert sur une base qui n'est pas la nôtre.
+      - name: Verse la couverture pour Sonar
+        uses: actions/upload-artifact@v7
+        with:
+          name: backend-coverage
+          path: apps/backend/coverage.xml
+          if-no-files-found: error
+
+  # Piège : même image que docker-compose.yml, pas un `postgres` nu. La première migration refuse
+  # de s'appliquer sans TimescaleDB, et une autre image testerait une base qui n'est pas la nôtre.
  integration:
    name: Tests exigeant une base
    runs-on: ubuntu-latest
+    timeout-minutes: 15
    defaults:
      run:
        working-directory: apps/backend
@@ -93,16 +95,17 @@ jobs:
        uses: actions/checkout@v7

      - name: Installe uv
-        uses: astral-sh/setup-uv@v7
+        uses: astral-sh/setup-uv@37802adc94f370d6bfd71619e3f0bf239e1f3b78 # v7
        with:
          enable-cache: true
          cache-dependency-glob: apps/backend/uv.lock
+          prune-cache: false

      - name: Installe l'interpréteur déclaré par .python-version
        run: uv python install

-      - name: Synchronise les dépendances sans dévier du verrou
-        run: uv sync --all-groups --frozen
+      - name: Synchronise les dépendances sur le verrou
+        run: uv sync --all-groups --locked

      # Sur le poste, c'est db/init/110-test-database.sql qui pose l'extension. Ce fichier n'est
      # pas monté ici, et sans lui `alembic upgrade head` s'arrête sur la garde de la révision 1.
@@ -112,14 +115,15 @@ jobs:
      - name: Applique les migrations
        run: uv run alembic upgrade head

-      # `-m` en ligne de commande écrase celui d'`addopts`. La couverture est désactivée : ce job
-      # ne joue qu'une partie de la suite, son taux n'aurait aucun sens face au seuil de 85 %.
+      # Couverture désactivée : ce job ne joue qu'une partie de la suite, son taux n'aurait
+      # aucun sens face au seuil de 85 %.
      - name: Tests d'intégration
        run: uv run pytest -m integration --no-cov

  security-audit:
    name: Audit des dépendances
    runs-on: ubuntu-latest
+    timeout-minutes: 10
    defaults:
      run:
        working-directory: apps/backend
@@ -129,21 +133,23 @@ jobs:
        uses: actions/checkout@v7

      - name: Installe uv
-        uses: astral-sh/setup-uv@v7
+        uses: astral-sh/setup-uv@37802adc94f370d6bfd71619e3f0bf239e1f3b78 # v7
        with:
          enable-cache: true
          cache-dependency-glob: apps/backend/uv.lock
+          prune-cache: false

      # L'audit porte sur le verrou, pas sur l'environnement : sinon pip-audit auditerait
      # aussi les paquets que son propre `--with` injecte, hors dépendances du projet.
      - name: Audite les dépendances livrées
        # Piège : sans `shell: bash`, un échec de `uv export` serait masqué par le pipe.
        shell: bash
-        run: uv export --frozen --no-dev --no-emit-project --no-hashes | uvx pip-audit --requirement /dev/stdin --no-deps
+        run: uv export --locked --no-dev --no-emit-project --no-hashes | uvx pip-audit --requirement /dev/stdin --no-deps

  sast:
    name: Analyse statique de sécurité
    runs-on: ubuntu-latest
+    timeout-minutes: 10
    defaults:
      run:
        working-directory: apps/backend
@@ -155,7 +161,9 @@ jobs:
      # Pourquoi : pas de cache ici. uvx n'installe pas le projet, le verrou n'alimente donc
      # aucune clé de cache ; la seule roue téléchargée est celle de Bandit.
      - name: Installe uv
-        uses: astral-sh/setup-uv@v7
+        uses: astral-sh/setup-uv@37802adc94f370d6bfd71619e3f0bf239e1f3b78 # v7
+        with:
+          enable-cache: false

      # Pourquoi : le périmètre est `app`, le code livré. Les tests emploient légitimement des
      # secrets factices et des `assert` que Bandit signalerait sans qu'aucun n'atteigne la prod.
@@ -0,0 +1,225 @@
+# Pourquoi : un seul point d'entrée pour toute la CI (ADR 0014) - workflow CI. Chaque composant
+# ne tourne que si ses fichiers changent, Sonar reprend les couvertures déjà produites au lieu de
+# tout rejouer, et le déploiement ne part que d'un commit dont la CI est verte.
+# Piège : le seul check à exiger dans les règles de branche est « CI ok ». Un job sauté par son
+# filtre ne publie pas les checks de son workflow, qui resteraient en attente s'ils étaient exigés.
+# Piège : sur un push vers dev ou main, tous les filtres valent vrai. paths-filter comparerait
+# sinon à la base de fusion avec main, et Sonar n'analyserait qu'une partie de la branche.
+# Piège : pas d'annulation des runs de push. Un run coupé en plein `make stack-up` laisserait la
+# stack à moitié redémarrée ; le groupe par SHA évite aussi de mettre `dev` en file derrière lui.
+
+name: CI
+
+on:
+  pull_request:
+  push:
+    branches: [dev, main]
+  workflow_dispatch:
+
+permissions:
+  contents: read
+
+concurrency:
+  group: ci-${{ github.event_name == 'pull_request' && github.ref || github.sha }}
+  cancel-in-progress: ${{ github.event_name == 'pull_request' }}
+
+jobs:
+  changes:
+    name: Périmètre modifié
+    runs-on: ubuntu-latest
+    timeout-minutes: 5
+    permissions:
+      contents: read
+      pull-requests: read
+    outputs:
+      backend: ${{ github.event_name != 'pull_request' || steps.filtre.outputs.ci == 'true' || steps.filtre.outputs.backend == 'true' }}
+      frontend: ${{ github.event_name != 'pull_request' || steps.filtre.outputs.ci == 'true' || steps.filtre.outputs.frontend == 'true' }}
+      ml: ${{ github.event_name != 'pull_request' || steps.filtre.outputs.ci == 'true' || steps.filtre.outputs.ml == 'true' }}
+      airflow: ${{ github.event_name != 'pull_request' || steps.filtre.outputs.ci == 'true' || steps.filtre.outputs.airflow == 'true' }}
+      terraform: ${{ github.event_name != 'pull_request' || steps.filtre.outputs.ci == 'true' || steps.filtre.outputs.terraform == 'true' }}
+      compose: ${{ github.event_name != 'pull_request' || steps.filtre.outputs.ci == 'true' || steps.filtre.outputs.compose == 'true' }}
+      workflows: ${{ github.event_name != 'pull_request' || steps.filtre.outputs.workflows == 'true' }}
+      e2e: ${{ github.event_name != 'pull_request' || steps.filtre.outputs.ci == 'true' || steps.filtre.outputs.e2e == 'true' }}
+      sonar: ${{ github.event_name != 'pull_request' || steps.filtre.outputs.ci == 'true' || steps.filtre.outputs.sonar == 'true' }}
+
+    steps:
+      # Sur une PR, la liste des fichiers vient de l'API : ni checkout ni historique requis.
+      - name: Calcule le périmètre de la PR
+        id: filtre
+        if: github.event_name == 'pull_request'
+        uses: dorny/paths-filter@ceb8a2b8f2d89434be7ff52d3de7ec3738c5cc9d # v4.0.3
+        with:
+          filters: |
+            ci:
+              - ".github/workflows/ci.yml"
+            backend:
+              - "apps/backend/**"
+              - ".github/workflows/backend.yml"
+            frontend:
+              - "apps/frontend/**"
+              - ".github/workflows/frontend.yml"
+            ml:
+              - "ml/**"
+              - "apps/backend/alembic/**"
+              - "apps/backend/app/models/**"
+              - "apps/backend/tests/test_chaine_ml_api.py"
+              - "apps/backend/pyproject.toml"
+              - "apps/backend/uv.lock"
+              - ".github/workflows/ml.yml"
+            airflow:
+              - "etl/airflow/**"
+              - "ml/pyproject.toml"
+              - "ml/uv.lock"
+              - "ml/enervision_ml/**"
+              - "apps/backend/pyproject.toml"
+              - "apps/backend/uv.lock"
+              - "apps/backend/app/**"
+              - ".github/workflows/airflow.yml"
+            terraform:
+              - "infra/terraform/**"
+              - ".github/workflows/infra.yml"
+            compose:
+              - "docker-compose*.yml"
+              - ".env.example"
+              - "infra/front/**"
+              - "monitoring/**"
+              - ".github/workflows/infra.yml"
+            workflows:
+              - ".github/**"
+            e2e:
+              - "apps/frontend/**"
+              - "apps/backend/app/**"
+              - "apps/backend/alembic/**"
+              - "apps/backend/Dockerfile"
+              - "apps/backend/pyproject.toml"
+              - "apps/backend/uv.lock"
+              - "infra/proxy/**"
+              - "docker-compose*.yml"
+              - "db/**"
+              - "tests/**"
+              - "scripts/comptes-test.sh"
+              - "scripts/tls-selfsigned.sh"
+              - "Makefile"
+              - ".env.example"
+              - ".github/workflows/e2e.yml"
+            sonar:
+              - "apps/backend/**"
+              - "apps/frontend/**"
+              - "ml/**"
+              - "etl/airflow/**"
+              - "sonar-project.properties"
+
+  backend:
+    name: Backend
+    needs: changes
+    if: needs.changes.outputs.backend == 'true'
+    uses: ./.github/workflows/backend.yml
+
+  frontend:
+    name: Frontend
+    needs: changes
+    if: needs.changes.outputs.frontend == 'true'
+    uses: ./.github/workflows/frontend.yml
+
+  ml:
+    name: ML
+    needs: changes
+    if: needs.changes.outputs.ml == 'true'
+    uses: ./.github/workflows/ml.yml
+
+  airflow:
+    name: Airflow
+    needs: changes
+    if: needs.changes.outputs.airflow == 'true'
+    uses: ./.github/workflows/airflow.yml
+
+  infra:
+    name: Infra
+    needs: changes
+    if: >-
+      needs.changes.outputs.terraform == 'true'
+      || needs.changes.outputs.compose == 'true'
+      || needs.changes.outputs.workflows == 'true'
+    uses: ./.github/workflows/infra.yml
+    with:
+      terraform: ${{ needs.changes.outputs.terraform == 'true' }}
+      compose: ${{ needs.changes.outputs.compose == 'true' }}
+      workflows: ${{ needs.changes.outputs.workflows == 'true' }}
+
+  e2e:
+    name: E2E
+    needs: changes
+    if: needs.changes.outputs.e2e == 'true'
+    uses: ./.github/workflows/e2e.yml
+
+  # Ni dependabot[bot] ni une PR de fork ne reçoivent SONAR_TOKEN : le scan échouerait sans rien
+  # analyser. Tests et couverture restent joués par leurs jobs.
+  sonar:
+    name: SonarQube
+    needs: [changes, backend, frontend, ml]
+    if: >-
+      always() && !cancelled()
+      && !contains(needs.*.result, 'failure')
+      && needs.changes.outputs.sonar == 'true'
+      && github.actor != 'dependabot[bot]'
+      && (github.event_name != 'pull_request' || github.event.pull_request.head.repo.full_name == github.repository)
+    runs-on: ubuntu-latest
+    timeout-minutes: 15
+
+    steps:
+      - name: Récupère le dépôt
+        uses: actions/checkout@v7
+        with:
+          fetch-depth: 0
+
+      # Un téléchargement par rapport : backend et ML nomment tous deux le leur `coverage.xml`.
+      - name: Couverture du backend
+        if: needs.backend.result == 'success'
+        uses: actions/download-artifact@v8
+        with:
+          name: backend-coverage
+          path: apps/backend
+
+      - name: Couverture du pipeline ML
+        if: needs.ml.result == 'success'
+        uses: actions/download-artifact@v8
+        with:
+          name: ml-coverage
+          path: ml
+
+      - name: Couverture du frontend
+        if: needs.frontend.result == 'success'
+        uses: actions/download-artifact@v8
+        with:
+          name: frontend-coverage
+          path: apps/frontend/coverage/frontend
+
+      # Action tierce, épinglée sur le commit du tag (règle Sonar githubactions:S7637).
+      - name: Analyse SonarQube
+        uses: SonarSource/sonarqube-scan-action@ba9859eae8dd6bd29e412f25ddbbef3d032000f4 # v8.2.2
+        env:
+          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
+
+  ci-ok:
+    name: CI ok
+    needs: [changes, backend, frontend, ml, airflow, infra, e2e, sonar]
+    if: always()
+    runs-on: ubuntu-latest
+    timeout-minutes: 5
+
+    steps:
+      - name: Refuse si un job a échoué ou a été annulé
+        env:
+          RESULTATS: ${{ toJSON(needs.*.result) }}
+        run: |
+          echo "$RESULTATS"
+          if grep -qE '"(failure|cancelled)"' <<<"$RESULTATS"; then
+            echo "::error::Au moins un job de la CI a échoué ou a été annulé."
+            exit 1
+          fi
+
+  deploy:
+    name: Déploiement
+    needs: ci-ok
+    if: ${{ !cancelled() && needs.ci-ok.result == 'success' && github.event_name == 'push' }}
+    uses: ./.github/workflows/deploy.yml
@@ -0,0 +1,316 @@
+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 le jeu de démonstration (sans ça le scan ne frappe que
+# des gestionnaires d'erreur), crée des comptes jetables (scripts/dast-token.sh), puis lance ZAP
+# sur le contrat OpenAPI avec le jeton du `lecteur`.
+#
+# 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"
+      - "scripts/comptes-test.sh"
+      - "db/seeds/**"
+
+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 --locked --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.
+      - name: Sème le jeu de démonstration
+        run: psql -h localhost -p 5433 -U enervision -d enervision_dast -v ON_ERROR_STOP=1 -f db/seeds/demo.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
+              echo ""
+              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
@@ -1,57 +1,74 @@
 # Pourquoi : le runner tourne sur la VM ENI, adresse privée que les runners hébergés par GitHub
 # ne joignent pas, et travaille dans un dossier stable par environnement plutôt que dans son
 # espace de travail : `.env`, certificats et volumes y survivent d'un déploiement à l'autre.
+# Pourquoi : appelé par ci.yml une fois « CI ok » vert, jamais directement par un push, et il
+# déploie `GITHUB_SHA`, le commit testé, pas la pointe de branche du moment (ADR 0014).
+# Pourquoi : `main` va en prod, `dev` en recette, et toute autre branche lancée à la main
+# (workflow_dispatch) va dans `dev`, la vitrine d'une branche de travail (ADR 0017).
 # Piège : jamais de déclencheur `pull_request` ici. Sur un dépôt public, une PR de fork
 # exécuterait son code sur la machine de production (ADR 0009) - job deploy.
+# Piège : les CI de deux push finissent parfois dans le désordre. Un commit qui précède celui déjà
+# déployé depuis la même branche est ignoré, et le verrou est un `flock` sur le dossier de
+# l'environnement plutôt qu'un groupe `concurrency` : GitHub n'y garde qu'un job en attente, et
+# le suivant l'évince sans bruit.

 name: Déploiement

 on:
-  push:
-    branches: [dev, main]
+  workflow_call:
  workflow_dispatch:

 permissions:
  contents: read

-concurrency:
-  group: deploy-${{ github.ref_name }}
-  cancel-in-progress: false
-
 jobs:
  deploy:
+    name: Déploie sur la VM
    runs-on: [self-hosted, linux, eni-g3]
    timeout-minutes: 30
    environment:
-      name: ${{ github.ref_name == 'main' && 'prod' || 'rec' }}
-      url: ${{ github.ref_name == 'main' && 'https://enervision.local' || 'https://rec.enervision.local:8443' }}
+      name: ${{ github.ref_name == 'main' && 'prod' || github.ref_name == 'dev' && 'rec' || 'dev' }}
+      url: ${{ github.ref_name == 'main' && 'https://enervision-g3.dynv6.net' || github.ref_name == 'dev' && 'https://rec.enervision-g3.dynv6.net' || 'https://dev.enervision-g3.dynv6.net' }}
    env:
-      ENVIRONNEMENT: ${{ github.ref_name == 'main' && 'prod' || 'rec' }}
-      PORT_HTTPS: ${{ github.ref_name == 'main' && '443' || '8443' }}
+      ENVIRONNEMENT: ${{ github.ref_name == 'main' && 'prod' || github.ref_name == 'dev' && 'rec' || 'dev' }}
+      PORT_HTTPS: ${{ github.ref_name == 'main' && '10443' || github.ref_name == 'dev' && '8443' || '9443' }}
    steps:
-      - name: Aligner le dossier de l'environnement sur la branche poussée
+      # Un seul step : le verrou tombe avec le shell qui l'a posé.
+      - name: Déploie le commit testé, sans jamais reculer
        run: |
          cd "/srv/enervision/${ENVIRONNEMENT}"
+          exec 9>"$(git rev-parse --git-dir)/verrou-deploiement"
+          flock 9
+
+          echo "::group::Aligne le dossier de l'environnement sur le commit testé"
          git fetch --quiet origin "${GITHUB_REF_NAME}"
+          deploye="$(git rev-parse HEAD)"
+          if [ "$(git branch --show-current)" = "$GITHUB_REF_NAME" ] && [ "$deploye" != "$GITHUB_SHA" ] \
+            && git merge-base --is-ancestor "$GITHUB_SHA" "$deploye"; then
+            echo "::notice::${GITHUB_SHA:0:7} précède le commit déjà déployé (${deploye:0:7}) : rien à déployer."
+            exit 0
+          fi
          git checkout --quiet "${GITHUB_REF_NAME}"
-          git reset --quiet --hard "origin/${GITHUB_REF_NAME}"
+          git reset --quiet --hard "${GITHUB_SHA}"
          git log -1 --format='%h %s'
+          echo "::endgroup::"

-      - name: Reconstruire et redémarrer la stack
-        run: |
-          cd "/srv/enervision/${ENVIRONNEMENT}"
+          echo "::group::Reconstruit et redémarre la stack"
+          # Un `.env` pas encore réaligné par provision-host.sh porte encore un nom en `.local`.
+          if [ -r ../dns.token ] && ! grep -q '^PUBLIC_HOST=.*\.local$' .env; then make tls-dns01; fi
          make stack-up
+          if [ "${ENVIRONNEMENT}" = prod ]; then make front-up; fi
+          echo "::endgroup::"

-      - name: Attendre que l'API réponde derrière le proxy
-        run: |
-          for tentative in $(seq 1 36); do
+          echo "::group::Attend que l'API réponde derrière le proxy"
+          for _ in $(seq 1 36); do
            if curl --fail --silent --insecure "https://localhost:${PORT_HTTPS}/api/v1/health/ready"; then
              exit 0
            fi
            sleep 5
          done
+          echo "::endgroup::"
          echo "L'API ne répond pas après 3 minutes" >&2
-          cd "/srv/enervision/${ENVIRONNEMENT}"
          compose="docker compose -f docker-compose.yml -f docker-compose.prod.yml"
          $compose ps
          $compose logs --tail=50 backend proxy
@@ -0,0 +1,135 @@
+name: E2E
+
+# Pourquoi : les parcours tournent contre la stack telle qu'elle est déployée, derrière le proxy
+# TLS (cookie `__Secure-`, CSP, limitation de débit), pas contre `ng serve` - job parcours. Il
+# construit aussi les images backend et frontend, que rien d'autre ne construit avant le
+# déploiement (ADR 0015).
+# Piège : pas d'Airflow ici. `up` nomme ses services : sans eux, la construction de l'image
+# Airflow doublerait la durée du job sans rien tester de plus.
+
+on:
+  workflow_call:
+
+permissions:
+  contents: read
+
+jobs:
+  parcours:
+    name: Parcours Playwright et tirs k6
+    runs-on: ubuntu-latest
+    timeout-minutes: 30
+    env:
+      COMPOSE_FILE: docker-compose.yml:docker-compose.prod.yml
+      PUBLIC_HOST: localhost
+      E2E_BASE_URL: https://localhost
+
+    steps:
+      - name: Récupère le dépôt
+        uses: actions/checkout@v7
+
+      - name: Prépare le .env de la stack
+        run: |
+          secret() { openssl rand -hex 32; }
+          sed -e "s|^POSTGRES_PASSWORD=.*|POSTGRES_PASSWORD=$(secret)|" \
+              -e "s|^APP_SECRET_KEY=.*|APP_SECRET_KEY=$(secret)|" \
+              -e "s|^PUBLIC_HOST=.*|PUBLIC_HOST=localhost|" \
+              .env.example > .env
+
+      - name: Génère le certificat de démonstration
+        run: ./scripts/tls-selfsigned.sh
+
+      - name: Construit et démarre la stack derrière le proxy
+        run: docker compose up --detach --build --wait --wait-timeout 300 db mailpit backend frontend proxy
+
+      - name: Applique les migrations
+        run: docker compose exec -T backend alembic upgrade head
+
+      # Même cible que `make stack-up` en prod : les droits du rôle portent sur le schéma réel.
+      - name: Pose le rôle de supervision en lecture seule
+        run: make db-ensure-supervision
+
+      - name: Sème le jeu de démonstration
+        run: docker compose exec -T db psql -U enervision -d enervision -v ON_ERROR_STOP=1 < db/seeds/demo.sql
+
+      - name: Crée les comptes de test
+        env:
+          BASE_URL: https://localhost
+          APP_CLI: docker compose exec -T backend python -m app.cli
+          COMPTES_FICHIER: ${{ runner.temp }}/comptes.json
+        run: ./scripts/comptes-test.sh
+
+      - name: Installe Node
+        uses: actions/setup-node@v7
+        with:
+          node-version: 26
+          cache: npm
+          cache-dependency-path: tests/e2e/package-lock.json
+
+      - name: Installe Playwright
+        working-directory: tests/e2e
+        run: npm ci
+
+      - name: Restaure les navigateurs de Playwright
+        uses: actions/cache@v6
+        with:
+          path: ~/.cache/ms-playwright
+          key: playwright-${{ runner.os }}-${{ hashFiles('tests/e2e/package-lock.json') }}
+
+      # `--with-deps` tourne même quand le cache a servi : il pose aussi les bibliothèques système.
+      - name: Installe Chromium
+        working-directory: tests/e2e
+        run: npx playwright install --with-deps chromium
+
+      - name: Joue les parcours
+        working-directory: tests/e2e
+        env:
+          E2E_COMPTES: ${{ runner.temp }}/comptes.json
+        run: npx playwright test
+
+      # Direct sur `backend:8000` : ce tir mesure l'API, pas la limitation de nginx.
+      - name: Tir k6 de fumée sur l'API
+        env:
+          K6_RESUME: /results/resume-smoke.md
+        run: |
+          K6_EMAIL="$(jq -r .lecteur.email "$RUNNER_TEMP/comptes.json")"
+          K6_PASSWORD="$(jq -r .lecteur.password "$RUNNER_TEMP/comptes.json")"
+          echo "::add-mask::$K6_PASSWORD"
+          export K6_EMAIL K6_PASSWORD
+          make load-smoke
+
+      - name: Vérifie par k6 que le proxy limite le débit
+        env:
+          K6_RESUME: /results/resume-limitation.md
+        run: make load-limits
+
+      - name: Publie la synthèse k6
+        if: ${{ !cancelled() }}
+        run: cat tests/load/results/resume-*.md >> "$GITHUB_STEP_SUMMARY" 2>/dev/null || true
+
+      - name: Publie les rapports k6
+        if: ${{ !cancelled() }}
+        uses: actions/upload-artifact@v7
+        with:
+          name: k6-rapports
+          path: tests/load/results/
+          if-no-files-found: ignore
+          retention-days: 14
+
+      - name: Publie le rapport Playwright
+        if: ${{ !cancelled() }}
+        uses: actions/upload-artifact@v7
+        with:
+          name: playwright-report
+          path: |
+            tests/e2e/playwright-report/
+            tests/e2e/test-results/
+          if-no-files-found: ignore
+          retention-days: 14
+
+      - name: Journaux de la stack en cas d'échec
+        if: failure()
+        run: docker compose logs --tail=200 backend proxy frontend
+
+      - name: Arrête la stack
+        if: always()
+        run: docker compose down --volumes
@@ -1,64 +1,70 @@
 name: Frontend

+# Pourquoi : aucun déclencheur propre. ci.yml appelle ce workflow quand le frontend change, et
+# Sonar y reprend la couverture versée par le job `verification` (ADR 0014).
+
 on:
-  push:
-    paths:
-      - "apps/frontend/**"
-      - ".github/workflows/frontend.yml"
-  pull_request:
-    paths:
-      - "apps/frontend/**"
-      - ".github/workflows/frontend.yml"
+  workflow_call:

 permissions:
  contents: read

 jobs:
-  build:
+  # Un seul `npm ci` pour la construction et les tests : un job de plus ne ferait que le rejouer.
+  verification:
+    name: Construction et tests
    runs-on: ubuntu-latest
+    timeout-minutes: 15
+    defaults:
+      run:
+        working-directory: apps/frontend
+
    steps:
-      - uses: actions/checkout@v7
-      - uses: actions/setup-node@v7
+      - name: Récupère le dépôt
+        uses: actions/checkout@v7
+
+      - name: Installe Node
+        uses: actions/setup-node@v7
        with:
          node-version: 26
          cache: npm
          cache-dependency-path: apps/frontend/package-lock.json

-      - run: npm ci
-        working-directory: apps/frontend
-      - run: npm run build
-        working-directory: apps/frontend
+      - name: Installe les dépendances
+        run: npm ci

-  security-audit:
-    name: Audit des dépendances
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v7
-      - uses: actions/setup-node@v7
-        with:
-          node-version: 26
-      # Seuil high : une vulnérabilité moderate de devDependency ne doit pas bloquer une livraison.
-      - run: npm audit --audit-level=high --package-lock-only
-        working-directory: apps/frontend
+      - name: Construit l'application
+        run: npm run build

-  test:
-    needs: build
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v7
-      - uses: actions/setup-node@v7
-        with:
-          node-version: 26
-          cache: npm
-          cache-dependency-path: apps/frontend/package-lock.json
-      - name : Installation des dépendances (Front)
-        run: npm ci 
-        working-directory: apps/frontend
-      - name : Lancement des tests et génénration du rapport de couverture (Front)
-        run: npm test --watch=false --code-coverage --coverageReporters=lcov
-        working-directory: apps/frontend
-      - name: Upload coverage
+      # Piège : `npm test --watch=false` garde l'option pour npm, `ng test` ne la reçoit jamais.
+      # La couverture lcov vient d'angular.json (`coverage: true`).
+      - name: Tests et couverture
+        run: npm run test:ci
+
+      - name: Verse la couverture pour Sonar
        uses: actions/upload-artifact@v7
        with:
          name: frontend-coverage
          path: apps/frontend/coverage/frontend/lcov.info
+          if-no-files-found: error
+
+  security-audit:
+    name: Audit des dépendances
+    runs-on: ubuntu-latest
+    timeout-minutes: 10
+    defaults:
+      run:
+        working-directory: apps/frontend
+
+    steps:
+      - name: Récupère le dépôt
+        uses: actions/checkout@v7
+
+      - name: Installe Node
+        uses: actions/setup-node@v7
+        with:
+          node-version: 26
+
+      # Seuil high : une vulnérabilité moderate de devDependency ne doit pas bloquer une livraison.
+      - name: Audite le verrou
+        run: npm audit --audit-level=high --package-lock-only
@@ -1,38 +1,40 @@
 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.
+# Pourquoi : rien de ce qui décrit l'infrastructure ne s'exécute avant le déploiement. Terraform est
+# resté cassé sans que rien ne le dise, faute de job qui le joue : ce workflow n'applique rien, il
+# vérifie le Terraform, les fichiers Compose et les workflows eux-mêmes - jobs terraform, compose,
+# workflows. ci.yml choisit par ses entrées ceux qui tournent (ADR 0014).
+# Piège : la boucle Terraform 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"
+  workflow_call:
+    inputs:
+      terraform:
+        type: boolean
+        default: false
+      compose:
+        type: boolean
+        default: false
+      workflows:
+        type: boolean
+        default: false

 permissions:
  contents: read

-concurrency:
-  group: infra-${{ github.ref }}
-  cancel-in-progress: true
-
 jobs:
  terraform:
    name: Formatage et validation Terraform
+    if: inputs.terraform
    runs-on: ubuntu-latest
+    timeout-minutes: 10

    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).
+      # Action tierce, épinglée sur le commit du tag (règle Sonar githubactions:S7637).
      - name: Installe Terraform
        uses: hashicorp/setup-terraform@dfe3c3f87815947d99a8997f908cb6525fc44e9e # v4.0.1
        with:
@@ -50,3 +52,56 @@ jobs:
            terraform -chdir="${racine}" validate
            echo "::endgroup::"
          done
+
+  compose:
+    name: Validation des fichiers Compose et de la supervision
+    if: inputs.compose
+    runs-on: ubuntu-latest
+    timeout-minutes: 10
+
+    steps:
+      - name: Récupère le dépôt
+        uses: actions/checkout@v7
+
+      # Compose interpole tout le fichier : les `:?` exigent une valeur, pas un vrai secret.
+      - name: Prépare un .env d'exemple
+        run: cp .env.example .env
+
+      - name: Valide la stack de développement
+        run: docker compose config --quiet
+
+      - name: Valide la stack déployée, profils compris
+        run: docker compose -f docker-compose.yml -f docker-compose.prod.yml --profile acme --profile monitoring --profile load config --quiet
+
+      - name: Valide le frontal SNI de la VM
+        run: |
+          docker compose -f infra/front/compose.yml config --quiet
+          docker run --rm -v "$PWD/infra/front/nginx.conf:/etc/nginx/nginx.conf:ro" nginx:1.31-alpine nginx -t
+
+      # Mêmes commandes que `make monitoring-check` : images et montages viennent du fichier Compose.
+      - name: Valide la configuration de Prometheus et ses règles
+        run: docker compose --profile monitoring run --rm --no-deps --entrypoint promtool prometheus check config /etc/prometheus/prometheus.yml
+
+      - name: Joue les tests unitaires des règles d'alerte
+        run: docker compose --profile monitoring run --rm --no-deps --entrypoint promtool prometheus test rules /etc/prometheus/tests/enervision.test.yml
+
+      - name: Valide la configuration d'Alertmanager
+        run: docker compose --profile monitoring run --rm --no-deps --entrypoint amtool alertmanager check-config /etc/alertmanager/alertmanager.yml
+
+      - name: Valide les tableaux de bord Grafana
+        run: for tableau in monitoring/grafana/dashboards/*.json; do jq empty "$tableau"; done
+
+  workflows:
+    name: Analyse des workflows
+    if: inputs.workflows
+    runs-on: ubuntu-latest
+    timeout-minutes: 10
+
+    steps:
+      - name: Récupère le dépôt
+        uses: actions/checkout@v7
+
+      # Image épinglée par tag, comme les images des fichiers Compose. Elle embarque shellcheck,
+      # qui analyse aussi les blocs `run:`.
+      - name: actionlint
+        run: docker run --rm -v "$PWD:/repo" --workdir /repo rhysd/actionlint:1.7.12 -color
@@ -2,46 +2,20 @@ name: ML

 # Piège : la version de Python vient de ml/.python-version, et doit rester en 3.14 (cf.
 # .github/workflows/backend.yml, même contrainte).
+# Pourquoi : aucun déclencheur propre. ci.yml l'appelle aussi quand les migrations ou les modèles
+# du backend changent, dont dépend le job `integration` (ADR 0014).

 on:
-  push:
-    paths:
-      - "ml/**"
-      - ".github/workflows/ml.yml"
-      # Le job `integration` monte son schema avec les migrations du backend et joue le test de
-      # chaine qui vit dans ses tests : sans ces chemins, une migration modifiee ne declencherait
-      # rien et le schema deriverait du SQL du pipeline sans que rien ne casse. Meme raisonnement
-      # que le filtre d'airflow.yml, qui inclut deja des chemins de ml/ et de apps/backend/.
-      - "apps/backend/alembic/**"
-      - "apps/backend/app/models/**"
-      - "apps/backend/tests/test_chaine_ml_api.py"
-      - "apps/backend/pyproject.toml"
-      - "apps/backend/uv.lock"
-  pull_request:
-    paths:
-      - "ml/**"
-      - ".github/workflows/ml.yml"
-      # Le job `integration` monte son schema avec les migrations du backend et joue le test de
-      # chaine qui vit dans ses tests : sans ces chemins, une migration modifiee ne declencherait
-      # rien et le schema deriverait du SQL du pipeline sans que rien ne casse. Meme raisonnement
-      # que le filtre d'airflow.yml, qui inclut deja des chemins de ml/ et de apps/backend/.
-      - "apps/backend/alembic/**"
-      - "apps/backend/app/models/**"
-      - "apps/backend/tests/test_chaine_ml_api.py"
-      - "apps/backend/pyproject.toml"
-      - "apps/backend/uv.lock"
+  workflow_call:

 permissions:
  contents: read

-concurrency:
-  group: ml-${{ github.ref }}
-  cancel-in-progress: true
-
 jobs:
  verification:
    name: Lint, typage et tests
    runs-on: ubuntu-latest
+    timeout-minutes: 15
    defaults:
      run:
        working-directory: ml
@@ -50,17 +24,19 @@ jobs:
      - name: Récupère le dépôt
        uses: actions/checkout@v7

+      # Action tierce, épinglée sur le commit du tag (règle Sonar githubactions:S7637).
      - name: Installe uv
-        uses: astral-sh/setup-uv@v7
+        uses: astral-sh/setup-uv@37802adc94f370d6bfd71619e3f0bf239e1f3b78 # v7
        with:
          enable-cache: true
          cache-dependency-glob: ml/uv.lock
+          prune-cache: false

      - name: Installe l'interpréteur déclaré par .python-version
        run: uv python install

-      - name: Synchronise les dépendances sans dévier du verrou
-        run: uv sync --all-groups --frozen
+      - name: Synchronise les dépendances sur le verrou
+        run: uv sync --all-groups --locked

      - name: Vérifie le formatage
        run: uv run ruff format --check .
@@ -71,17 +47,24 @@ jobs:
      - name: Typage
        run: uv run mypy enervision_ml tests

-      # Les tests exigeant une base portent le marqueur `integration`, ecarte par defaut et
-      # joue par le job `integration` ci-dessous.
-      - name: Tests
-        run: uv run pytest
+      # Les tests exigeant une base portent le marqueur `integration`, écarté par défaut et
+      # joué par le job `integration` ci-dessous.
+      - name: Tests et couverture
+        run: uv run pytest --cov-report=xml

-  # Le seul job du depot qui dispose a la fois des deux environnements uv et d'une base. Piege :
-  # le schema de la base ML est celui du backend (apps/backend/alembic, proprietaire du schema).
-  # Le reconstruire ici a la main rendrait ce job vert sur une base qui n'est pas la notre.
+      - name: Verse la couverture pour Sonar
+        uses: actions/upload-artifact@v7
+        with:
+          name: ml-coverage
+          path: ml/coverage.xml
+          if-no-files-found: error
+
+  # Piège : le schéma de la base ML est celui du backend (apps/backend/alembic, propriétaire du
+  # schéma). Le reconstruire ici à la main rendrait ce job vert sur une base qui n'est pas la nôtre.
  integration:
    name: ML - DB et chaîne ML - DB - API
    runs-on: ubuntu-latest
+    timeout-minutes: 20

    services:
      db:
@@ -112,26 +95,27 @@ jobs:
        uses: actions/checkout@v7

      - name: Installe uv
-        uses: astral-sh/setup-uv@v7
+        uses: astral-sh/setup-uv@37802adc94f370d6bfd71619e3f0bf239e1f3b78 # v7
        with:
          enable-cache: true
          cache-dependency-glob: |
            ml/uv.lock
            apps/backend/uv.lock
+          prune-cache: false

      - name: Installe l'interpréteur déclaré par .python-version
        working-directory: ml
        run: uv python install

-      - name: Synchronise le pipeline ML sans dévier du verrou
+      - name: Synchronise le pipeline ML sur le verrou
        working-directory: ml
-        run: uv sync --all-groups --frozen
+        run: uv sync --all-groups --locked

      # Le backend est installé ici parce qu'il porte les migrations, seule source du schéma, et
      # le test de chaîne, qui interroge l'API.
-      - name: Synchronise le backend sans dévier du verrou
+      - name: Synchronise le backend sur le verrou
        working-directory: apps/backend
-        run: uv sync --all-groups --frozen
+        run: uv sync --all-groups --locked

      # db/init/110-test-database.sql n'est pas monté ici, et sans l'extension la première
      # révision Alembic refuse de s'appliquer.
@@ -142,8 +126,8 @@ jobs:
        working-directory: apps/backend
        run: uv run alembic upgrade head

-      # `-m` en ligne de commande écrase celui d'addopts. Couverture désactivée : ce job ne joue
-      # qu'une partie de la suite, son taux n'aurait pas de sens (même raison que backend.yml).
+      # Couverture désactivée : ce job ne joue qu'une partie de la suite, son taux n'aurait pas
+      # de sens (même raison que backend.yml).
      - name: Tests ML exigeant une base
        working-directory: ml
        run: uv run pytest -m integration --no-cov
@@ -159,6 +143,7 @@ jobs:
  sast:
    name: Analyse statique de sécurité
    runs-on: ubuntu-latest
+    timeout-minutes: 10
    defaults:
      run:
        working-directory: ml
@@ -170,7 +155,9 @@ jobs:
      # Pourquoi : pas de cache ici. uvx n'installe pas le projet, le verrou n'alimente donc
      # aucune clé de cache ; la seule roue téléchargée est celle de Bandit.
      - name: Installe uv
-        uses: astral-sh/setup-uv@v7
+        uses: astral-sh/setup-uv@37802adc94f370d6bfd71619e3f0bf239e1f3b78 # v7
+        with:
+          enable-cache: false

      - name: Analyse le code livré (bloquant à partir de MEDIUM)
        run: uvx bandit==1.9.4 --recursive enervision_ml --severity-level medium --confidence-level medium
@@ -1,172 +0,0 @@
-name: SonarQube
-
-on:
-  push:
-    paths:
-      - "apps/frontend/**"
-      - "apps/backend/**"
-      - "ml/**"
-      - "etl/airflow/**"
-      - ".github/workflows/sonarqube.yml"
-  pull_request:
-    paths:
-      - "apps/frontend/**"
-      - "apps/backend/**"
-      - "ml/**"
-      - "etl/airflow/**"
-      - ".github/workflows/sonarqube.yml"
-
-
-# Build l'ensemble du projet, puis lance les tests
-# Génère les rapports de couverture, puis lance l'analyse SonarQube
-
-jobs:
-  build-front:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v7
-      - uses: actions/setup-node@v7
-        with:
-          node-version: 26
-          cache: npm
-          cache-dependency-path: apps/frontend/package-lock.json
-      
-      - run: npm ci 
-        working-directory: apps/frontend
-      - run: npm run build
-        working-directory: apps/frontend
-
-  test-front:  
-    needs: build-front
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v7
-      - uses: actions/setup-node@v7
-        with:
-          node-version: 26
-          cache: npm
-          cache-dependency-path: apps/frontend/package-lock.json
-
-      - name : Installation des dépendances (Front)
-        run: npm ci 
-        working-directory: apps/frontend
-
-      - name : Lancement des tests et génénration du rapport de couverture (Front)
-        run: npm test --watch=false --code-coverage --coverageReporters=lcov
-        working-directory: apps/frontend
-
-      - name: Upload coverage
-        uses: actions/upload-artifact@v7
-        with:
-          name: frontend-coverage
-          path: apps/frontend/coverage/frontend/lcov.info
-
-  build-back:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v7
-      - name: Installe uv
-        uses: astral-sh/setup-uv@v7
-        with:
-          enable-cache: true
-          cache-dependency-glob: apps/backend/uv.lock
-      - name: Installe l'interpréteur déclaré par .python-version
-        run: uv python install
-        working-directory: apps/backend
-
-      - name: Synchronise les dépendances sans dévier du verrou
-        run: uv sync --all-groups --frozen
-        working-directory: apps/backend
-
-      - name: Vérifie le formatage
-        run: uv run ruff format --check .
-        working-directory: apps/backend
-
-      - name: Analyse statique
-        run: uv run ruff check --output-format=github .
-        working-directory: apps/backend
-
-      - name: Typage
-        run: uv run mypy app
-        working-directory: apps/backend
-
-
-  test-back:
-    needs: build-back
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v7
-      - name: Installe uv
-        uses: astral-sh/setup-uv@v7
-        with:
-          enable-cache: true
-          cache-dependency-glob: apps/backend/uv.lock
-
-      - name : Lancement des tests et génénration du rapport de couverture (Back)
-        run: uv run pytest --cov-fail-under=85 --cov-report=xml
-        working-directory: apps/backend
-
-      - name: Upload coverage
-        uses: actions/upload-artifact@v7
-        with:
-          name: backend-coverage
-          path: apps/backend/coverage.xml
-
-  test-ml:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v7
-      - name: Installe uv
-        uses: astral-sh/setup-uv@v7
-        with:
-          enable-cache: true
-          cache-dependency-glob: ml/uv.lock
-
-      - name: Installe l'interpréteur déclaré par .python-version
-        run: uv python install
-        working-directory: ml
-
-      - name: Synchronise les dépendances sans dévier du verrou
-        run: uv sync --all-groups --frozen
-        working-directory: ml
-
-      - name: Lancement des tests et génération du rapport de couverture (ML)
-        run: uv run pytest --cov-report=xml
-        working-directory: ml
-
-      - name: Upload coverage
-        uses: actions/upload-artifact@v7
-        with:
-          name: ml-coverage
-          path: ml/coverage.xml
-
-  sonarqube:
-    needs: [build-front, build-back, test-front, test-back, test-ml]
-    name: SonarQube
-    # Pourquoi : GitHub ne fournit pas les secrets aux workflows lancés par dependabot[bot].
-    # Sans SONAR_TOKEN le scan échoue sans rien analyser ; build et tests restent joués.
-    if: github.actor != 'dependabot[bot]'
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v7
-        with:
-          fetch-depth: 0
-      - name: Téléchargement du rapport de couverture (Front)
-        uses: actions/download-artifact@v8
-        with:
-          name: frontend-coverage
-          path: apps/frontend/coverage/frontend
-      - name: Téléchargement du rapport de couverture (Back)
-        uses: actions/download-artifact@v8
-        with:
-          name: backend-coverage
-          path: apps/backend
-      - name: Téléchargement du rapport de couverture (ML)
-        uses: actions/download-artifact@v8
-        with:
-          name: ml-coverage
-          path: ml
-      - name: SonarQube Scan
-        uses: SonarSource/sonarqube-scan-action@v8
-        env:
-          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
@@ -22,6 +22,12 @@ apps/frontend/.angular/
 npm-debug.log*
 yarn-error.log*

+# Tests de bout en bout et de charge : rapports générés et identifiants des comptes de test
+playwright-report/
+blob-report/
+tests/e2e/.comptes.json
+tests/load/results/
+
 # Terraform
 .terraform/
 # .terraform.lock.hcl est versionne (pas ignore) pour figer les versions de provider entre contributeurs/CI
@@ -54,8 +60,6 @@ secrets/
 data/raw/*
 !data/raw/.gitkeep
 *.sqlite3
-monitoring/grafana/data/
-monitoring/prometheus/data/

 # ML : jeu de donnees, modeles entraines et suivi MLflow local, tous generes/volumineux
 ml/data/
@@ -63,13 +67,15 @@ ml/models/*
 !ml/models/.gitkeep
 ml/mlruns/
 ml/mlartifacts/
-ml/mlflow.db
+ml/mlflow.db*
+ml/.env

 # Airflow : base sqlite locale generee par les tests d'integrite des DAGs (etl/airflow/tests)
 etl/airflow/tests/.airflow_home/

 # TLS : certificats du reverse proxy, générés par script ou par certbot
 infra/proxy/tls/*.pem
+infra/proxy/acme/

 # IDE et OS
 .idea/
@@ -2,6 +2,7 @@ BACKEND := apps/backend
 FRONTEND := apps/frontend
 ML := ml
 AIRFLOW := etl/airflow
+E2E := tests/e2e
 COMPOSE_PROD := docker compose -f docker-compose.yml -f docker-compose.prod.yml

 # Piège : sans `export`, une valeur passée en ligne de commande n'atteindrait pas docker compose.
@@ -20,6 +21,8 @@ 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)
@@ -32,6 +35,31 @@ PG_TEST_DB ?= enervision_test
 TEST_DATABASE_URL ?= postgresql+asyncpg://$(PG_USER):$(PG_PASSWORD)@localhost:$(PG_PORT)/$(PG_TEST_DB)
 ML_TEST_DATABASE_URL ?= postgresql+psycopg://$(PG_USER):$(PG_PASSWORD)@localhost:$(PG_PORT)/$(PG_TEST_DB)

+# Piege : ni make ni ces cibles ne lisent `.env` pour COMPOSE_PROFILES, que docker compose y lit
+# seul. `stack-up` le relit ici pour savoir s'il doit poser le role `supervision` apres migration.
+SUPERVISION := $(findstring monitoring,$(COMPOSE_PROFILES) $(call env-val,COMPOSE_PROFILES))
+SERVICES_SUPERVISION := prometheus alertmanager grafana postgres-exporter node-exporter cadvisor
+GRAFANA_PORT := $(or $(strip $(call env-val,GRAFANA_PORT)),3001)
+PROMETHEUS_PORT := $(or $(strip $(call env-val,PROMETHEUS_PORT)),9090)
+supervision-garde = for cle in APP_METRICS_TOKEN GRAFANA_ADMIN_PASSWORD SUPERVISION_DB_PASSWORD; do \
+		sed -n "s/^$$cle=//p" .env 2>/dev/null | tail -1 | grep -q . \
+			|| { echo "$$cle manquant dans .env, requis par la supervision (cf. .env.example)"; exit 1; }; \
+	done
+MONITORING := docker compose --profile monitoring
+PROMTOOL := $(MONITORING) run --rm --no-deps --entrypoint promtool prometheus
+
+# Piege : `e2e-prepare` ajoute trois sites `demo-*` et des comptes `test-*` a la base visee. Elle
+# vise la base de `make dev` ; ne jamais la lancer contre la recette ou la prod.
+E2E_COMPTES ?= $(CURDIR)/$(E2E)/.comptes.json
+E2E_API ?= http://localhost:$(or $(strip $(call env-val,BACKEND_PORT)),8000)
+
+# Piege : `run` ne demarre que k6, la stack doit deja tourner. `--user` fait ecrire les rapports
+# de tests/load/results avec l'uid du poste, pas celui de l'image (12345), qui n'y a pas acces.
+k6-run = mkdir -p tests/load/results && $(COMPOSE_PROD) --profile load run --rm \
+	--user "$$(id -u):$$(id -g)" -e K6_WEB_DASHBOARD=true \
+	-e K6_WEB_DASHBOARD_EXPORT=/results/$(1)-$$(date +%Y%m%dT%H%M%S).html \
+	k6 run /scripts/$(1).js
+
 # Le jeu historique s'arrete au 31/12/2024 : score et detection ancres a l'horloge reelle ne
 # verraient qu'un parc muet depuis des mois. Cf. `--now` de enervision_ml.score.
 DEMO_NOW ?= 2024-12-31T00:00:00Z
@@ -43,12 +71,14 @@ DEMO_NOW ?= 2024-12-31T00:00:00Z
        test-chaine check \
        openapi docker-build db-up db-down db-reset db-logs db-psql db-wait db-ensure-airflow \
        migrate migrate-test bootstrap-admin services-up demo-data demo-data-force \
-        ml-lint ml-typecheck ml-test ml-check ml-train ml-score detect-alerts recommendations \
+        ml-lint ml-typecheck ml-test ml-check ml-train ml-score mlflow-up 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
+        tls-selfsigned tls-acme tls-renew tls-dns01 front-up stack-up stack-down stack-logs \
+        e2e-install e2e-prepare e2e load-smoke load-test load-stress load-limits \
+        db-ensure-supervision monitoring-up monitoring-down monitoring-logs monitoring-check

 help: ## Liste les cibles disponibles
-	@grep -E '^[a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | awk 'BEGIN {FS = ":.*?## "}; {printf "  \033[36m%-16s\033[0m %s\n", $$1, $$2}'
+	@grep -E '^[a-zA-Z0-9_-]+:.*?## .*$$' $(MAKEFILE_LIST) | awk 'BEGIN {FS = ":.*?## "}; {printf "  \033[36m%-16s\033[0m %s\n", $$1, $$2}'

 install: install-backend install-frontend install-ml install-airflow ## Installe les dépendances backend, frontend, ML et Airflow

@@ -136,6 +166,14 @@ 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),)

@@ -173,8 +211,10 @@ stack-up: ## Démarre la stack derrière le reverse proxy, puis migre la base. P
 		|| { echo "Aucun certificat dans infra/proxy/tls. Lancer d'abord make tls-selfsigned"; exit 1; }
 	@openssl x509 -in infra/proxy/tls/fullchain.pem -noout -checkhost "$(PUBLIC_HOST)" >/dev/null \
 		|| { echo "Le certificat ne couvre pas $(PUBLIC_HOST). Relancer make tls-selfsigned PUBLIC_HOST=$(PUBLIC_HOST) FORCE=1"; exit 1; }
+	@$(if $(SUPERVISION),$(supervision-garde),true)
 	$(COMPOSE_PROD) up -d --build
 	$(COMPOSE_PROD) exec -T backend alembic upgrade head
+	@$(if $(SUPERVISION),$(MAKE) --no-print-directory db-ensure-supervision,true)

 stack-down: ## Arrête la stack complète en conservant les données
 	$(COMPOSE_PROD) stop
@@ -195,6 +235,82 @@ tls-renew: ## Renouvelle les certificats Let's Encrypt et recharge le proxy
 	$(COMPOSE_PROD) --profile acme run --rm certbot renew --deploy-hook /deploy-hook.sh
 	$(COMPOSE_PROD) exec proxy nginx -s reload

+# Pourquoi : la VM n'a qu'une IP privée, que Let's Encrypt ne joint pas ; le défi DNS-01 passe
+# par l'API du fournisseur DNS, dynv6 par défaut (ADR 0018). Le jeton ne passe jamais par `argv`.
+ACME_SH := neilpang/acme.sh:3.1.6
+DNS01_API ?= dns_dynv6
+DNS01_JETON_VAR ?= DYNV6_TOKEN
+DNS01_JETON_FICHIER ?= $(abspath $(CURDIR)/../dns.token)
+acme-sh = docker run --rm --user "$$(id -u):$$(id -g)" -e $(DNS01_JETON_VAR) -e AUTO_UPGRADE=0 \
+	-v "$(CURDIR)/infra/proxy/acme:/acme.sh" -v "$(CURDIR)/infra/proxy/tls:/tls" $(ACME_SH)
+
+# acme.sh sort en 2 quand le certificat n'est pas encore à renouveler, et recopie le jeton dans
+# acme/account.conf : d'où le chmod, qui le soustrait aux autres comptes de la machine.
+tls-dns01: ## Certificat Let's Encrypt par DNS-01, renouvelé seulement à échéance. Jeton : ../dns.token
+	@case "$(PUBLIC_HOST)" in *.local | localhost) echo "PUBLIC_HOST=$(PUBLIC_HOST) n'est pas un nom public"; exit 1 ;; esac
+	@test -r "$(DNS01_JETON_FICHIER)" || { echo "Jeton DNS illisible : $(DNS01_JETON_FICHIER)"; exit 1; }
+	@mkdir -p infra/proxy/acme && chmod 700 infra/proxy/acme
+	@$(DNS01_JETON_VAR)="$$(tr -d '[:space:]' < "$(DNS01_JETON_FICHIER)")"; export $(DNS01_JETON_VAR); \
+		$(acme-sh) --issue --server letsencrypt --dns $(DNS01_API) -d "$(PUBLIC_HOST)"; \
+		code=$$?; chmod -R go-rwx infra/proxy/acme; [ $$code -eq 0 ] || [ $$code -eq 2 ] || exit $$code
+	@$(acme-sh) --install-cert --ecc -d "$(PUBLIC_HOST)" \
+		--fullchain-file /tls/fullchain.pem --key-file /tls/privkey.pem
+	@$(COMPOSE_PROD) exec -T proxy nginx -s reload 2>/dev/null \
+		|| echo "Proxy arrêté : il lira le certificat à son démarrage"
+
+front-up: ## Démarre ou recharge le frontal SNI de la VM, sur les ports 80 et 443 de l'hôte
+	docker compose -f infra/front/compose.yml up -d
+	docker compose -f infra/front/compose.yml exec -T front nginx -s reload
+
+e2e-install: ## Installe Playwright et Chromium pour les tests de bout en bout
+	cd $(E2E) && npm ci && npx playwright install chromium
+
+e2e-prepare: ## Sème le jeu de démonstration et crée les comptes de test sur la base de `make dev`
+	docker compose exec -T db psql -U $(PG_USER) -d $(PG_DB) -v ON_ERROR_STOP=1 < db/seeds/demo.sql
+	cd $(BACKEND) && BASE_URL=$(E2E_API) COMPTES_FICHIER=$(E2E_COMPTES) ADMIN_SUPPLEMENTAIRE=1 \
+		../../scripts/comptes-test.sh
+
+e2e: ## Joue les parcours Playwright. E2E_BASE_URL= optionnel (défaut http://localhost:4200)
+	cd $(E2E) && E2E_COMPTES=$(E2E_COMPTES) npx playwright test
+
+load-smoke: ## Tir k6 d'une minute. K6_EMAIL= et K6_PASSWORD= d'un lecteur, K6_BASE_URL= optionnel
+	$(call k6-run,smoke)
+
+load-test: ## Charge nominale k6, 50 utilisateurs pendant 8 minutes. Rapport HTML dans tests/load/results
+	$(call k6-run,charge)
+
+load-stress: ## Monte le débit jusqu'à la rupture de l'API. Sur la VM, la prod partage la machine
+	$(call k6-run,stress)
+
+load-limits: ## Vérifie par le proxy que nginx limite le débit d'une même adresse (429)
+	$(call k6-run,limitation-debit)
+
+# Piege : le mot de passe est lu dans `.env` par le shell et passe a psql sur son entree
+# standard. Developpe par make, il apparaitrait en clair dans la ligne de commande (`ps`).
+db-ensure-supervision: ## Crée ou réaligne le rôle `supervision`, en lecture seule, de Grafana et de l'exportateur
+	@mdp="$$(sed -n 's/^SUPERVISION_DB_PASSWORD=//p' .env 2>/dev/null | tail -1)"; \
+	[ -n "$$mdp" ] || { echo "SUPERVISION_DB_PASSWORD manquant dans .env"; exit 1; }; \
+	{ printf '\\set mot_de_passe %s\n' "$$mdp"; cat db/roles/supervision.sql; } \
+		| docker compose exec -T db psql -U $(PG_USER) -d $(PG_DB) -v ON_ERROR_STOP=1 -v base=$(PG_DB) -q
+
+monitoring-up: ## Démarre la supervision sur la stack en cours : Prometheus, Alertmanager, Grafana, exporteurs
+	@$(supervision-garde)
+	$(MONITORING) up -d --no-deps $(SERVICES_SUPERVISION)
+	@$(MAKE) --no-print-directory db-ensure-supervision
+	@echo "grafana -> http://localhost:$(GRAFANA_PORT)  prometheus -> http://localhost:$(PROMETHEUS_PORT)"
+
+monitoring-down: ## Arrête la supervision en conservant ses données
+	$(MONITORING) stop $(SERVICES_SUPERVISION)
+
+monitoring-logs: ## Suit les journaux de Prometheus, Alertmanager et Grafana
+	$(MONITORING) logs -f prometheus alertmanager grafana
+
+monitoring-check: ## Valide la configuration de supervision et joue les tests des règles d'alerte, comme la CI
+	$(PROMTOOL) check config /etc/prometheus/prometheus.yml
+	$(PROMTOOL) test rules /etc/prometheus/tests/enervision.test.yml
+	$(MONITORING) run --rm --no-deps --entrypoint amtool alertmanager check-config /etc/alertmanager/alertmanager.yml
+	@for tableau in monitoring/grafana/dashboards/*.json; do jq empty "$$tableau" || exit 1; done
+
 db-up: ## Démarre la base PostgreSQL TimescaleDB
 	docker compose up -d db

@@ -27,7 +27,8 @@ Ce que la documentation apporte à chacun : [docs/architecture/00-vue-ensemble.m
 | Infra      | Terraform (k3s single-node)         | `infra/terraform`   | Initialise    |
 | Reverse proxy | Nginx, TLS                       | `infra/proxy`       | En place      |
 | CI/CD      | GitHub Actions                      | `.github/workflows` | En place |
-| Monitoring | Prometheus, Grafana, Alertmanager   | `monitoring`        | A initialiser |
+| Monitoring | Prometheus, Grafana, Alertmanager   | `monitoring`        | En place, profil Compose |
+| Tests e2e et de charge | Playwright, k6              | `tests`             | En place |
 | ML         | LightGBM, MLflow                    | `ml`                | En place |

 Le backend, la base et l'infrastructure (Terraform/k3s) sont initialises a ce stade. Le frontend
@@ -48,9 +49,10 @@ L'etat detaille de chaque brique et les vues d'architecture sont dans
 ├── db/
 │   ├── init/           Bootstrap PostgreSQL + TimescaleDB
 │   ├── migrations/     Migrations SQL versionnees
-│   └── seeds/          Jeux de donnees de reference
+│   ├── roles/          Roles PostgreSQL hors schema (supervision)
+│   └── seeds/          Jeu de demonstration des tests
 ├── etl/airflow/
-│   ├── dags/           DAGs d'orchestration (pipeline ML, alertes, import, dérive)
+│   ├── dags/           DAGs d'orchestration (pipeline ML, alertes, imports, dérive)
 │   ├── plugins/        Operateurs et hooks maison
 │   ├── include/        Requetes SQL et ressources des DAGs
 │   └── tests/          Tests d'integrite des DAGs
@@ -64,6 +66,9 @@ L'etat detaille de chaque brique et les vues d'architecture sont dans
 │   ├── prometheus/     Collecte et regles d'alerte
 │   ├── grafana/        Provisioning et dashboards
 │   └── alertmanager/   Routage des alertes
+├── tests/
+│   ├── e2e/            Parcours Playwright contre la stack
+│   └── load/           Scenarios de charge k6
 ├── docs/               ADR et vues d'architecture
 └── scripts/            Outillage local
 ```
@@ -148,10 +153,25 @@ nom de domaine public ne résout vers la machine. Routage, mode ACME et renouvel

 Sur la VM ENI, deux environnements cohabitent, recette sur `dev` et production sur `main`,
 chacun dans son dossier et son projet Compose : `scripts/provision-host.sh` les prépare, le
-workflow `deploy.yml` les redéploie à chaque push par un runner auto-hébergé. Ports, noms
+workflow `deploy.yml` les redéploie par un runner auto-hébergé, une fois la CI du commit poussé
+verte ([ADR 0014](docs/adr/0014-pipeline-ci-unique-et-deploiement-conditionne.md)). Ports, noms
 d'hôte et garde-fous dans [`docs/architecture/10-infra.md`](docs/architecture/10-infra.md) et
 [l'ADR 0009](docs/adr/0009-deux-environnements-compose-sur-la-vm-eni.md).

+## Tests de bout en bout, charge et supervision
+
+| Besoin | Commandes | Détail |
+|---|---|---|
+| Parcours utilisateur (Playwright) | `make e2e-install`, puis `make e2e-prepare e2e` contre `make dev` | [`tests/e2e/README.md`](tests/e2e/README.md) |
+| Tir de charge (k6) | `make load-smoke`, `load-test`, `load-stress`, `load-limits` | [`tests/load/README.md`](tests/load/README.md) |
+| Supervision | `make monitoring-up`, Grafana sur <http://localhost:3001> | [`monitoring/README.md`](monitoring/README.md) |
+
+La CI joue les parcours, un tir de fumée et le contrôle de la limitation de débit à chaque PR
+qui touche l'application, contre la stack de prod derrière le proxy
+([ADR 0015](docs/adr/0015-tests-e2e-et-de-charge-contre-la-stack-compose.md)). La supervision
+est active en prod, à la demande ailleurs
+([ADR 0016](docs/adr/0016-supervision-en-profil-compose.md)).
+
 ## Conventions

 - Branches : `feat/`, `fix/`, `chore/`, `docs/`, `test/` suivi d'un libelle court.
@@ -50,7 +50,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)]


@@ -16,6 +16,9 @@ EN_TETES: Final[dict[str, str]] = {
    "X-Content-Type-Options": "nosniff",
    "X-Frame-Options": "DENY",
    "Referrer-Policy": "no-referrer",
+    # same-origin : aucun client ne charge l'API en no-cors depuis une autre origine
+    # (proxy.conf.json en dev, reverse proxy nginx ensuite, cf. docs/architecture/20-backend.md).
+    "Cross-Origin-Resource-Policy": "same-origin",
 }

 PREFIXE_AUTHENTIFICATION: Final = "/auth"
@@ -102,7 +102,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 "
@@ -1,7 +1,7 @@
 from functools import lru_cache
 from typing import Literal, Self

-from pydantic import Field, SecretStr, model_validator
+from pydantic import Field, SecretStr, field_validator, model_validator
 from pydantic_settings import BaseSettings, SettingsConfigDict

 Environment = Literal["local", "dev", "staging", "prod"]
@@ -76,6 +76,13 @@ class Settings(BaseSettings):
    expose_api_docs: bool | None = None
    metrics_token: SecretStr | None = None

+    # Compose passe `APP_METRICS_TOKEN` vide quand aucun jeton n'est posé : vide vaut absent, sinon
+    # `/metrics` exigerait un `Bearer` sans valeur et plus rien ne pourrait le scruter.
+    @field_validator("metrics_token", mode="before")
+    @classmethod
+    def _jeton_vide_vaut_absent(cls, valeur: object) -> object:
+        return None if valeur == "" else valeur
+
    @property
    def allowed_origins(self) -> list[str]:
        return [origin.strip() for origin in self.cors_origins.split(",") if origin.strip()]
@@ -45,15 +45,19 @@ CAPACITY_BOUNDS = (0.0, 100_000.0)
 def create_mock_api_client() -> httpx.AsyncClient:
    settings = get_settings()

-    if settings.mock_api_username is None or settings.mock_api_password is None:
+    username = settings.mock_api_username
+    password = (
+        settings.mock_api_password.get_secret_value()
+        if settings.mock_api_password is not None
+        else None
+    )
+
+    if not username or not username.strip() or not password or not password.strip():
        raise ValueError("Les identifiants de l'API Mock ne sont pas configurés.")

    return httpx.AsyncClient(
        base_url=settings.mock_api_base_url.rstrip("/"),
-        auth=(
-            settings.mock_api_username,
-            settings.mock_api_password.get_secret_value(),
-        ),
+        auth=(username, password),
        timeout=settings.mock_api_timeout_seconds,
    )

@@ -6,7 +6,8 @@ from fastapi import Depends, FastAPI
 from fastapi.middleware.cors import CORSMiddleware
 from fastapi.openapi.docs import get_redoc_html, get_swagger_ui_html
 from fastapi.staticfiles import StaticFiles
-from prometheus_fastapi_instrumentator import Instrumentator
+from prometheus_client import CollectorRegistry, GCCollector, PlatformCollector, ProcessCollector
+from prometheus_fastapi_instrumentator import Instrumentator, metrics
 from starlette.requests import Request
 from starlette.responses import HTMLResponse

@@ -37,6 +38,16 @@ async def lifespan(_: FastAPI) -> AsyncIterator[None]:
    await get_engine().dispose()


+# Pourquoi : le registre global n'accepte chaque métrique qu'une fois. Toute application créée
+# après la première, dans les tests notamment, n'aurait rien mesuré.
+def _registre_de_metriques() -> CollectorRegistry:
+    registre = CollectorRegistry()
+    ProcessCollector(registry=registre)
+    PlatformCollector(registry=registre)
+    GCCollector(registry=registre)
+    return registre
+
+
 def create_app(settings: Settings | None = None) -> FastAPI:
    resolved = settings or get_settings()
    configure_logging(resolved)
@@ -102,7 +113,14 @@ def create_app(settings: Settings | None = None) -> FastAPI:

    register_error_handlers(application)

-    Instrumentator().instrument(application).expose(
+    # Les sondes de santé tombent toutes les 30 s : comptées, elles fausseraient latences et débit.
+    # Seaux fins autour du seuil de charge (p95 < 500 ms, ADR 0015), route par route.
+    registre = _registre_de_metriques()
+    Instrumentator(
+        excluded_handlers=["/metrics", f"{resolved.api_prefix}/health/.*"], registry=registre
+    ).add(
+        metrics.default(latency_lowr_buckets=(0.05, 0.1, 0.25, 0.5, 1, 2.5), registry=registre)
+    ).instrument(application).expose(
        application,
        endpoint="/metrics",
        include_in_schema=False,
@@ -65,6 +65,15 @@ def parse_args(argv: list[str] | None = None) -> argparse.Namespace:
        default=defauts.min_observations,
        help="En deçà, le verdict est `indetermine` plutôt qu'un chiffre trompeur.",
    )
+    parser.add_argument(
+        "--bias-threshold",
+        type=float,
+        default=defauts.seuil_biais,
+        help=(
+            "Biais absolu en kWh au-delà duquel le verdict bascule en dérive. "
+            "Zéro, le défaut, laisse le biais informatif : voir l'ADR 0013."
+        ),
+    )
    parser.add_argument(
        "--fail-on-drift",
        action="store_true",
@@ -78,6 +87,7 @@ def seuils_depuis(args: argparse.Namespace) -> Seuils:
        fenetre=timedelta(hours=args.window_hours),
        grace=timedelta(hours=args.grace_hours),
        min_observations=args.min_observations,
+        seuil_biais=args.bias_threshold,
    )


@@ -41,6 +41,8 @@ class Seuils:
    min_observations: int = 24
    ratio_derive: float = 1.25
    mae_plancher: float = 0.0
+    # Un biais se compte en kWh, donc ne se transpose pas d'un site à l'autre : zéro le désactive,
+    # sans cesser de le mesurer. Réglé par `--bias-threshold`, arbitrage dans l'ADR 0013.
    seuil_biais: float = 0.0
    seuil_couverture: float = 0.8

@@ -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": []
          }
        ]
      }
@@ -1869,7 +1869,7 @@
        "operationId": "get_drift_api_v1_monitoring_drift_get",
        "security": [
          {
-            "Jeton d'accès": []
+            "JetonAcces": []
          }
        ],
        "parameters": [
@@ -3487,13 +3487,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"
      }
@@ -23,8 +23,9 @@ async def interroge(
        ("x-content-type-options", "nosniff"),
        ("x-frame-options", "DENY"),
        ("referrer-policy", "no-referrer"),
+        ("cross-origin-resource-policy", "same-origin"),
    ],
-    ids=["nosniff", "anti_iframe", "referrer"],
+    ids=["nosniff", "anti_iframe", "referrer", "corp"],
 )
 async def test_every_response_carries_the_security_headers(
    client: AsyncClient, entete: str, valeur: str
@@ -71,6 +72,20 @@ async def test_metrics_stay_open_when_no_token_is_configured(client: AsyncClient
    assert response.status_code == 200


+async def test_an_empty_metrics_token_means_no_token() -> None:
+    assert (await interroge({"metrics_token": ""}, "/metrics")).status_code == 200
+
+
+async def test_metrics_ignore_health_probes_but_count_business_routes(client: AsyncClient) -> None:
+    await client.get("/api/v1/health/live")
+    await client.get("/api/v1/sites")
+
+    exposition = (await client.get("/metrics")).text
+
+    assert 'handler="/api/v1/health/live"' not in exposition
+    assert 'handler="/api/v1/sites"' in exposition
+
+
 async def test_metrics_demand_the_token_once_one_is_configured() -> None:
    surcharges = {"metrics_token": "un-jeton-de-supervision-assez-long"}

@@ -227,24 +227,26 @@ async def test_a_real_token_reaches_exactly_the_routes_of_its_rank(
    assert ecarts == []


-# Contrainte : `operateur` n'ouvre aujourd'hui aucune route de plus que `lecteur`, faute d'écriture
-# métier dans l'API. Figer l'égalité rend la régression visible le jour où une route d'opérateur
-# arrive sans que `ROLE_MINIMUM` soit mis à jour.
+# Contrainte : les deux rangs ne se séparent que sur les routes que `ROLE_MINIMUM` réserve à
+# `operateur`. Une route d'opérateur ajoutée sans être classée fait diverger les statuts sans
+# qu'aucune entrée ne l'annonce, et une garde d'opérateur posée par erreur sur une route de
+# lecture fait diverger ce qui devait rester identique.
@pytest.mark.integration
-async def test_the_operator_rank_opens_nothing_more_than_the_reader_rank(
+async def test_the_operator_rank_diverges_from_the_reader_rank_only_where_declared(
    comptes_par_role: dict[Role, str], client: AsyncClient
 ) -> None:
    lecteur = await authentifie(client, comptes_par_role[Role.LECTEUR])
    operateur = await authentifie(client, comptes_par_role[Role.OPERATEUR])
-    divergences: list[tuple[str, str]] = []
+    ecarts: list[tuple[str, str]] = []

-    for methode, chemin in ROLE_MINIMUM:
+    for (methode, chemin), minimum in ROLE_MINIMUM.items():
        cote_lecteur = await appelle(client, methode, chemin, headers=lecteur)
        cote_operateur = await appelle(client, methode, chemin, headers=operateur)
-        if cote_lecteur.status_code != cote_operateur.status_code:
-            divergences.append((methode, chemin))
+        diverge = cote_lecteur.status_code != cote_operateur.status_code
+        if diverge is not (minimum is Role.OPERATEUR):
+            ecarts.append((methode, chemin))

-    assert divergences == []
+    assert ecarts == []


 # Piège : `/auth/logout-all` prend un `CurrentPrincipalDep` nu, donc elle échappe au gate
@@ -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:
@@ -283,6 +283,41 @@ def test_create_mock_api_client_requires_credentials(
        mock_api_import.create_mock_api_client()


+@pytest.mark.parametrize(
+    ("username", "password_value"),
+    [
+        ("", "test-password"),
+        ("test-user", ""),
+        ("   ", "test-password"),
+        ("test-user", "   "),
+    ],
+)
+def test_create_mock_api_client_rejects_empty_credentials(
+    monkeypatch: pytest.MonkeyPatch,
+    username: str,
+    password_value: str,
+) -> None:
+    password = MagicMock()
+    password.get_secret_value.return_value = password_value
+
+    settings = SimpleNamespace(
+        mock_api_username=username,
+        mock_api_password=password,
+    )
+
+    monkeypatch.setattr(
+        mock_api_import,
+        "get_settings",
+        lambda: settings,
+    )
+
+    with pytest.raises(
+        ValueError,
+        match="Les identifiants de l'API Mock ne sont pas configurés",
+    ):
+        mock_api_import.create_mock_api_client()
+
+
 async def test_create_mock_api_client_uses_configuration(
    monkeypatch: pytest.MonkeyPatch,
 ) -> None:
@@ -33,6 +33,9 @@ async def creer_lecture(session: AsyncSession, *, site_id: str, **overrides: obj
        timestamp=overrides.get("timestamp", datetime(2026, 9, 16, tzinfo=UTC)),
        source=overrides.get("source", "api_current"),
        consumption_kw=overrides.get("consumption_kw", 10.0),
+        # Nul par defaut : seules les mesures en kWh alimentent la comparaison prevu/realise, et
+        # un override silencieusement ignore laissait la colonne vide sans que rien ne le dise.
+        consumption_kwh=overrides.get("consumption_kwh"),
        data_quality=overrides.get("data_quality", "good"),
        raw_data=overrides.get("raw_data", {}),
    )
@@ -218,3 +218,54 @@ async def test_drift_compares_the_recent_window_to_the_reference_one(
    rapports = await service(depot, min_observations=10, mae_plancher=1.0).evaluate(now=INSTANT)

    assert next(r for r in rapports if r.site_id is None).status == attendu
+
+
+async def test_drift_leaves_the_bias_out_of_the_verdict_by_default() -> None:
+    # Le modèle surestime de 3 kWh à chaque heure, et le verdict reste `stable` : le biais est
+    # mesuré et servi, il ne juge pas tant que `--bias-threshold` n'a pas été réglé (ADR 0013).
+    depot = FauxDepot(
+        recentes=paires(nombre=30, prevu=13.0, reel=10.0),
+        anciennes=paires(nombre=30, prevu=13.0, reel=10.0),
+        comptages=[ComptageStatut(site_id="SITE001", status="available", nombre=30)],
+    )
+
+    rapports = await service(depot, min_observations=10).evaluate(now=INSTANT)
+
+    global_ = next(rapport for rapport in rapports if rapport.site_id is None)
+    assert global_.status == STATUT_STABLE
+    assert global_.bias == 3.0
+
+
+@pytest.mark.parametrize(
+    ("prevu", "attendu"),
+    [(13.0, STATUT_DERIVE), (11.0, STATUT_STABLE)],
+    ids=["biais_au_dela", "biais_sous_le_seuil"],
+)
+async def test_drift_reports_derive_on_the_bias_once_a_threshold_is_set(
+    prevu: float, attendu: str
+) -> None:
+    # MAE récente et MAE de référence sont égales : seul le biais peut faire basculer le verdict.
+    depot = FauxDepot(
+        recentes=paires(nombre=30, prevu=prevu, reel=10.0),
+        anciennes=paires(nombre=30, prevu=prevu, reel=10.0),
+        comptages=[ComptageStatut(site_id="SITE001", status="available", nombre=30)],
+    )
+
+    rapports = await service(depot, min_observations=10, seuil_biais=2.0).evaluate(now=INSTANT)
+
+    global_ = next(rapport for rapport in rapports if rapport.site_id is None)
+    assert global_.status == attendu
+
+
+async def test_drift_prefers_the_mae_reason_when_both_the_mae_and_the_bias_exceed() -> None:
+    depot = FauxDepot(
+        recentes=paires(nombre=30, prevu=20.0, reel=10.0),
+        anciennes=paires(nombre=30, prevu=11.0, reel=10.0),
+        comptages=[ComptageStatut(site_id="SITE001", status="available", nombre=30)],
+    )
+
+    rapports = await service(depot, min_observations=10, seuil_biais=2.0).evaluate(now=INSTANT)
+
+    global_ = next(rapport for rapport in rapports if rapport.site_id is None)
+    assert global_.status == STATUT_DERIVE
+    assert "MAE" in (global_.reason or "")
@@ -106,3 +106,11 @@ def test_main_exits_zero_when_drift_is_detected_without_the_flag(

    assert code == 0
    assert capsys.readouterr().out != ""
+
+
+def test_parse_args_leaves_the_bias_threshold_disabled_by_default() -> None:
+    assert cli.parse_args([]).bias_threshold == 0.0
+
+
+def test_seuils_depuis_carries_the_bias_threshold() -> None:
+    assert cli.seuils_depuis(cli.parse_args(["--bias-threshold", "2.5"])).seuil_biais == 2.5
@@ -86,3 +86,9 @@ describe('MonComposant', () => {
 - Un fichier ou un dossier seulement :
  `npx ng test --watch=false --coverage=false --include=src/app/core/services/alerts.service.spec.ts`
  (répéter `--include` pour plusieurs cibles ; un dossier joue tous ses specs)
+
+## Au-delà des tests unitaires
+Les parcours utilisateur complets (connexion, rôles, sites, recommandations, alertes) sont
+testés de bout en bout par Playwright, contre l'API et le proxy réels : voir
+[tests/e2e/README.md](../../tests/e2e/README.md). Un élément sans rôle ni libellé stable que ces
+parcours doivent viser reçoit un `data-testid`.
@@ -1,18 +0,0 @@
-sonar.projectKey=ProjetPiscine_EnerVision
-sonar.organization=groupe3-ener-vision
-sonar.sourceEncoding=UTF-8
-
-#  Dossier contenant le code source
-sonar.sources=apps/frontend/src,apps/backend/app
-sonar.tests=apps/backend/tests
-
-#  Liste des fichiers et dossiers à exclure de l'analyse
-#  Liste des fichiers et dossiers à exclure de l'analyse
-sonar.exclusions=**/node_modules/**,**/dist/**,**/*.spec.js,**/*.test.js,github,db,ml,docker-compose.yml,**/**/Dockerfile,**/**/proxy.conf.json,**/**/package.json,**/**/angular.json
-
-#  Chemin vers le rapport de couverture de code
-#  Fichier généré par Vitest
-#  Chemin vers le rapport de couverture de code
-#  Fichier généré par Vitest
-sonar.javascript.lcov.reportPaths=apps/frontend/coverage/frontend/lcov.info
-sonar.python.coverage.reportPaths=apps/backend/cov.info
@@ -20,7 +20,7 @@
  @if (data(); as d) {
    <div class="sites-grid">
      @for (site of d.sites; track site.site_id) {
-        <ev-card class="site-card">
+        <ev-card class="site-card" data-testid="site-card">
          <div class="site-card__header">
            <span class="site-card__name">{{ site.site_name }}</span>
            <ev-badge [tone]="badgeToneForOverall(site.overall)">{{ site.overall }}</ev-badge>
@@ -5,7 +5,12 @@ PostgreSQL 17 avec l'extension TimescaleDB, servie en local par le service `db`

 - `init` : scripts de bootstrap joues au premier demarrage du conteneur.
 - `migrations` : migrations SQL versionnees.
- `seeds` : jeux de donnees de reference.
+- `seeds` : jeux de donnees de reference. `demo.sql` seme trois sites `demo-*`, 72 heures de
+  releves, des alertes et des rapports de derive pour la CI, l'e2e et les tirs de charge. Base
+  jetable seulement.
+- `roles` : roles PostgreSQL hors schema applicatif. `supervision.sql` pose le role en lecture
+  seule de Grafana et de postgres-exporter, rejoue par `make db-ensure-supervision` (et par
+  `make stack-up` quand la supervision est active) plutot que par `init`, qui ne rejoue jamais.

 Les migrations du schema applicatif expose par l'API vivent dans
 `apps/backend/alembic`, pas ici.
@@ -0,0 +1,15 @@
+-- Contrainte : rôle en lecture seule de la supervision (Grafana, postgres-exporter) -
+-- supervision.sql. Ses droits ne portent que sur les tables métier : jamais `app_user`, les
+-- jetons ni le journal d'audit. `pg_monitor` donne à l'exportateur les vues de statistiques.
+-- Rejoué par `make db-ensure-supervision`, qui passe `mot_de_passe` et `base` en variables psql :
+-- crée le rôle au besoin, puis réaligne à chaque passage mot de passe et droits.
+-- Piège : les tables doivent exister, d'où l'appel après `alembic upgrade head` dans `stack-up`.
+
+SELECT 'CREATE ROLE supervision LOGIN'
+WHERE NOT EXISTS (SELECT 1 FROM pg_roles WHERE rolname = 'supervision') \gexec
+
+ALTER ROLE supervision WITH LOGIN PASSWORD :'mot_de_passe';
+GRANT pg_monitor TO supervision;
+GRANT CONNECT ON DATABASE :"base" TO supervision;
+GRANT USAGE ON SCHEMA public TO supervision;
+GRANT SELECT ON site, reading, alert, prediction, recommendation, drift_report TO supervision;
@@ -0,0 +1,101 @@
+-- Contrainte : jeu de démonstration pour une base JETABLE (CI, e2e, charge, DAST) - demo.sql.
+-- Rejouable : identifiants fixes et `ON CONFLICT DO NOTHING`, ou `NOT EXISTS` là où aucune
+-- contrainte d'unicité ne protège la table.
+-- Pourquoi : les horodatages suivent `now()`. La fenêtre par défaut de `GET /readings` couvre les
+-- 24 dernières heures, et un jeu figé dans le passé laisserait le tableau de bord vide.
+-- Piège : `demo-ecole` finit sur une lecture `partial` sans humidité, pour que la supervision des
+-- capteurs montre un site dégradé ; au-delà de dix alertes, le fil affiche « Afficher plus ».
+
+BEGIN;
+
+INSERT INTO site (site_id, site_name, site_type, location, capacity_kw, status)
+VALUES
+    ('demo-siege', 'Siège Part-Dieu', 'office', 'Lyon', 450, 'actif'),
+    ('demo-usine', 'Usine de Vénissieux', 'factory', 'Vénissieux', 900, 'actif'),
+    ('demo-ecole', 'Groupe scolaire Gratte-Ciel', 'school', 'Villeurbanne', 250, 'maintenance')
+ON CONFLICT (site_id) DO NOTHING;
+
+WITH profil (site_id, base_kw, amplitude_kw) AS (
+    VALUES ('demo-siege', 180.0, 120.0), ('demo-usine', 520.0, 260.0), ('demo-ecole', 70.0, 60.0)
+),
+heures AS (
+    SELECT date_trunc('hour', now()) - make_interval(hours => n) AS horodatage, n
+    FROM generate_series(0, 71) AS n
+),
+lectures AS (
+    SELECT
+        p.site_id,
+        h.horodatage,
+        h.n,
+        round((p.base_kw + p.amplitude_kw * greatest(0, sin(pi() * (extract(hour FROM h.horodatage) - 6) / 14)))::numeric, 2)::double precision AS kw,
+        extract(isodow FROM h.horodatage) < 6 AND extract(hour FROM h.horodatage) BETWEEN 8 AND 18 AS ouvre
+    FROM profil AS p
+    CROSS JOIN heures AS h
+)
+INSERT INTO reading (
+    site_id, timestamp, source, consumption_kw, consumption_kwh, consumption_euros,
+    voltage_v, current_a, power_factor, temperature_celsius, humidity_percent,
+    is_working_hours, data_quality, null_reasons, raw_data
+)
+SELECT
+    site_id,
+    horodatage,
+    'api_current',
+    kw,
+    kw,
+    round((kw * 0.19)::numeric, 2),
+    230.0,
+    round((kw * 1000 / (230.0 * 3 * 0.95))::numeric, 1)::double precision,
+    0.95,
+    19.5 + 3 * sin(pi() * extract(hour FROM horodatage) / 12),
+    CASE WHEN site_id = 'demo-ecole' AND n = 0 THEN NULL ELSE 45.0 END,
+    ouvre,
+    CASE WHEN site_id = 'demo-ecole' AND n = 0 THEN 'partial' ELSE 'good' END,
+    CASE WHEN site_id = 'demo-ecole' AND n = 0 THEN ARRAY['humidity_sensor_failure'] END,
+    '{}'::jsonb
+FROM lectures
+ON CONFLICT DO NOTHING;
+
+INSERT INTO prediction (site_id, target_at, target_metric, period_minutes, predicted_value, model_reference, status)
+SELECT s.site_id, date_trunc('hour', now()) + interval '1 hour', 'consumption_kwh', 60, s.valeur, 'demo-seed', 'available'
+FROM (VALUES ('demo-siege', 214.0), ('demo-usine', 610.5), ('demo-ecole', 88.2)) AS s (site_id, valeur)
+WHERE NOT EXISTS (
+    SELECT 1 FROM prediction AS p
+    WHERE p.site_id = s.site_id
+      AND p.model_reference = 'demo-seed'
+      AND p.target_at = date_trunc('hour', now()) + interval '1 hour'
+);
+
+INSERT INTO alert (source_alert_id, site_id, source, timestamp, type, severity, message, value, threshold, metric, raw_data)
+SELECT a.id, a.site_id, 'enervision', now() - make_interval(hours => a.age_h), a.type, a.severite, a.message, a.valeur, a.seuil, a.metrique, '{}'::jsonb
+FROM (
+    VALUES
+        ('demo-01', 'demo-siege', 1, 'spike', 'high', 'Pic de consommation à 312 kW', 312.0, 250.0, 'consumption_kw'),
+        ('demo-02', 'demo-siege', 3, 'threshold', 'medium', 'Seuil de 80 % de la capacité franchi', 372.0, 360.0, 'consumption_kw'),
+        ('demo-03', 'demo-siege', 6, 'anomaly', 'low', 'Consommation nocturne inhabituelle', 205.0, NULL, 'consumption_kw'),
+        ('demo-04', 'demo-siege', 9, 'sensor', 'medium', 'Capteur de température muet', NULL, NULL, 'temperature_celsius'),
+        ('demo-05', 'demo-siege', 20, 'outage', 'critical', 'Coupure de courant de 2 heures', 0.0, NULL, 'consumption_kw'),
+        ('demo-06', 'demo-usine', 2, 'spike', 'critical', 'Pic de consommation à 1 020 kW', 1020.0, 850.0, 'consumption_kw'),
+        ('demo-07', 'demo-usine', 4, 'threshold', 'high', 'Seuil de 90 % de la capacité franchi', 830.0, 810.0, 'consumption_kw'),
+        ('demo-08', 'demo-usine', 8, 'anomaly', 'medium', 'Facteur de puissance dégradé', 0.71, 0.85, 'power_factor'),
+        ('demo-09', 'demo-usine', 14, 'outage', 'high', 'Perte de mesure sur la ligne principale', NULL, NULL, 'consumption_kw'),
+        ('demo-10', 'demo-usine', 30, 'sensor', 'low', 'Capteur électrique intermittent', NULL, NULL, 'voltage_v'),
+        ('demo-11', 'demo-ecole', 1, 'sensor', 'high', 'Capteur d''humidité muet', NULL, NULL, 'humidity_percent'),
+        ('demo-12', 'demo-ecole', 5, 'anomaly', 'low', 'Chauffage actif hors des heures d''ouverture', 96.0, NULL, 'consumption_kw'),
+        ('demo-13', 'demo-ecole', 12, 'threshold', 'medium', 'Seuil de 60 % de la capacité franchi', 158.0, 150.0, 'consumption_kw'),
+        ('demo-14', 'demo-ecole', 40, 'spike', 'medium', 'Pic de consommation à 190 kW', 190.0, 160.0, 'consumption_kw')
+) AS a (id, site_id, age_h, type, severite, message, valeur, seuil, metrique)
+ON CONFLICT DO NOTHING;
+
+INSERT INTO drift_report (window_start, window_end, n_observations, mae, mape, bias, reference_mae, coverage_ratio, insufficient_data_ratio, model_references, status, reason, site_id)
+SELECT date_trunc('day', now()) - interval '7 days', date_trunc('day', now()), d.n, d.mae, d.mape, d.biais, 11.0, 0.98, 0.0, ARRAY['demo-seed'], d.statut, d.raison, d.site_id
+FROM (
+    VALUES
+        ('demo-siege', 168, 9.4, 0.052, -1.2, 'stable', NULL),
+        ('demo-usine', 168, 31.8, 0.061, 14.5, 'derive', 'MAE supérieure à 1,5 fois la référence'),
+        ('demo-ecole', 120, 6.1, 0.083, 0.4, 'stable', NULL),
+        (NULL, 456, 16.9, 0.064, 5.1, 'stable', NULL)
+) AS d (site_id, n, mae, mape, biais, statut, raison)
+ON CONFLICT DO NOTHING;
+
+COMMIT;
@@ -58,6 +58,8 @@ services:
    ports:
      - "${PROXY_HTTP_PORT:-80}:80"
      - "${PROXY_HTTPS_PORT:-443}:443"
+      # Vide : port aléatoire sur la boucle locale, pour que deux stacks sans frontal cohabitent.
+      - "${PROXY_FRONT_PORT:-127.0.0.1:}:4443"
    volumes:
      - ./infra/proxy/nginx.conf:/etc/nginx/nginx.conf:ro
      - ./infra/proxy/conf.d:/etc/nginx/conf.d:ro
@@ -34,12 +34,14 @@ x-airflow-common: &airflow-common
    # memes identifiants que le backend en attendant.
    ML_DATABASE_URL: postgresql+psycopg://${POSTGRES_USER}:${POSTGRES_PASSWORD}@db:5432/${POSTGRES_DB}
    MLFLOW_TRACKING_URI: sqlite:////opt/ml/state/mlflow.db
-    # Le DAG `alertes` lance le backend en sous-processus : il lit `DATABASE_URL`, en
-    # dialecte asyncpg, là où le pipeline ML lit `ML_DATABASE_URL`.
+    # Les DAGs backend lisent `DATABASE_URL` en dialecte asyncpg, là où le pipeline ML
+    # utilise `ML_DATABASE_URL`.
    DATABASE_URL: postgresql+asyncpg://${POSTGRES_USER}:${POSTGRES_PASSWORD}@db:5432/${POSTGRES_DB}
-    # Clé distincte de celle de l'API : la détection ne signe ni ne vérifie aucun jeton, et
-    # Airflow permet d'exécuter du code depuis son interface (cf. ADR 0008).
+
+    # Clé distincte de celle de l'API : les traitements lancés par Airflow ne signent ni ne
+    # vérifient aucun jeton. Airflow permet d'exécuter du code depuis son interface (ADR 0008).
    APP_SECRET_KEY: ${AIRFLOW_APP_SECRET_KEY:-}
+
  volumes:
    - ./etl/airflow/dags:/opt/airflow/dags
    - ./etl/airflow/plugins:/opt/airflow/plugins
@@ -105,6 +107,7 @@ services:
      APP_SMTP_PORT: "1025"
      APP_SMTP_USE_TLS: "false"
      APP_SMTP_FROM_ADDRESS: ${APP_SMTP_FROM_ADDRESS:-no-reply@enervision.fr}
+      APP_METRICS_TOKEN: ${APP_METRICS_TOKEN:-}
    ports:
      - "${BACKEND_PORT:-8000}:8000"
    restart: unless-stopped
@@ -167,6 +170,14 @@ services:
  airflow-scheduler:
    <<: *airflow-common
    command: scheduler
+    environment:
+      <<: *airflow-common-env
+      # LocalExecutor exécute les tâches dans le scheduler : lui seul a besoin des
+      # identifiants de l'API Mock.
+      APP_MOCK_API_BASE_URL: ${APP_MOCK_API_BASE_URL:-https://api-mock.charlieandre.fr}
+      APP_MOCK_API_USERNAME: ${APP_MOCK_API_USERNAME:-}
+      APP_MOCK_API_PASSWORD: ${APP_MOCK_API_PASSWORD:-}
+      APP_MOCK_API_TIMEOUT_SECONDS: ${APP_MOCK_API_TIMEOUT_SECONDS:-10}
    depends_on:
      db:
        condition: service_healthy
@@ -183,7 +194,137 @@ services:
      airflow-init:
        condition: service_completed_successfully

+  # Profil `monitoring` : actif en prod par COMPOSE_PROFILES, à la demande ailleurs (ADR 0016).
+  # Aucun `depends_on` : `make monitoring-up` démarre en `--no-deps`, sans jamais recréer `db`.
+  prometheus:
+    image: prom/prometheus:v3.14.0
+    profiles: ["monitoring"]
+    command:
+      - --config.file=/etc/prometheus/prometheus.yml
+      - --storage.tsdb.path=/prometheus
+      - --storage.tsdb.retention.time=15d
+      - --storage.tsdb.retention.size=1GB
+    volumes:
+      - ./monitoring/prometheus:/etc/prometheus:ro
+      - prometheus_data:/prometheus
+    secrets:
+      - metrics_token
+    ports:
+      - "127.0.0.1:${PROMETHEUS_PORT:-9090}:9090"
+    mem_limit: 512m
+    restart: unless-stopped
+
+  alertmanager:
+    image: prom/alertmanager:v0.34.1
+    profiles: ["monitoring"]
+    command:
+      - --config.file=/etc/alertmanager/alertmanager.yml
+      - --storage.path=/alertmanager
+    volumes:
+      - ./monitoring/alertmanager:/etc/alertmanager:ro
+      - alertmanager_data:/alertmanager
+    ports:
+      - "127.0.0.1:${ALERTMANAGER_PORT:-9093}:9093"
+    mem_limit: 64m
+    restart: unless-stopped
+
+  # Sans mot de passe, Grafana créerait un compte admin/admin : le conteneur refuse de démarrer.
+  grafana:
+    image: grafana/grafana:13.2.2
+    profiles: ["monitoring"]
+    entrypoint:
+      - /bin/sh
+      - -c
+      - ': "$${GF_SECURITY_ADMIN_PASSWORD:?GRAFANA_ADMIN_PASSWORD manquant dans .env}" && exec /run.sh'
+    environment:
+      GF_SECURITY_ADMIN_USER: admin
+      GF_SECURITY_ADMIN_PASSWORD: ${GRAFANA_ADMIN_PASSWORD:-}
+      GF_USERS_ALLOW_SIGN_UP: "false"
+      GF_AUTH_ANONYMOUS_ENABLED: "false"
+      GF_ANALYTICS_REPORTING_ENABLED: "false"
+      GF_ANALYTICS_CHECK_FOR_UPDATES: "false"
+      GF_ANALYTICS_CHECK_FOR_PLUGIN_UPDATES: "false"
+      GF_NEWS_NEWS_FEED_ENABLED: "false"
+      GF_DASHBOARDS_DEFAULT_HOME_DASHBOARD_PATH: /etc/grafana/dashboards/api.json
+      POSTGRES_DB: ${POSTGRES_DB:-enervision}
+      SUPERVISION_DB_PASSWORD: ${SUPERVISION_DB_PASSWORD:-}
+    volumes:
+      - ./monitoring/grafana/provisioning:/etc/grafana/provisioning:ro
+      - ./monitoring/grafana/dashboards:/etc/grafana/dashboards:ro
+      - grafana_data:/var/lib/grafana
+    ports:
+      - "127.0.0.1:${GRAFANA_PORT:-3001}:3000"
+    mem_limit: 256m
+    restart: unless-stopped
+
+  postgres-exporter:
+    image: prometheuscommunity/postgres-exporter:v0.20.1
+    profiles: ["monitoring"]
+    environment:
+      DATA_SOURCE_URI: db:5432/${POSTGRES_DB:-enervision}?sslmode=disable
+      DATA_SOURCE_USER: supervision
+      DATA_SOURCE_PASS: ${SUPERVISION_DB_PASSWORD:-}
+    mem_limit: 64m
+    restart: unless-stopped
+
+  node-exporter:
+    image: prom/node-exporter:v1.12.1
+    profiles: ["monitoring"]
+    command:
+      - --path.rootfs=/host
+    pid: host
+    volumes:
+      - /:/host:ro,rslave
+    mem_limit: 64m
+    restart: unless-stopped
+
+  # Contrainte : cAdvisor lit les cgroups de tous les conteneurs de l'hôte, d'où `privileged` et
+  # ses montages en lecture seule. Aucun port publié : seul Prometheus le joint.
+  cadvisor:
+    image: gcr.io/cadvisor/cadvisor:v0.55.1
+    profiles: ["monitoring"]
+    privileged: true
+    devices:
+      - /dev/kmsg
+    command:
+      - --docker_only=true
+      - --housekeeping_interval=30s
+      - --store_container_labels=false
+    volumes:
+      - /:/rootfs:ro
+      - /var/run:/var/run:ro
+      - /sys:/sys:ro
+      - /var/lib/docker/:/var/lib/docker:ro
+      - /dev/disk/:/dev/disk:ro
+    mem_limit: 160m
+    restart: unless-stopped
+
+  # Pourquoi : sur le réseau du projet, k6 joint `backend:8000` sans passer par nginx, dont la
+  # limite par adresse (20 req/s) fausserait la mesure de l'API. `make load-*` le lance (ADR 0015).
+  k6:
+    image: grafana/k6:2.3.0
+    profiles: ["load"]
+    volumes:
+      - ./tests/load:/scripts:ro
+      - ./tests/load/results:/results
+    environment:
+      K6_BASE_URL: ${K6_BASE_URL:-http://backend:8000}
+      K6_PROXY_URL: ${K6_PROXY_URL:-https://proxy}
+      K6_EMAIL: ${K6_EMAIL:-}
+      K6_PASSWORD: ${K6_PASSWORD:-}
+      K6_RESUME: ${K6_RESUME:-}
+    extra_hosts:
+      - "host.docker.internal:host-gateway"
+
 volumes:
  pgdata:
  airflow_logs:
  airflow_ml_state:
+  prometheus_data:
+  alertmanager_data:
+  grafana_data:
+
+# Vide tant qu'APP_METRICS_TOKEN n'est pas posé : l'API n'exige alors aucun jeton.
+secrets:
+  metrics_token:
+    environment: APP_METRICS_TOKEN
@@ -25,7 +25,7 @@ Le choix du modèle est dans l'ADR 0005. Ce document ne les répète pas.
 |---|---|---|
 | `load_from_csv(path)` | `ml/data/all_sites_combined.csv` | Chemin de démarrage, tant que la base n'est pas peuplée |
 | `load_from_database(connection)` | `reading` joint à `site`, **historique complet** | Entraînement |
-| `load_recent_from_database(connection, since=…)` | `reading` joint à `site`, **borné par `since`** | Scoring |
+| `load_recent_from_database(connection, since=…, until=…)` | `reading` joint à `site`, **borné des deux côtés** | Scoring |

 L'égalité des schémas n'est pas un confort : c'est ce qui permet de valider tout le pipeline sur
 CSV, sans base joignable, et d'obtenir le même comportement une fois la base peuplée. Une
@@ -93,7 +93,7 @@ La table `prediction` **n'a pas de contrainte d'unicité sur `(site_id, target_a
 insère une ligne de plus au lieu d'écraser la précédente. C'est délibéré, et c'est ce qui rend
 possible la comparaison prévision contre réalisé. La surveillance de dérive s'en sert : elle
 retient, pour chaque `(site_id, target_at)`, la ligne du run le plus récent, celle-là même que
-sert `GET /api/v1/predictions`. Voir l'[ADR 0011](adr/0011-surveillance-de-derive-dans-le-backend.md).
+sert `GET /api/v1/predictions`. Voir l'[ADR 0013](adr/0013-surveillance-de-derive-dans-le-backend.md).

 Trois contraintes de cohérence sont portées par la base et non par le code applicatif :
 `status = 'available'` exige une `predicted_value` et interdit un `failure_reason` ;
@@ -183,7 +183,7 @@ l'entraînement, dont le DAG `ml_train` n'a pas de planification.
 La surveillance de dérive traverse cette frontière **dans le sens de la table vers le backend**,
 sans la percer : elle relit `prediction` et `reading` en SQL, ne charge aucun modèle, et n'appelle
 pas MLflow. Son calcul, son seuil et son refus de comparer à la métrique d'entraînement sont dans
-l'[ADR 0011](adr/0011-surveillance-de-derive-dans-le-backend.md).
+l'[ADR 0013](adr/0013-surveillance-de-derive-dans-le-backend.md).

 ---

@@ -194,4 +194,4 @@ l'[ADR 0011](adr/0011-surveillance-de-derive-dans-le-backend.md).
 - [ADR 0006](adr/0006-moteur-de-regles-dans-le-backend.md) : ce qui consomme les prédictions
 - [`architecture/20-backend.md`](architecture/20-backend.md) : le contrat de `GET /predictions`
 - [`architecture/40-data.md`](architecture/40-data.md) : le modèle de données
- [ADR 0011](adr/0011-surveillance-de-derive-dans-le-backend.md) : la surveillance de dérive
+- [ADR 0013](adr/0013-surveillance-de-derive-dans-le-backend.md) : la surveillance de dérive
@@ -17,4 +17,9 @@
 | [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 |
-| [0011](adr/0011-surveillance-de-derive-dans-le-backend.md) | La surveillance de dérive vit dans le backend et écrit sa propre table |
+| [0011](adr/0011-enervision-procedure-deploiement.md) | Procédure de déploiement, telle qu'exécutée le 22/09/2026 |
+| [0012](adr/0012-enervision-deploiement-rec-prod-vm-eni.md) | État de la recette et de la production sur la VM ENI |
+| [0013](adr/0013-surveillance-de-derive-dans-le-backend.md) | La surveillance de dérive vit dans le backend et écrit sa propre table |
+| [0014](adr/0014-pipeline-ci-unique-et-deploiement-conditionne.md) | Un pipeline CI unique appelle les workflows de composant et conditionne le déploiement |
+| [0015](adr/0015-tests-e2e-et-de-charge-contre-la-stack-compose.md) | Les tests de bout en bout et de charge visent la stack Compose déployée |
+| [0016](adr/0016-supervision-en-profil-compose.md) | La supervision vit dans un profil Compose, active en prod |
@@ -0,0 +1,162 @@
+# EnerVision · procédure de déploiement (22/09/2026)
+
+Terraform provisionne la machine, GitHub Actions déploie (ADR 0010). Deux environnements Compose
+sur la VM ENI `10.101.200.37` : `rec` sur la branche `dev`, `prod` sur `main` (ADR 0009).
+
+| | recette | production |
+|---|---|---|
+| Branche, environnement GitHub | `dev`, `rec` | `main`, `prod` |
+| Dossier, projet Compose | `/srv/enervision/rec`, `enervision-rec` | `/srv/enervision/prod`, `enervision-prod` |
+| URL | `https://rec.enervision.local:8443` | `https://enervision.local` |
+| Proxy HTTP / HTTPS | `127.0.0.1:8081` / `8443` | `80` / `443` |
+| Postgres / Mailpit / Airflow (locaux) | `5434` / `8026` / `8082` | `5433` / `8025` / `8080` |
+
+## 0. Avant toute commande
+
+1. **Clé SSH déposée** sur la VM : `ssh-copy-id -i ~/.ssh/id_ed25519.pub root@10.101.200.37`.
+   Terraform ne gère **pas** l'authentification par mot de passe (elle finirait dans le state).
+2. **L'utilisateur propriétaire existe déjà** sur la VM (ex. `enervision`) : il possède
+   `/srv/enervision` et fait tourner le runner. Terraform échoue tôt s'il manque, il ne le crée pas.
+3. **Jeton d'enregistrement du runner** : Settings > Actions > Runners > New self-hosted runner.
+   Valable 1 h, une seule inscription, créé par un administrateur du dépôt (ineszang).
+4. **`main` est en retard de 64 commits** et ne porte ni `deploy.yml`, ni `provision-host.sh`, ni
+   le Terraform, ni l'overlay paramétré (ports et `PUBLIC_ORIGIN` en dur). Tant que `dev` n'est pas
+   remonté dans `main`, seule la recette est déployable : le clone `prod` sera préparé mais son
+   `make stack-up` publierait 80/443 sans les variables, et aucun push sur `main` ne déclencherait
+   de déploiement (le workflow n'y existe pas). **Remonter `dev` → `main` avant de toucher à prod.**
+
+## 1. Provisionner la machine (depuis le poste)
+
+```bash
+cd infra/terraform/environments/vm-eni
+cp terraform.tfvars.example terraform.tfvars
+terraform init
+terraform apply
+```
+
+`terraform.tfvars`, ignoré par git, trois valeurs à renseigner :
+
+```hcl
+proprietaire   = "enervision"   # doit exister sur la VM
+runner_version = "2.330.0"      # épingler depuis github.com/actions/runner/releases
+runner_token   = "..."          # jeton d'1 h, à retirer du fichier après l'apply
+```
+
+Défauts utiles : `ssh_host = "10.101.200.37"`, `ssh_user = "root"`,
+`ssh_private_key_path = "~/.ssh/id_ed25519"`, `racine = "/srv/enervision"`,
+`runner_labels = "eni-g3"` (ciblé par `deploy.yml`), `runner_dossier = "/opt/actions-runner"`.
+
+L'apply fait trois choses, dans cet ordre : Docker + plugin Compose et `usermod -aG docker`,
+puis `scripts/provision-host.sh`, puis l'installation et l'enregistrement du runner en service.
+Il ne construit aucune image et ne démarre aucun conteneur : un apply n'interrompt pas la stack.
+
+Rejouable : un clone existant est réaligné, un `.env` présent n'est **jamais** réécrit, un
+certificat présent n'est jamais régénéré. Un nouvel apply de la ressource runner redemande un
+jeton frais (il expire en 1 h).
+
+## 2. Variables d'environnement
+
+Un `.env` par dossier, en `600`, généré sur la machine depuis `.env.example`. **Aucun secret ne
+passe par git ni par GitHub** : le runner n'en reçoit aucun (seul `SONAR_TOKEN` existe côté CI).
+
+**Générés automatiquement** : `POSTGRES_PASSWORD`, `APP_SECRET_KEY`, `AIRFLOW_FERNET_KEY`,
+`AIRFLOW_API_SECRET_KEY`, `AIRFLOW_JWT_SECRET`, `AIRFLOW_ADMIN_PASSWORD`, `AIRFLOW_APP_SECRET_KEY`.
+
+**Fixés par environnement** : `COMPOSE_PROJECT_NAME`, `PUBLIC_HOST`, `PUBLIC_ORIGIN`,
+`PROXY_HTTP_PORT`, `PROXY_HTTPS_PORT`, `POSTGRES_PORT`, `MAILPIT_UI_PORT`, `AIRFLOW_PORT`.
+
+**À renseigner à la main**, dans chaque `.env`, avant le premier démarrage :
+
+```
+APP_MOCK_API_USERNAME=...
+APP_MOCK_API_PASSWORD=...
+```
+
+Garde-fou : le script refuse d'écrire un `.env` s'il reste un `change_me` hors `APP_MOCK_API_*`
+(cas vécu d'une clé renommée en amont, `AIRFLOW_WEBSERVER_SECRET_KEY` sous Airflow 3).
+
+`APP_ENV=prod` et `APP_DEBUG=false` sont en dur dans l'overlay, pas dans le `.env` : la valeur
+`local` du poste reprendrait le dessus et rouvrirait `/docs` sans cookie `__Secure-`.
+
+`TS_TUNE_MEMORY=2GB` et `TS_TUNE_NUM_CPUS=2` sont obligatoires : deux TimescaleDB sur 8 Go se
+réserveraient 25 % de la RAM chacune. La montée à 32 Go est à demander.
+
+Certificats auto-signés générés par le script (`infra/proxy/tls/`), couvrant le nom d'hôte,
+`localhost` et l'IP. Let's Encrypt (`make tls-acme`, `ACME_EMAIL`) reste hors d'atteinte sans
+domaine public résolvable.
+
+## 3. Premier démarrage (manuel, une seule fois, sur la VM)
+
+```bash
+cd /srv/enervision/rec && make stack-up      # build + up + alembic upgrade head
+cd /srv/enervision/prod && make stack-up     # seulement après la remontée dev → main
+```
+
+`stack-up` refuse de démarrer si le certificat manque ou ne couvre pas `PUBLIC_HOST`, et applique
+les migrations : sans elles la stack démarrerait verte sur une base sans schéma.
+
+Premier administrateur, stack démarrée, dans chaque dossier :
+
+```bash
+docker compose -f docker-compose.yml -f docker-compose.prod.yml exec backend \
+    python -m app.cli create-admin --email <adresse>
+```
+
+Données historiques : `data/raw` n'est pas dans git. Déposer les fichiers dans chaque dossier
+avant de déclencher le DAG `historical_import`.
+
+## 4. Réglages GitHub (administrateur du dépôt)
+
+- Environnement `prod` : branche `main` seule autorisée, **approbation d'un relecteur** requise.
+- Environnement `rec` : branche `dev` seule autorisée, sans approbation.
+- Settings > Actions : **« Require approval for all outside collaborators »**. Un runner
+  auto-hébergé sur un dépôt public exécute ce qu'on lui envoie ; `deploy.yml` ne se déclenche
+  jamais sur `pull_request`, et le runner ne tourne jamais en root.
+
+## 5. Déploiement continu, ensuite
+
+Un push sur `dev` déploie la recette, un push sur `main` la production après approbation.
+Le job (runner `eni-g3`) aligne le clone (`fetch`, `checkout`, `reset --hard`), lance
+`make stack-up`, puis sonde `/api/v1/health/ready` derrière le proxy pendant 3 minutes ; en cas
+d'échec il publie `ps` et les 50 dernières lignes de `backend` et `proxy`. Pas de `checkout` dans
+l'espace du runner : `.env`, certificats et volumes doivent survivre d'un déploiement à l'autre.
+Concurrence par branche, sans annulation.
+
+Déclenchement manuel possible : `workflow_dispatch`.
+
+## 6. Vérifier
+
+```bash
+curl -k https://localhost:8443/api/v1/health/ready    # recette, sur la VM
+curl -k https://localhost/api/v1/health/ready         # production, sur la VM
+```
+
+Depuis un poste, ajouter à `/etc/hosts` :
+
+```
+10.101.200.37 enervision.local rec.enervision.local
+```
+
+Les deux noms sont obligatoires : le cookie `__Secure-ev_refresh` est posé par hôte et non par
+port ; un seul nom déconnecterait la production à chaque connexion en recette.
+
+## Pièges à connaître
+
+- Compose **2.24.4 minimum** : l'overlay emploie `!override` et `!reset`, sans quoi l'API resterait
+  joignable en clair à côté du proxy. Le script le vérifie.
+- Le runner doit tourner sous le propriétaire de `/srv/enervision` : sinon git refuse les clones
+  (propriété douteuse) et le `.env` en `600` lui échappe. Correctif :
+  `PROPRIETAIRE=<utilisateur> bash scripts/provision-host.sh`.
+- Chaque environnement reconstruit ses images à partir du même commit : la production n'exécute
+  pas l'artefact validé en recette, mais un second build. Le passage à GHCR lèvera cette limite.
+- Un `.env` perdu se régénère, mais invalide les sessions et les connexions chiffrées par Airflow :
+  ils ne sont sauvegardés nulle part ailleurs.
+- Retirer le runner se fait à la main, depuis les paramètres du dépôt : `terraform destroy` ne le
+  désinscrit pas.
+
+## Références dans le dépôt
+
+`docs/adr/0009-deux-environnements-compose-sur-la-vm-eni.md`,
+`docs/adr/0010-terraform-provisionne-github-actions-deploie.md`,
+`docs/architecture/50-cicd.md`, `docs/architecture/10-infra.md`, `infra/README.md`,
+`scripts/provision-host.sh`, `.github/workflows/deploy.yml`, `docker-compose.prod.yml`.
@@ -0,0 +1,120 @@
+# EnerVision · Recette et production sur la VM ENI, aujourd'hui
+
+État au lundi 21 septembre 2026, 15h. Cible : deux environnements qui tournent sur la VM
+`eadl-2025-nantes-g3` (`10.101.200.37`) avant vendredi 25/09 9h, déployés automatiquement depuis
+GitHub. Ce document donne la solution retenue, ce qu'elle change dans le dépôt, et le déroulé de
+l'après-midi avec qui fait quoi.
+
+## 1. La décision en une phrase
+
+**Deux projets Docker Compose sur la même VM, un par environnement, déployés par un runner GitHub
+Actions installé sur la VM.** `dev` alimente la recette, `main` alimente la production. Terraform
+reste ce qu'il est : le module k3s, cible à terme, non utilisé pour cette mise en ligne.
+
+| | Recette (`rec`) | Production (`prod`) |
+|---|---|---|
+| Branche | `dev` | `main` |
+| Environnement GitHub | `rec` (créé ce midi) | `prod` (créé ce midi) |
+| Dossier sur la VM | `/srv/enervision/rec` | `/srv/enervision/prod` |
+| Projet Compose | `enervision-rec` | `enervision-prod` |
+| URL | `https://rec.enervision.local:8443` | `https://enervision.local` |
+| Proxy HTTPS | `8443` | `443` |
+| Proxy HTTP (redirection) | `127.0.0.1:8081`, inutilisé | `80` |
+| PostgreSQL, Mailpit, Airflow | `127.0.0.1` : `5434`, `8026`, `8082` | `127.0.0.1` : `5433`, `8025`, `8080` |
+| Certificat | auto-signé, SAN `rec.enervision.local` | auto-signé, SAN `enervision.local` |
+| Déclenchement | chaque push sur `dev` | push sur `main`, après approbation dans GitHub |
+
+Les deux noms d'hôte pointent sur la même IP. Deux lignes dans le `/etc/hosts` des postes de
+l'équipe suffisent. Deux noms distincts sont indispensables : le cookie de rafraîchissement
+`__Secure-ev_refresh` est posé par hôte, pas par port, et un seul nom ferait se déconnecter la
+prod à chaque connexion sur la recette.
+
+## 2. Pourquoi c'est la solution la plus simple
+
+- **Tout existe déjà.** L'overlay `docker-compose.prod.yml`, le proxy Nginx TLS, les scripts de
+  certificat et `make stack-up` sont écrits et validés sur poste (PR #117, ADR 0007). Il ne
+  manque que quatre variables pour que deux instances cohabitent sur une machine.
+- **Un projet Compose isole tout.** Volumes, réseau, noms de conteneurs sont préfixés par le nom
+  du projet. Casser la recette ne touche pas la prod, ce qui est la raison d'être d'une recette.
+- **Le runner sur la VM est la seule façon d'atteindre une IP privée d'école depuis GitHub.** Les
+  runners hébergés par GitHub ne voient pas `10.101.200.37`. Le runner se connecte en sortie
+  vers GitHub, aucun port entrant n'est nécessaire. C'était le choix 16 du dossier EC01 : il
+  redevient tenu.
+- **La promotion existe déjà dans la stratégie de branches** : `dev` puis `main` par PR. Le
+  même code est déployé en recette, puis en production, sans troisième mécanisme.
+
+Ce qu'on écarte, et pourquoi :
+
+| Piste | Pourquoi pas cette semaine |
+|---|---|
+| k3s avec deux namespaces | Le cluster serait vide : aucun manifeste, aucun registre d'images, aucun stockage persistant. Trois jours de travail sans valeur visible au J10 |
+| Terraform de `feat/deploy` (nginx système + copie de fichiers) | Revue postée sur l'issue #21 : huit points bloquants, `rec` et `prod` ne passent pas `terraform validate`. On abandonne cette voie |
+| Azure ENI pour la prod | Deuxième infrastructure à provisionner, choix à justifier devant le jury (document 03), et rien n'est prêt côté Azure |
+| Images publiées sur GHCR | Meilleure pratique, mais un registre de plus à authentifier sur la VM. Les images se construisent sur la VM, où le runner tourne déjà. À faire ensuite, issue à ouvrir |
+| Let's Encrypt | Aucun domaine public ne résout vers la VM. Auto-signé assumé, chemin ACME déjà câblé |
+
+## 3. Ce qui change dans le dépôt (une PR vers `dev`)
+
+| Fichier | Changement | Raison |
+|---|---|---|
+| `apps/frontend/Dockerfile` | `FROM nginx:1.28-alpine` à la place de `dhi.io/nginx:...` | Le registre Docker Hardened Images demande une authentification. L'image frontend n'a jamais été construite, sur aucun poste : c'est le premier point où `make stack-up` échouerait sur la VM |
+| `docker-compose.prod.yml` | Ports du proxy en variables `PROXY_HTTP_PORT` et `PROXY_HTTPS_PORT`. Origine publique `PUBLIC_ORIGIN` pour CORS et le lien de réinitialisation. `TS_TUNE_MEMORY` sur la base | Deux proxys ne peuvent pas publier 80 et 443. L'origine de la recette porte un port. Deux TimescaleDB sur 8 Go se réserveraient chacune 2 Go sans réglage |
+| `.env.example` | `COMPOSE_PROJECT_NAME`, les variables ci-dessus, ports de la recette en commentaire | Le `.env` de chaque dossier est la seule différence entre les deux environnements |
+| `.github/workflows/deploy.yml` | Nouveau. `on: push` sur `dev` et `main`, `runs-on: [self-hosted, eni-g3]`, `environment: rec` ou `prod`, puis `git reset --hard origin/<branche>` et `make stack-up` dans le dossier de l'environnement | Le D de CI/CD, issue #21 |
+| `scripts/provision-host.sh` | Nouveau. Vérifie Docker et Compose 2.24.4 ou plus, crée `/srv/enervision/{rec,prod}`, clone les deux branches | Rejouable, et réutilisable par Terraform plus tard |
+| `docs/adr/0009-...md`, `10-infra.md`, `50-cicd.md`, `infra/proxy/README.md` | Décision, vue infra, vue CI/CD, tableau des ports | Règle du dépôt : la vue change dans la même PR que le composant |
+
+Ce qui ne change pas : `docker-compose.yml`, la configuration Nginx, `infra/terraform`.
+
+## 4. Déroulé de l'après-midi
+
+| # | Qui | Quoi | Durée |
+|---|---|---|---|
+| 1 | **ineszang** (seule admin du dépôt) | Environnement `prod` : branche autorisée `main`, un relecteur requis. Environnement `rec` : branche `dev`. Settings > Actions : « Require approval for all outside collaborators ». Générer le jeton d'enregistrement du runner (Settings > Actions > Runners > New self-hosted runner, Linux x64) et le transmettre à Johan | 10 min |
+| 2 | **Johan** | Déposer sa clé sur la VM : `ssh-copy-id -i ~/.ssh/id_ed25519.pub root@10.101.200.37`, mot de passe du compte administrateur local des postes de l'école | 2 min |
+| 3 | Johan + Claude | **Fait à 15h** : branche locale `feat/deploy-rec-prod` avec tous les changements du §3, image frontend reconstruite avec succès, fusion Compose vérifiée pour les deux environnements. Reste : commit, push, PR vers `dev` | fait |
+| 4 | Claude, par SSH | `scripts/provision-host.sh` sur la VM. Écrire les deux `.env` (secrets générés sur la VM, jamais dans git). Certificats : `PUBLIC_HOST=rec.enervision.local PUBLIC_IP=10.101.200.37 make tls-selfsigned` dans `rec`, idem avec `enervision.local` dans `prod`. Puis `make stack-up` dans chaque dossier | 20 min plus la construction des images |
+| 5 | Johan, sur la VM | Installer le runner sous un utilisateur non-root membre du groupe `docker`, label `eni-g3`, en service systemd (`./config.sh --unattended --labels eni-g3`, `sudo ./svc.sh install && sudo ./svc.sh start`) | 10 min |
+| 6 | Équipe | Merger la PR dans `dev` : la recette se redéploie seule. Ouvrir la PR `dev` vers `main` : la prod se déploie après approbation dans l'onglet Environments | 15 min |
+| 7 | Tous | Vérifier depuis un poste de l'équipe, `/etc/hosts` renseigné : connexion, tableau de bord, Airflow par tunnel SSH | 15 min |
+
+Contrôle en fin de chaîne, depuis la VM :
+
+```bash
+curl -k https://localhost/api/v1/health/ready          # prod
+curl -k https://localhost:8443/api/v1/health/ready     # rec
+docker compose -p enervision-prod ps
+docker compose -p enervision-rec ps
+```
+
+## 5. Ce qui peut faire échouer la journée, et la parade
+
+| Risque | Parade |
+|---|---|
+| **8 Go de RAM pour deux stacks complètes** (deux Airflow, deux TimescaleDB, deux API) | Demander dès maintenant le passage à 32 Go, prévu par les consignes. En attendant : `TS_TUNE_MEMORY=2GB` et deux workers gunicorn pour Airflow. Si la RAM ne suit pas, démarrer la recette sans Airflow (`docker compose up -d --scale airflow-webserver=0 --scale airflow-scheduler=0`) |
+| **Compose trop ancien sur la VM** (les marqueurs `!override` et `!reset` exigent 2.24.4) | `docker compose version` en premier. Sinon installer le paquet `docker-compose-plugin` depuis le dépôt Docker |
+| **Pas de sortie Internet depuis la VM** | `curl -sI https://github.com` et `docker pull hello-world` avant tout. Sans sortie, ni construction d'image ni runner : déploiement manuel par `scp` d'images, plan B lourd |
+| **Runner auto-hébergé sur un dépôt public** | Le workflow de déploiement ne s'exécute que sur `push` vers `dev` et `main`, jamais sur `pull_request`. Réglage d'approbation des PR externes (étape 1). Runner sous un utilisateur dédié, jamais root |
+| **Premier démarrage avec un volume `pgdata` vide** | C'est le cas nominal sur la VM : `db/init` crée les bases `enervision`, `enervision_test` et `airflow`. Ne pas restaurer un volume de poste |
+| **Le jury accepte mal un certificat auto-signé** | Dire pourquoi avant qu'on le demande : aucun DNS public, ACME câblé et documenté, ADR 0007. Un clic « continuer » dans le navigateur |
+| **Conflit avec `feat/deploy`** (ineszang y a mergé `dev` à 14h06) | Partager ce document avant de pousser. La PR remplace `feat/deploy`, elle ne s'y ajoute pas |
+
+## 6. Ce que ça donne pour la grille
+
+- **EC03, CI/CD** : la chaîne ne s'arrête plus au merge. Deux environnements, déploiement
+  automatique en recette, promotion approuvée en production, journal des déploiements dans
+  l'onglet Environments de GitHub.
+- **EC04, cloud et sécurisation** : une application déployée et fonctionnelle, une seule surface
+  exposée par environnement, secrets hors de git et hors de GitHub, base et Airflow joignables
+  uniquement par tunnel SSH.
+- **Dossier EC01** : le choix 16 (runner auto-hébergé, déploiement automatique) passe de « non
+  fait » à « tenu ». Le choix 12 (Ansible) reste non fait, et la réponse est prête : le
+  durcissement de la machine n'est pas automatisé, le script de provisionnement en est la
+  première brique, Terraform pourra l'appeler.
+
+## 7. Après vendredi, si on continue
+
+Dans l'ordre de valeur : images construites une fois en CI et publiées sur GHCR, puis déployées
+par digest (vraie promotion d'artefact). Racine Terraform `environments/eni-g3` qui provisionne
+la machine et le runner à partir du script. Sauvegarde de `pgdata` par `pg_dump` planifié.
+Monitoring (issue #26). Et seulement ensuite la bascule k3s, si elle garde un sens.
@@ -1,4 +1,4 @@
-# 0011 - La surveillance de dérive vit dans le backend et écrit sa propre table
+# 0013 - La surveillance de dérive vit dans le backend et écrit sa propre table

 - Statut : accepté
 - Date : 2026-09-22
@@ -97,6 +97,13 @@ modèle change n'est pas une dérive, c'est une régression de réentraînement.
  l'identique.
 - La CLI sort en code non nul sous `--fail-on-drift` seulement. Par défaut, constater une dérive
  n'est pas un échec d'exécution.
+- **Le biais ne fait pas basculer le verdict par défaut** : `Seuils.seuil_biais` vaut `0`, ce qui
+  désactive la règle. Le plafond de MAE se dérive de la fenêtre de référence, donc il vaut pour
+  n'importe quel site ; un seuil de biais, lui, s'exprime en kWh et ne se transpose pas d'un
+  bureau de 10 kWh à une usine de 1 000 kWh. En déclarer un sans l'avoir calibré sur la vraie
+  série ferait rougir la tâche sans rien prouver. Le `bias` signé reste calculé, stocké et servi
+  par `GET /api/v1/monitoring/drift` : il se lit, il ne juge pas encore. `--bias-threshold`
+  l'active site par site quand une valeur aura été mesurée.

 ## Effet de bord assumé sur le pipeline

@@ -0,0 +1,79 @@
+# 0014 - Un pipeline CI unique appelle les workflows de composant et conditionne le déploiement
+
+- Statut : accepté
+- Date : 2026-09-23
+- Complète : [0009](0009-deux-environnements-compose-sur-la-vm-eni.md), qui reste en vigueur
+
+## Contexte
+
+Au 22/09, huit workflows se déclenchaient chacun de leur côté, et l'audit y a relevé :
+
+- **Double exécution.** Chaque workflow partait sur `push` (toutes branches) **et** sur
+  `pull_request`. Un commit poussé sur une branche de PR jouait donc toute la CI deux fois,
+  à la même minute (constaté dans l'historique des runs de `test/integration-api-db-ml`).
+- **Sonar refaisait tout.** `sonarqube.yml` reconstruisait le frontend et retestait frontend,
+  backend et ML pour produire ses rapports de couverture, en double exact de `frontend.yml`,
+  `backend.yml` et `ml.yml`. Son test backend tournait sans `uv sync`. Il n'avait ni
+  `permissions` ni `concurrency`.
+- **Déploiement non conditionné.** `deploy.yml` partait à chaque push sur `dev` ou `main`,
+  que la CI du commit soit verte ou non, et déployait la pointe de branche du moment plutôt
+  que le commit poussé.
+- **Erreurs silencieuses et hygiène.**
+  - `npm test --watch=false --code-coverage` : npm garde ces options pour lui, `ng test` ne
+    les reçoit jamais, et la CI ne tenait que par les réglages d'`angular.json`.
+  - `uv sync --frozen` ne vérifie pas que `uv.lock` suit `pyproject.toml`.
+  - Plusieurs actions tierces étaient épinglées par tag, contrairement à la règle Sonar
+    `githubactions:S7637`.
+  - Aucun job n'avait de `timeout-minutes` (360 minutes par défaut).
+
+## Décision
+
+**`ci.yml` est le seul workflow déclenché par `pull_request` et par les push sur `dev` et
+`main`.** Les workflows de composant (`backend`, `frontend`, `ml`, `airflow`, `infra`, `e2e`)
+passent en `workflow_call` et n'ont plus de déclencheur propre.
+
+1. **`changes`.** Un job initial calcule, par `dorny/paths-filter` épinglé sur un SHA, les
+   composants touchés par la PR, et chaque composant n'est appelé que si son filtre vaut vrai.
+   Sur un push vers `dev` ou `main`, tous les filtres valent vrai : l'analyse Sonar reste
+   complète sur les branches longues, et paths-filter ne compare pas à la base de fusion avec
+   `main`, qui a 80 commits de retard.
+2. **`sonar`.** Il ne reconstruit ni ne reteste plus rien : il télécharge, dans le même run, les
+   couvertures versées par les jobs `verification` des composants.
+3. **`CI ok`.** Le job agrège le résultat de tous les autres. Il tourne toujours (`if:
+   always()`) et échoue dès qu'un job est en `failure` ou `cancelled`. **C'est le seul check à
+   exiger dans les règles de branche** : un composant sauté par son filtre ne publie aucun check
+   interne, qui resterait « en attente » s'il était exigé.
+4. **`deploy`.** Il appelle `deploy.yml`, sur les seuls push, et seulement si `CI ok` a réussi.
+   `deploy.yml` aligne le dossier de l'environnement sur `GITHUB_SHA`, le commit testé, sauf
+   si ce commit précède celui déjà déployé : les CI de deux push peuvent finir dans le désordre,
+   et un environnement ne recule jamais. Les déploiements d'un même environnement passent un par
+   un sous un verrou `flock` sur la VM, et non dans un groupe `concurrency`, où GitHub ne garde
+   qu'un job en attente et annule le précédent quand un troisième arrive.
+
+`deploy.yml` n'a toujours **aucun déclencheur `pull_request`** : il n'accepte que
+`workflow_call` et `workflow_dispatch`, dans l'esprit de l'ADR 0009.
+
+## Alternatives écartées
+
+| Écartée | Raison |
+|---|---|
+| Garder huit workflows et restreindre seulement `push` à `dev` et `main` | Supprime la double exécution, pas le doublon Sonar : il faudrait toujours rejouer les tests pour que Sonar ait ses couvertures, les artefacts ne passant pas d'un workflow à l'autre. Et rien n'empêche un déploiement rouge. |
+| Déclencher le déploiement par `workflow_run` | `workflow_run` joue toujours le fichier de la branche par défaut, `main`, en retard de 80 commits : la recette ne se serait plus déployée avant la prochaine remontée vers `main`, sans erreur visible. |
+| `alls-green` ou une action tierce d'agrégation | Dix lignes de shell sur `toJSON(needs.*.result)` font le même travail, sans dépendance de plus à épingler. |
+| Cache de couches Docker (`bake-action`, `type=gha`) pour l'e2e | Quatre pièges (noms d'image, cibles Compose, buildx, `load`) pour deux à quatre minutes gagnées. Reporté après le rendu. |
+
+## Conséquences
+
+- Une PR ne joue que ce qu'elle touche. Une PR de documentation ne joue que `changes` et
+  `CI ok`.
+- Les checks s'appellent désormais « Backend / Lint, typage et tests », etc. Au 23/09, ni `dev`
+  ni `main` n'ont de règle de protection : à la première, exiger **« CI ok »** et rien d'autre.
+- Modifier `ci.yml` rejoue toute la CI sur la PR (filtre `ci`).
+- Le job `deploy` reste en file tant que le runner `eni-g3` n'est pas enregistré sur la VM,
+  comme avant. Le groupe de concurrence par SHA des push l'empêche de bloquer les runs suivants.
+- La sécurité du runner auto-hébergé ne repose pas sur l'absence de `pull_request` dans
+  `deploy.yml`. Une PR de fork peut ajouter son propre workflow. Ce qui protège le runner :
+  - l'approbation obligatoire des workflows de tous les contributeurs externes ;
+  - les règles de branche des environnements `rec` (`dev`) et `prod` (`main` et un relecteur).
+
+  Ces deux réglages restent à poser par l'administratrice du dépôt.
@@ -0,0 +1,70 @@
+# 0015 - Les tests de bout en bout et de charge visent la stack Compose déployée
+
+- Statut : accepté
+- Date : 2026-09-23
+
+## Contexte
+
+Les issues #46 (Playwright) et #47 (k6) demandent des preuves de robustesse pour EC03 et EC04.
+Rien ne vérifiait un parcours utilisateur complet : les tests du frontend simulent l'API, ceux
+du backend n'ouvrent pas de navigateur. Rien ne mesurait non plus l'API sous charge, et le
+dépôt ne chiffre aucun temps de réponse ni aucun volume d'utilisateurs.
+
+Trois contraintes du système pèsent sur la manière de tester :
+
+- **La session tient dans un cookie de refresh HttpOnly qui tourne à chaque usage.** Rejouer un
+  cookie déjà servi révoque toute la famille de session (ADR 0002).
+- **Le cookie n'est `__Secure-` et `Secure` que hors `local`, derrière le proxy TLS.** Tester
+  contre `ng serve` ne dit rien de ce que voit un navigateur en prod (ADR 0007).
+- **nginx limite chaque adresse IP** à 20 req/s sur l'API, avec une rafale de 40, et à 30
+  connexions par minute, avec une rafale de 20 (ADR 0007). Tout le trafic d'un tir parti d'une
+  seule machine partage la même adresse.
+
+## Décision
+
+**Playwright joue contre la stack de prod** (`docker-compose.yml` et
+`docker-compose.prod.yml`), sur `https://localhost` avec un certificat auto-signé.
+- **En CI**, le workflow `e2e.yml` démarre `db`, `mailpit`, `backend`, `frontend` et `proxy`,
+  sème `db/seeds/demo.sql` et crée les comptes par `scripts/comptes-test.sh`.
+- **Sur le poste**, la même suite vise `make dev` (`http://localhost:4200`).
+- **Écriture des tests**, imposée par la rotation du refresh et par la zone `auth` :
+  - un seul worker ;
+  - une session par fichier, sans `storageState` partagé ;
+  - chaque parcours qui consomme un compte le crée lui-même.
+
+**k6 tourne en service Compose (profil `load`) sur le réseau du projet et vise `backend:8000`**,
+pour mesurer l'API et non la limite de nginx. Un seul scénario, `limitation-debit.js`, passe par
+`https://proxy`, pour vérifier que la limite tient : des 429, jamais de 5xx.
+
+**Hypothèses et seuils**, faute d'exigence chiffrée :
+
+| Hypothèse ou seuil | Valeur |
+|---|---|
+| Utilisateurs simultanés | 50 : 40 sur le tableau de bord, qui interroge `/stats/summary` toutes les 10 s et `/alerts` toutes les 60 s ; 10 qui explorent les sites |
+| Lectures, p95 | < 500 ms |
+| Lectures, p99 | < 1 s |
+| Échecs HTTP | < 1 % |
+| Vérifications réussies | > 99 % |
+
+**En CI de PR** : Playwright, le tir `smoke` (une minute) et `limitation-debit`. La charge
+nominale et le stress se lancent à la main (`make load-test`, `make load-stress`), en recette,
+parce que rec et prod partagent la VM (ADR 0009).
+
+## Alternatives écartées
+
+| Écartée | Raison |
+|---|---|
+| Playwright contre `ng serve` en CI | Pas de TLS, pas de cookie `__Secure-`, pas de CSP ni de limitation : le parcours testé ne serait pas celui des utilisateurs. |
+| `storageState` partagé entre fichiers | Chaque fichier rejouerait le même cookie de refresh ; le second usage révoque la famille, et la suite échoue de façon intermittente selon l'ordre. |
+| k6 depuis le runner, à travers le proxy | Au-delà de 20 req/s, on mesure nginx. Relever la limite pour le tir, ce serait tester une configuration qui n'est pas celle de la prod. |
+| Tir de charge complet à chaque PR | Huit minutes de plus par PR, sur un runner partagé dont les performances varient d'un run à l'autre : un seuil franchi n'y voudrait rien dire. |
+| Un workflow k6 en `workflow_dispatch` contre la recette | La recette partage la VM avec la prod ; un tir déclenché d'un clic ralentirait la prod sans que personne soit prévenu. La cible Makefile, lancée sur la VM, garde un humain dans la boucle. |
+
+## Conséquences
+
+- La CI construit enfin les images backend et frontend avant le déploiement, par le job E2E.
+- `db/seeds/demo.sql` et `scripts/comptes-test.sh` deviennent le jeu commun de la CI, repris par
+  le DAST. Les deux sont réservés aux bases jetables.
+- Les seuils de k6 sont des hypothèses de l'équipe : à réviser dès qu'un besoin chiffré existe.
+- L'API expose des seaux de latence fins autour de 500 ms, pour que Grafana lise le même seuil
+  que k6 (ADR 0016).
@@ -0,0 +1,61 @@
+# 0016 - La supervision vit dans un profil Compose, active en prod
+
+- Statut : accepté
+- Date : 2026-09-23
+
+## Contexte
+
+L'API expose `/metrics` au format Prometheus depuis le début, et `monitoring/` ne contenait que
+des `.gitkeep` : aucun collecteur, aucun tableau de bord, aucune alerte (issue #26). La VM ENI
+porte la recette et la prod, deux piles complètes, sur 8 Go de mémoire (ADR 0009).
+
+## Décision
+
+**Prometheus, Alertmanager, Grafana et trois exporteurs** sont des services de
+`docker-compose.yml` sous le profil `monitoring` : postgres-exporter, node-exporter et cAdvisor.
+
+- **En prod**, `COMPOSE_PROFILES=monitoring` dans le `.env` : `make stack-up`, donc chaque
+  déploiement, les démarre avec le reste.
+- **En recette et sur le poste**, ils se lancent à la demande (`make monitoring-up`, en
+  `--no-deps`). La recette ne paie rien tant qu'on ne les lance pas.
+- **Mémoire.** Chaque service a un `mem_limit`, pour environ 700 Mo au total.
+- **Accès.** Les interfaces n'écoutent que sur `127.0.0.1` et se consultent par tunnel SSH,
+  comme Airflow. Rien ne passe par le proxy : Grafana derrière nginx exigerait sa propre
+  authentification forte, et rendrait `/metrics` joignable à un routage près (ADR 0007).
+- **Sécurité.**
+  - **Jeton.** Prometheus présente sur `/metrics` le jeton `APP_METRICS_TOKEN`, passé en
+    secret Compose. Il est exigé dès que la supervision tourne.
+  - **Lecture de la base.** Grafana et l'exportateur lisent la base par un rôle `supervision`
+    en lecture seule, limité aux tables métier (`db/roles/supervision.sql`). Ils n'ont
+    jamais accès à `app_user`, aux jetons ni à l'audit.
+- **Alertes.**
+  - Neuf règles couvrent l'API, la base, l'hôte et les cibles, chacune avec un cas de test
+    joué par `promtool test rules` en CI.
+  - Alertmanager les envoie par courriel à Mailpit, le seul SMTP de la stack.
+- **Dérive du modèle.** Elle s'affiche dans Grafana par une lecture SQL de `drift_report`.
+  L'ADR 0013 a écarté une jauge Prometheus calculée par un traitement par lot, pas la lecture
+  de sa table.
+
+## Alternatives écartées
+
+| Écartée | Raison |
+|---|---|
+| Supervision démarrée dans les deux environnements | Double la mémoire consommée sur une VM déjà serrée, pour des tableaux de recette que personne ne regarde. |
+| Une pile de supervision partagée, troisième projet Compose | Elle devrait rejoindre les réseaux des deux projets, par des réseaux externes à déclarer sur la VM : plus de pièces, et un couplage entre environnements que l'ADR 0009 évite. |
+| Publier Grafana derrière le proxy | Une interface d'administration de plus exposée au réseau de l'école, et un pas de plus vers une publication accidentelle de `/metrics`. |
+| Grafana avec le compte applicatif de la base | Le compte applicatif écrit partout, y compris dans `app_user`. Une requête libre dans Grafana y aurait accès. |
+| Une jauge de fraîcheur des relevés calculée par l'API au moment du scrape | Une requête SQL dans un collecteur synchrone, à chaque scrape. La même information se lit directement dans TimescaleDB depuis Grafana. |
+
+## Conséquences
+
+- **Secrets.** `.env.example` gagne `COMPOSE_PROFILES`, `APP_METRICS_TOKEN`,
+  `GRAFANA_ADMIN_PASSWORD`, `SUPERVISION_DB_PASSWORD` et les ports.
+  `scripts/provision-host.sh` génère ces secrets pour un nouvel environnement. Le `.env` d'un
+  environnement déjà provisionné n'est jamais réécrit : il faut les y ajouter à la main.
+  `make stack-up` refuse de démarrer si le profil est actif et qu'un secret manque.
+- **Instrumentation.** L'API ne compte plus les sondes de santé dans ses métriques, et chaque
+  application a son propre registre Prometheus.
+- **cAdvisor tourne en `privileged`**, avec des montages en lecture seule et sans port publié.
+  C'est le prix de la mémoire par conteneur, l'indicateur qui compte le plus sur une VM partagée.
+- **Données non couvertes.** L'ingestion et les DAG Airflow n'ont pas encore de métriques
+  (StatsD ou OpenTelemetry). Le tableau « Données » les supplée en lisant `reading`.
@@ -0,0 +1,57 @@
+# 0017 - Un troisième environnement, `dev`, déployé à la demande depuis n'importe quelle branche
+
+- Statut : accepté
+- Date : 2026-09-23
+
+## Contexte
+
+L'[ADR 0009](0009-deux-environnements-compose-sur-la-vm-eni.md) a posé deux environnements sur
+la VM ENI : la recette suit `dev`, la production suit `main`. Les environnements GitHub en
+comptent trois, `dev`, `rec` et `prod`, et le troisième ne déployait rien.
+
+Il manque un endroit où montrer une branche de travail avant son merge : la recette ne doit
+porter que ce qui est intégré à `dev`, sinon elle cesse d'être une recette. Un
+`workflow_dispatch` sur une branche de travail envoyait d'ailleurs cette branche dans la
+recette, puisque tout ce qui n'était pas `main` y partait.
+
+La VM est passée à 32 Go : une troisième TimescaleDB, réglée à 2 Go comme les deux autres,
+tient sans peine.
+
+## Décision
+
+**Un troisième projet Compose, `enervision-dev`, dans `/srv/enervision/dev`**, bâti exactement
+comme les deux autres : son clone, son `.env`, son certificat, préparés par
+`scripts/provision-host.sh`.
+
+**Déployé à la demande, jamais sur un push.** `deploy.yml` envoie `main` en prod, `dev` en
+recette, et toute autre branche lancée depuis l'onglet Actions dans `dev`. Seul un membre ayant
+le droit d'écriture sur le dépôt peut lancer un workflow.
+
+**Ports décalés d'un cran de plus** : HTTPS `9443`, et sur `127.0.0.1` la redirection HTTP
+`8083`, PostgreSQL `5435`, Mailpit `8027`, Airflow `8084`. Nom d'hôte `dev.enervision.local`,
+pour la même raison de cookie que la recette.
+
+**Le verrou de déploiement suit l'environnement** (un `flock` sur son dossier, ADR 0014), et non
+plus la branche : deux branches lancées coup sur coup écriraient sinon dans le même dossier en
+même temps.
+
+## Alternatives écartées
+
+- **`dev` suit la branche `dev` à chaque push, la recette devient manuelle** : la recette
+  offrirait une version figée au jury, mais la doc CI/CD, l'ADR 0009 et l'habitude de l'équipe
+  basculeraient à deux jours du rendu.
+- **Un environnement par branche de travail** : un projet Compose et une TimescaleDB par
+  branche, sans mécanisme de nettoyage. La machine ne le porterait pas longtemps.
+- **Garder `dev` sur les postes seulement** : rien à montrer d'une branche non mergée sans
+  passer par la recette.
+
+## Conséquences
+
+- Une branche de travail créée avant ce changement porte l'ancien `deploy.yml` : lancée à la
+  main, elle part encore dans la recette. Limiter l'environnement GitHub `rec` à la branche
+  `dev` ferme ce chemin, réglage que seul un administrateur du dépôt peut poser.
+- `dev` ne garde aucune donnée d'une branche à l'autre au-delà de ce que ses migrations
+  acceptent : une branche dont les migrations divergent de `dev` peut laisser la base dans un
+  état que la suivante refuse. Recréer le volume, `docker compose down -v`, est alors le remède.
+- Trois environnements construisent leurs images séparément : l'écart de l'ADR 0009, un même
+  commit construit deux fois, reste ouvert jusqu'au passage à GHCR.
@@ -0,0 +1,89 @@
+# 0018 - Noms publics, certificats Let's Encrypt par DNS-01 et frontal SNI sans port
+
+- Statut : accepté
+- Date : 2026-09-23
+
+## Contexte
+
+Les trois environnements de la VM ENI ([ADR 0009](0009-deux-environnements-compose-sur-la-vm-eni.md),
+[ADR 0017](0017-environnement-dev-a-la-demande.md)) répondaient sur `enervision.local`,
+`rec.enervision.local:8443` et `dev.enervision.local:9443`, avec des certificats auto-signés.
+Chaque poste devait éditer son `/etc/hosts` et accepter trois avertissements du navigateur :
+rien de présentable à un jury, et rien d'utilisable par quelqu'un qui n'a pas la main sur son
+poste.
+
+Contraintes : la VM n'a qu'une IP privée, `10.101.200.37`, que ni Internet ni Let's Encrypt ne
+joignent, et le réseau de l'école ne doit pas être touché. Vérifications faites le 23/09 : les
+résolveurs de l'école rendent bien une adresse privée pour un nom public, la VM sort en HTTPS
+vers Let's Encrypt et vers l'API de dynv6, mais le filtrage de l'école bloque duckdns.org, site
+et API, depuis les postes comme depuis la VM.
+
+## Décision
+
+**Des noms publics qui visent l'IP privée.** `enervision-g3.dynv6.net`, zone gratuite de dynv6,
+porte la prod, et deux enregistrements A portent `rec.` et `dev.`. `provision-host.sh` les publie
+par l'API dynv6 : le DNS est décrit par le code comme le reste. Tout
+poste du réseau de l'école les résout sans configuration ; hors de ce réseau, l'IP ne mène
+nulle part.
+
+**Des certificats Let's Encrypt par défi DNS-01.** Le défi passe par l'API dynv6, qui pose
+l'enregistrement TXT : Let's Encrypt n'a jamais à joindre la VM. `make tls-dns01` (acme.sh
+épinglé) le joue dans chaque stack ; il ne renouvelle qu'à échéance, d'où son rejeu à chaque
+déploiement et chaque nuit par cron. Un certificat par environnement plutôt qu'un joker : chaque
+stack garde le sien, et la clé de la prod n'est pas lisible depuis le clone de dev.
+
+**Un frontal SNI sur 443, le seul composant exposé.** `infra/front`, un nginx sur le réseau de
+l'hôte, lit le nom demandé dans le ClientHello et relaie le flux TLS intact vers la stack visée,
+publiée sur la boucle locale. Il ne détient aucun certificat. Le port 80 y redirige vers
+HTTPS. Les URL perdent leur port.
+
+**Le PROXY protocol entre frontal et stacks.** Relayé tel quel, le flux arriverait avec l'IP du
+frontal : `limit_req` et `get_client_ip()` compteraient tous les postes comme un seul, et un
+utilisateur bloquerait la connexion de tous. Chaque proxy de stack reçoit donc le frontal sur un
+écouteur dédié, 4443, qui exige l'en-tête PROXY protocol et en tire l'IP du client. Le 443 de
+la stack reste sans PROXY protocol, pour les postes de développement et la sonde du déploiement.
+
+**Le fournisseur est un paramètre.** `DNS01_API` et `DNS01_JETON_VAR` nomment le greffon acme.sh,
+le jeton vit dans `dns.token` quel que soit le fournisseur : passer à un domaine acheté chez
+Cloudflare ou OVH ne demande que ces deux variables et `domaine`, plus `publier_dns()`.
+
+**`scripts/provision-host.sh` fait foi pour l'adressage et les secrets.** Un `.env` existant
+garde ses secrets, reçoit ceux qui lui manquent et voit hôte, ports et profils réalignés sur le
+tableau du script. C'est ce qui permet de migrer trois `.env` nés avant ce changement, et le
+clone de la prod, en retard sur `main`, sans dépendre de son `.env.example`.
+
+## Alternatives écartées
+
+- **Garder `/etc/hosts` et l'auto-signé** : trois manipulations par poste et trois
+  avertissements, précisément ce qu'il fallait supprimer.
+- **DuckDNS** : premier choix, inscription en un clic, mais bloqué par le filtrage de l'école :
+  sans son API, pas de défi DNS-01.
+- **deSEC (`dedyn.io`)** : joignable et associatif, mais les inscriptions de nouveaux domaines
+  `dedyn.io` étaient fermées le 23/09 ; il reste le bon choix pour un domaine acheté.
+- **nip.io ou sslip.io** : résolution sans compte, mais aucun moyen d'y obtenir un certificat.
+- **Services à certificat joker public (traefik.me, local-ip.co)** : leur clé privée est publiée
+  par conception, n'importe qui peut usurper ces noms.
+- **Tunnel vers Internet (Cloudflare Tunnel, Tailscale Funnel)** : accès depuis l'extérieur,
+  mais l'application serait exposée hors de l'école, décision refusée.
+- **Autorité de certification interne (mkcert, step-ca)** : chaque poste devrait l'installer.
+- **Terminaison TLS au frontal** : un seul endroit pour les certificats, mais les stacks
+  recevraient du HTTP clair que leur proxy redirige vers HTTPS, et en-têtes de sécurité comme
+  limitation de débit seraient à déplacer. Le relais SNI ne touche à rien de tout cela.
+- **Domaine acheté** : plus présentable, mais un achat et un compte de plus pour un bénéfice nul
+  sur l'accès. Seule `DOMAINE` changerait.
+
+## Conséquences
+
+- L'objection de l'ADR 0009 à un proxy frontal, qui aurait dû joindre plusieurs réseaux Compose
+  aux services homonymes, tombe : le frontal ne joint que des ports de la boucle locale.
+- Sans le frontal, plus rien n'est joignable sur la VM. `deploy.yml` le relance à chaque
+  déploiement de la prod, et son `restart: unless-stopped` le ramène après un redémarrage.
+- Le jeton dynv6 vit dans `/srv/enervision/dns.token`, jamais dans git, GitHub ni le state
+  Terraform ; acme.sh en garde une copie dans `infra/proxy/acme/`, retirée à la lecture des
+  autres comptes. Qui le détient peut repointer les trois noms.
+- dynv6 devient une dépendance : s'il tombe, les noms cessent de résoudre et les
+  renouvellements échouent. Les certificats valent 90 jours, la marge est large.
+- Un filtrage de l'école qui viendrait à bloquer dynv6 arrêterait les renouvellements, pas les
+  noms : la résolution passe par les serveurs DNS de l'école, pas par le site.
+- Les noms sont publics mais ne mènent qu'à une IP privée : ils révèlent l'existence de la VM,
+  pas son contenu.
@@ -51,8 +51,8 @@ flowchart TB
    api["API FastAPI<br/>apps/backend"]
    db[("PostgreSQL 17<br/>TimescaleDB")]
    airflow["Airflow<br/>etl/airflow"]
-    prom["Prometheus"]
-    grafana["Grafana"]
+    prom["Prometheus<br/>profil monitoring"]
+    grafana["Grafana<br/>profil monitoring"]
  end

  navigateur --> proxy
@@ -61,9 +61,9 @@ flowchart TB
  front -.-> api
  api --> db
  airflow --> db
-  prom -.-> api
-  grafana -.-> db
-  grafana -.-> prom
+  prom --> api
+  grafana --> db
+  grafana --> prom
 ```

 Le lien `front -.-> api` reste en pointillé : le frontend appelle bien une API, mais un
@@ -72,12 +72,15 @@ intercepteur répond à sa place tant que les endpoints n'existent pas. Voir

 Le lien `airflow --> db` est maintenant en trait plein : cinq DAGs tournent, deux pour
 l'entraînement et le scoring du modèle ML (issue #115), un pour la détection d'alertes et la
-génération des recommandations (issue #116), et `historical_import` pour l'ingestion du dataset
-historique (issue #119). L'orchestration de l'import API Mock et la réconciliation globale des
-deux sources restent à compléter dans l'issue #15.
+génération des recommandations (issue #116), `historical_import` pour le dataset historique
+(issue #119) et `mock_api_import` pour l'ingestion horaire de l'API Mock (issue #15).
+La réconciliation globale des données provenant des deux sources reste à compléter dans l'issue #15.

-Le lien `prom -.-> api` de même : l'API expose bien `/metrics` au format Prometheus, mais aucun
-collecteur ne vient le lire.
+Les liens de la supervision sont en trait plein depuis le 23/09 (issue #26) : Prometheus scrute
+`/metrics` avec un jeton, Grafana lit Prometheus et, par un rôle en lecture seule, les tables
+métier de TimescaleDB. Ils tournent en prod sous le profil Compose `monitoring`, à la demande
+ailleurs ([ADR 0016](../adr/0016-supervision-en-profil-compose.md),
+[60-observabilite.md](60-observabilite.md)).

 ## État de la stack

@@ -86,18 +89,20 @@ collecteur ne vient le lire.
 | Backend | FastAPI, Python 3.14 | `apps/backend` | `En cours` | Factory, configuration, journalisation, 2 sondes de santé, `/metrics`, contrat OpenAPI versionné, routes `sites`, `alerts`, `recommendations`, `stats/summary`, `readings`, `sensors/status` et `predictions` en lecture (endpoints → services → repositories → models) |
 | 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 livrée côté backend (`app.monitoring.drift`, table `drift_report`, `GET /monitoring/drift`, DAG `derive`), voir [ADR 0011](../adr/0011-surveillance-de-derive-dans-le-backend.md) |
+| 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 livrée côté backend (`app.monitoring.drift`, table `drift_report`, `GET /monitoring/drift`, DAG `derive`), voir [ADR 0013](../adr/0013-surveillance-de-derive-dans-le-backend.md) |
 | 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. Cinq DAGs en sous-processus `uv run` : `ml_train`, `ml_score`, `alertes`, `historical_import` et `derive` (quotidien, surveillance de dérive). 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` | 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) |
+| Monitoring | Prometheus, Grafana, Alertmanager | `monitoring` | `Fait` | Profil Compose `monitoring`, actif en prod : Prometheus et trois exporteurs (PostgreSQL, hôte, conteneurs), neuf règles d'alerte testées par `promtool`, Alertmanager vers Mailpit, trois tableaux de bord Grafana provisionnés. Voir [60-observabilite.md](60-observabilite.md) |
+| ETL | Apache Airflow | `etl/airflow` | `En cours` | Webserver et scheduler avec LocalExecutor via Docker Compose, sur une base PostgreSQL dédiée. Six DAGs en sous-processus `uv run` : `ml_train`, `ml_score`, `alertes`, `historical_import`, `mock_api_import` et `derive` (quotidien, surveillance de dérive). L'import historique reste manuel et l'import API Mock s'exécute chaque heure. La réconciliation globale des deux sources reste à compléter dans l'issue #15. |
+| CI/CD | GitHub Actions | `.github/workflows` | `En cours` | Un orchestrateur `ci.yml` qui n'appelle que les composants modifiés ([ADR 0014](../adr/0014-pipeline-ci-unique-et-deploiement-conditionne.md)) : 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, Terraform, Compose et supervision, parcours Playwright et tirs k6 contre la stack de prod ([ADR 0015](../adr/0015-tests-e2e-et-de-charge-contre-la-stack-compose.md)). Déploiement vers la VM ENI par `deploy.yml`, appelé une fois « CI ok » vert, `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é : le runner n'est pas enregistré sur la machine. Détail dans [50-cicd.md](50-cicd.md) |

 ## Flux bout en bout

-Statut : `En cours`. **Le chemin de lecture tourne** : base, API et frontend. **Le chemin
-d'ingestion dessiné ci-dessous n'existe pas** : les DAGs livrés (`ml_train`, `ml_score`,
-issue #115 ; `alertes`, issue #116) orchestrent le pipeline ML et la détection d'alertes, pas
-l'ingestion, qui reste lancée à la main par les scripts d'import (issues #15 et #16).
+Statut : `En cours`. **Le chemin de lecture tourne** entre la base, l'API et le frontend.
+**Le chemin d'ingestion est maintenant orchestré par Airflow** : `historical_import` charge le
+dataset CSV/JSON sur déclenchement manuel et `mock_api_import` collecte chaque heure les mesures
+de l'API Mock. Les DAGs `ml_train` et `ml_score` (issue #115), `alertes` (issue #116) et `derive`
+(issue #45) portent le pipeline ML, la détection d'alertes et la surveillance de dérive. La
+réconciliation globale des données provenant des deux sources reste à compléter dans l'issue #15.

 ```mermaid
 sequenceDiagram
@@ -146,7 +151,7 @@ consolidée.
 - **Caviardage des journaux** : jetons, empreintes Argon2, mots de passe et cookies sont
  expurgés avant écriture.
 - **Documentation interactive fermée** en préproduction et en production, `/metrics` derrière un
-  jeton facultatif, sonde de disponibilité qui ne publie plus la version de TimescaleDB.
+  jeton, exigé dès que la supervision tourne, sonde de disponibilité qui ne publie plus la version de TimescaleDB.
 - **CI backend bloquante** : format, lint, typage strict et tests avec seuil de couverture.
 - **Conteneur backend non-root**, déclaré dans `apps/backend/Dockerfile`.
 - **Terminaison TLS au frontal** : un reverse proxy Nginx est le seul service publié, il redirige
@@ -10,6 +10,7 @@ dans quel contexte, quelles décisions sont arrêtées, et ce qui manque encore
 | 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

@@ -36,6 +37,8 @@ flowchart TB
 |---|---|---|
 | `db` | `timescale/timescaledb-ha:pg17` | Publié sur **5433** côté hôte, 5432 souvent déjà pris. `healthcheck` `pg_isready`, 12 tentatives, `start_period` 40s |
 | `backend` | Construite depuis `apps/backend` | `depends_on: db, condition: service_healthy`. **N'embarque pas le source** : toute modification impose `docker compose up -d --build backend` |
+| `prometheus`, `alertmanager`, `grafana`, exporteurs | Images épinglées par tag | Profil `monitoring`, jamais démarrés par `make dev`. `make monitoring-up` les lance en `--no-deps`. Voir [60-observabilite.md](60-observabilite.md) |
+| `k6` | `grafana/k6` | Profil `load`, lancé par `make load-*` le temps d'un tir, sur le réseau du projet. Voir [`tests/load/README.md`](../../tests/load/README.md) |

 **La boucle de développement n'utilise pas le service `backend`.** `make db-up` puis `make dev` :
 seule la base tourne en conteneur, l'API et `ng serve` tournent sur le poste avec le rechargement
@@ -53,7 +56,7 @@ Trois pièges sont documentés en tête du `docker-compose.yml`, ils ne se devin
 - `LocalExecutor` exécute les tâches comme sous-processus du **scheduler**, jamais de l'api-server :
  c'est le scheduler qui a besoin du volume `airflow_ml_state` (modèle, magasin MLflow).

-### Airflow (issues #115, #116 et #119)
+### Airflow (issues #15, #115, #116 et #119)

 Quatre services (Airflow 3.3), `docker compose profiles` non utilisés (démarrage explicite via `make
 airflow-up`, pas dans `make dev`) :
@@ -86,6 +89,7 @@ l'[ADR 0008](../adr/0008-airflow-execute-le-code-du-backend.md).
 | `ml_score` | `0 * * * *` | `enervision_ml.score`, dans `/opt/ml/.venv` |
 | `alertes` | `15 * * * *` | `app.detection.internal_alerts` puis `app.cli generate-recommendations`, dans `/opt/backend/.venv` |
 | `historical_import` | manuelle | `app.etl.historical_import`, dans `/opt/backend/.venv` ; les fichiers de `data/raw` sont montés en lecture seule dans `/opt/data/raw` |
+| `mock_api_import` | `45 * * * *` | `app.etl.mock_api_import`, dans `/opt/backend/.venv` ; importe l'heure précédant son déclenchement depuis l'API Mock |
 | `derive` | `30 5 * * *` | `app.monitoring.drift`, dans `/opt/backend/.venv` ; quotidien parce que sa fenêtre couvre 168 h, et sans reprise parce qu'une dérive n'est pas une panne passagère |

 Le DAG `historical_import` réutilise le pipeline historique existant sans dupliquer sa logique.
@@ -93,6 +97,17 @@ Il reste manuel, car le dataset sert à initialiser l'environnement. Le montage
 `./data/raw:/opt/data/raw:ro` permet au scheduler de lire les fichiers CSV/JSON sans pouvoir les
 modifier.

+Le DAG `mock_api_import` exécute le pipeline API Mock toutes les heures, à la minute `:45`.
+Un `CronTriggerTimetable` explicite lui attribue un intervalle d'une heure, y compris lors d'un
+déclenchement manuel. Il transmet cet intervalle au script backend et charge les mesures dans
+les tables communes `site` et `reading`. Le décalage à `:45` laisse quinze minutes avant le
+scoring exécuté à l'heure pile, puis quinze minutes supplémentaires avant les alertes à `:15`.
+`max_active_runs=1` empêche deux exécutions du DAG de se chevaucher.
+
+Le DAG conserve `catchup=False` pour éviter un rattrapage massif depuis sa date de démarrage.
+Une interruption du scheduler peut donc créer un intervalle manquant, qui devra être rejoué
+explicitement par une opération de backfill.
+
 **Pourquoi `alertes` tourne à la quinzième minute.** Sa règle `anomaly` compare une lecture à la
 `prediction` du même instant, que `ml_score` écrit à l'heure pile. Le décalage laisse le scoring
 finir. Aucune dépendance n'est déclarée entre les deux DAGs pour autant, ni `ExternalTaskSensor` ni
@@ -149,6 +164,34 @@ 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
@@ -160,11 +203,12 @@ flowchart LR
  navigateur["Navigateur"]

  subgraph machine["Machine on-premise"]
-    proxy["service proxy<br/>nginx:1.28-alpine<br/>:80 et :443"]
+    proxy["service proxy<br/>nginx:1.31-alpine<br/>:80 et :443"]
    front["service frontend<br/>nginx statique :3000"]
    api["service backend<br/>uvicorn :8000"]
    db[("service db<br/>:5432")]
    mail["service mailpit"]
+    sup["profil monitoring<br/>Prometheus, Alertmanager, Grafana"]
  end

  navigateur -->|"HTTPS"| proxy
@@ -172,6 +216,9 @@ flowchart LR
  proxy -->|"/api/"| api
  api --> db
  api --> mail
+  sup -->|"/metrics, jeton"| api
+  sup -->|"rôle supervision, lecture seule"| db
+  sup -->|"alertes par courriel"| mail
 ```

 Le proxy est **le seul service à publier des ports** sur le réseau. Backend et frontend ne sont
@@ -186,27 +233,36 @@ Deux conséquences se propagent jusqu'à l'application, et elles ne se devinent
 - `APP_TRUST_PROXY_HEADERS` passe à vrai en même temps, sinon la limitation de débit par IP
  compte sur l'IP du proxy et devient globale.

-### Deux environnements sur la même machine
+### Trois environnements sur la même machine

-Statut : `En cours`, la machine n'étant pas encore provisionnée. Décision et motifs dans
-l'[ADR 0009](../adr/0009-deux-environnements-compose-sur-la-vm-eni.md).
-La VM `eadl-2025-nantes-g3` portera la recette et la production, chacune dans son clone du dépôt,
-son `.env` et son projet Compose. Le nom de projet préfixe volumes, réseau et conteneurs : rien
-n'est partagé. `scripts/provision-host.sh` prépare les deux dossiers, génère les secrets et les
-certificats, et ne démarre rien.
+Statut : `En cours`. Décision et motifs dans
+l'[ADR 0009](../adr/0009-deux-environnements-compose-sur-la-vm-eni.md), étendue à un troisième
+environnement par l'[ADR 0017](../adr/0017-environnement-dev-a-la-demande.md) ; noms,
+certificats et frontal sans port dans l'[ADR 0018](../adr/0018-noms-publics-certificats-dns01-et-frontal-sni.md).
+La VM `eadl-2025-nantes-g3` porte le développement, la recette et la production, chacun dans son
+clone du dépôt, son `.env` et son projet Compose. Le nom de projet préfixe volumes, réseau et
+conteneurs : rien n'est partagé. `scripts/provision-host.sh` prépare les trois dossiers, génère
+les secrets et les certificats, et ne démarre rien.

-| | Recette | Production |
-|---|---|---|
-| Branche, environnement GitHub | `dev`, `rec` | `main`, `prod` |
-| Dossier, projet Compose | `/srv/enervision/rec`, `enervision-rec` | `/srv/enervision/prod`, `enervision-prod` |
-| URL | `https://rec.enervision.local:8443` | `https://enervision.local` |
-| Proxy HTTP, HTTPS | `127.0.0.1:8081`, `8443` | `80`, `443` |
-| PostgreSQL, Mailpit, Airflow, sur `127.0.0.1` | `5434`, `8026`, `8082` | `5433`, `8025`, `8080` |
+| | Développement | Recette | Production |
+|---|---|---|---|
+| Branche, environnement GitHub | toute branche lancée à la main, `dev` | `dev`, `rec` | `main`, `prod` |
+| Dossier, projet Compose | `/srv/enervision/dev`, `enervision-dev` | `/srv/enervision/rec`, `enervision-rec` | `/srv/enervision/prod`, `enervision-prod` |
+| URL | `https://dev.enervision-g3.dynv6.net` | `https://rec.enervision-g3.dynv6.net` | `https://enervision-g3.dynv6.net` |
+| Proxy HTTP, HTTPS, PROXY protocol, sur `127.0.0.1` | `8083`, `9443`, `9444` | `8081`, `8443`, `8444` | `10080`, `10443`, `10444` |
+| PostgreSQL, Mailpit, Airflow, sur `127.0.0.1` | `5435`, `8027`, `8084` | `5434`, `8026`, `8082` | `5433`, `8025`, `8080` |
+| Supervision (profil `monitoring`) | à la demande, `make monitoring-up` | à la demande, `make monitoring-up` | active, `COMPOSE_PROFILES=monitoring` |
+| Grafana, Prometheus, Alertmanager, sur `127.0.0.1` | `3003`, `9092`, `9095` | `3002`, `9091`, `9094` | `3001`, `9090`, `9093` |

-Les deux noms d'hôte visent la même IP, à déclarer dans le `/etc/hosts` des postes. Deux noms
-distincts sont nécessaires : le cookie `__Secure-ev_refresh` est posé par hôte, pas par port.
-La redirection HTTP de la recette est ramenée sur la boucle locale parce que la configuration
-Nginx renvoie vers `https://$host` sans port, c'est-à-dire vers la production.
+Les trois noms sont publics chez dynv6 et visent l'IP privée de la VM : rien à déclarer sur
+les postes du réseau de l'école, et rien n'est joignable hors de ce réseau. Trois noms distincts
+sont nécessaires : le cookie `__Secure-ev_refresh` est posé par hôte, pas par port.
+
+Aucune stack ne publie hors de la boucle locale. Le frontal `infra/front`, sur le réseau de
+l'hôte, écoute 80 et 443 : il redirige le premier, et aiguille le second d'après le nom demandé
+(SNI) vers l'écouteur PROXY protocol de la stack visée, sans déchiffrer le TLS. Chaque stack
+garde son certificat Let's Encrypt, obtenu par défi DNS-01 (`make tls-dns01`) et renouvelé à
+chaque déploiement ainsi que chaque nuit par `/etc/cron.d/enervision-tls`.

 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`.
@@ -226,7 +282,7 @@ sequenceDiagram

  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
+  VM->>VM: trois clones, trois .env, trois certificats
  TF->>VM: installe actions-runner, config.sh, svc.sh
  VM->>GH: le runner s'enregistre avec le label eni-g3
 ```
@@ -312,11 +368,13 @@ Ces arbitrages sont pris. Ils ne vivaient jusqu'ici que dans des commentaires de
 | API | `8000` | Identique en conteneur et hors conteneur |
 | Frontend, `ng serve` | `4200` | Boucle de développement. Valeur par défaut d'`APP_CORS_ORIGINS` |
 | Frontend en conteneur | `3000` | Ce qu'écoute le nginx de l'image, en conteneur comme côté hôte |
-| Reverse proxy | `80` et `443` | Les seuls ports publiés par `docker-compose.prod.yml`, via `PROXY_HTTP_PORT` et `PROXY_HTTPS_PORT`. 80 ne sert que la redirection et le défi ACME. La recette publie `8443` et `127.0.0.1:8081` |
+| Reverse proxy | `80` et `443`, plus `4443` | Les seuls ports publiés par `docker-compose.prod.yml`, via `PROXY_HTTP_PORT`, `PROXY_HTTPS_PORT` et `PROXY_FRONT_PORT`. 80 ne sert que la redirection et le défi ACME ; 4443 n'accepte que le PROXY protocol du frontal. Sur la VM, tous sur `127.0.0.1` |
+| Frontal SNI de la VM | `80` et `443` de l'hôte | `infra/front`, seul composant exposé sur le réseau de l'école (ADR 0018) |
 | SSH du serveur | `22` par défaut | `ssh_port`, redéfinissable |
 | Base applicative | `enervision` | Variable `POSTGRES_DB` |
 | Base de test | `enervision_test` | Créée par `db/init/110-test-database.sql`, nom attendu en dur par `apps/backend/tests/conftest.py` |
 | Base de métadonnées Airflow | `airflow` | Créée par `db/init/120-airflow-database.sql`, même conteneur `db` |
+| Grafana, Prometheus, Alertmanager | `3001`, `9090`, `9093` | Sur `127.0.0.1` seulement, profil `monitoring`. `GRAFANA_PORT`, `PROMETHEUS_PORT`, `ALERTMANAGER_PORT`. 3000 est pris par le frontend |
 | API server Airflow | `8080` | `make airflow-up`. Api-server, scheduler et dag-processor ne publient que ce port ; les tâches (`LocalExecutor`) tournent côté scheduler, sans port propre |

 ## Le trou vers k3s
@@ -103,7 +103,7 @@ démarre ne prouve rien sur la base, la première connexion réelle a lieu au pr
 | `APP_LOGIN_MAX_FAILURES_PER_IDENTIFIER` | `50` | Signature d'une attaque distribuée |
 | `APP_TRUST_PROXY_HEADERS` | `false` | À vrai derrière un proxy, sinon le compteur par IP devient global |
 | `APP_EXPOSE_API_DOCS` | déduit | Faux en `staging` et `prod` si non renseigné |
-| `APP_METRICS_TOKEN` | absent | Si présent, `/metrics` exige `Authorization: Bearer` |
+| `APP_METRICS_TOKEN` | absent | Si présent et non vide, `/metrics` exige `Authorization: Bearer`. Vide vaut absent |

 Cinq gardes refusent de démarrer plutôt que de laisser passer une erreur silencieuse :
 secret de moins de 32 caractères ou laissé à sa valeur d'exemple, `debug` en `staging` ou
@@ -235,7 +235,7 @@ n'ajoute rien.
 | Métrique | Ce qu'elle dit |
 |---|---|
 | `mae` | Erreur moyenne en kWh, la métrique même qu'optimise LightGBM |
-| `bias` | Erreur moyenne **signée** : c'est elle qui distingue un modèle plus bruyant d'un modèle qui se trompe systématiquement du même côté |
+| `bias` | Erreur moyenne **signée** : c'est elle qui distingue un modèle plus bruyant d'un modèle qui se trompe systématiquement du même côté. Lue et servie, elle ne fait basculer le verdict que sous `--bias-threshold`, faute d'un seuil en kWh transposable d'un site à l'autre ([ADR 0013](../adr/0013-surveillance-de-derive-dans-le-backend.md)) |
 | `mape` | Comparable entre sites de tailles différentes, hors réalisés nuls |
 | `coverage_ratio` | Part des prévisions disponibles qui ont trouvé leur réalisé : mesure le pipeline, pas le modèle |
 | `insufficient_data_ratio` | Part des sites privés d'historique suffisant |
@@ -246,7 +246,7 @@ d'observations, le service dit qu'il ne sait pas plutôt que de rendre un chiffr
 fenêtre est fermée à droite par un délai de grâce de 2 h, le temps que l'ingestion livre le
 réalisé de la dernière heure. `python -m app.monitoring.drift` l'exécute, le DAG `derive`
 l'ordonnance, et `GET /api/v1/monitoring/drift` sert le dernier rapport de chaque site. Les
-arbitrages sont dans l'[ADR 0011](../adr/0011-surveillance-de-derive-dans-le-backend.md).
+arbitrages sont dans l'[ADR 0013](../adr/0013-surveillance-de-derive-dans-le-backend.md).

 ### Détection d'alertes internes

@@ -356,8 +356,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.
@@ -421,8 +423,13 @@ Le reste, par ordre de surface :
  écriture des journaux. C'est la troisième ligne de défense : la première est de ne rien passer
  de secret au logger, la deuxième de ne jamais mettre un jeton dans une URL.
 - En-têtes posés par l'application : `X-Content-Type-Options`, `X-Frame-Options`,
-  `Referrer-Policy`, plus `Cache-Control: no-store` sur `/auth/*`. HSTS et CSP appartiennent au
-  terminateur TLS, que l'application ne connaît pas : le reverse proxy les pose
+  `Referrer-Policy`, `Cross-Origin-Resource-Policy: same-origin`, plus `Cache-Control: no-store`
+  sur `/auth/*`. Le CORP est fixé à `same-origin` parce qu'aucun client légitime ne charge l'API
+  en `no-cors` (image, script, média) depuis une autre origine : le frontend l'appelle en relatif
+  (`/api/v1`), sur sa propre origine, via `proxy.conf.json` en dev et le reverse proxy nginx
+  (`infra/proxy/conf.d/enervision.conf`) en recette et en production. Les appels `HttpClient`, en
+  mode `cors`, n'y sont de toute façon pas soumis. HSTS et CSP appartiennent au terminateur TLS, que
+  l'application ne connaît pas : le reverse proxy les pose
  ([ADR 0007](../adr/0007-terminaison-tls-et-reverse-proxy-nginx.md)).
 - Le conteneur tourne en utilisateur non-root, avec un `HEALTHCHECK` sur `/api/v1/health/live`.
 - TLS, limitation de débit au frontal et journal d'accès sont portés par le reverse proxy.
@@ -433,7 +440,17 @@ Le reste, par ordre de surface :

 - Journalisation par `dictConfig` : format console en développement, JSON dès `APP_ENV=prod`.
  `sqlalchemy.engine` est forcé à `WARNING` pour ne pas noyer les journaux.
- `/metrics` au format Prometheus. **Aucun collecteur ne le lit** : `monitoring/` est vide.
+- `/metrics` au format Prometheus (`prometheus-fastapi-instrumentator`), scruté toutes les 15 s
+  par Prometheus sous le profil `monitoring` ([60-observabilite.md](60-observabilite.md)).
+  - **Séries publiées.** `http_requests_total` par route, méthode et classe de statut, et
+    `http_request_duration_seconds` par route, avec des seaux de 50 ms à 2,5 s autour du seuil
+    de charge de 500 ms (ADR 0015). Aussi `http_request_duration_highr_seconds`, fin mais sans
+    libellé de route, et les métriques du processus.
+  - **Exclusions.** Les sondes `/health/*` et `/metrics` lui-même sont exclus : la sonde Docker
+    de 30 s fausserait débit et latences.
+  - **Un registre par application** (`_registre_de_metriques()` dans `main.py`). Le registre
+    global de `prometheus_client` n'accepte chaque métrique qu'une fois : toute application créée
+    après la première, dans les tests notamment, ne mesurait rien.

 ## Tests

@@ -289,6 +289,10 @@ Chaque table remplit un rôle précis dans le traitement et l'exploitation des d
 | `recommendation` | Proposer des actions et expliquer la règle qui les motive | Règles métier d'EnerVision |
 | `drift_report` | Suivre l'écart entre prévisions et réalisé, par site et tous sites confondus | Surveillance de dérive 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.
@@ -297,7 +301,7 @@ Les lignes de `drift_report` sont écrites par `app.monitoring.drift`, ordonnanc
 `derive`. Une ligne dont le `site_id` est `NULL` porte le résultat global, tous sites confondus :
 c'est pourquoi l'unicité passe par un index sur `coalesce(site_id, '')` et non par une contrainte,
 qui ne dédoublonnerait jamais deux lignes globales. Le calcul, ses seuils et ce qu'il refuse de
-comparer sont dans l'[ADR 0011](../adr/0011-surveillance-de-derive-dans-le-backend.md).
+comparer sont dans l'[ADR 0013](../adr/0013-surveillance-de-derive-dans-le-backend.md).

 Les lignes de `recommendation` sont écrites par le moteur de règles du backend
 (`app/services/recommendation_rules.py`), déclenché par `POST /api/v1/recommendations/generate`,
@@ -10,8 +10,9 @@ vérifié, ce qui bloque, et ce qui ne l'est pas.

 Le **D** de CI/CD est écrit depuis le 21/09 : `deploy.yml` déploie `dev` en recette et `main` en
 production sur la VM de l'école, par un runner auto-hébergé (issue #21,
-[ADR 0009](../adr/0009-deux-environnements-compose-sur-la-vm-eni.md)). Il n'a encore rien
-déployé : la machine n'est pas provisionnée et le runner n'y est pas enregistré. Statut à
+[ADR 0009](../adr/0009-deux-environnements-compose-sur-la-vm-eni.md)). Depuis le 23/09, il ne part
+plus qu'une fois la CI du commit verte ([ADR 0014](../adr/0014-pipeline-ci-unique-et-deploiement-conditionne.md)).
+Il n'a encore rien déployé : le runner n'est pas enregistré sur la machine. Statut à
 basculer sur `Fait` au premier déploiement vert. Sa limite, nommée ici plutôt que découverte en
 soutenance : les images sont construites sur la machine à chaque déploiement, aucun artefact
 n'est publié puis promu d'un environnement à l'autre.
@@ -24,82 +25,67 @@ GitHub Actions déploie ; aucun des deux ne fait le travail de l'autre.

 ## Vue d'ensemble

+`ci.yml` est le seul point d'entrée des PR et des push sur `dev` et `main`. Il appelle les
+workflows de composant, qui n'ont plus de déclencheur propre, selon les fichiers modifiés
+([ADR 0014](../adr/0014-pipeline-ci-unique-et-deploiement-conditionne.md)).
+
 ```mermaid
 flowchart TB
-  push["push ou pull_request"]
+  evt["pull_request, ou push sur dev et main"]
+  changes["changes<br/>paths-filter : composants touchés"]

-  subgraph back["Backend · .github/workflows/backend.yml"]
-    bv["verification<br/>ruff, mypy, pytest --cov-fail-under=85"]
-    bi["integration<br/>TimescaleDB réel + alembic upgrade head"]
-    bd["security-audit<br/>uv export | pip-audit"]
-    bs["sast<br/>bandit"]
+  subgraph comp["Workflows de composant (workflow_call)"]
+    back["backend.yml<br/>lint, typage, tests ≥ 85 %, intégration, pip-audit, bandit"]
+    front["frontend.yml<br/>build et tests, npm audit"]
+    mlw["ml.yml<br/>lint, typage, tests, ML ↔ DB, chaîne ML → API, bandit"]
+    afw["airflow.yml<br/>intégrité des DAGs, image"]
+    infw["infra.yml<br/>Terraform, Compose et supervision, actionlint"]
+    e2e["e2e.yml<br/>stack de prod, Playwright, k6 smoke et limitation"]
  end

-  subgraph front["Frontend · frontend.yml"]
-    fb["build<br/>npm ci, npm run build"]
-    ft["test<br/>couverture lcov"]
-    fd["security-audit<br/>npm audit --audit-level=high"]
-  end
+  sonar["sonar<br/>reprend les couvertures du run"]
+  ok["CI ok<br/>seul check à exiger"]
+  dep["deploy.yml<br/>runner eni-g3, rec ou prod"]

-  subgraph mlw["ML · ml.yml"]
-    mv["verification<br/>ruff, mypy, pytest"]
-    ms["sast<br/>bandit"]
-  end
+  evt --> changes --> back & front & mlw & afw & infw & e2e
+  back & front & mlw --> sonar
+  back & front & mlw & afw & infw & e2e & sonar --> ok
+  ok -->|"push sur dev ou main"| dep

-  subgraph afw["Airflow · airflow.yml"]
-    av["verification<br/>ruff, intégrité des DAGs"]
-    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"]
-    sb3["test-ml"]
-    sscan["sonarqube<br/>quality gate SonarCloud"]
-  end
-
-  push --> bv & bi & bd & bs
-  push --> fb --> ft
-  push --> fd
-  push --> mv & ms
-  push --> av & ab
-  push --> it
-  push --> sb1 & sb2 --> 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, à la main,<br/>ou PR sur ses fichiers"]
+  dast["dast.yml<br/>seed + scan actif OWASP ZAP"]
+  planifie --> dast
 ```

 ## Déclenchement

-Les six workflows hébergés par GitHub se déclenchent sur `push` **et** sur `pull_request`,
-filtrés par **chemin** : `backend.yml` sur `apps/backend/**`, `frontend.yml` sur
-`apps/frontend/**`, `ml.yml` sur `ml/**`, `infra.yml` sur `infra/terraform/**`, `airflow.yml` sur
-`etl/airflow/**` **plus des chemins de `ml/` et de `apps/backend/`**, chacun incluant son propre
-fichier de workflow dans le filtre pour qu'une modification du pipeline déclenche le pipeline.
+**Sur une PR**, le job `changes` lit la liste des fichiers modifiés par l'API GitHub
+(`dorny/paths-filter`, épinglé sur un SHA) et chaque composant n'est appelé que si son filtre
+vaut vrai. Une PR de documentation ne joue que `changes` et `CI ok`. Modifier `ci.yml` rejoue
+tout.

-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
-`apps/backend/app/**` parce que l'image Airflow copie le code et les dépendances des deux
-modules : celles du ML pour `ml_train`/`ml_score`, celles du backend depuis que le DAG `alertes`
-y exécute les commandes de détection ([ADR 0008](../adr/0008-airflow-execute-le-code-du-backend.md)).
-Une modification de l'un ou l'autre peut donc casser la construction de cette image, et le filtre
-le voit.
+**Sur un push vers `dev` ou `main`**, tous les filtres valent vrai. C'est le moment où l'analyse
+Sonar doit couvrir tout le dépôt, et paths-filter comparerait sinon le push à sa base de fusion
+avec `main`, en retard de 80 commits. Une branche de travail ne déclenche plus rien par un push :
+la CI part de sa PR, une seule fois par commit.

-**Piège à connaître** : il n'y a **aucun filtre de branche**. Une branche de travail déclenche la
-CI complète à chaque push, et un merge vers n'importe quelle branche la déclenche aussi. C'est
-délibéré pendant le projet (retour au plus tôt, et la CI tournera sur `main` dès la remontée sans
-rien changer), mais ce serait à borner sur un dépôt à forte fréquence de push.
+Deux filtres écoutent plus que leur dossier, parce que ce qu'ils testent dépend d'autres modules :

-`backend.yml`, `ml.yml` et `airflow.yml` déclarent en plus un groupe de concurrence par référence
-git avec `cancel-in-progress`, ce qui annule un run devenu obsolète par un push plus récent.
+- `airflow` inclut `ml/pyproject.toml`, `ml/uv.lock`, `ml/enervision_ml/**`,
+  `apps/backend/pyproject.toml`, `apps/backend/uv.lock` et `apps/backend/app/**`. L'image
+  Airflow copie le code et les dépendances des deux modules
+  ([ADR 0008](../adr/0008-airflow-execute-le-code-du-backend.md)), et une modification de l'un
+  ou de l'autre peut casser sa construction.
+- `e2e` inclut le frontend, l'API, ses migrations et son Dockerfile, le proxy, les fichiers
+  Compose, `db/`, `tests/` et les scripts qu'il appelle : tout ce qui change un parcours.
+
+`dast.yml` reste hors de l'orchestrateur : un scan actif est trop long pour chaque PR. Il se
+lance à la main, chaque lundi, et sur une PR qui modifie le scan, son jeu de données ou ses
+comptes.
+
+Le groupe de concurrence de `ci.yml` annule le run d'une PR devenu obsolète par un push plus
+récent. Pour un push sur `dev` ou `main`, le groupe est le SHA et rien n'est annulé : un run
+coupé en plein `make stack-up` laisserait la stack à moitié redémarrée.

 **Piège de version** : `etl/airflow` tourne en **Python 3.12** et non 3.14 : c'est l'interpréteur
 de l'image `apache/airflow:3.3.2-python3.12` retenue, et les tests d'intégrité doivent tourner sur
@@ -108,34 +94,52 @@ environnement.

 ## Déploiement

-`deploy.yml` est le septième workflow, et le seul qui ne tourne pas chez GitHub : il s'exécute sur
-un runner auto-hébergé installé sur la VM ENI, label `eni-g3`, parce que les runners hébergés ne
-joignent pas une adresse privée d'école. Le runner se connecte en sortie vers GitHub, aucun port
-entrant n'est ouvert.
+`deploy.yml` est le seul workflow 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. Il n'a pas de déclencheur propre en dehors de `workflow_dispatch` : c'est le job
+`deploy` de `ci.yml` qui l'appelle, sur un push, une fois « CI ok » vert.

 | Événement | Environnement GitHub | Dossier sur la VM | Garde |
 |---|---|---|---|
-| `push` sur `dev` | `rec` | `/srv/enervision/rec` | aucune : la recette suit `dev` |
-| `push` sur `main` | `prod` | `/srv/enervision/prod` | approbation d'un relecteur dans l'environnement `prod`, branche `main` seule autorisée |
+| `push` sur `dev`, « CI ok » vert | `rec` | `/srv/enervision/rec` | aucune de plus : la recette suit `dev` |
+| `push` sur `main`, « CI ok » vert | `prod` | `/srv/enervision/prod` | approbation d'un relecteur dans l'environnement `prod`, branche `main` seule autorisée |
+| `workflow_dispatch` sur toute autre branche | `dev` | `/srv/enervision/dev` | droit d'écriture sur le dépôt, seul à pouvoir lancer un workflow ([ADR 0017](../adr/0017-environnement-dev-a-la-demande.md)) |

-Le job aligne le clone sur la branche (`fetch`, `checkout`, `reset --hard`), lance
+Le job aligne le clone sur **le commit testé** (`fetch`, `checkout`, `reset --hard $GITHUB_SHA`),
+et non sur la pointe de branche du moment, qui a pu avancer pendant la CI. Il lance
 `make stack-up`, qui reconstruit les images, redémarre les conteneurs puis applique les
 migrations Alembic dans le conteneur backend, et attend jusqu'à trois minutes que
 `/api/v1/health/ready` réponde derrière le proxy. Cette sonde ne vérifie que la connexion à la
 base et la présence de TimescaleDB : sans la migration, le déploiement serait vert sur une base
-sans schéma, et c'est pourquoi `make stack-up` la porte. Un groupe de concurrence par branche,
-sans annulation, empêche deux déploiements simultanés du même environnement.
+sans schéma, et c'est pourquoi `make stack-up` la porte.
+
+Les CI de deux push rapprochés peuvent finir dans le désordre. Deux gardes empêchent un
+environnement de reculer ou de sauter un commit :
+
+- un commit qui **précède** celui déjà déployé depuis la même branche est ignoré, avec une
+  annotation dans le run. Dans `dev`, une autre branche que celle en place est toujours déployée ;
+- les déploiements d'un même environnement passent un par un sous un verrou `flock` posé dans le
+  clone de la VM, y compris deux branches lancées coup sur coup dans `dev`. Un groupe
+  `concurrency` ne convenait pas : GitHub n'y garde qu'un job en attente, et un troisième arrivé
+  l'annule sans erreur.

 Le job ne fait pas de `actions/checkout` dans son espace de travail, et c'est voulu : le dossier
 de l'environnement est stable, hors du runner, parce que `.env`, certificats et volumes doivent
 survivre d'un déploiement à l'autre.

 **Piège à connaître.** Un runner auto-hébergé sur un dépôt public exécute ce qu'un workflow lui
-envoie, et une PR de fork peut réécrire un workflow. Trois parades, et les trois sont
-nécessaires : `deploy.yml` ne se déclenche jamais sur `pull_request` ; le runner tourne sous un
-utilisateur dédié membre du groupe `docker`, jamais root ; le dépôt doit exiger une approbation
-pour les workflows des PR externes (Settings, Actions, « Require approval for all outside
-collaborators »), ce qui reste à activer. Les workflows de CI restent sur `ubuntu-latest`.
+envoie, et une PR de fork peut ajouter son propre workflow qui vise le label `eni-g3`. L'absence
+de `pull_request` dans `deploy.yml` ne suffit donc pas. Ce qui protège vraiment le runner :
+
+- le dépôt exige l'approbation des workflows de tous les contributeurs externes (Settings,
+  Actions, « Require approval for all external contributors ») ;
+- les environnements `rec` et `prod` n'acceptent que leur branche (`dev`, `main` avec un
+  relecteur), ce qui bloque un job qui les déclare avant qu'il atteigne le runner ;
+- le runner tourne sous un utilisateur dédié membre du groupe `docker`, jamais root.
+
+Les deux réglages de dépôt restent à activer par l'administratrice. Tous les autres workflows
+restent sur `ubuntu-latest`.

 Cet utilisateur dédié doit posséder `/srv/enervision` : sinon git refuse les deux clones pour
 propriété douteuse et le `.env` en `600` lui échappe. `PROPRIETAIRE=<utilisateur du runner>`
@@ -143,7 +147,7 @@ passé à `scripts/provision-host.sh` fixe ce propriétaire.

 La machine se prépare avec `scripts/provision-host.sh`, qui vérifie Docker et Compose 2.24.4 ou
 plus, clone les deux branches, génère les secrets de chaque `.env` et les certificats
-auto-signés, et ne démarre rien. Le détail des deux environnements, ports et noms d'hôte, est
+auto-signés, et ne démarre rien. Le détail des trois environnements, ports et noms d'hôte, est
 dans [10-infra.md](10-infra.md).

 ## Ce qui bloque un merge
@@ -165,6 +169,14 @@ dans [10-infra.md](10-infra.md).
 | 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 |
+| Verrous uv à jour | backend, ml, airflow | `uv sync --locked` : un `uv.lock` qui ne suit plus `pyproject.toml` échoue | Bloque |
+| Fichiers Compose | infra | `docker compose config` sur la stack de dev et la stack déployée, tous profils | Bloque |
+| Supervision | infra | `promtool check config`, `promtool test rules` (un cas par alerte), `amtool check-config`, JSON des tableaux | Bloque |
+| Workflows | infra | `actionlint`, shellcheck compris sur les blocs `run:` | Bloque |
+| Parcours de bout en bout | e2e | 18 parcours Playwright contre la stack de prod (proxy TLS) | Bloque |
+| Tir k6 de fumée | e2e | p95 < 500 ms et p99 < 1 s sur les lectures, moins de 1 % d'échecs | Bloque |
+| Limitation de débit | e2e | k6 par le proxy : des 429 au-delà de 20 req/s, aucune 5xx | Bloque |
+| **CI ok** | ci.yml | aucun job en `failure` ou `cancelled` | Bloque, **seul check à exiger** |

 Deux seuils portent une décision qu'il faut savoir défendre :

@@ -195,12 +207,42 @@ avant `alembic upgrade head`.
 La couverture est **désactivée** sur ce job (`pytest -m integration --no-cov`) : il ne joue qu'une
 partie de la suite, et son taux n'aurait aucun sens face au seuil de 85 %.

+### Pourquoi le job d'intégration ML installe aussi le backend
+
+Le schéma de la base n'a qu'une source, les six révisions Alembic de `apps/backend/alembic` : le
+backend est propriétaire du schéma, `ml/` n'en est que consommateur. Reconstruire ce schéma à la
+main dans le job ML donnerait un job vert sur une base qui n'est pas la nôtre, exactement l'erreur
+qu'évite déjà le choix de l'image `timescaledb-ha` plutôt qu'un `postgres` nu. Le job installe
+donc les deux environnements uv, applique `alembic upgrade head`, puis joue `-m integration` côté
+`ml/` et `-m chaine` côté backend.
+
+Conséquence sur le déclenchement : le filtre `ml` de `ci.yml` inclut `apps/backend/alembic/**` et
+`apps/backend/app/models/**`. Sans eux, une migration qui renomme une colonne de `reading` ne
+déclencherait pas ce job, le SQL brut du pipeline dériverait du schéma, et **rien ne casserait
+avant la production**. Le prix est qu'une PR touchant seulement une migration lance aussi le lint
+et le typage de `ml/` : environ deux minutes de runner, en parallèle. Même arbitrage que le filtre
+d'`airflow.yml`, qui écoute déjà `ml/**` et `apps/backend/app/**` parce que son image réunit les
+deux.
+
+Le marqueur `chaine` est distinct d'`integration` pour une raison mécanique : le job `integration`
+de `backend.yml` n'installe pas `ml/.venv`, et sélectionnerait sinon un test qui lance les
+binaires du pipeline. Il est aussi exclu d'`addopts`, sans quoi `make test` échouerait sur tout
+poste où `ml/` n'est pas installé.
+
 ## SonarCloud, et l'incident qui a immobilisé trois PR

-Le workflow `sonarqube.yml` exécute cinq jobs de préparation (`build-front`, `test-front`,
-`build-back`, `test-back`, `test-ml`) dont les tests produisent chacun un rapport de couverture en
-artefact, puis un dernier job qui les télécharge et lance `SonarSource/sonarqube-scan-action@v8`
-avec le secret `SONAR_TOKEN`. Le périmètre est décrit par `sonar-project.properties` à la racine.
+Le job `sonar` de `ci.yml` ne reconstruit ni ne reteste rien. Les jobs `verification` de
+`backend.yml`, `ml.yml` et `frontend.yml` versent leur rapport de couverture en artefact, et
+`sonar` les télécharge dans le même run, un par un (backend et ML nomment tous deux le leur
+`coverage.xml`), puis lance `SonarSource/sonarqube-scan-action`, épinglée sur un SHA, avec le
+secret `SONAR_TOKEN`. Il ne tourne ni pour Dependabot ni pour une PR de fork, qui n'ont pas ce
+secret. Le périmètre est décrit par `sonar-project.properties` à la racine, seul fichier de
+configuration Sonar du dépôt.
+
+Jusqu'au 23/09, un `sonarqube.yml` à part rejouait build et tests des trois modules pour produire
+ces rapports, en double exact des workflows qui le faisaient déjà. Les exclusions de
+`sonar-project.properties` sont aussi passées en globs (`**/tests/**`, `**/alembic/**`) : un
+motif sans `**` ne vise que la racine du dépôt.

 Le périmètre couvre `apps/frontend`, `apps/backend`, `ml/` et `etl/airflow` (les deux derniers
 ajoutés après coup : ils n'étaient pas analysés, une PR qui ne touchait qu'eux ne lançait pas
@@ -225,9 +267,10 @@ contournée** en désactivant la gate ou en excluant les fichiers gênants.

 ## Dependabot

-`.github/dependabot.yml` déclare **six entrées hebdomadaires groupées, sur cinq écosystèmes** :
-`npm` sur `/apps/frontend`, `uv` sur `/apps/backend`, `github-actions` sur `/`, `docker` sur les
-deux dossiers d'application, et `docker-compose` sur `/`. Les mises à jour arrivent en PR, donc
+`.github/dependabot.yml` déclare **sept entrées hebdomadaires, sur cinq écosystèmes** : `npm`
+sur `/apps/frontend` et sur `/tests/e2e`, `uv` sur `/apps/backend`, `github-actions` sur `/`,
+`docker` sur les deux dossiers d'application, et `docker-compose` sur `/`, qui suit aussi les
+images de supervision et de k6. Les mises à jour arrivent en PR, donc
 elles traversent les mêmes gates que n'importe quel changement : une montée de version qui casse
 les tests ne se merge pas.

@@ -256,37 +299,134 @@ 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.

-### Pourquoi le job d'intégration ML installe aussi le backend
+## Scan DAST (OWASP ZAP)

-Le schéma de la base n'a qu'une source, les six révisions Alembic de `apps/backend/alembic` : le
-backend est propriétaire du schéma, `ml/` n'en est que consommateur. Reconstruire ce schéma à la
-main dans le job ML donnerait un job vert sur une base qui n'est pas la nôtre, exactement l'erreur
-qu'évite déjà le choix de l'image `timescaledb-ha` plutôt qu'un `postgres` nu. Le job installe
-donc les deux environnements uv, applique `alembic upgrade head`, puis joue `-m integration` côté
-`ml/` et `-m chaine` côté backend.
+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.

-Conséquence sur le déclenchement : les `paths` de `ml.yml` incluent `apps/backend/alembic/**` et
-`apps/backend/app/models/**`. Sans eux, une migration qui renomme une colonne de `reading` ne
-déclencherait pas ce job, le SQL brut du pipeline dériverait du schéma, et **rien ne casserait
-avant la production**. Le prix est qu'une PR touchant seulement une migration lance aussi le lint
-et le typage de `ml/` : environ deux minutes de runner, en parallèle. Même arbitrage que le filtre
-d'`airflow.yml`, qui écoute déjà `ml/**` et `apps/backend/app/**` parce que son image réunit les
-deux.
+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 `db/seeds/demo.sql` (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` s'appuie sur `scripts/comptes-test.sh` pour
+créer les comptes et rend le jeton du **`lecteur`**. Le jeu et les comptes sont ceux de l'e2e.

-Le marqueur `chaine` est distinct d'`integration` pour une raison mécanique : le job `integration`
-de `backend.yml` n'installe pas `ml/.venv`, et sélectionnerait sinon un test qui lance les
-binaires du pipeline. Il est aussi exclu d'`addopts`, sans quoi `make test` échouerait sur tout
-poste où `ml/` n'est pas installé.
+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.
+
+## Tests de bout en bout et de charge
+
+Le workflow `e2e.yml` démarre la stack telle qu'elle est déployée, derrière le proxy TLS, sur
+`https://localhost` ([ADR 0015](../adr/0015-tests-e2e-et-de-charge-contre-la-stack-compose.md)) :
+
+1. Il construit et démarre `db`, `mailpit`, `backend`, `frontend` et `proxy` avec
+   `docker-compose.prod.yml`, sans Airflow. C'est le seul job qui construit les images backend et
+   frontend avant un déploiement.
+2. Il migre la base, pose le rôle `supervision`, sème `db/seeds/demo.sql` et crée les comptes
+   (`scripts/comptes-test.sh`).
+3. Il joue les 18 parcours Playwright de `tests/e2e`, sur un seul worker et avec une session par
+   fichier. Le rapport HTML et les traces du premier réessai sont versés en artefact.
+4. Il lance le tir k6 `smoke`, directement sur `backend:8000`, puis `limitation-debit` par le
+   proxy. Les synthèses s'affichent dans le résumé du job, et les rapports HTML sont versés en
+   artefact.
+
+La charge nominale (`make load-test`) et le stress (`make load-stress`) ne tournent pas en CI :
+voir `tests/load/README.md`.

 ## 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 |
-| 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 |
+| 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 |
+| Tir de charge nominal automatisé | #47 | Seul le smoke tourne en CI ; la charge à 50 utilisateurs se lance à la main en recette (`make load-test`), rec et prod partageant la VM |
+| Cache de couches Docker en CI | aucune | Le job E2E reconstruit les images backend et frontend à chaque run, deux à quatre minutes de plus |
+| Scan d'image de conteneur | aucune | Les images sont construites par le job E2E, pas analysées |

 ## Reproduire la CI en local

@@ -303,6 +443,14 @@ make ml-test-integration    # pipeline ML, marqueur `integration`
 make test-chaine            # vrais binaires ML puis relecture par l'API, marqueur `chaine`
 ```

+Les autres jobs se rejouent aussi sur le poste :
+
+```bash
+make e2e-prepare e2e        # parcours Playwright contre `make dev` (tests/e2e/README.md)
+make load-smoke K6_EMAIL=... K6_PASSWORD=...   # tir k6 d'une minute (tests/load/README.md)
+make monitoring-check       # promtool, amtool et JSON des tableaux de bord, comme le job Infra
+```
+
 Le SAST se rejoue à l'identique : `uvx bandit==1.9.4 --recursive app --severity-level medium
 --confidence-level medium` depuis `apps/backend`, et la même commande sur `enervision_ml` depuis
 `ml`.
@@ -0,0 +1,113 @@
+# Observabilité
+
+Ce document décrit ce qu'on voit du système en fonctionnement : métriques, tableaux de bord,
+alertes et journaux. Décision dans l'[ADR 0016](../adr/0016-supervision-en-profil-compose.md),
+mode d'emploi dans [`monitoring/README.md`](../../monitoring/README.md).
+
+| Brique | Sert à | Statut |
+|---|---|---|
+| Métriques de l'API | Débit, erreurs et latences par route | `Fait` |
+| Collecte et alertes | Prometheus, neuf règles testées, Alertmanager vers Mailpit | `Fait` |
+| Tableaux de bord | Grafana : API, données et modèle, infrastructure | `Fait` |
+| Métriques d'Airflow | StatsD ou OpenTelemetry des DAGs | `Cible` |
+| Journaux centralisés | Loki ou équivalent | `Cible` |
+
+## Vue d'ensemble
+
+```mermaid
+flowchart LR
+  subgraph projet["Projet Compose de la prod"]
+    api["backend<br/>/metrics"]
+    db[("db<br/>TimescaleDB")]
+    mail["mailpit"]
+
+    subgraph sup["Profil monitoring"]
+      prom["prometheus<br/>15 s, 15 jours"]
+      am["alertmanager"]
+      graf["grafana"]
+      pge["postgres-exporter"]
+      node["node-exporter"]
+      cad["cadvisor"]
+    end
+  end
+
+  hote["Hôte : VM ENI<br/>recette et prod"]
+
+  prom -->|"Bearer APP_METRICS_TOKEN"| api
+  prom --> pge & node & cad
+  pge -->|"rôle supervision"| db
+  node -.->|"/proc, /sys"| hote
+  cad -.->|"cgroups"| hote
+  prom -->|"règles franchies"| am -->|"SMTP"| mail
+  graf --> prom
+  graf -->|"rôle supervision, SQL"| db
+```
+
+Tout vit dans le projet Compose de la prod, sur son réseau. La recette n'a pas de supervision
+propre. node-exporter et cAdvisor voient pourtant tout l'hôte : la mémoire de la VM et de chaque
+conteneur couvre donc aussi la recette, qu'on distingue au préfixe `enervision-rec-`.
+
+## Ce que mesure chaque source
+
+| Source | Métriques utiles | Où les lire |
+|---|---|---|
+| API (`prometheus-fastapi-instrumentator`) | `http_requests_total` par route et classe de statut, `http_request_duration_seconds` par route (seaux 50 ms à 2,5 s), `http_request_duration_highr_seconds` global, mémoire du processus | Tableau « API » |
+| postgres-exporter | `pg_up`, connexions par état, `max_connections`, transactions validées, taille des bases | Tableau « Infrastructure » |
+| node-exporter | Processeur, mémoire disponible, espace disque de `/` | Tableau « Infrastructure » |
+| cAdvisor | Mémoire (`working_set`) et processeur par conteneur | Tableau « Infrastructure » |
+| TimescaleDB, en SQL | Fraîcheur des relevés par site, relevés ingérés par heure, alertes par sévérité, `drift_report` | Tableau « Données et modèle » |
+
+Deux choix de l'instrumentation se lisent dans ces courbes :
+
+- **Les sondes `/health/*` et `/metrics` ne sont pas comptées.** La sonde Docker frappe toutes
+  les 30 s : incluse, elle ferait baisser la latence moyenne et gonfler le débit d'une API au
+  repos.
+- **Les seaux par route encadrent 500 ms**, seuil de charge de l'ADR 0015. Grafana lit ainsi le
+  même p95 que k6 pendant un tir.
+
+## Alertes
+
+| Groupe | Alertes | Sévérité |
+|---|---|---|
+| API | Indisponible 2 min, 5xx au-delà de 5 %, p95 au-delà d'une seconde | critical, critical, warning |
+| Base | PostgreSQL injoignable 2 min, connexions au-delà de 80 % | critical, warning |
+| Hôte | Mémoire au-delà de 90 %, disque sous 10 %, processeur au-delà de 90 % | warning, critical, warning |
+| Supervision | Un exporteur muet 5 min | warning |
+
+- **Tests des règles.** Chaque règle a un cas dans `monitoring/prometheus/tests/`, joué par
+  `promtool test rules` dans le job Infra de la CI. Une règle qui ne se déclenche plus, ou se
+  déclenche à tort, casse la CI avant d'atteindre la prod.
+- **Envoi.** Alertmanager groupe les alertes par nom et sévérité et les envoie par courriel via
+  Mailpit, qui les capture sans rien relayer. Un `critical` est rappelé toutes les heures, un
+  `warning` toutes les douze. Un `critical` masque le `warning` de la même cible.
+
+## Sécurité
+
+- **Aucune interface exposée.** Prometheus, Alertmanager et Grafana n'écoutent que sur
+  `127.0.0.1`, et rien ne passe par le proxy (ADR 0007). Accès par tunnel SSH.
+- **`/metrics` gardé par jeton.** Il n'est pas routé par nginx, et Prometheus y présente
+  `APP_METRICS_TOKEN`, que l'API exige dès qu'il est posé. Le jeton lui parvient en secret
+  Compose, jamais en clair dans sa configuration.
+- **Base en lecture seule.** Grafana et postgres-exporter lisent la base par le rôle
+  `supervision`, en lecture seule, limité aux tables métier (`db/roles/supervision.sql`). Ils
+  n'ont ni `app_user`, ni jetons, ni journal d'audit.
+- **Grafana verrouillé.** Il refuse de démarrer sans `GRAFANA_ADMIN_PASSWORD`. Inscription,
+  accès anonyme et appels sortants (statistiques d'usage, vérification de mises à jour) y sont
+  désactivés.
+- **cAdvisor en `privileged`.** Il tourne ainsi pour lire les cgroups, avec des montages en
+  lecture seule et sans port publié.
+
+## Journaux
+
+Les journaux restent ceux de Docker : `docker compose logs`, `make stack-logs`,
+`make monitoring-logs`. L'API écrit du JSON dès `APP_ENV=prod`, caviardé des jetons et des mots
+de passe (voir [20-backend.md](20-backend.md)). Aucune agrégation centralisée n'est en place.
+
+## Ce qui manque
+
+| Manque | Conséquence assumée |
+|---|---|
+| Métriques d'Airflow (StatsD, OpenTelemetry) | Un DAG qui échoue ne se voit que dans Airflow ; le tableau « Données » le trahit indirectement par des relevés qui vieillissent |
+| Alerte sur la fraîcheur des relevés | Visible dans Grafana, mais aucune règle Prometheus ne la porte : il faudrait une métrique calculée par l'API ou un exportateur SQL |
+| Journaux centralisés | Un incident se diagnostique conteneur par conteneur |
+| Destinataire réel des alertes | Mailpit capture tout : les alertes se lisent dans son interface, elles ne réveillent personne |
@@ -15,12 +15,12 @@ contredisent, c'est l'ADR qui fait foi et la vue qui est en retard.
 | [31-contrat-authentification.md](31-contrat-authentification.md) | Ce que le frontend doit savoir pour coder la connexion |
 | [32-design-systeme-frontend.md](32-design-systeme-frontend.md) | Tokens CSS, composants `ev-*` partagés, règle anti-couleur-en-dur |
 | [40-data.md](40-data.md) | Frontières `db/` et `alembic/`, cycle de vie d'une mesure, modèle |
-| [50-cicd.md](50-cicd.md) | Workflows, gates bloquantes, SonarCloud, Dependabot, ce qui manque |
+| [50-cicd.md](50-cicd.md) | Orchestrateur `ci.yml`, gates bloquantes, e2e et charge, SonarCloud, Dependabot, ce qui manque |
+| [60-observabilite.md](60-observabilite.md) | Métriques, Prometheus, alertes, tableaux de bord Grafana, ce qui manque |

-La CI/CD a désormais son document : cinq workflows et seize jobs, c'est assez de matière pour
-qu'une section de plus dans une autre vue devienne illisible. L'observabilité, elle, n'en a
-toujours pas : `monitoring/` ne contient que des `.gitkeep`. Elle en sortira le jour où elle aura
-de la matière. Un fichier vide de plus n'aide personne.
+La CI/CD a son document : un orchestrateur et ses workflows de composant, c'est assez de
+matière pour qu'une section de plus dans une autre vue devienne illisible. L'observabilité a le
+sien depuis l'issue #26, qui lui a donné de la matière : collecte, alertes et tableaux de bord.

 L'orchestration Airflow, elle, en a depuis les issues #115 et #116 : trois DAGs, leur image et
 leurs contraintes sont décrits dans [10-infra.md](10-infra.md).
@@ -38,7 +38,8 @@ 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 |
-| En-têtes `nosniff`, `DENY`, `no-referrer`, et `no-store` sur les routes d'authentification | `app/api/middleware.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`, `Cross-Origin-Resource-Policy: same-origin`, 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 |
 | Réponse de l'API Mock bornée avant écriture : timeout, plafond de sites et de mesures, bornes physiques par grandeur, recopie des seuls champs attendus | `app/etl/mock_api_import.py` | API10 Unsafe Consumption of APIs |
@@ -663,16 +663,22 @@ mock_api_import.py

 La logique d'extraction, de transformation et de chargement est donc disponible pour les deux sources de données du MVP.

-Airflow tourne désormais réellement (`etl/airflow/`, `make airflow-up`) et orchestre le pipeline
-ML (`ml_train`/`ml_score`, issue #115), la détection d'alertes et la génération des
-recommandations (`alertes`, issue #116), ainsi que l'import historique
-(`historical_import`, issue #119).
+Airflow tourne désormais réellement (`etl/airflow/`, `make airflow-up`) et orchestre cinq DAGs :
+le pipeline ML (`ml_train` et `ml_score`, issue #115), la détection d'alertes et la génération
+des recommandations (`alertes`, issue #116), l'import historique (`historical_import`,
+issue #119) et l'import périodique de l'API Mock (`mock_api_import`, issue #15).

-Le DAG `historical_import` est déclenché manuellement. Il exécute
-`app.etl.historical_import` avec les fichiers montés en lecture seule depuis `data/raw` vers
-`/opt/data/raw`. L'orchestration de l'import API Mock et la réconciliation globale des deux
-sources restent couvertes par l'issue #15.
+Le DAG `mock_api_import` s'exécute chaque heure, à la minute `:45`. Il appelle
+`app.etl.mock_api_import` avec un intervalle explicite d'une heure et une limite de 1 000 lectures
+par site. Les deux pipelines normalisent leurs données vers les tables communes `site` et
+`reading`, tout en conservant leur source (`csv` ou `api_history`). La réconciliation globale
+des deux sources reste à compléter dans l'issue #15.

-Airflow permet de planifier les traitements, gérer leur ordre d'exécution, suivre leur état et remonter les erreurs. Il ne remplace pas la logique ETL Python existante : les scripts actuels restent responsables de l'extraction, de la validation, de la transformation et du chargement. `etl/airflow/dags/ml_train.py`, `ml_score.py` et `alertes.py` et `historical_import.py` montrent le patron retenu (des `BashOperator` qui invoquent le script tel quel, dans l'environnement `uv` que l'image embarque pour lui).
+Le DAG `mock_api_import` exécute `app.etl.mock_api_import` toutes les heures. Chaque exécution
+traite l'intervalle Airflow précédent. Les deux pipelines normalisent leurs données vers les
+tables communes `site` et `reading`, tout en conservant leur source (`csv` ou `api_history`).
+
+Airflow permet de planifier les traitements, gérer leur ordre d'exécution, suivre leur état et remonter les erreurs. Il ne remplace pas la logique ETL Python existante : les scripts actuels restent responsables de l'extraction, de la validation, de la transformation et du chargement. `etl/airflow/dags/ml_train.py`, `ml_score.py`, `alertes.py`, `historical_import.py` et
+`mock_api_import.py` montrent le patron retenu (des `BashOperator` qui invoquent le script tel quel, dans l'environnement `uv` que l'image embarque pour lui).

 Le pipeline Data servira ensuite à préparer les données nécessaires au modèle de Machine Learning.
@@ -0,0 +1,61 @@
+"""DAG d'import périodique des données de l'API Mock EnerVision (issue #15).
+
+Orchestre le pipeline existant `app.etl.mock_api_import` sans dupliquer sa logique ETL.
+Chaque exécution traite l'heure précédant son déclenchement.
+
+Le pipeline backend reste responsable de la validation, de la normalisation, du suivi de la
+qualité, de l'idempotence et du chargement dans PostgreSQL/TimescaleDB.
+"""
+
+from __future__ import annotations
+
+from datetime import datetime, timedelta
+
+from airflow.providers.standard.operators.bash import BashOperator
+from airflow.sdk import DAG
+from airflow.timetables.trigger import CronTriggerTimetable
+
+# Le backend possède son propre environnement uv dans l'image Airflow (ADR 0008).
+COMMANDE_BACKEND = "cd /opt/backend && env -u VIRTUAL_ENV uv run --no-sync python -m"
+
+# Le pipeline backend et l'API acceptent au maximum 1 000 lectures par site.
+# Cette marge évite de perdre silencieusement une lecture si une heure en contient plus de 60.
+LIMITE_LECTURES = 1000
+
+# Deux reprises donnent trois tentatives au total. Même dans le pire cas, l'exécution reste
+# inférieure au pas horaire du DAG.
+NOMBRE_REPRISES = 2
+DELAI_ENTRE_REPRISES = timedelta(minutes=2)
+PLAFOND_PAR_TENTATIVE = timedelta(minutes=10)
+
+# L'intervalle est déclaré explicitement pour ne pas dépendre de la valeur du paramètre Airflow
+# `create_cron_data_intervals`. Le déclenchement à :45 laisse quinze minutes avant `ml_score`,
+# exécuté à l'heure pile, puis avant `alertes`, exécuté à :15.
+PLANIFICATION = CronTriggerTimetable(
+    "45 * * * *",
+    timezone="UTC",
+    interval=timedelta(hours=1),
+)
+
+with DAG(
+    dag_id="mock_api_import",
+    description="Importe chaque heure les données de l'API Mock dans site et reading.",
+    schedule=PLANIFICATION,
+    start_date=datetime(2026, 1, 1),
+    catchup=False,
+    # Deux exécutions simultanées pourraient demander et traiter le même intervalle.
+    max_active_runs=1,
+    tags=["etl", "mock-api"],
+) as dag:
+    BashOperator(
+        task_id="import_mock_api",
+        bash_command=(
+            f"{COMMANDE_BACKEND} app.etl.mock_api_import "
+            "--start-time \"{{ data_interval_start.strftime('%Y-%m-%dT%H:%M:%S') }}\" "
+            "--end-time \"{{ data_interval_end.strftime('%Y-%m-%dT%H:%M:%S') }}\" "
+            f"--limit {LIMITE_LECTURES}"
+        ),
+        retries=NOMBRE_REPRISES,
+        retry_delay=DELAI_ENTRE_REPRISES,
+        execution_timeout=PLAFOND_PAR_TENTATIVE,
+    )
@@ -1,22 +1,31 @@
 """Tests d'integrite des DAGs : s'importent sans erreur, structure attendue. Pas d'execution
 reelle des taches (ca reclamerait le conteneur avec `uv`/`enervision_ml`), juste la definition."""

-from datetime import timedelta
+from datetime import datetime, timedelta
 from pathlib import Path

 import pytest
 from airflow.dag_processing.dagbag import DagBag
 from airflow.sdk import BaseOperator
+from airflow.timetables.trigger import CronTriggerTimetable

 DAGS_FOLDER = Path(__file__).resolve().parent.parent / "dags"

-DAG_IDS = ["ml_train", "ml_score", "alertes", "historical_import", "derive"]
+DAG_IDS = [
+    "ml_train",
+    "ml_score",
+    "alertes",
+    "historical_import",
+    "mock_api_import",
+    "derive",
+]
 TACHES = [
    ("ml_train", "train"),
    ("ml_score", "score"),
    ("alertes", "detection"),
    ("alertes", "recommandations"),
    ("historical_import", "import_historical"),
+    ("mock_api_import", "import_mock_api"),
    ("derive", "derive"),
 ]

@@ -53,6 +62,19 @@ def test_historical_import_has_no_schedule(dagbag: DagBag) -> None:
    assert dagbag.dags["historical_import"].schedule is None


+def test_mock_api_import_uses_an_explicit_hourly_interval(dagbag: DagBag) -> None:
+    timetable = dagbag.dags["mock_api_import"].timetable
+
+    assert isinstance(timetable, CronTriggerTimetable)
+    assert timetable.serialize()["expression"] == "45 * * * *"
+
+    manual_interval = timetable.infer_manual_data_interval(
+        run_after=datetime.fromisoformat("2026-09-22T12:30:00+00:00"),
+    )
+
+    assert manual_interval.end - manual_interval.start == timedelta(hours=1)
+
+
 def test_ml_train_task_calls_the_training_module(dagbag: DagBag) -> None:
    tache = dagbag.dags["ml_train"].get_task("train")
    assert "enervision_ml.train" in tache.bash_command
@@ -85,6 +107,20 @@ def test_historical_import_uses_the_expected_source_files(dagbag: DagBag) -> Non
    assert "--metadata /opt/data/raw/dataset_metadata.json" in commande


+def test_mock_api_import_calls_the_existing_backend_module(dagbag: DagBag) -> None:
+    commande = dagbag.dags["mock_api_import"].get_task("import_mock_api").bash_command
+
+    assert "app.etl.mock_api_import" in commande
+
+
+def test_mock_api_import_uses_the_airflow_data_interval(dagbag: DagBag) -> None:
+    commande = dagbag.dags["mock_api_import"].get_task("import_mock_api").bash_command
+
+    assert "--start-time \"{{ data_interval_start.strftime('%Y-%m-%dT%H:%M:%S') }}\"" in commande
+    assert "--end-time \"{{ data_interval_end.strftime('%Y-%m-%dT%H:%M:%S') }}\"" in commande
+    assert "--limit 1000" in commande
+
+
@pytest.mark.parametrize("task_id", ["detection", "recommandations"])
 def test_alertes_tasks_run_in_the_backend_environment(dagbag: DagBag, task_id: str) -> None:
    # Le backend a son propre venv dans l'image, distinct de celui de ml/ (ADR 0008).
@@ -96,6 +132,12 @@ def test_historical_import_runs_in_the_backend_environment(dagbag: DagBag) -> No
    assert "/opt/backend" in commande


+def test_mock_api_import_runs_in_the_backend_environment(dagbag: DagBag) -> None:
+    commande = dagbag.dags["mock_api_import"].get_task("import_mock_api").bash_command
+
+    assert "/opt/backend" in commande
+
+
 def test_alertes_generates_recommendations_after_detecting(dagbag: DagBag) -> None:
    # `recommendation.alert_id` est une cle etrangere `NOT NULL` : la generation n'a rien a lire
    # tant que la detection n'a pas ecrit.
@@ -137,6 +179,14 @@ def duree_au_pire(tache: BaseOperator) -> timedelta:
    return (tache.retries + 1) * tache.execution_timeout + tache.retries * tache.retry_delay


+def test_mock_api_import_worst_case_stays_below_its_hourly_step(
+    dagbag: DagBag,
+) -> None:
+    tache = dagbag.dags["mock_api_import"].get_task("import_mock_api")
+
+    assert duree_au_pire(tache) < timedelta(hours=1)
+
+
 def test_alertes_worst_case_stays_below_its_hourly_step(dagbag: DagBag) -> None:
    # Les deux taches s'enchainent : c'est leur somme, reprises comprises, qui doit tenir dans le
    # pas horaire, sinon `max_active_runs=1` fait attendre l'execution suivante.
@@ -160,6 +210,10 @@ def test_historical_import_retries_after_a_transient_failure(dagbag: DagBag) ->
    assert dagbag.dags["historical_import"].get_task("import_historical").retries >= 1


+def test_mock_api_import_retries_after_a_transient_failure(dagbag: DagBag) -> None:
+    assert dagbag.dags["mock_api_import"].get_task("import_mock_api").retries >= 1
+
+
 def test_derive_runs_once_a_day(dagbag: DagBag) -> None:
    assert dagbag.dags["derive"].timetable.expression == "30 5 * * *"

@@ -8,8 +8,9 @@ Rien ici ne construit d'image ni ne lance de conteneur.
  - `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/<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,
+  - `vm-eni` : la VM `eadl-2025-nantes-g3`, qui porte les environnements `dev`, `rec` et `prod`
+    ([ADR 0009](../docs/adr/0009-deux-environnements-compose-sur-la-vm-eni.md),
+    [ADR 0017](../docs/adr/0017-environnement-dev-a-la-demande.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.
@@ -32,9 +33,16 @@ terraform apply
  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`.
+Apres l'apply, la machine porte `/srv/enervision/dev`, `/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`, et a chaque lancement manuel d'une autre branche pour `dev`.
+
+Noms et certificats (ADR 0018) : avant l'apply, la zone `domaine` doit exister chez dynv6 et son
+jeton se trouver dans `<racine>/dns.token` (600, proprietaire). L'apply fait alors pointer la
+zone, `rec` et `dev` vers la machine, obtient un certificat Let's Encrypt par environnement et planifie leur
+renouvellement ; sans jeton, chaque environnement garde un certificat auto-signe. Le frontal SNI (`infra/front`)
+se demarre une fois depuis le dossier de la prod, `make front-up`.

 Retirer le runner se fait a la main, depuis les parametres du depot : `terraform destroy` ne le
 desinscrit pas.
@@ -0,0 +1,12 @@
+# Pourquoi : le réseau de l'hôte, parce que les trois stacks publient leur écouteur PROXY protocol
+# sur 127.0.0.1 et que seul un conteneur sur l'hôte joint cette boucle locale (ADR 0018).
+
+name: enervision-front
+
+services:
+  front:
+    image: nginx:1.31-alpine
+    network_mode: host
+    volumes:
+      - ./nginx.conf:/etc/nginx/nginx.conf:ro
+    restart: unless-stopped
@@ -0,0 +1,46 @@
+# Pourquoi : trois environnements sur une seule IP, des URL sans port (ADR 0018). Ce frontal lit
+# le nom demandé dans le ClientHello (SNI) et relaie le flux TLS intact vers le proxy de la
+# stack visée : il ne détient aucun certificat, chaque stack garde le sien et ses en-têtes.
+# Piège : relayé tel quel, le flux arriverait avec l'IP du frontal, et les limitations de débit
+# de nginx et du backend deviendraient globales. D'où `proxy_protocol on`, reçu sur l'écouteur
+# 4443 de chaque stack (infra/proxy/conf.d/enervision.conf), qui y restaure l'IP du client.
+# Contrainte : ces ports sont ceux que `scripts/provision-host.sh` donne à PROXY_FRONT_PORT.
+
+worker_processes auto;
+error_log /var/log/nginx/error.log warn;
+pid /var/run/nginx.pid;
+
+events {
+    worker_connections 1024;
+}
+
+stream {
+    log_format aiguillage '$remote_addr [$time_local] $ssl_preread_server_name '
+                          '-> $upstream_addr $status $session_time';
+    access_log /var/log/nginx/access.log aiguillage;
+
+    map $ssl_preread_server_name $stack {
+        ~^rec\.  127.0.0.1:8444;
+        ~^dev\.  127.0.0.1:9444;
+        default  127.0.0.1:10444;
+    }
+
+    server {
+        listen 443;
+        ssl_preread on;
+        proxy_pass $stack;
+        proxy_protocol on;
+        proxy_connect_timeout 5s;
+    }
+}
+
+http {
+    server_tokens off;
+    access_log off;
+
+    server {
+        listen 80 default_server;
+        server_name _;
+        return 301 https://$host$request_uri;
+    }
+}
@@ -76,8 +76,28 @@ Renouvellement, à passer en tâche planifiée sur la machine :
 17 3 * * * cd /srv/enervision && make tls-renew >> /var/log/enervision-tls.log 2>&1
 ```

-Pour un domaine sans port 80 entrant, le défi DNS-01 est l'alternative : elle demande un
-greffon certbot propre au fournisseur DNS et un jeton d'API, hors périmètre à ce jour.
+### Let's Encrypt par DNS-01, le mode de la VM
+
+La VM n'a qu'une IP privée : le défi HTTP-01 y est impossible. Ses trois noms sont chez dynv6,
+dont l'API pose l'enregistrement TXT du défi DNS-01, et acme.sh le fait sans rien ouvrir
+([ADR 0018](../../docs/adr/0018-noms-publics-certificats-dns01-et-frontal-sni.md)).
+
+```bash
+make tls-dns01          # PUBLIC_HOST lu dans .env, jeton dans ../dns.token (600)
+```
+
+Autre fournisseur : `DNS01_API` et `DNS01_JETON_VAR` nomment le greffon acme.sh et sa variable
+(`dns_cf` et `CF_Token` pour Cloudflare, par exemple). La cible est rejouable : acme.sh ne renouvelle qu'à trente jours de l'échéance, installe le
+résultat dans `tls/` et recharge le proxy s'il tourne. Son état vit dans `acme/`, ignoré par git.
+`deploy.yml` la rejoue avant chaque `make stack-up`, et `/etc/cron.d/enervision-tls` chaque nuit.
+
+## Écouteur PROXY protocol
+
+Sur la VM, le frontal `infra/front` relaie les connexions TLS sans les déchiffrer. Reçues sur
+443, elles porteraient son adresse, et `limit_req` comme `get_client_ip()` compteraient tous les
+postes comme un seul. Le port 4443 ne les accepte qu'avec l'en-tête PROXY protocol, d'où
+`real_ip_header proxy_protocol` tire l'IP du client ; seules les adresses des réseaux Docker ont
+le droit de l'annoncer, et le port n'est publié que sur `127.0.0.1` (`PROXY_FRONT_PORT`).

 ## Vérifier la configuration sans démarrer la stack

@@ -7,6 +7,8 @@
 # variable et le résolveur interne de Docker : la résolution redevient dynamique.
 # Pourquoi : la redirection 80 vers 443 conserve `$host` plutôt qu'un nom canonique, faute de
 # quoi l'accès par IP cesserait de fonctionner sur la cible. Risque acté dans l'ADR 0007.
+# Piège : 4443 n'accepte que le PROXY protocol du frontal (infra/front, ADR 0018), qui y porte
+# l'IP du client. Seules les adresses des réseaux Docker ont le droit de l'annoncer.

 server {
    listen 80 default_server;
@@ -23,9 +25,14 @@ server {

 server {
    listen 443 ssl default_server;
+    listen 4443 ssl proxy_protocol default_server;
    http2 on;
    server_name _;

+    set_real_ip_from 172.16.0.0/12;
+    set_real_ip_from 192.168.0.0/16;
+    real_ip_header proxy_protocol;
+
    resolver 127.0.0.11 valid=10s ipv6=off;

    ssl_certificate     /etc/nginx/tls/fullchain.pem;
@@ -6,7 +6,7 @@
 # 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.
+# Ref : ADR 0009 et 0017 pour les trois environnements, `scripts/provision-host.sh` pour leur contenu.

 locals {
  sudo           = var.ssh_user == "root" ? "" : "sudo "
@@ -57,9 +57,10 @@ resource "null_resource" "environnements" {
  depends_on = [null_resource.docker_engine]

  triggers = {
-    script = filesha256(local.provisionneur)
-    racine = var.racine
-    depot  = var.depot_url
+    script  = filesha256(local.provisionneur)
+    racine  = var.racine
+    depot   = var.depot_url
+    domaine = var.domaine
  }

  connection {
@@ -83,6 +84,7 @@ resource "null_resource" "environnements" {
        ${local.sudo}env RACINE='${var.racine}' \
          REPO_URL='${var.depot_url}' \
          PROPRIETAIRE='${var.proprietaire}' \
+          DOMAINE='${var.domaine}' \
          PUBLIC_IP='${var.adresse_publique}' \
          bash /tmp/provision-host.sh
        rm -f /tmp/provision-host.sh
@@ -1,6 +1,6 @@
 variable "ssh_host" {
  type        = string
-  description = "Adresse de la VM ENI qui porte les deux environnements (ADR 0009)."
+  description = "Adresse de la VM ENI qui porte les trois environnements (ADR 0009, ADR 0017)."
 }

 variable "ssh_port" {
@@ -43,6 +43,12 @@ variable "depot_url" {
  default     = "https://github.com/ineszang/ProjetPiscine_EnerVision.git"
 }

+variable "domaine" {
+  type        = string
+  description = "Zone dynv6 de la prod, rec. et dev. en sous-domaines (ADR 0018). Son jeton doit se trouver dans <racine>/dns.token sur la machine : provision-host.sh y fait pointer la zone et ses deux sous-domaines vers la machine."
+  default     = "enervision-g3.dynv6.net"
+}
+
 variable "adresse_publique" {
  type        = string
  description = "Adresse annoncee dans les certificats auto-signes. Vide : la premiere adresse de la VM."
@@ -0,0 +1,6 @@
+.venv
+data
+mlruns
+mlflow.db*
+models
+.env
@@ -0,0 +1 @@
+MLFLOW_DB_PASSWORD=change-me
@@ -0,0 +1,7 @@
+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,6 +57,50 @@ 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
@@ -83,6 +127,13 @@ 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.
@@ -0,0 +1,32 @@
+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:
@@ -43,8 +43,8 @@ NUMERIC_COLUMNS = [
    "capacity_kw",
 ]

-# Piege : `reading.is_working_hours` est nullable et entre dans les features. Une seule lecture a
-# NULL rend la colonne `object`, que LightGBM refuse ("pandas dtypes must be int, float or bool").
+# Piege : `is_working_hours` est nullable et entre dans les features. Toujours `float64`, jamais
+# `bool` : `astype(bool)` ferait un `True` d'une absence, et les deux chargeurs divergeraient.
 FLAG_COLUMNS = ["is_working_hours"]

 _READING_QUERY = text(
@@ -113,10 +113,15 @@ def load_recent_from_database(


 def load_from_csv(csv_path: Path) -> pd.DataFrame:
-    """Lit le jeu de donnees CSV historique (chemin de demarrage, hors base)."""
+    """Lit le jeu de donnees CSV historique (chemin de demarrage, hors base).
+
+    `is_working_hours` passe par `_typer` comme le chemin base, et non par un `astype(bool)` : le
+    fichier livre porte cette colonne en `0`/`1`, donc une case vide arrive en `NaN` et `astype`
+    la rendrait `True` sans rien signaler. Les deux chargeurs rendent ainsi le meme schema, ce que
+    `docs/ML-START.md` promet.
+    """
    frame = pd.read_csv(csv_path, parse_dates=["timestamp"])
    frame["capacity_kw"] = float("nan")
-    frame["is_working_hours"] = frame["is_working_hours"].astype(bool)

    return _typer(frame[OUTPUT_COLUMNS])

@@ -131,12 +136,18 @@ def _typer(frame: pd.DataFrame) -> pd.DataFrame:
    n'importe quelle autre colonne mesuree entierement absente sur une fenetre de scoring, pas
    seulement `capacity_kw`.

+    Les colonnes de `FLAG_COLUMNS` sont en outre ramenees a `float64` : ce sont des drapeaux
+    nullables, et c'est le seul dtype qui survive a l'absence sans inventer de valeur. Sans cela,
+    le meme chargeur rendrait `bool`, `int64` ou `float64` selon le contenu de la fenetre lue.
+
    Piege additionnel : `NUMERIC_COLUMNS` inclut `consumption_kwh`, la cible du modele, pas
    seulement des variables explicatives. Une valeur non numerique y devient donc silencieusement
    `NaN` aussi bien a l'entrainement (ou `train.py` l'exclura ensuite via son `dropna`) qu'au
    scoring -- ce n'est pas un effet de bord limite aux colonnes mesurees.
    """
    typee = frame.copy()
-    for colonne in (*NUMERIC_COLUMNS, *FLAG_COLUMNS):
+    for colonne in NUMERIC_COLUMNS:
        typee[colonne] = pd.to_numeric(typee[colonne], errors="coerce")
+    for colonne in FLAG_COLUMNS:
+        typee[colonne] = pd.to_numeric(typee[colonne], errors="coerce").astype("float64")
    return typee
@@ -181,7 +181,11 @@ 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")
+        mlflow.lightgbm.log_model(
+            booster,
+            name="model",
+            registered_model_name="consumption-forecast-lightgbm",
+        )
        mlflow.log_artifact(str(model_output))


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

 import pandas as pd
+import pytest

 from enervision_ml.data import NUMERIC_COLUMNS, load_from_csv

@@ -53,3 +54,44 @@ def test_load_from_csv_always_types_capacity_kw_as_float(tmp_path: Path) -> None

    assert frame["capacity_kw"].dtype == "float64"
    assert pd.isna(frame["capacity_kw"].iloc[0])
+
+
+@pytest.mark.parametrize("present", ["1", "True"], ids=["entier", "booleen_textuel"])
+def test_load_from_csv_keeps_a_missing_is_working_hours_as_nan(
+    tmp_path: Path, present: str
+) -> None:
+    # Une case vide vaut "on ne sait pas", que LightGBM sait traiter. La rendre `True` inventerait
+    # une heure ouvree, et le modele apprendrait sur une valeur que personne n'a mesuree.
+    csv_path = write_csv(
+        tmp_path,
+        f"SITE001,2026-01-01T00:00:00,10.5,15.0,50.0,0.0,{present},office",
+        "SITE001,2026-01-01T01:00:00,11.5,15.2,50.5,0.0,,office",
+    )
+
+    frame = load_from_csv(csv_path)
+
+    assert frame["is_working_hours"].iloc[0] == 1
+    assert pd.isna(frame["is_working_hours"].iloc[1])
+
+
+@pytest.mark.parametrize(
+    "valeurs",
+    [("1", "0"), ("True", "False")],
+    ids=["entier", "booleen_textuel"],
+)
+def test_load_from_csv_always_types_is_working_hours_as_float(
+    tmp_path: Path, valeurs: tuple[str, str]
+) -> None:
+    # Le dtype ne doit pas dependre de l'ecriture du fichier ni de la presence d'un trou : c'est
+    # ce qui rend comparable le schema des deux chargeurs, cf. `test_data_integration.py`.
+    present, absent = valeurs
+    csv_path = write_csv(
+        tmp_path,
+        f"SITE001,2026-01-01T00:00:00,10.5,15.0,50.0,0.0,{present},office",
+        f"SITE001,2026-01-01T01:00:00,11.5,15.2,50.5,0.0,{absent},office",
+    )
+
+    frame = load_from_csv(csv_path)
+
+    assert frame["is_working_hours"].dtype == "float64"
+    assert list(frame["is_working_hours"]) == [1.0, 0.0]
@@ -142,6 +142,21 @@ def test_load_recent_from_database_types_a_null_is_working_hours_as_float64(
    assert list(frame["is_working_hours"].isna()) == [True, False]


+def test_load_recent_from_database_types_is_working_hours_as_float64_even_without_a_null(
+    connexion_ml: Connection,
+) -> None:
+    # Sans cette garantie, le dtype dependrait du contenu de la fenetre lue : `bool` ici, `float64`
+    # des qu'une seule lecture est a NULL, et le schema des deux chargeurs cesserait d'etre egal.
+    site_id = insere_site(connexion_ml)
+    insere_lectures(connexion_ml, site_id, heures=2, fin=ANCRAGE)
+
+    frame = load_recent_from_database(
+        connexion_ml, since=ANCRAGE - timedelta(hours=2), until=ANCRAGE
+    )
+
+    assert frame["is_working_hours"].dtype == "float64"
+
+
 def test_both_loaders_produce_the_same_columns_in_the_same_order(
    connexion_ml: Connection, tmp_path: Path
 ) -> None:
@@ -3,6 +3,7 @@ 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
@@ -74,3 +75,19 @@ 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,10 +1,82 @@
-# Monitoring
+# Supervision

-Prometheus, Grafana et Alertmanager. Non initialise, voir le ticket dedie.
+Prometheus, Alertmanager, Grafana et trois exporteurs, sous le profil Compose `monitoring`.
+Issue #26, décisions dans l'ADR 0016, vue d'architecture dans
+`docs/architecture/60-observabilite.md`.

- `prometheus` : configuration de collecte et regles d'alerte.
- `grafana/provisioning` : sources de donnees et fournisseurs de dashboards.
- `grafana/dashboards` : dashboards versionnes au format JSON.
- `alertmanager` : routage et inhibition des alertes.
+| Service | Image | Rôle | Accès |
+|---|---|---|---|
+| `prometheus` | `prom/prometheus` | Collecte toutes les 15 s, évalue les règles, garde 15 jours (1 Go au plus) | `127.0.0.1:${PROMETHEUS_PORT:-9090}` |
+| `alertmanager` | `prom/alertmanager` | Groupe les alertes et les envoie par courriel à Mailpit | `127.0.0.1:${ALERTMANAGER_PORT:-9093}` |
+| `grafana` | `grafana/grafana` | Trois tableaux de bord provisionnés, dossier « EnerVision » | `127.0.0.1:${GRAFANA_PORT:-3001}` |
+| `postgres-exporter` | `prometheuscommunity/postgres-exporter` | Connexions, transactions, taille des bases | réseau interne |
+| `node-exporter` | `prom/node-exporter` | Processeur, mémoire et disque de l'hôte | réseau interne |
+| `cadvisor` | `gcr.io/cadvisor/cadvisor` | Mémoire et processeur par conteneur | réseau interne |

-Le backend expose deja ses metriques sur `/metrics` au format Prometheus.
+Les interfaces n'écoutent que sur `127.0.0.1`. Depuis un poste, on passe par un tunnel SSH,
+comme pour Airflow :
+
+```bash
+ssh -L 3001:127.0.0.1:3001 -L 9090:127.0.0.1:9090 enervision@10.101.200.37
+```
+
+## Démarrer
+
+- **Prod.** `COMPOSE_PROFILES=monitoring` dans le `.env` : `make stack-up`, donc chaque
+  déploiement, démarre la supervision et pose le rôle `supervision` après les migrations.
+- **Recette et poste.** À la demande, sur une stack déjà démarrée : `make monitoring-up`. Les
+  services partent en `--no-deps`, sans toucher aux autres.
+
+Trois secrets sont requis, et `make stack-up` comme `make monitoring-up` refusent de démarrer
+s'il en manque un. `scripts/provision-host.sh` les génère pour un nouvel environnement.
+
+| Variable | Rôle |
+|---|---|
+| `APP_METRICS_TOKEN` | Jeton que Prometheus présente sur `/metrics`, et que l'API exige dès qu'il est posé |
+| `GRAFANA_ADMIN_PASSWORD` | Compte `admin` de Grafana. Sans lui, le conteneur refuse de démarrer |
+| `SUPERVISION_DB_PASSWORD` | Rôle PostgreSQL `supervision`, en lecture seule (`db/roles/supervision.sql`) |
+
+L'API doit tourner en conteneur (`make stack-up`, ou `docker compose up -d backend`) :
+Prometheus la joint en `backend:8000`, sur le réseau du projet. Une API lancée par `make dev`
+sur l'hôte reste hors de sa portée, et l'alerte `ApiIndisponible` le signale.
+
+## Tableaux de bord
+
+| Tableau | Source | Contenu |
+|---|---|---|
+| EnerVision · API | Prometheus | Débit, erreurs 5xx, latences p50/p95/p99, globales et par route. C'est lui qu'on regarde pendant un tir k6 |
+| EnerVision · Données et modèle | TimescaleDB | Fraîcheur des relevés par site, relevés ingérés, alertes par sévérité, dérive du modèle (`drift_report`) |
+| EnerVision · Infrastructure | Prometheus | Hôte, mémoire et processeur par conteneur (recette et prod comprises), PostgreSQL |
+
+Les fichiers JSON de `grafana/dashboards` sont la source : Grafana les recharge et refuse de
+les modifier depuis l'interface. Pour changer un tableau, l'exporter en JSON depuis Grafana et
+remplacer le fichier.
+
+## Alertes
+
+`prometheus/rules/enervision.yml` définit les règles, et `prometheus/tests/enervision.test.yml`
+porte un cas par règle, joué par `promtool test rules`.
+
+| Alerte | Condition | Sévérité |
+|---|---|---|
+| `ApiIndisponible` | `/metrics` injoignable pendant 2 min | critical |
+| `ApiErreursServeur` | Plus de 5 % de 5xx sur 5 min | critical |
+| `ApiLatenceElevee` | p95 au-delà d'une seconde pendant 10 min | warning |
+| `BaseIndisponible` | Exportateur sans connexion pendant 2 min | critical |
+| `BaseConnexionsSaturees` | Plus de 80 % de `max_connections` | warning |
+| `HoteMemoireSaturee` | Mémoire au-delà de 90 % pendant 10 min | warning |
+| `HoteDisquePlein` | Moins de 10 % libres sur `/` | critical |
+| `HoteCpuSature` | Processeur au-delà de 90 % pendant 15 min | warning |
+| `CibleInjoignable` | Un exporteur muet pendant 5 min | warning |
+
+Alertmanager envoie les courriels à `supervision@enervision.fr` via Mailpit, qui les capture :
+ils se lisent dans son interface. Un `critical` masque le `warning` de la même cible.
+
+## Vérifier la configuration
+
+```bash
+make monitoring-check   # promtool check config et test rules, amtool check-config, JSON des tableaux
+```
+
+La CI joue les mêmes commandes (job « Validation des fichiers Compose et de la supervision »)
+dès que `monitoring/` ou un fichier Compose change.
@@ -0,0 +1,31 @@
+# Contrainte : Mailpit est le seul serveur SMTP de la stack, et il ne relaie rien vers l'extérieur
+# - alertmanager.yml. Les alertes se lisent dans son interface (MAILPIT_UI_PORT), comme les
+# courriels de réinitialisation de l'API.
+
+global:
+  smtp_smarthost: mailpit:1025
+  smtp_from: supervision@enervision.fr
+  smtp_require_tls: false
+
+route:
+  receiver: equipe
+  group_by: [alertname, severity]
+  group_wait: 30s
+  group_interval: 5m
+  repeat_interval: 12h
+  routes:
+    - matchers: ['severity="critical"']
+      receiver: equipe
+      group_wait: 10s
+      repeat_interval: 1h
+
+receivers:
+  - name: equipe
+    email_configs:
+      - to: supervision@enervision.fr
+        send_resolved: true
+
+inhibit_rules:
+  - source_matchers: ['severity="critical"']
+    target_matchers: ['severity="warning"']
+    equal: [instance]
@@ -0,0 +1,578 @@
+{
+  "uid": "enervision-api",
+  "title": "EnerVision · API",
+  "description": "Débit, erreurs et latences vus par l'API elle-même (prometheus-fastapi-instrumentator).",
+  "tags": [
+    "enervision"
+  ],
+  "timezone": "browser",
+  "editable": false,
+  "graphTooltip": 1,
+  "refresh": "10s",
+  "schemaVersion": 39,
+  "version": 1,
+  "time": {
+    "from": "now-1h",
+    "to": "now"
+  },
+  "templating": {
+    "list": []
+  },
+  "annotations": {
+    "list": []
+  },
+  "links": [],
+  "panels": [
+    {
+      "id": 1,
+      "type": "stat",
+      "title": "API",
+      "gridPos": {
+        "x": 0,
+        "y": 0,
+        "w": 6,
+        "h": 4
+      },
+      "datasource": {
+        "type": "prometheus",
+        "uid": "prometheus"
+      },
+      "targets": [
+        {
+          "refId": "A",
+          "datasource": {
+            "type": "prometheus",
+            "uid": "prometheus"
+          },
+          "expr": "up{job=\"backend\"}",
+          "legendFormat": "",
+          "range": true
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "thresholds": {
+            "mode": "absolute",
+            "steps": [
+              {
+                "color": "red",
+                "value": null
+              },
+              {
+                "color": "green",
+                "value": 1
+              }
+            ]
+          },
+          "color": {
+            "mode": "thresholds"
+          },
+          "mappings": [
+            {
+              "type": "value",
+              "options": {
+                "0": {
+                  "text": "Injoignable",
+                  "color": "red"
+                },
+                "1": {
+                  "text": "Joignable",
+                  "color": "green"
+                }
+              }
+            }
+          ]
+        },
+        "overrides": []
+      },
+      "options": {
+        "reduceOptions": {
+          "calcs": [
+            "lastNotNull"
+          ],
+          "fields": "",
+          "values": false
+        },
+        "colorMode": "background",
+        "graphMode": "area",
+        "textMode": "auto"
+      },
+      "description": "Prometheus joint-il /metrics ?"
+    },
+    {
+      "id": 2,
+      "type": "stat",
+      "title": "Débit",
+      "gridPos": {
+        "x": 6,
+        "y": 0,
+        "w": 6,
+        "h": 4
+      },
+      "datasource": {
+        "type": "prometheus",
+        "uid": "prometheus"
+      },
+      "targets": [
+        {
+          "refId": "A",
+          "datasource": {
+            "type": "prometheus",
+            "uid": "prometheus"
+          },
+          "expr": "sum(rate(http_requests_total{job=\"backend\"}[5m]))",
+          "legendFormat": "",
+          "range": true
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "reqps",
+          "thresholds": {
+            "mode": "absolute",
+            "steps": [
+              {
+                "color": "blue",
+                "value": null
+              }
+            ]
+          },
+          "color": {
+            "mode": "thresholds"
+          }
+        },
+        "overrides": []
+      },
+      "options": {
+        "reduceOptions": {
+          "calcs": [
+            "lastNotNull"
+          ],
+          "fields": "",
+          "values": false
+        },
+        "colorMode": "background",
+        "graphMode": "area",
+        "textMode": "auto"
+      }
+    },
+    {
+      "id": 3,
+      "type": "stat",
+      "title": "Erreurs 5xx",
+      "gridPos": {
+        "x": 12,
+        "y": 0,
+        "w": 6,
+        "h": 4
+      },
+      "datasource": {
+        "type": "prometheus",
+        "uid": "prometheus"
+      },
+      "targets": [
+        {
+          "refId": "A",
+          "datasource": {
+            "type": "prometheus",
+            "uid": "prometheus"
+          },
+          "expr": "sum(rate(http_requests_total{job=\"backend\", status=\"5xx\"}[5m])) / sum(rate(http_requests_total{job=\"backend\"}[5m]))",
+          "legendFormat": "",
+          "range": true
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "percentunit",
+          "thresholds": {
+            "mode": "absolute",
+            "steps": [
+              {
+                "color": "green",
+                "value": null
+              },
+              {
+                "color": "orange",
+                "value": 0.01
+              },
+              {
+                "color": "red",
+                "value": 0.05
+              }
+            ]
+          },
+          "color": {
+            "mode": "thresholds"
+          }
+        },
+        "overrides": []
+      },
+      "options": {
+        "reduceOptions": {
+          "calcs": [
+            "lastNotNull"
+          ],
+          "fields": "",
+          "values": false
+        },
+        "colorMode": "background",
+        "graphMode": "area",
+        "textMode": "auto"
+      },
+      "description": "Seuil d'alerte : 5 % pendant 5 minutes."
+    },
+    {
+      "id": 4,
+      "type": "stat",
+      "title": "Latence p95",
+      "gridPos": {
+        "x": 18,
+        "y": 0,
+        "w": 6,
+        "h": 4
+      },
+      "datasource": {
+        "type": "prometheus",
+        "uid": "prometheus"
+      },
+      "targets": [
+        {
+          "refId": "A",
+          "datasource": {
+            "type": "prometheus",
+            "uid": "prometheus"
+          },
+          "expr": "histogram_quantile(0.95, sum by (le) (rate(http_request_duration_highr_seconds_bucket{job=\"backend\"}[5m])))",
+          "legendFormat": "",
+          "range": true
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "s",
+          "thresholds": {
+            "mode": "absolute",
+            "steps": [
+              {
+                "color": "green",
+                "value": null
+              },
+              {
+                "color": "orange",
+                "value": 0.5
+              },
+              {
+                "color": "red",
+                "value": 1
+              }
+            ]
+          },
+          "color": {
+            "mode": "thresholds"
+          }
+        },
+        "overrides": []
+      },
+      "options": {
+        "reduceOptions": {
+          "calcs": [
+            "lastNotNull"
+          ],
+          "fields": "",
+          "values": false
+        },
+        "colorMode": "background",
+        "graphMode": "area",
+        "textMode": "auto"
+      },
+      "description": "Seuil de charge : 500 ms (ADR 0015). Alerte au-delà d'une seconde pendant 10 minutes."
+    },
+    {
+      "id": 5,
+      "type": "timeseries",
+      "title": "Débit par route",
+      "gridPos": {
+        "x": 0,
+        "y": 4,
+        "w": 12,
+        "h": 8
+      },
+      "datasource": {
+        "type": "prometheus",
+        "uid": "prometheus"
+      },
+      "targets": [
+        {
+          "refId": "A",
+          "datasource": {
+            "type": "prometheus",
+            "uid": "prometheus"
+          },
+          "expr": "sum by (handler) (rate(http_requests_total{job=\"backend\"}[1m]))",
+          "legendFormat": "{{handler}}",
+          "range": true
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "reqps"
+        },
+        "overrides": []
+      },
+      "options": {
+        "legend": {
+          "displayMode": "list",
+          "placement": "bottom",
+          "showLegend": true
+        },
+        "tooltip": {
+          "mode": "multi",
+          "sort": "desc"
+        }
+      }
+    },
+    {
+      "id": 6,
+      "type": "timeseries",
+      "title": "Latence de l'API",
+      "gridPos": {
+        "x": 12,
+        "y": 4,
+        "w": 12,
+        "h": 8
+      },
+      "datasource": {
+        "type": "prometheus",
+        "uid": "prometheus"
+      },
+      "targets": [
+        {
+          "refId": "A",
+          "datasource": {
+            "type": "prometheus",
+            "uid": "prometheus"
+          },
+          "expr": "histogram_quantile(0.50, sum by (le) (rate(http_request_duration_highr_seconds_bucket{job=\"backend\"}[1m])))",
+          "legendFormat": "p50",
+          "range": true
+        },
+        {
+          "refId": "B",
+          "datasource": {
+            "type": "prometheus",
+            "uid": "prometheus"
+          },
+          "expr": "histogram_quantile(0.95, sum by (le) (rate(http_request_duration_highr_seconds_bucket{job=\"backend\"}[1m])))",
+          "legendFormat": "p95",
+          "range": true
+        },
+        {
+          "refId": "C",
+          "datasource": {
+            "type": "prometheus",
+            "uid": "prometheus"
+          },
+          "expr": "histogram_quantile(0.99, sum by (le) (rate(http_request_duration_highr_seconds_bucket{job=\"backend\"}[1m])))",
+          "legendFormat": "p99",
+          "range": true
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "s"
+        },
+        "overrides": []
+      },
+      "options": {
+        "legend": {
+          "displayMode": "list",
+          "placement": "bottom",
+          "showLegend": true
+        },
+        "tooltip": {
+          "mode": "multi",
+          "sort": "desc"
+        }
+      }
+    },
+    {
+      "id": 7,
+      "type": "timeseries",
+      "title": "Latence p95 par route",
+      "gridPos": {
+        "x": 0,
+        "y": 12,
+        "w": 12,
+        "h": 8
+      },
+      "datasource": {
+        "type": "prometheus",
+        "uid": "prometheus"
+      },
+      "targets": [
+        {
+          "refId": "A",
+          "datasource": {
+            "type": "prometheus",
+            "uid": "prometheus"
+          },
+          "expr": "histogram_quantile(0.95, sum by (le, handler) (rate(http_request_duration_seconds_bucket{job=\"backend\"}[5m])))",
+          "legendFormat": "{{handler}}",
+          "range": true
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "s"
+        },
+        "overrides": []
+      },
+      "options": {
+        "legend": {
+          "displayMode": "list",
+          "placement": "bottom",
+          "showLegend": true
+        },
+        "tooltip": {
+          "mode": "multi",
+          "sort": "desc"
+        }
+      },
+      "description": "Estimée sur les seaux 50 ms à 2,5 s de http_request_duration_seconds."
+    },
+    {
+      "id": 8,
+      "type": "timeseries",
+      "title": "Réponses par classe de statut",
+      "gridPos": {
+        "x": 12,
+        "y": 12,
+        "w": 12,
+        "h": 8
+      },
+      "datasource": {
+        "type": "prometheus",
+        "uid": "prometheus"
+      },
+      "targets": [
+        {
+          "refId": "A",
+          "datasource": {
+            "type": "prometheus",
+            "uid": "prometheus"
+          },
+          "expr": "sum by (status) (rate(http_requests_total{job=\"backend\"}[1m]))",
+          "legendFormat": "{{status}}",
+          "range": true
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "reqps"
+        },
+        "overrides": []
+      },
+      "options": {
+        "legend": {
+          "displayMode": "list",
+          "placement": "bottom",
+          "showLegend": true
+        },
+        "tooltip": {
+          "mode": "multi",
+          "sort": "desc"
+        }
+      }
+    },
+    {
+      "id": 9,
+      "type": "timeseries",
+      "title": "Mémoire du processus API",
+      "gridPos": {
+        "x": 0,
+        "y": 20,
+        "w": 12,
+        "h": 8
+      },
+      "datasource": {
+        "type": "prometheus",
+        "uid": "prometheus"
+      },
+      "targets": [
+        {
+          "refId": "A",
+          "datasource": {
+            "type": "prometheus",
+            "uid": "prometheus"
+          },
+          "expr": "process_resident_memory_bytes{job=\"backend\"}",
+          "legendFormat": "résidente",
+          "range": true
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "bytes"
+        },
+        "overrides": []
+      },
+      "options": {
+        "legend": {
+          "displayMode": "list",
+          "placement": "bottom",
+          "showLegend": true
+        },
+        "tooltip": {
+          "mode": "multi",
+          "sort": "desc"
+        }
+      }
+    },
+    {
+      "id": 10,
+      "type": "timeseries",
+      "title": "Requêtes en cours de traitement",
+      "gridPos": {
+        "x": 12,
+        "y": 20,
+        "w": 12,
+        "h": 8
+      },
+      "datasource": {
+        "type": "prometheus",
+        "uid": "prometheus"
+      },
+      "targets": [
+        {
+          "refId": "A",
+          "datasource": {
+            "type": "prometheus",
+            "uid": "prometheus"
+          },
+          "expr": "sum(rate(http_request_duration_highr_seconds_sum{job=\"backend\"}[1m]))",
+          "legendFormat": "secondes de traitement par seconde",
+          "range": true
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "short"
+        },
+        "overrides": []
+      },
+      "options": {
+        "legend": {
+          "displayMode": "list",
+          "placement": "bottom",
+          "showLegend": true
+        },
+        "tooltip": {
+          "mode": "multi",
+          "sort": "desc"
+        }
+      },
+      "description": "Loi de Little : durée moyenne multipliée par le débit, soit le nombre moyen de requêtes simultanées."
+    }
+  ]
+}
@@ -0,0 +1,528 @@
+{
+  "uid": "enervision-donnees",
+  "title": "EnerVision · Données et modèle",
+  "description": "Fraîcheur des relevés, alertes métier et dérive du modèle, lus dans TimescaleDB par le rôle supervision.",
+  "tags": [
+    "enervision"
+  ],
+  "timezone": "browser",
+  "editable": false,
+  "graphTooltip": 1,
+  "refresh": "1m",
+  "schemaVersion": 39,
+  "version": 1,
+  "time": {
+    "from": "now-7d",
+    "to": "now"
+  },
+  "templating": {
+    "list": []
+  },
+  "annotations": {
+    "list": []
+  },
+  "links": [],
+  "panels": [
+    {
+      "id": 1,
+      "type": "stat",
+      "title": "Sites suivis",
+      "gridPos": {
+        "x": 0,
+        "y": 0,
+        "w": 6,
+        "h": 4
+      },
+      "datasource": {
+        "type": "grafana-postgresql-datasource",
+        "uid": "timescaledb"
+      },
+      "targets": [
+        {
+          "refId": "A",
+          "datasource": {
+            "type": "grafana-postgresql-datasource",
+            "uid": "timescaledb"
+          },
+          "rawSql": "SELECT count(*) AS \"Sites\" FROM site",
+          "format": "table",
+          "rawQuery": true,
+          "editorMode": "code"
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "thresholds": {
+            "mode": "absolute",
+            "steps": [
+              {
+                "color": "blue",
+                "value": null
+              }
+            ]
+          },
+          "color": {
+            "mode": "thresholds"
+          }
+        },
+        "overrides": []
+      },
+      "options": {
+        "reduceOptions": {
+          "calcs": [
+            "lastNotNull"
+          ],
+          "fields": "",
+          "values": false
+        },
+        "colorMode": "background",
+        "graphMode": "area",
+        "textMode": "auto"
+      }
+    },
+    {
+      "id": 2,
+      "type": "stat",
+      "title": "Relevés sur 24 h",
+      "gridPos": {
+        "x": 6,
+        "y": 0,
+        "w": 6,
+        "h": 4
+      },
+      "datasource": {
+        "type": "grafana-postgresql-datasource",
+        "uid": "timescaledb"
+      },
+      "targets": [
+        {
+          "refId": "A",
+          "datasource": {
+            "type": "grafana-postgresql-datasource",
+            "uid": "timescaledb"
+          },
+          "rawSql": "SELECT count(*) AS \"Relevés\" FROM reading WHERE timestamp > now() - interval '24 hours'",
+          "format": "table",
+          "rawQuery": true,
+          "editorMode": "code"
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "short",
+          "thresholds": {
+            "mode": "absolute",
+            "steps": [
+              {
+                "color": "red",
+                "value": null
+              },
+              {
+                "color": "green",
+                "value": 1
+              }
+            ]
+          },
+          "color": {
+            "mode": "thresholds"
+          }
+        },
+        "overrides": []
+      },
+      "options": {
+        "reduceOptions": {
+          "calcs": [
+            "lastNotNull"
+          ],
+          "fields": "",
+          "values": false
+        },
+        "colorMode": "background",
+        "graphMode": "area",
+        "textMode": "auto"
+      },
+      "description": "Zéro : l'import de la Mock API ne tourne plus."
+    },
+    {
+      "id": 3,
+      "type": "stat",
+      "title": "Alertes sur 24 h",
+      "gridPos": {
+        "x": 12,
+        "y": 0,
+        "w": 6,
+        "h": 4
+      },
+      "datasource": {
+        "type": "grafana-postgresql-datasource",
+        "uid": "timescaledb"
+      },
+      "targets": [
+        {
+          "refId": "A",
+          "datasource": {
+            "type": "grafana-postgresql-datasource",
+            "uid": "timescaledb"
+          },
+          "rawSql": "SELECT count(*) AS \"Alertes\" FROM alert WHERE timestamp > now() - interval '24 hours'",
+          "format": "table",
+          "rawQuery": true,
+          "editorMode": "code"
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "short",
+          "thresholds": {
+            "mode": "absolute",
+            "steps": [
+              {
+                "color": "green",
+                "value": null
+              },
+              {
+                "color": "orange",
+                "value": 1
+              },
+              {
+                "color": "red",
+                "value": 10
+              }
+            ]
+          },
+          "color": {
+            "mode": "thresholds"
+          }
+        },
+        "overrides": []
+      },
+      "options": {
+        "reduceOptions": {
+          "calcs": [
+            "lastNotNull"
+          ],
+          "fields": "",
+          "values": false
+        },
+        "colorMode": "background",
+        "graphMode": "area",
+        "textMode": "auto"
+      }
+    },
+    {
+      "id": 4,
+      "type": "stat",
+      "title": "Sites en dérive",
+      "gridPos": {
+        "x": 18,
+        "y": 0,
+        "w": 6,
+        "h": 4
+      },
+      "datasource": {
+        "type": "grafana-postgresql-datasource",
+        "uid": "timescaledb"
+      },
+      "targets": [
+        {
+          "refId": "A",
+          "datasource": {
+            "type": "grafana-postgresql-datasource",
+            "uid": "timescaledb"
+          },
+          "rawSql": "SELECT count(*) AS \"Sites\" FROM (SELECT DISTINCT ON (site_id) status FROM drift_report WHERE site_id IS NOT NULL ORDER BY site_id, computed_at DESC) AS derniers WHERE status = 'derive'",
+          "format": "table",
+          "rawQuery": true,
+          "editorMode": "code"
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "short",
+          "thresholds": {
+            "mode": "absolute",
+            "steps": [
+              {
+                "color": "green",
+                "value": null
+              },
+              {
+                "color": "red",
+                "value": 1
+              }
+            ]
+          },
+          "color": {
+            "mode": "thresholds"
+          }
+        },
+        "overrides": []
+      },
+      "options": {
+        "reduceOptions": {
+          "calcs": [
+            "lastNotNull"
+          ],
+          "fields": "",
+          "values": false
+        },
+        "colorMode": "background",
+        "graphMode": "area",
+        "textMode": "auto"
+      },
+      "description": "Dernier rapport de dérive de chaque site (ADR 0013)."
+    },
+    {
+      "id": 5,
+      "type": "table",
+      "title": "Fraîcheur des relevés par site",
+      "gridPos": {
+        "x": 0,
+        "y": 4,
+        "w": 12,
+        "h": 8
+      },
+      "datasource": {
+        "type": "grafana-postgresql-datasource",
+        "uid": "timescaledb"
+      },
+      "targets": [
+        {
+          "refId": "A",
+          "datasource": {
+            "type": "grafana-postgresql-datasource",
+            "uid": "timescaledb"
+          },
+          "rawSql": "SELECT s.site_name AS \"Site\", max(r.timestamp) AS \"Dernier relevé\", round(extract(epoch FROM now() - max(r.timestamp)) / 60) AS \"Âge (min)\"\nFROM site AS s\nLEFT JOIN reading AS r ON r.site_id = s.site_id AND r.timestamp > now() - interval '7 days'\nGROUP BY s.site_name\nORDER BY 3 DESC NULLS FIRST",
+          "format": "table",
+          "rawQuery": true,
+          "editorMode": "code"
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {},
+        "overrides": []
+      },
+      "options": {
+        "showHeader": true
+      },
+      "description": "Un site sans relevé depuis sept jours apparaît vide, en tête de liste."
+    },
+    {
+      "id": 6,
+      "type": "table",
+      "title": "Dérive du modèle, dernier rapport",
+      "gridPos": {
+        "x": 12,
+        "y": 4,
+        "w": 12,
+        "h": 8
+      },
+      "datasource": {
+        "type": "grafana-postgresql-datasource",
+        "uid": "timescaledb"
+      },
+      "targets": [
+        {
+          "refId": "A",
+          "datasource": {
+            "type": "grafana-postgresql-datasource",
+            "uid": "timescaledb"
+          },
+          "rawSql": "SELECT DISTINCT ON (d.site_id) coalesce(s.site_name, 'Tout le parc') AS \"Site\", d.status AS \"Statut\", round(d.mae::numeric, 2) AS \"MAE\", round(d.reference_mae::numeric, 2) AS \"MAE de référence\", round(d.bias::numeric, 2) AS \"Biais\", d.computed_at AS \"Calculé le\"\nFROM drift_report AS d\nLEFT JOIN site AS s ON s.site_id = d.site_id\nORDER BY d.site_id, d.computed_at DESC",
+          "format": "table",
+          "rawQuery": true,
+          "editorMode": "code"
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {},
+        "overrides": []
+      },
+      "options": {
+        "showHeader": true
+      },
+      "description": "Une ligne par site, plus la ligne globale (ADR 0013)."
+    },
+    {
+      "id": 7,
+      "type": "timeseries",
+      "title": "Consommation par site",
+      "gridPos": {
+        "x": 0,
+        "y": 12,
+        "w": 12,
+        "h": 8
+      },
+      "datasource": {
+        "type": "grafana-postgresql-datasource",
+        "uid": "timescaledb"
+      },
+      "targets": [
+        {
+          "refId": "A",
+          "datasource": {
+            "type": "grafana-postgresql-datasource",
+            "uid": "timescaledb"
+          },
+          "rawSql": "SELECT $__timeGroupAlias(r.timestamp, $__interval), s.site_name AS metric, avg(r.consumption_kw) AS value\nFROM reading AS r\nJOIN site AS s ON s.site_id = r.site_id\nWHERE $__timeFilter(r.timestamp)\nGROUP BY 1, 2\nORDER BY 1",
+          "format": "time_series",
+          "rawQuery": true,
+          "editorMode": "code"
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "kwatt"
+        },
+        "overrides": []
+      },
+      "options": {
+        "legend": {
+          "displayMode": "list",
+          "placement": "bottom",
+          "showLegend": true
+        },
+        "tooltip": {
+          "mode": "multi",
+          "sort": "desc"
+        }
+      }
+    },
+    {
+      "id": 8,
+      "type": "timeseries",
+      "title": "Relevés ingérés par heure",
+      "gridPos": {
+        "x": 12,
+        "y": 12,
+        "w": 12,
+        "h": 8
+      },
+      "datasource": {
+        "type": "grafana-postgresql-datasource",
+        "uid": "timescaledb"
+      },
+      "targets": [
+        {
+          "refId": "A",
+          "datasource": {
+            "type": "grafana-postgresql-datasource",
+            "uid": "timescaledb"
+          },
+          "rawSql": "SELECT time_bucket('1 hour', timestamp) AS time, count(*) AS \"Relevés\"\nFROM reading\nWHERE $__timeFilter(timestamp)\nGROUP BY 1\nORDER BY 1",
+          "format": "time_series",
+          "rawQuery": true,
+          "editorMode": "code"
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "short"
+        },
+        "overrides": []
+      },
+      "options": {
+        "legend": {
+          "displayMode": "list",
+          "placement": "bottom",
+          "showLegend": true
+        },
+        "tooltip": {
+          "mode": "multi",
+          "sort": "desc"
+        }
+      }
+    },
+    {
+      "id": 9,
+      "type": "timeseries",
+      "title": "Alertes par sévérité",
+      "gridPos": {
+        "x": 0,
+        "y": 20,
+        "w": 12,
+        "h": 8
+      },
+      "datasource": {
+        "type": "grafana-postgresql-datasource",
+        "uid": "timescaledb"
+      },
+      "targets": [
+        {
+          "refId": "A",
+          "datasource": {
+            "type": "grafana-postgresql-datasource",
+            "uid": "timescaledb"
+          },
+          "rawSql": "SELECT time_bucket('1 hour', timestamp) AS time, severity AS metric, count(*) AS value\nFROM alert\nWHERE $__timeFilter(timestamp)\nGROUP BY 1, 2\nORDER BY 1",
+          "format": "time_series",
+          "rawQuery": true,
+          "editorMode": "code"
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "short"
+        },
+        "overrides": []
+      },
+      "options": {
+        "legend": {
+          "displayMode": "list",
+          "placement": "bottom",
+          "showLegend": true
+        },
+        "tooltip": {
+          "mode": "multi",
+          "sort": "desc"
+        }
+      }
+    },
+    {
+      "id": 10,
+      "type": "timeseries",
+      "title": "Erreur absolue moyenne du modèle",
+      "gridPos": {
+        "x": 12,
+        "y": 20,
+        "w": 12,
+        "h": 8
+      },
+      "datasource": {
+        "type": "grafana-postgresql-datasource",
+        "uid": "timescaledb"
+      },
+      "targets": [
+        {
+          "refId": "A",
+          "datasource": {
+            "type": "grafana-postgresql-datasource",
+            "uid": "timescaledb"
+          },
+          "rawSql": "SELECT d.computed_at AS time, coalesce(s.site_name, 'Tout le parc') AS metric, d.mae AS value\nFROM drift_report AS d\nLEFT JOIN site AS s ON s.site_id = d.site_id\nWHERE $__timeFilter(d.computed_at)\nORDER BY 1",
+          "format": "time_series",
+          "rawQuery": true,
+          "editorMode": "code"
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "kwatt"
+        },
+        "overrides": []
+      },
+      "options": {
+        "legend": {
+          "displayMode": "list",
+          "placement": "bottom",
+          "showLegend": true
+        },
+        "tooltip": {
+          "mode": "multi",
+          "sort": "desc"
+        }
+      }
+    }
+  ]
+}
@@ -0,0 +1,583 @@
+{
+  "uid": "enervision-infra",
+  "title": "EnerVision · Infrastructure",
+  "description": "Hôte (node-exporter), conteneurs (cAdvisor) et PostgreSQL (postgres-exporter). L'hôte porte la recette et la prod.",
+  "tags": [
+    "enervision"
+  ],
+  "timezone": "browser",
+  "editable": false,
+  "graphTooltip": 1,
+  "refresh": "30s",
+  "schemaVersion": 39,
+  "version": 1,
+  "time": {
+    "from": "now-6h",
+    "to": "now"
+  },
+  "templating": {
+    "list": []
+  },
+  "annotations": {
+    "list": []
+  },
+  "links": [],
+  "panels": [
+    {
+      "id": 1,
+      "type": "stat",
+      "title": "Mémoire de l'hôte",
+      "gridPos": {
+        "x": 0,
+        "y": 0,
+        "w": 6,
+        "h": 4
+      },
+      "datasource": {
+        "type": "prometheus",
+        "uid": "prometheus"
+      },
+      "targets": [
+        {
+          "refId": "A",
+          "datasource": {
+            "type": "prometheus",
+            "uid": "prometheus"
+          },
+          "expr": "1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes",
+          "legendFormat": "",
+          "range": true
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "percentunit",
+          "thresholds": {
+            "mode": "absolute",
+            "steps": [
+              {
+                "color": "green",
+                "value": null
+              },
+              {
+                "color": "orange",
+                "value": 0.8
+              },
+              {
+                "color": "red",
+                "value": 0.9
+              }
+            ]
+          },
+          "color": {
+            "mode": "thresholds"
+          }
+        },
+        "overrides": []
+      },
+      "options": {
+        "reduceOptions": {
+          "calcs": [
+            "lastNotNull"
+          ],
+          "fields": "",
+          "values": false
+        },
+        "colorMode": "background",
+        "graphMode": "area",
+        "textMode": "auto"
+      },
+      "description": "Alerte au-delà de 90 % pendant 10 minutes."
+    },
+    {
+      "id": 2,
+      "type": "stat",
+      "title": "Processeur de l'hôte",
+      "gridPos": {
+        "x": 6,
+        "y": 0,
+        "w": 6,
+        "h": 4
+      },
+      "datasource": {
+        "type": "prometheus",
+        "uid": "prometheus"
+      },
+      "targets": [
+        {
+          "refId": "A",
+          "datasource": {
+            "type": "prometheus",
+            "uid": "prometheus"
+          },
+          "expr": "1 - avg(rate(node_cpu_seconds_total{mode=\"idle\"}[5m]))",
+          "legendFormat": "",
+          "range": true
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "percentunit",
+          "thresholds": {
+            "mode": "absolute",
+            "steps": [
+              {
+                "color": "green",
+                "value": null
+              },
+              {
+                "color": "orange",
+                "value": 0.7
+              },
+              {
+                "color": "red",
+                "value": 0.9
+              }
+            ]
+          },
+          "color": {
+            "mode": "thresholds"
+          }
+        },
+        "overrides": []
+      },
+      "options": {
+        "reduceOptions": {
+          "calcs": [
+            "lastNotNull"
+          ],
+          "fields": "",
+          "values": false
+        },
+        "colorMode": "background",
+        "graphMode": "area",
+        "textMode": "auto"
+      }
+    },
+    {
+      "id": 3,
+      "type": "stat",
+      "title": "Disque libre",
+      "gridPos": {
+        "x": 12,
+        "y": 0,
+        "w": 6,
+        "h": 4
+      },
+      "datasource": {
+        "type": "prometheus",
+        "uid": "prometheus"
+      },
+      "targets": [
+        {
+          "refId": "A",
+          "datasource": {
+            "type": "prometheus",
+            "uid": "prometheus"
+          },
+          "expr": "node_filesystem_avail_bytes{mountpoint=\"/\", fstype!~\"tmpfs|overlay\"} / node_filesystem_size_bytes{mountpoint=\"/\", fstype!~\"tmpfs|overlay\"}",
+          "legendFormat": "",
+          "range": true
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "percentunit",
+          "thresholds": {
+            "mode": "absolute",
+            "steps": [
+              {
+                "color": "red",
+                "value": null
+              },
+              {
+                "color": "orange",
+                "value": 0.1
+              },
+              {
+                "color": "green",
+                "value": 0.2
+              }
+            ]
+          },
+          "color": {
+            "mode": "thresholds"
+          }
+        },
+        "overrides": []
+      },
+      "options": {
+        "reduceOptions": {
+          "calcs": [
+            "lastNotNull"
+          ],
+          "fields": "",
+          "values": false
+        },
+        "colorMode": "background",
+        "graphMode": "area",
+        "textMode": "auto"
+      }
+    },
+    {
+      "id": 4,
+      "type": "stat",
+      "title": "PostgreSQL",
+      "gridPos": {
+        "x": 18,
+        "y": 0,
+        "w": 6,
+        "h": 4
+      },
+      "datasource": {
+        "type": "prometheus",
+        "uid": "prometheus"
+      },
+      "targets": [
+        {
+          "refId": "A",
+          "datasource": {
+            "type": "prometheus",
+            "uid": "prometheus"
+          },
+          "expr": "pg_up",
+          "legendFormat": "",
+          "range": true
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "thresholds": {
+            "mode": "absolute",
+            "steps": [
+              {
+                "color": "red",
+                "value": null
+              },
+              {
+                "color": "green",
+                "value": 1
+              }
+            ]
+          },
+          "color": {
+            "mode": "thresholds"
+          },
+          "mappings": [
+            {
+              "type": "value",
+              "options": {
+                "0": {
+                  "text": "Injoignable",
+                  "color": "red"
+                },
+                "1": {
+                  "text": "Joignable",
+                  "color": "green"
+                }
+              }
+            }
+          ]
+        },
+        "overrides": []
+      },
+      "options": {
+        "reduceOptions": {
+          "calcs": [
+            "lastNotNull"
+          ],
+          "fields": "",
+          "values": false
+        },
+        "colorMode": "background",
+        "graphMode": "area",
+        "textMode": "auto"
+      }
+    },
+    {
+      "id": 5,
+      "type": "timeseries",
+      "title": "Mémoire par conteneur",
+      "gridPos": {
+        "x": 0,
+        "y": 4,
+        "w": 12,
+        "h": 8
+      },
+      "datasource": {
+        "type": "prometheus",
+        "uid": "prometheus"
+      },
+      "targets": [
+        {
+          "refId": "A",
+          "datasource": {
+            "type": "prometheus",
+            "uid": "prometheus"
+          },
+          "expr": "sum by (name) (container_memory_working_set_bytes{name!=\"\"})",
+          "legendFormat": "{{name}}",
+          "range": true
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "bytes"
+        },
+        "overrides": []
+      },
+      "options": {
+        "legend": {
+          "displayMode": "list",
+          "placement": "bottom",
+          "showLegend": true
+        },
+        "tooltip": {
+          "mode": "multi",
+          "sort": "desc"
+        }
+      },
+      "description": "Recette et prod partagent l'hôte : leurs conteneurs se distinguent par le préfixe du projet Compose."
+    },
+    {
+      "id": 6,
+      "type": "timeseries",
+      "title": "Processeur par conteneur",
+      "gridPos": {
+        "x": 12,
+        "y": 4,
+        "w": 12,
+        "h": 8
+      },
+      "datasource": {
+        "type": "prometheus",
+        "uid": "prometheus"
+      },
+      "targets": [
+        {
+          "refId": "A",
+          "datasource": {
+            "type": "prometheus",
+            "uid": "prometheus"
+          },
+          "expr": "sum by (name) (rate(container_cpu_usage_seconds_total{name!=\"\"}[5m]))",
+          "legendFormat": "{{name}}",
+          "range": true
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "short"
+        },
+        "overrides": []
+      },
+      "options": {
+        "legend": {
+          "displayMode": "list",
+          "placement": "bottom",
+          "showLegend": true
+        },
+        "tooltip": {
+          "mode": "multi",
+          "sort": "desc"
+        }
+      }
+    },
+    {
+      "id": 7,
+      "type": "timeseries",
+      "title": "Mémoire de l'hôte",
+      "gridPos": {
+        "x": 0,
+        "y": 12,
+        "w": 12,
+        "h": 8
+      },
+      "datasource": {
+        "type": "prometheus",
+        "uid": "prometheus"
+      },
+      "targets": [
+        {
+          "refId": "A",
+          "datasource": {
+            "type": "prometheus",
+            "uid": "prometheus"
+          },
+          "expr": "node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes",
+          "legendFormat": "utilisée",
+          "range": true
+        },
+        {
+          "refId": "B",
+          "datasource": {
+            "type": "prometheus",
+            "uid": "prometheus"
+          },
+          "expr": "node_memory_MemTotal_bytes",
+          "legendFormat": "totale",
+          "range": true
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "bytes"
+        },
+        "overrides": []
+      },
+      "options": {
+        "legend": {
+          "displayMode": "list",
+          "placement": "bottom",
+          "showLegend": true
+        },
+        "tooltip": {
+          "mode": "multi",
+          "sort": "desc"
+        }
+      }
+    },
+    {
+      "id": 8,
+      "type": "timeseries",
+      "title": "Connexions PostgreSQL par état",
+      "gridPos": {
+        "x": 12,
+        "y": 12,
+        "w": 12,
+        "h": 8
+      },
+      "datasource": {
+        "type": "prometheus",
+        "uid": "prometheus"
+      },
+      "targets": [
+        {
+          "refId": "A",
+          "datasource": {
+            "type": "prometheus",
+            "uid": "prometheus"
+          },
+          "expr": "sum by (state) (pg_stat_activity_count)",
+          "legendFormat": "{{state}}",
+          "range": true
+        },
+        {
+          "refId": "B",
+          "datasource": {
+            "type": "prometheus",
+            "uid": "prometheus"
+          },
+          "expr": "max(pg_settings_max_connections)",
+          "legendFormat": "maximum",
+          "range": true
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "short"
+        },
+        "overrides": []
+      },
+      "options": {
+        "legend": {
+          "displayMode": "list",
+          "placement": "bottom",
+          "showLegend": true
+        },
+        "tooltip": {
+          "mode": "multi",
+          "sort": "desc"
+        }
+      }
+    },
+    {
+      "id": 9,
+      "type": "timeseries",
+      "title": "Transactions validées par base",
+      "gridPos": {
+        "x": 0,
+        "y": 20,
+        "w": 12,
+        "h": 8
+      },
+      "datasource": {
+        "type": "prometheus",
+        "uid": "prometheus"
+      },
+      "targets": [
+        {
+          "refId": "A",
+          "datasource": {
+            "type": "prometheus",
+            "uid": "prometheus"
+          },
+          "expr": "sum by (datname) (rate(pg_stat_database_xact_commit{datname!~\"template.*|postgres\"}[5m]))",
+          "legendFormat": "{{datname}}",
+          "range": true
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "ops"
+        },
+        "overrides": []
+      },
+      "options": {
+        "legend": {
+          "displayMode": "list",
+          "placement": "bottom",
+          "showLegend": true
+        },
+        "tooltip": {
+          "mode": "multi",
+          "sort": "desc"
+        }
+      }
+    },
+    {
+      "id": 10,
+      "type": "timeseries",
+      "title": "Taille des bases",
+      "gridPos": {
+        "x": 12,
+        "y": 20,
+        "w": 12,
+        "h": 8
+      },
+      "datasource": {
+        "type": "prometheus",
+        "uid": "prometheus"
+      },
+      "targets": [
+        {
+          "refId": "A",
+          "datasource": {
+            "type": "prometheus",
+            "uid": "prometheus"
+          },
+          "expr": "pg_database_size_bytes{datname!~\"template.*|postgres\"}",
+          "legendFormat": "{{datname}}",
+          "range": true
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "bytes"
+        },
+        "overrides": []
+      },
+      "options": {
+        "legend": {
+          "displayMode": "list",
+          "placement": "bottom",
+          "showLegend": true
+        },
+        "tooltip": {
+          "mode": "multi",
+          "sort": "desc"
+        }
+      }
+    }
+  ]
+}
@@ -0,0 +1,10 @@
+apiVersion: 1
+
+providers:
+  - name: enervision
+    folder: EnerVision
+    type: file
+    disableDeletion: true
+    allowUiUpdates: false
+    options:
+      path: /etc/grafana/dashboards
@@ -0,0 +1,28 @@
+# Pourquoi : Grafana lit la base avec le rôle `supervision`, en lecture seule sur les seules tables
+# métier (db/roles/supervision.sql) - datasources.yml. Jamais le compte applicatif.
+
+apiVersion: 1
+
+datasources:
+  - name: Prometheus
+    uid: prometheus
+    type: prometheus
+    access: proxy
+    url: http://prometheus:9090
+    isDefault: true
+    editable: false
+
+  - name: TimescaleDB
+    uid: timescaledb
+    type: grafana-postgresql-datasource
+    access: proxy
+    url: db:5432
+    user: supervision
+    jsonData:
+      database: ${POSTGRES_DB}
+      sslmode: disable
+      postgresVersion: 1700
+      timescaledb: true
+    secureJsonData:
+      password: ${SUPERVISION_DB_PASSWORD}
+    editable: false
@@ -0,0 +1,43 @@
+# Contrainte : Prometheus ne lit pas les variables d'environnement dans ce fichier - prometheus.yml.
+# Le jeton de `/metrics` lui parvient en secret Compose (`metrics_token`, tiré d'APP_METRICS_TOKEN) ;
+# vide, l'API n'en exige aucun (app/api/security.py).
+
+global:
+  scrape_interval: 15s
+  evaluation_interval: 15s
+
+rule_files:
+  - /etc/prometheus/rules/*.yml
+
+alerting:
+  alertmanagers:
+    - static_configs:
+        - targets: ["alertmanager:9093"]
+
+scrape_configs:
+  - job_name: backend
+    authorization:
+      type: Bearer
+      credentials_file: /run/secrets/metrics_token
+    static_configs:
+      - targets: ["backend:8000"]
+
+  - job_name: prometheus
+    static_configs:
+      - targets: ["localhost:9090"]
+
+  - job_name: alertmanager
+    static_configs:
+      - targets: ["alertmanager:9093"]
+
+  - job_name: postgres
+    static_configs:
+      - targets: ["postgres-exporter:9187"]
+
+  - job_name: node
+    static_configs:
+      - targets: ["node-exporter:9100"]
+
+  - job_name: cadvisor
+    static_configs:
+      - targets: ["cadvisor:8080"]
@@ -0,0 +1,103 @@
+# Contrainte : chaque règle a son cas dans tests/enervision.test.yml, joué par `promtool test
+# rules` en CI - enervision.yml. Une règle modifiée sans son test fait échouer le job Infra.
+# Pourquoi : `critical` réveille (mail immédiat, rappel toutes les heures), `warning` se lit le
+# lendemain ; alertmanager.yml masque le warning d'une cible déjà en critical.
+
+groups:
+  - name: api
+    rules:
+      - alert: ApiIndisponible
+        expr: up{job="backend"} == 0
+        for: 2m
+        labels:
+          severity: critical
+        annotations:
+          summary: "L'API ne répond plus"
+          description: "Prometheus ne joint plus {{ $labels.instance }} depuis 2 minutes."
+
+      - alert: ApiErreursServeur
+        expr: |
+          sum(rate(http_requests_total{job="backend", status="5xx"}[5m]))
+            / sum(rate(http_requests_total{job="backend"}[5m])) > 0.05
+        for: 5m
+        labels:
+          severity: critical
+        annotations:
+          summary: "Plus de 5 % de réponses 5xx"
+          description: "{{ $value | humanizePercentage }} des réponses de l'API sont des erreurs serveur."
+
+      - alert: ApiLatenceElevee
+        expr: |
+          histogram_quantile(0.95,
+            sum by (le) (rate(http_request_duration_highr_seconds_bucket{job="backend"}[5m]))
+          ) > 1
+        for: 10m
+        labels:
+          severity: warning
+        annotations:
+          summary: "p95 de l'API au-dessus d'une seconde"
+          description: "Le p95 des réponses vaut {{ $value | humanizeDuration }} depuis 10 minutes."
+
+  - name: base
+    rules:
+      - alert: BaseIndisponible
+        expr: pg_up == 0
+        for: 2m
+        labels:
+          severity: critical
+        annotations:
+          summary: "PostgreSQL ne répond plus"
+          description: "L'exportateur ne se connecte plus à la base depuis 2 minutes."
+
+      - alert: BaseConnexionsSaturees
+        expr: |
+          sum by (instance) (pg_stat_activity_count)
+            / max by (instance) (pg_settings_max_connections) > 0.8
+        for: 5m
+        labels:
+          severity: warning
+        annotations:
+          summary: "Connexions PostgreSQL au-delà de 80 %"
+          description: "{{ $value | humanizePercentage }} des connexions autorisées sont ouvertes."
+
+  - name: hote
+    rules:
+      - alert: HoteMemoireSaturee
+        expr: 1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes > 0.9
+        for: 10m
+        labels:
+          severity: warning
+        annotations:
+          summary: "Mémoire de l'hôte au-delà de 90 %"
+          description: "{{ $value | humanizePercentage }} de la mémoire est utilisée, recette et prod comprises."
+
+      - alert: HoteDisquePlein
+        expr: |
+          node_filesystem_avail_bytes{mountpoint="/", fstype!~"tmpfs|overlay"}
+            / node_filesystem_size_bytes{mountpoint="/", fstype!~"tmpfs|overlay"} < 0.1
+        for: 10m
+        labels:
+          severity: critical
+        annotations:
+          summary: "Moins de 10 % de disque libre"
+          description: "Il reste {{ $value | humanizePercentage }} d'espace sur la racine de l'hôte."
+
+      - alert: HoteCpuSature
+        expr: 1 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) > 0.9
+        for: 15m
+        labels:
+          severity: warning
+        annotations:
+          summary: "Processeur de l'hôte au-delà de 90 %"
+          description: "Le processeur est occupé à {{ $value | humanizePercentage }} depuis 15 minutes."
+
+  - name: supervision
+    rules:
+      - alert: CibleInjoignable
+        expr: up{job!="backend"} == 0
+        for: 5m
+        labels:
+          severity: warning
+        annotations:
+          summary: "Cible de supervision injoignable"
+          description: "Prometheus ne joint plus {{ $labels.job }} ({{ $labels.instance }}) depuis 5 minutes."
@@ -0,0 +1,112 @@
+rule_files:
+  - ../rules/enervision.yml
+
+evaluation_interval: 1m
+
+tests:
+  - name: l'API injoignable déclenche une alerte critique au bout de 2 minutes
+    interval: 1m
+    input_series:
+      - series: 'up{job="backend", instance="backend:8000"}'
+        values: "1 0 0 0 0"
+    alert_rule_test:
+      - eval_time: 2m
+        alertname: ApiIndisponible
+        exp_alerts: []
+      - eval_time: 3m
+        alertname: ApiIndisponible
+        exp_alerts:
+          - exp_labels:
+              severity: critical
+              job: backend
+              instance: backend:8000
+            exp_annotations:
+              summary: "L'API ne répond plus"
+              description: "Prometheus ne joint plus backend:8000 depuis 2 minutes."
+
+  - name: une API qui répond ne déclenche rien
+    interval: 1m
+    input_series:
+      - series: 'up{job="backend", instance="backend:8000"}'
+        values: "1x10"
+    alert_rule_test:
+      - eval_time: 10m
+        alertname: ApiIndisponible
+        exp_alerts: []
+
+  - name: dix pour cent de 5xx déclenchent l'alerte d'erreurs serveur
+    interval: 1m
+    input_series:
+      - series: 'http_requests_total{job="backend", handler="/api/v1/sites", method="GET", status="5xx"}'
+        values: "0+10x20"
+      - series: 'http_requests_total{job="backend", handler="/api/v1/sites", method="GET", status="2xx"}'
+        values: "0+90x20"
+    alert_rule_test:
+      - eval_time: 12m
+        alertname: ApiErreursServeur
+        exp_alerts:
+          - exp_labels:
+              severity: critical
+            exp_annotations:
+              summary: "Plus de 5 % de réponses 5xx"
+              description: "10% des réponses de l'API sont des erreurs serveur."
+
+  - name: un p95 au-delà d'une seconde déclenche l'alerte de latence
+    interval: 1m
+    input_series:
+      - series: 'http_request_duration_highr_seconds_bucket{job="backend", le="0.5"}'
+        values: "0x30"
+      - series: 'http_request_duration_highr_seconds_bucket{job="backend", le="1"}'
+        values: "0x30"
+      - series: 'http_request_duration_highr_seconds_bucket{job="backend", le="2"}'
+        values: "0+10x30"
+      - series: 'http_request_duration_highr_seconds_bucket{job="backend", le="+Inf"}'
+        values: "0+10x30"
+    alert_rule_test:
+      - eval_time: 20m
+        alertname: ApiLatenceElevee
+        exp_alerts:
+          - exp_labels:
+              severity: warning
+            exp_annotations:
+              summary: "p95 de l'API au-dessus d'une seconde"
+              description: "Le p95 des réponses vaut 1.95s depuis 10 minutes."
+
+  - name: la mémoire de l'hôte au-delà de 90 % déclenche un avertissement
+    interval: 1m
+    input_series:
+      - series: 'node_memory_MemAvailable_bytes{job="node", instance="node-exporter:9100"}'
+        values: "500000000x15"
+      - series: 'node_memory_MemTotal_bytes{job="node", instance="node-exporter:9100"}'
+        values: "10000000000x15"
+    alert_rule_test:
+      - eval_time: 12m
+        alertname: HoteMemoireSaturee
+        exp_alerts:
+          - exp_labels:
+              severity: warning
+              job: node
+              instance: node-exporter:9100
+            exp_annotations:
+              summary: "Mémoire de l'hôte au-delà de 90 %"
+              description: "95% de la mémoire est utilisée, recette et prod comprises."
+
+  - name: un exportateur muet déclenche l'alerte de cible, pas celle de l'API
+    interval: 1m
+    input_series:
+      - series: 'up{job="postgres", instance="postgres-exporter:9187"}'
+        values: "0x10"
+    alert_rule_test:
+      - eval_time: 6m
+        alertname: CibleInjoignable
+        exp_alerts:
+          - exp_labels:
+              severity: warning
+              job: postgres
+              instance: postgres-exporter:9187
+            exp_annotations:
+              summary: "Cible de supervision injoignable"
+              description: "Prometheus ne joint plus postgres (postgres-exporter:9187) depuis 5 minutes."
+      - eval_time: 6m
+        alertname: ApiIndisponible
+        exp_alerts: []
@@ -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,101 @@
+#!/usr/bin/env bash
+# Contrainte : réservé à une base JETABLE (CI, e2e, charge sur le poste) - comptes-test.sh. Crée
+# un administrateur par la CLI, puis un lecteur et un opérateur, et écrit leurs identifiants en
+# JSON dans $COMPTES_FICHIER.
+# Piège : un compte neuf est en `must_change_password`, que toute route gardée refuse. Chaque
+# compte passe donc le changement de mot de passe avant d'être écrit dans le fichier.
+# Piège : `create-admin` refuse un second administrateur actif. ADMIN_SUPPLEMENTAIRE=1 passe
+# `--force`, pour la base du poste ; jamais en recette, où les comptes se créent par l'interface.
+#
+# BASE_URL vise l'API (http://localhost:8000 par défaut, ou le proxy en https). APP_CLI lance la
+# CLI du backend : depuis apps/backend par défaut, ou `docker compose ... exec -T backend python
+# -m app.cli` contre la stack conteneurisée.
+
+set -euo pipefail
+# Sans lui, une erreur dans `$(...)` ne s'arrête pas : la substitution rendrait un mot de passe vide.
+shopt -s inherit_errexit
+
+BASE_URL="${BASE_URL:-http://localhost:8000}"
+API="$BASE_URL/api/v1"
+COMPTES_FICHIER="${COMPTES_FICHIER:?COMPTES_FICHIER=chemin du fichier JSON requis}"
+read -ra CLI <<<"${APP_CLI:-uv run --frozen --no-sync --no-build python -m app.cli}"
+SUFFIXE="$(openssl rand -hex 4)"
+
+CURL=(curl -fsS)
+[[ "$BASE_URL" == https://* ]] && CURL+=(--insecure)
+
+# Classes exigées par le validateur : majuscule, minuscule, chiffre, caractère spécial.
+nouveau_mot_de_passe() { echo "Test-$(openssl rand -hex 12)-Aa1!"; }
+
+journal() { echo "comptes-test: $*" >&2; }
+
+connexion() {
+    local email="$1" mot_de_passe="$2"
+    "${CURL[@]}" -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'
+}
+
+# `/auth/password` rend un nouveau jeton d'accès : pas de reconnexion, donc pas de second hachage
+# Argon2id ni de requête de plus dans la zone `auth` de nginx (30 par minute).
+changer_mot_de_passe() {
+    local jeton="$1" ancien="$2" nouveau="$3"
+    "${CURL[@]}" -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'
+}
+
+creer_compte() {
+    local jeton_admin="$1" email="$2" role="$3" reponse temporaire
+    reponse="$("${CURL[@]}" -X POST "$API/users" -H "Authorization: Bearer $jeton_admin" \
+        -H 'Content-Type: application/json' \
+        -d "$(jq -n --arg e "$email" --arg r "$role" '{email:$e, role:$r}')")"
+    temporaire="$(jq -r '.temporary_password // empty' <<<"$reponse")"
+    [[ -n "$temporaire" ]] || { journal "mot de passe temporaire absent de la réponse : $reponse"; exit 1; }
+    echo "$temporaire"
+}
+
+# Rend le mot de passe définitif d'un compte créé par `creer_compte`.
+activer_compte() {
+    local email="$1" temporaire="$2" definitif jeton
+    definitif="$(nouveau_mot_de_passe)"
+    jeton="$(connexion "$email" "$temporaire")"
+    changer_mot_de_passe "$jeton" "$temporaire" "$definitif" >/dev/null
+    echo "$definitif"
+}
+
+EMAIL_ADMIN="test-admin-$SUFFIXE@enervision.fr"
+journal "création de l'administrateur $EMAIL_ADMIN"
+OPTIONS_ADMIN=(--email "$EMAIL_ADMIN" --generate)
+[[ "${ADMIN_SUPPLEMENTAIRE:-0}" == "1" ]] && OPTIONS_ADMIN+=(--force)
+if ! SORTIE="$("${CLI[@]}" create-admin "${OPTIONS_ADMIN[@]}")"; then
+    journal "la création de l'administrateur a échoué : $SORTIE"
+    exit 1
+fi
+MDP_TEMPORAIRE_ADMIN="$(sed -n 's/^Mot de passe généré, il ne sera plus affiché : //p' <<<"$SORTIE" | tr -d '\r')"
+[[ -n "$MDP_TEMPORAIRE_ADMIN" ]] || { journal "mot de passe introuvable dans la sortie : $SORTIE"; exit 1; }
+
+MDP_ADMIN="$(nouveau_mot_de_passe)"
+JETON_ADMIN="$(connexion "$EMAIL_ADMIN" "$MDP_TEMPORAIRE_ADMIN")"
+JETON_ADMIN="$(changer_mot_de_passe "$JETON_ADMIN" "$MDP_TEMPORAIRE_ADMIN" "$MDP_ADMIN")"
+
+EMAIL_LECTEUR="test-lecteur-$SUFFIXE@enervision.fr"
+EMAIL_OPERATEUR="test-operateur-$SUFFIXE@enervision.fr"
+journal "création du lecteur et de l'opérateur"
+TEMPORAIRE_LECTEUR="$(creer_compte "$JETON_ADMIN" "$EMAIL_LECTEUR" lecteur)"
+MDP_LECTEUR="$(activer_compte "$EMAIL_LECTEUR" "$TEMPORAIRE_LECTEUR")"
+TEMPORAIRE_OPERATEUR="$(creer_compte "$JETON_ADMIN" "$EMAIL_OPERATEUR" operateur)"
+MDP_OPERATEUR="$(activer_compte "$EMAIL_OPERATEUR" "$TEMPORAIRE_OPERATEUR")"
+
+umask 077
+jq -n \
+    --arg ae "$EMAIL_ADMIN" --arg ap "$MDP_ADMIN" \
+    --arg le "$EMAIL_LECTEUR" --arg lp "$MDP_LECTEUR" \
+    --arg oe "$EMAIL_OPERATEUR" --arg op "$MDP_OPERATEUR" \
+    '{
+        admin: {email: $ae, password: $ap},
+        lecteur: {email: $le, password: $lp},
+        operateur: {email: $oe, password: $op}
+    }' >"$COMPTES_FICHIER"
+journal "identifiants écrits dans $COMPTES_FICHIER"
@@ -0,0 +1,24 @@
+#!/usr/bin/env bash
+# Contrainte : prépare le scan DAST sur une base JETABLE - dast-token.sh. Crée les comptes de
+# test (scripts/comptes-test.sh, mêmes variables) et écrit sur la sortie standard le seul jeton
+# d'accès du `lecteur`.
+# 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.
+
+set -euo pipefail
+shopt -s inherit_errexit
+
+ICI="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+BASE_URL="${BASE_URL:-http://localhost:8000}"
+COMPTES="$(mktemp)"
+trap 'rm -f "$COMPTES"' EXIT
+
+COMPTES_FICHIER="$COMPTES" BASE_URL="$BASE_URL" "$ICI/comptes-test.sh"
+
+JETON="$(curl -fsS -X POST "$BASE_URL/api/v1/auth/login" -H 'Content-Type: application/json' \
+    -d "$(jq '.lecteur | {email, password}' "$COMPTES")" | jq -r '.access_token')"
+
+CODE="$(curl -sS -o /dev/null -w '%{http_code}' "$BASE_URL/api/v1/sites" -H "Authorization: Bearer $JETON")"
+[[ "$CODE" == "200" ]] || { echo "dast-token: GET /sites répond $CODE avec le jeton du lecteur, attendu 200" >&2; exit 1; }
+
+echo "$JETON"
@@ -1,23 +1,39 @@
 #!/usr/bin/env bash
-# Pourquoi : la machine porte deux environnements, chacun un clone du dépôt, un `.env` et un
-# projet Compose (ADR 0009). Ce script prépare la machine et les deux dossiers sans rien
-# démarrer : construction des images et démarrage restent à l'opérateur, puis au runner GitHub.
-# Rejouable : un dossier déjà cloné est réaligné sur sa branche, un `.env` existant n'est jamais
-# réécrit, un certificat présent n'est jamais régénéré.
+# Pourquoi : la machine porte trois environnements, chacun un clone du dépôt, un `.env` et un
+# projet Compose (ADR 0009, 0017), derrière un frontal SNI sur 443 (ADR 0018). Ce script prépare
+# la machine et les trois dossiers sans démarrer aucune stack : c'est le rôle du runner.
+# Piège : le script, et non le `.env.example` du clone, fait foi pour les secrets (GENERATEURS)
+# et l'adressage (tableau du bas). Un `.env` existant garde ses secrets, reçoit ceux qui lui
+# manquent et voit son adressage réaligné : sans ça, un `.env` né avant une clé ne la reçoit
+# jamais, et le clone de la prod, en retard sur `main`, ne connaîtrait pas les nouvelles.
+# Piège : lancé en root, git refuse un clone déjà chowné au runner (propriété douteuse). D'où
+# `safe.directory` passé en ligne de commande, seule portée où git l'accepte - preparer().
+# Rejouable : un certificat n'est refait que s'il ne couvre plus l'hôte, et celui de Let's Encrypt
+# n'est renouvelé qu'à échéance.

 set -euo pipefail

 DEPOT="${REPO_URL:-https://github.com/ineszang/ProjetPiscine_EnerVision.git}"
 RACINE="${RACINE:-/srv/enervision}"
+DOMAINE="${DOMAINE:-enervision-g3.dynv6.net}"
 ADRESSE="${PUBLIC_IP:-$(hostname -I | awk '{print $1}')}"
 PROPRIETAIRE="${PROPRIETAIRE:-${SUDO_USER:-}}"
+JETON_DNS="$RACINE/dns.token"
 COMPOSE_MINIMALE="2.24.4"

 erreur() { echo "erreur : $*" >&2; exit 1; }
 secret() { openssl rand -base64 48 | tr -d '/+=\n' | cut -c1-48; }
+court() { secret | cut -c1-20; }
 # Clé Fernet : 32 octets en base64 urlsafe, padding compris.
 fernet() { openssl rand -base64 32 | tr '+/' '-_'; }

+declare -A GENERATEURS=(
+    [POSTGRES_PASSWORD]=secret [APP_SECRET_KEY]=secret [AIRFLOW_FERNET_KEY]=fernet
+    [AIRFLOW_API_SECRET_KEY]=secret [AIRFLOW_JWT_SECRET]=secret [AIRFLOW_ADMIN_PASSWORD]=court
+    [AIRFLOW_APP_SECRET_KEY]=secret [APP_METRICS_TOKEN]=secret [GRAFANA_ADMIN_PASSWORD]=court
+    [SUPERVISION_DB_PASSWORD]=secret
+)
+
 verifier_outils() {
    for outil in git make openssl curl; do
        command -v "$outil" >/dev/null || erreur "$outil absent (apt-get install $outil)"
@@ -33,81 +49,180 @@ verifier_outils() {
    echo "docker compose $version, sortie Internet : ok"
 }

+valeur() { sed -n "s/^$2=//p" "$1" | tail -1; }
+
+poser() {
+    local fichier="$1" cle="$2" contenu="$3"
+    if grep -q "^$cle=" "$fichier"; then
+        CLE="$cle" CONTENU="$contenu" awk -F= '
+            $1 == ENVIRON["CLE"] { print ENVIRON["CLE"] "=" ENVIRON["CONTENU"]; next } { print }
+        ' "$fichier" > "$fichier.tmp"
+        mv "$fichier.tmp" "$fichier"
+    else
+        printf '%s=%s\n' "$cle" "$contenu" >> "$fichier"
+    fi
+}
+
 preparer() {
-    local env="$1" branche="$2" hote="$3" origine="$4"
-    local port_https="$5" port_http="$6" port_pg="$7" port_mailpit="$8" port_airflow="$9"
+    local env="$1" branche="$2" hote="$3"
+    local port_https="$4" port_http="$5" port_front="$6" port_pg="$7" port_mailpit="$8"
+    local port_airflow="$9" profils="${10}" port_grafana="${11}" port_prometheus="${12}"
+    local port_alertmanager="${13}"
    local dossier="$RACINE/$env"
+    local fichier="$dossier/.env" brouillon="$dossier/.env.brouillon" cle oubliees ajoutees=""

    if [[ -d "$dossier/.git" ]]; then
-        git -C "$dossier" fetch --quiet origin "$branche"
-        git -C "$dossier" checkout --quiet "$branche"
-        git -C "$dossier" reset --quiet --hard "origin/$branche"
+        local git=(git -c "safe.directory=$dossier" -C "$dossier")
+        "${git[@]}" fetch --quiet origin "$branche"
+        "${git[@]}" checkout --quiet "$branche"
+        "${git[@]}" reset --quiet --hard "origin/$branche"
    else
        git clone --quiet --branch "$branche" "$DEPOT" "$dossier"
    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_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|" \
-            -e "s|^PUBLIC_ORIGIN=.*|PUBLIC_ORIGIN=$origine|" \
-            -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" > "$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%%=*}=" "$brouillon" || echo "$cle" >> "$brouillon"
-        done
-        # 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."
+    local masque
+    masque="$(umask)"
+    umask 077
+    if [[ -f "$fichier" ]]; then
+        cp -p "$fichier" "$brouillon"
+        awk -F= 'NR == FNR { connues[$1]; next } /^[A-Z_][A-Z0-9_]*=/ && !($1 in connues)' \
+            "$fichier" "$dossier/.env.example" >> "$brouillon"
+    else
+        cp "$dossier/.env.example" "$brouillon"
    fi

-    if [[ ! -f "$dossier/infra/proxy/tls/fullchain.pem" ]]; then
-        (cd "$dossier" && PUBLIC_HOST="$hote" PUBLIC_IP="$ADRESSE" ./scripts/tls-selfsigned.sh)
+    for cle in "${!GENERATEURS[@]}"; do
+        case "$(valeur "$brouillon" "$cle")" in
+            "" | change_me) poser "$brouillon" "$cle" "$("${GENERATEURS[$cle]}")"; ajoutees+=" $cle" ;;
+        esac
+    done
+
+    declare -A adressage=(
+        [PUBLIC_HOST]="$hote" [PUBLIC_ORIGIN]="https://$hote" [COMPOSE_PROJECT_NAME]="enervision-$env"
+        [PROXY_HTTPS_PORT]="$port_https" [PROXY_HTTP_PORT]="$port_http" [PROXY_FRONT_PORT]="$port_front"
+        [POSTGRES_PORT]="$port_pg" [MAILPIT_UI_PORT]="$port_mailpit" [AIRFLOW_PORT]="$port_airflow"
+        [COMPOSE_PROFILES]="$profils" [GRAFANA_PORT]="$port_grafana"
+        [PROMETHEUS_PORT]="$port_prometheus" [ALERTMANAGER_PORT]="$port_alertmanager"
+    )
+    for cle in "${!adressage[@]}"; do
+        poser "$brouillon" "$cle" "${adressage[$cle]}"
+    done
+
+    # 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 : clés sans générateur, .env inchangé : $oubliees"
    fi
-    echo "$env : $dossier sur $branche, $origine"
+    chmod 600 "$brouillon"
+    if [[ -f "$fichier" ]]; then
+        cat "$brouillon" > "$fichier"
+        rm -f "$brouillon"
+        echo "$env : .env réaligné sur le tableau${ajoutees:+, secrets ajoutés :$ajoutees}"
+    else
+        mv "$brouillon" "$fichier"
+        echo "$env : .env généré. Reste à renseigner APP_MOCK_API_USERNAME et APP_MOCK_API_PASSWORD."
+    fi
+    umask "$masque"
+
+    if ! openssl x509 -in "$dossier/infra/proxy/tls/fullchain.pem" -noout -checkhost "$hote" 2>/dev/null \
+        | grep -q " does match"; then
+        (cd "$dossier" && PUBLIC_HOST="$hote" PUBLIC_IP="$ADRESSE" ./scripts/tls-selfsigned.sh --force)
+    fi
+    if [[ -r "$JETON_DNS" && "$hote" != *.local ]]; then
+        make -C "$dossier" --no-print-directory tls-dns01 PUBLIC_HOST="$hote" \
+            || echo "$env : pas de certificat Let's Encrypt, l'auto-signé reste en place" >&2
+    fi
+    echo "$env : $dossier sur $branche, https://$hote"
+}
+
+# Pourquoi : dynv6 est le fournisseur que le filtrage de l'école laisse passer (ADR 0018). Le
+# jeton passe par l'environnement du seul processus Python, jamais par `argv`.
+publier_dns() {
+    [[ -r "$JETON_DNS" ]] || { echo "pas de jeton $JETON_DNS : ni DNS ni Let's Encrypt"; return 0; }
+    DNS_TOKEN="$(tr -d '[:space:]' < "$JETON_DNS")" python3 - "$DOMAINE" "$ADRESSE" rec dev <<'PY' \
+        || echo "DNS : dynv6 refuse la mise à jour de $DOMAINE, enregistrements inchangés" >&2
+import json, os, sys, time, urllib.request
+
+domaine, adresse, *sous_noms = sys.argv[1:]
+
+def appel(methode, chemin, corps=None):
+    requete = urllib.request.Request(
+        f"https://dynv6.com/api/v2/{chemin}", method=methode,
+        data=None if corps is None else json.dumps(corps).encode(),
+        headers={"Authorization": f"Bearer {os.environ['DNS_TOKEN']}", "User-Agent": "enervision-provision",
+                 "Content-Type": "application/json", "Accept": "application/json"})
+    with urllib.request.urlopen(requete, timeout=60) as reponse:
+        contenu = reponse.read()
+    return json.loads(contenu) if contenu else None
+
+def synchroniser():
+    zone = appel("GET", f"zones/by-name/{domaine}")
+    if zone.get("ipv4address") != adresse:
+        appel("PATCH", f"zones/{zone['id']}", {"ipv4address": adresse})
+    existants = {(r["type"], r["name"]): r for r in appel("GET", f"zones/{zone['id']}/records")}
+    for nom in sous_noms:
+        actuel = existants.get(("A", nom))
+        if actuel is None:
+            appel("POST", f"zones/{zone['id']}/records", {"type": "A", "name": nom, "data": adresse})
+        elif actuel["data"] != adresse:
+            appel("PATCH", f"zones/{zone['id']}/records/{actuel['id']}", {"data": adresse})
+
+# dynv6 laisse parfois une écriture sans réponse, appliquée ou non : chaque essai relit l'état
+# avant d'écrire, si bien qu'une création aboutie malgré le délai n'est jamais dupliquée.
+for essai in range(3):
+    try:
+        synchroniser()
+        break
+    except OSError:
+        if essai == 2:
+            raise
+        time.sleep(5)
+print(f"DNS : {domaine}, {', '.join(sous_noms)} visent {adresse}")
+PY
+}
+
+planifier_renouvellement() {
+    [[ "$(id -u)" -eq 0 && -n "$PROPRIETAIRE" && -d /etc/cron.d ]] || return 0
+    cat > /etc/cron.d/enervision-tls <<CRON
+# Renouvellement Let's Encrypt des trois environnements (ADR 0018), écrit par provision-host.sh.
+PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
+23 4 * * * $PROPRIETAIRE for e in prod rec dev; do make -C $RACINE/\$e --no-print-directory tls-dns01; done 2>&1 | logger -t enervision-tls
+CRON
+    chmod 644 /etc/cron.d/enervision-tls
+    echo "renouvellement planifié : /etc/cron.d/enervision-tls"
 }

 verifier_outils
 mkdir -p "$RACINE"
+publier_dns

-#        env   branche  hôte                  origine                            https  http            pg    mailpit airflow
-preparer prod  main     enervision.local      https://enervision.local           443    80              5433  8025    8080
-preparer rec   dev      rec.enervision.local  https://rec.enervision.local:8443  8443   127.0.0.1:8081  5434  8026    8082
+# Supervision active en prod seulement (ADR 0016). Le frontal (infra/front) publie 80 et 443 et
+# relaie vers les ports `front` ; les stacks ne publient plus rien hors de la boucle locale.
+#        env   branche  hôte            https            http             front            pg    mailpit airflow profils    grafana prometheus alertmanager
+preparer prod  main     "$DOMAINE"      127.0.0.1:10443  127.0.0.1:10080  127.0.0.1:10444  5433  8025    8080    monitoring 3001    9090       9093
+preparer rec   dev      "rec.$DOMAINE"  127.0.0.1:8443   127.0.0.1:8081   127.0.0.1:8444   5434  8026    8082    ""         3002    9091       9094
+preparer dev   dev      "dev.$DOMAINE"  127.0.0.1:9443   127.0.0.1:8083   127.0.0.1:9444   5435  8027    8084    ""         3003    9092       9095

+planifier_renouvellement
 if [[ -n "$PROPRIETAIRE" && "$(id -u)" -eq 0 ]]; then
    chown -R "$PROPRIETAIRE" "$RACINE"
 fi

 cat <<FIN

-Démarrage, dans chaque dossier : make stack-up, qui applique aussi les migrations.
+Démarrage, dans chaque dossier : make stack-up, qui applique aussi les migrations. Puis, une
+fois, depuis $RACINE/prod : make front-up, que chaque déploiement de la prod rejoue ensuite.
 Premier administrateur, stack démarrée, dans chaque dossier :
  docker compose -f docker-compose.yml -f docker-compose.prod.yml exec backend \\
      python -m app.cli create-admin --email <adresse>
-Le runner GitHub Actions (label eni-g3) rejouera le déploiement à chaque push sur dev et main.
+Le runner GitHub Actions (label eni-g3) rejouera le déploiement à chaque push sur dev et main,
+et déploiera dans dev toute autre branche lancée à la main depuis l'onglet Actions.
 L'installer sous le propriétaire de $RACINE, sinon git refuse ces dépôts et le .env en 600 lui
 échappe : relancer au besoin ce script avec PROPRIETAIRE=<utilisateur du runner>.
 Données historiques : git ne porte pas data/raw, déposer les fichiers dans chaque dossier avant
 de déclencher le DAG historical_import.
-Depuis un poste : ajouter « $ADRESSE enervision.local rec.enervision.local » à /etc/hosts.
+Noms et certificats : le jeton dynv6 de la zone $DOMAINE doit se trouver dans $JETON_DNS (600,
+propriétaire du runner). Sans lui, ni enregistrement DNS ni Let's Encrypt : auto-signé.
 FIN
@@ -2,18 +2,16 @@ sonar.projectKey=ProjetPiscine_EnerVision
 sonar.organization=groupe3-ener-vision
 sonar.sourceEncoding=UTF-8

-#  Dossier contenant le code source
 sonar.sources=apps/frontend/src,apps/backend,ml,etl/airflow
-#  Dossier contenant les tests
 sonar.tests=apps/frontend/src,apps/backend/tests,ml/tests,etl/airflow/tests
-sonar.test.inclusions=**/*.spec.ts,**/*.test.ts,**/*test_*.py,**/*test.py
+sonar.test.inclusions=**/*.spec.ts,**/*.test.ts,**/test_*.py,**/*_test.py

-#  Liste des fichiers et dossiers à exclure de l'analyse
-sonar.exclusions=.pytest_cache,.venv,.airflow_home,alembic,tests,ml/data/**,ml/models/**,ml/mlruns/**,ml/mlartifacts/**,**/*/node_modules/**,**/*/dist/**,**/*/build/**,**/*.spec.ts,**/*.test.ts,**/*test_*.py,**/*test.py,**/*.spec.ts
+# Piège : un motif sans `**` (`alembic`, `tests`) ne vise que la racine du dépôt. Les dossiers de
+# tests restent donc exclus des sources ici, sans quoi leurs fixtures comptent en code non couvert.
+sonar.exclusions=**/.pytest_cache/**,**/.venv/**,**/.airflow_home/**,**/node_modules/**,**/dist/**,**/build/**,**/htmlcov/**,**/coverage/**,**/tests/**,**/alembic/**,ml/data/**,ml/models/**,ml/mlruns/**,ml/mlartifacts/**,**/*.spec.ts,**/*.test.ts,**/test_*.py,**/*_test.py

-#  Chemin vers le rapport de couverture de code
-#  Fichier généré par Pytest
+# Rapports versés par les jobs de backend.yml, ml.yml et frontend.yml, repris par le job sonar de ci.yml.
 sonar.python.coverage.reportPaths=apps/backend/coverage.xml,ml/coverage.xml
-#  Les DAGs n'ont pas de couverture mesurable : leurs tests ne font que les charger (DagBag)
-sonar.coverage.exclusions=etl/airflow/**
 sonar.javascript.lcov.reportPaths=apps/frontend/coverage/frontend/lcov.info
+# Les DAGs n'ont pas de couverture mesurable : leurs tests ne font que les charger (DagBag).
+sonar.coverage.exclusions=etl/airflow/**
@@ -0,0 +1,4 @@
+{
+  "printWidth": 100,
+  "singleQuote": true
+}
@@ -0,0 +1,61 @@
+# Tests de bout en bout (Playwright)
+
+Parcours utilisateur joués dans Chromium contre une stack qui tourne : frontend, API, base et,
+en CI, le reverse proxy TLS. Issue #46, décisions dans l'ADR 0015.
+
+## Ce qui est couvert
+
+| Fichier | Parcours |
+|---|---|
+| `authentification.spec.ts` | Redirection sans session, identifiants refusés, connexion, session conservée au rechargement, déconnexion |
+| `premiere-connexion.spec.ts` | Compte neuf : changement du mot de passe temporaire imposé avant le tableau de bord |
+| `roles.spec.ts` | Lecteur et opérateur sans supervision ni génération, page admin refusée ; admin sur la santé des capteurs |
+| `sites.spec.ts` | Liste des sites, détail (mesure instantanée, historique), recommandations filtrées sur le site |
+| `recommandations.spec.ts` | Génération par l'admin, bilan, isolement d'une alerte (`?alert=`) |
+| `alertes.spec.ts` | Pagination du fil (« Afficher plus »), filtres par sévérité et par site, fil vide |
+| `mot-de-passe-oublie.spec.ts` | Lien invalide refusé ; réinitialisation par le lien reçu dans Mailpit |
+
+Les parcours s'appuient sur le jeu `db/seeds/demo.sql` (sites `demo-*`) et sur les comptes créés
+par `scripts/comptes-test.sh`.
+
+## Lancer en local, contre `make dev`
+
+```bash
+make e2e-install     # une fois : dépendances et Chromium
+make dev             # dans un autre terminal
+make e2e-prepare     # sème demo.sql et crée les comptes test-* dans la base de dev
+make e2e             # joue les parcours contre http://localhost:4200
+```
+
+`make e2e-prepare` écrit dans la base de `make dev` : trois sites `demo-*`, quatorze alertes et
+des comptes `test-*`, dont un administrateur supplémentaire. Ne jamais le lancer contre la
+recette ou la prod.
+
+Rapport HTML : `cd tests/e2e && npx playwright show-report`.
+
+## En CI
+
+Le workflow `e2e.yml`, appelé par `ci.yml` dès que le frontend, l'API, le proxy, les fichiers
+Compose ou ces tests changent :
+
+1. construit et démarre `db`, `mailpit`, `backend`, `frontend` et `proxy` avec
+   `docker-compose.prod.yml`, sur `https://localhost` et un certificat auto-signé ;
+2. migre, sème `demo.sql`, crée les comptes ;
+3. joue les parcours, puis publie `playwright-report` en artefact (traces au premier réessai).
+
+## Règles d'écriture
+
+- Sélecteurs par rôle, libellé ou `data-testid`, jamais par classe CSS de mise en page.
+- Une session par fichier (`ouvrirSession` dans `beforeAll`, mode `serial`). Rejouer un cookie
+  de refresh dans un autre contexte révoque la famille de session, donc pas de `storageState`
+  partagé.
+- Un seul worker : la zone `auth` de nginx admet 30 connexions par minute.
+- Un parcours qui consomme un compte (premier login, réinitialisation) le crée lui-même par
+  l'API (`creerCompteTemporaire`), pour qu'un nouvel essai ne retombe pas sur un compte déjà
+  activé.
+
+| Variable | Défaut | Rôle |
+|---|---|---|
+| `E2E_BASE_URL` | `http://localhost:4200` | Origine du frontend. Doit figurer dans `APP_CORS_ORIGINS` |
+| `E2E_COMPTES` | aucun, requis | JSON écrit par `scripts/comptes-test.sh` |
+| `E2E_MAILPIT_URL` | `http://localhost:8025` | API de Mailpit, pour le lien de réinitialisation |
--- a/Show More
+++ b/Show More