Johan LEROY
1f6210698d
Le jeton de rafraîchissement est une chaîne opaque de 256 bits, jamais un JWT. Il doit être révocable, donc sa ligne en base existe de toute façon, et le JWT n'ajouterait qu'un second chemin de signature. Surtout, la séparation d'avec le jeton d'accès devient structurelle : un JWT ne figure dans aucune ligne, une chaîne opaque échoue au décodage. La confusion refresh-vers-accès, qui transforme une fenêtre de 15 minutes en fenêtre de 7 jours, est impossible même si quelqu'un oublie le test. Seule l'empreinte SHA-256 est stockée. Pas d'Argon2 : l'entrée fait 256 bits de CSPRNG, aucun dictionnaire ne l'atteint, et une KDF coûterait 17 ms à chaque rafraîchissement. La rotation ne protège de rien par elle-même : elle rend la réutilisation détectable, et c'est la détection qui termine le vol. Un jeton déjà tourné révoque donc toute sa famille et laisse une trace dans `audit_log` ; un jeton expiré, lui, ne révoque rien, ce n'est pas une preuve de compromission. Les deux cas ont leur test. La revendication est une seule instruction SQL avec RETURNING. Un SELECT puis un UPDATE laisseraient une fenêtre où deux onglets réussissent la même rotation ; le test d'intégration le prouve, ce qui est indémontrable sur un double. `expires_at` est absolu et hérité du prédécesseur : s'il glissait, la promesse de sept jours serait fictive. Corrige au passage un défaut trouvé par un test : une `HTTPException` construit sa propre réponse, donc l'effacement du cookie posé sur la `Response` injectée était perdu. Un navigateur gardait un cookie mort après une détection de réutilisation.
EnerVision
Monorepo de la plateforme EnerVision : collecte, stockage, analyse et restitution de series temporelles energetiques, deployee sur une machine on-premise.
Jalons
| Jalon | Intitulé |
|---|---|
| J1 | Valider la préparation de l'environnement et du repo |
| J2 | Valider le périmètre retenu et les choix technologiques |
| J3 | Valider l'architecture et la gestion de la sécurité |
| J4 | Valider la robustesse et assurer les livrables |
Ce que la documentation apporte à chacun : docs/architecture/00-vue-ensemble.md.
Stack cible
| Domaine | Technologie | Emplacement | Etat |
|---|---|---|---|
| Backend | FastAPI, Python 3.14 | apps/backend |
Initialise |
| Frontend | Angular 22, Node 24 LTS | apps/frontend |
Squelette |
| Base | PostgreSQL 17 + TimescaleDB | db |
Initialise |
| ETL | Apache Airflow | etl/airflow |
A initialiser |
| Infra | Terraform (k3s single-node) | infra/terraform |
Initialise |
| CI/CD | GitHub Actions | .github/workflows |
A initialiser |
| Monitoring | Prometheus, Grafana, Alertmanager | monitoring |
A initialiser |
Le backend, la base et l'infrastructure (Terraform/k3s) sont initialises a ce stade. Le frontend porte le squelette Angular, sans code metier : aucune route, aucun appel d'API. Les autres dossiers portent l'arborescence et un README de cadrage, leur contenu fait l'objet d'un ticket dedie.
L'etat detaille de chaque brique et les vues d'architecture sont dans docs/architecture.
Arborescence
.
├── apps/
│ ├── backend/ API FastAPI
│ └── frontend/ Application Angular
├── db/
│ ├── init/ Bootstrap PostgreSQL + TimescaleDB
│ ├── migrations/ Migrations SQL versionnees
│ └── seeds/ Jeux de donnees de reference
├── etl/airflow/
│ ├── dags/ DAGs d'ingestion et d'agregation
│ ├── plugins/ Operateurs et hooks maison
│ ├── include/ Requetes SQL et ressources des DAGs
│ └── tests/ Tests d'integrite des DAGs
├── infra/terraform/
│ ├── modules/ Modules reutilisables
│ └── environments/ Racines Terraform, une par environnement
├── monitoring/
│ ├── prometheus/ Collecte et regles d'alerte
│ ├── grafana/ Provisioning et dashboards
│ └── alertmanager/ Routage des alertes
├── docs/ ADR et vues d'architecture
└── scripts/ Outillage local
Demarrage
Prerequis : uv, Docker. Le poste doit disposer de Python 3.14, que uv installe seul.
cp .env.example .env # variables de docker-compose
cp apps/backend/.env.example apps/backend/.env # variables du backend hors conteneur
make db-up # PostgreSQL + TimescaleDB, publie sur le port 5433
make install # dependances du backend
make migrate # applique les migrations Alembic
make dev # API sur http://localhost:8000, docs sur /docs
make check # lint + typage + tests
make help liste les cibles disponibles.
Deux fichiers d'environnement, deux usages : .env a la racine alimente docker-compose.yml,
apps/backend/.env alimente le backend lance sur le poste. Le port 5433 est publie plutot que
5432, souvent deja pris par une autre base.
La boucle de developpement est make db-up puis make dev : seule la base tourne en
conteneur. Le service backend du docker-compose.yml sert la stack complete et la recette,
et n'embarque pas le source, donc toute modification y demande un
docker compose up -d --build backend.
Verifier que la base repond et que l'extension est chargee :
curl -s localhost:8000/api/v1/health/ready
Conventions
- Branches :
feat/,fix/,chore/,docs/,test/suivi d'un libelle court. - Commits : Conventional Commits, portee = dossier de premier niveau concerne.
- Toute decision structurante donne lieu a un ADR dans
docs/adr. - Toute PR qui change un composant met a jour sa vue dans
docs/architecture, dans la meme PR.