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.

.env.example

@@ -29,6 +29,21 @@ 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

.github/workflows/airflow.yml

@@ -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"

.gitignore

@@ -66,6 +66,9 @@ 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
 

Makefile

@@ -1,6 +1,7 @@
 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.
@@ -13,16 +14,18 @@ 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 \
+        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
@@ -33,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 & \
@@ -91,6 +97,24 @@ 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)
 

db/init/120-airflow-database.sql

@@ -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;

docker-compose.prod.yml

@@ -15,6 +15,10 @@ services:
     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:

docker-compose.yml

@@ -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
@@ -70,7 +100,64 @@ services:
     ports:
       - "${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:

docs/architecture/00-vue-ensemble.md

@@ -60,7 +60,7 @@ flowchart TB
   proxy --> api
   front -.-> api
   api --> db
-  airflow -.-> db
+  airflow --> db
   prom -.-> api
   grafana -.-> db
   grafana -.-> prom
@@ -70,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.
 
@@ -80,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 |
+| 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

docs/architecture/10-infra.md

@@ -41,13 +41,63 @@ 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).
+
+### 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
 
@@ -158,6 +208,8 @@ Ces arbitrages sont pris. Ils ne vivaient jusqu'ici que dans des commentaires de
 | 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 vers k3s
 

docs/architecture/20-backend.md

@@ -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
+La détection est un script lancé à la main, pas encore ordonnancé par Airflow (contrairement à
-Airflow : `uv run python -m app.detection.internal_alerts [--site-id ...] [--now ...]`, dans
+`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

docs/architecture/owasp-traceabilite.md

@@ -61,7 +61,7 @@ le certificat servi reste auto-signé. Le chemin ACME est livré et documenté,
 | **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

etl/README.md

@@ -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 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).
-
-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.
 
 Le pipeline Data servira ensuite à préparer les données nécessaires au modèle de Machine Learning.

etl/airflow/.python-version

@@ -0,0 +1 @@
+3.12

etl/airflow/Dockerfile

@@ -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

etl/airflow/dags/ml_score.py

@@ -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),
+    )

etl/airflow/dags/ml_train.py

@@ -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),
+    )

etl/airflow/pyproject.toml

@@ -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"

etl/airflow/tests/conftest.py

@@ -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'}"
+)

etl/airflow/tests/test_dags.py

@@ -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

infra/proxy/README.md

@@ -21,6 +21,10 @@ configuration est montée en volume par `docker-compose.prod.yml`.
 | `/api/` | `backend:8000` | Préfixe `/api/v1` préservé tel quel |
 | `/` | `frontend:3000` | Le SPA, qui renvoie `index.html` sur les routes inconnues |
 
+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