6 Commits

Include renames

Author	SHA1	Message	Date
Johan LEROY	19ff152445	refactor(etl): migre les DAGs et leurs tests vers le SDK Airflow 3 ... DAG et BaseOperator viennent d'airflow.sdk, BashOperator du provider standard (airflow.operators.bash n'est plus qu'un alias déprécié). DagBag s'importe depuis airflow.dag_processing et ne prend plus include_examples, les exemples étant déjà coupés par la configuration de conftest.py. Les timetables n'exposent plus summary : la planification se lit sur dag.schedule (None) et timetable.expression (cron normalisé).	2026-09-22 09:01:07 +02:00
Johan LEROY	f8d08c8686	fix(etl): borne le DAG alertes sur son pire cas et couvre sa seconde commande en CI ... `execution_timeout` plafonne une tentative, pas la tâche. Avec deux reprises, quinze minutes par tentative autorisaient quarante-neuf minutes par tâche et quatre-vingt-dix-huit pour l'enchaînement, quand le commentaire annonçait une somme tenant sous le pas horaire. Le plafond passe à cinq minutes, ce qui borne le pire cas à trente-huit minutes, et le test d'intégrité calcule désormais ce pire cas plutôt que la somme des plafonds : reprises et délais d'attente compris, c'est la durée qu'un `max_active_runs=1` fait payer à l'exécution suivante. La CI vérifie aussi `app.cli generate-recommendations --help` sans réseau. C'est la seconde commande du DAG, et son import tire FastAPI, les repositories et les services, donc une part de l'environnement `/opt/backend` que la détection seule ne touche pas. `10-infra.md` nomme enfin ce que le décalage de quinze minutes ne garantit pas : le plafond de `ml_score` valant trente minutes, un scoring qui déborde prive la règle `anomaly` de la prédiction de l'heure, qu'elle ne retrouvera au passage suivant que si sa fenêtre la couvre encore.	2026-09-21 13:28:23 +02:00
Johan LEROY	ae58a896d9	feat(etl): ordonnance la détection d'alertes et les recommandations par un DAG Airflow ... Le DAG `alertes` enchaîne `app.detection.internal_alerts` puis `app.cli generate-recommendations`, à la quinzième minute de chaque heure. Le décalage laisse finir `ml_score`, qui écrit à l'heure pile les prédictions dont la règle `anomaly` a besoin, sans créer de dépendance entre les deux DAGs : quatre règles de détection sur cinq ne touchent pas au modèle, et un modèle jamais entraîné ne doit pas priver le parc de ses alertes. L'image Airflow porte un second environnement uv, `/opt/backend/.venv`, puisque la logique vit dans le backend (ADR 0006) et qu'aucune route HTTP ne l'expose. Le `UV_PROJECT_ENVIRONMENT` global hérité de l'issue #115 disparaît : il vaut pour tous les projets, donc `uv run` depuis `/opt/ml` résolvait le venv du backend. uv prend `<projet>/.venv` par défaut, se placer dans le dossier suffit. La CI vérifie maintenant que les deux environnements s'importent sans réseau. Le conteneur reçoit `DATABASE_URL` en asyncpg et une `APP_SECRET_KEY` distincte de celle de l'API, alimentée par `AIRFLOW_APP_SECRET_KEY` : la détection ne signe aucun jeton, et Airflow permet d'exécuter du code depuis son interface.	2026-09-21 12:13:55 +02:00
Dorian	901ceffd72	fix(etl): fiabilise airflow-init, borne les DAGs ML et ajoute la CI Airflow	2026-09-21 11:18:02 +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	26704831e4	chore: arborescence du monorepo EnerVision ... Pose les dossiers des sept domaines de la stack (backend, frontend, base, ETL, infra, CI/CD, monitoring) avec un README de cadrage par domaine. Seul apps/backend est initialise, les autres font l'objet d'un ticket dedie. Le squelette Angular n'est pas versionne a la main : apps/frontend porte la commande ng new a lancer.	2026-09-14 12:26:12 +02:00