PD-251 — Tests & Validation (référence contractuelle, v2)¶

1) Matrice de couverture INV/CA -> TC¶

1.1 Couverture des invariants¶

1.2 Couverture des critères d'acceptation (CA)¶

2) Scénarios de test détaillés (Given/When/Then)¶

Préconditions communes (déterminisme)¶

• Horloge de test figée (T0) et progression contrôlée.
• Jeu d'archives fixe :
• A-HC-001 (haute criticité),
• A-LC-001 (basse criticité),
• A-CORR-001 (payload corrompu),
• A-REST-001 (éligible restauration).
• Hash de référence (SHA3), preuve Merkle, timestamp TSA et ancre blockchain connus/figés.
• Endpoints stockage primaire et alternatif simulés de façon reproductible.
• Journal d'audit et signatures vérifiables cryptographiquement.
• Toute erreur simulée est injectée explicitement (pas d'aléa).

TC-251-01 — Exécution périodique et rapport systématique de run¶

• INV/CA couverts : INV-251-01, INV-251-14, CA-251-01, CA-251-14
• Prérequis : scheduler actif, scopeRotationWindow configuré.
• Given : deux fenêtres temporelles successives avec périmètres distincts.
• When : le scheduler déclenche deux runs périodiques.
• Then : chaque run traite un périmètre conforme à la rotation et génère un rapport, y compris si aucune anomalie.
• Résultat attendu : 2 rapports de run présents, horodatés, non vides, avec statut de conformité explicite.
• Automatisable : Oui

TC-251-02 — Couverture complète des 4 maillons avec statut explicite¶

• INV/CA couverts : INV-251-02, INV-251-16, CA-251-02
• Prérequis : archive avec 4 artefacts disponibles.
• Given : un run incluant A-HC-001.
• When : la vérification de la chaîne de preuve est exécutée.
• Then : les 4 maillons (document, Merkle, TSA, blockchain) retournent chacun OK/KO/INDETERMINE.
• Résultat attendu : aucune archive du scope n'est marquée "vérifiée" si un maillon est absent ou sans statut explicite.
• Automatisable : Oui

TC-251-03 — Double vérification : faux positif I/O transitoire¶

• INV/CA couverts : INV-251-03, INV-251-16, CA-251-03
• Prérequis : première lecture primaire en erreur transitoire, relectures cohérentes.
• Given : A-CORR-001 avec échec simulé sur 1re tentative puis hash conforme.
• When : la séquence de double vérification est lancée.
• Then : la 2e/3e vérification invalide le soupçon initial.
• Résultat attendu : pas de transition vers SUSPECT, statut final non-corrompu, trace complète des tentatives.
• Automatisable : Oui

TC-251-04 — Double vérification : corruption confirmée -> SUSPECT + blocage¶

• INV/CA couverts : INV-251-03, CA-251-04
• Prérequis : mismatch persistant sur primaire et alternatif.
• Given : hash observé différent du hash attendu sur toutes tentatives.
• When : la séquence de double vérification se termine.
• Then : la transition HEALTHY -> SUSPECT est appliquée ; accès publics et export bloqués immédiatement.
• Résultat attendu : état SUSPECT atteint uniquement après confirmation multi-tentatives ; blocage effectif des accès.
• Automatisable : Oui

TC-251-05 — Validation des bornes de configuration des tentatives¶

• INV/CA couverts : INV-251-04, CA-251-04
• Prérequis : moteur de validation de config actif.
• Given : jeux de configs verificationAttemptsMax (1,2,3,4), attemptTimeout hors bornes, attemptInterval hors bornes.
• When : la configuration est chargée.
• Then : hors bornes critiques rejetées, attemptInterval clamped selon contrat.
• Résultat attendu : [2,3] strict pour tentatives ; rejets explicites et traçables.
• Automatisable : Oui

TC-251-06 — Journal append-only signé des tentatives¶

• INV/CA couverts : INV-251-05, CA-251-05
• Prérequis : mécanisme de signature et vérification disponible.
• Given : une archive subit 3 tentatives de vérification.
• When : les événements sont écrits en journal.
• Then : chaque entrée contient timestamp, méthode, hash calculé, résultat, cause d'échec éventuelle ; aucune modification/suppression possible.
• Résultat attendu : journal vérifiable (append-only + signature valide).
• Automatisable : Oui

TC-251-07 — Gel effectif des accès publics¶

• INV/CA couverts : INV-251-06, CA-251-06
• Prérequis : archive en SUSPECT.
• Given : demandes de lecture publique et d'export sur archive suspecte.
• When : les demandes sont exécutées.
• Then : lecture/export publics sont bloqués ; les opérations d'investigation autorisées restent possibles.
• Résultat attendu : blocage strict conforme à la phase de gel.
• Automatisable : Oui

TC-251-08 — Snapshot forensique signé obligatoire avant restauration¶

• INV/CA couverts : INV-251-07, CA-251-05, CA-251-07
• Prérequis : archive SUSPECT, HSM disponible.
• Given : tentative de passage en RESTORE_PENDING.
• When : snapshot forensique est absent, puis présent/signé.
• Then : sans snapshot signé, transition refusée ; avec snapshot signé, transition autorisée.
• Résultat attendu : précondition de signature HSM strictement enforced.
• Automatisable : Oui

TC-251-09 — Restauration réussie déterministe + versionnement¶

• INV/CA couverts : INV-251-08, INV-251-17, CA-251-08
• Prérequis : RESTORE_PENDING, CRR disponible.
• Given : restauration de A-REST-001 et recalcul hash post-restauration cohérent.
• When : la restauration est finalisée.
• Then : état final RESTORED; version restaurée créée avec traçabilité de filiation.
• Résultat attendu : résultat reproductible et chaîne de versionnement probatoire intacte.
• Automatisable : Oui

TC-251-10 — Restauration échouée : corruption confirmée sans suppression¶

• INV/CA couverts : INV-251-08, INV-251-09, INV-251-17, CA-251-08
• Prérequis : RESTORE_PENDING, hash post-restauration incohérent.
• Given : tentative de restauration produisant mismatch persistant.
• When : le contrôle post-restauration s'achève.
• Then : état CORRUPTED_CONFIRMED; conservation des versions antérieures et archivage de la version corrompue.
• Résultat attendu : aucune suppression silencieuse ; historique probatoire complet.
• Automatisable : Oui

TC-251-11 — États terminaux fermés¶

• INV/CA couverts : INV-251-10, CA-251-16
• Prérequis : archive en CORRUPTED_CONFIRMED puis CORRUPTED_ARCHIVED.
• Given : requêtes de transitions sortantes depuis états terminaux.
• When : transitions sont demandées.
• Then : toutes refusées avec code et motif, sans effet de bord.
• Résultat attendu : clôture stricte des états terminaux.
• Automatisable : Oui

TC-251-12 — Notification propriétaire strictement conditionnelle¶

• INV/CA couverts : INV-251-11, CA-251-15
• Prérequis : canaux email signé + in-app + attachement rapport disponibles.
• Given : 3 cas (SUSPECT simple, CORRUPTED_CONFIRMED, indisponibilité > restoreSla).
• When : le moteur de notification évalue les règles.
• Then : notification propriétaire uniquement dans les 2 cas autorisés ; alerte ops selon contrat.
• Résultat attendu : absence de sur-notification et absence d'omission.
• Automatisable : Oui

TC-251-13 — Rapport d'incident probant (JSON canonique + PDF signé)¶

• INV/CA couverts : INV-251-12, CA-251-09
• Prérequis : incident confirmé.
• Given : génération d'un rapport d'incident.
• When : production des artefacts JSON et PDF.
• Then : JSON canonicalisé RFC 8785 et signé HSM ; PDF signé ; cohérence entre contenus.
• Résultat attendu : artefacts probants, vérifiables, traçables.
• Automatisable : Oui

TC-251-14 — SLA de détection 1h/24h et gestion des dépassements¶

• INV/CA couverts : INV-251-13, CA-251-10, CA-251-15
• Prérequis : archives haute/basse criticité, horloge contrôlée.
• Given : détection simulée à T0+59m, T0+61m, T0+23h, T0+25h.
• When : évaluation des SLA.
• Then : respect = conforme ; dépassement = alerte ops (critique/majeure) + run non conforme.
• Résultat attendu : statut SLA déterministe et traçable.
• Automatisable : Oui

TC-251-15 — SLA restauration : expiration, retries, backoff¶

• INV/CA couverts : INV-251-13, CA-251-11, CA-251-15
• Prérequis : archive SUSPECT, CRR indisponible temporairement.
• Given : restoreSla, restoreRetryMax, restoreRetryBackoff aux bornes et hors bornes.
• When : restauration échoue jusqu'au maximum de retries.
• Then : backoff clamped si nécessaire, arrêt des retries au plafond, escalade ops, notification propriétaire si délai > restoreSla.
• Résultat attendu : conformité stricte des règles d'expiration et de retry.
• Automatisable : Oui

TC-251-16 — Atomicité multi-composant (crash pré/post-commit)¶

• INV/CA couverts : INV-251-15, CA-251-16
• Prérequis : injection de crash contrôlée.
• Given : scénario A crash pré-commit ; scénario B crash post-commit.
• When : run incident est exécuté avec pannes injectées.
• Then : A -> rollback complet sans artefact persistant ; B -> DB cohérente + rattrapage async (journal/Merkle) par réconciliation.
• Résultat attendu : absence d'état intermédiaire incohérent.
• Automatisable : Oui

TC-251-17 — Aucune erreur silencieuse / statuts explicites en cas de dépendance indisponible¶

• INV/CA couverts : INV-251-02, INV-251-14, INV-251-16, CA-251-02, CA-251-14
• Prérequis : indisponibilité forcée d'un maillon (ex: TSA timeout).
• Given : run sur archive avec dépendance externe indisponible.
• When : vérification s'exécute.
• Then : statut INDETERMINE explicite, run report inclut non-conformité, aucune "validation implicite".
• Résultat attendu : traçabilité complète des causes d'indétermination.
• Automatisable : Oui

TC-251-18 — Priorisation multi-critères + rate limiting des opérations sensibles¶

• INV/CA couverts : CA-251-12, CA-251-15
• Prérequis : ensemble d'archives avec scores variés ; limite d'opérations sensibles configurée.
• Given : score légal/âge/criticité produisant priorités distinctes + rafale de demandes manuelles (re-run/restore).
• When : ordonnanceur trie puis exécute.
• Then : traitement prioritaire selon score ; dépassements de cadence refusés/throttlés et tracés.
• Résultat attendu : ordre d'exécution conforme, tentatives excédentaires journalisées.
• Automatisable : Oui

TC-251-19 — Bornes fréquence/périmètre (batch/parallel/timeout/window)¶

• INV/CA couverts : INV-251-01, CA-251-13
• Prérequis : validation config active.
• Given : valeurs min/max et hors bornes pour runBatchSize, maxParallelChecks, runTimeout, scopeRotationWindow.
• When : chargement de configuration.
• Then : clamps/rejets appliqués selon contrat.
• Résultat attendu : aucune config invalide exécutée silencieusement.
• Automatisable : Oui

TC-251-20 — Matrice de transitions interdites de la machine à états¶

• INV/CA couverts : INV-251-10, CA-251-16
• Prérequis : fixtures dans chaque état.
• Given : tentative exhaustive des transitions interdites documentées.
• When : API/moteur de transition reçoit ces demandes.
• Then : refus systématique avec code et motif, sans effet de bord.
• Résultat attendu : seules transitions explicitement autorisées passent.
• Automatisable : Oui

TC-251-21 — Suppression d'une archive corrompue refusée¶

• INV/CA couverts : INV-251-09, CA-251-14
• Prérequis : archive en état CORRUPTED_CONFIRMED ; variante avec CORRUPTED_ARCHIVED.
• Given : une archive corrompue (CORRUPTED_CONFIRMED ou CORRUPTED_ARCHIVED) existe en base.
• When : une tentative de suppression explicite est effectuée (via API ou commande interne).
• Then : la suppression est refusée avec code d'erreur métier explicite ; l'archive reste présente et inchangée ; un événement d'audit de refus est tracé.
• Résultat attendu : aucun chemin applicatif ne permet la suppression d'une archive corrompue ; invariant de non-suppression strictement respecté.
• Automatisable : Oui

TC-251-22 — Exposition des métriques Prometheus après run complet¶

• INV/CA couverts : CA-251-15
• Prérequis : endpoint /metrics exposé ; un run complet exécutable en environnement de test ; jeu de données incluant cas sains et corrompus.
• Given : un run complet de vérification d'intégrité est exécuté, produisant des résultats variés (OK, SUSPECT, INDETERMINE).
• When : l'endpoint /metrics est interrogé après fin de run.
• Then : les métriques suivantes sont présentes et cohérentes avec les résultats du run :
• Volumétrie de run (nombre d'archives vérifiées)
• Taux de corruption (ratio archives KO / total)
• Durées de run (histogramme ou summary)
• Compteurs par état d'archive (HEALTHY, SUSPECT, RESTORED, CORRUPTED_CONFIRMED, CORRUPTED_ARCHIVED)
• Résultat attendu : les 4 familles de métriques requises sont publiées et exploitables ; aucune famille manquante.
• Automatisable : Oui

3) Scénarios de non-régression (edge cases, concurrence)¶

NR-251-01 — Concurrence de runs sur même archive¶

• Given : deux workers tentent de vérifier la même archive simultanément.
• When : les deux traitements démarrent à T0.
• Then : un seul chemin de transition d'état est retenu, absence de double-écriture incohérente.
• Attendu : idempotence et cohérence transactionnelle.

NR-251-02 — Crash entre snapshot signé et transition d'état¶

• Given : snapshot forensique signé produit.
• When : crash survient avant persistance de RESTORE_PENDING.
• Then : reprise sans doublon de snapshot, transition rejouée proprement.
• Attendu : pas de perte probatoire, pas de transition fantôme.

NR-251-03 — Rejeu d'événement de journal append-only¶

• Given : même événement async livré 2 fois.
• When : consommateur traite les deux messages.
• Then : second traitement sans duplication logique.
• Attendu : retry-safe et idempotent.

NR-251-04 — Rafale de 10x la limite nominale (rate limiting)¶

• Given : charge burst sur opérations de contrôle manuel.
• When : limite atteinte.
• Then : throttling/réjection conforme + traces complètes.
• Attendu : stabilité système sans perte de traçabilité.

NR-251-05 — Horodatages proches des frontières SLA¶

• Given : événements à SLA-1s, SLA, SLA+1s.
• When : moteur d'évaluation SLA calcule conformité.
• Then : classification correcte aux frontières.
• Attendu : absence d'erreur off-by-one.

NR-251-06 — Indisponibilité intermittente TSA/Blockchain¶

• Given : alternance dispo/indispo d'un maillon externe.
• When : run complet s'exécute.
• Then : statuts explicites par maillon, aucune validation implicite globale.
• Attendu : robustesse aux pannes transitoires sans erreur silencieuse.

4) Éléments non testables / ambiguïtés¶

1. NON TESTABLE (infrastructure matérielle) : garanties physiques HSM
2. Justification : on peut tester la présence/validité des signatures et la politique d'usage, mais pas certifier en test applicatif les propriétés physiques/certifications matérielles du HSM.
3. Action attendue : compléter par preuves de conformité infrastructure (audit HSM séparé).