PD-35 — Acceptabilité¶
📚 Navigation User Story
| Document | | | ---------- | -- | | 📋 [Spécification](PD-35-specification.md) | | | 🛠️ [Plan d'implémentation](PD-35-plan.md) | | | ✅ **Critères d'acceptation** | *(ce document)* | | 📝 [Retour d'expérience](PD-35-rex.md) | | [← Retour à crypto-proof](../PD-189-epic.md) · [↑ Index User Story](index.md)Objectif¶
Vérifier que l’implémentation est conforme à la spécification, respecte l’ensemble des invariants ProbatioVault et ne présente aucune incohérence ou oubli critique.
Périmètre de vérification¶
La revue d’acceptabilité vérifie explicitement :
- la conformité stricte à la spécification fonctionnelle
- le respect de tous les invariants applicables
- la couverture des scénarios de test définis
- l’absence d’incohérences, oublis ou régressions
Écarts identifiés¶
Chaque écart constaté est documenté et classé selon sa gravité.
Classification des écarts¶
| Niveau | Définition |
|---|---|
| BLOQUANT | Violation d’un invariant, faille de sécurité, non-conformité majeure à la spec |
| MAJEUR | Fonction incomplète, comportement non conforme mais sans rupture de sécurité |
| MINEUR | Détail, dette acceptable, amélioration non critique |
Détail des écarts¶
| ID | Description | Référence | Gravité |
|---|---|---|---|
| E-01 | API non protégée (scaffolding DEV ONLY documenté) : guard JWT désactivé et userId/deviceId hardcodés en attendant PD-XX. Le périmètre PD-35 ne précise pas si l’auth devait être livrée, mais en l’état l’isolement utilisateur n’est pas assuré. | Spec « Sécurité » / « Isolation stricte des données », key-envelope.controller.ts (guards commentés, TODO JWT, userId/deviceId en dur) | MAJEUR |
| E-02 | Mécanisme de récupération incomplet côté API : aucune route pour récupérer l’enveloppe de récupération (seule la création est exposée), rendant la récupération de compte inexploitable. | Spec « Support d'un mécanisme de récupération de compte », key-envelope.controller.ts (pas de GET recovery), service seulement | MAJEUR |
| E-03 | Vérification blacklist globale : isDeviceBlacklisted filtre uniquement sur deviceId et ignore userId, alors que le modèle et la contrainte UNIQUE sont par (user_id, device_id). Un device révoqué pour un utilisateur est bloqué pour tous. | Plan Phase ¾ (révocation device par utilisateur), device_blacklist UNIQUE (user_id, device_id), key-envelope.service.ts:isDeviceBlacklisted | MAJEUR |
| E-04 | Journalisation probatoire absente : les opérations sensibles (création/révocation/rotation) ne sont pas journalisées de manière probatoire (TODO laissés), contrairement à la contrainte de sécurité. | Spec « Sécurité » (journalisation probatoire), key-envelope.service.ts (TODO audit log), key-envelope.controller.ts | MAJEUR |
| E-05 | Tests incomplets vis-à-vis du plan : aucun test de conformité aux vecteurs RFC 3394 (plan Phase 6.1). Les tests AES-KW valident les longueurs/erreurs mais pas de vecteur normatif. | Plan Phase 6 Tests (RFC 3394), src/modules/crypto/services/aes-kw.service.spec.ts | MINEUR |
Conclusion d’acceptabilité¶
⚠️ ACCEPTÉ AVEC RÉSERVES (écarts MAJEURS/MINEURS documentés)