Colophon

Stack technique

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.
• →ISR (pages HTML) : non activé sur Vercel CDN par choix de sécurité — le nonce CSP généré par requête (suppression de `'unsafe-inline'`) est incompatible avec un HTML mis en cache. Cache prévu via reverse-proxy homelab (Q4 2026), qui pourra mettre en cache le HTML à sa couche sans compromettre le nonce.

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.
• →En-têtes HTTP dans `next.config.mjs` : HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy étendu, Cross-Origin-Opener-Policy (`same-origin`), Cross-Origin-Resource-Policy (`same-origin`), Report-To, Reporting-Endpoints. Fingerprinting du framework désactivé (`poweredByHeader: false`).
• →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 (5 req/15 min — protection anti brute-force). Si Redis n'est pas configuré en production, le limiteur bascule en *fail-closed* (toutes les requêtes bloquées). En cas de panne transitoire de Redis, il bascule en *fail-open* pour ne pas pénaliser les utilisateurs légitimes — sauf sur `/admin` où le comportement reste *fail-closed*.
• →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.
• →Validation externe (tiers neutres) : securityheaders.com · Mozilla Observatory — posture HTTP vérifiée indépendamment du site.

Open source