---
title: UX — Risques & vigilance : Général
domain: ux
bucket: risques
tags: [mobile, navigation, handler, wording, tokens, a11y]
applies_to: [design, implementation, review]
severity: medium
validated_on: 2026-06-25
source_projects: [app-alexandrie]
---

# UX — Risques & vigilance : Général

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

---

<a id="risque-ux-back-button-dans-scrollview"></a>
## Bouton retour placé à l'intérieur du ScrollView

### Risques

- Sur une app mobile RN/Expo avec une TopBar globale sans back natif, un bouton retour ajouté localement dans le `<ScrollView>` disparaît dès que l'utilisateur défile
- Sur une page critique (gestion d'abonnement, résiliation, support), perdre l'accès au retour pendant le scroll est un piège UX direct

### Symptômes

- Le bouton retour est le premier enfant du contenu scrollable et défile avec lui ; il devient inaccessible plus bas dans une page longue

### Bonnes pratiques / mitigations

- Tout bouton retour local doit vivre **hors du ScrollView** : header local sticky en `<View>` parent (flex:1) + ScrollView frère.
- Stop conditions : ne PAS doubler `insets.top` (le header le consomme → `contentInset.top = 0`) ; ne PAS placer le bouton dans `contentContainerStyle`. Si l'app utilise `<Stack.Screen>` Expo Router avec header natif, préférer `headerBackVisible: true`.
- Filet de test : test statique vérifiant qu'un fichier avec `handleBack` ne place pas le `<Pressable accessibilityLabel="Retour">` dans un `<ScrollView>`.

- Contexte technique : RN/Expo + TopBar globale — app-alexandrie 28-05-2026 (ux-cleanup-2)

---

<a id="risque-ux-bouton-sans-handler-hors-scope"></a>
## Bouton/lien sans handler laissé dans l'UI ("hors scope")

### Risques

- Un bouton survit dans l'UI sans `onPress` (résidu de template ou de dépendance retirée) : il tapote sans rien faire → boucle de frustration, l'utilisateur conclut que l'app est cassée et abandonne (grave sur le flow auth, critique pour l'acquisition)
- "Hors scope" utilisé comme argument pour laisser passer → dérive de dette story après story

### Symptômes

- `<TouchableOpacity>` / `<Pressable>` visible sans prop `onPress` (ex. bouton "Facebook" sans OAuth côté API)

### Bonnes pratiques / mitigations

- **Règle** : tout bouton/lien visible doit avoir un `onPress` qui fait quelque chose. Si la feature n'est pas livrée : supprimer le bouton (défaut) ; OU le mettre derrière un feature flag interne ; OU afficher un toast/modal "Bientôt disponible".
- Garde-fou review : grep `<TouchableOpacity`/`<Pressable` sans `onPress=` → finding HIGH. "Hors scope" n'est jamais un permis : un bouton mort sur un écran qu'on édite est dans le scope.

- Contexte technique : RN/Expo — app-alexandrie 29-05-2026 (ux-cleanup-5, login.tsx)

---

<a id="risque-ux-wording-divergent-cross-ecran"></a>
## Wording divergent cross-écran pour le même état métier

### Risques

- Deux écrans/composants affichent le même état métier (`NOT_STARTED`, `OUT_OF_STOCK`) avec des libellés différents, souvent parce que livrés par des stories distinctes
- L'utilisateur traverse les écrans et voit deux mots pour le même état → confusion ; ne casse aucun test, dette qui s'accumule en silence

### Symptômes

- `CourseListItem` affiche "Nouveau" pour `NOT_STARTED`, `ProgressionInline` affiche "Pas encore commencé" pour le même état

### Bonnes pratiques / mitigations

- Centraliser le mapping état → libellé dans une seule fonction pure exportée (`statusLabel(state) => string`) consommée par tous les écrans.
- Review : grep les libellés de status sur les écrans du domaine ; > 1 wording par état = finding MEDIUM.
- Préférer les libellés courts et positifs ("Nouveau" > "Pas encore commencé").

- Contexte technique : RN/Expo — app-alexandrie 29-05-2026 (ux-cleanup-6/7)

---

<a id="risque-ux-regle-token-sans-detection"></a>
## Règle d'usage de token sans stratégie de détection

### Risques

- Un token décoratif (`outlineVariant` MD3 marqué "ne pas utiliser pour des séparations fonctionnelles") continue d'être utilisé pour des bordures fonctionnelles
- La règle reste écrite dans le README mais inappliquée → divergence README vs code

### Symptômes

- Callsites résiduels utilisant le token décoratif en `borderColor`/`borderTopColor` malgré la règle documentée

### Bonnes pratiques / mitigations

- **Une règle d'usage de token doit être assortie d'une stratégie de détection** : (1) lint custom qui flag le token dans une prop bordure/couleur ; (2) audit récurrent (CI cron qui liste les usages) ; (3) renommer le token (`outlineDecorative` rend l'intention explicite).
- Le coût "écrire la règle" est ~10 min, le coût "détecter les violations" est récurrent — investir dans la détection automatique.

- Contexte technique : design tokens MD3 — app-alexandrie 30-05-2026 (ux-cleanup-8/11)

---

<a id="risque-ux-touch-target-padding-composant-partage"></a>
## Augmenter le padding d'un composant réutilisé multi-écrans (touch targets)

### Risques

- Élargir un touch target en augmentant le `padding` d'un composant réutilisé multi-écrans casse le layout des callers (liste serrée, ligne d'icônes header avec gap fixe)

### Symptômes

- Une cible tactile passe sous 44pt ; la corriger par `padding` change la taille visuelle et décale les callers

### Bonnes pratiques / mitigations

- Pour un composant réutilisé, préférer `hitSlop` au `padding` : seul effet = zone tap étendue, taille visuelle inchangée (cf. pattern d'audit dans `ux/patterns/general.md`).

- Contexte technique : RN/Expo a11y — app-alexandrie 31-05-2026 (ux-cleanup-14)