Hébergement (Hobby plan) — CDN mondial, HTTPS automatique, preview deployments
Vercel Analytics
Métriques Core Web Vitals (production uniquement)
Vercel Speed Insights
Analyse des performances en production
Décisions d'architecture
→One-page landing avec sections distinctes pour les compétences, l'expérience, les services, les projets et le contact — navigation par ancres.
→Track toggle côté client (cookie `track`) : un seul composant hero, compétences et services adaptés selon le profil Salesforce ou IT Ops.
→Pages dédiées pour About, Certifications et Blog — accessibles via la navbar, non dupliquées dans la landing.
→Server Components par défaut : seuls les composants interactifs (hero, toggle de thème, formulaire) sont marqués `use client`.
→Données Supabase récupérées côté serveur avec cache Redis (stale-while-revalidate) — pas de requêtes client directes.
→Blog MDX : articles écrits en `.mdx` dans `content/blog/posts/{locale}/` — rendu statique au build, pas de base de données requise.
Stratégie de cache
→Upstash Redis stocke les réponses des requêtes Supabase (projets, certifications, about) avec un TTL de 5 minutes.
→stale-while-revalidate : si la donnée est en cache, elle est retournée immédiatement pendant qu'une revalidation asynchrone se déclenche en arrière-plan.
→Invalidation manuelle : l'endpoint `POST /api/cache/invalidate` (protégé par secret) permet de purger le cache après une mise à jour des données.
→RSS feed : `Cache-Control: public, max-age=3600, stale-while-revalidate=86400` — 1h en cache CDN, revalidé toutes les 24h.
Sécurité
→CSP nonce-based : `'unsafe-inline'` retiré de `script-src`. Un nonce cryptographique unique est généré par requête dans le middleware Edge (`proxy.ts`) et injecté dans tous les scripts inline autorisés (JSON-LD, Vercel Analytics, hydratation Next.js). Tout script inline sans nonce est bloqué par le navigateur.
→Row Level Security (RLS) activé sur toutes les tables Supabase. `project_assets` restreinte aux assets des projets publiés uniquement — les brouillons ne sont pas exposés via la clé anon.
→Rate-limiting via Upstash Redis (fenêtre glissante) sur les endpoints sensibles : contact (5 req/10 min), témoignages (3 req/24h), invalidation cache (10 req/min), health check (30 req/min), rapports CSP (20 req/min), panneau admin (10 req/5 min — protection anti brute-force). En cas d'indisponibilité Redis, le limiteur bascule en mode fail-closed en production.
→Honeypot : champs cachés dans les formulaires de contact et de témoignages — les bots remplissant ces champs reçoivent un 200 silencieux.
→Validation d'origine : les requêtes API provenant d'origines inconnues sont rejetées en production.
→Routes de diagnostic désactivées en production : `/api/redis-test` retourne 404 hors mode développement.
→CORS restreint : `/api/health` scoped à l'origine du site uniquement — les outils de monitoring opèrent en serveur-à-serveur.
→security.txt disponible à `/.well-known/security.txt` (RFC 9116) — contact de divulgation responsable.
→Aucun secret dans les variables `NEXT_PUBLIC_*` — toutes les clés sensibles (service role, token Redis, credentials admin) restent strictement côté serveur.