docs: acte l'ordonnancement des alertes par l'ADR 0008 et met à jour les vues

L'ADR 0008 décide qu'Airflow exécute le code du backend en sous-processus plutôt
que d'appeler l'API, et assume ce que cela coûte : une image plus lourde, la CI
Airflow déclenchée par les changements du backend, une clé applicative de plus.

Les vues suivent. Trois DAGs dans 10-infra.md et dans la vue d'ensemble, avec le
motif du décalage horaire. La détection n'est plus « lancée à la main » dans
20-backend.md. La génération des recommandations gagne son troisième déclencheur
dans 40-data.md. La dette de cantonnement ETL et ML porte l'aggravation comme
l'atténuation. L'affirmation selon laquelle `etl/airflow/` ne contient que des
`.gitkeep`, fausse depuis l'issue #115, disparaît.

L'index des décisions omettait les ADR 0005 et 0006, il les récupère au passage.

docs/architecture/40-data.md

@@ -14,8 +14,10 @@ décrivent les éléments prévus mais pas encore réalisés.
 
 L'ingestion des **mesures** est implémentée pour les deux sources du MVP, le dataset CSV/JSON et
 l'API Mock. Celle des **alertes** de l'API Mock, `/alerts`, reste à faire : voir
-l'[ADR 0006](../adr/0006-moteur-de-regles-dans-le-backend.md). L'orchestration Airflow, les
-agrégats continus, la compression et la rétention restent des cibles.
+l'[ADR 0006](../adr/0006-moteur-de-regles-dans-le-backend.md). Les alertes `source='enervision'`,
+elles, sont produites par la détection interne, désormais ordonnancée par le DAG Airflow `alertes`
+(issue #116). L'orchestration de l'ingestion, les agrégats continus, la compression et la
+rétention restent des cibles.
 
 ## Trois emplacements, trois rôles
 
@@ -290,10 +292,10 @@ Les anomalies historiques décrites dans les JSON sont conservées dans `dataset
 Elles servent à l'analyse des données et ne sont pas considérées comme des alertes actuelles.
 
 Les lignes de `recommendation` sont écrites par le moteur de règles du backend
-(`app/services/recommendation_rules.py`), déclenché par `POST /api/v1/recommendations/generate`
-ou par `make recommendations`, à partir des alertes déjà en base. Le couple
-`(alert_id, rule_reference)` est unique : rejouer le moteur sur les mêmes alertes n'ajoute aucune
-ligne.
+(`app/services/recommendation_rules.py`), déclenché par `POST /api/v1/recommendations/generate`,
+par `make recommendations`, ou par la seconde tâche du DAG `alertes`, à partir des alertes déjà en
+base. Le couple `(alert_id, rule_reference)` est unique : rejouer le moteur sur les mêmes alertes
+n'ajoute aucune ligne.
 
 ### Relations entre les tables