PD-80 — Implémenter scellement instantané (P95 < 15 min)¶

1. Contexte¶

ProbatioVault est un coffre-fort numérique à valeur probante. Dans le cadre de l'offre B2C-mineurs (cyberharcèlement, revenge porn, menaces, diffusion rapide de contenu), la rapidité du scellement probatoire est critique. Aujourd'hui, l'ancrage blockchain fonctionne en batch standard avec un SLA de plusieurs heures. Cette story introduit un mécanisme de scellement prioritaire garantissant une preuve juridiquement complète en P95 < 15 minutes (pire-cas < 25 min sans dégradation externe, < 75 min avec retries TSA/blockchain).

Argument différenciant : Aucun concurrent coffre-fort numérique ne propose aujourd'hui un scellement probatoire complet (TSA + blockchain) en moins d'une heure.

2. Problème¶

Un mineur victime de cyberharcèlement uploade une capture d'écran comme preuve. Avec le système batch standard, l'ancrage blockchain peut prendre plusieurs heures. Pendant ce délai : - Le contenu peut être supprimé par l'auteur - L'urgence judiciaire (dépôt de plainte, référé) n'est pas servie - La preuve existe localement (hash + journal append-only) mais n'a pas encore de valeur probante complète (TSA + blockchain)

3. Objectif¶

Permettre à un mineur (ou à son représentant légal) de sceller probatoirement une preuve numérique en moins d'une heure, avec : - Horodatage qualifié RFC 3161 (TSA) - Inclusion Merkle (mini-batch prioritaire) - Signature HSM - Ancrage blockchain L2 - Génération de la preuve vérifiable - Notification multi-canal

4. Acteurs¶

5. Règles métier¶

5.1 Mode de déclenchement (hybride)¶

5.2 SLA global (chaîne complète)¶

Le SLA couvre l'intégralité de la chaîne probatoire, mesurée à 3 niveaux :

Note : En cas de dégradation externe (indisponibilité TSA : 4 retries [1,5,15,30] min = 51 min, ou congestion blockchain : finality timeout 15 min), le pire-cas absolu atteint ~75 min. Le final_timeout à 120 min couvre ce scénario avec marge. Le SLA engagé reste P95 < 15 min sur fenêtre glissante 24h.

5.3 Mini-batch prioritaire (pas d'ancrage individuel)¶

Un Merkle batch de 5–20 preuves produit 1 transaction blockchain pour N preuves vérifiables. L'utilisateur ne voit aucune différence avec un ancrage individuel.

5.4 Dégradation (fail-soft)¶

Si TSA ou blockchain temporairement indisponible : - Jamais d'échec immédiat — file d'attente avec retry - Politique retry (exponential backoff) :

• Timeout final : > 2h → notification d'échec + escalade opérationnelle
• Le hash local + journal append-only garantissent déjà une preuve de capture, même sans ancrage blockchain

5.5 Quotas et anti-abus¶

• Rate limit : 1 scellement urgent / heure / utilisateur
• Protection anti-DoS économique (flood blockchain)

5.6 Notifications (triple canal)¶

5.7 UX progression¶

Après upload urgent :

🔒 Capture de preuve effectuée
⏱ Horodatage certifié : en cours
⛓ Ancrage blockchain : en cours
Temps estimé : quelques minutes

Puis :

✅ Preuve scellée
Horodatage : 14:32
Blockchain : confirmée

Détails techniques (accès avancé via bouton) : hash document, Merkle proof, transaction blockchain avec lien explorateur.

6. Architecture cible¶

6.1 Queues BullMQ¶

Politique de priorité : priority weight = 5, standard weight = 1. Pas de starvation des batchs standards.

6.2 Métriques¶

7. Périmètre et exclusions¶

Inclus (cette story)¶

• Queues BullMQ prioritaires (TSA + anchor)
• Workers prioritaires
• Mini-batch Merkle prioritaire
• Dégradation fail-soft avec retry
• Quotas et rate limiting
• Notifications push + email + webhook
• Métriques de latence

Exclus (stories séparées)¶

• UX front-end : composants visuels (bouton "Scellement urgent", carte de progression, détails techniques) → PD-284 (créée, bloquée par PD-80)
• Facturation pay-per-use (intégration Stripe)
• Dashboard opérationnel de monitoring des queues prioritaires

8. Dépendances¶

9. Critères d'acceptation (haut niveau)¶

• CA-01 : Un compte mineur qui uploade un document déclenche automatiquement le fast-track (pas de clic supplémentaire)
• CA-02 : Un utilisateur standard peut déclencher manuellement le scellement urgent (bouton API)
• CA-03 : Le SLA global P95 < 15 min est respecté (TSA + batch + Merkle + blockchain finality + proof + notification). Pire-cas sans dégradation externe < 25 min. Timeout final à 120 min.
• CA-04 : Le mini-batch prioritaire regroupe 5–20 preuves avec un batch_time_max de 5 min
• CA-05 : En cas d'indisponibilité TSA/blockchain, le retry exponential backoff est appliqué (1min, 5min, 15min, 30min)
• CA-06 : Le timeout final > 2h déclenche une notification d'échec + escalade
• CA-07 : Les quotas sont respectés (freemium: 3/mois, premium: 10/mois, enterprise: illimité)
• CA-08 : Le rate limiting 1/heure/utilisateur est appliqué
• CA-09 : La notification push mobile est envoyée immédiatement après scellement
• CA-10 : L'email de preuve officielle contient hash, tx blockchain, lien téléchargement, horodatage TSA
• CA-11 : Le webhook proof_sealed est émis si configuré
• CA-12 : Les métriques seal_latency_seconds et priority_queue_depth sont exposées
• CA-13 : La file prioritaire ne provoque pas de starvation du batch standard (weight 5:1)

10. Learnings injectés¶