PD-17 — Rétrospective¶
1. Contexte¶
| Champ | Valeur |
|---|---|
| Story ID | PD-17 |
| Titre | Extension probatoire journal PD-37 |
| Domaine | backend-core |
| Projet | backend |
| Date complétion | 2025-12-XX |
| Verdict | ACCEPTÉ |
2. Métriques¶
| Métrique | Valeur |
|---|---|
| Tests unitaires | 56 |
| Lignes de code | 667 |
| Écarts corrigés | E-01 (BLOQUANT), E-02 (MAJEUR) |
3. Learnings clés¶
-
Contre-mesures ≠ flux métier : PD-17 avait dblink prohibition et pg_notify, mais pas le cœur fonctionnel (ALLOW/DENY). Les contre-mesures de sécurité ne remplacent pas les flux métier.
-
Taxonomie spec à challenger : Les codes métier (
ACL_DENY) sont moins universels que les codes HTTP (FORBIDDEN). La taxonomie doit être validée tôt avec les équipes API/front. -
Pattern Guard+Interceptor : Le Guard capture le contexte avant, l'Interceptor log après. Pattern adapté au logging déclaratif.
-
Réutilisation mocks PD-37 : 56 tests en < 2h grâce aux patterns de mock établis par PD-37.
4. Patterns applicables¶
Pattern existant : Primauté PD-37¶
Toute extension du journal d'audit doit respecter l'invariant PD-37 : aucune modification de AuditLog entity ni des colonnes signées.
Nouveau pattern : Audit déclaratif Guard+Interceptor¶
Pour le logging d'accès (ALLOW/DENY) : 1. @AuditedResource() decorator pour marquer les endpoints 2. Guard capture le contexte avant l'exécution 3. Interceptor log après l'exécution (succès ou exception)
5. Signal CLAUDE.md¶
Priorité moyenne : Documenter le pattern Guard+Interceptor pour l'audit.
Priorité basse : Documenter l'importance de valider la taxonomie des codes d'erreur avec les équipes front.
6. Conclusion¶
PD-17 a réussi après correction de deux écarts critiques liés aux flux ALLOW/DENY manquants. La réutilisation des patterns de mock PD-37 a accéléré le développement. Le mode strict (accès refusé si HSM down) n'a pas été implémenté, privilégiant la disponibilité via queue fallback.
Rétrospective générée 2026-02-19 (Étape 10 batch backend-core)