PD-27 — Rétrospective¶

1. Contexte¶

2. Métriques¶

3. Learnings clés¶

• Délégation périmètre explicite : R6 (brute force protection) a été délégué à PD-26 car non observable côté backend. Cette délégation aurait dû être identifiée dès la spec.

• Livrer avec preuves de tests : L'absence de preuves d'exécution a bloqué le verdict initial.

• null vs undefined claims OIDC : Un claim peut être null (présent mais vide) ou undefined (absent). Utiliser != null pour les deux cas.

• Guards sync vs async : Vérifier la signature de canActivate() avant d'écrire les tests (expect(...).toThrow() vs expect(...).rejects.toThrow()).

4. Patterns applicables¶

Pattern existant : Architecture par délégation¶

La décision de ne pas manipuler les secrets MFA (TOTP seeds, QR codes) et de déléguer à l'IdP réduit la surface d'attaque.

Nouveau pattern : Validation claims OIDC null-safe¶

// BON
if (claims.acr != null) {
  // acr présent et non vide
}

// MAUVAIS
if (claims.acr !== undefined) {
  // Manque le cas acr = null
}

5. Signal CLAUDE.md¶

Priorité moyenne : Documenter la matrice de délégation inter-US.

### Délégation inter-US — Identifier dès la spec (2026-02-XX)

Les règles déléguées à l'IdP doivent être identifiées comme "non testables côté backend" dès la spécification.

**Format dans spec** :
| Règle | Responsabilité | US cible | Testable backend |
|-------|----------------|----------|------------------|
| R6 | IdP | PD-26 | Non |

6. Conclusion¶

PD-27 a implémenté la validation MFA basée sur les claims OIDC avec une architecture par délégation. Les principaux learnings concernent la gestion des valeurs null/undefined et la nécessité d'identifier les responsabilités inter-US dès la spécification. La validation croisée Claude/ChatGPT a été efficace pour détecter les écarts.

Rétrospective générée 2026-02-19 (Étape 10 batch auth-identity)