PD-172 — Clarifications PO (2026-04-25)¶

Quel est le problème ou le besoin utilisateur prioritaire ?¶

Pas d'incident réel survenu. Risque structurel critique lié à l'architecture ProbatioVault. Priorité réelle : protéger les endpoints critiques contre les abus automatisés et préserver la stabilité du système sous charge distribuée.

Scénarios prioritaires (ordre réel) : 1. Bruteforce / auth abuse — /auth/login, /auth/otp, /auth/refresh — Impact : sécurité + réputation + coût 2. Explosion de charge sur endpoints coûteux — /documents/upload, /exports, /proof/generate — Impact : saturation CPU/IO/coûts S3/latence globale 3. Rafales API (burst non contrôlé) — scripts/bots/intégrations mal conçues — Impact : dégradation QoS pour tous 4. Abus multi-tenant — un tenant monopolise la plateforme — Impact : rupture d'équité

Conclusion PO : le scénario critique V1 = protection auth + endpoints coûteux contre rafales automatisées.

Quels sont les critères de succès ?¶

Arbitrages PO : - Repli Redis down : VALIDÉ — auth → fail-closed, lecture → fail-open contrôlé, upload/export → fail-closed - Dimensions V1 : IP + user_id + tenant + route (tenant remonté en V1, API key en V2) - Headers quota : VALIDÉ — X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After (ne pas exposer logique interne) - Seuils dynamiques : V1 = statique au boot (config YAML/TS), reload dynamique en V2 - Logging 429 : hybride — logs individuels sur endpoints sensibles (auth), métriques agrégées sur endpoints bruyants

Y a-t-il des contraintes connues ?¶

• Redis : même instance, DB logique séparée (ex: db=2) — cohérence infra, isolation logique suffisante
• Budget latence : < 5 ms p99 par check rate limit — pas plus de 1 RTT Redis, idéalement Lua script atomique
• Whitelist/bypass ops : NON en V1 — trop dangereux si mal géré
• Script Redis atomique (Lua) : MUST-HAVE V1 — sinon race conditions et incohérence multi-instance
• Convention clé Redis : rate_limit:{route}:{dimension}:{identifier} — ex: rate_limit:/auth/login:ip:1.2.3.4

Quelles sont les priorités (must-have vs nice-to-have) ?¶

V1 MUST-HAVE : - Guard NestJS distribué Redis - Sliding window + burst - Clés IP + user + tenant + route - 429 + headers standard - Logs structurés + métriques Prometheus - Fail strategy (auth closed / lecture open / export closed) - Script Redis atomique (Lua)

V2 NICE-TO-HAVE : - Dashboard Grafana dédié - Daily guardrail - API key dimension - Config dynamique sans redeploy - Alerting automatique avancé - Whitelist ops - Quotas par plan / pricing