PD-55 — Expression de besoin¶
Metadata¶
| Champ | Valeur |
|---|---|
| Story ID | PD-55 |
| Titre | Créer worker ancrage blockchain périodique |
| Epic | PD-187 (BLOCKCHAIN) |
| Projet | ProbatioVault-backend |
| Domaine | blockchain |
| Priorité | High |
| Labels | async, blockchain, worker |
1. Contexte¶
ProbatioVault repose sur un modèle de preuve composite ancrée, combinant :
- Journal append-only immuable (WORM)
- Agrégation par arbre de Merkle
- Signature probatoire
- Horodatage qualifié (RFC 3161)
- Ancrage périodique sur blockchain publique
Tel que décrit dans l'Architecture Executive v4.1 et dans la fiche brevet "Preuve Composite Ancrée".
L'ancrage blockchain constitue la couche publique d'inaltérabilité permettant :
- La vérification indépendante hors système
- La recevabilité probatoire
- La transparence d'audit
Pour garantir la cohérence et la continuité de cette chaîne de confiance, un mécanisme périodique d'ancrage doit être opéré automatiquement.
2. Problématique¶
Les événements probatoires (création, re-chiffrement, révocation, transfert, etc.) sont générés en continu.
Sans mécanisme d'agrégation et d'ancrage périodique :
- La preuve resterait interne au système
- La vérifiabilité publique serait absente
- La chaîne probatoire serait juridiquement affaiblie
- La conformité aux exigences NF Z42-013 / ISO 14641 serait incomplète
Il est donc nécessaire d'assurer un ancrage régulier, fiable et traçable, sans intervention manuelle.
3. Objectif du besoin¶
Mettre en place un mécanisme automatique et périodique permettant :
- D'agréger les événements probatoires produits sur une fenêtre temporelle définie
- De produire une empreinte racine représentative (Merkle root)
- D'ancrer cette empreinte sur une blockchain publique
- D'enregistrer l'identifiant de transaction associé
- De garantir la traçabilité complète entre événements internes et transaction publique
4. Résultat attendu¶
À intervalles réguliers (cible : toutes les 10 minutes) :
- Tous les événements probatoires non encore ancrés sont agrégés
- Une racine cryptographique unique est générée
- Cette racine est publiée sur une blockchain publique
- L'identifiant de transaction (tx_id) est enregistré
- Chaque événement concerné devient rattachable à :
- Un Merkle root
- Une transaction blockchain identifiable
- Un horodatage vérifiable publiquement
5. Invariants fonctionnels attendus¶
Le mécanisme doit garantir :
| ID | Invariant | Description |
|---|---|---|
| INV-55-01 | Aucune exposition de contenu | Seuls des hashes sont ancrés |
| INV-55-02 | Idempotence | Aucun double ancrage involontaire |
| INV-55-03 | Traçabilité complète | Chaque événement doit pouvoir être rattaché à un ancrage |
| INV-55-04 | Continuité temporelle | Aucune fenêtre probatoire non couverte |
| INV-55-05 | Auditabilité externe | Vérification possible sans coopération de ProbatioVault |
6. Contraintes et tensions à préserver¶
Le besoin comporte plusieurs exigences concurrentes :
| Exigence | Tension associée |
|---|---|
| Ancrage fréquent | Coût blockchain |
| Mutualisation des événements | Latence probatoire |
| Publication publique | Protection des métadonnées |
| Automatisation complète | Robustesse en cas d'échec |
| Vérifiabilité externe | Complexité de preuve |
Ces tensions ne doivent pas être résolues à ce stade : elles structurent les choix futurs.
7. Résultats inacceptables¶
Sont considérés comme inacceptables :
- Perte d'événements non ancrés
- Ancrage d'un ensemble partiel sans traçabilité
- Ancrage non vérifiable publiquement
- Absence d'association explicite entre événement interne et transaction blockchain
- Possibilité de modification post-ancrage
- Dépendance exclusive à une seule chaîne sans stratégie de continuité
8. Intention stratégique¶
Ce worker ne constitue pas une simple tâche technique.
Il représente :
- Le point de bascule entre système interne et registre public
- La matérialisation du pilier "Auditabilité" de l'Architecture Executive
- L'un des fondements de la revendication de brevet "Preuve Composite Ancrée"
- Un élément différenciant majeur face aux solutions de stockage classiques
Il transforme un journal interne en preuve opposable, indépendante et pérenne.
9. Dépendances¶
| Story | Titre | Statut | Nature |
|---|---|---|---|
| PD-52 | Ethereum L2 setup | DONE | Infrastructure blockchain (provider, wallet, config) |
| PD-53 | Smart contract Merkle anchor | DONE | Contrat Solidity pour ancrage Merkle root |
| PD-237 | Merkle persistence | DONE | Service de persistance des arbres Merkle |
10. Hors périmètre¶
- Interface utilisateur de visualisation des ancrages (story dédiée)
- Multi-chain simultané (prévu mais hors scope initial)
- Mécanisme de fallback automatique vers autre blockchain
11. Learnings pertinents¶
Issus de la recherche sémantique au démarrage du workflow.
- PD-44 : Security sanitization Gate 8, S3 key validation, KMS, constant-time
- PD-40 : Append-only simplifie gestion erreurs, canonicalisation RFC 8785 systématique
- BATCH-RETRO : Object Lock COMPLIANCE irréversible pour WORM probatoire
12. Conclusion¶
PD-55 vise à garantir que la production continue d'événements probatoires aboutit systématiquement à une publication cryptographique publique, périodique et traçable.
Ce besoin est fondamental :
Sans ancrage périodique fiable, ProbatioVault ne serait qu'un coffre-fort sécurisé.
Avec ancrage périodique robuste, il devient une infrastructure de confiance publique vérifiable.