PD-106 — Plan d'implémentation¶

1. Découpage en composants¶

1.1 Nouveaux composants¶

1.2 Composants existants modifiés¶

1.3 Architecture navigation PD-106¶

Home (headerRight: ProfileAvatar → Settings)
  └─ Settings (profil + menu)
       ├─ MfaSettings (état MFA + actions)
       │    └─ MfaEnroll (flux activation TOTP)
       ├─ ChangePassword (formulaire)
       ├─ SecuritySettings (existant PD-174, auto-lock/biométrie)
       └─ DeleteAccount (flux suppression)

La navigation vers un écran hors du parcours Settings invalide la re-authentification en cours (INV-106-05, TC-NOM-12).

2. Flux techniques¶

2.1 F-106-01 — Accès Settings et consultation profil¶

1. Utilisateur tape sur ProfileAvatar → navigate("Settings")
2. SettingsScreen.mount()
   → useSettings().loadProfile() → GET /user/profile → {name, email, avatar?}
   → useSettings().loadMfaState() → GET /user/mfa/status → {active, method}
3. Si loadMfaState() échoue → état "inconnu", actions MFA bloquées
4. Render: profil (nom, email, avatar/initiales) en lecture seule + menu

2.2 F-106-02 — Activation MFA TOTP¶

1. SettingsScreen → MfaSettings (état MFA affiché)
2. Utilisateur appuie "Activer MFA"
3. ReauthModal s'ouvre → saisie mot de passe
   → POST /auth/reauth → validation serveur → timestamp re-auth mémorisé
4. Si re-auth OK → navigate("MfaEnroll")
5. MfaEnrollScreen.mount()
   → POST /user/mfa/totp/init → {secret, otpauth_uri, qr_code_data_url}
   → Afficher QR code (Image base64) + secret texte
6. Utilisateur saisit code TOTP dans TextInput
7. POST /user/mfa/totp/verify {code} → 200 {recovery_codes: string[]}
   → Si succès: afficher RecoveryCodesDisplay (affichage unique, avertissement)
   → Reload état MFA serveur
   → Si échec: ERR-106-MFA-CODE-INVALID, nouvelle tentative
8. Quitter MfaEnrollScreen → recovery_codes purgés de la mémoire React

2.3 F-106-03 — Consultation / Régénération codes de récupération¶

1. MfaSettingsScreen → section "Codes de récupération"
2. Si pas d'affichage unique en cours → message "régénération nécessaire"
3. Utilisateur appuie "Régénérer"
   → ConfirmationModal (confirmation explicite)
   → ReauthModal (re-authentification)
4. POST /user/mfa/recovery/regenerate → {recovery_codes: string[]}
   → Si succès: RecoveryCodesDisplay (affichage unique)
   → Anciens codes invalidés (serveur)
5. Fermeture RecoveryCodesDisplay → codes purgés de la mémoire

2.4 F-106-04 — Désactivation MFA¶

1. MfaSettingsScreen → "Désactiver MFA"
2. ConfirmationModal (confirmation explicite)
3. ReauthModal (re-authentification)
4. POST /user/mfa/disable → 200
   → Si succès: état MFA → "désactivé", reload serveur
   → Si échec: ERR-106-MFA-DISABLE-DENIED

2.5 F-106-05 — Changement de mot de passe¶

1. Settings → navigate("ChangePassword")
2. Formulaire: ancien mdp, nouveau mdp, confirmation
3. Validation locale: confirmation === nouveau (sinon ERR-106-PWD-CONFIRM-MISMATCH)
4. ReauthModal → re-authentification
5. POST /user/password/change {old_password, new_password}
   → Si succès: session invalidée, clearAllOnLogout(), navigate("Login")
   → Si échec: ERR-106-PWD-POLICY avec motif serveur exploitable

2.6 F-106-06 — Déconnexion¶

1. Settings → "Se déconnecter"
2. ConfirmationModal (confirmation explicite)
3. POST /auth/logout → invalidation session serveur
   → Si succès: clearAllOnLogout(), navigation.reset → Login
   → Si échec réseau: ERR-106-LOGOUT-FAILED
     → clearAllOnLogout() quand même (fallback dégradation gracieuse)
     → navigation.reset → Login
     → Message explicite (risque session zombie)

2.7 F-106-07 — Suppression de compte¶

1. Settings → navigate("DeleteAccount")
2. Avertissement d'irréversibilité
3. Confirmation renforcée (étape 1 : saisir "SUPPRIMER" + bouton)
4. Confirmation finale (étape 2 : dialog "Êtes-vous sûr ?")
5. ReauthModal → re-authentification
6. DELETE /user/account → 200
   → Si succès: clearAllOnLogout(), navigation.reset → Login
   → Si échec: ERR-106-DELETE-FAILED, compte non supprimé

2bis. Diagrammes Mermaid¶

2bis.1 Graphe de dépendances des composants¶

graph TD
    subgraph Screens
        SS[SettingsScreen]
        MFS[MfaSettingsScreen]
        MES[MfaEnrollScreen]
        CPS[ChangePasswordScreen]
        DAS[DeleteAccountScreen]
    end

    subgraph Components
        RM[ReauthModal]
        RCD[RecoveryCodesDisplay]
        CM[ConfirmationModal]
    end

    subgraph Hooks
        uM[useMfa]
        uR[useReauth]
        uS[useSettings]
        uA[useAuth]
    end

    subgraph Services
        sAPI[settingsApi]
    end

    subgraph Navigation
        AN[AppNavigator]
        PA[ProfileAvatar]
    end

    subgraph i18n
        I18N_MFA[mfa.json]
        I18N_SET[settings.json]
    end

    PA -->|navigate| AN
    AN --> SS
    AN --> MFS
    AN --> MES
    AN --> CPS
    AN --> DAS

    SS --> uS
    SS --> uR
    SS --> RM
    SS --> CM

    MFS --> uM
    MFS --> uR
    MFS --> RM
    MFS --> CM
    MFS --> RCD

    MES --> uM
    MES --> RCD

    CPS --> uR
    CPS --> RM

    DAS --> uR
    DAS --> RM
    DAS --> CM

    uM --> sAPI
    uS --> sAPI
    uR --> sAPI
    uA --> sAPI

    SS --> I18N_SET
    MFS --> I18N_MFA
    MES --> I18N_MFA
    CPS --> I18N_SET
    DAS --> I18N_SET

2bis.2 Diagramme de séquence — Activation MFA TOTP (F-106-02)¶

sequenceDiagram
    actor U as Utilisateur
    participant SS as SettingsScreen
    participant MFS as MfaSettingsScreen
    participant RM as ReauthModal
    participant uR as useReauth
    participant MES as MfaEnrollScreen
    participant uM as useMfa
    participant API as settingsApi
    participant BE as Backend

    U->>SS: Tap "MFA"
    SS->>MFS: navigate("MfaSettings")
    U->>MFS: Tap "Activer MFA"
    MFS->>RM: Ouvrir modal re-auth
    U->>RM: Saisie mot de passe
    RM->>uR: requireReauth(password)
    uR->>API: POST /auth/reauth
    API->>BE: Vérification mot de passe
    BE-->>API: 200 OK
    API-->>uR: Re-auth validée
    uR-->>RM: Succès (timestamp mémorisé)
    RM-->>MFS: Fermer modal
    MFS->>MES: navigate("MfaEnroll")
    MES->>uM: initTotp()
    uM->>API: POST /user/mfa/totp/init
    API->>BE: Génération secret TOTP
    BE-->>API: {secret, otpauth_uri, qr_code_data_url}
    API-->>uM: Données TOTP
    uM-->>MES: Afficher QR code + secret
    U->>MES: Saisie code TOTP
    MES->>uM: verifyTotp(code)
    uM->>API: POST /user/mfa/totp/verify {code}
    API->>BE: Vérification code
    BE-->>API: 200 {recovery_codes}
    API-->>uM: Codes de récupération
    uM-->>MES: Afficher RecoveryCodesDisplay
    Note over MES: Codes en useState uniquement<br/>Purgés au unmount (INV-106-08)
    U->>MES: Fermer / Retour
    MES->>MES: unmount → purge secrets mémoire

2bis.3 Diagramme de séquence — Suppression de compte (F-106-07)¶

sequenceDiagram
    actor U as Utilisateur
    participant SS as SettingsScreen
    participant DAS as DeleteAccountScreen
    participant CM as ConfirmationModal
    participant RM as ReauthModal
    participant uR as useReauth
    participant uA as useAuth
    participant API as settingsApi
    participant BE as Backend

    U->>SS: Tap "Supprimer mon compte"
    SS->>DAS: navigate("DeleteAccount")
    DAS->>DAS: Afficher avertissement irréversibilité
    U->>DAS: Saisir "SUPPRIMER" (étape 1)
    DAS->>CM: Confirmation finale (étape 2)
    U->>CM: Confirmer
    CM-->>DAS: Confirmé
    DAS->>RM: Ouvrir modal re-auth
    U->>RM: Saisie mot de passe
    RM->>uR: requireReauth(password)
    uR->>API: POST /auth/reauth
    API->>BE: Vérification
    BE-->>API: 200 OK
    API-->>uR: Re-auth validée
    uR-->>RM: Succès
    RM-->>DAS: Fermer modal
    DAS->>uR: consume()
    DAS->>API: DELETE /user/account
    API->>BE: Suppression compte
    BE-->>API: 200 OK
    API-->>DAS: Succès
    DAS->>uA: clearAllOnLogout()
    Note over uA: SecureStore + AsyncStorage<br/>+ Zustand vidés (INV-106-13)
    DAS->>DAS: navigation.reset → Login

3. Mapping invariants → mécanismes¶

4. Mapping critères d'acceptation → mécanismes¶

5. Mapping tests (TC-*) → mécanismes + observables¶

6. Gestion des erreurs¶

6.1 Pattern uniforme¶

Chaque opération critique suit le pattern :

try {
  // Appel API
  const result = await settingsApi.operation();
  if (!result.success) {
    Alert.alert(t(`errors.${result.code}`), result.error);
    return;
  }
  // Succès
} catch (error) {
  // Erreur réseau/inattendue
  Alert.alert(t("errors.network"), t("errors.networkMessage"));
}

6.2 Mapping codes erreur → comportement¶

6.3 Intercepteur 401 global¶

L'intercepteur API existant dans api.ts sera enrichi : si un appel retourne 401 sur les endpoints PD-106, déclencher clearAllOnLogout() + navigation vers Login avec message ERR-106-SESSION-EXPIRED.

7. Impacts sécurité¶

7.1 Secrets TOTP (INV-106-08)¶

• Mécanisme : Le secret TOTP et l'URI otpauth reçus de /user/mfa/totp/init sont stockés uniquement dans un useState de MfaEnrollScreen. Au unmount du composant (navigation arrière ou fin de flux), les valeurs sont purgées automatiquement par React.
• Interdit : Aucun SecureStore.setItemAsync(), AsyncStorage.setItem(), ou console.log() ne doit contenir le secret TOTP ou les codes de récupération.
• Vérification : TC-INV-01 avec valeurs sentinelles.

7.2 Codes de récupération (INV-106-09)¶

• Mécanisme : RecoveryCodesDisplay reçoit les codes en props. L'état freshCodes est un useState dans useMfa. Toute navigation hors composant purge cet état. Aucune persistance.
• Avertissement : Texte de criticité obligatoire affiché au-dessus des codes.

7.3 Re-authentification (INV-106-05, INV-106-06)¶

• Mécanisme : useReauth() expose {requireReauth, isReauthValid, consume}.
• requireReauth() : ouvre ReauthModal, POST /auth/reauth avec mot de passe.
• isReauthValid() : vérifie Date.now() - reauthTimestamp < 5 * 60 * 1000.
• consume() : invalide la re-auth après utilisation (one-time).
• Listener navigation : navigation.addListener("blur") sur les écrans Settings invalide la re-auth.
• Risque : Le TTL est évalué côté client (contrainte temporelle évaluée par le serveur selon spec). Le serveur re-vérifie au moment de l'opération critique.

7.4 Nettoyage local (INV-106-13)¶

• Mécanisme : clearAllOnLogout() existant (PD-174) efface SecureStore + AsyncStorage + mémoire Zustand. Réutilisé pour logout, suppression compte, changement mdp.
• Extension : Vérifier que les tokens JWT (accessToken, refreshToken) sont bien dans le périmètre de clearAllOnLogout().

7.5 Confirmation renforcée (INV-106-14)¶

• Mécanisme : DeleteAccountScreen implémente 2 étapes séquentielles :
• Saisie du texte "SUPPRIMER" (ou "DELETE" en anglais) dans un TextInput.
• Dialog de confirmation finale (Alert.alert avec bouton destructif).
• Les 2 étapes doivent être validées dans le même flux ; toute sortie réinitialise le processus.

7.6 Journalisation¶

• Aucun secret (TOTP, codes de récupération, mot de passe) ne doit apparaître dans console.log(), console.error(), ou tout autre mécanisme de log.
• Les logs d'erreur ne contiennent que le code erreur, pas le payload.

8. Hypothèses techniques¶

9. Points de vigilance (risques, dette, pièges)¶

9.1 Risques¶

1. Endpoints backend non encore implémentés : La plupart des endpoints PD-106 (MFA TOTP init/verify/disable, recovery codes, reauth, password change, delete account) ne sont pas visibles dans le codebase backend actuel. Le middleware MFA existe mais les routes d'administration MFA sont absentes. Il faudra coordonner avec l'équipe backend ou créer un PD dédié.

2. Re-auth côté client vs serveur : Le TTL 5 min est vérifié côté client ET côté serveur (spec : "cette borne temporelle est évaluée par le serveur"). Si le serveur re-valide indépendamment, le client peut afficher un refus tardif. Prévoir un message exploitable pour ce cas.

3. QR code TOTP : Aucune librairie QR code n'est actuellement dans le projet. Il faudra ajouter react-native-qrcode-svg ou équivalent. Alternative : le backend fournit un qr_code_data_url (base64 PNG).

4. Navigation invalidation : L'invalidation de re-auth sur navigation hors flux repose sur navigation.addListener("blur"). Ce mécanisme doit couvrir le cas où l'utilisateur utilise le swipe-back iOS ou le bouton hardware.

9.2 Dette technique¶

1. ProfileScreen existant : L'écran actuel affiche un profil statique (t("defaultUserName")). PD-106 le remplace par des données serveur réelles. La transition doit être propre.

2. Logout existant : Le logout actuel dans ProfileScreen ne fait que clearAllOnLogout() sans appel serveur. PD-106 enrichit ce comportement (INV-106-13).

3. Types RootStackParamList : L'ajout de 5 nouvelles routes nécessite une extension propre du typage.

9.3 Pièges¶

1. Affichage unique codes : Ne pas utiliser un state global (Zustand) pour les codes de récupération — cela créerait une persistance mémoire au-delà du composant.

2. React Navigation state : Lors d'un navigation.reset() après logout/suppression, vérifier que les écrans Settings sont bien dépilés (pas de fuite de composant avec secrets en mémoire).

3. Double confirmation renforcée : La spec exige "validation initiale puis confirmation finale" (TC-NOM-08). Ce sont bien 2 étapes distinctes, pas 2 clics sur le même bouton.

10. Hors périmètre¶

• Modification des endpoints backend existants (H-106-01 à H-106-10 : les endpoints sont supposés disponibles).
• Nouvelles méthodes MFA (SMS, email, WebAuthn).
• Flux de login MFA (saisie TOTP à la connexion).
• Édition du profil (nom, email, avatar).
• Biométrie et auto-lock (déjà gérés par PD-174, SecuritySettingsScreen reste inchangé).
• Android.
• Preuve RGPD art. 17 complète (INV-106-18, artefacts backend).
• Création des endpoints backend (PD séparé à planifier).