PD-60 — Dépôt probatoire d'un document (Upload)¶

1. Objectif¶

Définir le contrat canonique de POST /documents/upload pour qu'un acteur autorisé puisse déposer un document avec création d'un acte probatoire daté, traçable et juridiquement imputable, vérifiable par un tiers hors plateforme, sans exposition du contenu intelligible du document à ProbatioVault.

2. Périmètre / Hors périmètre¶

Inclus¶

• Réception d'un acte de dépôt documentaire via API.
• Vérification de l'authentification et de l'autorisation du déposant.
• Enregistrement d'un acte de dépôt daté, traçable et non ambigu.
• Émission d'un reçu probatoire exportable remis au déposant.
• Association explicite du dépôt à un compte ProbatioVault et à un périmètre de responsabilité.
• Gestion déterministe des erreurs.
• Gestion d'un état intermédiaire explicite non probatoire en contexte dégradé, puis confirmation probatoire ultérieure.

Exclu¶

• Consultation, modification, partage, suppression, recherche, indexation, versioning documentaire.
• Définition des mécanismes internes de stockage, de chiffrement, de calcul cryptographique ou de transport.
• Définition d'objectifs de performance (latence, débit, volumétrie).
• Rate-limiting et protection contre les tentatives massives d'authentification échouées (relève de la couche infrastructure/opérationnelle — résolution R-14).
• Qualification juridictionnelle finale de la valeur probatoire par une autorité externe (hors périmètre — non testable dans cette US).

3. Définitions¶

• Acte de dépôt probatoire : opération métier qui établit l'existence probatoire du document.
• Acteur autorisé : compte authentifié disposant du droit de déposer.
• Compte déposant : identifiant de compte ProbatioVault (depositor_identity_ref) ; la spécification ne qualifie pas l'identité civile réelle derrière ce compte.
• Contenu intelligible : contenu lisible en clair par ProbatioVault.
• Empreinte documentaire (document_fingerprint) : hash SHA-256 du contenu opaque soumis, fourni par le client au format hexadécimal lowercase (64 caractères). Le système DOIT recalculer le hash du contenu opaque reçu et vérifier la cohérence avec l'empreinte fournie par le client (voir INV-60-15).
• Date d'existence probatoire : horodatage UTC opposable (existence_timestamp_utc), au format ISO 8601 avec précision à la seconde. La source d'horodatage DOIT être synchronisée NTP avec une dérive maximale tolérée de 1 seconde. Au-delà, le système DOIT refuser la confirmation probatoire (contexte dégradé).
• Reçu probatoire (proof_receipt) : structure JSON signée (JWS — RFC 7515, algorithme RS256 ou ES256) contenant dans le payload : deposit_id, existence_timestamp_utc, document_fingerprint, depositor_identity_ref, responsibility_scope_ref, audit_trace_ref, responsibility_declaration. La signature est vérifiable avec la clé publique ProbatioVault publiée hors plateforme. La vérification tiers consiste à : (1) vérifier la signature JWS avec la clé publique, (2) comparer le document_fingerprint du reçu avec le hash SHA-256 du document original, (3) vérifier la cohérence des champs du payload.
• Pré-enregistrement non probatoire : état intermédiaire explicite sans effet juridique probatoire.
• Contexte dégradé : situation où le contenu opaque a été reçu et validé (authentification OK, requête complète, empreinte cohérente) mais au moins une des deux conditions de l'existence juridique ne peut pas être satisfaite (écriture d'audit immuable indisponible OU émission du reçu probatoire impossible). Se distingue d'une erreur technique (ERR-60-06) qui survient avant la validation de la requête.
• Confirmation probatoire : transition d'un état non probatoire vers un acte de dépôt probatoire complet.
• Périmètre de responsabilité : contexte d'imputation de l'acte (responsibility_scope_ref).
• Tiers vérificateur : entité pouvant vérifier la preuve sans accès API ProbatioVault.
• Notice minimale obligatoire : texte exact "Vous réalisez un acte probatoire daté." devant être accepté explicitement avant confirmation probatoire. Le système vérifie la présence de probative_notice_ack=true dans la requête ; la responsabilité de présenter effectivement le texte de la notice à l'utilisateur final incombe au client appelant (limitation architecturale inhérente aux API — résolution R-05).

4. Invariants (non négociables)¶

5. Flux nominaux¶

FN-60-01 — Confirmation probatoire nominale¶

1. Le client soumet une requête complète avec : contenu opaque, empreinte, client_request_id, contexte identité/autorisations, probative_notice_ack=true.
2. Le système vérifie la validité de l'authentification et des droits.
3. Le système vérifie la complétude et la cohérence de la requête (incluant la vérification serveur : hash SHA-256 du contenu opaque reçu == document_fingerprint fourni).
4. Le système écrit la trace d'audit immuable de l'acte.
5. Le système émet le reçu probatoire.
6. L'acte acquiert l'existence juridique (double condition satisfaite).

Sortie obligatoire (succès probatoire) : deposit_id, existence_timestamp_utc, depositor_identity_ref, responsibility_scope_ref, document_fingerprint, client_request_id, proof_receipt, audit_trace_ref, act_type=PROBATIVE_DEPOSIT, legal_existence_status=ESTABLISHED.

FN-60-02 — Rejeu idempotent (même intention)¶

1. Le client rejoue la même requête (client_request_id identique + même document).
2. Le système renvoie le résultat probatoire initial.

Résultat attendu : aucun doublon d'acte probatoire.

FN-60-03 — Contexte dégradé : pré-enregistrement non probatoire¶

1. Le client soumet une requête mais la confirmation probatoire ne peut pas être finalisée.
2. Le système crée un pré-enregistrement explicite.

Sortie obligatoire (non probatoire) : staging_id, client_request_id, act_type=NON_PROBATIVE_STAGING, legal_existence_status=NOT_ESTABLISHED.

Interdictions : pas de deposit_id, pas de proof_receipt, pas de existence_timestamp_utc.

FN-60-04 — Confirmation ultérieure d'un pré-enregistrement¶

1. Le client rejoue avec le même client_request_id après rétablissement des conditions.
2. Le système applique FN-60-01.

Résultat attendu : un seul acte probatoire final, sans ambiguïté sur le statut juridique.

FN-60-05 — Vérification tiers hors plateforme (niveau renforcé)¶

1. Le tiers dispose du document, du reçu probatoire et de la référence d'audit.
2. Le tiers vérifie :
3. cohérence document ↔ empreinte,
4. cohérence deposit_id + existence_timestamp_utc,
5. présence et cohérence de depositor_identity_ref + responsibility_scope_ref,
6. cohérence reçu ↔ audit_trace_ref.

Résultat attendu : preuve valide sans appel à l'API applicative ProbatioVault.

5bis. Diagrammes¶

Diagramme d'etats — Cycle de vie d'un depot¶

Le depot documentaire suit une machine d'etats a deux statuts explicites (INV-60-09) avec une confirmation probatoire atomique (INV-60-02). L'existence juridique n'est acquise que par double condition : audit immuable + recu emis (INV-60-10).

stateDiagram-v2
    [*] --> Validation : POST /documents/upload
    Validation --> Refuse : ERR-60-01..04, 07, 11
    Refuse --> [*]

    Validation --> ConfirmationProbatoire : Requete valide\n+ conditions nominales
    Validation --> NON_PROBATIVE_STAGING : Requete valide\n+ contexte degrade (INV-60-11)

    state ConfirmationProbatoire {
        [*] --> EcritureAudit : Trace immuable (INV-60-06)
        EcritureAudit --> EmissionRecu : Recu JWS (INV-60-05)
        EmissionRecu --> DoubleCondition : INV-60-10
    }

    ConfirmationProbatoire --> PROBATIVE_DEPOSIT : Succes atomique (INV-60-02)
    ConfirmationProbatoire --> NON_PROBATIVE_STAGING : Echec partiel\n(audit OU recu indisponible)

    NON_PROBATIVE_STAGING --> ConfirmationProbatoire : Rejeu apres retablissement\n(FN-60-04)

    PROBATIVE_DEPOSIT --> PROBATIVE_DEPOSIT : Rejeu idempotent\n(FN-60-02, ERR-60-08)
    PROBATIVE_DEPOSIT --> [*]

    note right of NON_PROBATIVE_STAGING
        legal_existence_status = NOT_ESTABLISHED
        Pas de deposit_id, pas de proof_receipt (INV-60-11)
    end note

    note right of PROBATIVE_DEPOSIT
        legal_existence_status = ESTABLISHED
        deposit_id + existence_timestamp_utc (INV-60-03)
    end note

Diagramme de sequence — Flux nominal (FN-60-01)¶

Le flux nominal implique le client, le service API, le module de verification d'integrite, le journal d'audit immuable et le module de signature JWS. La confirmation probatoire est atomique (INV-60-02) : toute defaillance avant la double condition entraine un rollback vers NON_PROBATIVE_STAGING.

sequenceDiagram
    participant C as Client
    participant API as DocumentUploadService
    participant Auth as AuthService
    participant Hash as IntegrityVerifier
    participant NTP as NTPSource
    participant Audit as AuditLog (append-only)
    participant JWS as JWSSigningModule

    C->>+API: POST /documents/upload<br/>(contenu opaque, document_fingerprint,<br/>client_request_id, probative_notice_ack=true)

    API->>+Auth: Verifier authentification + autorisation
    Auth-->>-API: OK (depositor_identity_ref,<br/>responsibility_scope_ref)
    Note over API: INV-60-01, INV-60-07

    API->>API: Verifier completude requete<br/>+ probative_notice_ack (INV-60-12)

    API->>+Hash: SHA-256(contenu opaque)
    Hash-->>-API: hash_recalcule
    API->>API: hash_recalcule == document_fingerprint ?
    Note over API: INV-60-15 — Rejet si incoherent

    API->>+NTP: Horodatage UTC
    NTP-->>-API: existence_timestamp_utc
    Note over API: Derive <= 1s (H-60-03)

    rect rgb(230, 245, 255)
        Note over API,JWS: Confirmation probatoire atomique (INV-60-02, INV-60-10)
        API->>+Audit: Ecrire trace immuable<br/>(deposit_id, fingerprint, identity, scope)
        Audit-->>-API: audit_trace_ref
        Note over Audit: INV-60-06 — append-only

        API->>+JWS: Signer recu probatoire<br/>(deposit_id, timestamp, fingerprint,<br/>identity, scope, audit_trace_ref)
        JWS-->>-API: proof_receipt (JWS RS256/ES256)
        Note over JWS: INV-60-05 — verifiable hors plateforme
    end

    API-->>-C: 201 Created<br/>act_type=PROBATIVE_DEPOSIT<br/>legal_existence_status=ESTABLISHED<br/>deposit_id, proof_receipt, audit_trace_ref
    Note over C: INV-60-03, INV-60-09

Diagramme de sequence — Contexte degrade (FN-60-03 / FN-60-04)¶

En contexte degrade (INV-60-11), le systeme cree un pre-enregistrement non probatoire. La confirmation ulterieure (FN-60-04) reprend le flux nominal apres retablissement des conditions.

sequenceDiagram
    participant C as Client
    participant API as DocumentUploadService
    participant Audit as AuditLog (append-only)
    participant JWS as JWSSigningModule

    C->>+API: POST /documents/upload<br/>(requete valide, verifications OK)

    alt Audit indisponible OU JWS indisponible
        API->>Audit: Ecrire trace immuable
        Note over Audit: INDISPONIBLE (ou JWS indisponible)
        API-->>C: 202 Accepted<br/>act_type=NON_PROBATIVE_STAGING<br/>legal_existence_status=NOT_ESTABLISHED<br/>staging_id (pas de deposit_id, pas de proof_receipt)
        Note over C: INV-60-09, INV-60-11
    end

    Note over C,API: ... Retablissement des conditions ...

    C->>+API: POST /documents/upload<br/>(meme client_request_id — FN-60-04)
    API->>+Audit: Ecrire trace immuable
    Audit-->>-API: audit_trace_ref
    API->>+JWS: Signer recu probatoire
    JWS-->>-API: proof_receipt

    API-->>-C: 201 Created<br/>act_type=PROBATIVE_DEPOSIT<br/>legal_existence_status=ESTABLISHED
    Note over C: Double condition satisfaite (INV-60-10)

6. Cas d'erreur¶

7. Critères d'acceptation (testables)¶

8. Scénarios de test (Given / When / Then)¶

ST-60-01 — Dépôt nominal¶

• Given un acteur authentifié et autorisé avec requête complète et probative_notice_ack=true
• When il appelle POST /documents/upload
• Then le système retourne un succès probatoire avec deposit_id, existence_timestamp_utc, proof_receipt, audit_trace_ref

ST-60-02 — Rejet non authentifié¶

• Given une requête sans authentification valide
• When l'appel est soumis
• Then le système refuse et ne crée aucun acte probatoire

ST-60-03 — Rejet non autorisé¶

• Given un acteur authentifié sans droit de dépôt
• When l'appel est soumis
• Then le système refuse et ne crée aucun acte probatoire

ST-60-04 — Atomicité confirmation probatoire¶

• Given une erreur simulée avant confirmation
• When une confirmation probatoire est tentée
• Then l'opération échoue explicitement sans état probatoire partiel

ST-60-05 — Rejeu idempotent¶

• Given un dépôt probatoire déjà accepté
• When la requête identique est rejouée
• Then le système renvoie le même deposit_id

ST-60-06 — Conflit de rejeu¶

• Given un client_request_id existant sur document A
• When il est rejoué avec document B
• Then le système refuse avec conflit

ST-60-07 — Confidentialité de contenu¶

• Given un document contenant un marqueur connu
• When le dépôt est traité
• Then le marqueur n'apparaît ni en réponse ni en logs/traces applicatives

ST-60-08 — Vérification tiers renforcée réussie¶

• Given document original, reçu probatoire, référence d'audit cohérente
• When un tiers vérifie hors plateforme
• Then la preuve est valide

ST-60-09 — Altération détectée¶

• Given document modifié après dépôt et reçu initial
• When un tiers vérifie
• Then la vérification échoue

ST-60-10 — Lien compte déposant / responsabilité¶

• Given un dépôt probatoire accepté
• When reçu et audit sont examinés
• Then depositor_identity_ref et responsibility_scope_ref sont présents et cohérents

ST-60-11 — Refus sans notice acceptée¶

• Given une requête sans probative_notice_ack=true
• When l'appel est soumis
• Then le système refuse et ne crée aucun acte probatoire

ST-60-12 — Double condition d'existence juridique¶

• Given une tentative de dépôt
• When seule une des deux conditions (audit immuable / reçu) est présente
• Then legal_existence_status n'est pas ESTABLISHED

ST-60-13 — Pré-enregistrement non probatoire¶

• Given un contexte dégradé empêchant la confirmation
• When la requête est soumise
• Then le système retourne NON_PROBATIVE_STAGING sans reçu probatoire

ST-60-14 — Confirmation après staging¶

• Given un NON_PROBATIVE_STAGING existant
• When les conditions nominales sont rétablies et la requête est rejouée
• Then un acte probatoire unique est créé

ST-60-15 — Incohérence reçu / audit¶

• Given un reçu probatoire et une référence d'audit incohérente
• When un tiers réalise la vérification
• Then la vérification échoue

9. Hypothèses explicites¶

10. Points à clarifier¶

Aucun point bloquant restant pour PD-60 à ce stade.

Décisions contractuelles actées : - PC-60-01 : existence juridique par double condition (audit immuable + reçu émis). - PC-60-02 : obligation irréversible limitée à la reconnaissance de l'acte (existence/date). - PC-60-03 : responsabilité partagée (déposant / organisation / ProbatioVault). - PC-60-04 : notice minimale obligatoire = "Vous réalisez un acte probatoire daté.". - PC-60-05 : contexte dégradé avec état intermédiaire explicitement non probatoire. - PC-60-06 : vérification tiers renforcée incluant cohérence reçu ↔ référence d'audit. - PC-60-07 : empreinte documentaire = SHA-256 hex lowercase, vérifiée côté serveur (résolution R-01/R-12). - PC-60-08 : reçu probatoire = JWS signé (RS256 ou ES256), vérifiable avec clé publique ProbatioVault (résolution R-03). - PC-60-09 : contexte dégradé = contenu reçu et validé mais double condition non satisfaisable (résolution R-02). - PC-60-10 : tolérance horodatage NTP ≤ 1s, sinon contexte dégradé (résolution R-11). - PC-60-11 : testabilité double condition via injection de faute contrôlée (résolution R-09). - PC-60-12 : INV-60-13/14 testables sur présence syntaxique uniquement ; qualification juridique hors périmètre (résolution R-07/R-08). - PC-60-13 : non-altérabilité audit = append-only applicatif ; résistance admin-level hors périmètre US (résolution R-04). - PC-60-14 : présentation effective de la notice = responsabilité client appelant (résolution R-05). - PC-60-15 : rejeu staging avec document modifié = conflit ERR-60-12 (résolution R-06). - PC-60-16 : zero-knowledge = responsabilité client ; le système traite le contenu comme opaque (résolution R-13). - PC-60-17 : rate-limiting hors périmètre US, relève de l'infrastructure (résolution R-14).

Références¶

• Epic : API Documents & preuves probatoires (PD-192)
• JIRA : PD-60
• Repos concernés : ProbatioVault-backend, ProbatioVault-infra, clients API (web/mobile/desktop/partenaires)
• Documents associés : PD-60-besoin.md, ADR de l'API Documents, référentiels RGPD / NF Z42-013 / ISO 14641