PD-99 — Retour d'expérience (REX)¶
1. Résumé exécutif¶
Objectif initial : Implémenter l'écran de connexion utilisateur iOS avec authentification SRP-6a, connexion facilitée par biométrie, et messages d'erreur non inférentiels.
Résultat obtenu : Implémentation complète après correction de 4 écarts identifiés lors de la revue d'acceptabilité initiale.
Verdict d'acceptabilité : - Revue initiale (2026-01-20) : ⛔ REFUSÉ — 4 écarts (E-01, E-02, E-03, E-04) - Après corrections : ✅ Tous les écarts résolus
État des tests contractuels : - 72 tests PD-99 exécutés (63 passed, 9 skipped E2E) - 31 tests TC-* formels avec traçabilité vers PD-99-tests.md - Couverture : TC-NOM-01 à TC-NOM-04, TC-ERR-01 à TC-ERR-03, TC-INV-01/02/04/05/07/08A/08B/09/11, TC-CA-09, TC-NR-01/02, TC-NEG-01 à TC-NEG-03
2. Points fluides¶
| Aspect | Observation |
|---|---|
| Spécification des invariants | INV-01 à INV-11 clairement définis avec critères d'acceptation testables (CA-01 à CA-09) |
| Textes exacts contractuels | Texte du disclaimer (INV-11) et du message d'erreur (CA-09) explicitement spécifiés |
| Architecture SRP-6a | Plan d'implémentation détaillé avec flux techniques (§2) et mapping invariants/mécanismes (§3) |
| Composants UI réutilisables | PasswordDisclaimer et AuthErrorMessage isolés et testables unitairement |
| Intégration biometric.ts | Service centralisé avec clés pv_biometric_* comme source de vérité |
3. Points difficiles¶
| Difficulté | Manifestation |
|---|---|
| Désalignement des clés biométriques | useBiometric.ts utilisait des clés biometric_* tandis que biometric.ts et LoginScreen utilisaient pv_biometric_* |
| Observable SRP-6a non implémenté | Header X-Auth-Protocol prévu au plan (§5) mais absent de l'implémentation initiale |
| Chemins d'authentification multiples | Mode démo/local coexistait avec SRP-6a, violant INV-01 |
| Exécution des tests | npm test échouait initialement (watchman "Operation not permitted") |
| Tests sans IDs formels | Tests existants non nommés selon les TC-* de PD-99-tests.md |
4. Hypothèses révélées tardivement¶
| Hypothèse implicite | Découverte | Impact |
|---|---|---|
| Un seul système de clés biométriques | L'écart E-02 a révélé deux systèmes incompatibles (biometric_* vs pv_biometric_*) | Refactoring de useBiometric.ts |
| Les tests existants suffisent pour la traçabilité | L'auditeur exigeait des IDs TC-* explicites selon PD-99-tests.md | Création de PD99.TC.formal.test.tsx |
| L'observable SRP est implicite | INV-01 exige un "élément observable contractuel" explicite | Ajout du header X-Auth-Protocol: SRP-6a-v1 |
5. Invariants complexes¶
| Invariant | Complexité | TC-* associés |
|---|---|---|
| INV-01 (SRP-6a obligatoire) | Nécessite un observable contractuel vérifiable sans accès au code | TC-INV-01, TC-NOM-01 |
| INV-08 (biométrie désactivable globalement ET par appareil) | Deux niveaux de gestion avec persistance SecureStore par device_id | TC-INV-08A, TC-INV-08B, TC-NOM-03, TC-NOM-04 |
| INV-09 (messages non inférentiels) | Tous les cas d'erreur doivent produire le même texte exact | TC-INV-09, TC-ERR-01, TC-ERR-02, TC-NEG-01 à TC-NEG-03 |
6. Dette technique¶
| Dette | Description | Statut |
|---|---|---|
| Mode démo supprimé | Le mode démo avec auth locale a été supprimé pour conformité INV-01 | Résolu |
| Tests E2E skipped | 9 tests E2E nécessitent un environnement avec appareil physique | Accepté |
| Refresh token | Non implémenté (JWT unique avec expiration) | Hors scope PD-99 |
| Rotation credentials biométrie | Non planifiée | Future US |
7. Risques résiduels¶
| Risque | Probabilité | Impact | Mitigation actuelle |
|---|---|---|---|
| Régression sur textes exacts (INV-11, CA-09) | Moyenne | Élevé | Snapshots TC-NR-01, TC-NR-02 |
| Désalignement futur useBiometric/biometric.ts | Faible | Moyen | Commentaires "PD-99 E-02 FIX" dans le code |
| Tests E2E biométrie non exécutés en CI | Moyenne | Moyen | Tests manuels requis avant release |
| Modification du header X-Auth-Protocol | Faible | Élevé | Test TC-INV-01 vérifie sa présence |
8. Améliorations de processus¶
| Suggestion | Justification |
|---|---|
| Exiger les IDs TC-* dès l'implémentation | L'écart E-03 aurait été évité si les tests avaient été nommés selon PD-99-tests.md dès le départ |
| Inclure les observables contractuels dans le plan | Le header X-Auth-Protocol était mentionné au §5 mais non tracé comme livrable obligatoire |
| Vérifier l'unicité des clés de stockage | Un inventaire des clés SecureStore aurait révélé le doublon biometric_* / pv_biometric_* |
| Automatiser la vérification des textes exacts | Les constantes PASSWORD_DISCLAIMER et AUTH_ERROR_MESSAGE devraient être validées par des tests de régression dès leur création |
9. Enseignements clés¶
-
Un observable contractuel doit être explicite et vérifiable — L'ajout du header
X-Auth-Protocol: SRP-6a-v1permet d'attester l'usage de SRP-6a sans accès au code source ni aux secrets. -
Source de vérité unique pour les clés de stockage — Deux modules (
useBiometric.tsetbiometric.ts) ne doivent pas gérer indépendamment les mêmes données persistantes. -
Traçabilité TC-* obligatoire pour l'acceptabilité — Les tests doivent porter les identifiants exacts de PD-99-tests.md pour démontrer la couverture contractuelle.
-
Les chemins alternatifs violent les invariants "DOIT" — Un mode démo ou fallback local contredit un invariant stipulant "Toute authentification DOIT utiliser SRP-6a".
-
La revue d'acceptabilité est une étape de validation, pas de découverte — Les 4 écarts auraient pu être détectés avant soumission par une auto-revue contre PD-99-tests.md.
Document généré le 2026-01-24 — Version post-corrections E-01/E-02/E-03/E-04