Story 1.1: initialisation projet

docs/prd.md

@@ -0,0 +1,700 @@
+# 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` :**
+```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.
+```