# Dashboard Contenu — Cadrage / Design

- **Date** : 2026-07-24
- **Statut** : **CADRAGE** — document de vision et de découpage. Pas d'implémentation lancée (décision Bastien : « juste maquetter/cadrer »).
- **Source** : design Claude Design `~/Downloads/seo-insight-web/project/Dashboard Contenu - Final.html` (2 frames : A = vue d'ensemble, B = éditeur split). Design self-contained (aucun import externe hors fonts).
- **Décisions de cadrage (Bastien)** : démarrer par le **cadrage** (pas de code tout de suite) ; **éditeur IA in-app différé** (à décider plus tard) ; **WordPress différé**.

## Vision

Une section Contenu qui va au-delà du pipeline éditorial actuel : un **poste de travail SEO du contenu** — voir la santé SEO de toutes les pages du site, puis entrer dans une page pour l'optimiser (éditeur + analyse temps réel + suggestions IA + aperçu Google). Le design se découpe en deux frames de maturité très différente.

## État de l'existant (audit, 2026-07-24)

**Réutilisable :**
- `site_pages` (`domain-schema.ts:369`) : pages crawlées du sitemap — `url, status, title, metaDescription, h1, h1Count, canonical, robots, lang, wordCount, issues[], crawledAt`. Crawler `src/lib/pages/crawl-runner.ts`, checklist `src/lib/pages/issues.ts` (title/desc/h1/noindex/canonical), UI table `src/components/pages/pages-view.tsx` (`/pages`).
- Moteur sémantique wasm `src/lib/semantic/` : `parse_onpage_document` (récupère markdown + images + **alt** + JSON-LD, aujourd'hui non exploité par `site_pages`), guide de termes BM25F, gap analysis — mais **orienté corpus SERP concurrent**, pas « ma page vs cible ».
- Pipeline éditorial `content_items` (`domain-schema.ts:557`) : kanban idea→published, briefs, assignee — mais **pas de corps de contenu ni de méta stockés**.
- Perf GSC par page (`gsc_page_snapshots`, `content/stats`, `content/online`).
- Rendu markdown (react-markdown, lecture seule) ; génération de **prompt IA copy-paste** (`build-prompt.ts`) ; audit spec technique du site (`spec/audit/checks.ts`).

**Inexistant (à construire) :**
- Score SEO numérique **par page rédigée** (le moteur score les concurrents, pas la page propre).
- Densité mot-clé / lisibilité (Flesch) / checklist on-page (alt, liens internes) appliquées à une page.
- Éditeur riche (tiptap/lexical/contenteditable) — zéro.
- Génération IA **in-app** (pas de SDK LLM ; modèle actuel = prompt copy-paste externe + MCP).
- Aperçu Google (SERP preview) — zéro composant.
- Stockage du corps de contenu.
- **Intégration WordPress** — zéro (`wp-json`, auth, sync).

## Découpage en phases

### Phase 1 — Frame A : Vue d'ensemble (implémentable, réutilise l'existant)

La page « Contenu » liste toutes les pages du site avec leur santé SEO. S'appuie sur `site_pages` + crawl + issues déjà en place.

- **KPIs** : Pages suivies, Score moyen, Pages à corriger (dont critiques), Métas générées IA (ce dernier dépend d'une feature IA — à adapter/retirer en Phase 1).
- **Toolbar** : recherche, filtre par score, tri par priorité. (Le segment « WordPress / App » du design est **différé** — voir WordPress ci-dessous ; en Phase 1, une seule source = crawl sitemap.)
- **Table** (colonnes du design) : Page (titre + slug), Score /100, Title (statut + longueur), Méta desc (statut + longueur), Hn (statut), Mot-clé cible (via mapping keyword↔page existant `pages/mapping.ts`), Mots (`wordCount`), MàJ (`crawledAt`), action « ouvrir ».
- **À construire en Phase 1** : un **scorer de page** — agrège les `issues[]` on-page existantes en un score /100 + un statut par dimension (title/méta/Hn). Étendre le crawl pour exploiter `parse_onpage_document` (alt/images/liens) afin d'enrichir la checklist. Pur, testable.

**Décision d'architecture à trancher au moment d'implémenter** : le Frame A ressemble à `/pages` (audit de pages crawlées) plus qu'au `/content/overview` actuel (pipeline éditorial `content_items`). Deux options :
1. Frame A **devient** le nouveau `/content/overview` (le pipeline éditorial migre ailleurs ou cohabite).
2. Frame A **enrichit `/pages`** et le design Contenu pointe dessus.
À réconcilier avec le rôle actuel de `/content/*` (overview/planning/online/stats = pipeline éditorial) — ne pas casser l'existant. Rappel : `/content` est aujourd'hui gaté « under-construction » en prod.

### Phase 2+ — Frame B : Éditeur split (DIFFÉRÉ — vrai produit à part)

Liste des pages / éditeur riche (title, méta, slug, corps) avec **suggestions IA inline** + **aperçu Google live** / panneau d'analyse (score, checklist actionnable, densité, lisibilité, génération IA, maillage interne).

**Prérequis structurels (aucun n'existe) — chacun est une décision et un chantier :**
- **Éditeur riche** : choix tiptap/lexical, stockage du corps (nouveau champ/table), autosave.
- **IA in-app** : intégrer un SDK LLM (Claude) pour title/méta/paragraphes/suggestions — **décision produit lourde** (coûts API récurrents, streaming, quotas). Alternative : rester sur le modèle prompt copy-paste + MCP. **Différé, à trancher.**
- **SERP preview** : composant d'aperçu snippet Google (rendu title/URL/méta façon Google), live sur les champs édités.
- **Scorer page-vs-cible** : relier le guide sémantique (SERP concurrente) à la page rédigée pour densité/coverage/gap réels + lisibilité (Flesch à implémenter).

Frame B mérite son **propre cycle brainstorm → spec → plan** quand il sera priorisé, une fois les décisions IA/éditeur prises.

### Transverse — WordPress (DIFFÉRÉ)

Le design assume « WordPress vs App » (badges Source, bouton Sync WordPress). L'app n'a **aucune** intégration. C'est un chantier séparé (auth `wp-json`/Application Passwords, sync pages/articles bidirectionnelle). Différé : en Phase 1, la source de pages reste le crawl du sitemap.

## Design system (note d'implémentation future)

Le proto utilise ses propres tokens (bleu `#5b6ef5`, orange `#ff5722`, fonts Manrope/Inter/JetBrains Mono). À l'implémentation, **adapter au design system de l'app** (shadcn + thème, police Geist) — recréer le rendu, pas copier les couleurs/fontes du proto. L'accent orange du proto correspond à la marque (logo braise) — à confirmer comme accent produit.

## Ce que ce document N'EST PAS

Un plan d'implémentation. Aucune tâche n'est ouverte. Prochaine étape possible (sur décision Bastien) : brainstormer/planifier **Phase 1 (Frame A)** seule, en réutilisant `site_pages`/crawl/issues + un scorer de page — c'est le morceau à valeur rapide et faible risque.

## Décisions ouvertes (pour plus tard)
- Frame A : nouveau `/content/overview` vs enrichir `/pages` (réconciliation avec le pipeline éditorial actuel).
- Frame B : IA in-app (SDK LLM) vs modèle prompt externe.
- WordPress : si/quand.
- Le KPI « Métas générées par IA » et la colonne « Source WordPress/App » dépendent de features différées — à adapter en Phase 1.