Le pipeline ML n'avait aucun test touchant PostgreSQL : `ml/README.md` le disait, faute de
base joignable en CI. Le marqueur `integration` de `ml/pyproject.toml` etait declare et porte
par zero test.
- `ml/tests/conftest.py` : deux fixtures d'acces a la base, jamais interchangeables.
`connexion_ml` annule sa transaction, `parc` valide ses ecritures parce que `run_scoring`
ouvre sa propre connexion et ne verrait rien d'autre. Garde sur le nom de base, marque uuid
sur chaque site, nettoyage dans l'ordre des cles etrangeres.
- `test_data_integration.py` : les neuf colonnes du contrat confrontees au schema Alembic
reel, la borne `since`, l'ordre de tri dont dependent des lags positionnels, et le typage
des colonnes entierement nulles.
- `test_score_integration.py` : les contraintes de `prediction` vues depuis le code qui
ecrit, l'empilement volontaire de deux runs, et `run_scoring` de bout en bout sur un
booster reel.
- `apps/backend/tests/test_chaine_ml_api.py` : lance les vrais binaires `enervision_ml.train`
et `.score` en sous-processus, comme les DAGs, puis relit par `GET /api/v1/predictions`.
Marqueur `chaine` distinct : le job `integration` du backend n'a pas l'environnement de ml/.
- `ml.yml` : job `integration`, seul du depot a reunir les deux environnements uv et une base.
Ses `paths` incluent les migrations du backend, sans quoi le schema deriverait du SQL du
pipeline sans que rien ne casse.
- Makefile : `migrate-test`, qui manquait (`enervision_test` n'a jamais recu de table),
`ml-test-integration` et `test-chaine`.