Architecture Decision Records
Pourquoi on a choisi telle techno plutôt qu'une autre, avec le rationale
Cette section trace chaque décision technique structurante avec son contexte, les alternatives envisagées, et le pourquoi du choix. Format ADR (Architecture Decision Records).
Pourquoi des ADR ?
Pour ne pas se retrouver dans 6 mois à se demander "pourquoi on a fait ça déjà ?". Chaque décision a un coût caché : revenir dessus, expliquer aux nouveaux arrivants, changer d'avis à mi-projet. Les ADR forcent à expliciter le contexte et permettent à Future-You (ou à un collaborateur) de comprendre le choix.
Format
Chaque ADR contient :
- Statut : Proposé / Accepté / Déprécié / Remplacé
- Date : quand la décision a été prise
- Contexte : qu'est-ce qu'on essaie de résoudre
- Alternatives : ce qu'on a considéré et écarté
- Décision : ce qu'on a choisi
- Conséquences : ce que ça implique (positif et négatif)
ADRs en cours
| # | Sujet | Statut |
|---|---|---|
| 01 | Base de données : Postgres + pgvector | Accepté |
| 02 | Stack IA : Claude + OpenAI embeddings + Whisper | Accepté |
| 03 | Pipeline de recherche en 3 couches | Accepté |
| 04 | API layer : Eden Treaty + Elysia (vs tRPC) | Accepté |
| 05 | Email : Resend (vs self-host SMTP) | Accepté |
| 06 | Hébergement : Postgres self-host via Dokploy (vs Neon) | Accepté |