---
title: UX — Patterns validés : Général
domain: ux
bucket: patterns
tags: [mobile, navigation, cta, fab, liste, etat, i18n, a11y, notifications]
applies_to: [design, implementation, review]
severity: medium
validated_on: 2026-06-25
source_projects: [app-alexandrie]
---

# UX — Patterns validés : Général

> Extrait de la base de connaissance Lead_tech. Voir `knowledge/ux/patterns/README.md` pour l'index complet.

---

<a id="pattern-ux-mark-read-au-mount"></a>
## Pattern : Marquage "lu" au mount de l'écran cible (mount-based, pas click-based)

- Objectif : éviter les "clics accidentels qui consomment" une notification — marquer comme lu uniquement quand l'utilisateur a réellement vu le contenu.
- Contexte : liste de notifications qui navigue vers un écran cible (thread, conversation, achievements).
- Quand l'utiliser : tout flux notification → écran cible où le clic ne prouve pas la lecture.
- Quand l'éviter : action où le clic EST l'acte de lecture (ex. dépliage inline).

### Description

Mauvais pattern : `onPress(item) → markRead(item.id); navigate(target)` — un clic accidentel puis back immédiat consomme la notif sans qu'elle ait été vue ; la notif disparaît avant que l'écran cible monte.

Bon pattern : déléguer le mark-read à l'écran cible, déclenché au mount via query param (`?notificationId=`). Un hook `useMarkNotificationReadOnMount()` lit le param et appelle `markRead` dans un `useEffect`, avec un guard d'idempotence (`alreadyMarkedRef`) contre les re-renders (focus refresh, hot reload).

Comportements obtenus : cas nominal (tap → écran monte → lu), cas annulation (tap → back avant mount → reste non lu), deep-link analytics-friendly et testable.

- Validé le : 28-05-2026 — app-alexandrie (IA-v2.8 AC4)

---

<a id="pattern-ux-fiche-detail-immersive"></a>
## Pattern : Fiche détail — single-scroll immersif, méta-infos en tête, chip drill-down

- Objectif : structurer une fiche de contenu/produit/praticien/événement sans "rooms vides" ni dispersion des infos.
- Contexte : fiche détail mobile/web avec contenu de profondeur variable.
- Quand l'utiliser : fiche détail à contenu court ou partiellement livré.
- Quand l'éviter : fiche à forte profondeur réelle (chapitres + avis nombreux) où les tabs sont justifiés.

### Trois patterns indépendants

1. **Single-scroll vs tabs Udemy/Masterclass** : pour une fiche courte (pas de chapitres, pas d'avis livrés), préférer un single-scroll vertical. Les tabs créent des "rooms vides" qui sapent la crédibilité (onglet "Chapitres" vide, "Avis" avec un faux 5 étoiles). Réintégrer les sections en single-scroll est plus simple que remplir artificiellement des tabs.
2. **Méta-infos groupées en tête** : regrouper toutes les méta-infos dans un bloc dense entre le hero et le contenu (overline catégorie > titre H1 > InfoChips > ligne progression compacte). Évite la dispersion ; donne un signal fort sur "ce qu'est ce contenu" avant de plonger. La progression tient sur une ligne (icon + label + date), c'est une info légère.
3. **Chip cliquable drill-down** : plutôt qu'une section vide (avis sans backend, stats peu lues), exposer l'info en chip dans la zone méta (état neutre si vide : "☆ Aucun avis") qui devient l'entrée vers une page dédiée. Évite les empty states verbeux.

- Validé le : 29-05-2026 — app-alexandrie (ux-cleanup-7)

---

<a id="pattern-ux-fab-vs-sticky-bottom"></a>
## Pattern : Préférer le FAB étendu au sticky bottom plein-largeur sur écran à nav persistante

- Objectif : éviter le piège de positionnement à 3 couches synchronisées (sticky `bottom` + paddingBottom ScrollView + safeArea) du CTA sticky.
- Contexte : écran avec nav persistante (TabBar/BottomBar en `position: absolute, bottom: 0`) ET un CTA principal contextuel.
- Quand l'utiliser : écran à nav persistante avec CTA (commencer, reprendre, créer).
- Quand l'éviter : écran SANS nav persistante (modal, full-screen) où le sticky devient naturel ; ou CTA à label très long ; ou page de paiement validée maquette par maquette.

### Description

Un sticky bottom plein-largeur exige de re-synchroniser 3 hauteurs à chaque évolution de la nav, et un drift → le CTA chevauche la TabBar (bug observé sur device, invisible en tests Jest). Préférer un **FAB étendu Material 3** (icon + label, bottom-right) qui se positionne via UNE seule valeur (`bottom = NAV_HEIGHT + spacing + safeArea`) gérée par le composant lui-même, n'ajoute pas de surface visuelle redondante, et est immune aux évolutions de la nav.

Anti-pattern : `<View position="absolute" bottom={const}>` avec un Button plein-largeur — semble simple mais oblige à recalculer 3 hauteurs à chaque changement de nav.

- Validé le : 29-05-2026 — app-alexandrie (ux-cleanup-7, le sticky a généré ~3 cycles de bugs sur device)

---

<a id="pattern-ux-ligne-contexte-sous-filtres"></a>
## Pattern : Ligne de contexte sous les filtres de liste

- Objectif : permettre à l'utilisateur de comprendre instantanément ce qu'il regarde (combien, quel filtre) et pourquoi la liste est vide.
- Contexte : toute liste filtrée (annuaire, feed, bibliothèque).
- Quand l'utiliser : liste avec filtres et/ou recherche.
- Quand l'éviter : liste sans filtre ni recherche.

### Description

Afficher une ligne de contexte juste sous les filtres et au-dessus du premier résultat. Elle : compte les résultats (singulier/pluriel correct), mentionne le filtre actif ("Ma cohorte • 5 membres"), contextualise la query ("Aucun résultat pour « pnl »"), explicite le vide ("Aucun membre dans votre cohorte" plutôt qu'une chaîne générique), et ne s'affiche PAS pendant le 1er chargement (count=0 + isLoading) pour éviter le flash "Aucun X".

Implémentation type : helper pur `formatXxxContext({filter, count, query, isLoading}) → string` (testable à 100% en node) + composant léger en `textSecondary` 13px.

Anti-pattern : empty state global (centré, gros) sur une liste filtrée — il masque les filtres alors que l'utilisateur veut comprendre POURQUOI c'est vide.

- Validé le : 29-05-2026 — app-alexandrie (ux-cleanup-9)

---

<a id="pattern-ux-cta-toggle-differencie"></a>
## Pattern : CTA toggle différencié au-delà du libellé

- Objectif : rendre l'état d'un CTA toggle (Suivre/Suivi, Souscrire/Souscrit) perceptible au premier regard.
- Contexte : CTA qui bascule entre deux états (action / état "fait").
- Quand l'utiliser : tout bouton à état binaire persistant.
- Quand l'éviter : bouton d'action one-shot sans état.

### Description

Deux éléments visuels distincts au-delà du libellé :

- **État inactif (action disponible)** : ghost button (fond transparent, bordure + texte `colors.primary`, libellé verbe infinitif "Suivre").
- **État actif ("fait")** : filled tinted (fond `${colors.primary}1F` ≈ 12% d'alpha, bordure transparente, icône remplie alignée gauche, libellé participe passé "Suivi" — l'icône porte l'info, pas une coche dans le texte).

**Pourquoi `${color}1F` plutôt qu'`opacity: 0.12`** : `opacity` fade TOUT l'enfant (icône + label), `${color}1F` n'applique l'alpha qu'au background — icône et label gardent leur saturation pleine.

A11y obligatoire : `accessibilityState={{ selected: isActive }}` + `accessibilityLabel` explicitant état + action.

Anti-pattern : différencier UNIQUEMENT par le libellé (Suivre → Suivi ✓) — le ✓ Unicode est faible visuellement et inaccessible.

- Validé le : 29-05-2026 — app-alexandrie (ux-cleanup-9 AC3)

---

<a id="pattern-ux-wordings-inclusifs-i18n"></a>
## Pattern : Table i18n de wordings inclusifs

- Objectif : centraliser les wordings pour qu'ils soient auditables et inclusifs, et empêcher le composant d'inventer ses propres libellés.
- Contexte : app francophone avec wordings genrés potentiels (notifications, messages).
- Quand l'utiliser : tout domaine produisant des wordings adressés à l'utilisateur.
- Quand l'éviter : —

### Structure

Un fichier `i18n/<domain>.ts` par domaine exposant : un `Record<TypeEnum, string>` interne `WORDING_FALLBACK` (générique), une fonction `<domain>Wording(type, ctx?)` qui combine type + contexte, et un `.spec.ts` qui vérifie fallbacks, cas avec contexte, dégradation gracieuse, et la règle d'inclusivité via un garde-fou regex anti-régression (`expect(wording).not.toMatch(/mentionnée(?![\w·])/)`).

### Règles d'inclusivité française

1. **Point milieu `·e`** pour les participes : "mentionné·e", "invité·e".
2. **Nom commun neutre** quand possible : "abonné" plutôt que "follower".
3. **Passé composé impersonnel** sans acteur nommé : "Nouvelle réponse à votre fil" plutôt que "Vous avez été répondu".
4. **Nommer l'acteur quand on l'a** : "Bob a répondu à votre fil" (plus actionnable).

Anti-patterns : wording inline dans le composant (inaudit­able) ; wording dans le push payload backend sans miroir dans la table mobile (divergence lockscreen vs in-app) ; test "smoke" qui vérifie juste que le wording n'est pas vide (rate les régressions de genre).

- Validé le : 29-05-2026 — app-alexandrie

---

<a id="pattern-ux-etat-readonly-cacher-vs-griser"></a>
## Pattern : État read-only — cacher l'interactif plutôt que griser

- Objectif : éviter le grisage avec placeholder ("Action désactivée"), un anti-pattern d'invitation qui fait essayer puis échouer l'utilisateur.
- Contexte : élément interactif (composer DM, bouton "Acheter", formulaire) indisponible pour cause d'état métier (lecture seule, compte suspendu, plan inactif).
- Quand l'utiliser : indisponibilité durable liée à un état métier.
- Quand l'éviter : désactivation transitoire pendant un async court (préférer un loading).

### Description

Ne pas griser — **cacher** l'élément et afficher en remplacement un **bandeau neutre** qui explique l'état.

Pourquoi cacher est meilleur : pas d'invitation à essayer ; explicite > implicite (le bandeau explique POURQUOI) ; a11y (`accessibilityRole="alert"` annonce l'état au mount, un input `editable={false}` ne signale rien) ; visuel (1 zone au lieu de composer grisé + bandeau redondant).

Pattern de code : `{isReadOnly ? <ReadOnlyBanner message="..." /> : <Composer ... />}`. Ton neutre (`textSecondary` / `surfaceContainerLow`), pas `error` (réservé aux vraies erreurs réversibles).

Anti-patterns : placeholder "Envoi désactivé" dans un TextInput non éditable ; `opacity: 0.5` (reste cliquable visuellement) ; bandeau ET composer affichés ensemble.

- Validé le : 29-05-2026 — app-alexandrie (ux-cleanup-11 AC4)

---

<a id="pattern-ux-avatar-pastel-buckets-distincts"></a>
## Pattern : Avatar coloré par hash — buckets distincts du fallback

- Objectif : éviter qu'un utilisateur tombant dans un bucket trop neutre soit confondu avec un compte supprimé.
- Contexte : avatar coloré "hash du nom" avec un bucket fallback (compte supprimé/anonyme).
- Quand l'utiliser : avatars générés par hash.
- Quand l'éviter : avatars uploadés / sans fallback identitaire.

### Description

Ne mettre dans le pool hashable QUE des accents colorés (`primary`/`secondary`/`tertiary` + leurs containers). Le fallback (`outlineVariant`) reste réservé aux fallbacks identitaires (compte supprimé, handle vide).

Anti-pattern : inclure un token "surface" très clair (background-like) dans le pool — il ressemble au fallback grisé en light theme. Validation : tester visuellement les 8-12 tokens du pool sous light + dark ; retirer tout token proche du fallback.

- Validé le : 30-05-2026 — app-alexandrie (ux-cleanup-11 M1)

---

<a id="pattern-ux-audit-a11y-touch-targets"></a>
## Pattern : Audit a11y des touch targets mobile RN

- Objectif : garantir des cibles tactiles conformes (EAA 2025) sans linter a11y RN mainstream.
- Contexte : app mobile React Native / Expo avec composants interactifs denses.
- Quand l'utiliser : audit a11y ou story de polish touch targets.
- Quand l'éviter : —

### Cible et méthode

Cible : 44×44pt iOS (Apple HIG) / 48×48dp Android (Material). Méthode (grep + calcul, pas de linter) : grep tous les `Pressable`/`TouchableOpacity`/`onPress` ; pour chacun, taille effective = `max(width, iconSize + paddingH*2) × max(height, fontSize + paddingV*2)` + `hitSlop` ; marquer non conforme si une dimension < 44pt ; rapport ordonné par gravité.

### Décision hitSlop vs padding

| Choisir... | Quand... |
|---|---|
| `hitSlop` | Composant qui DOIT rester visuellement compact (chip dense, icône + label adjacent, pill en liste serrée), réutilisé multi-écrans (changer le padding casse les callers), pas de feedback visuel attendu au-delà de la cible (chevron, lien "Voir tout") |
| `padding` / `minHeight: 44` | Composant qui peut grossir sans gêne (CTA EmptyState, bouton primaire), feedback visuel attendu sur la zone élargie, composant isolé sans dépendance layout serrée |

Syntaxe : `hitSlop={{ top: N, bottom: N, left: M, right: M }}` — N pour atteindre exactement 44pt en hauteur ; `left/right` plus petits (4-8) si chips côte-à-côte pour éviter l'overlap. Limite acceptée : audit visuel + grep seul (cf. risque associé dans `ux/risques/general.md`).

- Validé le : 31-05-2026 — app-alexandrie (ux-cleanup-14)