Merge remote-tracking branch 'origin/dev' into feat/reconciliation-dag

etl/airflow/dags/mock_api_import.py

@@ -1,7 +1,7 @@
 """DAG d'import périodique des données de l'API Mock EnerVision (issue #15).
 
 Orchestre le pipeline existant `app.etl.mock_api_import` sans dupliquer sa logique ETL.
-Chaque exécution traite l'heure précédant son déclenchement.
+Chaque exécution importe la mesure de l'heure pile qui précède son déclenchement.
 
 Le pipeline backend reste responsable de la validation, de la normalisation, du suivi de la
 qualité, de l'idempotence et du chargement dans PostgreSQL/TimescaleDB.
@@ -26,11 +26,11 @@ PLAFOND_PAR_TENTATIVE = timedelta(minutes=10)
 
 # L'intervalle est déclaré explicitement pour ne pas dépendre de la valeur du paramètre Airflow
 # `create_cron_data_intervals`. Le déclenchement à :45 laisse quinze minutes avant `ml_score`,
-# exécuté à l'heure pile, puis avant `alertes`, exécuté à :15. Conséquence vérifiée empiriquement
-# sur l'API Mock (cf. `limit_for_window()` dans `app.etl.mock_api_import`) : la fenêtre importée
-# est `[:45, :45)`, donc chaque lecture atterrit à :45, pas à :00, un décalage constant sur
-# toute la série, sans effet sur les lags positionnels ni sur les jointures en aval (`ml_score`
-# vise la dernière lecture + 1h, `derive` joint à l'égalité), cf. 40-data.md.
+# exécuté à l'heure pile, puis avant `alertes`, exécuté à :15. La fenêtre demandée à l'API Mock
+# (voir `bash_command` ci-dessous) ne suit pas cet intervalle Airflow tel quel : elle part de
+# l'heure pile qui précède le déclenchement, pas de `data_interval_start`, pour que l'unique
+# lecture demandée (`app.etl.mock_api_import.limit_for_window()`) atterrisse à :00 et non à :45
+# (vérifié empiriquement sur l'API Mock), au pas horaire du reste du schéma, cf. 40-data.md.
 PLANIFICATION = CronTriggerTimetable(
     "45 * * * *",
     timezone="UTC",
@@ -51,12 +51,16 @@ with DAG(
         task_id="import_mock_api",
         bash_command=(
             f"{COMMANDE_BACKEND} app.etl.mock_api_import "
-            "--start-time \"{{ data_interval_start.strftime('%Y-%m-%dT%H:%M:%S') }}\" "
+            # `--start-time` part de l'heure pile qui précède le déclenchement, pas de
+            # `data_interval_start` : sur `[:45, :45)`, l'API aurait placé son unique lecture
+            # à :45, hors de la grille horaire du reste du schéma (vérifié empiriquement).
+            "--start-time \"{{ data_interval_end.strftime('%Y-%m-%dT%H:00:00') }}\" "
             "--end-time \"{{ data_interval_end.strftime('%Y-%m-%dT%H:%M:%S') }}\""
             # Pas de --limit : app.etl.mock_api_import.limit_for_window() le dérive de la
-            # fenêtre (une lecture/heure), et refuse une fenêtre qui ne couvre pas un nombre
-            # entier d'heures ou dépasse le plafond de l'API. Porter la règle dans le code,
-            # pas dans ce DAG, évite qu'un appel manuel oublie de la respecter.
+            # fenêtre (ici plus courte qu'une heure, donc une seule lecture, ancrée sur
+            # --start-time) et refuse une fenêtre qui ne démarre pas pile sur l'heure. Porter
+            # la règle dans le code, pas dans ce DAG, évite qu'un appel manuel oublie de la
+            # respecter.
         ),
         retries=NOMBRE_REPRISES,
         retry_delay=DELAI_ENTRE_REPRISES,