PD-72 — Expression de besoin¶

1. Titre¶

Créer worker PRE transfert coffre entreprise → salarié

2. Contexte¶

Dans le cas d'usage RH (bulletins de paie probatoires), l'entreprise chiffre le document avec une clé documentaire issue de son espace professionnel (K_docEntreprise). Conformément à l'architecture RH (Architecture Technique v4.1), l'entreprise ne doit pas conserver le contenu lisible après remise au salarié.

Le transfert vers le coffre personnel du salarié doit :

• Maintenir le modèle Zero-Knowledge (le worker ne voit jamais le document en clair)
• Produire une preuve de remise juridiquement opposable
• Journaliser et ancrer l'opération dans la chaîne de preuve composite
• Être révocable jusqu'au scellement final

Ce transfert repose sur le mécanisme Legal PRE (Proxy Re-Encryption) décrit dans la fiche brevet n°803.

3. Objectif¶

Implémenter un worker BullMQ asynchrone qui orchestre le re-chiffrement probatoire d'un document RH du coffre entreprise vers le coffre personnel du salarié. Le worker est un orchestrateur métier RH : il appelle les modules existants sans réimplémenter de primitive cryptographique.

4. Périmètre fonctionnel¶

4.1 Ce que PD-72 implémente¶

4.2 Ce que PD-72 n'implémente PAS (modules existants)¶

4.3 Hors scope explicite¶

• UX consentement salarié (futur ticket) — PD-72 suppose employee_consent = TRUE
• Logique cryptographique de révocation complète (module PRE / key lifecycle)
• Format bundle preuve (ProofEnvelope canonical existant)

5. Entité DocumentTransfer¶

5.1 Schéma¶

Document
   │
   └── DocumentTransfer
            ├ id (UUID)
            ├ document_id (FK → Document)
            ├ status (enum)
            ├ source_vault_id (FK → Vault entreprise)
            ├ target_vault_id (FK → Vault salarié)
            ├ transfer_policy ('copy' | 'transfer')
            ├ rk_id (identifiant clé de re-chiffrement, nullable post-zeroization)
            ├ proof_id (FK → Proof, nullable avant création preuve)
            ├ error_code (nullable)
            ├ retry_count (default 0)
            ├ created_at
            ├ updated_at
            └ completed_at (nullable)

5.2 Machine d'états¶

PENDING
  ↓
READY_FOR_TRANSFER
  ↓
TRANSFER_IN_PROGRESS
  ↓
TRANSFERRED
  ↓
PROOF_PENDING_ANCHOR
  ↓
ANCHOR_CONFIRMED

En cas d'échec :
  FAILED → retry (max 3) → READY_FOR_TRANSFER
  BLOCKED_WAITING_CONSENT (si consentement absent)

6. Flux nominal¶

1. Déclenchement : Un document RH passe au statut SEALED → job BullMQ pre-transfer créé
2. Vérification préconditions :
3. Salarié dispose d'un compte ProbatioVault actif
4. Clé publique salarié (PK_encSalarié) disponible et certifiée
5. employee_consent = TRUE
6. Génération auth_token : Token signé par HSM (modèle Legal PRE)
7. Génération clé de re-chiffrement : rk_Entreprise→Salarié (locale, éphémère)
8. Re-chiffrement aveugle : wrap_Salarié = PRE.ReEncrypt(wrap_Entreprise, rk)
9. Zeroization : Destruction immédiate de rk en mémoire
10. Événement probatoire : Création TRANSFER_EMPLOYEE avec doc_id, employee_id, hash_doc, timestamp, hsm_signature, previous_merkle_root
11. Signature HSM de l'événement
12. Inclusion Merkle batch
13. Horodatage TSA RFC 3161
14. Ancrage blockchain (périodique, via batch)
15. Acte de remise : Génération du document probatoire signé
16. Notification salarié : In-app + email neutre
17. Policy check : Si transfer_policy = 'transfer' → déclencher révocation accès entreprise

7. Exigences fonctionnelles¶

8. Exigences non fonctionnelles¶

9. Invariants de sécurité (non négociables)¶

10. Cas d'erreur¶

11. Critères d'acceptation¶

• CA-01 : Le salarié peut ouvrir le document via son coffre personnel après transfert
• CA-02 : L'entreprise ne peut plus accéder au contenu si transfer_policy = 'transfer'
• CA-03 : Une preuve composite exportable est générée (ProofEnvelope canonical)
• CA-04 : Vérification offline possible via bundle JSON
• CA-05 : Audit externe valide la chaîne Merkle → TSA → blockchain
• CA-06 : Le worker est idempotent (relance = même résultat, pas de duplication)
• CA-07 : Performance < 3s par transfert (hors ancrage batch)
• CA-08 : Les 7 invariants de sécurité sont respectés

12. Dépendances¶

13. Learnings injectés¶

1. crypto.randomUUID() obligatoire pour tout ID aléatoire (PD-63 — Sonar S2245)
2. crypto.verify(null, hash, key, sig) pour raw ECDSA HSM — jamais createVerify() (PD-282 — double-hash)
3. Centralisation constantes crypto dans constants.ts (PD-243)
4. Timing-safe comparison pour tokens de sécurité (PD-238)
5. Branded types pour UUIDs sémantiquement distincts (DocumentTransferId, VaultId, ProofId)

14. Impact stratégique¶

Ce worker est : - Le cœur du modèle RH différenciant - La preuve que l'entreprise ne conserve pas les données personnelles (RGPD) - Un levier majeur ARR B2B

Il concrétise la promesse : "Fusion logique coffre pro / perso, sans duplication, avec séparation probatoire."