Merge remote-tracking branch 'origin/dev' into pr117-fix

fix(infra): lève les points de revue du reverse proxy
Compose interpole tout le fichier avant n'importe quelle sous-commande : la garde `${PUBLIC_HOST:?}` de l'overlay cassait `stack-down` et `stack-logs` autant que le démarrage. La valeur retombe sur `enervision.local`, et `stack-up` vérifie à la place que le certificat présent couvre l'hôte demandé, ce qui est la condition réelle à tenir. La CSP `script-src 'self'` bloquait le gestionnaire `onload` que l'inlining du CSS critique d'Angular pose sur la feuille de styles : l'application se serait affichée sans style derrière le proxy. `inlineCritical` passe à faux, le build de production ne produit plus aucun script en ligne. La zone de limitation resserrée ne couvre plus que les routes qui vérifient un secret. Derrière le NAT de l'école, où une seule adresse porte toute la promotion, `/auth/me` et `/auth/refresh` y auraient produit des 429 en usage normal. Enfin `certbot/certbot` est épinglé en v5.8.0 pour que Dependabot puisse le suivre, le proxy attend une API saine plutôt que démarrée, et la redirection vers `$host` est actée comme risque accepté : figer un nom canonique couperait l'accès par adresse IP, seule voie ouverte sur la machine cible.
2026-09-21 12:11:39 +02:00 · 2026-09-21 12:11:32 +02:00 · 2026-09-21 11:42:55 +02:00 · 2026-09-21 11:39:00 +02:00 · 2026-09-21 11:38:52 +02:00 · 2026-09-21 11:24:42 +02:00
45 changed files with 3604 additions and 62 deletions
@@ -17,9 +17,34 @@ APP_LOG_LEVEL=INFO
 APP_SECRET_KEY=change_me
 APP_CORS_ORIGINS=http://localhost:4200
 BACKEND_PORT=8000
+FRONTEND_PORT=3000
+
+# Mailpit capture les courriels du backend, rien ne sort vers l'extérieur.
+MAILPIT_SMTP_PORT=1025
+MAILPIT_UI_PORT=8025

 # API Mock EnerVision
 APP_MOCK_API_BASE_URL=https://api-mock.charlieandre.fr
 APP_MOCK_API_USERNAME=change_me
 APP_MOCK_API_PASSWORD=change_me
 APP_MOCK_API_TIMEOUT_SECONDS=10
+
+# Airflow (webserver + scheduler, LocalExecutor). Base de métadonnées dédiée `airflow` dans le
+# même conteneur `db` (cf. db/init/120-airflow-database.sql), pas un conteneur de plus.
+AIRFLOW_PORT=8080
+# Chiffre les connexions/variables stockées par Airflow. Générer la vôtre :
+# python -c "from cryptography.fernet import Fernet; print(Fernet.generate_key().decode())"
+AIRFLOW_FERNET_KEY=change_me
+# Clé Flask du webserver Airflow (signature de session), distincte de la précédente. Générer la
+# vôtre : python -c "import secrets; print(secrets.token_urlsafe(48))"
+AIRFLOW_WEBSERVER_SECRET_KEY=change_me
+AIRFLOW_ADMIN_USERNAME=admin
+# Compte Airflow créé au premier démarrage (service `airflow-init`), sans rapport avec les
+# comptes `app_user` d'EnerVision.
+AIRFLOW_ADMIN_PASSWORD=change_me
+AIRFLOW_ADMIN_EMAIL=admin@enervision.fr
+
+# Stack complète derrière le reverse proxy (docker-compose.prod.yml).
+# PUBLIC_HOST alimente l'origine CORS, le lien de réinitialisation et le certificat.
+PUBLIC_HOST=enervision.local
+ACME_EMAIL=
@@ -38,3 +38,9 @@ updates:
    directory: "/apps/frontend"
    schedule:
      interval: "weekly"
+
+  # Images du reverse proxy et du compagnon ACME, épinglées dans les fichiers Compose
+  - package-ecosystem: "docker-compose"
+    directory: "/"
+    schedule:
+      interval: "weekly"
@@ -0,0 +1,84 @@
+name: Airflow
+
+# Piège : la version de Python vient de etl/airflow/.python-version. C'est 3.12 et non 3.14
+# (contrairement à backend.yml et ml.yml) : apache-airflow 2.10 ne supporte pas 3.14. Le 3.14 de
+# ml/ ne vit que dans l'image Docker, dans son propre environnement (cf. etl/airflow/Dockerfile).
+#
+# Piège : l'image COPY les fichiers de dépendances et le code de ml/. Une modification de ml/
+# peut donc casser sa construction, d'où ces chemins dans les déclencheurs.
+
+on:
+  push:
+    paths:
+      - "etl/airflow/**"
+      - "ml/pyproject.toml"
+      - "ml/uv.lock"
+      - "ml/enervision_ml/**"
+      - ".github/workflows/airflow.yml"
+  pull_request:
+    paths:
+      - "etl/airflow/**"
+      - "ml/pyproject.toml"
+      - "ml/uv.lock"
+      - "ml/enervision_ml/**"
+      - ".github/workflows/airflow.yml"
+
+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
+    defaults:
+      run:
+        working-directory: etl/airflow
+
+    steps:
+      - name: Récupère le dépôt
+        uses: actions/checkout@v4
+
+      - name: Installe uv
+        uses: astral-sh/setup-uv@v5
+        with:
+          enable-cache: true
+          cache-dependency-glob: etl/airflow/uv.lock
+
+      - 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: Vérifie le formatage
+        run: uv run ruff format --check .
+
+      - name: Analyse statique
+        run: uv run ruff check --output-format=github .
+
+      # Aucun test ne lance de tâche ni de scheduler : DagBag charge les fichiers de dags/ et
+      # vérifie import, planification, plafonds d'exécution et commande de chaque tâche.
+      - name: Tests d'intégrité des DAGs
+        run: uv run pytest
+
+  image:
+    name: Construction de l'image
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Récupère le dépôt
+        uses: actions/checkout@v4
+
+      - name: Construit l'image (contexte à la racine, elle COPY ml/)
+        run: docker build -f etl/airflow/Dockerfile -t enervision-airflow:ci .
+
+      # Vérifie ce qui ne casse qu'à l'exécution, pas à la construction : libgomp1 absent
+      # (`OSError: libgomp.so.1` au premier import) ou environnement ml/ non figé.
+      - name: Vérifie que le pipeline ML s'importe sans réseau
+        run: >
+          docker run --rm --network none enervision-airflow:ci
+          bash -c "cd /opt/ml && env -u VIRTUAL_ENV uv run --no-sync python -m enervision_ml.train --help"
@@ -66,6 +66,12 @@ ml/mlruns/
 ml/mlartifacts/
 ml/mlflow.db

+# 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
+
 # IDE et OS
 .idea/
 .vscode/
@@ -1,17 +1,31 @@
 BACKEND := apps/backend
 FRONTEND := apps/frontend
 ML := ml
+AIRFLOW := etl/airflow
+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.
+# PUBLIC_HOST retombe sur le `.env`, que make ne lit pas, puis sur la valeur de `.env.example`.
+PUBLIC_HOST ?= $(shell sed -n 's/^PUBLIC_HOST=//p' .env 2>/dev/null | tail -1)
+PUBLIC_HOST := $(or $(strip $(PUBLIC_HOST)),enervision.local)
+export PUBLIC_HOST
+ifdef ACME_EMAIL
+export ACME_EMAIL
+endif

 .DEFAULT_GOAL := help
-.PHONY: help install install-backend install-frontend install-ml dev dev-backend dev-frontend \
+.PHONY: help install install-backend install-frontend install-ml install-airflow \
+        dev dev-backend dev-frontend \
        lint format typecheck test test-cov test-integration check \
        openapi docker-build db-up db-down db-reset db-logs db-psql migrate bootstrap-admin \
-        ml-lint ml-typecheck ml-test ml-check ml-train ml-score recommendations
+        ml-lint ml-typecheck ml-test ml-check ml-train ml-score 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

 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}'

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

 install-backend: ## Installe les dépendances du backend
 	cd $(BACKEND) && uv sync --all-groups
@@ -22,6 +36,9 @@ install-frontend: ## Installe les dépendances du frontend
 install-ml: ## Installe les dépendances du pipeline ML
 	cd $(ML) && uv sync --all-groups

+install-airflow: ## Installe les dépendances de lint/test des DAGs Airflow
+	cd $(AIRFLOW) && uv sync --all-groups
+
 dev: ## Lance toute la stack (backend + frontend) en rechargement à chaud
 	@trap 'kill 0' EXIT INT TERM; \
 	$(MAKE) --no-print-directory dev-backend & \
@@ -80,9 +97,56 @@ ml-score: ## Score le prochain pas horaire et l'ecrit dans `prediction`. CSV=che
 recommendations: ## Genere les recommandations depuis les alertes en base. SITE=identifiant optionnel
 	cd $(BACKEND) && uv run python -m app.cli generate-recommendations $(if $(SITE),--site-id $(SITE),)

+airflow-lint: ## Analyse statique des DAGs Airflow
+	cd $(AIRFLOW) && uv run ruff check .
+
+airflow-test: ## Verifie que les DAGs s'importent sans erreur et ont la structure attendue
+	cd $(AIRFLOW) && uv run pytest
+
+airflow-check: airflow-lint airflow-test ## Chaîne de vérification complète des DAGs Airflow
+
+airflow-up: ## Démarre Airflow (webserver + scheduler, LocalExecutor). db-up requis avant.
+	docker compose up -d airflow-init airflow-webserver airflow-scheduler
+	@echo "airflow  -> http://localhost:$${AIRFLOW_PORT:-8080}"
+
+airflow-down: ## Arrête le webserver et le scheduler Airflow
+	docker compose stop airflow-webserver airflow-scheduler
+
+airflow-logs: ## Suit les journaux du scheduler Airflow (où tournent les tâches, LocalExecutor)
+	docker compose logs -f airflow-scheduler
+
 docker-build: ## Construit l'image du backend
 	docker build -t enervision-backend:local $(BACKEND)

+tls-selfsigned: ## Génère le certificat de démonstration. PUBLIC_HOST=..., FORCE=1 pour écraser
+	./scripts/tls-selfsigned.sh $(if $(FORCE),--force,)
+
+stack-up: ## Démarre la stack complète derrière le reverse proxy (80/443). PUBLIC_HOST=... au besoin
+	@test -f infra/proxy/tls/fullchain.pem \
+		|| { 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; }
+	$(COMPOSE_PROD) up -d --build
+
+stack-down: ## Arrête la stack complète en conservant les données
+	$(COMPOSE_PROD) stop
+
+stack-logs: ## Suit les journaux du reverse proxy
+	$(COMPOSE_PROD) logs -f proxy
+
+tls-acme: ## Demande un certificat Let's Encrypt. PUBLIC_HOST public et ACME_EMAIL requis
+	@test "$(PUBLIC_HOST)" != enervision.local \
+		|| { echo "PUBLIC_HOST doit être un domaine public résolvable, pas le nom de démonstration"; exit 1; }
+	$(COMPOSE_PROD) --profile acme run --rm certbot certonly --webroot -w /var/www/certbot \
+		-d $(PUBLIC_HOST) \
+		--email $${ACME_EMAIL:?ACME_EMAIL=... requis} \
+		--agree-tos --no-eff-email --deploy-hook /deploy-hook.sh
+	$(COMPOSE_PROD) exec proxy nginx -s reload
+
+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
+
 db-up: ## Démarre la base PostgreSQL TimescaleDB
 	docker compose up -d db

@@ -23,6 +23,7 @@ Ce que la documentation apporte à chacun : [docs/architecture/00-vue-ensemble.m
 | Base       | PostgreSQL 17 + TimescaleDB         | `db`                | Initialise    |
 | ETL        | Apache Airflow                      | `etl/airflow`       | A initialiser |
 | Infra      | Terraform (k3s single-node)         | `infra/terraform`   | Initialise    |
+| Reverse proxy | Nginx, TLS                       | `infra/proxy`       | En place      |
 | CI/CD      | GitHub Actions                      | `.github/workflows` | Backend en place |
 | Monitoring | Prometheus, Grafana, Alertmanager   | `monitoring`        | A initialiser |
 | ML         | LightGBM, MLflow                    | `ml`                | Entrainement initialise |
@@ -51,9 +52,11 @@ L'etat detaille de chaque brique et les vues d'architecture sont dans
 │   ├── plugins/        Operateurs et hooks maison
 │   ├── include/        Requetes SQL et ressources des DAGs
 │   └── tests/          Tests d'integrite des DAGs
-├── infra/terraform/
-│   ├── modules/        Modules reutilisables
-│   └── environments/   Racines Terraform, une par environnement
+├── infra/
+│   ├── proxy/          Reverse proxy Nginx : terminaison TLS et routage
+│   └── terraform/
+│       ├── modules/        Modules reutilisables
+│       └── environments/   Racines Terraform, une par environnement
 ├── ml/                 Pipeline d'entrainement LightGBM, suivi MLflow
 ├── monitoring/
 │   ├── prometheus/     Collecte et regles d'alerte
@@ -98,6 +101,21 @@ Verifier que la base repond et que l'extension est chargee :
 curl -s localhost:8000/api/v1/health/ready
 ```

+## Stack complète derrière le reverse proxy
+
+Pour servir l'application comme sur la machine cible, en HTTPS et sous une seule origine.
+L'overlay emploie `!override` et `!reset`, donc **Docker Compose 2.24.4 ou plus récent** :
+
+```bash
+make tls-selfsigned PUBLIC_HOST=enervision.local   # certificat de démonstration
+make stack-up PUBLIC_HOST=enervision.local         # nginx en 80/443, rien d'autre n'est publié
+```
+
+Le navigateur avertit d'un émetteur inconnu : Let's Encrypt reste hors d'atteinte tant qu'aucun
+nom de domaine public ne résout vers la machine. Routage, mode ACME et renouvellement dans
+[`infra/proxy/README.md`](infra/proxy/README.md) ; la décision et ses motifs dans
+[l'ADR 0007](docs/adr/0007-terminaison-tls-et-reverse-proxy-nginx.md).
+
 ## Conventions

 - Branches : `feat/`, `fix/`, `chore/`, `docs/`, `test/` suivi d'un libelle court.
@@ -34,6 +34,11 @@
          },
          "configurations": {
            "production": {
+              "optimization": {
+                "styles": {
+                  "inlineCritical": false
+                }
+              },
              "budgets": [
                {
                  "type": "initial",
@@ -23,4 +23,11 @@ export const routes: Routes = [
    loadComponent: () =>
      import('./features/sites/site-detail/site-detail').then((m) => m.SiteDetail),
  },
+  {
+    path: 'monitoring/sensors',
+    canActivate: [authGuard],
+    data: { role: 'admin' },
+    loadComponent: () =>
+      import('./features/monitoring/sensor-status/sensor-status').then((m) => m.SensorStatusView),
+  },
 ];
@@ -0,0 +1,48 @@
+import { TestBed } from '@angular/core/testing';
+import { provideHttpClient } from '@angular/common/http';
+import { provideHttpClientTesting, HttpTestingController } from '@angular/common/http/testing';
+import { SensorsService } from './sensors.service';
+import { environment } from '../../../environments/environment';
+
+describe('SensorsService', () => {
+  let service: SensorsService;
+  let httpMock: HttpTestingController;
+
+  beforeEach(() => {
+    TestBed.configureTestingModule({
+      providers: [provideHttpClient(), provideHttpClientTesting()],
+    });
+    service = TestBed.inject(SensorsService);
+    httpMock = TestBed.inject(HttpTestingController);
+  });
+
+  afterEach(() => httpMock.verify());
+
+  it("appelle l'endpoint /sensors/status et retourne la réponse", () => {
+    let result: unknown;
+    service.getStatus().subscribe((r) => (result = r));
+
+    const req = httpMock.expectOne(`${environment.apiUrl}/sensors/status`);
+    expect(req.request.method).toBe('GET');
+
+    req.flush({
+      timestamp: '2026-09-18T08:00:00',
+      sites: [
+        {
+          site_id: 'SITE001',
+          site_name: 'Test',
+          overall: 'ok',
+          sensors: {
+            consumption: { status: 'ok', since: null },
+            electrical: { status: 'ok', since: null },
+            temperature: { status: 'ok', since: null },
+            humidity: { status: 'ok', since: null },
+            network: { status: 'ok', since: null },
+          },
+        },
+      ],
+    });
+
+    expect((result as { sites: unknown[] }).sites.length).toBe(1);
+  });
+});
@@ -0,0 +1,13 @@
+import { Service, inject } from '@angular/core';
+import { HttpClient } from '@angular/common/http';
+import { environment } from '../../../environments/environment';
+import {SensorStatusResponse} from '../../shared/models/sensor-status.model';
+
+@Service()
+export class SensorsService {
+  private http = inject(HttpClient);
+
+  getStatus() {
+    return this.http.get<SensorStatusResponse>(`${environment.apiUrl}/sensors/status`);
+  }
+}
@@ -10,6 +10,9 @@
      </div>
    </div>
    <div class="dashboard__actions">
+      @if (auth.principal()?.role === 'admin') {
+        <a routerLink="/monitoring/sensors" class="ev-link">Supervision des capteurs</a>
+      }
      <a routerLink="/sites" class="ev-link">Voir les sites</a>
      <ev-button
        class="logout-button"
@@ -68,6 +68,15 @@ h2 {
  text-align: center;
 }

+.card--link {
+  cursor: pointer;
+  transition: border-color 0.15s ease;
+
+  &:hover {
+    border-color: var(--color-primary);
+  }
+}
+
 .card__label {
  font-size: 0.8rem;
  color: var(--color-text-muted);
@@ -170,8 +170,11 @@ describe('Dashboard', () => {
  it('appelle logout et redirige vers /login au clic sur le bouton de déconnexion', () => {
  const statsMock = { getSummary: vi.fn().mockReturnValue(of({ total_sites: 7, sites: [] })) };
  const alertsMock = { getAlerts: vi.fn().mockReturnValue(of([])) };
-  const authMock = { logout: vi.fn().mockReturnValue(of(undefined)), clearSession: vi.fn() };
-
+  const authMock = {
+    logout: vi.fn().mockReturnValue(of(undefined)),
+    clearSession: vi.fn(),
+    principal: vi.fn().mockReturnValue({ role: 'admin' }),
+  };
  TestBed.configureTestingModule({
    imports: [Dashboard],
    providers: [
@@ -198,9 +201,10 @@ describe('Dashboard', () => {
  it('déconnecte localement et redirige vers /login même si logout échoue côté réseau', () => {
  const statsMock = { getSummary: vi.fn().mockReturnValue(of({ total_sites: 7, sites: [] })) };
  const alertsMock = { getAlerts: vi.fn().mockReturnValue(of([])) };
-  const authMock = {
+    const authMock = {
    logout: vi.fn().mockReturnValue(throwError(() => new Error('réseau indisponible'))),
    clearSession: vi.fn(),
+    principal: vi.fn().mockReturnValue({ role: 'admin' }),
  };
  TestBed.configureTestingModule({
    imports: [Dashboard],
@@ -59,8 +59,8 @@ const TON_PAR_STATUT_PREDICTION: Record<PredictionStatus, BadgeTone> = {
 export class Dashboard implements OnInit {
  private statsService = inject(StatsService);
  private alertsService = inject(AlertsService);
+  public auth = inject(AuthService);
  private predictionsService = inject(PredictionsService);
-  private auth = inject(AuthService);
  private router = inject(Router);
  private destroyRef = inject(DestroyRef);

@@ -0,0 +1,51 @@
+<div class="sensor-status">
+  <nav class="ev-breadcrumb">
+    <a routerLink="/dashboard">Tableau de bord</a>
+  </nav>
+
+  <header class="sensor-status__header">
+    <a routerLink="/dashboard" class="ev-brand-link">
+      <ev-brand class="sensor-status__logo" />
+    </a>
+    <div>
+      <h1>Supervision des capteurs</h1>
+      <p class="sensor-status__subtitle">État de santé par capteur et par site</p>
+    </div>
+  </header>
+
+  @if (error(); as message) {
+    <ev-alert severity="danger" class="banner-error">{{ message }}</ev-alert>
+  }
+
+  @if (data(); as d) {
+    <div class="sites-grid">
+      @for (site of d.sites; track site.site_id) {
+        <ev-card class="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>
+          </div>
+
+          <ul class="sensor-list">
+            @for (entry of sensorEntries; track entry[0]) {
+              @let diagnostic = sensorOf(site.sensors, entry[0]);
+              <li class="sensor-item">
+                <span class="sensor-dot" [class]="'sensor-dot--' + diagnostic.status"></span>
+                <span class="sensor-item__label">{{ entry[1] }}</span>
+                @if (diagnostic.status === 'failing') {
+                  <span class="sensor-item__since">
+                    @if (diagnostic.since; as since) {
+                      dernière lecture le {{ since | date: 'dd/MM/yyyy HH:mm' }}
+                    } @else {
+                      aucune lecture reçue
+                    }
+                  </span>
+                }
+              </li>
+            }
+          </ul>
+        </ev-card>
+      }
+    </div>
+  }
+</div>
@@ -0,0 +1,90 @@
+:host {
+  display: block;
+  color: var(--color-text);
+  padding: 2.5rem 2rem;
+  max-width: 1100px;
+  margin: 0 auto;
+}
+
+.sensor-status__header {
+  display: flex;
+  align-items: center;
+  gap: 0.85rem;
+  margin-bottom: 2rem;
+
+  h1 {
+    margin: 0;
+    font-size: 1.75rem;
+    font-weight: 700;
+  }
+}
+
+.sensor-status__logo {
+  font-size: 1.3rem;
+}
+
+.sensor-status__subtitle {
+  margin: 0.25rem 0 0;
+  color: var(--color-text-muted);
+}
+
+.banner-error {
+  display: block;
+  margin: 0 0 1.5rem;
+}
+
+.sites-grid {
+  display: grid;
+  grid-template-columns: repeat(auto-fit, minmax(260px, 1fr));
+  gap: 1rem;
+}
+
+.site-card__header {
+  display: flex;
+  align-items: center;
+  justify-content: space-between;
+  margin-bottom: 0.75rem;
+}
+
+.site-card__name {
+  font-weight: 600;
+}
+
+.sensor-list {
+  list-style: none;
+  margin: 0;
+  padding: 0;
+  display: flex;
+  flex-direction: column;
+  gap: 0.5rem;
+}
+
+.sensor-item {
+  display: flex;
+  align-items: center;
+  gap: 0.5rem;
+  font-size: 0.85rem;
+}
+
+.sensor-dot {
+  width: 8px;
+  height: 8px;
+  border-radius: 50%;
+  flex-shrink: 0;
+
+  &--ok {
+    background: var(--color-success);
+  }
+  &--failing {
+    background: var(--color-danger);
+  }
+}
+
+.sensor-item__label {
+  flex: 1;
+}
+
+.sensor-item__since {
+  color: var(--color-text-muted);
+  font-size: 0.75rem;
+}
@@ -0,0 +1,122 @@
+import { TestBed } from '@angular/core/testing';
+import { of, throwError } from 'rxjs';
+import { vi } from 'vitest';
+import { SensorStatusView } from './sensor-status';
+import { SensorsService } from '../../../core/services/sensors.service';
+import { SiteSensors } from '../../../shared/models/sensor-status.model';
+import {provideRouter} from '@angular/router';
+
+const OK_SENSORS: SiteSensors = {
+  consumption: { status: 'ok', since: null },
+  electrical: { status: 'ok', since: null },
+  temperature: { status: 'ok', since: null },
+  humidity: { status: 'ok', since: null },
+  network: { status: 'ok', since: null },
+};
+
+describe('SensorStatusView', () => {
+  let sensorsMock: { getStatus: ReturnType<typeof vi.fn> };
+
+  beforeEach(() => {
+    sensorsMock = { getStatus: vi.fn() };
+
+    TestBed.configureTestingModule({
+      imports: [SensorStatusView],
+      providers: [
+        { provide: SensorsService, useValue: sensorsMock },
+        provideRouter([]),
+      ],
+    });
+  });
+
+  it('charge et affiche les données au démarrage', () => {
+    sensorsMock.getStatus.mockReturnValue(
+      of({
+        timestamp: '2026-09-18T08:00:00',
+        sites: [
+          { site_id: 'SITE001', site_name: 'Bureau Test', overall: 'ok', sensors: OK_SENSORS },
+        ],
+      })
+    );
+
+    const fixture = TestBed.createComponent(SensorStatusView);
+    fixture.detectChanges();
+
+    expect(fixture.componentInstance.data()?.sites.length).toBe(1);
+    expect(fixture.componentInstance.error()).toBeNull();
+    expect(fixture.nativeElement.textContent).toContain('Bureau Test');
+  });
+
+  it("affiche un message d'erreur si l'appel échoue", () => {
+    sensorsMock.getStatus.mockReturnValue(throwError(() => new Error('boom')));
+
+    const fixture = TestBed.createComponent(SensorStatusView);
+    fixture.detectChanges();
+
+    expect(fixture.componentInstance.error()).toBe(
+      'État des capteurs indisponible, réessayez plus tard.'
+    );
+    expect(fixture.componentInstance.data()).toBeNull();
+    expect(fixture.nativeElement.textContent).toContain('État des capteurs indisponible');
+  });
+
+  it('associe le bon ton de badge à chaque statut global', () => {
+    sensorsMock.getStatus.mockReturnValue(of({ timestamp: '2026-09-18T08:00:00', sites: [] }));
+    const fixture = TestBed.createComponent(SensorStatusView);
+    const component = fixture.componentInstance;
+
+    expect(component.badgeToneForOverall('ok')).toBe('success');
+    expect(component.badgeToneForOverall('degraded')).toBe('warning');
+    expect(component.badgeToneForOverall('critical')).toBe('critical');
+    expect(component.badgeToneForOverall('inconnu')).toBe('neutral');
+  });
+
+  it('retourne le bon diagnostic via sensorOf', () => {
+    sensorsMock.getStatus.mockReturnValue(of({ timestamp: '2026-09-18T08:00:00', sites: [] }));
+    const fixture = TestBed.createComponent(SensorStatusView);
+    const component = fixture.componentInstance;
+
+    expect(component.sensorOf(OK_SENSORS, 'temperature')).toEqual({ status: 'ok', since: null });
+  });
+
+  it('affiche la date de la dernière lecture reçue pour un capteur en panne', () => {
+    const sensors: SiteSensors = {
+      ...OK_SENSORS,
+      temperature: { status: 'failing', since: '2026-09-18T08:00:00' },
+    };
+    sensorsMock.getStatus.mockReturnValue(
+      of({
+        timestamp: '2026-09-18T08:00:00',
+        sites: [{ site_id: 'SITE001', site_name: 'Bureau Test', overall: 'degraded', sensors }],
+      })
+    );
+
+    const fixture = TestBed.createComponent(SensorStatusView);
+    fixture.detectChanges();
+
+    expect(fixture.nativeElement.textContent).toContain('dernière lecture le');
+    expect(fixture.nativeElement.textContent).toContain('18/09/2026 08:00');
+  });
+
+  it("annonce l'absence de lecture quand un site n'en a jamais reçu", () => {
+    const sensors: SiteSensors = {
+      consumption: { status: 'failing', since: null },
+      electrical: { status: 'failing', since: null },
+      temperature: { status: 'failing', since: null },
+      humidity: { status: 'failing', since: null },
+      network: { status: 'failing', since: null },
+    };
+    sensorsMock.getStatus.mockReturnValue(
+      of({
+        timestamp: '2026-09-18T08:00:00',
+        sites: [{ site_id: 'SITE001', site_name: 'Bureau Test', overall: 'critical', sensors }],
+      })
+    );
+
+    const fixture = TestBed.createComponent(SensorStatusView);
+    fixture.detectChanges();
+
+    expect(fixture.nativeElement.textContent).toContain('aucune lecture reçue');
+    expect(fixture.nativeElement.textContent).not.toContain('dernière lecture le');
+  });
+});
@@ -0,0 +1,65 @@
+import { Component, OnInit, inject, signal } from '@angular/core';
+import { RouterLink } from '@angular/router';
+import { catchError, EMPTY, Observable } from 'rxjs';
+import {Badge, BadgeTone} from '../../../shared/components/ui/badge/badge';
+import {Card} from '../../../shared/components/ui/card/card';
+import {Alert} from '../../../shared/components/ui/alert/alert';
+import {Brand} from '../../../shared/components/ui/brand/brand';
+import {SensorsService} from '../../../core/services/sensors.service';
+import {SensorDiagnostic, SensorStatusResponse} from '../../../shared/models/sensor-status.model';
+import { DatePipe } from '@angular/common';
+
+const UNAVAILABLE_MESSAGE = 'État des capteurs indisponible, réessayez plus tard.';
+
+const SENSOR_LABELS: Record<string, string> = {
+  consumption: 'Consommation',
+  electrical: 'Électrique',
+  temperature: 'Température',
+  humidity: 'Humidité',
+  network: 'Réseau',
+};
+
+const TON_PAR_OVERALL: Record<string, BadgeTone> = {
+  ok: 'success',
+  degraded: 'warning',
+  critical: 'critical',
+};
+
+@Component({
+  selector: 'app-sensor-status',
+  standalone: true,
+  imports: [RouterLink, Card, Alert, Badge, Brand, DatePipe],
+  templateUrl: './sensor-status.html',
+  styleUrl: './sensor-status.scss',
+})
+export class SensorStatusView implements OnInit {
+  private sensorsService = inject(SensorsService);
+
+  data = signal<SensorStatusResponse | null>(null);
+  error = signal<string | null>(null);
+
+  readonly sensorEntries = Object.entries(SENSOR_LABELS);
+
+  ngOnInit(): void {
+    this.sensorsService
+      .getStatus()
+      .pipe(catchError(() => this.reportUnavailable()))
+      .subscribe((response) => {
+        this.error.set(null);
+        this.data.set(response);
+      });
+  }
+
+  sensorOf(sensors: Record<string, SensorDiagnostic>, key: string): SensorDiagnostic {
+    return sensors[key];
+  }
+
+  badgeToneForOverall(overall: string): BadgeTone {
+    return TON_PAR_OVERALL[overall] ?? 'neutral';
+  }
+
+  private reportUnavailable(): Observable<never> {
+    this.error.set(UNAVAILABLE_MESSAGE);
+    return EMPTY;
+  }
+}
@@ -0,0 +1,28 @@
+export type SensorStatus = 'ok' | 'failing';
+export type OverallStatus = 'ok' | 'degraded' | 'critical';
+
+export interface SensorDiagnostic {
+  status: SensorStatus;
+  since: string | null;
+}
+
+export interface SiteSensors {
+  consumption: SensorDiagnostic;
+  electrical: SensorDiagnostic;
+  temperature: SensorDiagnostic;
+  humidity: SensorDiagnostic;
+  network: SensorDiagnostic;
+  [key: string]: SensorDiagnostic;
+}
+
+export interface SiteSensorStatus {
+  site_id: string;
+  site_name: string;
+  sensors: SiteSensors;
+  overall: OverallStatus;
+}
+
+export interface SensorStatusResponse {
+  timestamp: string;
+  sites: SiteSensorStatus[];
+}
@@ -0,0 +1,5 @@
+-- Base de metadonnees Airflow (webserver + scheduler, LocalExecutor). Separee de la base
+-- applicative : les tables internes d'Airflow (dag_run, task_instance, ...) n'ont rien a faire
+-- dans le schema metier. Meme conteneur Postgres que `enervision`/`enervision_test` plutot qu'un
+-- service dedie, pour ne pas ajouter un conteneur de plus (issue #115).
+CREATE DATABASE airflow;
@@ -0,0 +1,74 @@
+# Piège : `APP_ENV` et `APP_DEBUG` sont en dur et non en `${APP_ENV:-prod}` : le `.env` du poste
+# vaut `local` et reprendrait le dessus, ce qui laisserait le cookie sans `__Secure-` et
+# rouvrirait `/docs`. Hors `local`, l'API exige en retour une origine CORS non vide.
+# Piège : les listes de ports se cumulent à la fusion des deux fichiers. `!reset` est le seul
+# moyen de dépublier 8000 et 3000 : sans lui, l'API resterait joignable en clair à côté du proxy.
+# Piège : pas de `:?` sur `PUBLIC_HOST`. Compose interpole tout le fichier, y compris pour
+# `stop` et `logs` : la garde vit dans `make stack-up`, qui la compare au certificat servi.
+
+name: enervision
+
+services:
+  db:
+    ports: !override
+      - "127.0.0.1:${POSTGRES_PORT:-5433}:5432"
+
+  mailpit:
+    ports: !override
+      - "127.0.0.1:${MAILPIT_UI_PORT:-8025}:8025"
+
+  airflow-webserver:
+    ports: !override
+      - "127.0.0.1:${AIRFLOW_PORT:-8080}:8080"
+
+  backend:
+    ports: !reset null
+    command:
+      - uvicorn
+      - app.main:create_app
+      - --factory
+      - --host
+      - 0.0.0.0
+      - --port
+      - "8000"
+      - --proxy-headers
+      - --forwarded-allow-ips=*
+    environment:
+      APP_ENV: prod
+      APP_DEBUG: "false"
+      APP_TRUST_PROXY_HEADERS: "true"
+      APP_CORS_ORIGINS: https://${PUBLIC_HOST:-enervision.local}
+      APP_FRONTEND_RESET_PASSWORD_URL: https://${PUBLIC_HOST:-enervision.local}/reset-password
+
+  frontend:
+    ports: !reset null
+
+  proxy:
+    image: nginx:1.28-alpine
+    depends_on:
+      backend:
+        condition: service_healthy
+      frontend:
+        condition: service_started
+    ports:
+      - "80:80"
+      - "443:443"
+    volumes:
+      - ./infra/proxy/nginx.conf:/etc/nginx/nginx.conf:ro
+      - ./infra/proxy/conf.d:/etc/nginx/conf.d:ro
+      - ./infra/proxy/tls:/etc/nginx/tls:ro
+      - acme_webroot:/var/www/certbot
+    restart: unless-stopped
+
+  certbot:
+    image: certbot/certbot:v5.8.0
+    profiles: ["acme"]
+    volumes:
+      - letsencrypt:/etc/letsencrypt
+      - acme_webroot:/var/www/certbot
+      - ./infra/proxy/tls:/tls
+      - ./infra/proxy/acme-deploy-hook.sh:/deploy-hook.sh:ro
+
+volumes:
+  acme_webroot:
+  letsencrypt:
@@ -5,6 +5,35 @@

 name: enervision

+# Piege : LocalExecutor fait tourner les taches comme sous-processus du scheduler, jamais du
+# webserver. `airflow_ml_state` (modele entraine, magasin MLflow) n'a donc besoin d'etre monte
+# que sur `airflow-scheduler` en pratique, mais reste partage avec le webserver pour que ce
+# dernier puisse au besoin l'inspecter sans en devenir dependant.
+x-airflow-common: &airflow-common
+  build:
+    context: .
+    dockerfile: etl/airflow/Dockerfile
+  environment: &airflow-common-env
+    AIRFLOW__CORE__EXECUTOR: LocalExecutor
+    AIRFLOW__CORE__LOAD_EXAMPLES: "false"
+    # Piege : pas de `:?` sur les secrets Airflow. Compose interpole le fichier entier avant de
+    # filtrer les services : une variable requise manquante casserait aussi `make db-up`,
+    # `make dev`... pour quiconque n'a pas encore complete son `.env`. Le refus est porte par
+    # `airflow-init` (ci-dessous), dont `webserver` et `scheduler` dependent.
+    AIRFLOW__CORE__FERNET_KEY: ${AIRFLOW_FERNET_KEY:-}
+    AIRFLOW__WEBSERVER__SECRET_KEY: ${AIRFLOW_WEBSERVER_SECRET_KEY:-}
+    AIRFLOW__DATABASE__SQL_ALCHEMY_CONN: postgresql+psycopg2://${POSTGRES_USER}:${POSTGRES_PASSWORD}@db:5432/airflow
+    # Role `enervision_ml` dedie pas encore provisionne (dette assumee, cf. ADR 0003) :
+    # 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
+  volumes:
+    - ./etl/airflow/dags:/opt/airflow/dags
+    - ./etl/airflow/plugins:/opt/airflow/plugins
+    - airflow_logs:/opt/airflow/logs
+    - airflow_ml_state:/opt/ml/state
+  restart: unless-stopped
+
 services:
  db:
    image: timescale/timescaledb-ha:pg17
@@ -19,6 +48,7 @@ services:
      - pgdata:/home/postgres/pgdata/data
      - ./db/init/100-extensions.sql:/docker-entrypoint-initdb.d/100-extensions.sql:ro
      - ./db/init/110-test-database.sql:/docker-entrypoint-initdb.d/110-test-database.sql:ro
+      - ./db/init/120-airflow-database.sql:/docker-entrypoint-initdb.d/120-airflow-database.sql:ro
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
      interval: 10s
@@ -68,9 +98,66 @@ services:
  frontend:
    build: ./apps/frontend
    ports:
-      - "${FRONTEND_PORT:-3000}:80"
+      - "${FRONTEND_PORT:-3000}:3000"
    restart: unless-stopped

+  # Conteneur unique, jamais redemarre. La migration et la creation du premier compte sont
+  # portees par l'entrypoint de l'image (`_AIRFLOW_DB_MIGRATE`, `_AIRFLOW_WWW_USER_*`), qui porte
+  # aussi leur code de sortie : une migration ratee (ex. base `airflow` absente sur un volume
+  # `pgdata` deja peuple) fait echouer ce service, et `webserver`/`scheduler`, qui attendent son
+  # succes, ne demarrent pas sur une base non migree. Le mot de passe passe par l'environnement,
+  # jamais par `argv` (ni `ps`, ni `docker compose config`).
+  # Sans mot de passe, l'entrypoint refuse lui-meme de creer le compte ; la commande ci-dessous
+  # refuse en plus les deux cles de chiffrement vides.
+  airflow-init:
+    <<: *airflow-common
+    restart: "no"
+    environment:
+      <<: *airflow-common-env
+      _AIRFLOW_DB_MIGRATE: "true"
+      _AIRFLOW_WWW_USER_CREATE: "true"
+      _AIRFLOW_WWW_USER_USERNAME: ${AIRFLOW_ADMIN_USERNAME:-admin}
+      _AIRFLOW_WWW_USER_PASSWORD: ${AIRFLOW_ADMIN_PASSWORD:-}
+      _AIRFLOW_WWW_USER_EMAIL: ${AIRFLOW_ADMIN_EMAIL:-admin@enervision.fr}
+    depends_on:
+      db:
+        condition: service_healthy
+    command:
+      - bash
+      - -c
+      - |
+        set -euo pipefail
+        : "$${AIRFLOW__CORE__FERNET_KEY:?AIRFLOW_FERNET_KEY manquant dans .env}"
+        : "$${AIRFLOW__WEBSERVER__SECRET_KEY:?AIRFLOW_WEBSERVER_SECRET_KEY manquant dans .env}"
+        exec airflow version
+
+  airflow-webserver:
+    <<: *airflow-common
+    command: webserver
+    ports:
+      - "${AIRFLOW_PORT:-8080}:8080"
+    depends_on:
+      db:
+        condition: service_healthy
+      airflow-init:
+        condition: service_completed_successfully
+    healthcheck:
+      test: ["CMD", "curl", "--fail", "http://localhost:8080/health"]
+      interval: 30s
+      timeout: 10s
+      retries: 5
+      start_period: 60s
+
+  airflow-scheduler:
+    <<: *airflow-common
+    command: scheduler
+    depends_on:
+      db:
+        condition: service_healthy
+      airflow-init:
+        condition: service_completed_successfully

 volumes:
  pgdata:
+  airflow_logs:
+  airflow_ml_state:
@@ -11,3 +11,6 @@
 | [0002](adr/0002-authentification-jwt-et-refresh-opaque.md) | Authentification par JWT d'accès et jeton de rafraîchissement opaque |
 | [0003](adr/0003-autorisation-rbac-a-trois-roles.md) | Autorisation RBAC à trois rôles, relecture du compte à chaque requête |
 | [0004](adr/0004-journal-d-audit-en-ajout-seul.md) | Journal d'audit en ajout seul, garanti par PostgreSQL |
+| [0005](adr/0005-modele-prediction-lightgbm.md) | LightGBM pour la prédiction de consommation, un modèle global |
+| [0006](adr/0006-moteur-de-regles-dans-le-backend.md) | Le moteur de règles de recommandation vit dans le backend, pas dans `ml/` |
+| [0007](adr/0007-terminaison-tls-et-reverse-proxy-nginx.md) | Terminaison TLS par un reverse proxy Nginx, en Docker Compose |
@@ -0,0 +1,120 @@
+# 0007 - Terminaison TLS par un reverse proxy Nginx, en Docker Compose
+
+- Statut : accepté
+- Date : 2026-09-21
+
+## Contexte
+
+Quatre documents désignaient le même trou. `10-infra.md` ouvrait ses questions par « Quel ingress
+remplace Traefik, et qui termine le TLS ». `00-vue-ensemble.md` rangeait « TLS, HSTS et CSP » dans
+« Absent, et assumé ». `owasp-traceabilite.md` laissait la ligne API8 transport ouverte.
+`31-contrat-authentification.md` listait deux corrections « à faire avant la démonstration » :
+servir le SPA et l'API sous la même origine, et servir en HTTPS.
+
+Ce n'est pas un durcissement facultatif, c'est une condition de fonctionnement. Les deux fichiers
+`apps/frontend/src/environments/environment*.ts` portent `apiUrl: '/api/v1'`, en relatif. En
+développement, `proxy.conf.json` route `/api` vers l'API. Une fois en conteneur, plus rien ne le
+fait : l'application déployée ne peut pas appeler son API. Et le cookie de rafraîchissement prend
+le préfixe `__Secure-` dès que `APP_ENV` sort de `local`, donc sans HTTPS il n'est jamais posé et
+l'authentification ne tient pas au rechargement de page.
+
+La contrainte qui cadre tout le reste : **aucun nom de domaine public n'existe**. La cible
+documentée est le serveur on-premise de l'école, `ssh_host = "10.0.0.10"` dans le
+`terraform.tfvars.example`. Sur une adresse privée, le défi HTTP-01 de Let's Encrypt ne peut pas
+aboutir, faute de DNS public et de port 80 entrant.
+
+## Décision
+
+**Un service `proxy` dans Docker Compose**, image officielle `nginx:1.28-alpine`, seul composant à
+publier des ports sur la machine : 80 et 443. Backend et frontend ne sont plus publiés du tout, la
+base et l'interface Mailpit sont ramenées sur la boucle locale. La stack complète est décrite par
+l'overlay `docker-compose.prod.yml`, le `docker-compose.yml` restant la boucle de développement.
+
+**Le SPA et l'API sont servis sous la même origine** : `/` vers le conteneur frontend, `/api/` vers
+l'API en préservant le préfixe `/api/v1`. Le CORS cesse d'être un mécanisme de production et
+redevient ce qu'il est, un filet pour les appels croisés qui ne devraient plus exister.
+
+**nginx lit toujours les deux mêmes fichiers**, `/etc/nginx/tls/fullchain.pem` et `privkey.pem`.
+Seule leur fabrication varie : un script `openssl` pour la démonstration, le `--deploy-hook` de
+certbot quand un domaine existera. La configuration nginx ne connaît pas la différence et n'aura
+pas à changer le jour de la bascule.
+
+**Le proxy pose HSTS et CSP**, que l'application refuse de poser. Ce refus est verrouillé par
+`tests/api/test_hardening.py::test_the_application_never_sets_hsts_itself` : l'application ne peut
+pas savoir si elle est jointe en HTTPS, le terminateur, si.
+
+## Pourquoi Compose et pas l'ingress k3s
+
+Le module `infra/terraform/modules/k3s/` installe un cluster et rien d'autre. Il ne déclare que le
+provider `null`, aucun namespace, aucun déploiement, aucun service, aucun ingress, et il n'a jamais
+été appliqué. Passer par un ingress supposait d'abord de combler tout ce qui manque entre les deux
+topologies : un registre d'images alimenté, des manifestes pour le front, l'API et la base, un
+stockage persistant pour PostgreSQL. C'est le chantier que `10-infra.md` nomme « le trou entre les
+deux topologies », et il ne tient pas dans le jalon.
+
+Compose, lui, fait déjà tourner les quatre services sur un réseau commun. Le proxy y entre comme un
+cinquième service, sans rien déplacer. La décision de désactiver Traefik reste valable : le choix
+d'ingress n'est pas tranché ici, il est repoussé avec le reste de la bascule Kubernetes.
+
+## Ce que le proxy n'expose pas, et pourquoi c'est structurel
+
+`/docs`, `/redoc`, `/openapi.json`, `/static` et `/metrics` sont montés par l'API **à la racine**,
+pas sous le préfixe `/api`. Avec un routage où seul `/api/` part vers l'API, ils tombent dans
+`location /`, donc sur le SPA, donc hors d'atteinte publique. Aucune règle de blocage n'est
+nécessaire, et il n'y en a pas : le jour où quelqu'un routera la racine vers l'API pour « réparer »
+Swagger, il publiera les métriques avec.
+
+## Conséquences
+
+- `APP_ENV`, `APP_DEBUG`, `APP_CORS_ORIGINS`, `APP_TRUST_PROXY_HEADERS` et le TLS changent
+  ensemble, dans le même fichier. Hors `local`, la configuration refuse de démarrer sans origine
+  CORS, et le cookie devient `__Secure-ev_refresh`.
+- `APP_TRUST_PROXY_HEADERS` passe à vrai, et le proxy écrit `X-Forwarded-For` avec
+  `$proxy_add_x_forwarded_for`, qui ajoute l'IP réelle en fin de chaîne. C'est exactement ce que
+  lit `get_client_ip()`. Toute autre forme ferait compter la limitation de débit par IP sur l'IP
+  du proxy, c'est-à-dire globalement.
+- `--forwarded-allow-ips=*` reste sans conséquence : uvicorn s'en sert pour réécrire
+  `request.client` depuis `X-Forwarded-For`, et `get_client_ip()` est le seul lecteur de
+  `request.client` du backend, en dernier recours quand l'en-tête est absent.
+- Une limitation de débit au frontal existe désormais, distincte de celle de l'application : 20
+  requêtes par seconde sur l'API, et 30 par minute sur les seules routes qui vérifient un secret,
+  `login`, `password`, `forgot-password` et `reset-password`. `/auth/me` et `/auth/refresh` en
+  sont exclues : elles partent à chaque chargement de page, et le NAT de l'école donnant une seule
+  adresse à toute la promotion, la zone resserrée les aurait transformées en 429 en démonstration.
+- **La CSP contraint le build du frontend.** `script-src 'self'` interdit les gestionnaires
+  d'événements en ligne, et l'inlining du CSS critique d'Angular produisait exactement cela :
+  `<link rel="stylesheet" media="print" onload="this.media='all'">`. La feuille serait restée en
+  `media="print"`, donc l'application entière sans style. D'où `styles.inlineCritical: false` dans
+  `angular.json`. `style-src` garde `'unsafe-inline'`, dont Angular a besoin pour les styles de
+  composants injectés à l'exécution.
+- **La redirection 80 vers 443 conserve `$host`.** Un client qui forge son en-tête `Host` obtient
+  donc une redirection vers l'hôte de son choix. Risque accepté : un navigateur ne peut pas être
+  amené à envoyer un `Host` étranger, aucun cache ne s'intercale, et figer un nom canonique
+  couperait l'accès par adresse IP, seule voie ouverte sur `10.0.0.10`.
+- **Aucun `:?` dans l'overlay.** Compose interpole tout le fichier avant n'importe quelle
+  sous-commande : une garde y casserait `stop` et `logs` autant que `up`. `PUBLIC_HOST` retombe
+  donc sur `enervision.local`, et `make stack-up` vérifie à la place que le certificat présent
+  couvre l'hôte demandé, ce qui est la condition réelle à tenir.
+- Le proxy attend une API saine et pas seulement démarrée : le `HEALTHCHECK` de l'image du backend
+  sert de condition à `depends_on`, faute de quoi les premiers appels à `/api/` répondent 502.
+- La ligne API8 transport de `owasp-traceabilite.md` se referme.
+- **Let's Encrypt n'est pas prouvé.** Le chemin ACME est livré, monté et documenté ; il n'a pas
+  été exercé faute de domaine. Le certificat de démonstration est auto-signé, le navigateur
+  avertit, et c'est la situation réelle du projet, pas un raccourci.
+- Le proxy résout ses cibles par le résolveur interne de Docker plutôt que par un bloc `upstream`,
+  sans quoi recréer le seul conteneur backend suffirait à produire des 502 jusqu'au rechargement.
+
+## Alternatives écartées
+
+- **Ingress k3s avec cert-manager** : la bonne cible, et elle reste la cible. Elle suppose un
+  registre et des manifestes qui n'existent pas, à quatre jours du rendu.
+- **Étendre le `nginx.conf` du conteneur frontend** avec un `location /api` et l'écoute TLS :
+  moins de pièces, mais les certificats entrent dans l'image du front et tout rebuild du front
+  redéploie le terminateur TLS. La séparation des cycles de vie vaut le conteneur supplémentaire.
+- **Traefik ou Caddy**, qui automatisent ACME : ils déplacent le problème sans le résoudre, le
+  défi HTTP-01 échouant pour la même raison. Et l'issue nomme Nginx.
+- **Let's Encrypt par défi DNS-01** : fonctionne derrière une IP privée, mais exige un domaine
+  possédé et un jeton d'API chez le fournisseur DNS. Rouvrable sans rien changer à la
+  configuration nginx le jour où ces deux éléments existent.
+- **Un `Dockerfile` de proxy** : inutile, la configuration est montée en volume. Cela évite aussi
+  la dépendance à un registre authentifié, piège déjà présent dans `apps/frontend/Dockerfile`.
@@ -46,6 +46,7 @@ flowchart TB
  navigateur["Navigateur"]

  subgraph machine["Machine on-premise"]
+    proxy["Reverse proxy Nginx<br/>:80 et :443"]
    front["Frontend Angular 22<br/>apps/frontend"]
    api["API FastAPI<br/>apps/backend"]
    db[("PostgreSQL 17<br/>TimescaleDB")]
@@ -54,10 +55,12 @@ flowchart TB
    grafana["Grafana"]
  end

-  navigateur --> front
+  navigateur --> proxy
+  proxy --> front
+  proxy --> api
  front -.-> api
  api --> db
-  airflow -.-> db
+  airflow --> db
  prom -.-> api
  grafana -.-> db
  grafana -.-> prom
@@ -67,6 +70,10 @@ Le lien `front -.-> api` reste en pointillé : le frontend appelle bien une API,
 intercepteur répond à sa place tant que les endpoints n'existent pas. Voir
 [30-frontend.md](30-frontend.md).

+Le lien `airflow --> db` est maintenant en trait plein : deux DAGs orchestrent l'entraînement et
+le scoring du modèle ML (issue #115), cf. plus bas et [20-backend.md](20-backend.md). Le reste du
+périmètre Airflow envisagé (ingestion, issues #15/#16) reste en pointillé, non construit.
+
 Le lien `prom -.-> api` de même : l'API expose bien `/metrics` au format Prometheus, mais aucun
 collecteur ne vient le lire.

@@ -77,15 +84,17 @@ 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`. Voir [ADR 0005](../adr/0005-modele-prediction-lightgbm.md) et [ML-START.md](../../ML-START.md). Automatisation (Airflow) et surveillance de dérive (EC06, #44/#45) pas encore construites |
-| Infra | Terraform, k3s single-node | `infra/terraform` | `En cours` | Module d'installation du cluster. Jamais appliqué, aucune ressource Kubernetes déclarée |
+| ML | LightGBM, MLflow | `ml` | `En cours` | Pipeline d'entraînement et de scoring (`enervision_ml.train`/`.score`, features par lags/moyennes glissantes partagées entre les deux, baseline de persistance saisonnière, suivi MLflow local), exposé en lecture via `GET /predictions`, orchestré par Airflow (`ml_train`/`ml_score`). Voir [ADR 0005](../adr/0005-modele-prediction-lightgbm.md) et [ML-START.md](../../ML-START.md). Surveillance de dérive (EC06, #44/#45) pas encore construite |
+| Infra | Docker Compose, Nginx, Terraform, k3s single-node | `infra`, `docker-compose.prod.yml` | `En cours` | Reverse proxy et overlay de déploiement écrits et validés, jamais lancés sur le serveur ([ADR 0007](../adr/0007-terminaison-tls-et-reverse-proxy-nginx.md)). Module d'installation k3s jamais appliqué, aucune ressource Kubernetes déclarée |
 | Monitoring | Prometheus, Grafana, Alertmanager | `monitoring` | `Cible` | Rien, hors le `/metrics` exposé par l'API |
-| ETL | Apache Airflow | `etl/airflow` | `Cible` | Rien |
+| ETL | Apache Airflow | `etl/airflow` | `En cours` | Webserver + scheduler (LocalExecutor) tournent via docker-compose, base de métadonnées Postgres dédiée. Deux DAGs (`ml_train` manuel, `ml_score` `@hourly`) orchestrent le pipeline ML existant en sous-processus `uv run` (issue #115). L'ingestion (issues #15/#16) n'a pas encore de DAG |
 | CI/CD | GitHub Actions | `.github/workflows` | `Cible` | Rien |

 ## Flux bout en bout

-Statut : `Cible`. Aucun maillon de cette chaîne n'existe aujourd'hui, à l'exception de la base.
+Statut : `Cible`. Ce flux d'ingestion (Source → Airflow → hypertable) n'existe pas encore : les
+deux DAGs livrés à ce jour (`ml_train`/`ml_score`, issue #115) orchestrent le pipeline ML, pas
+l'ingestion. Seule la base tourne réellement parmi les maillons ci-dessous.

 ```mermaid
 sequenceDiagram
@@ -137,6 +146,11 @@ consolidée.
  jeton facultatif, 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
+  80 vers 443, sert le SPA et l'API sous la même origine, pose **HSTS** et **CSP** que
+  l'application refuse délibérément de poser, et ajoute une **limitation de débit au frontal**
+  distincte de celle de l'application. Voir
+  [ADR 0007](../adr/0007-terminaison-tls-et-reverse-proxy-nginx.md).
 - **Côté infrastructure** : la clé SSH est marquée `sensitive`, le kubeconfig reste en `600/root`
  sur la machine cible et n'est lu que par `sudo`, `*.tfvars` est ignoré par git sauf les
  `.example`.
@@ -150,13 +164,10 @@ consolidée.
  arrêteraient une application compromise. Même raison de report.
 - **Portée par site** dans l'autorisation : les rôles sont globaux, un opérateur du site A peut
  agir sur le site B. C'est la limite connue du modèle.
- **TLS, HSTS et CSP** : ils appartiennent au terminateur TLS, qui n'existe pas encore.
- **Limitation de débit au frontal** : celle de l'application protège les identifiants, pas
-  l'infrastructure.
+- **Certificat reconnu** : aucun nom de domaine public ne résout vers la machine, donc le défi
+  HTTP-01 de Let's Encrypt ne peut pas aboutir. Le certificat servi est auto-signé, le chemin ACME
+  est livré et documenté mais pas exercé.
 - **Analyse de dépendances et de conteneurs** dans la CI, qui relève du chantier CI/CD.
- **Le fichier `environment.ts` de production** pointe encore sur `http://localhost:8000` en HTTP
-  simple : dans cet état, le cookie `Secure` ne sera pas posé. Voir
-  [31-contrat-authentification.md](31-contrat-authentification.md).

 ## Décisions structurantes

@@ -170,3 +181,4 @@ Elles vivent dans `../adr/`, pas ici.
 | [0004](../adr/0004-journal-d-audit-en-ajout-seul.md) | Journal d'audit en ajout seul, garanti par PostgreSQL |
 | [0005](../adr/0005-modele-prediction-lightgbm.md) | Modèle de prédiction de consommation : LightGBM |
 | [0006](../adr/0006-moteur-de-regles-dans-le-backend.md) | Le moteur de règles de recommandation vit dans le backend, pas dans `ml/` |
+| [0007](../adr/0007-terminaison-tls-et-reverse-proxy-nginx.md) | Terminaison TLS par un reverse proxy Nginx, en Docker Compose |
@@ -1,12 +1,13 @@
 # Infrastructure

-Deux topologies coexistent et ne servent pas la même chose. Ce document dit laquelle vaut dans
-quel contexte, quelles décisions sont arrêtées, et ce qui manque encore entre les deux.
+Trois topologies coexistent et ne servent pas la même chose. Ce document dit laquelle vaut dans
+quel contexte, quelles décisions sont arrêtées, et ce qui manque encore entre elles.

 | Topologie | Sert à | Statut |
 |---|---|---|
 | Docker Compose | Développer et recetter sur le poste | `Fait` |
-| k3s single-node | Déployer sur le serveur on-premise | `En cours` |
+| Docker Compose plus reverse proxy | Déployer sur la machine on-premise | `Fait` |
+| k3s single-node | Cible à terme | `En cours` |

 ## Poste de développement

@@ -40,15 +41,102 @@ seule la base tourne en conteneur, l'API et `ng serve` tournent sur le poste ave
 des deux seul). Le service `backend` sert la stack complète et la recette. Les deux occupent le
 port 8000, ils ne se lancent donc pas ensemble.

-Deux pièges sont documentés en tête du `docker-compose.yml`, ils ne se devinent pas :
+Trois pièges sont documentés en tête du `docker-compose.yml`, ils ne se devinent pas :

 - `PGDATA` vaut `/home/postgres/pgdata/data` pour l'image `-ha`, et non le chemin habituel de
  l'image `postgres`. Monté ailleurs, le volume ne retient rien, sans le moindre message.
 - `db/init` est monté **fichier par fichier**. Monter le dossier masquerait les scripts d'init de
  l'image, dont `timescaledb-tune`. Ajouter un fichier dans `db/init/` impose donc une ligne dans
  le compose. Voir [`db/README.md`](../../db/README.md).
+- `LocalExecutor` exécute les tâches comme sous-processus du **scheduler**, jamais du webserver :
+  c'est le scheduler qui a besoin du volume `airflow_ml_state` (modèle, magasin MLflow).

-## Cible de déploiement
+### Airflow (`ml_train`/`ml_score`, issue #115)
+
+Trois services, `docker compose profiles` non utilisés (démarrage explicite via `make
+airflow-up`, pas dans `make dev`) :
+
+| Service | Rôle | Points notables |
+|---|---|---|
+| `airflow-init` | Migre la base de métadonnées, crée le compte admin | Conteneur jetable (`restart: "no"`), ne redémarre jamais. `webserver`/`scheduler` attendent qu'il se termine avec succès |
+| `airflow-webserver` | UI, port `8080` | `LocalExecutor` : n'exécute aucune tâche lui-même |
+| `airflow-scheduler` | Planifie et **exécute** les tâches (`LocalExecutor`) | Les DAGs y tournent en sous-processus (`uv run --frozen --no-dev python -m enervision_ml...`), c'est lui qui a besoin du volume `airflow_ml_state` |
+
+Construits depuis `etl/airflow/Dockerfile`, contexte `.` (racine du repo, pas `etl/airflow/`) :
+l'image doit pouvoir `COPY` `ml/pyproject.toml`/`ml/uv.lock`/`ml/enervision_ml` pour se
+synchroniser un second environnement Python **3.14** (`/opt/ml/.venv`, `uv sync --locked` à la
+construction), distinct du Python 3.12 qui fait tourner Airflow lui-même. Les DAGs shellent vers
+ce venv plutôt que d'importer LightGBM/MLflow dans le process Airflow.
+
+`airflow-init` s'appuie sur l'entrypoint de l'image (`_AIRFLOW_DB_MIGRATE`,
+`_AIRFLOW_WWW_USER_*`) plutôt que sur un script maison : l'entrypoint porte le code de sortie, une
+migration ratée (typiquement la base `airflow` absente, cf. ci-dessous) fait échouer le service et
+`webserver`/`scheduler` ne démarrent pas sur une base non migrée. Le mot de passe du compte admin
+passe par l'environnement, jamais par `argv` (ni `ps`, ni `docker compose config`).
+
+Les variables `AIRFLOW_*` ne sont volontairement pas en `${VAR:?}` : Compose interpole le fichier
+entier avant de filtrer les services, une variable requise manquante casserait `make db-up`,
+`make dev`... pour tout poste dont le `.env` est antérieur. Elles valent `${VAR:-}` et c'est
+`airflow-init` qui refuse de démarrer (clé Fernet, clé Flask ou mot de passe vides).
+
+**Pourquoi `ml_train` est manuel.** Réentraîner est coûteux et sa cadence n'est pas une décision
+prise. Surtout, `train.py` écrase le modèle sans comparer ses métriques à celles de l'ancien : un
+cron déploierait silencieusement un modèle dégradé. Tant que ce garde-fou n'existe pas, le
+déclenchement reste humain. `ml_score`, lui, est planifié à l'heure, avec `max_active_runs=1`
+(pas deux scorings simultanés dans `prediction`), 2 tentatives et un plafond de 30 minutes.
+
+CI : `.github/workflows/airflow.yml` (Python 3.12 via `etl/airflow/.python-version`) lance lint et
+tests d'intégrité des DAGs, et construit l'image (elle `COPY` `ml/`, une modification de `ml/`
+peut donc la casser) avant de vérifier que le pipeline s'y importe sans réseau.
+
+Piège à connaître : sur un volume `pgdata` déjà peuplé (poste de dev existant plutôt que premier
+`make db-up`), `db/init/120-airflow-database.sql` ne se rejoue pas (PostgreSQL n'exécute
+`docker-entrypoint-initdb.d/` que sur un volume vide). Créer la base `airflow` à la main une fois :
+`docker compose exec db psql -U $POSTGRES_USER -d $POSTGRES_DB -c "CREATE DATABASE airflow;"`.
+
+`libgomp1` est installé explicitement dans l'image (`apt-get`, en root) : l'image Airflow de base
+est minimale et n'embarque pas la runtime OpenMP dont LightGBM a besoin, sans quoi l'erreur
+(`OSError: libgomp.so.1`) n'apparaît qu'à la première tâche réellement exécutée, pas à la
+construction de l'image.
+
+## Machine cible, exécution Docker
+
+Statut : `Fait`. Défini par l'overlay `docker-compose.prod.yml`, appliqué par-dessus le
+`docker-compose.yml`. Écrit et validé sur le poste, **jamais encore lancé sur le serveur de
+l'école**. Décision et motifs dans l'[ADR 0007](../adr/0007-terminaison-tls-et-reverse-proxy-nginx.md).
+
+```mermaid
+flowchart LR
+  navigateur["Navigateur"]
+
+  subgraph machine["Machine on-premise"]
+    proxy["service proxy<br/>nginx:1.28-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"]
+  end
+
+  navigateur -->|"HTTPS"| proxy
+  proxy -->|"/"| front
+  proxy -->|"/api/"| api
+  api --> db
+  api --> mail
+```
+
+Le proxy est **le seul service à publier des ports** sur le réseau. Backend et frontend ne sont
+plus publiés du tout, la base et l'interface Mailpit sont ramenées sur `127.0.0.1`, donc joignables
+par tunnel SSH et pas autrement. Le détail du routage, les deux modes d'obtention du certificat et
+la commande de validation hors exécution sont dans [`infra/proxy/README.md`](../../infra/proxy/README.md).
+
+Deux conséquences se propagent jusqu'à l'application, et elles ne se devinent pas :
+
+- Servir le SPA et l'API sous la même origine est ce qui rend le cookie `__Secure-ev_refresh`
+  utilisable. Sans cela, `apiUrl: '/api/v1'` ne mène nulle part une fois en conteneur.
+- `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.
+
+## Cible à terme, k3s

 Statut : `En cours`. Le module `infra/terraform/modules/k3s/` installe le cluster. Il n'a jamais
 été appliqué.
@@ -104,6 +192,8 @@ Ces arbitrages sont pris. Ils ne vivaient jusqu'ici que dans des commentaires de
 | `*.tfvars` ignoré, `*.tfvars.example` versionné | Les tfvars portent l'adresse du serveur et le chemin de la clé | `.gitignore` |
 | Désinstallation gérée au `destroy` | `k3s-uninstall.sh` en `on_failure = continue` : un serveur injoignable ne bloque pas le `destroy` | `modules/k3s/main.tf` |
 | Deux racines, `dev` et `prod` | Séparation des états et des variables par environnement | `environments/` |
+| Terminaison TLS par un reverse proxy Nginx en Compose | L'ingress k3s supposait un registre et des manifestes qui n'existent pas, à quatre jours du rendu | `docker-compose.prod.yml`, [ADR 0007](../adr/0007-terminaison-tls-et-reverse-proxy-nginx.md) |
+| Certificat auto-signé par défaut, chemin ACME câblé | Aucun domaine public ne résout vers la machine : le défi HTTP-01 ne peut pas aboutir | `scripts/tls-selfsigned.sh`, `infra/proxy/acme-deploy-hook.sh` |

 ## Ports et noms

@@ -112,12 +202,16 @@ Ces arbitrages sont pris. Ils ne vivaient jusqu'ici que dans des commentaires de
 | PostgreSQL, côté hôte | `5433` | Redirigé vers 5432 dans le conteneur. 5432 est souvent déjà pris |
 | PostgreSQL, côté réseau Compose | `db:5432` | Nom de service, utilisé par `DATABASE_URL` du service `backend` |
 | API | `8000` | Identique en conteneur et hors conteneur |
-| Frontend, `ng serve` | `4200` | Valeur par défaut d'`APP_CORS_ORIGINS`. Le compose n'a aucun service frontend |
+| 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`. 80 ne sert que la redirection et le défi ACME |
 | 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` |
+| Webserver Airflow | `8080` | `make airflow-up`. Scheduler et webserver ne publient que ce port ; les tâches (`LocalExecutor`) tournent côté scheduler, sans port propre |

-## Le trou entre les deux topologies
+## Le trou vers k3s

 Rien ne relie aujourd'hui ce qui est construit par Compose et ce qui tournerait sur k3s. Compose
 construit une image backend localement ; k3s ne saurait pas où la trouver. C'est la première
@@ -125,7 +219,11 @@ question à trancher, avant toute ressource Kubernetes.

 ## Questions ouvertes

- **Quel ingress** remplace Traefik, et qui termine le TLS.
+- **Quel ingress** remplace Traefik le jour de la bascule k3s. Qui termine le TLS est tranché par
+  l'[ADR 0007](../adr/0007-terminaison-tls-et-reverse-proxy-nginx.md), mais la réponse vaut pour la
+  topologie Compose, pas pour Kubernetes.
+- **Quel nom de domaine public**, sans lequel Let's Encrypt reste hors d'atteinte et le certificat
+  reste auto-signé.
 - **Quel registre d'images**, et comment il est alimenté sans CI.
 - **Quel stockage persistant** côté Kubernetes pour PostgreSQL, et si la base tourne dans le
  cluster ou à côté.
@@ -256,8 +256,8 @@ auraient pu comparer des lectures/choisir une prévision au hasard. `_detect_spi
 explicitement les paires de lectures qui partagent le même horodatage (deux `source` pour un seul
 instant réel, pas une variation).

-Comme `enervision_ml.score`, la détection est un script lancé à la main, pas encore ordonnancé par
-Airflow : `uv run python -m app.detection.internal_alerts [--site-id ...] [--now ...]`, dans
+La détection est un script lancé à la main, pas encore ordonnancé par Airflow (contrairement à
+`enervision_ml.score`, orchestré par le DAG `ml_score` depuis l'issue #115) : `uv run python -m app.detection.internal_alerts [--site-id ...] [--now ...]`, dans
 `apps/backend` puisque les règles s'appuient sur les repositories ORM de l'API plutôt que sur une
 connexion SQL directe (contrairement à `app/etl/historical_import.py`). Cette issue (#104)
 débloquait #38 (moteur de règles pour recommandations), dont la FK `alert_id` `NOT NULL` n'avait
@@ -390,9 +390,12 @@ Le reste, par ordre de surface :
  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.
+  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`.
- Ni limitation de débit au frontal, ni TLS, ni journalisation des accès applicative.
+- TLS, limitation de débit au frontal et journal d'accès sont portés par le reverse proxy.
+  `APP_TRUST_PROXY_HEADERS` doit alors valoir vrai, sinon le compteur par IP devient global.
+- Pas de journalisation des accès applicative.

 ## Observabilité

@@ -97,11 +97,11 @@ En développement, `proxy.conf.json` redirige tout `/api` vers `http://localhost
 qui évite le CORS sur le poste, et c'est pourquoi `environment.development.ts` se contente d'un
 `apiUrl` relatif, `/api/v1`.

-En production, il n'y a pas de proxy, mais `environment.ts` porte lui aussi un `apiUrl` relatif
-(`/api/v1`) plutôt qu'une URL absolue : la dette qui pointait en dur sur
-`http://localhost:8000/api/v1` a été corrigée. Un build de production sert donc l'appel `/api/v1/...`
-sur son propre origin, ce qui suppose qu'un ingress ou un reverse proxy route `/api` vers le
-backend une fois déployé — question toujours ouverte dans [10-infra.md](10-infra.md).
+En production, `environment.ts` porte lui aussi un `apiUrl` relatif (`/api/v1`) plutôt qu'une URL
+absolue : la dette qui pointait en dur sur `http://localhost:8000/api/v1` a été corrigée. Un build
+de production sert donc l'appel `/api/v1/...` sur son propre origin, et c'est le **reverse proxy**
+qui route `/api` vers le backend : `location /api/` dans `infra/proxy/conf.d/enervision.conf`, voir
+[10-infra.md](10-infra.md) et l'[ADR 0007](../adr/0007-terminaison-tls-et-reverse-proxy-nginx.md).

 ## Exécution

@@ -118,13 +118,14 @@ le message d'erreur arrive avant toute compilation. Un poste en 22.21 ou en 24.1
 tester ni construire le frontend.

 Le frontend a ses cibles dans le `Makefile` racine (`install-frontend`, `dev-frontend`,
-englobées par `install` et `dev`), mais **aucun service dans `docker-compose.yml`** : en
-développement il tourne toujours directement via `npm`, depuis `apps/frontend`. Le port 4200
-n'apparaît dans le compose que comme valeur par défaut d'`APP_CORS_ORIGINS`, côté backend.
+englobées par `install` et `dev`). En développement il tourne directement via `npm`, depuis
+`apps/frontend` : le port 4200 n'apparaît dans le compose que comme valeur par défaut
+d'`APP_CORS_ORIGINS`, côté backend.

-Un `Dockerfile` frontend existe sur la branche `feat/pipeline-cd`, mais il est mono-étage et sans
-`CMD` : il construit sans rien servir. Le `README.md` de l'application demande un multi-étage
-avec un service statique, il reste à écrire.
+Le service `frontend` du `docker-compose.yml` sert le build statique par le nginx de
+`apps/frontend/Dockerfile`, multi-étage, qui **écoute sur 3000**. En déploiement il n'est plus
+publié du tout : le reverse proxy est seul à sortir sur le réseau, et l'atteint par le réseau
+Compose.

 ## Sécurité

@@ -133,6 +134,13 @@ avec un service statique, il reste à écrire.
  `/sites`, `authInterceptor` pose le jeton porteur sur les requêtes sortantes et déclenche le
  rafraîchissement sur 401. Détail complet dans
  [31-contrat-authentification.md](31-contrat-authentification.md).
+- **La CSP posée par le reverse proxy contraint le build.** `script-src 'self'` interdit les
+  gestionnaires d'événements en ligne ; l'inlining du CSS critique en produisait un
+  (`<link media="print" onload="this.media='all'">`), ce qui aurait laissé l'application sans
+  style derrière le proxy. D'où `optimization.styles.inlineCritical: false` dans la configuration
+  de production d'`angular.json`. La contrepartie est un rendu non stylé très bref au premier
+  affichage. `style-src` conserve `'unsafe-inline'` : Angular injecte les styles de composants à
+  l'exécution, et s'en passer demanderait un `ngCspNonce` que le SPA statique ne peut pas produire.

 ## Tests

@@ -129,18 +129,18 @@ n'est pas envoyé et le rafraîchissement échoue toujours.
 En développement, `proxy.conf.json` fait passer `/api` par `localhost:4200`, donc tout est
 **même origine** et le cookie marche sans rien configurer.

-En production, `src/environments/environment.ts` contient encore le gabarit
-`http://localhost:8000/api/v1`, en HTTP simple et sur une autre origine. **Dans cet état, aucun
-cookie `Secure` ne sera posé et l'authentification ne fonctionnera pas.**
+En déploiement, les deux conditions sont désormais remplies par le reverse proxy
+([ADR 0007](../adr/0007-terminaison-tls-et-reverse-proxy-nginx.md)) : `environment.ts` porte un
+`apiUrl` relatif, `/api/v1`, et le proxy sert le SPA sur `/` et l'API sur `/api/` **sous la même
+origine, en HTTPS**. C'est cela, et rien d'autre, qui rend le cookie `__Secure-ev_refresh`
+utilisable : servi en HTTP simple ou depuis une autre origine, il n'est jamais posé et
+l'authentification ne survit pas à un rechargement de page.

-Deux corrections, à faire avant la démonstration :
-
-1. passer `apiUrl` à `/api/v1` et servir le SPA et l'API sous la même origine, via un
-   `location /api` dans le `nginx.conf` du conteneur frontend ou via l'ingress ;
-2. servir en HTTPS.
+Ce qui reste à surveiller : le certificat est auto-signé tant qu'aucun domaine public ne résout
+vers la machine. Un navigateur qui refuse l'exception refusera aussi le cookie.

 Et au moins une fois avant la soutenance, lancer le front **sans le proxy**, en cross-origin
-réel : c'est le seul moyen d'exercer le préflight CORS et `SameSite`, que le proxy masque.
+réel : c'est le seul moyen d'exercer le préflight CORS et `SameSite`, que la même origine masque.

 ## Origines autorisées

@@ -43,21 +43,25 @@ lecture seule ; plusieurs lignes resteront à compléter une fois les endpoints
 | 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 |
 | CI bloquante : format, lint avec règles Bandit, typage strict, tests avec seuil de couverture | `.github/workflows/backend.yml` | A06 Vulnerable and Outdated Components |
+| Terminaison TLS au frontal, redirection 80 vers 443, HSTS et CSP posés par le proxy, limitation de débit au frontal | `infra/proxy/conf.d/enervision.conf`, ADR 0007 | API8 Security Misconfiguration, A05 |

 Note sur A06 : le jeu de règles `S` de ruff, déjà actif dans `pyproject.toml`, est le portage des
 règles Bandit. Ajouter Bandit à la CI serait redondant, contrairement à ce qu'annonce l'EC01.

+Note sur API8 : le transport est couvert, le certificat ne l'est qu'à moitié. Tant qu'aucun nom de
+domaine public ne résout vers la machine, le défi HTTP-01 de Let's Encrypt ne peut pas aboutir et
+le certificat servi reste auto-signé. Le chemin ACME est livré et documenté, pas exercé.
+
 ## Non couvert, et pourquoi

 | Item | État | Raison |
 |---|---|---|
 | **API1 Broken Object Level Authorization** | **ouvert** | Les rôles sont globaux, il n'y a pas de portée par site : `GET /sites/{site_id}` et `GET /recommendations/{recommendation_id}` répondent à tout compte `lecteur` pour n'importe quel site ou recommandation, sans vérifier une affectation compte-site qui n'existe pas encore. Un opérateur du site A pourra agir sur le site B dès que les endpoints d'écriture métier existeront. Correctif prévu : table d'affectation compte-site, contrôle d'appartenance dans la même dépendance que le contrôle de rôle. |
 | **API4, lectures de séries temporelles** | **partiel** | `GET /readings` plafonne la fenêtre temporelle (90 jours) et la pagination (`limit` ≤ 2000), voir plus haut. Reste ouvert : pagination en `limit`/`offset` simple plutôt qu'en curseur (un `offset` élevé sur une fenêtre dense reste coûteux), et aucun `statement_timeout` au niveau de la connexion pour borner une requête individuelle si les plafonds au-dessus s'avéraient insuffisants. |
-| **API8 Security Misconfiguration, transport** | **ouvert** | Pas de TLS, donc ni HSTS, ni cookie `Secure` réellement posé en production. Ils appartiennent au terminateur TLS, qui n'existe pas. |
 | **API10 Unsafe Consumption of APIs** | **partiel, et spécifique à ce projet** | L'API Mock de l'école n'a aucune authentification, tourne en HTTP clair sur le réseau de l'école, et expose un endpoint mutatif à quiconque. Sa réponse est traitée comme une entrée hostile par `app/etl/mock_api_import.py`, son seul consommateur à ce jour : les quatre garde-fous attendus sont en place, voir la ligne correspondante plus haut. Reste ouvert : le plafond de taille s'applique après désérialisation de la réponse, borner le corps HTTP lui-même demanderait une lecture en flux ; et `APP_MOCK_API_BASE_URL` n'impose pas `https`, donc les identifiants Basic partiraient en clair sur une URL en `http`. La conséquence la plus sérieuse n'est pas la fausse alerte, c'est l'empoisonnement du jeu d'entraînement du modèle de prédiction. |
 | **A08 Software and Data Integrity Failures** | **partiel** | La CI vérifie le code mais n'analyse ni les dépendances ni les images. `.terraform.lock.hcl` reste ignoré par git, ce qui contredit une chaîne d'approvisionnement maîtrisée. |
 | **A10 Server-Side Request Forgery** | **sans objet aujourd'hui** | Aucune URL sortante n'est pilotée par une donnée utilisateur. Le jour où l'adresse d'une source devient un champ de configuration, il faudra une liste blanche de schémas et d'hôtes, sans suivi de redirection. |
-| **Cantonnement des accès ETL et ML** | **dette assumée** | Le compte applicatif porte l'identité, le rôle PostgreSQL porterait le cantonnement. Voir ADR 0003. |
+| **Cantonnement des accès ETL et ML** | **dette assumée** | Le compte applicatif porte l'identité, le rôle PostgreSQL porterait le cantonnement. Voir ADR 0003. Plus coûteuse depuis Airflow (#115) : ce service publie le port 8080, détient les identifiants Postgres complets (`ML_DATABASE_URL`, mêmes que le backend) et permet de déclencher l'exécution de code depuis son interface. Un compte Airflow compromis atteint donc toute la base, pas seulement `reading`/`site`. Le compte admin Airflow est distinct des `app_user` et son mot de passe passe par l'environnement, jamais par `argv`. |
 | **Non-répudiation de l'audit** | **dette assumée** | Les déclencheurs arrêtent les accidents, pas un compte détenant `ALTER TABLE`. Voir ADR 0004. |

 ## Ce qu'il faut répondre, et ne pas répondre
@@ -663,10 +663,8 @@ 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.

-La prochaine étape consiste à orchestrer ces traitements avec Apache Airflow.
+Airflow tourne désormais réellement (`etl/airflow/`, `make airflow-up`), mais il orchestre pour l'instant le pipeline ML (`ml_train`/`ml_score`, issue #115), pas encore ces deux imports : orchestrer `historical_import.py` et `mock_api_import.py` (normalisation et chargement micro-batch, issues #15/#16) reste à faire.

-Airflow permettra de planifier les traitements, gérer leur ordre d'exécution, suivre leur état et remonter les erreurs.
-
-Airflow ne remplacera pas la logique ETL Python existante. Les scripts actuels resteront responsables de l'extraction, de la validation, de la transformation et du chargement.
+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` et `ml_score.py` montrent le patron retenu (des `BashOperator` qui invoquent le script tel quel).

 Le pipeline Data servira ensuite à préparer les données nécessaires au modèle de Machine Learning.
@@ -0,0 +1 @@
+3.12
@@ -0,0 +1,39 @@
+# Image Airflow EnerVision : ajoute le projet ml/ dans son propre environnement Python 3.14,
+# distinct du Python 3.12 qui fait tourner Airflow lui-meme (apache-airflow 2.10 ne supporte pas
+# 3.14), pour que les DAGs puissent lancer `uv run python -m enervision_ml.train`/`.score` en
+# sous-processus. Airflow ne devient jamais un consommateur direct de LightGBM/MLflow.
+FROM apache/airflow:2.10.4-python3.12
+
+# LightGBM est compile contre libgomp (OpenMP), absent de l'image de base (minimale, sans
+# toolchain de compilation). Sans lui : `OSError: libgomp.so.1: cannot open shared object file`
+# au premier `import lightgbm`, seulement au moment ou une tache tourne reellement.
+USER root
+RUN apt-get update \
+    && apt-get install --no-install-recommends -y libgomp1 \
+    && apt-get clean \
+    && rm -rf /var/lib/apt/lists/*
+# Pre-cree, appartenant a `airflow` : docker-compose y monte un volume nomme partage entre
+# `ml_train` et `ml_score` (le modele ecrit par l'un, lu par l'autre). Un volume nomme herite des
+# permissions du repertoire qu'il recouvre a son premier montage ; sans ce chown prealable, il
+# serait cree root:root et illisible par le conteneur, qui tourne en `airflow` (uid 50000).
+RUN mkdir -p /opt/ml/state && chown -R airflow:root /opt/ml
+USER airflow
+
+# L'image de base embarque deja un `uv`, mais trop ancien (0.4.29) pour le format de verrou de
+# `ml/uv.lock`. On le remplace par la version deja pinnee ailleurs dans le depot
+# (apps/backend/Dockerfile).
+COPY --from=ghcr.io/astral-sh/uv:0.11.26 /uv /home/airflow/.local/bin/uv
+
+ENV UV_COMPILE_BYTECODE=1 \
+    UV_LINK_MODE=copy \
+    UV_PROJECT_ENVIRONMENT=/opt/ml/.venv
+
+WORKDIR /opt/ml
+
+COPY --chown=airflow:root ml/pyproject.toml ml/uv.lock ./
+RUN uv sync --locked --no-install-project --no-dev
+
+COPY --chown=airflow:root ml/enervision_ml ./enervision_ml
+RUN uv sync --locked --no-dev
+
+WORKDIR /opt/airflow
@@ -0,0 +1,41 @@
+"""DAG de scoring horaire du modele LightGBM (issue #115).
+
+Planifie toutes les heures, au rythme documente par `enervision_ml.score` (score le prochain pas
+horaire par site). Reutilise le modele ecrit par `ml_train` (DAG separe, declenche a la main) :
+ce DAG ne reentraine jamais rien. Si aucun modele n'a encore ete entraine, la tache echoue
+(`FileNotFoundError`) plutot que de rester silencieuse.
+"""
+
+from __future__ import annotations
+
+from datetime import datetime, timedelta
+
+from airflow.models.dag import DAG
+from airflow.operators.bash import BashOperator
+
+MODEL_PATH = "/opt/ml/state/models/lightgbm-consumption.txt"
+
+with DAG(
+    dag_id="ml_score",
+    description="Score le prochain pas horaire par site (enervision_ml.score).",
+    schedule="@hourly",
+    start_date=datetime(2026, 1, 1),
+    catchup=False,
+    # Deux scorings qui se chevauchent inseraient en meme temps dans `prediction` (pas de contrainte
+    # d'unicite sur `(site_id, target_at)`, chaque run garde sa ligne).
+    max_active_runs=1,
+    tags=["ml"],
+) as dag:
+    # `--no-sync`, `env -u VIRTUAL_ENV` : cf. `ml_train.py`, meme raisonnement.
+    BashOperator(
+        task_id="score",
+        bash_command=(
+            "cd /opt/ml && env -u VIRTUAL_ENV uv run --no-sync python -m enervision_ml.score "
+            f"--model {MODEL_PATH}"
+        ),
+        # Un incident transitoire sur Postgres ne doit pas faire perdre le creneau horaire.
+        retries=2,
+        retry_delay=timedelta(minutes=2),
+        # Bien en dessous du pas horaire : un scoring pendu ne doit pas empieter sur le suivant.
+        execution_timeout=timedelta(minutes=30),
+    )
@@ -0,0 +1,43 @@
+"""DAG d'entrainement du modele LightGBM (issue #115).
+
+Pas de planification : reentrainer est couteux et sa cadence n'est pas une decision prise, en
+particulier tant que `train.py` ecrase le modele sans comparer ses metriques a l'ancien (cf.
+`docs/architecture/10-infra.md`, section Airflow). Declenchement manuel depuis l'UI ou la CLI
+Airflow en attendant. `ml_score` (DAG separe, planifie toutes les heures) reutilise le modele que
+ce DAG ecrit, il ne reentraine jamais rien lui-meme.
+"""
+
+from __future__ import annotations
+
+from datetime import datetime, timedelta
+
+from airflow.models.dag import DAG
+from airflow.operators.bash import BashOperator
+
+MODEL_PATH = "/opt/ml/state/models/lightgbm-consumption.txt"
+MLFLOW_TRACKING_URI = "sqlite:////opt/ml/state/mlflow.db"
+
+with DAG(
+    dag_id="ml_train",
+    description="Entraine le modele LightGBM de prevision de consommation (enervision_ml.train).",
+    schedule=None,
+    start_date=datetime(2026, 1, 1),
+    catchup=False,
+    # Deux entrainements simultanes ecriraient le meme fichier modele.
+    max_active_runs=1,
+    tags=["ml"],
+) as dag:
+    # `--no-sync` : l'environnement `/opt/ml/.venv` est fige a la construction de l'image, `uv run`
+    # ne le resynchronise pas (sinon `enervision-ml` est reconstruit a chaque tache).
+    # `env -u VIRTUAL_ENV` : l'image de base positionne celui d'Airflow, que `uv` signale a chaque
+    # execution sans qu'il change quoi que ce soit.
+    BashOperator(
+        task_id="train",
+        bash_command=(
+            "cd /opt/ml && env -u VIRTUAL_ENV uv run --no-sync python -m enervision_ml.train "
+            f"--model-output {MODEL_PATH} --mlflow-tracking-uri {MLFLOW_TRACKING_URI}"
+        ),
+        # Un entrainement complet dure quelques minutes ; une connexion pendue ne doit pas
+        # immobiliser un slot du scheduler indefiniment.
+        execution_timeout=timedelta(hours=1),
+    )
@@ -0,0 +1,32 @@
+[project]
+name = "enervision-airflow"
+version = "0.1.0"
+description = "DAGs d'orchestration EnerVision (Airflow)"
+requires-python = ">=3.12,<3.13"
+dependencies = [
+    "apache-airflow==2.10.4",
+]
+
+[dependency-groups]
+dev = [
+    "ruff>=0.16.7",
+    "pytest>=9.1.1",
+]
+
+[tool.uv]
+package = false
+
+[tool.ruff]
+line-length = 100
+target-version = "py312"
+src = ["dags", "tests"]
+
+[tool.ruff.lint]
+select = ["E", "W", "F", "I", "N", "UP", "B", "SIM", "RUF"]
+
+[tool.ruff.format]
+quote-style = "double"
+
+[tool.pytest.ini_options]
+testpaths = ["tests"]
+addopts = "-q"
@@ -0,0 +1,16 @@
+"""Isole Airflow d'un `~/airflow` reel : `AIRFLOW_HOME` doit etre pose avant le premier `import
+airflow`, donc ici plutot que dans une fixture (les fixtures s'executent trop tard, apres que les
+modules de test aient deja importe `airflow`)."""
+
+import os
+from pathlib import Path
+
+_AIRFLOW_HOME = Path(__file__).resolve().parent / ".airflow_home"
+_AIRFLOW_HOME.mkdir(exist_ok=True)
+
+os.environ.setdefault("AIRFLOW_HOME", str(_AIRFLOW_HOME))
+os.environ.setdefault("AIRFLOW__CORE__LOAD_EXAMPLES", "False")
+os.environ.setdefault("AIRFLOW__CORE__UNIT_TEST_MODE", "True")
+os.environ.setdefault(
+    "AIRFLOW__DATABASE__SQL_ALCHEMY_CONN", f"sqlite:///{_AIRFLOW_HOME / 'airflow.db'}"
+)
@@ -0,0 +1,82 @@
+"""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 pathlib import Path
+
+import pytest
+from airflow.models.dagbag import DagBag
+
+DAGS_FOLDER = Path(__file__).resolve().parent.parent / "dags"
+
+
+@pytest.fixture(scope="module")
+def dagbag() -> DagBag:
+    return DagBag(dag_folder=str(DAGS_FOLDER), include_examples=False)
+
+
+def test_dags_folder_has_no_import_error(dagbag: DagBag) -> None:
+    assert dagbag.import_errors == {}
+
+
+def test_every_expected_dag_is_discovered(dagbag: DagBag) -> None:
+    assert set(dagbag.dag_ids) == {"ml_train", "ml_score"}
+
+
+def test_ml_train_has_no_schedule(dagbag: DagBag) -> None:
+    assert dagbag.dags["ml_train"].timetable.summary == "None"
+
+
+def test_ml_score_runs_every_hour(dagbag: DagBag) -> None:
+    # `@hourly` est un alias Airflow pour ce cron, c'est sous cette forme que `.summary` le rend.
+    assert dagbag.dags["ml_score"].timetable.summary == "0 * * * *"
+
+
+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
+
+
+def test_ml_score_task_calls_the_scoring_module(dagbag: DagBag) -> None:
+    tache = dagbag.dags["ml_score"].get_task("score")
+    assert "enervision_ml.score" in tache.bash_command
+
+
+def test_ml_score_reuses_the_model_path_written_by_ml_train(dagbag: DagBag) -> None:
+    entrainement = dagbag.dags["ml_train"].get_task("train").bash_command
+    scoring = dagbag.dags["ml_score"].get_task("score").bash_command
+    chemin_modele = "/opt/ml/state/models/lightgbm-consumption.txt"
+
+    assert chemin_modele in entrainement
+    assert chemin_modele in scoring
+
+
+@pytest.mark.parametrize("dag_id", ["ml_train", "ml_score"])
+def test_no_two_runs_of_a_dag_overlap(dagbag: DagBag, dag_id: str) -> None:
+    # Deux entrainements ecriraient le meme fichier modele, deux scorings inseriraient en meme
+    # temps dans `prediction`.
+    assert dagbag.dags[dag_id].max_active_runs == 1
+
+
+@pytest.mark.parametrize(("dag_id", "task_id"), [("ml_train", "train"), ("ml_score", "score")])
+def test_every_task_has_an_execution_timeout(dagbag: DagBag, dag_id: str, task_id: str) -> None:
+    # Sans plafond, une connexion pendue immobilise un slot du scheduler indefiniment.
+    assert dagbag.dags[dag_id].get_task(task_id).execution_timeout is not None
+
+
+def test_ml_score_execution_timeout_stays_below_its_hourly_step(dagbag: DagBag) -> None:
+    timeout = dagbag.dags["ml_score"].get_task("score").execution_timeout
+    assert timeout is not None
+    assert timeout < timedelta(hours=1)
+
+
+def test_ml_score_retries_after_a_transient_failure(dagbag: DagBag) -> None:
+    assert dagbag.dags["ml_score"].get_task("score").retries >= 1
+
+
+@pytest.mark.parametrize(("dag_id", "task_id"), [("ml_train", "train"), ("ml_score", "score")])
+def test_tasks_never_resync_the_baked_environment(
+    dagbag: DagBag, dag_id: str, task_id: str
+) -> None:
+    # Sans `--no-sync`, `uv run` reconstruit `enervision-ml` a chaque execution.
+    assert "--no-sync" in dagbag.dags[dag_id].get_task(task_id).bash_command
@@ -0,0 +1,88 @@
+# Reverse proxy
+
+Terminaison TLS et routage de la stack déployée. Seul composant publié sur le réseau : il
+écoute en 80 et 443, et rien d'autre ne sort du réseau Compose.
+
+- `nginx.conf` : bloc `http`, journalisation, compression, zones de limitation de débit.
+- `conf.d/enervision.conf` : redirection 80 vers 443, terminaison TLS, en-têtes de sécurité,
+  routage.
+- `tls/` : les deux fichiers que nginx lit, `fullchain.pem` et `privkey.pem`. Ignorés par git.
+- `acme-deploy-hook.sh` : recopie le résultat de certbot dans `tls/`.
+
+Pas de `Dockerfile` : l'image officielle `nginx:1.28-alpine` est utilisée telle quelle et la
+configuration est montée en volume par `docker-compose.prod.yml`.
+
+L'overlay emploie les marqueurs `!override` et `!reset`, qui demandent **Docker Compose 2.24.4
+ou plus récent**. Sur une version antérieure, la fusion échoue au lieu de dépublier les ports.
+
+## Routage
+
+| Chemin | Destination | Remarque |
+|---|---|---|
+| `/.well-known/acme-challenge/` | `/var/www/certbot` sur le port 80 | Seul chemin non redirigé vers HTTPS |
+| `/api/v1/auth/` + `login`, `password`, `forgot-password`, `reset-password` | `backend:8000` | Zone resserrée, 30 requêtes par minute |
+| `/api/` | `backend:8000` | Préfixe `/api/v1` préservé tel quel, 20 requêtes par seconde |
+| `/` | `frontend:3000` | Le SPA, qui renvoie `index.html` sur les routes inconnues |
+
+La zone resserrée ne couvre que les routes qui vérifient un secret. `/auth/me` et `/auth/refresh`
+partent à chaque chargement de page et restent dans la zone générale : derrière un NAT, où une
+seule adresse porte tous les postes, les y soumettre aurait produit des 429 en usage normal.
+
+L'interface Airflow, celle de Mailpit et la base ne passent pas par le proxy : l'overlay les
+ramène sur `127.0.0.1`, donc joignables par tunnel SSH et pas autrement. Les publier derrière le
+proxy demanderait une authentification propre, qui n'est pas la leur.
+
+`/docs`, `/redoc`, `/openapi.json`, `/static` et `/metrics` sont montés par l'API **à la racine**,
+pas sous `/api`. Ils tombent donc dans `location /`, donc sur le SPA : ils ne sont pas joignables
+depuis l'extérieur, sans qu'aucune règle de blocage ait à être écrite. Y toucher, c'est les
+exposer.
+
+## Certificat : deux modes, un seul emplacement
+
+nginx lit toujours `tls/fullchain.pem` et `tls/privkey.pem`. Seule leur fabrication change, la
+configuration n'a jamais à bouger.
+
+### Démonstration, certificat auto-signé
+
+```bash
+make tls-selfsigned PUBLIC_HOST=enervision.local
+make stack-up
+```
+
+Le navigateur avertira d'un émetteur inconnu : c'est attendu, et c'est le seul mode exploitable
+tant que la machine cible n'a pas de nom de domaine public.
+
+### Let's Encrypt
+
+Le défi HTTP-01 exige un nom de domaine **résolvable publiquement** et le port 80 joignable
+depuis Internet. La cible documentée aujourd'hui (`ssh_host = "10.0.0.10"`, serveur de l'école)
+ne remplit ni l'une ni l'autre condition : le chemin ci-dessous est livré et documenté, il n'a
+pas été exercé.
+
+```bash
+make stack-up                                     # nginx doit tourner pour servir le défi
+make tls-acme PUBLIC_HOST=enervision.fr ACME_EMAIL=ops@enervision.fr
+```
+
+Renouvellement, à passer en tâche planifiée sur la machine :
+
+```cron
+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.
+
+## Vérifier la configuration sans démarrer la stack
+
+`nginx -t` charge les certificats : `tls/` doit être rempli, par `make tls-selfsigned` au besoin.
+
+```bash
+docker run --rm \
+  -v "$PWD/infra/proxy/nginx.conf:/etc/nginx/nginx.conf:ro" \
+  -v "$PWD/infra/proxy/conf.d:/etc/nginx/conf.d:ro" \
+  -v "$PWD/infra/proxy/tls:/etc/nginx/tls:ro" \
+  nginx:1.28-alpine nginx -t
+```
+
+Monter `infra/proxy/` entier sur `/etc/nginx` échouerait : `mime.types` vient de l'image.
@@ -0,0 +1,11 @@
+#!/bin/sh
+# Contrainte : certbot écrit dans /etc/letsencrypt/live/<domaine>/, nginx lit /etc/nginx/tls/.
+# Ce hook recopie le résultat à l'emplacement unique que la configuration nginx connaît, ce
+# qui rend le mode auto-signé et le mode ACME interchangeables sans toucher à un vhost.
+
+set -eu
+
+cp -L "$RENEWED_LINEAGE/fullchain.pem" /tls/fullchain.pem
+cp -L "$RENEWED_LINEAGE/privkey.pem" /tls/privkey.pem
+chmod 644 /tls/fullchain.pem
+chmod 600 /tls/privkey.pem
@@ -0,0 +1,69 @@
+# Piège : `X-Forwarded-For` se construit avec `$proxy_add_x_forwarded_for`, qui ajoute l'IP
+# réelle en fin de chaîne. `get_client_ip()` (apps/backend/app/api/deps.py) ne lit que le
+# dernier élément : toute autre forme rend la limitation de débit par IP globale, donc le
+# déni de service auto-infligé que ce code cherche précisément à éviter.
+# Piège : un nom d'hôte littéral dans `proxy_pass` fige l'IP du conteneur au démarrage de
+# nginx, et recréer `backend` seul donnerait des 502 jusqu'au rechargement du proxy. D'où la
+# 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.
+
+server {
+    listen 80 default_server;
+    server_name _;
+
+    location /.well-known/acme-challenge/ {
+        root /var/www/certbot;
+    }
+
+    location / {
+        return 301 https://$host$request_uri;
+    }
+}
+
+server {
+    listen 443 ssl default_server;
+    http2 on;
+    server_name _;
+
+    resolver 127.0.0.11 valid=10s ipv6=off;
+
+    ssl_certificate     /etc/nginx/tls/fullchain.pem;
+    ssl_certificate_key /etc/nginx/tls/privkey.pem;
+    ssl_protocols TLSv1.2 TLSv1.3;
+    ssl_prefer_server_ciphers off;
+    ssl_session_cache shared:SSL:10m;
+    ssl_session_timeout 1d;
+    ssl_session_tickets off;
+
+    # L'application refuse délibérément de poser ces deux en-têtes, verrouillé par
+    # tests/api/test_hardening.py. Ils appartiennent au terminateur TLS, c'est-à-dire ici.
+    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
+    add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self' data:; connect-src 'self'; frame-ancestors 'none'; base-uri 'self'; form-action 'self'" always;
+
+    proxy_http_version 1.1;
+    proxy_set_header Host              $host;
+    proxy_set_header X-Real-IP         $remote_addr;
+    proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
+    proxy_set_header X-Forwarded-Proto $scheme;
+    proxy_read_timeout 60s;
+
+    # Piège : la zone `auth` ne couvre que les routes qui vérifient un secret. Derrière le NAT de
+    # l'école, `/auth/me` et `/auth/refresh` y produiraient des 429 à chaque chargement de page.
+    location ~ ^/api/v1/auth/(login|password|forgot-password|reset-password)$ {
+        limit_req zone=auth burst=20 nodelay;
+        set $cible_api http://backend:8000;
+        proxy_pass $cible_api$request_uri;
+    }
+
+    location /api/ {
+        limit_req zone=api burst=40 nodelay;
+        set $cible_api http://backend:8000;
+        proxy_pass $cible_api$request_uri;
+    }
+
+    location / {
+        set $cible_web http://frontend:3000;
+        proxy_pass $cible_web$request_uri;
+    }
+}
@@ -0,0 +1,40 @@
+# Contrainte : les directives `limit_req_zone` ne sont valides que dans le bloc `http`.
+# Les `location` de conf.d/enervision.conf s'y réfèrent par nom, `api` et `auth`.
+
+worker_processes auto;
+error_log /var/log/nginx/error.log warn;
+pid /var/run/nginx.pid;
+
+events {
+    worker_connections 1024;
+}
+
+http {
+    include /etc/nginx/mime.types;
+    default_type application/octet-stream;
+
+    server_tokens off;
+
+    log_format enervision '$remote_addr - $remote_user [$time_local] "$request" '
+                          '$status $body_bytes_sent $request_time '
+                          '"$http_referer" "$http_user_agent"';
+    access_log /var/log/nginx/access.log enervision;
+
+    sendfile on;
+    tcp_nopush on;
+    keepalive_timeout 65;
+    client_max_body_size 2m;
+
+    gzip on;
+    gzip_vary on;
+    gzip_min_length 1024;
+    gzip_proxied any;
+    gzip_types application/javascript application/json application/xml
+               image/svg+xml text/css text/plain;
+
+    limit_req_zone $binary_remote_addr zone=api:10m  rate=20r/s;
+    limit_req_zone $binary_remote_addr zone=auth:10m rate=30r/m;
+    limit_req_status 429;
+
+    include /etc/nginx/conf.d/*.conf;
+}
@@ -0,0 +1,50 @@
+#!/usr/bin/env bash
+# Contrainte : nginx lit toujours infra/proxy/tls/{fullchain,privkey}.pem, quel que soit le
+# mode d'obtention. Ce script remplit ces deux fichiers pour la démonstration, certbot les
+# remplit par acme-deploy-hook.sh. La configuration nginx ne connaît pas la différence.
+
+set -euo pipefail
+
+RACINE="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
+DESTINATION="$RACINE/infra/proxy/tls"
+HOTE="${PUBLIC_HOST:-enervision.local}"
+ADRESSE="${PUBLIC_IP:-}"
+JOURS="${TLS_DAYS:-365}"
+ECRASER=0
+
+for argument in "$@"; do
+    case "$argument" in
+        --force) ECRASER=1 ;;
+        *)
+            echo "Usage : PUBLIC_HOST=exemple.local [PUBLIC_IP=10.0.0.10] $0 [--force]" >&2
+            exit 2
+            ;;
+    esac
+done
+
+if [[ -f "$DESTINATION/fullchain.pem" && $ECRASER -eq 0 ]]; then
+    echo "Un certificat existe déjà dans $DESTINATION." >&2
+    echo "Relancer avec --force pour l'écraser." >&2
+    exit 1
+fi
+
+mkdir -p "$DESTINATION"
+
+NOMS="DNS:$HOTE,DNS:localhost"
+if [[ -n "$ADRESSE" ]]; then
+    NOMS="$NOMS,IP:$ADRESSE"
+fi
+
+openssl req -x509 -nodes -newkey rsa:2048 -sha256 -days "$JOURS" \
+    -subj "/CN=$HOTE" \
+    -addext "subjectAltName=$NOMS" \
+    -keyout "$DESTINATION/privkey.pem" \
+    -out "$DESTINATION/fullchain.pem" 2>/dev/null
+
+chmod 600 "$DESTINATION/privkey.pem"
+chmod 644 "$DESTINATION/fullchain.pem"
+
+echo "Certificat auto-signé écrit dans $DESTINATION."
+echo "  Noms couverts : $NOMS"
+echo "  Validité      : $JOURS jours"
+echo "Le navigateur avertira d'un émetteur inconnu, c'est attendu hors Let's Encrypt."
Author	SHA1	Message	Date
Johan LEROY	5a29faaa16	Merge remote-tracking branch 'origin/dev' into pr117-fix	2026-09-21 12:11:39 +02:00
Johan LEROY	bc75528616	fix(infra): lève les points de revue du reverse proxy Compose interpole tout le fichier avant n'importe quelle sous-commande : la garde `${PUBLIC_HOST:?}` de l'overlay cassait `stack-down` et `stack-logs` autant que le démarrage. La valeur retombe sur `enervision.local`, et `stack-up` vérifie à la place que le certificat présent couvre l'hôte demandé, ce qui est la condition réelle à tenir. La CSP `script-src 'self'` bloquait le gestionnaire `onload` que l'inlining du CSS critique d'Angular pose sur la feuille de styles : l'application se serait affichée sans style derrière le proxy. `inlineCritical` passe à faux, le build de production ne produit plus aucun script en ligne. La zone de limitation resserrée ne couvre plus que les routes qui vérifient un secret. Derrière le NAT de l'école, où une seule adresse porte toute la promotion, `/auth/me` et `/auth/refresh` y auraient produit des 429 en usage normal. Enfin `certbot/certbot` est épinglé en v5.8.0 pour que Dependabot puisse le suivre, le proxy attend une API saine plutôt que démarrée, et la redirection vers `$host` est actée comme risque accepté : figer un nom canonique couperait l'accès par adresse IP, seule voie ouverte sur la machine cible.	2026-09-21 12:11:32 +02:00
Johan LEROYandGitHub	3cd9a6b272	Merge pull request #107 from ineszang/feat/supervision-des-capteurs feat(frontend): supervision des capteurs par site (admin)	2026-09-21 11:42:55 +02:00
Johan LEROY	26f834485c	Merge branch 'dev' into feat/supervision-des-capteurs	2026-09-21 11:39:00 +02:00
Johan LEROY	777cd0ac64	fix(frontend): affiche since comme la dernière lecture reçue, pas comme un début de panne Le schéma backend dit que since est l'horodatage de la dernière lecture du site, identique pour tous ses capteurs en panne et sans rapport avec le début de la panne. Le template annonçait « depuis <date> », ce que l'exploitant lit comme une date de début de panne. Un site sans aucune lecture renvoie ses cinq capteurs en échec avec since à null : le template affichait « depuis » suivi d'une chaîne vide. Ce cas dit maintenant « aucune lecture reçue ». Format de date explicite plutôt que 'short' : aucune locale n'est enregistrée dans app.config.ts, donc 'short' rendait la date au format en-US.	2026-09-21 11:38:52 +02:00
Johan LEROY	c528ed239b	Merge remote-tracking branch 'origin/dev' into feat/reverse-proxy-nginx-tls Rapatrie la #118 (DAGs Airflow). Quatre conflits, tous additifs sauf un : - `.env.example` et `.gitignore` : les blocs Airflow et proxy cohabitent. - `Makefile` : `AIRFLOW` rejoint les variables de dossier, les cibles Airflow et TLS cohabitent dans `.PHONY`. - `00-vue-ensemble.md` : la ligne ML de `dev` est retenue, la ligne Infra de cette branche aussi, chacune portant sa propre mise à jour. L'interface Airflow rejoint la base et Mailpit sur `127.0.0.1` dans l'overlay : elle n'a pas d'authentification à publier derrière le proxy.	2026-09-21 11:24:42 +02:00
Johan LEROY	a88e51c92a	Merge remote-tracking branch 'origin/dev' into feat/reverse-proxy-nginx-tls Trois conflits, tous documentaires ou de liste : - `.env.example` : les variables de l'API Mock et celles du proxy cohabitent. - `Makefile` : la cible `recommendations` rejoint les cibles TLS dans `.PHONY`. - `owasp-traceabilite.md` : la ligne API10 de `dev` est retenue, la ligne API8 « ouvert » de `dev` est abandonnée puisque cette branche la déplace vers les points couverts. Au passage, l'ADR 0006 arrivé par la #114 manquait aux deux index de décisions, et l'ADR 0007 manquait à celui de la vue d'ensemble.	2026-09-21 11:21:45 +02:00
PhyriosandGitHub	f3ea2785b3	Merge pull request #118 from ineszang/feat/dag-ml-train-score feat(etl,ml): orchestre l'entrainement et le scoring LightGBM via deu…	2026-09-21 11:19:43 +02:00
Dorian	901ceffd72	fix(etl): fiabilise airflow-init, borne les DAGs ML et ajoute la CI Airflow Airflow / Lint et intégrité des DAGs (push) Successful in 1m10s Details Airflow / Construction de l'image (push) Successful in 1m47s Details	2026-09-21 11:18:02 +02:00
Dorian	6f6f451eb4	Merge remote-tracking branch 'origin/dev' into feat/dag-ml-train-score	2026-09-21 10:39:07 +02:00
Johan LEROYandGitHub	cc3e38efa3	Merge pull request #112 from ineszang/feat/mock-api-import Import des données depuis l'API Mock	2026-09-21 10:29:36 +02:00
Dorian	b941880c22	feat(etl,ml): orchestre l'entrainement et le scoring LightGBM via deux DAGs Airflow	2026-09-21 10:03:23 +02:00
Johan LEROY	0c487fa7be	docs: acte la terminaison TLS par l'ADR 0007 et met à jour les vues L'ADR 0007 tranche le reverse proxy en Compose plutôt que l'ingress k3s, qui supposait un registre et des manifestes inexistants, et referme la première question ouverte de 10-infra.md. Les vues suivent : troisième topologie et ports 80/443 dans 10-infra.md, TLS, HSTS et CSP passent d'« Absent, et assumé » à « En place » dans la vue d'ensemble, la ligne API8 transport rejoint les points couverts de la traçabilité OWASP. Trois affirmations périmées disparaissent au passage : le compose a bien un service frontend, environment.ts ne pointe plus sur localhost:8000, et le Dockerfile du front n'est plus mono-étage sur une branche.	2026-09-21 09:51:19 +02:00
Johan LEROY	b3efb98208	feat(infra): reverse proxy Nginx et terminaison TLS devant la stack Le SPA appelle /api/v1 en relatif et rien ne routait cet appel vers l'API une fois en conteneur. Le cookie de rafraîchissement prend le préfixe __Secure- dès que APP_ENV sort de local, donc sans HTTPS il n'était jamais posé et l'authentification ne survivait pas à un rechargement de page. Un service proxy, image officielle nginx dont la configuration est montée en volume, devient le seul composant publié : 80 redirige vers 443 et sert le défi ACME, 443 termine le TLS, sert le SPA sur / et l'API sur /api/ sous la même origine, pose HSTS et CSP que l'application refuse délibérément de poser, et ajoute une limitation de débit au frontal. Backend et frontend ne sont plus publiés, la base et l'interface Mailpit sont ramenées sur la boucle locale. nginx lit toujours les deux mêmes fichiers de certificat : seule leur fabrication varie, script openssl pour la démonstration, deploy-hook certbot le jour où un domaine public existera. Le chemin ACME est livré et documenté, pas exercé : sur une IP privée le défi HTTP-01 ne peut pas aboutir.	2026-09-21 09:51:09 +02:00
Johan LEROY	2d7b4bd74d	fix: publie le service frontend sur 3000, le port qu'écoute son nginx Le compose mappait vers le port 80 du conteneur alors que le nginx de l'image écoute sur 3000 (apps/frontend/nginx.conf, EXPOSE 3000). Le port publié ne pointait sur rien, le service frontend ne répondait pas.	2026-09-21 09:51:09 +02:00
ValentinDeFariaandGitHub	f9c2a4610c	Update dashboard.ts Frontend / Audit des dépendances (push) Successful in 6s Details SonarQube / build-back (push) Successful in 1m6s Details Frontend / build (push) Successful in 9m52s Details SonarQube / build-front (push) Successful in 9m44s Details SonarQube / test-back (push) Failing after 52s Details Frontend / test (push) Failing after 5m0s Details SonarQube / test-front (push) Failing after 5m2s Details SonarQube / SonarQube (push) Skipped Details	2026-09-18 16:56:59 +02:00
ValentinDeFariaandGitHub	b5fa7b0010	Merge branch 'dev' into feat/supervision-des-capteurs	2026-09-18 16:54:39 +02:00
Valentin	7f710c9084	feat(frontend): supervision des capteurs par site (admin)	2026-09-18 12:02:48 +02:00