_Assistant_Lead_Tech/knowledge/ux/risques/general.md

---

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.

---

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)

---

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)

---

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)

---

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)

---

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)