PD-238 — Retour d'Expérience (REX)¶
Date : 2026-02-06 Story : PD-238 - MFA Management Endpoints Domaine : auth-identity Epic : EPIC-182
Résumé¶
PD-238 a implémenté les endpoints backend de gestion MFA utilisateur, permettant à l'application iOS (PD-106) de consommer une API complète pour : - Consulter le statut MFA - Initialiser TOTP - Vérifier et activer TOTP - Désactiver MFA (avec ré-authentification) - Régénérer les codes de récupération
Métriques¶
| Métrique | Valeur |
|---|---|
| Durée totale | ~4 sessions |
| Nombre d'itérations gates | 2 (v1 → v2) |
| Tests ajoutés | ~50 |
| Tests totaux backend | 3884 |
| Fichiers modifiés | ~25 |
| Écarts corrigés | 8 (ECT-01 à ECT-06, OBS-01, ZO-01) |
Ce qui a bien fonctionné¶
Architecture¶
- Délégation à Keycloak : Le choix de déléguer la gestion MFA à Keycloak Admin API a simplifié l'implémentation et évité le stockage de secrets côté backend.
- Pattern Guards/Filters : L'utilisation de guards (
OidcJwtAuthGuard,ReauthTokenGuard,MfaRateLimitGuard) et de filters (MfaExceptionFilter) a permis une séparation claire des responsabilités. - Reauth Token : Le mécanisme de ré-authentification avec token JWT 5min a bien sécurisé les opérations sensibles.
Processus¶
- Workflow gouverné : Les gates ont détecté des écarts importants (fail-open Redis, absence de rate limiting sur reauth).
- Validation croisée : Les reviews ChatGPT ont identifié des points que les outils automatisés n'auraient pas détectés.
Ce qui peut être amélioré¶
Processus¶
| ID | Problème | Action corrective | Priorité |
|---|---|---|---|
| REX-01 | Oubli du cycle d'acceptabilité complet après corrections | Règle ajoutée au CLAUDE.md : reviews LLM obligatoires après toute modification | FAIT |
| REX-02 | Tests avec mockResolvedValue sur méthode synchrone | Attention accrue aux signatures de méthodes lors des mocks | LEÇON |
| REX-03 | Warnings ESLint initialement considérés "hors périmètre" | Tous les warnings doivent être traités, pas seulement les erreurs | LEÇON |
Technique¶
| ID | Problème | Action corrective | Priorité |
|---|---|---|---|
| REX-04 | Rate limiting fail-open initial | Pattern fail-closed avec fallback in-memory documenté | FAIT |
| REX-05 | Messages d'erreur permettant énumération utilisateurs | Unification systématique en INVALID_CREDENTIALS | FAIT |
| REX-06 | constantTimeEqual custom vs crypto.timingSafeEqual | Toujours préférer les primitives natives Node.js | LEÇON |
Leçons apprises¶
1. Cycle d'acceptabilité obligatoire¶
Après TOUTE modification du code (même mineure), le cycle complet d'acceptabilité doit être relancé : 1. Reviews automatisées (lint, format, types, tests) 2. Reviews LLM (code, tests, sécurité si applicable)
Ne jamais considérer l'acceptabilité complète après les seuls outils automatisés.
2. Fail-closed par défaut¶
Pour tout mécanisme de sécurité (rate limiting, validation, auth), le comportement par défaut en cas d'erreur doit être le blocage, pas le passage.
3. Primitives natives¶
Préférer les fonctions cryptographiques natives (crypto.timingSafeEqual, crypto.randomBytes) aux implémentations custom.
4. Anti-énumération¶
Les messages d'erreur d'authentification doivent être identiques quel que soit le type d'échec (utilisateur inexistant, mot de passe invalide, etc.).
Améliorations du workflow¶
Le CLAUDE.md a été mis à jour avec : - Règle explicite sur le cycle d'acceptabilité après modification - Détail des deux phases obligatoires (automatisées + LLM) - Rappel que Claude ne peut pas valider son propre code
Prochaines étapes¶
- PD-106 : Écran Settings iOS consommant ces endpoints
- Documentation API : Swagger généré automatiquement via décorateurs
- Tests E2E : À ajouter dans le pipeline CI avec Keycloak de test
REX produit par Claude, étape 9 du workflow de gouvernance PD-238.