Aller au contenu

PD-106 — Expression de besoin : Ecran Settings (Profil, MFA, Sécurité, Compte)

1. Contexte

L'application mobile ProbatioVault (iOS, React Native / Expo SDK 54) dispose d'un écran ProfileScreen minimaliste et d'un SecuritySettingsScreen qui gère l'auto-lock et la biométrie. Le backend ProbatioVault expose déjà des endpoints d'authentification multi-facteur (MFA) via TOTP, avec un middleware dédié (auth-session-enricher.middleware).

Il manque un écran de paramètres complet permettant à l'utilisateur de gérer son profil, ses options de sécurité (MFA, mot de passe), et les actions critiques sur son compte (déconnexion, suppression).

Actuellement : - Aucune interface mobile pour configurer le MFA (l'utilisateur doit passer par un autre canal). - Pas de changement de mot de passe depuis l'app. - Pas de suppression de compte depuis l'app. - L'écran profil existant ne centralise pas ces fonctionnalités.

2. Objectifs principaux

Profil

  • L'utilisateur doit pouvoir consulter ses informations de profil (nom, email, avatar/initiales).
  • L'utilisateur doit pouvoir identifier visuellement son compte connecté.

MFA (TOTP)

  • L'utilisateur doit pouvoir visualiser l'état actuel de son MFA (activé/désactivé, méthode configurée).
  • L'utilisateur doit pouvoir activer le MFA TOTP depuis l'application mobile (affichage du QR code, saisie du code de vérification).
  • L'utilisateur doit pouvoir désactiver le MFA depuis l'application mobile (avec confirmation sécurisée).
  • L'utilisateur doit pouvoir consulter ses codes de récupération (avec avertissement sur la criticité).
  • L'utilisateur doit pouvoir régénérer ses codes de récupération (avec confirmation et invalidation des anciens codes).

Changement de mot de passe

  • L'utilisateur doit pouvoir changer son mot de passe depuis l'application (saisie ancien mot de passe + nouveau mot de passe + confirmation).

Déconnexion

  • L'utilisateur doit pouvoir se déconnecter de l'application (avec confirmation).

Suppression de compte

  • L'utilisateur doit pouvoir supprimer son compte depuis l'application (avec confirmation renforcée et ré-authentification).

Intégration

  • L'ensemble de ces fonctionnalités doit être accessible depuis un écran Settings unifié ou un parcours de navigation cohérent.

3. Non-objectifs (exclusions explicites)

  • Ne concerne pas la modification des endpoints backend existants (MFA, auth, profil).
  • Ne concerne pas l'ajout de nouvelles méthodes MFA (SMS, email, WebAuthn). Seul le TOTP est visé.
  • Ne concerne pas l'authentification biométrique (déjà gérée dans SecuritySettingsScreen).
  • Ne concerne pas le flux de login avec MFA (saisie du code TOTP au login). Il s'agit uniquement de la configuration du MFA.
  • Ne concerne pas la version Android de l'application.
  • Ne concerne pas l'édition du profil (changement de nom, d'email, d'avatar). L'écran est en lecture seule pour le profil.

4. Contraintes (juridiques, temporelles, organisationnelles)

  • Sécurité MFA : l'affichage du QR code TOTP et des codes de récupération sont des données extrêmement sensibles. Le secret TOTP ne doit jamais être stocké côté client après l'enrôlement. Les codes de récupération ne doivent être affichés qu'une seule fois après génération/régénération.
  • Ré-authentification : toute opération critique (activation/désactivation MFA, changement de mot de passe, suppression de compte) doit exiger une ré-authentification (mot de passe ou biométrie).
  • Suppression de compte : la suppression doit être irréversible, clairement signalée comme telle, et nécessiter une confirmation renforcée (saisie de texte de confirmation ou double validation).
  • Conformité : ProbatioVault est soumis à des exigences eIDAS et RGPD. Le droit à la suppression des données (droit à l'oubli RGPD art. 17) doit être respecté lors de la suppression de compte.
  • Cohérence UX : l'écran doit respecter le design system existant de l'application (cards, SettingRow, icônes Ionicons, palette de couleurs, modals bottom-sheet).
  • Stack technique : React Native, Expo SDK 54, TypeScript strict, i18n via react-i18next.
  • Déconnexion : la déconnexion doit invalider la session côté serveur, pas uniquement supprimer le token local.

5. Scénarios d'échec et résultats inacceptables

  • Inacceptable : le secret TOTP affiché dans le QR code est interceptable en clair dans les logs, le stockage local ou le trafic réseau.
  • Inacceptable : les codes de récupération restent accessibles après la première consultation (cache, screenshot non averti).
  • Inacceptable : un utilisateur peut désactiver le MFA ou supprimer son compte sans ré-authentification préalable.
  • Inacceptable : l'activation MFA échoue silencieusement sans message d'erreur exploitable.
  • Inacceptable : l'état MFA affiché dans l'app est désynchronisé de l'état réel côté serveur (stale state).
  • Inacceptable : la suppression de compte ne supprime pas les données côté serveur (violation RGPD).
  • Inacceptable : la déconnexion ne nettoie pas les données sensibles stockées localement (tokens, clés biométriques).
  • Inacceptable : le changement de mot de passe accepte un mot de passe faible sans avertissement.
  • Redouté : l'utilisateur active le TOTP mais ne sauvegarde pas ses codes de récupération, puis perd son dispositif.
  • Redouté : l'utilisateur supprime son compte par erreur suite à une interface ambiguë.

6. Tensions et conflits non résolus

  • UX vs Sécurité (MFA) : afficher le QR code TOTP est nécessaire pour l'enrôlement, mais c'est un secret critique. Tension entre facilité d'utilisation et sécurité.
  • Écran unique vs Navigation : faut-il tout mettre dans un seul écran Settings avec des sections, ou naviguer vers des sous-écrans (MfaSettings, ChangePassword, DeleteAccount) ? Un écran unique est plus direct, des sous-écrans permettent de mieux isoler les flux critiques.
  • Codes de récupération : faut-il forcer l'utilisateur à les copier/sauvegarder avant de quitter l'écran, ou simplement l'avertir ? Tension entre fluidité et prévention des pertes d'accès.
  • Ré-authentification : mot de passe seul, biométrie seule, ou les deux ? La biométrie est plus fluide mais moins forte pour une opération aussi critique que la suppression de compte.
  • Relation avec SecuritySettingsScreen : l'écran existant gère auto-lock et biométrie. Faut-il fusionner tout dans un seul Settings, ou garder SecuritySettings séparé et ajouter un Settings plus général au-dessus ?

7. Questions ouvertes

  • Quels sont les endpoints backend exacts pour la gestion MFA (activation TOTP, vérification, désactivation, codes de récupération) ?
  • Le backend retourne-t-il le secret TOTP en base32 ou une URI otpauth:// formatée ?
  • Existe-t-il déjà un service/hook côté app pour les appels API d'authentification ? Quel pattern (axios, fetch, react-query) ?
  • Le backend supporte-t-il la régénération des codes de récupération comme opération distincte ?
  • Quel endpoint backend pour le changement de mot de passe ? Quelles règles de complexité sont appliquées côté serveur ?
  • Quel endpoint backend pour la suppression de compte ? Quelle est la politique de rétention/purge des données ?
  • Quel endpoint backend pour le logout (invalidation de session serveur) ?
  • L'écran profil existant (ProfileScreen) doit-il être remplacé ou complété par ce nouvel écran ?
  • Quelles informations de profil sont disponibles via l'API (nom, email, date de création, rôle) ?