`/`` ajouté juste pour l'effet
- Interdit : variantes quasi-identiques d'une classe existante (`titre_2_bis`, `row_pad_2`) — réutiliser ou créer une seule classe pérenne. Détail complet : `config/context-stack.md` §5.5 et `.cursorrules`
## Fidélité de montage — recréer une page à l'identique
- S'applique à toute page montée à partir d'une référence à reproduire (maquette Figma/V0, capture d'écran, page existante à migrer)
- Avant de coder : analyser toute la source (sections, ordre, textes, interactions, responsive) et s'appuyer sur le découpage/les classes des pages du même `type`/`template` déjà montées — ne pas coder au fil de l'eau
- Avant de déclarer terminé : repasser source et résultat côte à côte section par section (pas une simple impression visuelle), vérifier la cohérence avec les pages du même type, corriger tout écart plutôt que de le noter pour plus tard, et signaler explicitement les écarts volontaires. Détail complet : `config/context-stack.md` §5.9 et `.cursorrules`
---
## SEO — règles obligatoires sur chaque page
- Une seule `
` par page, hiérarchie stricte H1→H2→H3
- `generateMetadata()` pour injecter `metaTitle` (50-60 car.) et `metaDescription` (140-160 car.) depuis Sanity ou le YAML en fallback
- JSON-LD sur chaque page (minimum `WebPage` ou `Service` ; `FAQPage` si FAQ ; `BreadcrumbList` sur toutes les pages sauf homepage)
- Slugs en minuscules, kebab-case, sans caractères spéciaux
- `noindex` → injecter `` via `generateMetadata()`
---
## Sanity — règle absolue
Si Sanity est connecté, **tout le contenu visible doit être éditable dans Sanity Studio** : titres, paragraphes, boutons, images, liens, navigation, footer, mentions légales, métadonnées SEO, textes alt des images. Aucun texte éditorial en dur dans le JSX. Les balises `alt` ne s'écrivent jamais en dur — elles viennent toujours de Sanity.
Champs minimum par page dans Sanity : `titre`, `contenu`, `metaTitle`, `metaDescription`, `slug`, `image principale avec alt`.
---
## Formulaires de contact (Phase 5B — optionnel)
Workflow : `Formulaire (Next.js) → /api/contact → Resend (email) + Supabase (stockage)`
**Prérequis à faire tôt (Phase 2) :**
- Créer un compte Resend, ajouter et vérifier le domaine (enregistrements DNS TXT + CNAME chez le registraire)
- La vérification DNS peut prendre plusieurs heures — à faire dès que le domaine est connu
**Mise en place (Phase 5B) :**
- Créer un compte Supabase, créer la table `contact_submissions` (colonnes : `id`, `name`, `email`, `message`, `created_at`)
- `npm install resend @supabase/supabase-js react-google-recaptcha-v3`
- Créer `/app/api/contact/route.ts` — vérification reCAPTCHA v3 d'abord, puis envoi Resend + insert Supabase en parallèle (`Promise.all`)
- Clés reCAPTCHA à créer sur google.com/recaptcha/admin (ajouter `localhost` ET le domaine de prod)
- Page contact-merci : `noindex: true`, `excludeFromSitemap: true`, redirection 301 si slug change
- Ajouter les **6 variables** dans Vercel > Settings > Environment Variables (pas seulement dans `.env.local`)
**Limites plan gratuit :**
- Resend : 100 emails/jour (bloqué si dépassé, pas de file d'attente)
- Supabase : 500 000 lignes, 50 000 requêtes/mois
---
## Fonctionnalités générées automatiquement
**Fil d'ariane (`/components/Breadcrumb.tsx`)** : présent sur toutes les pages sauf homepage, généré depuis la hiérarchie de `architecture.yaml`, avec JSON-LD `BreadcrumbList`.
**Sitemap** : `/app/sitemap.ts` lit `architecture.yaml` via `/lib/sitemap-utils.ts` et génère `sitemap.xml` automatiquement à chaque déploiement Vercel.
**Redirections** : déclarées dans `/config/redirects.json`, importées dans `next.config.js`. Toute suppression de page ou changement de slug génère une redirection 301.
**Interfaces admin (local uniquement, ne pas déployer en prod) :**
- `localhost:3000/admin/arborescence` : tri et organisation des pages (drag & drop, gestion des statuts, export vers `architecture.yaml`)
- `localhost:3000/admin/medias` : bibliothèque média avec édition des métadonnées via Sanity
---
## WPGraphQL (migration depuis WordPress)
Utilisé uniquement si le projet migre depuis un WordPress existant. Le plugin WPGraphQL doit être installé sur le WordPress **avant** de coder. Ne jamais utiliser la REST API WordPress.
- Stocker l'URL GraphQL dans `.env.local` : `WORDPRESS_GRAPHQL_URL`
- Récupérer uniquement les métadonnées légères pour l'arborescence (title, slug, metaTitle, metaDescription, status)
- Mapper `status` WordPress → `published` YAML : `publish` → `true`, `draft`/`private` → `false`
- Ne jamais écraser `architecture.yaml` automatiquement sans confirmation explicite
---
## Git — branches et configuration
- `main` → production (connectée à Vercel)
- `preprod` → validation client (URL de prévisualisation Vercel)
- `dev` → développement en cours
- Flux : `dev` → `preprod` (validation client) → `main` (déploiement production)
**Avant le premier commit — configurer l'email Git :**
```bash
git config user.email "123456789+tonusername@users.noreply.github.com"
git config user.name "tonusername"
```
L'email doit correspondre au compte GitHub (noreply ou email personnel via GitHub → Settings → Emails). Sans ça, Vercel bloque les déploiements avec le statut "Blocked".