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.

docs/architecture/20-backend.md

@@ -146,6 +146,7 @@ Deux fichiers d'environnement, deux usages : `.env` à la racine alimente `docke
 | GET | `/api/v1/alerts` | Liste les alertes, filtrable par `site_id` et `severity`. `lecteur` | 401, 403, 422, 500 |
 | GET | `/api/v1/recommendations` | Liste les recommandations. `lecteur` | 401, 403, 500 |
 | GET | `/api/v1/recommendations/{recommendation_id}` | Décrit une recommandation. `lecteur` | 401, 403, 404, 422, 500 |
+| POST | `/api/v1/recommendations/generate` | Applique le moteur de règles aux alertes, filtrable par `site_id`. `admin` | 401, 403, 422, 500 |
 | GET | `/api/v1/stats/summary` | Résume la consommation instantanée du parc. `lecteur` | 401, 403, 500 |
 | GET | `/api/v1/readings` | Historique des lectures, filtrable par `site_id`, fenêtre `start`/`end` (24h par défaut, 90 jours maximum) et paginé par `limit`/`offset`. `lecteur` | 400, 401, 403, 422, 500 |
 | GET | `/api/v1/sensors/status` | État de santé des capteurs par site, dérivé de la dernière lecture. `admin` | 401, 403, 500 |
@@ -194,6 +195,21 @@ plutôt qu'un statut inventé : le domaine `available`/`insufficient_data`/`erro
 LightGBM elle-même ; elle lit ce que le pipeline de scoring a déjà écrit, cf.
 [ML-START.md](../../ML-START.md) section 3.
 
+`POST /recommendations/generate` est la seule route d'écriture métier du contrat. Elle applique
+le moteur de règles d'`app/services/recommendation_rules.py` aux lignes d'`alert`, sans modèle ni
+feature ML : le catalogue `REGLES` associe à chaque type et à chaque gravité d'alerte une action et
+son explication, et une même alerte peut en déclencher plusieurs, comme le prévoit
+[40-data.md](40-data.md). L'idempotence est portée par la base, pas par le service :
+`RecommendationRepository.create_missing()` insère en `ON CONFLICT DO NOTHING` sur
+`uq_recommendation_alert_rule`, donc rejouer la génération sur les mêmes alertes ne crée rien et
+le rapport rendu distingue `recommendations_created` de `already_present`. Le même traitement est
+disponible hors HTTP par `python -m app.cli generate-recommendations` (cible `make
+recommendations`), sur le patron de `make ml-score`. Le choix de loger le moteur dans le backend
+plutôt que dans `ml/` est justifié par l'[ADR 0006](../adr/0006-moteur-de-regles-dans-le-backend.md).
+Les alertes traitées sont celles qu'écrit la détection interne (#104, section ci-dessous) : la
+génération ne rend donc de recommandations qu'une fois la détection passée. L'insertion est
+découpée en lots de `TAILLE_DE_LOT` lignes, asyncpg plafonnant une requête à 32 767 paramètres.
+
 `GET /readings` reprend le même gabarit mais s'en écarte sur un point : `reading` est l'hypertable,
 donc la seule table métier pouvant porter des années d'historique, ce que `docs/architecture/
 owasp-traceabilite.md` documentait comme un risque ouvert (API4, aucune pagination plafonnée ni