PD-251 — Expression de Besoin¶

1. Contexte¶

ProbatioVault est un système d'archivage à valeur probante conforme ISO 14641 et NF Z42-013. L'audit de conformité (PD-244) a identifié un écart GAP-FINAL-016 (NF Z42-013 §11.1) : la vérification d'intégrité des archives est possible à la demande, mais aucun mécanisme de vérification périodique automatisé n'existe.

Le rapport d'audit formel ISO 14641 (vérification Prolog check_iso_6_2_periodic_integrity) confirme cet écart : le check est en FAIL — aucun cron de vérification d'intégrité n'est référencé dans le code source.

La chaîne de preuve actuelle comprend quatre maillons : - Les documents archivés en stockage WORM (S3/OVH) avec hash SHA3 - Les arbres Merkle persistés regroupant les preuves par lots - Les horodatages certifiés TSA (RFC 3161) - Les ancres blockchain (racines Merkle ancrées sur Ethereum L2)

Chaque maillon dispose de services de vérification unitaire opérationnels. Il manque un processus automatisé qui vérifie périodiquement l'ensemble de cette chaîne et réagit de manière graduée en cas de corruption détectée.

L'epic parent PD-217 (LEGAL & COMPLIANCE) encadre cette exigence.

2. Objectifs principaux¶

O1 — Vérification périodique bout-en-bout¶

Vérifier automatiquement et périodiquement l'intégrité de la chaîne de preuve complète : documents archivés (hash SHA3), arbres Merkle, timestamps TSA et ancres blockchain.

O2 — Détection de toute corruption¶

Toute altération, même partielle, d'un maillon de la chaîne de preuve doit être identifiée et signalée. Aucune corruption ne doit rester invisible.

O3 — Double vérification indépendante avant gel¶

Un hash mismatch isolé ne suffit pas à déclencher le gel. Avant tout passage en SUSPECT, une double vérification indépendante est obligatoire pour éliminer les faux positifs (latence S3, erreur I/O transitoire, throttling AWS, lecture partielle).

Protocole de confirmation : 1. Relecture immédiate de l'objet via une nouvelle connexion S3 2. Recalcul SHA3 indépendant 3. Si toujours mismatch → lecture via endpoint alternatif (HEAD + GET) 4. Si mismatch confirmé après double vérification → passage en SUSPECT

Limites : - Maximum 2-3 tentatives de vérification, pas de boucle infinie - Journalisation de chaque tentative (hash calculé, timestamp, méthode, résultat)

O4 — Réaction graduée et traçable¶

Après confirmation par double vérification (O3), le système enchaîne quatre phases :

Phase 1 — Gel : - Marquage de l'archive comme SUSPECT - Blocage de la lecture publique et de l'export - Entrée dans le journal append-only signé

Phase 2 — Snapshot forensique : - Capture du hash actuel vs hash attendu - Capture de la Merkle proof - Capture de l'état TSA + blockchain - Signature HSM de l'ensemble du snapshot

Phase 3 — Tentative de restauration contrôlée : - Restauration depuis le réplica CRR Francfort - Recalcul du hash - Comparaison avec le hash original - Si cohérent → statut RESTORED (nouvelle version restaurée, ancienne marquée CORRUPTED_ARCHIVED) - Sinon → statut CORRUPTED_CONFIRMED

Phase 4 — Rapport d'incident probatoire : - Génération d'un rapport signé au double format : JSON canonicalisé signé HSM (machine-readable) + PDF signé (human-readable) - Le rapport trace l'ensemble de l'incident : détection, tentatives de vérification, gel, forensique, restauration, résultat

O5 — Alerting incident management¶

Intégration PagerDuty/OpsGenie pour escalade automatique en cas de corruption. Le workspace PagerDuty est à provisionner — PD-251 doit prévoir une abstraction (interface Notifier) permettant de brancher le provider concret.

O6 — Notification conditionnelle du propriétaire¶

Au-delà de l'alerting ops (PagerDuty), le propriétaire de l'archive est notifié directement sous conditions strictes :

Canal de notification propriétaire : email signé + notification in-app + rapport d'incident attaché.

Justification : éviter la panique sur des incidents infra transitoires, mais garantir la transparence et la conformité RGPD en cas d'incident confirmé impactant les données.

O7 — Devenir des archives CORRUPTED_CONFIRMED¶

Une archive corrompue ne peut jamais être supprimée. En probatoire, une archive corrompue est un événement historique — la suppression serait destructrice de preuve.

Comportement obligatoire : - Lecture et export bloqués - Statut visible par le propriétaire - Rapport d'incident probatoire généré et signé - Archive conservée en WORM (même corrompue) - Hash actuel ET hash attendu conservés

Restauration réussie (CRR sain) — modèle de versionnement probatoire : - Création d'une nouvelle version restaurée de l'archive - Ancienne version marquée CORRUPTED_ARCHIVED - Chaînage cryptographique entre les deux versions - Ancrage blockchain du rétablissement

Ce modèle transforme un incident en événement probatoire maîtrisé, renforçant la confiance dans le système.

O8 — Métriques d'observabilité¶

Exposition Prometheus des indicateurs de santé : nombre d'archives vérifiées par run, taux de corruption, durée des runs, nombre d'archives en statut SUSPECT/RESTORED/CORRUPTED_CONFIRMED/CORRUPTED_ARCHIVED.

O9 — Fréquence et périmètre configurables¶

La périodicité et le scope des vérifications doivent être paramétrables (expression cron). La fréquence doit pouvoir varier selon la criticité des archives.

O10 — Priorisation multi-critères¶

Les archives n'ont pas toutes le même niveau de criticité. La priorisation doit intégrer trois critères : - Statut juridique : archives liées à des procédures en cours = haute priorité - Âge : archives récentes vérifiées plus souvent - Criticité contractuelle : selon le plan de l'utilisateur / nature du document

O11 — SLA de détection à deux niveaux¶

• Archives haute criticité (procédures actives, récentes) : détection sous 1 heure
• Archives basse criticité (dormantes, anciennes) : détection sous 24 heures

O12 — Rapport d'intégrité par run¶

Chaque exécution du job produit un rapport structuré consultable, même quand aucune anomalie n'est détectée. Rétention configurable par politique (paramétrable, pas de durée imposée).

O13 — Design for scale¶

Le mécanisme doit supporter la montée en charge dès le départ (partitionnement du scope, scope rotatif, parallélisme) indépendamment du volume actuel d'archives.

3. Non-objectifs (exclusions explicites)¶

• Pas de correction silencieuse : le système ne doit jamais remplacer une archive sans traçabilité complète de l'incident. Même une restauration réussie doit être journalisée et signée.
• Pas de vérification en temps réel : ce besoin concerne un processus périodique (batch), pas un contrôle à chaque accès.
• Pas de refonte des services de vérification existants : les services unitaires (IntegrityVerifier, MerkleTreeService, TSA, Anchor) sont réutilisés tels quels.
• Pas de remédiation des ancres blockchain : si une ancre blockchain est corrompue ou absente, le système signale mais ne peut pas la recréer (immutabilité de la blockchain).
• Pas de provisionnement effectif PagerDuty : PD-251 fournit l'abstraction et l'intégration webhook, pas la création du compte PagerDuty.

4. Contraintes¶

Juridiques et réglementaires¶

• NF Z42-013 §11.1 : exige une vérification périodique de l'intégrité des archives avec traçabilité.
• ISO 14641 §6.2 : vérification d'intégrité périodique (check Prolog actuellement en FAIL).
• Valeur probante : toute action sur une archive suspecte (gel, restauration, rapport) doit elle-même être probante (signature HSM, horodatage TSA).
• ISO 14641 §9 : le seal du rapport d'incident doit être cohérent avec le security level du système (Strong → HSM FIPS).

Opérationnelles¶

• Le job ne doit pas dégrader les performances du système en production.
• Le volume d'archives croît avec le temps — le partitionnement est nécessaire dès le départ.
• La restauration depuis CRR Francfort implique une latence réseau significative.
• En cas d'indisponibilité CRR : retry automatique borné, maintien du statut SUSPECT, escalade après dépassement du SLA de restauration.

Techniques¶

• Dépendance aux services existants : MerkleTreeService (PD-237), IntegrityVerifierService (PD-60), TSA (PD-39), Anchor (PD-55), HSM (PD-36/37).
• Dépendance au stockage CRR Francfort (PD-6) pour la restauration.
• Infrastructure BullMQ existante pour les jobs périodiques.
• Génération PDF signée : nécessite une librairie de génération PDF + signature (PAdES ou signature détachée).

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

6. Tensions et conflits non résolus¶

1. Exhaustivité vs Performance : vérifier la chaîne complète bout-en-bout pour chaque archive à chaque run impose une charge proportionnelle au volume. Le scope rotatif et la priorisation multi-critères atténuent cette tension, mais l'arbitrage entre profondeur de vérification et impact performance reste à calibrer en implémentation.

2. Restauration automatique vs Investigation forensique : la tentative de restauration modifie l'état de l'archive. Le séquencement (snapshot forensique PUIS restauration) est impératif et doit être atomique. Aucune restauration ne peut démarrer tant que le snapshot n'est pas signé HSM.

3. Signature HSM en cas de corruption massive : en cas d'attaque, le nombre de snapshots forensiques signés HSM pourrait être élevé. Un mécanisme de regroupement (batch de signatures) ou de rate limiting peut être nécessaire.

4. Chaînage cryptographique version corrompue → version restaurée : le mécanisme exact de chaînage (hash de l'ancienne version dans les metadata de la nouvelle) et son ancrage blockchain doivent être définis en spécification.

7. Questions ouvertes¶

Aucune — toutes les questions ont été tranchées par le PO lors de l'expression de besoin.