Johan LEROY
d506e8f7ef
Revue de la branche : trois defauts empechaient la surveillance de tenir ce qu'elle annonce. - `evaluate()` gardait les microsecondes de `now()` dans `window_end`, la cle de `uq_drift_report_window`. Deux executions ne collidaient donc jamais et l'index ne dedoublonnait rien, contrairement a ce qu'affirmaient l'ADR 0011, 20-backend et le docstring du DAG. L'instant de reference est desormais tronque a l'heure. - Un site qui cessait d'etre score disparaissait du rapport : la liste des sites ne venait que de la fenetre recente. La panne que cette surveillance existe pour dire etait exactement celle qu'elle taisait. La fenetre de reference entre maintenant dans l'union, et le site recoit sa ligne `indetermine` a zero observation. - Sans fenetre de reference, `_plafond` rendait `None` et le verdict tombait sur `stable`, une affirmation que la donnee ne portait pas. C'est `indetermine` desormais. `ml.yml` ecoute `apps/backend/app/**` et non les seuls modeles : ce workflow est le seul a jouer `-m chaine`, or la chaine traverse les endpoints, les services et les schemas jusqu'a `GET /predictions`. Une PR touchant `predictions.py` ne declenchait pas le test qui l'assert. Hygiene de tests : le nettoyage des fixtures API connait `drift_report` (cle etrangere RESTRICT vers `site`), le test sans rapport rend ses overrides en teardown, `test_chaine_ml_api` compare les `created_at` strictement (un `>=` passait aussi quand l'API resservait la premiere ligne), et `test_data_integration` filtre sur le site seme au lieu de juger tout le contenu d'une fenetre dans une base partagee. Docs remises d'aplomb : sept revisions Alembic et non six, `derive.py` dans l'inventaire de etl/README, et le diagramme de 20-backend gagne DriftService, le depot drift et sa treizieme table.
Architecture
Les vues d'architecture d'EnerVision. Un ADR (../adr/) décide et date une décision
structurante ; une vue d'architecture décrit le système qui en résulte. Quand les deux se
contredisent, c'est l'ADR qui fait foi et la vue qui est en retard.
Les documents
| Document | Ce qu'il couvre |
|---|---|
| 00-vue-ensemble.md | Jalons du projet, contexte, conteneurs, sécurité, flux bout en bout |
| 10-infra.md | Poste de développement, cible k3s, décisions figées, ports et noms |
| 20-backend.md | Couches FastAPI, séquence de démarrage, routes, configuration, contrat OpenAPI |
| 30-frontend.md | Angular, arborescence cible, flux HTTP |
| 31-contrat-authentification.md | Ce que le frontend doit savoir pour coder la connexion |
| 32-design-systeme-frontend.md | Tokens CSS, composants ev-* partagés, règle anti-couleur-en-dur |
| 40-data.md | Frontières db/ et alembic/, cycle de vie d'une mesure, modèle |
| 50-cicd.md | Workflows, gates bloquantes, SonarCloud, Dependabot, ce qui manque |
La CI/CD a désormais son document : cinq workflows et seize jobs, c'est assez de matière pour
qu'une section de plus dans une autre vue devienne illisible. L'observabilité, elle, n'en a
toujours pas : monitoring/ ne contient que des .gitkeep. Elle en sortira le jour où elle aura
de la matière. Un fichier vide de plus n'aide personne.
L'orchestration Airflow, elle, en a depuis les issues #115 et #116 : trois DAGs, leur image et leurs contraintes sont décrits dans 10-infra.md.
La sécurité applicative, elle, a désormais de la matière : la vue consolidée reste dans 00-vue-ensemble.md, le détail dans 20-backend.md, la traçabilité OWASP dans owasp-traceabilite.md, et les décisions dans les ADR 0002 à 0004.
Conventions
Mermaid, et rien d'autre
GitHub rend Mermaid nativement dans les fichiers .md. Un diagramme est donc du texte : il se
relit en revue, il se diffe, et il ne se périme pas dans un binaire que plus personne ne sait
rouvrir six mois plus tard. Aucune image exportée, aucun .drawio, aucun .png.
Chaque section porte son statut
Une large part de la stack n'est pas écrite. Une vue qui mélange l'existant et la cible sans le dire devient fausse sans prévenir.
| Statut | Sens |
|---|---|
Fait |
Le code existe et tourne |
En cours |
Commencé, incomplet |
Cible |
Décidé, pas encore écrit |
Légende des diagrammes
Trait plein pour ce qui tourne, trait pointillé pour ce qui est cible.
flowchart LR
A[Composant en place] --> B[Composant en place]
B -.-> C[Composant cible]
Maintenance
Toute PR qui change un composant met à jour sa vue dans la même PR. Une vue qu'on promet de mettre à jour plus tard ne l'est jamais.
Une documentation fausse coûte plus cher qu'une documentation absente : on la lit, on la croit, et on construit dessus. Si une section ne peut plus être tenue à jour, elle est supprimée plutôt que laissée à dériver.