Files
ENI-projet-piscine/docs/architecture
Johan LEROY 19c38fe571
Backend / Tests exigeant une base (push) Failing after 34s
Backend / Lint, typage et tests (push) Successful in 1m24s
Backend / Audit des dépendances (push) Successful in 57s
SonarQube / build-back (push) Successful in 1m5s
SonarQube / build-front (push) Successful in 9m39s
SonarQube / test-back (push) Failing after 51s
SonarQube / test-front (push) Failing after 5m6s
SonarQube / SonarQube (push) Skipped
fix(backend): decoupe l'insertion des recommandations en lots et remet les docs a jour
`create_missing()` construisait un seul `INSERT ... VALUES` pour la totalite des
propositions. Avec quatre colonnes par ligne et le plafond asyncpg de 32 767
parametres, la route echouait au-dela de 8 191 recommandations par appel, cas
devenu realiste maintenant que la detection interne (#104) alimente `alert` en
continu. L'insertion passe par des lots de `TAILLE_DE_LOT` lignes, sur le patron
de `app/etl/historical_import.py`.

L'ADR 0006, `20-backend.md` et la description de la PR annoncaient qu'aucune
source n'alimentait `alert` et que #104 n'etait pas commencee. #104 est livree
sur `dev` depuis la #113 : les phrases sont corrigees plutot que laissees a
vieillir dans un ADR.
2026-09-21 09:45:25 +02:00
..

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

L'observabilité et la CI/CD n'ont pas de document propre : ce sont des sections des documents ci-dessus, tant que monitoring/ et etl/airflow/ ne contiennent que des .gitkeep. Elles en sortiront le jour où elles auront de la matière. Un fichier vide de plus n'aide personne.

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.