PD-250 — Tests & Validation — Job destruction définitive et bordereau (v4)¶

1. Matrice de couverture¶

Invariants → Tests¶

Critères d'acceptation → Tests¶

Cas d'erreur → Tests¶

2. Scénarios de test¶

TC-250-01 — Éligibilité stricte WORM (DB+S3+legal_lock)¶

• Invariant(s) couverts : INV-250-01
• Critère(s) couverts : CA-250-01
• Prérequis : Jeu de données mixte avec combinaisons contrôlées des états (DB expiry, S3 Object Lock expiry, legal_lock absent/actif/expiré).
• Given : 9 documents couvrant toutes les combinaisons booléennes des 3 conditions d'éligibilité.
• When : Exécution d'un run de sélection (sans destruction) avec batchSize > 9.
• Then : Seuls les documents satisfaisant simultanément les 3 conditions sont sélectionnés.
• Mécanisme de vérification : Comparaison déterministe entre set attendu et set sélectionné via journal d'exécution + audit de filtre.

TC-250-02 — Exclusion des statuts SEALED/PENDING¶

• Invariant(s) couverts : INV-250-01, INV-250-02
• Critère(s) couverts : CA-250-01
• Prérequis : Documents éligibles temporellement mais statuts SEALED, PENDING, EXPIRED.
• Given : 3 documents identiques sauf statut.
• When : Exécution de la sélection.
• Then : Seul le document EXPIRED peut être candidat; SEALED et PENDING sont exclus.
• Mécanisme de vérification : Trace de décision par document (raison d'exclusion incluse).

TC-250-03 — legal_lock actif interdit, legal_lock expiré autorisé¶

• Invariant(s) couverts : INV-250-01
• Critère(s) couverts : CA-250-01, CA-250-09
• Prérequis : Deux documents identiques, legal_lock actif pour l'un, expiré pour l'autre.
• Given : Conditions DB/S3 expirées pour les deux.
• When : Exécution de la sélection.
• Then : Document legal_lock actif non sélectionné; document legal_lock expiré sélectionné.
• Mécanisme de vérification : Audit des filtres avec motif explicite LEGAL_LOCK_ACTIVE.

TC-250-04 — Fail-closed si signature invalide¶

• Invariant(s) couverts : INV-250-03
• Critère(s) couverts : CA-250-03
• Prérequis : Lot de documents éligibles; injecteur de faute signature renvoyant invalide.
• Given : Prévalidation réussie, signature invalide.
• When : Exécution du batch.
• Then : Batch FAILED; aucune suppression S3/DB; aucune transition DESTROYED.
• Mécanisme de vérification : Compteurs de suppressions = 0, transitions = 0, statut batch + alerte.

TC-250-05 — TSA indisponible : tsaRetryCount tentatives max puis arrêt¶

• Invariant(s) couverts : INV-250-03, INV-250-09
• Critère(s) couverts : CA-250-03, CA-250-07
• Prérequis : Mock TSA timeout systématique. tsaRetryCount configuré à la valeur par défaut (3).
• Given : Batch éligible.
• When : Exécution de la phase horodatage.
• Then : Exactement tsaRetryCount tentatives (3 par défaut), puis FAILED; destruction non exécutée.
• Mécanisme de vérification : Logs retry horodatés (compte = tsaRetryCount), statut final FAILED, transitions DESTROYED absentes.

TC-250-06 — S3 injoignable post-validation : échec partiel observable¶

• Invariant(s) couverts : INV-250-10
• Critère(s) couverts : CA-250-08
• Prérequis : Batch validé probatoirement; panne S3 sur sous-ensemble déterminé.
• Given : 5 documents dont 2 ciblés en erreur S3.
• When : Exécution destruction unitaire (S3 asynchrone, cf. §5.5).
• Then : Batch PARTIAL_FAILED; erreurs unitaires auditées; alerte émise; documents en succès marqués DESTROYED après confirmation S3 + finalisation DB.
• Mécanisme de vérification : Corrélation des statuts unitaires, présence audit/alerte pour chaque échec.

TC-250-07 — Échec DB après suppression S3 : réconciliation vers état terminal¶

• Invariant(s) couverts : INV-250-10
• Critère(s) couverts : CA-250-08
• Prérequis : Suppression S3 réussie, suppression DB forcée en erreur sur 1 document.
• Given : Batch validé avec 1 faute DB injectée.
• When : Exécution puis réconciliation dans le délai reconciliationSla.
• Then : État terminal = DESTROYED si DB rattrapée, sinon RECONCILIATION_FAILED après reconciliationDbRetryCount retries + escalade. Anomalie critique tracée.
• Mécanisme de vérification : Audit d'anomalie + preuve de convergence vers état terminal contractuel (ERR-250-05).

TC-250-08 — Un batch réussi produit exactement un bordereau valide¶

• Invariant(s) couverts : INV-250-04
• Critère(s) couverts : CA-250-02
• Prérequis : Batch éligible complet sans erreur injectée.
• Given : N documents sélectionnés.
• When : Exécution complète du batch en succès.
• Then : 1 et 1 seul bordereau PDF/A, signature valide (certificat TSP qualifié eIDAS), timestamp RFC 3161 valide (champs obligatoires présents).
• Mécanisme de vérification : Vérificateur PDF/A + signature + jeton TSA; unicité sur batchId.

TC-250-08b — Échec persistance bordereau : aucune destruction¶

• Invariant(s) couverts : INV-250-03
• Critère(s) couverts : CA-250-03
• Prérequis : Injecteur de faute sur persistance bordereau.
• Given : Batch validé mais persistance du bordereau échoue.
• When : Exécution du batch.
• Then : Batch FAILED; aucune suppression S3/DB déclenchée; alerte.
• Mécanisme de vérification : Compteurs de suppressions = 0, statut batch FAILED.

TC-250-09 — Audit unitaire obligatoire lié au bordereau¶

• Invariant(s) couverts : INV-250-05
• Critère(s) couverts : CA-250-04
• Prérequis : Batch réussi avec plusieurs destructions.
• Given : Documents détruits dans un même batchId.
• When : Lecture des traces d'audit.
• Then : Une entrée par document détruit, contenant documentId, batchId, bordereauId corrélés.
• Mécanisme de vérification : Requête de complétude et d'unicité des logs sur cardinalité attendue.

TC-250-10 — Conservation indéfinie des bordereaux (observable fini)¶

• Invariant(s) couverts : INV-250-06
• Critère(s) couverts : CA-250-05
• Prérequis : Bordereaux anciens (au-delà de la fenêtre de rétention des documents métiers) présents.
• Given : Ensemble de bordereaux historiques.
• When : (1) Inspection du schéma/données des bordereaux, (2) Exécution du job de destruction automatique + consultation admin.
• Then : (1) retentionExpiry absent ou null pour tous les bordereaux, (2) Aucun bordereau sélectionné pour destruction; tous restent lisibles via API admin.
• Mécanisme de vérification : Contrôle schéma retentionExpiry + zéro tentative de suppression sur type bordereau + lecture API réussie.

TC-250-11 — Minimisation RGPD du contenu bordereau¶

• Invariant(s) couverts : INV-250-07
• Critère(s) couverts : CA-250-06
• Prérequis : Schéma attendu des champs autorisés (cf. §3) + liste fermée des données personnelles directes (cf. §3).
• Given : Bordereau généré.
• When : Contrôle de schéma et inspection du contenu.
• Then : Présence uniquement des champs probatoires autorisés (cf. §3); absence des données personnelles directes (cf. §3 liste fermée : nom, prénom, email, adresse, téléphone, NIR, etc.).
• Mécanisme de vérification : Validation JSON/schema dérivée + règles de détection PII sur payload extrait.

TC-250-12 — Idempotence sur relance même batch (sans erreur)¶

• Invariant(s) couverts : INV-250-08
• Critère(s) couverts : CA-250-08
• Prérequis : Batch déjà terminé en succès.
• Given : Relance du job sur même fenêtre de données.
• When : Deuxième exécution.
• Then : Aucun document déjà DESTROYED n'est retraité; pas de doublon d'audit de destruction. Le statut terminal DESTROYED sert de marqueur d'idempotence (pas de TTL de rejeu).
• Mécanisme de vérification : Delta nul sur transitions et audits unitaires de destruction.

TC-250-13 — Réconciliation post-crash vers état terminal contractuel¶

• Invariant(s) couverts : INV-250-08, INV-250-10
• Critère(s) couverts : CA-250-08
• Prérequis : Premier run PARTIAL_FAILED avec crash post-suppression S3.
• Given : Sous-ensemble déjà supprimé S3, DB non finalisée.
• When : Réconciliation dans le délai reconciliationSla.
• Then : État terminal contractuel atteint : DESTROYED si DB rattrapée, RECONCILIATION_FAILED si DB échoue après reconciliationDbRetryCount retries (escalade). Seuls les éléments en échec sont repris; absence de double destruction.
• Mécanisme de vérification : Comparaison des identifiants traités entre runs, unicité des événements de destruction, état terminal conforme à ERR-250-05.

TC-250-14 — Échec silencieux interdit (audit + alerte obligatoires)¶

• Invariant(s) couverts : INV-250-10
• Critère(s) couverts : CA-250-08
• Prérequis : Injection d'une erreur technique contrôlée.
• Given : Exécution en présence d'une panne partielle.
• When : Traitement du document en faute.
• Then : Événement d'audit d'erreur et alerte opérationnelle présents obligatoirement.
• Mécanisme de vérification : Assert conjoint sur bus d'alerting + journal d'audit, absence = non conforme.

TC-250-15 — Rejet des transitions inverses (4 transitions)¶

• Invariant(s) couverts : INV-250-11
• Critère(s) couverts : CA-250-12
• Prérequis : Documents dans états DESTROYED, EXPIRED, SEALED.
• Given : Tentatives API/service de transitions inverses interdites.
• When : Soumission des 4 transitions : DESTROYED→EXPIRED, EXPIRED→SEALED, SEALED→PENDING, DESTROYED→SEALED.
• Then : Chaque tentative est rejetée avec erreur explicite; état inchangé; trace d'audit.
• Mécanisme de vérification : Codes d'erreur contractuels + contrôle d'intégrité d'état avant/après pour les 4 transitions.

TC-250-16 — Audit log mesurable (non-perte, ordre causal, complétude)¶

• Invariant(s) couverts : INV-250-05
• Critère(s) couverts : CA-250-04
• Prérequis : Campagne de destructions avec injection d'un crash contrôlé suivi d'une reprise.
• Given : Batch avec crash injecté après suppression S3 mais avant le commit de la transaction DB (§10.4b). L'audit log et la finalisation DESTROYED étant dans la même transaction ACID, un crash à ce point signifie que ni l'état ni l'audit ne sont persistés. Reprise via réconciliation (ERR-250-05).
• When : Consolidation des événements après reprise/réconciliation.
• Then : (1) Non-perte : tout événement émis est persisté (garanti par transaction ACID — pas de fenêtre entre destruction et audit). (2) Ordre causal : monotonie garantie par séquence PostgreSQL audit_seq (cf. INV-250-05). (3) Complétude : exactement une entrée d'audit par document traité (type DESTROYED ou RECONCILIATION_FAILED selon état terminal, cf. §10.5).
• Mécanisme de vérification : Assertions sur cardinalité, monotonie par audit_seq, et absence de perte post-crash/réconciliation.

TC-250-17 — Destruction cryptographique obligatoire uniquement flux legal_lock (actif ou expiré)¶

• Invariant(s) couverts : INV-250-12
• Critère(s) couverts : CA-250-01
• Prérequis : 3 documents éligibles : (a) avec legal_lock expiré (flux legal_lock), (b) avec legal_lock jamais assigné (hors flux), © avec legal_lock historique assigné puis expiré (flux legal_lock, cf. §3 définition).
• Given : Batch mixte contenant les 3 documents.
• When : Exécution destruction.
• Then : Zeroization exécutée pour documents (a) et © (flux legal_lock); document (b) = suppression physique seule.
• Mécanisme de vérification : Traces d'orchestration des opérations de destruction par type de flux, assertion sur présence/absence de zeroization par document.

TC-250-18 — Convention BullMQ : nom de queue sans ':'¶

• Invariant(s) couverts : INV-250-13
• Critère(s) couverts : CA-250-13
• Prérequis : Configuration des queues chargée en environnement de test.
• Given : Liste effective des noms de queue utilisés par le job.
• When : Validation de conformité de nommage.
• Then : Aucun nom ne contient :.
• Mécanisme de vérification : Test contractuel de configuration (regex négative déterministe).

TC-250-19 — Interdiction des API BullMQ dépréciées¶

• Invariant(s) couverts : INV-250-14
• Critère(s) couverts : CA-250-14
• Prérequis : Analyse statique du code source du module.
• Given : Base de code du job.
• When : Scan des appels API BullMQ.
• Then : Absence d'occurrences getRepeatableJobs et removeRepeatableByKey. Présence de getJobSchedulers/removeJobScheduler.
• Mécanisme de vérification : Règle statique bloquante CI (pattern scan + seuil zéro).

TC-250-20 — Endpoint admin : autorisation ADMIN requise¶

• Invariant(s) couverts : INV-250-15
• Critère(s) couverts : CA-250-15
• Prérequis : Utilisateur avec rôle ADMIN et utilisateur sans rôle ADMIN.
• Given : Requête API vers l'endpoint de consultation des bordereaux.
• When : (1) Appel par utilisateur ADMIN, (2) Appel par utilisateur non-ADMIN.
• Then : (1) Accès autorisé, bordereaux retournés. (2) Accès refusé (403), aucun contenu bordereau, trace d'audit d'accès refusé.
• Mécanisme de vérification : Assertions HTTP status code + body + audit log.

TC-250-21 — Endpoint admin : filtre date et batch¶

• Invariant(s) couverts : INV-250-15
• Critère(s) couverts : CA-250-10
• Prérequis : Données de bordereaux sur plusieurs dates et batchId.
• Given : Requêtes API avec filtres individuels et combinés, par utilisateur ADMIN.
• When : Appel endpoint consultation bordereaux.
• Then : Résultats conformes aux filtres, sans éléments hors périmètre demandé.
• Mécanisme de vérification : Assertions exact-match sur cardinalité et identifiants attendus.

TC-250-22 — Notification de préavis N jours via bus événements¶

• Invariant(s) couverts : INV-250-01
• Critère(s) couverts : CA-250-11
• Prérequis : preNoticeDays configuré (cas N=30 et N=0), bus d'événements interne opérationnel.
• Given : Document approchant la date d'éligibilité.
• When : Passage de la fenêtre temporelle de préavis.
• Then : Événement de préavis émis sur le bus interne à J-N (N=0 = jour J), contenant uniquement documentId, date d'éligibilité prévue, preNoticeDays. Horodaté et corrélable au document.
• Mécanisme de vérification : Interception de l'événement sur le bus + validation du payload (champs techniques uniquement, pas de PII) + corrélation temporelle.

TC-250-23 — Rejet configuration hors bornes¶

• Invariant(s) couverts : —
• Critère(s) couverts : —
• ERR couvert : ERR-250-08
• Prérequis : Configuration invalide prête à injecter.
• Given : Configuration avec paramètres hors bornes (ex: destructionBatchSize=10000, tsaRetryCount=-1, clockSkewTolerance=0).
• When : Le job démarre.
• Then : Erreur de validation bloquante; aucun traitement document; alerte émise.
• And : Test des bornes min ET max pour au moins 3 paramètres (destructionBatchSize, tsaRetryCount, clockSkewTolerance).
• Mécanisme de vérification : Code d'erreur de validation + zéro document sélectionné + alerte présente.

TC-250-25 — Document non éligible détecté en cours de run (ERR-250-03)¶

• Invariant(s) couverts : INV-250-10
• Critère(s) couverts : CA-250-01
• ERR couvert : ERR-250-03
• Prérequis : Batch validé avec documents éligibles. Injection de changement d'état concurrent (re-scellement d'urgence → SEALED) sur 1 document entre sélection et destruction unitaire.
• Given : Batch de 3 documents éligibles. Le document B est re-scellé (→ SEALED) après sélection mais avant sa destruction unitaire.
• When : Exécution séquentielle du batch.
• Then : Document B exclu de la destruction avec audit d'anomalie (ERR-250-03). Documents A et C détruits normalement. Batch PARTIAL_FAILED (car au moins un document sélectionné n'a pas été détruit, cf. ERR-250-03). Document B conserve son état SEALED.
• Mécanisme de vérification : Audit d'anomalie pour document B + état SEALED préservé + documents A/C en DESTROYED + statut batch PARTIAL_FAILED.

TC-250-26 — Dépassement batchFinalizeSla¶

• Invariant(s) couverts : INV-250-16
• Critère(s) couverts : CA-250-16
• SLA couvert : batchFinalizeSla (§10.3)
• Prérequis : Mock temporel contrôlable, batchFinalizeSla configuré à valeur courte.
• Given : Batch en cours de traitement.
• When : La durée du batch dépasse batchFinalizeSla.
• Then : Batch marqué FAILED + alerte critique émise.
• Mécanisme de vérification : Statut batch FAILED + timestamp dépassement + alerte dans le bus d'alerting.

TC-250-27 — Dépassement destructionExecutionSla¶

• Invariant(s) couverts : INV-250-16
• Critère(s) couverts : CA-250-16
• SLA couvert : destructionExecutionSla (§10.3)
• Prérequis : Mock temporel contrôlable, destructionExecutionSla configuré à valeur courte.
• Given : Document unitaire en cours de destruction après bordereau validé.
• When : La durée de traitement du document dépasse destructionExecutionSla.
• Then : Batch marqué PARTIAL_FAILED + reprise autorisée.
• Mécanisme de vérification : Statut batch PARTIAL_FAILED + audit unitaire de timeout + reprise possible.

TC-250-28 — Dépassement reconciliationSla¶

• Invariant(s) couverts : INV-250-16
• Critère(s) couverts : CA-250-16
• SLA couvert : reconciliationSla (§10.3)
• ERR couvert : ERR-250-05
• Prérequis : Mock temporel contrôlable, reconciliationSla configuré à valeur courte. Crash injecté post-suppression S3 / pré-commit DB.
• Given : Document avec suppression S3 réussie mais finalisation DB échouée. Réconciliation en cours.
• When : La durée de réconciliation dépasse reconciliationSla après reconciliationDbRetryCount retries échoués.
• Then : Document marqué RECONCILIATION_FAILED (état terminal de document, cf. §10.5) + escalade critique obligatoire + entrée d'audit de type RECONCILIATION_FAILED.
• Mécanisme de vérification : État document RECONCILIATION_FAILED + audit type correspondant + alerte d'escalade émise + timestamp dépassement SLA.

3. Scénarios non testables¶

4. Verdict de testabilité¶

Verdict : TESTABLE (GO) avec contrôles contractuels

• Couverture invariants : 16/16 couverts par au moins un scénario.
• Couverture critères d'acceptation : 16/16 couverts par au moins un scénario.
• Couverture cas d'erreur : 8/8 ERR couverts (ERR-250-03 couvert par TC-250-25).
• Couverture SLA : batchFinalizeSla (TC-250-26), destructionExecutionSla (TC-250-27), reconciliationSla (TC-250-07/13/28), preNoticeDays (TC-250-22).
• Déterminisme : scénarios formulés avec prérequis contrôlables et observables explicites.
• Automatisabilité : exécutable en tests d'intégration + tests contractuels + contrôles statiques CI.
• Contrôles contractuels : conservation « indéfinie » (TC-250-10), conformité eIDAS (contrôle opérationnel, cf. §3 non testable).
• Risques résiduels : dépendance environnementale TSA/S3/notification à maîtriser par doubles de test et campagnes en environnement représentatif.