ADR 0003 : Proxy de connexion - ne jamais exposer les e-mails au navigateur

• Statut : Accepté
• Décideurs : Marco (Commanditaire), Julien (Commanditaire), Seer (Développeur)
• Date : 8 juillet 2026

Contexte et Problème

Avec Supabase Auth natif (ADR 0002), l'identifiant technique d'un compte est son e-mail. Or l'écran de connexion présente une liste de prénoms (l'utilisateur clique sur son nom puis saisit son PIN). Deux exigences s'opposent :

1. signInWithPassword a besoin de l'e-mail pour authentifier.
2. Les e-mails ne doivent pas apparaître dans le navigateur - ils incluent des adresses personnelles (Marco, Julien) et constituent une donnée à ne pas diffuser côté client.

Exposer les e-mails dans la page de login (pour permettre au client d'appeler signInWithPassword) reviendrait à publier ces adresses dans le code livré au navigateur.

Facteurs de Décision

• Confidentialité : aucun e-mail ne doit transiter jusqu'au navigateur.
• Fonctionnalité : l'écran de login doit afficher prénoms + rôle + projets.
• Non-duplication : la même logique doit servir en dev (server.js) et en prod (fonctions Netlify).

Options Envisagées

Option A : Roster complet côté client (avec e-mails)

Envoyer la liste des membres avec e-mails au navigateur, qui appelle directement signInWithPassword.

• Avantage : simplicité, pas d'endpoint serveur de login.
• Inconvénient : fuite des e-mails (dont personnels) dans le bundle/réseau ; inacceptable.

Option B : Proxy de connexion côté serveur (Recommandée)

Deux endpoints serveur, logique partagée dans lib/authBackend.js :

• GET /api/roster : renvoie prénoms + rôle + projets, jamais d'e-mail.
• POST /api/login : reçoit { memberId, pin }, résout l'e-mail côté serveur (clé service_role), fait signInWithPassword, renvoie les jetons de session.
• Avantage : les e-mails ne quittent jamais le serveur ; logique unique (dev + Netlify) ; point de contrôle idéal pour le rate limiting (ADR 0006).
• Inconvénient : nécessite un petit backend (déjà présent pour l'import IA).

Décision Retenue

L'Option B : proxy de connexion a été retenue.

Justification

C'est la seule option qui satisfait la confidentialité des e-mails tout en gardant Supabase Auth natif. La logique étant centralisée dans lib/authBackend.js, elle est réutilisée à l'identique par server.js (dev/Hostinger) et netlify/functions/{roster,login}.js (prod), sans duplication.

Conséquences

Positives

• Zéro e-mail exposé au navigateur (vérifié : le roster n'en contient aucun).
• Point d'entrée unique pour durcir la connexion (verrouillage, journalisation).
• Logique backend partagée dev/prod.

Négatives

• La connexion dépend de la disponibilité du backend (/api/*).
• La clé service_role doit rester strictement côté serveur (variable d'env, jamais préfixée VITE_).