Décisions d'architecture
Les choix techno structurants, documentés avec leur contexte et leurs alternatives
Un ADR pour toute décision structurante. Si un nouveau dev doit comprendre "pourquoi on a choisi X plutôt que Y", l'ADR est là.
Qu'est-ce qu'un ADR ?
Architecture Decision Record. Un document court qui capture :
- Le contexte — quel problème on essaie de résoudre
- Les alternatives — ce qu'on a considéré, avec pour/contre
- La décision — ce qu'on a choisi et pourquoi
- Les conséquences — ce que ça implique (positives et négatives)
- Les métriques — comment on saura plus tard si c'était le bon choix
Une fois accepté, un ADR ne se modifie pas. Si on change d'avis, on écrit un nouvel ADR qui remplace ou amende le précédent (et on met Statut: Remplacé par ADR-XX).
Les 9 décisions actuelles
ADR-01 — Séparation apps pwa / dashboard
Deux Next.js séparés plutôt qu'un seul avec route groups
ADR-02 — Auth via cookies HttpOnly
Pas de Bearer token côté client, cookies only avec proxy Next rewrites en dev
ADR-03 — Realtime via SSE Elysia
Server-Sent Events pour l'unlock check-in et les chats — pas de WebSocket
ADR-04 — Jobs hybrides cron + BullMQ
@elysiajs/cron pour le périodique, BullMQ pour le déclenché avec retries
ADR-05 — State machines
Fonctions pures validées côté DB et API pour les transitions
ADR-06 — Stratégie de tests
Bun test partout, Playwright pour les 3 flows critiques
ADR-07 — Eden Treaty + TypeBox
On exploite Elysia à fond, pas de tRPC
ADR-08 — Monitoring Signoz
OpenTelemetry + Signoz self-hosted
ADR-09 — Validation email Reacher
Check de délivrabilité avant d'envoyer un check-in email
ADR-10 — AI provider + RAG
Claude Haiku 4.5 default, Sonnet 4.6 Enterprise, prompt caching, RAG pgvector, quotas par plan