PD-287 — Expression de Besoin¶

Story : Lien de partage sans compte pour une preuve existante Domaine : sharing (backend) Date : 2026-04-19 Statut : BESOIN

1. Contexte¶

ProbatioVault conserve pour ses utilisateurs des preuves numériques à valeur probatoire (documents ancrés dans un SAE, scellés cryptographiquement, horodatés par TSA, ancrés en blockchain). Aujourd'hui, ces preuves ne sont consultables que par leur propriétaire authentifié, ou par un utilisateur disposant lui-même d'un compte ProbatioVault.

Or, dans la vie réelle d'une preuve, le propriétaire a régulièrement besoin de la montrer à un tiers :

• un avocat consulté ponctuellement pour un litige,
• un huissier instrumentaire qui doit constater l'existence d'un document,
• un officier de police judiciaire dans le cadre d'une réquisition ou d'un dépôt de plainte,
• un assureur traitant un sinistre,
• une partie adverse dans une négociation amiable pré-contentieuse,
• un expert judiciaire,
• un client ponctuel (ex : un notaire recevant un mandat pour une seule opération).

Ces tiers ont deux caractéristiques communes :

1. Ils sont externes à l'écosystème ProbatioVault — exiger qu'ils créent un compte complet (KYC, validation email, acceptation CGU, configuration de clés) est un frein d'adoption majeur et souvent un non-sens (un avocat consulte 200 clients par an, il ne créera pas 200 comptes sur 200 coffres différents).
2. Leur besoin est temporaire — ils doivent consulter la preuve sur une fenêtre définie (durée d'un dossier, d'une instruction, d'une négociation), après quoi le droit d'accès n'a plus de raison d'exister.

Le propriétaire de la preuve, lui, doit pouvoir déléguer un droit de lecture à ce tiers sans que cela équivaille à :

• lui donner une copie du document (qui sortirait du périmètre probatoire),
• lui transmettre ses propres clés (qui révoquerait son propre zero-knowledge),
• renoncer à son contrôle sur qui voit quoi, quand, pendant combien de temps.

Le PO a explicitement nommé le modèle attendu : Proxy Re-Encryption (PRE). Cette exigence est portée dans les contraintes (§4), pas dans les objectifs (§2), car le besoin fonctionnel est la délégation d'accès contrôlée ; la PRE est la technique imposée par le PO pour atteindre ce besoin tout en préservant les invariants zero-knowledge et WORM de la plateforme.

Cette story s'inscrit dans l'épic sharing, en continuité des travaux crypto-proof (hash, Merkle, TSA, blockchain) et en amont potentiel d'autres formes de partage (partage entre comptes, partage à un groupe, délégation révocable de longue durée).

2. Objectifs principaux¶

OBJ-1 — Déléguer un droit de lecture à un tiers sans compte¶

Permettre au propriétaire d'une preuve de générer, en quelques secondes, un lien qu'il peut transmettre à un destinataire externe par le canal de son choix (email, SMS, papier imprimé, QR code). Le destinataire doit pouvoir consulter la preuve sans créer de compte persistant sur ProbatioVault.

OBJ-2 — Authentifier le destinataire de façon légère mais traçable¶

Le destinataire n'est pas anonyme : à l'ouverture du lien, il doit prouver qu'il est bien la personne à qui le propriétaire a confié le lien. Le PO a nommé OTP par email comme mécanisme d'authentification légère minimal. L'identité du destinataire doit être reliée de façon traçable aux événements d'accès générés.

OBJ-3 — Donner accès à la preuve complète, pas seulement au document¶

Le destinataire doit pouvoir consulter :

• le document lui-même (contenu déchiffré côté client ou présenté en lecture seule),
• les éléments cryptographiques associés : empreinte (hash), preuve Merkle, jeton d'horodatage TSA, ancrage blockchain,
• les métadonnées probatoires pertinentes (date de création de la preuve, titulaire, version).

Sans ces éléments, le tiers ne peut pas constater la valeur probatoire — il verrait un simple document, ce qui viderait ProbatioVault de son intérêt.

OBJ-4 — Offrir un export vérifiable de façon autonome¶

Le destinataire doit pouvoir exporter une preuve composite (document + éléments cryptographiques + journal d'accès) qu'un tiers lui-même (juge, expert) peut vérifier sans dépendre de ProbatioVault. La preuve doit survivre à une éventuelle indisponibilité, liquidation ou compromission de la plateforme.

OBJ-5 — Préserver l'intégrité et la valeur probatoire de la preuve originale¶

L'opération de partage ne doit jamais altérer la preuve originale :

• aucune modification du document stocké dans le SAE,
• aucune duplication du document côté serveur,
• aucune dégradation de l'ancrage existant,
• aucune création d'une "copie probatoire" parallèle non maîtrisée.

OBJ-6 — Donner au propriétaire un contrôle granulaire et réversible¶

Le propriétaire doit pouvoir, à tout moment :

• définir une durée de vie (TTL) du lien configurable,
• révoquer le lien instantanément avant son expiration,
• consulter la liste des liens actifs qu'il a émis,
• voir les accès qui ont eu lieu sur chaque lien (qui, quand, depuis où si l'information est disponible).

OBJ-7 — Tracer tous les accès de façon probatoire¶

Chaque action significative (génération, activation, consultation, export, révocation, expiration) doit être enregistrée dans un journal append-only lui-même scellé cryptographiquement et ancré, de sorte que l'existence d'un accès à la preuve à un instant donné soit elle-même une preuve vérifiable.

OBJ-8 — Respecter le modèle zero-knowledge de la plateforme¶

ProbatioVault garantit aujourd'hui que le serveur ne peut pas lire le contenu des preuves de ses utilisateurs. Cette propriété doit être strictement préservée par le mécanisme de partage : le serveur doit pouvoir faciliter la délégation sans jamais déchiffrer le document.

3. Non-objectifs (exclusions explicites)¶

NOBJ-1 — Pas de création de compte pour le destinataire¶

Le destinataire ne doit pas être invité à créer un compte ProbatioVault, même "light". Un compte suppose une identité durable, un mot de passe, une acceptation des CGU, potentiellement un KYC. Ce n'est pas le besoin ici.

NOBJ-2 — Pas de partage entre comptes ProbatioVault¶

Cette story ne traite pas le cas où deux utilisateurs disposent chacun d'un compte ProbatioVault et veulent partager une preuve entre eux. Ce cas pourrait réutiliser la même mécanique mais n'est pas dans le périmètre.

NOBJ-3 — Pas de modification de la preuve partagée¶

Le destinataire ne peut ni modifier, ni annoter, ni signer la preuve. Pas de collaboration, pas d'édition, pas de workflow de validation. Lecture seule stricte.

NOBJ-4 — Pas de re-partage par le destinataire¶

Le destinataire n'a pas le droit de générer à son tour un lien de partage vers un quatrième acteur. La chaîne de délégation s'arrête à lui. Si un re-partage est nécessaire, c'est au propriétaire original de le faire.

NOBJ-5 — Pas de révocation rétroactive¶

Une fois qu'un accès a eu lieu, il ne peut pas être "défait". La révocation ne concerne que les accès futurs. Le destinataire qui a consulté une preuve a pu en prendre connaissance ; ce fait est inéluctable et ne doit pas être masqué par une prétendue "révocation" de l'accès passé.

NOBJ-6 — Pas de duplication du document côté serveur¶

Aucune copie du document ne doit être créée. Le partage opère sur l'original (contrainte WORM du SAE). Seuls les objets d'autorisation / enveloppes d'accès peuvent être créés, copiés ou détruits.

NOBJ-7 — Pas de DRM, pas d'empêchement de capture d'écran¶

Le destinataire qui consulte la preuve peut techniquement la photographier, faire une capture d'écran, l'imprimer. ProbatioVault n'a pas vocation à empêcher cela. La valeur probatoire de la preuve ne repose pas sur la non-divulgation de son contenu mais sur la démonstration de son intégrité et de son antériorité.

NOBJ-8 — Pas de paiement, pas de monétisation du partage¶

Le partage est une fonctionnalité du compte du propriétaire. Il n'y a pas de paiement par le destinataire, pas de micro-transaction, pas d'escrow.

NOBJ-9 — Pas de messagerie intégrée¶

Le propriétaire transmet le lien par le canal qu'il choisit (hors plateforme). ProbatioVault n'intègre pas de chat ou de messagerie pour échanger avec le destinataire autour de la preuve partagée.

4. Contraintes¶

4.1 Contraintes techniques (imposées par le PO)¶

CTR-TECH-1 — Délégation via Proxy Re-Encryption (PRE) Le PO impose explicitement l'usage d'un schéma de PRE : la délégation d'accès s'effectue par transformation cryptographique des enveloppes d'accès, sans jamais exposer les clés du propriétaire ni le contenu déchiffré au serveur. Tout autre mécanisme (partage par copie, lien signé simple, mot de passe commun, transmission directe de clé) est exclu.

CTR-TECH-2 — Identité cryptographique éphémère pour le destinataire Le destinataire se voit attribuer une paire de clés + un certificat temporaire à usage limité au partage, créés dynamiquement. Cette identité n'est pas un compte : elle n'a pas vocation à persister au-delà de la durée de vie du lien.

CTR-TECH-3 — Authentification légère par OTP email L'activation du lien par le destinataire requiert un OTP envoyé par email. Le PO a nommé ce canal ; d'autres canaux (SMS, app authenticator) ne sont pas dans le périmètre.

CTR-TECH-4 — Respect strict du WORM Aucune duplication, aucune mutation du document original. Les seules mutations tolérées sont la création, la révocation et l'expiration des objets de délégation et d'autorisation.

CTR-TECH-5 — Respect strict du zero-knowledge Le serveur ne doit jamais avoir accès au contenu déchiffré de la preuve pendant le partage. Les transformations cryptographiques doivent être conçues pour que le serveur manipule uniquement des objets chiffrés et des ré-encapsulations.

4.2 Contraintes juridiques et réglementaires¶

CTR-LEGAL-1 — Conformité RGPD Les données personnelles du destinataire (adresse email, traces d'accès) sont collectées. Base légale retenue par le PO : preuve et intérêt légitime du propriétaire. Principe de minimisation : ne collecter que ce qui est strictement nécessaire à l'authentification et à la traçabilité.

CTR-LEGAL-2 — Valeur probatoire préservée La preuve partagée doit rester admissible au sens de la réglementation française en vigueur (Code civil art. 1366-1368, eIDAS, exigences du SAE, AFNOR NF Z42-013 si applicable). Le fait qu'un tiers ait consulté la preuve ne doit pas diminuer sa recevabilité.

CTR-LEGAL-3 — Traçabilité opposable Le journal d'accès doit être constitué de façon à être lui-même utilisable comme preuve (append-only, horodaté, ancré).

CTR-LEGAL-4 — Droit à l'information du destinataire Le destinataire doit savoir qu'il est identifié et tracé, pourquoi, sur quelle base légale, et pendant combien de temps les données le concernant seront conservées.

4.3 Contraintes organisationnelles et opérationnelles¶

CTR-ORG-1 — Latence de génération du lien Quelques secondes maximum pour générer le lien côté propriétaire (sans préciser ici la valeur cible, qui relève de la spécification).

CTR-ORG-2 — Aucun support opérateur pour le destinataire ProbatioVault ne dispose pas d'un service de support orienté destinataires externes. L'expérience destinataire doit être autosuffisante : si le lien ne fonctionne pas, le destinataire revient vers le propriétaire, pas vers ProbatioVault.

CTR-ORG-3 — Aucune donnée transverse destinataire Un même email destinataire utilisé sur plusieurs partages par plusieurs propriétaires différents ne doit pas conduire à la création d'un profil transverse, ni à un historique inter-partages consultable par qui que ce soit.

4.4 Contraintes temporelles¶

CTR-TIME-1 — TTL configurable La durée de vie du lien est configurable par le propriétaire à la création. Les bornes min/max ne sont pas fixées par le PO à ce stade (question ouverte — cf §7).

CTR-TIME-2 — Révocation instantanée Dès que le propriétaire révoque, aucun nouvel accès n'est possible (propagation à définir en spec, mais l'attente du PO est "instantané" du point de vue utilisateur).

CTR-TIME-3 — Durée de conservation du journal Les traces d'accès doivent être conservées au moins aussi longtemps que la preuve elle-même, potentiellement au-delà si la réglementation probatoire l'exige.

5. Scénarios d'échec et résultats inacceptables¶

SE-1 — Le document fuite à un tiers non autorisé¶

Un tiers qui n'est pas le destinataire nommé parvient à consulter la preuve (par interception du lien, par partage du code OTP, par vol de session). Inacceptable : la délégation doit être réellement ciblée sur le destinataire identifié, et pas sur "quiconque possède le lien".

SE-2 — Le serveur ProbatioVault parvient à lire le document¶

Un opérateur malveillant, ou un serveur compromis, parvient à déchiffrer le contenu de la preuve à l'occasion du partage. Inacceptable : violerait le zero-knowledge constitutif de la promesse ProbatioVault.

SE-3 — Le document original est altéré ou dupliqué¶

À l'occasion de la génération d'un lien ou d'une consultation, le document subsistant dans le SAE est modifié, ou une copie probante indépendante est créée hors du SAE. Inacceptable : détruirait la valeur probatoire et violerait WORM.

SE-4 — Un destinataire révoqué continue à accéder¶

Le propriétaire révoque le lien, mais le destinataire parvient malgré tout à consulter la preuve ensuite (cache côté client, session non invalidée, délégation persistante non détruite). Inacceptable côté UX et côté juridique : le propriétaire doit pouvoir compter sur sa révocation.

SE-5 — Un destinataire expiré continue à accéder¶

Le TTL est dépassé mais le destinataire peut encore consulter. Même gravité que SE-4.

SE-6 — L'ancrage probatoire est perdu pour un tiers¶

Le destinataire consulte "un document" mais n'a aucun moyen de constater que c'est bien la preuve ancrée (pas d'accès au hash, à la Merkle, à la TSA). Inacceptable : la fonction fondamentale de ProbatioVault (apporter la preuve, pas le document) n'est plus remplie.

SE-7 — L'export composite n'est pas vérifiable hors ProbatioVault¶

Le destinataire exporte un "dossier de preuve" mais ce dossier nécessite un appel à l'API ProbatioVault pour être vérifié. Inacceptable : la preuve doit survivre à la plateforme.

SE-8 — Un propriétaire ne parvient pas à révoquer¶

Pour une raison technique (propagation lente, incohérence d'état), la révocation ne prend pas effet. Le propriétaire croit avoir coupé l'accès mais ne l'a pas. Inacceptable : l'UI ne doit pas mentir à l'utilisateur sur l'état effectif.

SE-9 — Le journal d'accès peut être truqué¶

Un opérateur ou un attaquant parvient à supprimer, modifier ou réécrire une entrée du journal d'accès. Inacceptable : le journal est lui-même probatoire.

SE-10 — Un destinataire peut énumérer d'autres preuves¶

Par des messages d'erreur différenciés, des codes HTTP distincts, ou des comportements observables, le destinataire parvient à déduire l'existence d'autres preuves ou d'autres liens sur la plateforme. Inacceptable — aligné sur le learning anti-enumeration des REX PD-283/PD-282/PD-265.

SE-11 — Fuite de données personnelles du destinataire¶

L'email du destinataire, son IP, ses horaires d'accès se retrouvent exposés à d'autres utilisateurs, indexés par un moteur de recherche, ou conservés au-delà de la période prévue. Inacceptable — violation RGPD.

SE-12 — Un destinataire subit un phishing au nom de ProbatioVault¶

Un attaquant, observant que des liens ProbatioVault circulent, imite le design du portail destinataire pour récolter des OTP ou des identifiants. Le destinataire, qui n'est pas un utilisateur aguerri de la plateforme, est la cible naturelle. À anticiper dans la conception (UX anti-phishing) même si la responsabilité du filtrage mail incombe au destinataire.

SE-13 — Un lien peut être réutilisé indéfiniment après première consultation¶

Le PO parle de "consultation" et pas de "consultation unique". Cependant, si un lien reste actif pour un usage illimité pendant toute sa durée de vie, cela élargit la surface d'attaque en cas de compromission du canal de transmission. Tension — cf §6.

SE-14 — Impossibilité de prouver a posteriori qu'un accès n'a pas eu lieu¶

Un propriétaire doit pouvoir, devant un juge, produire l'affirmation "tel avocat n'a pas consulté cette pièce avant telle date" et que cette affirmation soit soutenue par le journal. Si le journal ne permet que de prouver les accès qui ont eu lieu, sans permettre de prouver l'absence d'accès, la valeur probatoire est asymétrique. À clarifier — cf §7.

6. Tensions et conflits non résolus¶

TEN-1 — Simplicité d'accès destinataire vs robustesse de l'authentification¶

Le destinataire n'a pas de compte et n'est pas client. Chaque étape supplémentaire (OTP, MFA, captcha, re-OTP à chaque session) augmente la friction et le taux d'abandon. Mais moins de friction = plus grande surface d'attaque en cas de vol du lien ou du canal email. Non résolue : le PO a nommé "OTP email" mais n'a pas tranché si un seul OTP suffit pour toute la durée de vie du lien, ou si chaque session exige un nouvel OTP.

TEN-2 — Contrôle total du propriétaire vs besoin du destinataire¶

Le propriétaire peut révoquer à tout moment, y compris par inadvertance ou malveillance. Le destinataire, qui a été associé à un dossier professionnel (un avocat qui prépare une audience), peut se voir couper l'accès sans préavis. Non résolue : aucune garantie de stabilité côté destinataire n'est exigée, ce qui est peut-être un vrai trou fonctionnel.

TEN-3 — Zero-knowledge vs traçabilité nominative¶

Plus on enrichit le journal d'accès (email exact, IP, user-agent, horodatage précis, durée de consultation), plus la traçabilité probatoire est forte — mais plus la plateforme "sait" de choses sur des personnes qui n'ont pas créé de compte. Non résolue : où placer le curseur entre opposabilité probatoire et minimisation RGPD ?

TEN-4 — Preuve composite exportable vs confidentialité¶

Une preuve composite exportée hors plateforme contient potentiellement : le document, le hash, le jeton TSA, l'ancrage, des informations sur qui a consulté quand. Si le destinataire l'exporte, il emporte avec lui ces informations, y compris potentiellement sur d'autres accès. Non résolue : quel périmètre du journal apparaît dans l'export ?

TEN-5 — Une seule consultation vs consultations illimitées sur TTL¶

Un lien "utilisable une fois et c'est fini" est plus sûr mais peu pratique (l'avocat veut revenir sur la pièce pendant deux semaines). Un lien utilisable en illimité pendant le TTL est pratique mais élargit la fenêtre d'attaque. Non résolue : le PO n'a pas tranché.

TEN-6 — Notification au propriétaire vs silence¶

Faut-il notifier le propriétaire à chaque consultation du destinataire ? Utile (je sais que mon avocat a bien lu la pièce) mais intrusif (50 consultations = 50 notifications) et révélateur (l'horaire de consultation peut renseigner le destinataire sur la surveillance). Le PO a listé ceci en "nice-to-have" sans trancher le cadencement.

TEN-7 — Identité éphémère du destinataire vs continuité¶

Si un destinataire reçoit deux liens du même propriétaire (deux pièces d'un même dossier), faut-il que ce soit la même identité cryptographique éphémère, ou deux identités distinctes ? La continuité simplifie l'UX (un seul OTP, un seul "compte" éphémère) mais crée une persistance qui frôle la notion de compte. Non résolue.

TEN-8 — PRE imposée vs non-objectif de faisabilité (au niveau besoin)¶

Le PO a imposé PRE dans les contraintes. Cela déborde sur le "comment", mais le PO juge que ce comment est constitutif du besoin (sans PRE, les invariants zero-knowledge / WORM ne tiennent pas). Tension méthodologique qu'il faut acter : cette EB nomme une technique, et c'est assumé.

TEN-9 — Révocation non rétroactive vs attente utilisateur intuitive¶

"Je révoque" est perçu par l'utilisateur courant comme "j'annule complètement". Mais techniquement, un accès passé ne peut pas être défait. Non résolue côté UX : comment formuler cela sans mentir ni effrayer ?

TEN-10 — Absence de DRM vs fuite volontaire du destinataire¶

Le destinataire peut techniquement capturer, imprimer, partager le contenu. On a choisi explicitement de ne pas lutter contre cela. Mais cette non-lutte est-elle visible / comprise par le propriétaire qui partage ? Non résolue : faut-il afficher un avertissement au propriétaire ("vous déléguez un droit de lecture — vous ne contrôlez pas les copies que le destinataire pourrait faire hors plateforme") ?

7. Questions ouvertes — Décisions PO (2026-04-19)¶

Q-1 — Bornes du TTL¶

Décision : Min 15 min, défaut 7 jours, max 30 jours. 15 min évite les liens quasi permanents, 30 jours couvre les usages avocat/autorité sans dériver vers une cession déguisée.

Q-2 — OTP unique ou OTP par session¶

Décision : OTP demandé à l'activation puis à chaque nouvelle session, avec réauthentification après inactivité longue. Cohérent avec un accès ponctuel et traçable.

Q-3 — Nombre de consultations¶

Décision : Par défaut illimité pendant TTL. Option configurable : plafond N. Pas de one-shot par défaut, trop fragile en pratique.

Q-4 — Notification du propriétaire¶

Décision : Off par défaut, activable. Si activé : temps réel. L'agrégation quotidienne est moins utile sur des accès sensibles ponctuels.

Q-5 — Comportement sur échec OTP¶

Décision : 5 tentatives max par session. Au-delà : blocage temporaire 15 min. Après 3 blocages : notification propriétaire + possibilité de révocation proactive. Pas de blocage définitif automatique.

Q-6 — Rechargement OTP¶

Décision : Oui, maximum 3 renvois par heure puis cooldown. Évite le vecteur d'abus/spam.

Q-7 — Canal email du destinataire vérifié ?¶

Décision : Le propriétaire saisit l'email cible et en porte la responsabilité métier. ProbatioVault vérifie seulement que le destinataire contrôle effectivement cette boîte via OTP.

Q-8 — Format et contenu de la preuve composite exportée¶

Décision : Format ZIP. Contenu : document consulté/exporté, preuve composite ProbatioVault en JSON canonique, script ou manifeste de vérification, rendu lisible humainement optionnel. Pas de PDF seul (trop pauvre par rapport au modèle de preuve composite).

Q-9 — Continuité d'identité inter-liens¶

Décision : Non. Une identité éphémère par lien. Plus propre, plus compartimenté, cohérent avec le caractère ponctuel.

Q-10 — Comportement après révocation pendant une session active¶

Décision : Blocage immédiat des nouvelles requêtes + fin de session forcée au prochain round-trip, avec délai technique minimal. Révocation quasi immédiate, pas "à la fin de session".

Q-11 — Consultation hors-ligne¶

Décision : Non pour le MVP. Consultation obligatoirement en ligne. Le hors-ligne chiffré réouvre trop de complexité (clés, cache local, contrôle d'accès).

Q-12 — Langue et accessibilité du portail destinataire¶

Décision : MVP français. UI conçue pour être multilingue ensuite. Accessibilité correcte par défaut, RGAA complet en exigence ultérieure.

Q-13 — Support erreurs destinataire¶

Décision : Bouton "renvoyer OTP" + message clair si lien expiré. Retour vers le propriétaire uniquement pour les cas non résolvables. Ne pas laisser le destinataire dans une impasse.

Q-14 — Quotas¶

Décision : Oui, par preuve, par compte et par période. Valeurs larges au départ, mais garde-fous d'abus dès le MVP.

Q-15 — Preuve d'absence d'accès¶

Décision : Non comme garantie forte au MVP. Le journal append-only montre l'absence d'événement enregistré, pas une preuve mathématique absolue. Pas de heartbeats signés pour cette story.

Q-16 — Rétention post-expiration¶

Décision : Droits actifs détruits/invalidés immédiatement à expiration. Traces probatoires conservées. Identité éphémère inactive, enveloppes PRE invalidées, audit conservé.

Q-17 — Anti-phishing¶

Décision : Oui, fortement. Domaine dédié ou sous-domaine clair, emails signés correctement, pas de champ mot de passe propriétaire, UX sobre et prévisible. Très important pour un flux avocat/autorité.

Q-18 — Avertissement au propriétaire sur absence de DRM¶

Décision : Oui. Mention claire : "la révocation bloque les accès futurs sur la plateforme, pas les copies déjà réalisées hors plateforme."

Q-19 — Révocation partielle¶

Décision : MVP tout-ou-rien. Pas de séparation consultation/export, trop de complexité.

Q-20 — Preuves groupées¶

Décision : Hors périmètre MVP. Un lien = une preuve. Le multi-preuves viendra plus tard.

8. Invariants de sécurité¶

Liste des propriétés qui doivent tenir à tout instant et sur lesquelles le workflow engagera la gouvernance (spec, tests, gates, vérif formelle). Ces invariants sont formulés au niveau du besoin, indépendamment de la solution technique.

INV-SEC-1 — Zero-knowledge serveur préservé¶

Aucun chemin d'exécution côté serveur ne doit permettre la lecture du contenu déchiffré d'une preuve partagée. Le serveur manipule uniquement des objets chiffrés et des transformations cryptographiques.

INV-SEC-2 — WORM preservé¶

Le document original dans le SAE n'est jamais modifié, dupliqué, déplacé ni réécrit par la mécanique de partage.

INV-SEC-3 — Délégation ciblée, pas "bearer link"¶

Le seul fait de posséder le lien ne donne pas accès à la preuve. Une authentification du destinataire (OTP email) est toujours requise. Un lien volé et non activé reste inactif si l'attaquant ne contrôle pas aussi la boîte email du destinataire.

INV-SEC-4 — Révocation effective¶

Après révocation par le propriétaire, plus aucun accès en lecture ne peut être servi par le système. Le délai entre l'action du propriétaire et l'effectivité doit être borné et documenté. Aucun canal secondaire (cache, session longue, téléchargement pré-révocation) ne doit permettre de contourner.

INV-SEC-5 — Expiration effective¶

Au-delà du TTL, aucun accès ne peut plus être servi. Même propriétés qu'INV-SEC-4.

INV-SEC-6 — Aucune révocation rétroactive des accès passés¶

Un accès enregistré avant la révocation reste enregistré. Le journal ne peut pas être "nettoyé" par la révocation.

INV-SEC-7 — Journal append-only et scellé¶

Le journal d'accès n'accepte que des ajouts. Les entrées existantes sont immuables. Leur intégrité est démontrable cryptographiquement et opposable à un tiers.

INV-SEC-8 — Anti-enumeration¶

Les messages d'erreur, codes HTTP et comportements observables (timing, taille de réponse) ne doivent pas permettre à un tiers de distinguer "ce lien n'existe pas" de "ce lien existe mais vous n'y avez pas droit" ni d'énumérer d'autres ressources. (Aligné learning REX PD-283 / PD-282 / PD-265.)

INV-SEC-9 — Non-propagation des droits¶

Le destinataire ne peut pas re-déléguer (cf. NOBJ-4). Aucun chemin ne doit permettre à un destinataire de créer un nouveau lien à partir du sien.

INV-SEC-10 — Isolation inter-partages¶

Deux partages distincts du même propriétaire vers des destinataires distincts ne doivent partager aucun secret réutilisable. La compromission d'un partage ne compromet pas les autres.

INV-SEC-11 — Minimisation et rétention maîtrisée des données destinataire¶

Seules les données strictement nécessaires à l'authentification et à la traçabilité sont collectées. Leur durée de rétention est définie, documentée et tenue.

INV-SEC-12 — Vérifiabilité autonome de la preuve composite¶

La preuve composite exportée par le destinataire est vérifiable sans connexion à ProbatioVault (cf. OBJ-4). La validité de l'export ne dépend pas de la disponibilité de la plateforme.

INV-SEC-13 — Identité éphémère du destinataire dissoluble¶

Les clés et certificats éphémères du destinataire peuvent être détruits proprement à l'expiration / révocation sans compromettre la vérifiabilité des traces d'accès passés.

INV-SEC-14 — Intégrité de la preuve originale démontrable après partage¶

Après N partages, il doit rester démontrable que la preuve originale n'a pas été altérée — les mêmes hash, TSA et ancrage demeurent vérifiables.

INV-SEC-15 — Tests roundtrip obligatoires sur les transformations cryptographiques¶

Toute primitive de chiffrement / ré-encapsulation / signature / vérification utilisée dans le flux doit disposer de tests roundtrip (aligné learning REX PD-282). Il est interdit de tester uniquement la partie "chiffrement" ou uniquement la partie "déchiffrement" en isolation.

INV-SEC-16 — Purge proactive des artefacts temporaires¶

Les objets temporaires (enveloppes PRE intermédiaires, buffers de ré-encapsulation, certificats expirés) sont purgés de façon proactive au démarrage des flux concernés, pas seulement en finally (aligné learning REX PD-283 / PD-262).

INV-SEC-17 — Trust-store destinataire strict¶

Si la vérification d'un certificat (destinataire, TSA, chaîne de signature) est requise, le trust-store est obligatoire et non optionnel (aligné learning REX PD-282).

9. Arbitrages — Décisions PO (2026-04-19)¶

ARB-1 — OTP unique vs OTP par session¶

Décision PO : Option © — OTP à l'ouverture d'une session + redemande après inactivité.

ARB-2 — Consultations illimitées vs plafonnées¶

Décision PO : Option (a) par défaut + (b) configurable.

ARB-3 — Notification propriétaire par défaut¶

Décision PO : Option (a) — off par défaut, activable. Si activé : temps réel.

ARB-4 — Bornes TTL¶

Décision PO : Min 15 min, défaut 7 jours, max 30 jours.

ARB-5 — Continuité d'identité éphémère inter-liens¶

Décision PO : Option (a) — 1 identité par lien.

ARB-6 — Contenu du journal exporté dans la preuve composite¶

Décision PO : Option © configurable, avec défaut (a) pour le MVP — uniquement les événements nécessaires à la preuve exportée, pas l'historique global. Évite la sur-exposition de données d'accès.

ARB-7 — Formulation UX de la révocation non-rétroactive¶

Décision PO : Texte retenu : "Révoquer ce lien empêchera tout accès futur via ProbatioVault. Les consultations ou copies déjà réalisées ne peuvent pas être annulées."

ARB-8 — Avertissement au partage sur absence de DRM¶

Décision PO : Option © — affiché une fois, puis mémorisé, avec possibilité de le revoir.

ARB-9 — Méthodologie : acceptation de la PRE nommée en contrainte¶

Décision PO : Confirmé. Invariant produit, pas un simple choix technique. Cohérent avec les principes fondateurs et le rôle du PRE dans l'architecture.

ARB-10 — Preuve d'absence d'accès¶

Décision PO : Non pour le MVP. Le journal append-only prouve les accès enregistrés, pas l'absence forte d'accès par heartbeats signés. Trop coûteux et trop théorique pour cette story.

10. Périmètre MVP (synthèse PO)¶

Un utilisateur peut créer un lien temporaire donnant accès à une preuve unique, en lecture seule, à un tiers externe sans compte persistant. L'accès repose sur une identité éphémère créée pour ce lien, activée via OTP email, avec délégation PRE stricte, traçabilité complète, expiration configurable, révocation quasi immédiate et sans duplication du document WORM.

In scope MVP : - Une preuve par lien - Online only - OTP par session + réauth après inactivité - TTL 15 min à 30 jours (défaut 7j) - Révocation tout-ou-rien - Export ZIP probatoire (nice-to-have) - Notifications optionnelles (nice-to-have) - Quotas (valeurs larges) - Français, UI multilingue-ready

Out of scope MVP : - Preuve d'absence d'accès forte (heartbeats) - Multi-preuves par lien - Consultation hors-ligne - Révocation partielle (consultation vs export) - RGAA complet - Re-partage par le destinataire

Fin de l'Expression de Besoin PD-287.