ADR-0001 - Stack React + Vite + Supabase + Netlify
- Statut : ✅ Accepté (état de fait)
- Date : 2026-07-10 (constat)
- Décideurs : équipe projet (implicite)
- Tags : architecture, plateforme
Contexte
L'application doit gérer les RH d'un réseau multi-boutiques avec un budget et une équipe réduits. Besoin : authentification, base relationnelle, stockage de fichiers (justificatifs, contrats), hébergement web simple, mise à jour rapide.
Décision
Utiliser une architecture « serverless / BaaS » :
- React 18 + Vite 5 + Tailwind 3 pour un SPA côté client.
- Supabase comme backend unique (PostgreSQL + Auth + Storage), interrogé
directement depuis le navigateur via la clé publique
anon. - Netlify pour l'hébergement statique (fallback SPA via
netlify.toml).
Aucun serveur applicatif intermédiaire (pas de Node/Java/API maison).
Conséquences
Positives
- Time-to-market très court, coût quasi nul (offres gratuites Supabase/Netlify).
- Pas d'infrastructure serveur à maintenir.
- Auth et stockage « clé en main ».
Négatives / compromis
- Toute la sécurité repose sur la RLS PostgreSQL : si elle est mal configurée, la clé publique donne accès à la base (cf. ADR-0003).
- Pas d'endroit « de confiance » pour exécuter de la logique sensible (calcul de paie, envoi d'emails, intégrations) → aujourd'hui tout est côté client.
- Couplage fort au fournisseur Supabase.
Risques & dette induite
- Sans Edge Functions/serveur, les besoins futurs (notifications email, export signé, webhooks comptables) nécessiteront d'ajouter une brique serverless.
Alternatives envisagées
| Option | Avantages | Inconvénients | Retenue ? |
|---|---|---|---|
| Backend Node/Java + Postgres | Logique sensible côté serveur | Coût, ops, délai | ❌ |
| Firebase | BaaS mûr | NoSQL moins adapté au relationnel RH | ❌ |
| Supabase (BaaS Postgres) | Relationnel + auth + storage | Sécurité = RLS | ✅ |
Références
gestionrh-github/package.json,vite.config.js,netlify.tomlsrc/supabaseClient.js- Évolution possible : Edge Functions Supabase pour la logique de confiance.