📐 Architecture — Vue d'ensemble
Schéma général
┌─────────────────────────────────────────────────────────────┐
│ NAVIGATEUR │
│ │
│ React 18 + TypeScript + Vite 5 │
│ ┌──────────┐ ┌───────────┐ ┌──────────┐ ┌───────────┐ │
│ │ Pages │ │Components │ │ Hooks │ │localStorage│ │
│ │ 10 pages │ │ 7 métier │ │ 6 hooks │ │crédits │ │
│ └────┬─────┘ └─────┬─────┘ └────┬─────┘ │config API │ │
│ └──────────────┴─────────────┘ └───────────┘ │
│ │ │
│ TanStack Query (cache + mutations) │
└───────────────────────┼───────────────────────────────────--─┘
│ HTTPS
┌───────────────┼──────────────────────────────────┐
│ │ SUPABASE │
│ ┌────────────▼─────────────────────────────┐ │
│ │ Edge Functions (Deno) │ │
│ │ analyze-email-headers (SSE streaming) │ │
│ │ analyze-spam (JSON sync) │ │
│ │ arcep-check (JSON sync) │ │
│ │ trigger-n8n-export (JSON sync) │ │
│ │ trigger-make-scenario (JSON sync) │ │
│ └──────────────────┬───────────────────────┘ │
│ │ │
│ ┌──────────────────▼───────────────────────┐ │
│ │ PostgreSQL (RLS activé) │ │
│ │ email_analyses · phone_checks │ │
│ │ community_reports │ │
│ └──────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────┐ │
│ │ Auth (email/password + Google OAuth) │ │
│ └──────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────┐ │
│ │ Realtime (WebSocket PostgreSQL changes) │ │
│ └──────────────────────────────────────────┘ │
└────────────────────────────────────────────────--─┘
│
┌───────────────┼──────────────────────────────────┐
│ APIs EXTERNES│ │
│ IPQualityScore · AbuseIPDB · VirusTotal │
│ n8n webhook · Make.com webhook │
│ ARCEP/Codeberg (base numéros) │
└───────────────────────────────────────────────────┘
Couches applicatives
1. Frontend (React 18 + Vite 5)
Le frontend est une SPA (Single Page Application) entièrement côté client. Il communique avec Supabase via :
supabase.functions.invoke()pour les Edge Functions (JSON)fetchbrut pour le streaming SSE (analyze-email-headers)- Le client Supabase JS pour les opérations DB (RLS, realtime)
Port de développement : 8080 (IPv6 compatible)
Alias : @/ → ./src/ dans tous les imports
2. Backend (Supabase)
Supabase fournit l'intégralité du backend :
- Edge Functions (Deno) — 5 fonctions serverless, une par cas d'usage
- PostgreSQL — Base de données avec RLS (isolation par utilisateur)
- Auth — Gestion complète des sessions, JWT, OAuth
- Realtime — Abonnements WebSocket aux changements PostgreSQL
3. Données persistantes
Deux modes de stockage coexistent :
| Mode | Stockage | Utilisé quand |
|---|---|---|
| Authentifié | Supabase PostgreSQL | Utilisateur connecté |
| Non-authentifié | localStorage | Fallback ou invité |
4. APIs externes (optionnelles)
Toutes les APIs externes sont optionnelles et activées par l'utilisateur via ses propres clés :
| API | Usage | Endpoint appelé depuis |
|---|---|---|
| IPQualityScore | Score fraude IP | Edge Function analyze-email-headers |
| AbuseIPDB | Réputation IP communautaire | Edge Function analyze-email-headers |
| VirusTotal | Détection malveillante | Edge Function analyze-email-headers |
| ARCEP/Codeberg | Base numéros démarcheurs | Edge Function arcep-check |
Flux de données principaux
Analyse email (flux complet)
Utilisateur colle headers
↓
Vérification crédit (localStorage)
↓
[Parallèle]
├── analyze-spam (JSON sync) → patternScore
└── analyze-email-headers (SSE) → 8 étapes → headerScore
↓
Calcul score final : patternScore×0.6 + headerScore×0.4
↓
Stockage résultat (Supabase si auth, localStorage sinon)
↓
[Optionnel] Déclenchement webhook n8n/Make
Vérification numéro (flux complet)
Utilisateur saisit numéro
↓
Normalisation format (06/+33/0033 → 33XXXXXXXXX)
↓
arcep-check → Cache in-memory 1h → Base Codeberg
↓
Matching patterns ARCEP (wildcards #)
↓
Résultat + badges + actions
↓
Stockage (Supabase si auth, localStorage sinon)
Choix architecturaux clés
Pourquoi SSE pour l'analyse email ?
L'analyse email implique jusqu'à 3 appels API externes en parallèle (IPQS, AbuseIPDB, VirusTotal) qui peuvent prendre 1-3 secondes. Le SSE (Server-Sent Events) permet d'afficher chaque étape progressivement plutôt que d'attendre le résultat complet, ce qui améliore drastiquement la perception de performance.
Pourquoi Supabase Edge Functions ?
- Scalabilité automatique sans gestion d'infrastructure
- Proximité géographique avec les utilisateurs (CDN global)
- Intégration native avec PostgreSQL et Auth Supabase
- Runtime Deno (TypeScript natif, sécurisé par défaut)
Pourquoi le dual mode auth/non-auth ?
Permettre l'utilisation sans compte (localStorage) réduit la friction à l'adoption. Les utilisateurs découvrent la valeur du produit avant de créer un compte, améliorant les taux de conversion.
Pourquoi verify_jwt = false sur les Edge Functions ?
Configuration actuelle pour le MVP (facilite les tests et l'adoption). Dette technique connue : à migrer vers verify_jwt = true en Q2 2026 avec le déploiement de l'API v1.
Technologies détaillées
Voir les pages dédiées :
- Frontend — React, Vite, design system, composants
- Backend — Edge Functions, Supabase, auth
- Base de données — Schéma PostgreSQL, RLS, Realtime
- Sécurité — RGPD, RLS, conformité
Dernière mise à jour : Avril 2026