Portfolio-Codex/docs/prd.md

Portfolio Développeur Web - Product Requirements Document (PRD)

1. Objectifs et Contexte

1.1 Objectifs (Goals)

• Convaincre recruteurs et clients potentiels de mes compétences à travers des preuves tangibles et vérifiables
• Inspirer confiance par l'authenticité totale et la démonstration plutôt que l'affirmation
• Faciliter la prise de contact avec une expérience utilisateur sans friction
• Créer une connexion humaine en montrant la personne derrière le développeur
• Démontrer la maîtrise technique via des projets visitables et des explications techniques

1.2 Contexte (Background)

Ce projet consiste à reprendre de zéro un portfolio développeur web existant. L'objectif est de créer une vitrine professionnelle qui applique le principe fondamental "Montrer plutôt que dire" - chaque affirmation devant être soutenue par une preuve tangible et vérifiable.

Le portfolio cible deux audiences principales : les recruteurs cherchant un candidat fiable et compétent, et les clients potentiels souhaitant évaluer la capacité à livrer leurs projets. La stratégie repose sur l'authenticité vérifiable (projets en ligne, témoignages tiers, explications techniques prouvant la paternité du travail) et une expérience utilisateur fluide du premier clic jusqu'au formulaire de contact.

1.3 Journal des modifications (Change Log)

Date	Version	Description	Auteur
2026-01-22	0.1	Création initiale basée sur le brainstorming	John (PM)
2026-01-22	1.0	Version complète avec 5 epics, 24 stories, validation PM	John (PM)

2. Exigences (Requirements)

2.1 Exigences Fonctionnelles (FR)

• FR1: Le portfolio doit afficher une page d'accueil avec une accroche claire et une navigation vers toutes les sections
• FR2: Le portfolio doit présenter 5-10 projets vedettes avec des pages dédiées contenant : contexte, solution technique, réalisation, et lien vers le projet
• FR3: Le portfolio doit afficher une liste de projets secondaires en format simplifié
• FR4: Le portfolio doit présenter les compétences techniques liées aux projets correspondants (preuves vivantes)
• FR5: Le portfolio doit permettre de démontrer les outils vérifiables via des liens externes (dépôts Git, pages Notion, etc.)
• FR6: Le portfolio doit contenir une page "Me Découvrir" avec parcours, motivations et passions hors travail
• FR7: Le portfolio doit afficher une section témoignages clients/employeurs
• FR8: Le portfolio doit proposer un formulaire de contact avec les champs : Nom, Prénom, Email, Entreprise (optionnel), Catégorie (dropdown), Objet, Message
• FR9: Le formulaire de contact doit persister les données si le visiteur quitte et revient
• FR10: Le portfolio doit intégrer un bouton "Me contacter" visible en permanence dans la navbar
• FR11: Le formulaire doit proposer 3 catégories de contact : Projet freelance, Proposition de poste, Autre
• FR12: Le portfolio doit intégrer un captcha invisible (reCAPTCHA v3) pour la protection anti-spam

2.2 Exigences Non-Fonctionnelles (NFR)

• NFR1: Le site doit être développé en HTML/CSS/JS pur avec Tailwind CSS (pas de framework JS)
• NFR2: Le site doit être responsive et s'adapter à tous les écrans (mobile, tablette, desktop)
• NFR3: Le site doit être optimisé pour les performances (temps de chargement < 3s)
• NFR4: Le site doit respecter les bonnes pratiques SEO de base (meta tags, structure sémantique)
• NFR5: Le code doit être simple, maintenable et bien organisé
• NFR6: Le design doit privilégier les animations subtiles sans distraire du contenu
• NFR7: L'expérience utilisateur doit être fluide avec zéro friction du premier clic au contact
• NFR8: Le ton rédactionnel doit être sympathique et authentique, ni trop formel ni trop familier
• NFR9: Le score Lighthouse Performance doit être supérieur à 90
• NFR10: Le First Contentful Paint (FCP) doit être inférieur à 1.5 secondes
• NFR11: Le Cumulative Layout Shift (CLS) doit être inférieur à 0.1
• NFR12: Le Time to Interactive (TTI) doit être inférieur à 3 secondes

2.3 Hors Scope MVP

Les éléments suivants sont explicitement exclus du MVP :

Feature	Raison
Blog / Articles	Complexité ajoutée, pas essentiel pour la conversion
Multi-langue (i18n)	Portfolio FR uniquement pour le MVP
Mode sombre (dark mode)	Nice-to-have, peut être ajouté plus tard
Analytics avancés	Google Analytics basique suffit, pas de dashboard custom
CMS avec interface admin	Le fichier JSON est suffisant pour 5-10 projets
Système de commentaires	Pas pertinent pour un portfolio
Newsletter / Inscription	Le formulaire de contact suffit

3. Objectifs de Design UI/UX

3.1 Vision UX Globale

Un portfolio qui incarne le principe "Le design au service du message". L'interface doit être soignée et professionnelle tout en restant au second plan par rapport au contenu. Le visiteur doit pouvoir naviguer intuitivement et trouver rapidement les informations recherchées, que ce soit un projet spécifique, des compétences ou le formulaire de contact.

3.2 Paradigmes d'Interaction Clés

• Navigation claire : Menu principal toujours accessible avec CTA "Me contacter" visible
• Scroll fluide : Pages aérées favorisant la lecture verticale
• Animations subtiles : Micro-interactions qui guident l'œil sans distraire
• Liens contextuels : Compétences liées aux projets, outils vers preuves externes
• Progressive disclosure : Projets vedettes en détail, projets secondaires en liste

3.3 Écrans et Vues Principales

Écran	Description
Page d'accueil	Accroche + navigation vers sections principales
Liste des projets	Grille/liste des projets vedettes avec aperçu visuel
Page projet (x5-10)	Contexte → Solution → Réalisation → Lien/Démo
Page Compétences	Technos liées aux projets + outils démontrables
Page Me Découvrir	Parcours, motivations, passions (ton personnel)
Section Témoignages	Avis clients/employeurs avec attribution
Page Contact	Formulaire principal + liens réseaux secondaires

3.4 Accessibilité

Niveau : Bonnes pratiques de base (pas de certification WCAG formelle)

• Contrastes suffisants pour la lisibilité
• Navigation au clavier fonctionnelle
• Textes alternatifs pour les images
• Structure sémantique HTML5

3.5 Branding

• Pas de charte graphique imposée - liberté créative
• Style moderne, clean, technique mais accessible
• Palette de couleurs : tons neutres + couleur d'accent
• Typographie lisible et professionnelle

3.6 Plateformes Cibles

Web Responsive avec approche mobile-first :

• Mobile (prioritaire)
• Tablette
• Desktop (écrans larges)

4. Hypothèses Techniques

4.1 Structure du Repository

Monorepo - Un seul dépôt Git contenant l'ensemble du projet.

4.2 Architecture de Service

Site PHP léger (Multi-Page) - Architecture simple sans framework.

Composant	Technologie	Justification
Backend	PHP natif	Formulaire de contact + génération pages projets
Frontend	HTML5 + Tailwind CSS + JS vanilla	Simplicité, performance
Gestion projets	Fichier JSON + templates PHP	Maintenabilité sans CMS lourd
Formulaire	PHP personnalisé	Contrôle total, pas de dépendance externe
Captcha	Google reCAPTCHA v3	Protection anti-spam invisible
Persistance formulaire	localStorage	Côté navigateur, simple

4.3 Stack Technique Complet

Catégorie	Choix	Rationale
Markup	HTML5 sémantique + PHP	SEO + accessibilité + dynamisme
Styling	Tailwind CSS (CLI build)	Utility-first, purge CSS pour performance
Scripting	JavaScript ES6+ vanilla	Pas de framework, simplicité
Icons	SVG inline ou sprite	Performance, scalabilité
Hébergement	Serveur personnel (PHP)	Infrastructure existante
Build	Tailwind CLI + PostCSS	CSS optimisé et minifié
Versioning	Git	Standard industrie

4.4 Structure des Fichiers (Proposée)

/portfolio
├── index.php                    # Page d'accueil
├── projects.php                 # Liste des projets
├── project.php                  # Template page projet unique
├── skills.php                   # Page compétences
├── about.php                    # Page "Me Découvrir"
├── contact.php                  # Page contact + traitement formulaire
├── data/
│   └── projects.json            # Données des projets (mini-CMS)
├── templates/
│   ├── header.php               # En-tête commun
│   ├── footer.php               # Pied de page commun
│   ├── navbar.php               # Navigation
│   └── project-card.php         # Carte projet réutilisable
├── assets/
│   ├── css/
│   │   ├── input.css            # Source Tailwind
│   │   └── output.css           # CSS compilé
│   ├── js/
│   │   └── main.js              # Scripts (localStorage, animations)
│   └── img/
│       └── projects/            # Images des projets
└── tailwind.config.js           # Configuration Tailwind

4.5 Exigences de Tests

Type	Outil/Méthode
Validation HTML	W3C Validator
Tests responsive	DevTools navigateur + appareils réels
Tests performance	Lighthouse, PageSpeed Insights
Tests formulaire	Tests manuels envoi/réception
Tests sécurité	Vérification XSS, CSRF, injection

4.6 Hypothèses Additionnelles

• Pas de base de données : Les données projets sont dans un fichier JSON
• Images optimisées : Format WebP avec fallback, lazy loading
• Fonts : Google Fonts ou auto-hébergées
• Email : Envoi via fonction mail() PHP ou SMTP configuré sur le serveur
• SSL/HTTPS : Certificat Let's Encrypt sur le serveur personnel

4.7 Stratégie de Déploiement

Aspect	Détail
Méthode	Déploiement manuel via FTP/SFTP ou Git pull sur le serveur
Environnements	Local (développement) → Production (serveur personnel)
Build avant déploiement	npm run build pour générer le CSS Tailwind optimisé
Fichiers à déployer	Tous sauf node_modules/, package.json, package-lock.json, tailwind.config.js
Rollback	Conserver une copie de la version précédente sur le serveur
Vérification post-déploiement	Test manuel des pages principales + formulaire de contact

5. Liste des Epics

Epic	Titre	Objectif
Epic 1	Fondations & Infrastructure	Établir la structure du projet, le build Tailwind, et les templates PHP de base
Epic 2	Navigation & Page d'Accueil	Créer la navbar avec CTA, le header/footer, et la page d'accueil avec accroche
Epic 3	Système de Projets	Implémenter le mini-CMS JSON, la liste des projets et les pages projet individuelles
Epic 4	Pages de Contenu	Développer les pages Compétences, Me Découvrir, et Témoignages
Epic 5	Formulaire de Contact	Créer le formulaire complet avec validation, localStorage, reCAPTCHA et envoi PHP

6. Détail des Epics

Epic 1 : Fondations & Infrastructure

Objectif : Établir la base technique du projet en configurant l'environnement de développement, le build Tailwind CSS, et la structure de fichiers PHP. À la fin de cet epic, une page "canary" simple sera accessible sur le serveur, validant que l'infrastructure fonctionne correctement.

Story 1.1 : Initialisation du projet et structure de fichiers

En tant que développeur, Je veux initialiser la structure du projet avec les dossiers et fichiers de base, Afin de disposer d'une organisation claire et maintenable dès le départ.

Critères d'acceptation :

1. La structure de dossiers est créée : templates/, assets/css/, assets/js/, assets/img/projects/, data/
2. Un fichier index.php existe à la racine avec un contenu minimal ("Hello World")
3. Un fichier .gitignore est configuré (node_modules, .env, etc.)
4. Le projet est initialisé avec Git et un premier commit est effectué

Story 1.2 : Configuration de Tailwind CSS avec CLI

En tant que développeur, Je veux configurer Tailwind CSS avec le CLI et le build optimisé, Afin de bénéficier d'un CSS performant avec purge automatique.

Critères d'acceptation :

1. Node.js et npm sont utilisés uniquement pour le build (pas en production)
2. tailwind.config.js est créé avec les chemins des fichiers PHP à scanner
3. Le fichier assets/css/input.css contient les directives Tailwind (@tailwind base, etc.)
4. La commande npm run build génère assets/css/output.css minifié
5. Une commande npm run watch permet le développement en temps réel
6. Le fichier CSS généré fait moins de 50kb après purge

Story 1.3 : Templates PHP de base (header/footer)

En tant que développeur, Je veux créer les templates PHP réutilisables pour le header et le footer, Afin de ne pas dupliquer le code HTML commun sur chaque page.

Critères d'acceptation :

1. templates/header.php contient le doctype, head, meta tags SEO de base, et lien vers le CSS
2. templates/footer.php contient la fermeture body, les scripts JS, et le copyright
3. Le header inclut les balises meta viewport pour le responsive
4. Le header permet de passer un titre de page dynamique via une variable PHP
5. Les templates sont inclus dans index.php et la page s'affiche correctement

Story 1.4 : Page canary et validation du déploiement

En tant que développeur, Je veux déployer une page "canary" minimale sur le serveur, Afin de valider que l'infrastructure PHP et le CSS fonctionnent en production.

Critères d'acceptation :

1. La page index.php affiche un message de test stylé avec Tailwind (ex: titre centré, couleur d'accent)
2. La page est responsive (vérifiable sur mobile)
3. Le déploiement sur le serveur personnel fonctionne
4. Le site est accessible via HTTPS
5. Le temps de chargement est inférieur à 2 secondes (Lighthouse)

Epic 2 : Navigation & Page d'Accueil

Objectif : Créer le système de navigation global du portfolio avec le bouton CTA "Me contacter" toujours visible, ainsi que la page d'accueil avec une accroche percutante. À la fin de cet epic, les visiteurs pourront naviguer entre les sections et comprendre immédiatement l'identité du développeur.

Story 2.1 : Navbar responsive avec menu mobile

En tant que visiteur, Je veux disposer d'une navigation claire et accessible sur tous les appareils, Afin de trouver facilement les sections du portfolio.

Critères d'acceptation :

1. templates/navbar.php contient le menu de navigation avec les liens : Accueil, Projets, Compétences, Me Découvrir, Contact
2. La navbar est fixe en haut de page (sticky) et reste visible au scroll
3. Sur mobile, un menu "hamburger" affiche/masque les liens en JavaScript vanilla
4. Le lien de la page active est visuellement distingué (couleur/soulignement)
5. La navbar est responsive et s'adapte aux 3 breakpoints (mobile, tablette, desktop)

Story 2.2 : Bouton CTA "Me contacter" dans la navbar

En tant que visiteur, Je veux voir un bouton "Me contacter" visible en permanence, Afin de pouvoir initier un contact à tout moment sans chercher.

Critères d'acceptation :

1. Le bouton "Me contacter" est stylé différemment des autres liens (bouton rempli, couleur d'accent)
2. Le bouton est visible sur desktop ET sur mobile (même dans le menu hamburger)
3. Le bouton redirige vers la page contact.php
4. Le bouton a un état hover/focus visible
5. Le bouton respecte l'accessibilité (focusable, contraste suffisant)

Story 2.3 : Page d'accueil avec accroche

En tant que visiteur, Je veux voir une page d'accueil avec une accroche claire et engageante, Afin de comprendre immédiatement qui est le développeur et ce qu'il propose.

Critères d'acceptation :

1. La page d'accueil affiche une section "hero" avec : nom/prénom, titre (développeur web), et une phrase d'accroche
2. Un bouton secondaire CTA invite à découvrir les projets
3. Le design est aéré et la typographie met en valeur l'accroche
4. La page inclut la navbar et le footer
5. Le contenu est centré et responsive
6. Les animations sont subtiles (fade-in au chargement, optionnel)

Story 2.4 : Sections de navigation rapide sur l'accueil

En tant que visiteur, Je veux voir un aperçu des sections principales sur la page d'accueil, Afin de naviguer rapidement vers ce qui m'intéresse.

Critères d'acceptation :

1. Sous le hero, des cartes/blocs présentent les sections : Projets, Compétences, Me Découvrir
2. Chaque bloc a un titre, une courte description, et un lien vers la page correspondante
3. Les blocs sont disposés en grille responsive (1 colonne mobile, 3 colonnes desktop)
4. Les blocs ont un effet hover subtil
5. L'ensemble reste cohérent avec le design global

Epic 3 : Système de Projets

Objectif : Implémenter le cœur du portfolio - le système de gestion des projets basé sur JSON avec un router PHP pour des URLs propres. Cela inclut la structure de données, la page listant tous les projets vedettes, les pages individuelles pour chaque projet, et la gestion des projets secondaires. À la fin de cet epic, le principe "Montrer plutôt que dire" sera pleinement opérationnel.

Story 3.1 : Structure de données JSON pour les projets

En tant que développeur, Je veux définir et créer le fichier JSON contenant les données des projets, Afin de centraliser les informations et faciliter la maintenance.

Critères d'acceptation :

1. Le fichier data/projects.json est créé avec la structure définie
2. La structure supporte : id, title, slug, category (vedette/secondaire), thumbnail, url, technologies[], context, solution, teamwork, duration, testimonial, screenshots[]
3. Au moins 2 projets de test sont ajoutés pour valider la structure
4. Une fonction PHP getProjects() lit et décode le JSON
5. La fonction gère les erreurs (fichier manquant, JSON invalide)

Story 3.2 : Router PHP et URLs propres

En tant que visiteur, Je veux des URLs lisibles et propres pour accéder aux projets, Afin de comprendre le contenu de la page avant même de cliquer et améliorer le SEO.

Critères d'acceptation :

1. Un fichier .htaccess redirige toutes les requêtes vers index.php (front controller)
2. Un router PHP simple parse l'URL et route vers le bon fichier/action
3. Les URLs des projets sont au format /projet/{slug} (ex: /projet/site-ecommerce-xyz)
4. Les autres pages gardent des URLs simples : /projets, /competences, /a-propos, /contact
5. Une route 404 personnalisée gère les URLs inconnues
6. Le router est léger (<50 lignes de code) et sans dépendance externe

Structure d'URLs :

URL	Action
/	Page d'accueil
/projets	Liste des projets
/projet/{slug}	Page projet individuelle
/competences	Page compétences
/a-propos	Page Me Découvrir
/contact	Page contact

Story 3.3 : Page liste des projets vedettes

En tant que visiteur, Je veux voir une liste visuelle de tous les projets vedettes, Afin de parcourir rapidement le portfolio et choisir ce qui m'intéresse.

Critères d'acceptation :

1. /projets affiche tous les projets où category = "vedette"
2. Chaque projet est affiché sous forme de carte avec : thumbnail, titre, technologies (badges)
3. Les cartes sont cliquables et redirigent vers /projet/{slug}
4. La grille est responsive (1 col mobile, 2 cols tablette, 3 cols desktop)
5. Les cartes ont un effet hover (légère élévation/ombre)
6. Le template templates/project-card.php est réutilisable

Story 3.4 : Page projet individuelle

En tant que visiteur, Je veux consulter une page dédiée pour chaque projet vedette, Afin de comprendre le contexte, la solution technique et voir le résultat.

Critères d'acceptation :

1. L'URL /projet/{slug} affiche le projet correspondant au slug
2. Le slug est récupéré depuis le router (pas depuis $_GET)
3. La page affiche les sections : Contexte, Solution technique, Travail d'équipe (si applicable), Durée, Témoignage (si disponible)
4. Un bouton/lien permet de visiter le projet en ligne (ou affiche "Non disponible")
5. Les technologies sont affichées sous forme de badges
6. Des captures d'écran sont affichées si disponibles (galerie simple)
7. Un lien "Retour aux projets" permet de revenir à la liste
8. Si le slug n'existe pas, la page 404 est affichée

Story 3.5 : Liste des projets secondaires

En tant que visiteur, Je veux voir une liste simplifiée des projets secondaires, Afin de découvrir l'étendue du travail sans page dédiée pour chaque.

Critères d'acceptation :

1. Sur /projets, une section "Autres projets" liste les projets où category = "secondaire"
2. Chaque projet secondaire affiche : titre, courte description (1 ligne), technologies
3. Le format est compact (liste ou petites cartes)
4. Les projets secondaires peuvent avoir un lien externe direct (optionnel)
5. La section est visuellement distincte des projets vedettes (séparateur, titre de section)

Story 3.6 : Optimisation des images projets

En tant que visiteur, Je veux que les images des projets se chargent rapidement, Afin de ne pas attendre et avoir une expérience fluide.

Critères d'acceptation :

1. Les images sont stockées dans assets/img/projects/
2. Le lazy loading est activé sur toutes les images (attribut loading="lazy")
3. Les images ont des dimensions explicites (width/height) pour éviter le layout shift
4. Le format WebP est utilisé avec fallback JPG/PNG via <picture>
5. Les thumbnails sont redimensionnés (max 400px de large)
6. Le score Lighthouse "Images" est vert (>90)

Epic 4 : Pages de Contenu

Objectif : Développer les pages de contenu qui complètent le portfolio - Compétences, Me Découvrir, et Témoignages. Ces pages permettent au visiteur de mieux connaître le développeur, ses outils, et ce que d'autres pensent de son travail. À la fin de cet epic, toutes les pages statiques seront fonctionnelles.

Story 4.1 : Page Compétences - Technologies liées aux projets

En tant que visiteur, Je veux voir les compétences techniques du développeur liées aux projets réalisés, Afin de vérifier qu'il maîtrise les technologies dont j'ai besoin.

Critères d'acceptation :

1. /competences affiche une liste des technologies de développement (HTML, CSS, JS, PHP, etc.)
2. Chaque technologie est liée aux projets qui l'utilisent (liens cliquables)
3. Les technologies sont groupées par catégorie (Frontend, Backend, Outils, etc.)
4. Un indicateur visuel montre le nombre de projets utilisant chaque technologie
5. Le design utilise des badges/tags cohérents avec les pages projets

Story 4.2 : Page Compétences - Outils démontrables

En tant que visiteur, Je veux voir les outils maîtrisés avec des preuves concrètes, Afin de vérifier les compétences au-delà des simples affirmations.

Critères d'acceptation :

1. Une section "Outils démontrables" liste les outils avec liens de preuve (Git → GitHub, Notion → page publique, etc.)
2. Chaque outil a : nom, icône/logo, lien vers la preuve externe
3. Une section "Autres outils" liste les outils non démontrables avec contexte d'utilisation
4. Le design distingue clairement les deux types d'outils
5. Les liens externes s'ouvrent dans un nouvel onglet

Story 4.3 : Page Me Découvrir - Parcours et motivations

En tant que visiteur, Je veux en savoir plus sur le développeur en tant que personne, Afin de créer une connexion humaine et évaluer la compatibilité.

Critères d'acceptation :

1. /a-propos affiche les sections : Qui je suis, Mon parcours, Pourquoi ce métier
2. Le ton est sympathique et authentique (pas trop formel, pas trop familier)
3. Le texte est aéré avec des paragraphes courts
4. Une photo professionnelle ou illustration est présente (optionnel mais recommandé)
5. La localisation est mentionnée de façon générale (grande ville, pas adresse précise)

Story 4.4 : Page Me Découvrir - Passions et hobbies

En tant que visiteur, Je veux découvrir les passions du développeur en dehors du code, Afin de voir la personne au-delà du professionnel.

Critères d'acceptation :

1. Une section "En dehors du code" présente les hobbies et passions
2. Des preuves visuelles sont incluses si possible (photos d'événements, créations, etc.)
3. Le contenu reste professionnel (pas d'informations trop personnelles)
4. Les projets personnels sont mentionnés comme preuve de passion implicite
5. Le design intègre harmonieusement texte et visuels

Story 4.5 : Section Témoignages (JSON dynamique)

En tant que visiteur, Je veux lire des témoignages de clients ou employeurs, Afin de avoir une preuve sociale de la qualité du travail.

Critères d'acceptation :

1. Le fichier data/testimonials.json stocke tous les témoignages
2. La structure JSON supporte : id, quote, author_name, author_role, author_company, author_photo, project_slug (optionnel), date, featured (booléen)
3. Une fonction PHP getTestimonials() lit et décode le JSON
4. La section témoignages affiche dynamiquement les entrées du JSON
5. Chaque témoignage affiche : citation, nom, rôle/entreprise, photo (si disponible)
6. Si un témoignage est lié à un projet (project_slug), un lien vers le projet est affiché
7. Les témoignages featured: true peuvent être affichés sur la page d'accueil
8. Si le JSON est vide ou le fichier absent, la section affiche "Témoignages à venir" ou est masquée
9. Le design utilise des guillemets ou un style "citation" reconnaissable

Structure data/testimonials.json :

{
  "testimonials": [
    {
      "id": 1,
      "quote": "Excellent travail, livraison dans les délais...",
      "author_name": "Marie Dupont",
      "author_role": "Directrice Marketing",
      "author_company": "Entreprise XYZ",
      "author_photo": "marie-dupont.webp",
      "project_slug": "site-ecommerce-xyz",
      "date": "2025-06-15",
      "featured": true
    }
  ]
}

Epic 5 : Formulaire de Contact

Objectif : Créer le formulaire de contact complet avec toutes les fonctionnalités définies : validation côté client et serveur, persistance localStorage, protection reCAPTCHA v3, et envoi d'email via PHP. À la fin de cet epic, les visiteurs pourront envoyer des messages de manière fluide et sécurisée.

Story 5.1 : Structure du formulaire et validation HTML5

En tant que visiteur, Je veux un formulaire de contact clair avec des champs bien identifiés, Afin de savoir exactement quelles informations fournir.

Critères d'acceptation :

1. /contact affiche le formulaire avec les champs : Nom (requis), Prénom (requis), Email (requis), Entreprise (optionnel), Catégorie (dropdown requis), Objet (requis), Message (textarea requis)
2. Le champ email utilise type="email" pour validation native
3. Le dropdown Catégorie propose : "Je souhaite parler de mon projet", "Je souhaite vous proposer un poste", "Autre"
4. Les champs requis sont marqués visuellement (astérisque ou indication)
5. La validation HTML5 native est activée (required, type="email", maxlength)
6. Les labels sont explicites et associés aux champs (accessibilité)
7. Le formulaire est responsive et utilisable sur mobile

Story 5.2 : Validation JavaScript côté client

En tant que visiteur, Je veux être informé immédiatement si je fais une erreur de saisie, Afin de corriger avant d'envoyer et éviter les allers-retours.

Critères d'acceptation :

1. La validation JavaScript s'exécute à la soumission ET à la perte de focus (blur)
2. Les messages d'erreur sont affichés sous chaque champ concerné
3. Les champs en erreur sont visuellement distingués (bordure rouge, icône)
4. Le message d'erreur est clair et indique comment corriger
5. Le bouton d'envoi est désactivé tant que le formulaire contient des erreurs
6. La validation est en JavaScript vanilla (pas de bibliothèque)

Story 5.3 : Persistance des données avec localStorage

En tant que visiteur, Je veux que mes données soient sauvegardées si je quitte la page, Afin de ne pas tout ressaisir si je reviens plus tard.

Critères d'acceptation :

1. Chaque modification d'un champ sauvegarde automatiquement dans localStorage
2. Au chargement de la page, les champs sont pré-remplis avec les données sauvegardées
3. Le localStorage est vidé après un envoi réussi du formulaire
4. Un bouton "Effacer le formulaire" permet de réinitialiser manuellement
5. Les données sensibles (si ajoutées plus tard) ne sont PAS stockées
6. Le stockage utilise une clé unique (ex: portfolio_contact_form)

Story 5.4 : Intégration reCAPTCHA v3

En tant que propriétaire du site, Je veux une protection anti-spam invisible, Afin de ne pas recevoir de spam sans pénaliser l'expérience utilisateur.

Critères d'acceptation :

1. reCAPTCHA v3 est intégré (invisible, pas de case à cocher)
2. Le script reCAPTCHA est chargé depuis Google
3. Un token est généré à la soumission du formulaire
4. Le token est envoyé avec les données du formulaire au backend PHP
5. Les clés API (site key) sont configurables (fichier de config ou .env)
6. Si reCAPTCHA échoue à charger, le formulaire reste utilisable (dégradation gracieuse)

Story 5.5 : Traitement PHP et envoi d'email

En tant que propriétaire du site, Je veux recevoir les messages par email de manière sécurisée, Afin de pouvoir répondre aux visiteurs.

Critères d'acceptation :

1. Le backend PHP valide à nouveau tous les champs (ne jamais faire confiance au client)
2. Le token reCAPTCHA est vérifié via l'API Google (score > 0.5)
3. Les données sont nettoyées (htmlspecialchars, trim) contre XSS
4. Un token CSRF est vérifié pour éviter les attaques cross-site
5. L'email est envoyé via mail() PHP ou SMTP configuré
6. L'email contient : tous les champs du formulaire, catégorie, date/heure, IP (optionnel)
7. En cas de succès, une réponse JSON {"success": true} est renvoyée
8. En cas d'erreur, une réponse JSON avec le message d'erreur est renvoyée

Story 5.6 : Feedback utilisateur (succès/erreur)

En tant que visiteur, Je veux savoir clairement si mon message a été envoyé, Afin de ne pas douter et éviter les envois multiples.

Critères d'acceptation :

1. Pendant l'envoi, un indicateur de chargement est affiché (spinner ou texte)
2. Le bouton d'envoi est désactivé pendant le traitement
3. En cas de succès : message de confirmation visible, formulaire réinitialisé, localStorage vidé
4. En cas d'erreur : message d'erreur explicite, données conservées pour réessayer
5. L'envoi est fait en AJAX (pas de rechargement de page)
6. Le message de succès invite à vérifier les spams si pas de réponse

Story 5.7 : Liens de contact secondaires

En tant que visiteur, Je veux avoir des alternatives au formulaire pour contacter le développeur, Afin de choisir le canal qui me convient.

Critères d'acceptation :

1. Sous le formulaire, une section affiche les liens secondaires : LinkedIn, GitHub, email direct (mailto)
2. Les liens sont affichés avec leurs icônes respectives
3. Les liens s'ouvrent dans un nouvel onglet (sauf mailto)
4. La section est visuellement distincte mais cohérente avec le formulaire
5. L'adresse email est protégée contre le scraping (encodage ou JS)

7. Rapport de Validation PM

Résumé

Métrique	Valeur
Complétude du PRD	95%
Scope MVP	Approprié
Prêt pour l'architecture	✅ Oui

Statut par Catégorie

Catégorie	Statut
Définition du problème & Contexte	✅ PASS
Scope MVP	✅ PASS
Exigences UX	✅ PASS
Exigences fonctionnelles	✅ PASS
Exigences non-fonctionnelles	✅ PASS
Structure Epic/Story	✅ PASS
Guidance technique	✅ PASS
Exigences cross-fonctionnelles	✅ PASS
Clarté & Communication	✅ PASS

Décision

✅ READY FOR ARCHITECT - Le PRD est complet et prêt pour la phase d'architecture.

8. Prochaines Étapes

8.1 Prompt UX Expert

Bonjour, je suis le Product Manager et j'ai finalisé le PRD pour un portfolio développeur web.

Le document se trouve dans docs/prd.md.

Objectif principal : Créer un design qui incarne le principe "Montrer plutôt que dire" avec une expérience utilisateur fluide et sans friction.

Points clés à considérer :
- Navigation claire avec CTA "Me contacter" toujours visible
- Pages projets avec structure : Contexte → Solution → Réalisation
- Formulaire de contact optimisé pour la conversion
- Design responsive mobile-first
- Animations subtiles au service du contenu

Merci de proposer des wireframes et recommandations UX basés sur ce PRD.

8.2 Prompt Architecte

Bonjour, je suis le Product Manager et j'ai finalisé le PRD pour un portfolio développeur web.

Le document se trouve dans docs/prd.md.

Stack technique validé :
- PHP natif (pas de framework)
- Tailwind CSS avec CLI build
- JavaScript vanilla
- Fichiers JSON pour les données (projets, témoignages)
- Router PHP simple pour URLs propres
- Hébergement sur serveur personnel

Points d'attention :
- Router PHP léger (<50 lignes) pour URLs type /projet/{slug}
- Structure JSON pour le mini-CMS projets
- Formulaire de contact avec reCAPTCHA v3 et envoi email PHP
- Optimisation performance (Lighthouse > 90)

Merci de créer le document d'architecture basé sur ce PRD.