Mb Minimalistic Fr

---
name: mb-minimalistic-fr
description: Direction artistique MB-Minimalistic — minimalisme éditorial calme, palette quasi-monochrome en OKLCH, Manrope + IBM Plex Mono, rayons courts, zéro ombre, séparation par filets 1px. Utiliser pour créer ou refondre une interface dans cette DA (boutique, landing, dashboard, portfolio, docs, app). Sur un repo vide, demande quoi construire et propose des pistes ; sur une base de code existante, audite d'abord le stack en place puis migre par vagues réversibles. Version française.
---

# MB-Minimalistic — minimalisme éditorial calme

Direction artistique complète, extraite d'une boutique de soins en production (Next.js 16 + Tailwind v4 + base-ui), généralisée à n'importe quel type de produit.

Principe unique : **la page est un document, pas une vitrine.** Tout ce qui attire l'œil sans porter d'information est supprimé. Le contraste vient de la typographie et du blanc, jamais de la couleur ni de l'ombre.

---

## ÉTAPE 0 — Toujours commencer ici

**D'abord, déterminer sur lequel des deux chemins on se trouve.** Ne rien demander avant ça — c'est une vérification du système de fichiers, pas une question :

```bash
ls app pages src components 2>/dev/null | head
cat package.json 2>/dev/null | head -30
```

- **Repo vide ou quasi vide** → chemin A, greenfield. Continuer ci-dessous.
- **Code d'interface existant** (routes, composants, une feuille de style avec des variables) → **chemin B. S'arrêter et lire `references/adoption.md` maintenant.** Le premier geste du chemin A est de coller `tokens.css`, ce qui dans un projet vivant duplique l'import Tailwind et supprime toutes les variables que le projet possède. Le chemin B audite d'abord, fusionne les tokens, puis migre par vagues.

Cas ambigu (un `create-next-app` frais avec seulement le boilerplate) ? Le traiter comme chemin A, mais garder la règle de fusion : ne jamais supprimer une variable qu'on n'a pas introduite.

---

### Chemin A — greenfield

Si l'utilisateur n'a **pas** déjà dit précisément quoi construire, poser la question avec `AskUserQuestion` **avant d'écrire une ligne de code**.

Question 1 — « Qu'est-ce que tu veux construire avec MB-Minimalistic ? » (header : `Projet`)

Choisir les 4 options les plus plausibles selon le contexte du repo courant :

| Piste | Ce que ça donne dans cette DA |
|---|---|
| **Boutique / e-commerce** | Grille produits sans carte, image 4/5, prix en mono, panier en sheet latéral, checkout 1 colonne + récap sticky |
| **Landing produit ou marque** | Hero 2 colonnes texte/image, bande de promesses en `border-y`, section process, CTA sobre |
| **Dashboard / app interne** | Filets 1px partout, chiffres en mono, densité haute (`h-8` par défaut), zéro carte flottante |
| **Portfolio / site éditorial** | Colonne `max-w-2xl`, eyebrow mono, titres déclaratifs, images pleine largeur |
| **Docs / blog technique** | Sommaire discret, code en Plex Mono, `label-mono` pour les métadonnées |
| **Écrans d'app mobile** | Même palette, cibles `h-11`, sheets bas, pas de bottom-bar colorée |

Question 2 — « Teinte de base ? » (header : `Teinte`)
- **Sauge (d'origine)** — hue 145–152, la référence
- **Neutre pur** — chroma 0, gris papier
- **Autre hue** — même plafond de chroma (≤ 0.06), hue au choix (terracotta 40, encre 250, sable 80)

Question 3 — « Couple typographique ? » (header : `Typo`) — voir les quatre couples autorisés dans [Typographie](#typographie). Par défaut **Manrope + IBM Plex Mono** si l'utilisateur n'a pas d'avis ; ne jamais inventer un couple hors de cette liste.

Question 4 (si pertinent) — « Portée ? » (header : `Portée`) : page unique / parcours multi-pages / composants isolés / refonte d'un existant.

Ensuite : proposer en 3–5 lignes un plan de sections concret pour la piste choisie, puis construire.

**Ne jamais sauter cette étape sous prétexte que la demande semble évidente.** Si l'utilisateur a déjà tout précisé (« fais-moi une landing pour un torréfacteur en MB-Minimalistic, sauge »), passer directement à la construction.

---

### Chemin B — projet existant

Procédure complète dans `references/adoption.md`. La forme générale :

1. **Auditer avant de poser la moindre question.** Détecter la version de Tailwind, la base de composants (`base-nova` / shadcn Radix / aucune), quelles variables CSS le projet possède déjà, et comment les polices sont chargées. Compter les violations de la DA.
2. **Restituer l'écart** sous forme de tableau P0/P1/P2 avec les comptes réels, pour que la taille du chantier soit visible avant que le moindre code bouge.
3. **Ensuite** demander — et les questions diffèrent du chemin A :

   - Question 1 — « Portée ? » (header : `Portée`) : toute l'app / une route pilote *(recommandé)* / seulement les tokens / seulement les composants
   - Question 2 — « Teinte de base ? » — mêmes trois options que le chemin A, mais par défaut **garder leur teinte existante** si la marque en a déjà une ; seuls le plafond de chroma et la conversion OKLCH sont non négociables
   - Question 3 — « Couple typographique ? » — proposer de garder leurs fontes actuelles si le couple satisfait déjà les règles (une sans, une mono, poids ≤ 500)
   - Question 4 — « Jusqu'où ? » (header : `Profondeur`) : tokens seuls / tokens + primitives / migration visuelle complète

4. **Migrer par vagues**, un commit chacune : vague 0 tokens et polices sans toucher un composant, vague 1 primitives, vague 2 une route de bout en bout, vague 3 le reste, vague 4 nettoyage. Après la vague 0, l'app est *censée* paraître fausse mais cohérente.

Deux règles dures sur ce chemin : **ne jamais supprimer une variable qu'on n'a pas introduite**, et **ne jamais réécrire un écran avant que l'utilisateur ait vu et validé le rapport d'écart**. Si l'audit montre des centaines de violations P0, dire que la migration est un chantier de plusieurs jours et proposer une route pilote plutôt que de démarrer.

---

## Tokens — copier tels quels

Bloc complet prêt à coller : `references/tokens.css`. Résumé du contrat :

- **Espace couleur : OKLCH obligatoire.** Aucun hex, aucun `rgb()`.
- **Chroma plafonné à 0.06** sur tout sauf `--destructive`. Une seule famille de hue (145–152 en sauge) sur toute l'UI, light et dark.
- `--radius: 0.25rem` et l'échelle est **multiplicative** (`calc(var(--radius) * 0.6)` … `* 2.6`), pas additive. Changer une seule variable retaille tout.
- Le dark mode inverse la luminance et **remonte** la primaire (0.42 → 0.82) : en clair la primaire est sombre, en sombre elle est claire. Jamais la même valeur dans les deux thèmes.
- Bordures en dark = `oklch(1 0 0 / 12%)`, jamais une couleur opaque.

Utilitaire signature, à recréer systématiquement :

```css
@utility label-mono {
  @apply font-mono text-[0.7rem] uppercase tracking-[0.18em];
}
```

---

## Typographie

Deux fontes, jamais trois : une sans pour tout, une mono pour chaque chiffre. `next/font/google` avec `variable` + `display: 'swap'`.

### Les quatre couples autorisés

Demander lequel (Question 3), puis câbler celui-là uniquement. Ne pas mélanger, ne pas substituer une fonte hors liste.

**1 — Manrope + IBM Plex Mono** (référence, défaut)
Légèrement géométrique, chaleureux, esprit pharmacie française. Le couple sur lequel la DA a été conçue.

```ts
const sans = Manrope({ subsets: ['latin'], variable: '--font-manrope', display: 'swap' })
const mono = IBM_Plex_Mono({ subsets: ['latin'], weight: ['400', '500'], variable: '--font-plex-mono', display: 'swap' })
```

**2 — Geist + Geist Mono** (package `geist`, pas Google)
Plus froid, plus technique, chasse plus serrée. Idéal dashboards et produits développeur.

```ts
import { GeistSans } from 'geist/font/sans'
import { GeistMono } from 'geist/font/mono'
// className={`${GeistSans.variable} ${GeistMono.variable}`}
// --font-sans: var(--font-geist-sans);  --font-mono: var(--font-geist-mono);
```
Compenser ses métriques serrées : `leading` du héro à `1.02`, tracking de `label-mono` monté à `0.2em`.

**3 — Inter Tight + JetBrains Mono**
L'option la plus neutre, la meilleure couverture linguistique. La mono est plus large — les colonnes de chiffres respirent davantage.

```ts
const sans = Inter_Tight({ subsets: ['latin'], variable: '--font-sans-var', display: 'swap' })
const mono = JetBrains_Mono({ subsets: ['latin'], weight: ['400', '500'], variable: '--font-mono-var', display: 'swap' })
```

**4 — Instrument Serif en display + Manrope + IBM Plex Mono** (seule exception tolérée à la règle des deux fontes)
Une serif pour les `h1`/`h2` **uniquement** — jamais le corps, jamais les boutons, jamais les labels. Bascule la DA en éditorial/luxe.

```ts
const display = Instrument_Serif({ subsets: ['latin'], weight: '400', variable: '--font-display', display: 'swap' })
// @theme inline { --font-display: var(--font-display), ui-serif, serif; }
// titres : className="font-display text-5xl font-normal tracking-[-0.01em]"
```
Avec ce couple les titres sont en `font-normal` (400) et `tracking-[-0.01em]`, pas `font-medium tracking-tight` — une serif en 500 paraît cassée.

Le bloc de tokens expose toujours exactement `--font-sans` et `--font-mono` (plus `--font-display` pour le couple 4). Toutes les recettes de `references/patterns.md` fonctionnent quel que soit le couple retenu.

### Règles non négociables

1. **Aucun titre en `font-bold`.** `font-medium` (500) est le poids maximum du site — `font-normal` (400) avec le couple 4. Le poids ne crée pas la hiérarchie : la taille et l'espace la créent.
2. **Titres** : `tracking-tight` + `text-balance`. H1 hero : `text-4xl sm:text-5xl lg:text-6xl leading-[1.05]`. H1 de page : `text-3xl lg:text-4xl`. H2 : `text-2xl lg:text-3xl`.
3. **Corps** : `text-sm leading-relaxed text-muted-foreground text-pretty`, largeur bornée (`max-w-md` / `max-w-lg` / `max-w-xl`). Le texte courant est gris, pas noir.
4. **Eyebrow** : `.label-mono text-muted-foreground` au-dessus de chaque titre de section. C'est la signature de la DA — un nom commun court (« Le rituel », « Catalogue », « Favoris »), pas une phrase.
5. **Tout chiffre est en mono** : prix, quantités, compteurs, notes, références, dates, totaux, pourcentages. Sans exception. C'est ce qui donne l'aspect apothicaire.
6. Prix formatés via `Intl.NumberFormat`, jamais concaténés à la main.

---

## Surface, profondeur, rayons

- **Zéro `shadow-*`** sur les cartes, boutons, inputs, dropdowns. La seule ombre autorisée du système est `shadow-lg` sur un sheet en overlay.
- La séparation se fait par : `border border-border` (1px), un fond `bg-secondary` / `bg-muted`, ou du vide. Dans cet ordre de préférence.
- **Pas de carte autour des items de grille.** Image + texte dessous, aucun conteneur, aucune bordure.
- Rayons : `rounded-md` sur les vignettes, `rounded-lg` sur les grands blocs et images héro, `rounded-full` **uniquement** pour pastilles, compteurs et chips de filtre. Jamais de `rounded-2xl`+ sur un conteneur.
- Header : `sticky top-0 z-40 border-b border-border bg-background/85 backdrop-blur-md`. C'est le seul flou de l'interface.
- État vide : `border border-dashed border-border` + icône dans un rond `bg-muted` + une phrase + un bouton `outline`.

---

## Grille et rythme

- Conteneur : `mx-auto w-full max-w-6xl px-4 sm:px-6`.
- Rythme vertical : `py-12 lg:py-16` pour une page, `py-16`/`py-20` pour une section héro, `mb-10`/`mb-14` sous un header de page.
- **Grille d'items : `grid-cols-2 lg:grid-cols-4 gap-x-4 gap-y-10`.** Le gap vertical est ~2,5× l'horizontal — les lignes respirent, les colonnes serrent. Toujours 2 colonnes sur mobile, jamais 1.
- Bandes pleine largeur pour les faits : `<section className="border-y border-border">` avec une `<dl>` intérieure `lg:divide-x`. Sert aux promesses, stats, garanties.
- Split éditorial : `grid overflow-hidden rounded-lg border border-border lg:grid-cols-2` — image d'un côté, texte + CTA de l'autre, `p-8 lg:p-12`.
- Layouts asymétriques quand deux colonnes ont des poids différents : `lg:grid-cols-[1.2fr_0.8fr]` (formulaire/récap), `lg:grid-cols-[1.5fr_repeat(3,1fr)]` (footer).
- Aside de récap : `h-fit lg:sticky lg:top-24`.

---

## Imagerie

Le photographique porte toute la chaleur de la DA, puisque l'UI n'en a aucune. Direction détaillée + prompts : `references/imagerie.md`.

- Ratios : `aspect-4/5` (vignette), `aspect-square` (fiche détail), `aspect-3/4` ou `aspect-4/5` (héro), `aspect-16/10` (bandeau).
- Toujours `fill` + `sizes` explicite + `object-cover`, sur un parent `relative overflow-hidden bg-secondary` (le fond sert de placeholder pendant le chargement).
- `priority` sur la première image seulement.
- Hover : `transition-transform duration-500 group-hover:scale-[1.03]`. Discret, lent.

---

## Mouvement

Peu, lent, jamais décoratif.

- Liens et textes : `transition-colors` seul.
- Image de vignette : `duration-500`, scale 1.03 max.
- Action révélée au survol : `translate-y-2 opacity-0 → group-hover:translate-y-0 group-hover:opacity-100`, `duration-300`, **avec `focus-within:` en miroir** pour le clavier.
- Boutons : `active:translate-y-px`. C'est tout le budget de feedback tactile.
- Overlays : `duration-150`/`duration-200`, translation de `2.5rem`, opacité.
- **Interdits** : parallaxe, animations au scroll, springs, compteurs animés, carrousels, skeletons scintillants, `animate-pulse`.

---

## Architecture des composants

Convention à respecter pour tout nouveau composant (exemples complets : `references/patterns.md`).

- Primitives **base-ui** (`@base-ui/react/*`) + `cva` pour les variantes + `cn()` (clsx + tailwind-merge).
- `data-slot="..."` sur chaque racine de primitive.
- Polymorphisme par `render={<Link href="..." />}`, **pas** `asChild`.
- Tailles par défaut denses (`h-8`), et on **surcharge à l'usage** pour les zones marketing : `className="h-10 px-5"` (secondaire), `className="h-11 px-6"` (primaire/hero).
- Variantes de bouton : `default`, `outline`, `secondary`, `ghost`, `destructive`, `link`. `destructive` est en fond `/10`, pas en rouge plein.
- Icônes **lucide-react** uniquement, taille auto `size-4` (`size-3.5` en `sm`). Jamais d'emoji dans l'UI.
- Données statiques typées dans `lib/<domaine>.ts` : un `type`, un tableau `const`, des helpers (`getX(slug)`, `formatX()`). Pas de données en dur dans les composants.

---

## shadcn/ui — projets Next.js

Quand la cible est une app Next.js, ne pas écrire les primitives à la main. Scaffolder avec shadcn, puis appliquer la DA par-dessus.

### 1. Config — `components.json`

```json
{
  "$schema": "https://ui.shadcn.com/schema.json",
  "style": "base-nova",
  "rsc": true,
  "tsx": true,
  "tailwind": {
    "config": "",
    "css": "app/globals.css",
    "baseColor": "neutral",
    "cssVariables": true,
    "prefix": ""
  },
  "aliases": {
    "components": "@/components",
    "utils": "@/lib/utils",
    "ui": "@/components/ui",
    "lib": "@/lib",
    "hooks": "@/hooks"
  },
  "iconLibrary": "lucide"
}
```

`"style": "base-nova"` est déterminant : il génère des primitives **base-ui** avec la prop `render`, les attributs `data-slot` et les variantes `size` que cette DA suppose. Les styles basés sur Radix ne le font pas — ils utilisent `asChild` et un autre système de tailles. `"config": ""` est correct en Tailwind v4 (pas de fichier de config JS). `baseColor: neutral` ne sert qu'à amorcer le générateur ; le bloc OKLCH de `references/tokens.css` l'écrase juste après.

### 2. N'installer que ce dont la surface a besoin

```bash
npx shadcn@latest init          # sauter si components.json est déjà écrit
npx shadcn@latest add button input label separator sheet sonner
```

| Surface | À ajouter |
|---|---|
| Tout projet | `button input label separator sonner` |
| Boutique / panier | `+ sheet badge checkbox radio-group select` |
| Dashboard | `+ table tabs dropdown-menu tooltip skeleton` |
| Formulaires / réglages | `+ select checkbox radio-group switch textarea` |
| Docs / contenu | `+ tabs accordion scroll-area` |

Ne jamais ajouter tout le registre d'un coup. Une primitive inutilisée est du code mort qui dérive de la DA.

### 3. Patcher chaque composant ajouté

Les composants générés arrivent avec des valeurs par défaut que cette DA interdit. Juste après le `add`, passer sur les nouveaux fichiers de `components/ui/` :

- Supprimer `shadow-xs` / `shadow-sm` / `shadow-md` des boutons, inputs, cartes, popovers, dropdowns. Seul un sheet en overlay garde `shadow-lg`.
- Vérifier que les rayons passent bien par `var(--radius)` — remplacer tout `rounded-xl`/`rounded-2xl` codé en dur sur un conteneur par `rounded-lg`.
- Garder les tailles denses par défaut (`h-8`, `size-7`). Ne pas les augmenter globalement — surcharger à l'usage avec `className="h-10 px-5"` ou `h-11 px-6`.
- `destructive` doit rester un fond teinté `/10`, pas un bouton rouge plein.
- Toaster : brancher `--normal-bg`, `--normal-text`, `--normal-border`, `--border-radius` sur les tokens de la DA et passer les icônes lucide en `size-4`.
- Supprimer tout `focus:ring-offset-*` — cette DA utilise `focus-visible:ring-3 focus-visible:ring-ring/50`, sans offset.

### 4. Ordre des opérations (greenfield)

Projet existant : sauter cette liste et suivre `references/adoption.md` §3 — la base de composants est déjà choisie.

1. `create-next-app` (App Router, TypeScript, Tailwind v4)
2. Écrire `components.json`
3. Coller `references/tokens.css` dans `app/globals.css` — **avant** d'ajouter les composants, pour que le code généré lise les bonnes variables
4. Câbler le couple typographique choisi dans `app/layout.tsx`
5. `shadcn add` les primitives nécessaires, puis les patcher (étape 3 ci-dessus)
6. Construire les écrans à partir de `references/patterns.md`

Autres stacks (Vite, Remix, Astro, React nu) : mêmes tokens, mêmes règles, sauter cette section et écrire les primitives à la main — `references/patterns.md` ne demande que Tailwind v4 et `cn()`.

---

## Accessibilité (partie de la DA, pas une option)

- Tout bouton-icône a un `<span className="sr-only">` ou un `aria-label` explicite.
- Filtres, tailles, favoris → `aria-pressed`.
- `<nav aria-label="...">` sur chaque nav (principale, mobile, colonnes de footer).
- Formulaires : `noValidate`, validation maison, `aria-invalid`, `aria-describedby` vers un `<p id="{id}-error" className="text-xs text-destructive">`.
- Sémantique réelle : `<dl>` pour les paires clé/valeur, `<ol>` pour les étapes, `<article>` pour un item de grille.
- L'état actif d'un filtre se marque par `border-foreground text-foreground` — jamais par la couleur seule.

---

## Ton éditorial

- Titres = **affirmations courtes et sûres** : « La peau n'a pas besoin de dix étapes. », « Huit formules, rien de superflu », « Trois gestes suffisent ». Jamais de question rhétorique en H1, jamais de point d'exclamation.
- Sous-titres : une à deux phrases factuelles, qui expliquent le *comment*, pas qui vendent.
- Microcopie chiffrée et vérifiable : « Livraison offerte dès 60 € », « 12 ingrédients en moyenne », « expédié en 48 h ».
- États vides : constat + geste. « Touchez le cœur sur un produit pour le garder de côté et le retrouver ici. »
- Bannis : « révolutionnaire », « incroyable », emoji, superlatifs, majuscules d'insistance, « ✨ ».

---

## Liste noire

Si l'un de ces éléments apparaît, la DA est cassée :

dégradés · ombres portées sur cartes · glassmorphisme (hors header) · titres en 700+ · plus de deux fontes · violet/bleu SaaS · accents saturés · `rounded-2xl`+ sur conteneurs · carrousels héro · emoji · illustrations 3D · badges colorés multiples · boutons pleins de couleurs différentes · chiffres en sans-serif · texte centré sur de longs paragraphes · animations au scroll.

---

## Références

- `references/adoption.md` — **chemin B** : auditer un projet existant, fusionner les tokens sans détruire les leurs, replis Tailwind v3 et shadcn Radix, migration par vagues, retour arrière.
- `references/tokens.css` — bloc `@theme` + `:root` + `.dark` complet, à coller dans `globals.css`. **Greenfield uniquement** — dans un projet existant, utiliser le bloc de fusion de `adoption.md`.
- `references/patterns.md` — recettes JSX : header, grille d'items, split éditorial, bande de faits, sheet, champ de formulaire, état vide, footer.
- `references/imagerie.md` — direction photo et prompts de génération d'images cohérents avec la palette.

---

**MB-Minimalistic** · Version anglaise : `mb-minimalistic`