PD-63 — Expression de besoin¶
Story : Créer endpoint GET /documents/:id/download Epic : PD-192 (DOCS-API) Date : 2026-02-20 Auteur : PO (via Jira)
1. Contexte¶
ProbatioVault est un coffre-fort numérique souverain fondé sur un modèle zero-knowledge, une séparation stricte contenu / preuve et une conservation WORM multi-cloud (cf. Architecture Executive v4.1-E).
Dans ce modèle : - Les documents sont chiffrés côté client - Le backend ne manipule que des blobs chiffrés - Toute action significative doit être journalisée probatoirement - L'accès aux documents est soumis à une vérification stricte de propriété ou de délégation
L'endpoint PD-63 concerne la phase de récupération d'un document existant.
2. Objectif du besoin¶
Permettre à un utilisateur authentifié de télécharger un document chiffré dont il est légitimement détenteur, sans : - exposer le contenu au serveur, - compromettre le modèle zero-knowledge, - créer de surface d'attaque supplémentaire, - altérer la chaîne probatoire.
3. Résultat attendu¶
Lorsqu'un utilisateur appelle :
Le système doit permettre :
3.1 Vérification stricte de légitimité¶
- L'utilisateur est propriétaire OU
- Il détient une enveloppe cryptographique valide (PRE, B2B2C, transfert, etc.)
- Aucun accès implicite ou latéral n'est toléré
3.2 Accès au fichier chiffré¶
- Le backend ne transmet jamais de clé
- Le backend ne déchiffre jamais
- Le document reste chiffré de bout en bout
3.3 Traçabilité probatoire de l'accès¶
- L'événement de demande de téléchargement doit être journalisé
- L'événement doit pouvoir être intégré au mécanisme de preuve composite (cf. brevet Preuve Composite Ancrée)
- L'accès doit être auditable a posteriori
3.4 Respect des invariants réglementaires¶
- Aucune altération du stockage WORM
- Aucun accès non traçable
- Respect RGPD (droit d'accès mais pas divulgation excessive)
4. Invariants de sécurité¶
Les exigences suivantes sont non négociables :
| ID | Invariant |
|---|---|
| INV-63-01 | Le serveur ne doit jamais voir le document en clair |
| INV-63-02 | Le serveur ne doit jamais exposer K_doc, K_master ou toute clé dérivée |
| INV-63-03 | L'URL d'accès ne doit pas être réutilisable indéfiniment |
| INV-63-04 | Aucun téléchargement ne doit être possible sans authentification valide |
| INV-63-05 | Chaque téléchargement doit produire un événement journalisé |
| INV-63-06 | L'accès doit respecter les règles de révocation (device révoqué, partage expiré, etc.) |
| INV-63-07 | Le mécanisme doit rester compatible avec l'architecture multi-cloud (OVH + AWS Glacier) |
5. Tensions et exigences concurrentes¶
Cette user story doit concilier :
| Exigence | Tension |
|---|---|
| Accès fluide utilisateur | Sécurité maximale |
| Performance (temps de réponse court) | Vérification cryptographique stricte |
| Scalabilité horizontale | Auditabilité append-only |
| Zero-knowledge | Journalisation probatoire forte |
Principe directeur : Le système doit rester robuste avant d'être optimisé.
6. Cas d'usage couverts¶
L'endpoint doit fonctionner pour : - Coffre personnel B2C - RH (bulletin transféré salarié) - Mineurs (preuve scellée) - B2B2C (co-détention facture garage) - Délégation Legal PRE (avocat, juge)
Il ne doit créer aucune exception logique selon le vertical.
7. Résultats inacceptables¶
Sont considérés comme critiques : - Téléchargement possible via simple guessing d'ID - URL permanente partageable hors contrôle - Absence de journalisation - Téléchargement malgré révocation - Accès possible après suppression légale
8. Critères d'acceptabilité fonctionnelle¶
L'endpoint est conforme si : - [ ] Un utilisateur légitime peut récupérer son document chiffré - [ ] Un utilisateur non légitime reçoit une erreur explicite - [ ] Chaque appel génère une trace d'audit - [ ] Le système reste conforme au modèle zero-knowledge - [ ] Le stockage WORM reste intact
9. Intention humaine derrière la story¶
Ce besoin répond à un impératif fondamental de ProbatioVault :
Permettre l'accès aux preuves sans jamais compromettre la preuve elle-même.
Il s'agit de garantir que : - L'utilisateur peut exercer son droit d'accès, - Sans que la plateforme devienne un point de vulnérabilité, - Et sans affaiblir la recevabilité juridique future.
10. Dépendances¶
| Story | Statut | Relation |
|---|---|---|
| PD-60 | DONE | Upload - endpoint miroir |
| PD-46 | DONE | Secure download (infra) - dépendance directe |
| PD-31 | DONE | Audit log auth - pattern de journalisation |
| PD-37 | DONE | HSM audit signature - signature probatoire |
11. Hors périmètre¶
- Déchiffrement côté serveur (zero-knowledge)
- Gestion des quotas de téléchargement (story dédiée)
- Streaming de fichiers volumineux (> 1 Go) - optimisation future
- Interface utilisateur (story app)