Portfolio — exigences non fonctionnelles et risques

Exigences

Domaine	Cible
Performance	Site léger : LCP < 2 s en 4G, poids page d'accueil < 1 Mo images comprises
Disponibilité	Vitrine : une indispo d'une heure est tolérable, pas d'astreinte ; à surveiller comme le reste de l'infra (Uptime Kuma envisagé, cf. risque R2)
Sécurité	HTTPS (wildcard existant), en-têtes durcis (HSTS, nosniff — comme la forge), aucun backend exposé au MVP ; CrowdSec couvre déjà l'entrée
Accessibilité	Bon sens WCAG AA : contrastes suffisants, navigation clavier, textes alternatifs, HTML sémantique
Terminaux	Mobile d'abord (les recruteurs lisent sur téléphone), navigateurs récents (2 dernières versions majeures)
SEO	Indexable, titres/descriptions par page (complété en US-07)
RGPD	Aucune collecte, aucun cookie au MVP → pas de bandeau ; si US-10 (analytics) arrive : outil sans cookie ou consentement
Langues	FR au MVP ; structure prête pour EN (US-06) sans refonte

#	Risque	Parade / signal
R1	Le contenu n'arrive pas (sections vides, site jamais lancé)	Structure avec contenu d'exemple dès le début ; publier par lots (une section réelle vaut mieux que cinq vides) ; le site peut partir en ligne avec accueil + projets seulement
R2	Dépendance au homelab : un site-CV indisponible pendant une candidature fait mauvais effet (DNS dynamique, box, coupure)	Monitoring de disponibilité (Uptime Kuma à installer — décision en phase 5) ; code sur le miroir GitHub → redéployable ailleurs en urgence ; en dernier recours le site est statique donc hébergeable n'importe où en minutes
R3	Sur-ingénierie : transformer une vitrine en usine à gaz	MVP volontairement petit (5 stories), gates du process, stack choisie pour la simplicité (phase 2)
R4	Image renvoyée : un portfolio au design daté dessert plus qu'il ne sert	Partir d'un design sobre et éprouvé ; revue visuelle (mobile + desktop) avant chaque mise en ligne ; le perfectionnisme est cadré par R3