PD-79 — Tests & Validation¶

Metadata¶

1) Matrice de traçabilite (CA-79-xx -> TC-79-xxx)¶

2) Jeux de donnees de test (fixtures)¶

Dataset requis¶

• fixture_png_1kb.png : PNG valide, 1 Ko, magic bytes 89 50 4E 47
• fixture_jpeg_500kb.jpg : JPEG valide, 500 Ko, magic bytes FF D8 FF
• fixture_mp4_50mb.mp4 : MP4 valide, 50 Mo, ftyp conforme
• fixture_oversize_101mb.mp4 : MP4 valide, 101 Mo
• fixture_exe_renamed_png.png : executable renomme .png (MIME declare image/png, magic bytes 4D 5A)
• fixture_bad_magic_png.png : extension PNG, magic bytes invalides

Exemples de payloads API¶

{
  "clientRequestId": "req-79-0001",
  "category": "B2C_EVIDENCE_MINOR",
  "declaredMimeType": "image/png",
  "metadata": {
    "minorCaseId": "MIN-12345",
    "source": "mobile-app"
  }
}

{
  "clientRequestId": "req-79-0002",
  "declaredMimeType": "image/jpeg",
  "metadata": {
    "source": "legacy-client-without-category"
  }
}

{
  "clientRequestId": "req-79-0003",
  "category": "B2C_EVIDENCE_MINOR",
  "declaredMimeType": "application/x-msdownload",
  "metadata": {
    "source": "malicious-client"
  }
}

3) Tests unitaires (12)¶

TC-79-UT-001 : Defaut category sur absence¶

Preconditions : - CategoryConfigService initialise avec DEFAULT

Etapes : 1. Appeler resolveCategory(null) 2. Appeler resolveCategory(undefined)

Resultat attendu : - Retourne DEFAULT dans les deux cas - Aucune exception

Donnees de test :

{"category": null, "expected": "DEFAULT"}

TC-79-UT-002 : Category invalide -> ERR-79-001¶

Preconditions : - Liste categories autorisees chargee

Etapes : 1. Appeler validateCategory("B2C_MINOR")

Resultat attendu : - Exception metier avec code ERR-79-001 - Mapping HTTP prevu 400

Donnees de test :

{"category": "B2C_MINOR", "expectedError": "ERR-79-001"}

TC-79-UT-003 : Config absente pour categorie -> ERR-79-002¶

Preconditions : - B2C_EVIDENCE_MINOR absent de la config runtime

Etapes : 1. Appeler getCategoryRules("B2C_EVIDENCE_MINOR")

Resultat attendu : - Retour erreur ERR-79-002 - Aucun fallback silencieux

Donnees de test :

{"category": "B2C_EVIDENCE_MINOR", "expectedError": "ERR-79-002"}

TC-79-UT-004 : Whitelist B2C contient exactement 7 MIME¶

Preconditions : - Regles B2C chargees

Etapes : 1. Lire la whitelist MIME de B2C_EVIDENCE_MINOR

Resultat attendu : - Taille de liste = 7 - Valeurs strictement egales a la liste attendue

Donnees de test :

{"expectedCount": 7, "expectedMimes": ["image/png","image/jpeg","audio/mp4","audio/mpeg","audio/wav","video/mp4","video/quicktime"]}

TC-79-UT-005 : MIME non autorise rejete¶

Preconditions : - Regles B2C actives

Etapes : 1. Appeler validateMime("B2C_EVIDENCE_MINOR", "application/pdf")

Resultat attendu : - Erreur ERR-79-003 - Code HTTP cible 415

Donnees de test :

{"category": "B2C_EVIDENCE_MINOR", "mime": "application/pdf", "expectedError": "ERR-79-003"}

TC-79-UT-006 : MIME autorise accepte¶

Preconditions : - Regles B2C actives

Etapes : 1. Valider image/png 2. Valider video/quicktime

Resultat attendu : - Validation OK pour les deux MIME - Aucune erreur levee

Donnees de test :

{"mimes": ["image/png", "video/quicktime"], "expected": "accepted"}

TC-79-UT-007 : Taille strictement superieure a 100 Mo rejetee¶

Preconditions : - Limite category B2C configuree a 104857600

Etapes : 1. Verifier size=104857601

Resultat attendu : - Erreur ERR-79-004 - Rejet immediat

Donnees de test :

{"sizeBytes": 104857601, "expectedError": "ERR-79-004"}

TC-79-UT-008 : Taille limite exacte 100 Mo acceptee¶

Preconditions : - Limite B2C a 104857600

Etapes : 1. Verifier size=104857600

Resultat attendu : - Validation OK

Donnees de test :

{"sizeBytes": 104857600, "expected": "accepted"}

TC-79-UT-009 : Comparaison SHA-256 constant-time¶

Preconditions : - Fonction constantTimeDigestCompare instrumentee

Etapes : 1. Comparer deux hash egaux 2. Comparer deux hash differents 3. Mesurer distribution de temps sur 10k iterations

Resultat attendu : - Resultats booleens corrects - Ecart de temps moyen entre succes/echec dans un seuil acceptable (ex. <5%)

Donnees de test :

{"hashA": "3a...ff", "hashB": "3a...ff", "hashC": "9b...01", "iterations": 10000}

TC-79-UT-010 : Fingerprint mismatch -> ERR-79-005¶

Preconditions : - Digest calcule disponible

Etapes : 1. Appeler validation fingerprint avec valeur fournie differente

Resultat attendu : - ERR-79-005 - Statut HTTP cible 422

Donnees de test :

{"computedDigest": "abc", "providedDigest": "def", "expectedError": "ERR-79-005"}

TC-79-UT-011 : Audit enrichi B2C append-only¶

Preconditions : - Writer audit append-only mocke

Etapes : 1. Logger un upload B2C 2. Tenter update d'une entree existante

Resultat attendu : - Entree inclut category, clientRequestId, hash, sealingLatencyMs - Update refuse (append-only)

Donnees de test :

{"category": "B2C_EVIDENCE_MINOR", "expectedFields": ["category","clientRequestId","digest","sealingLatencyMs"]}

TC-79-UT-012 : Regle d'idempotence inchangee¶

Preconditions : - Store idempotence initialise

Etapes : 1. Ecrire premiere requete clientRequestId=req-1 avec digest A 2. Rejouer clientRequestId=req-1 avec digest A 3. Rejouer clientRequestId=req-1 avec digest B

Resultat attendu : - Etape 2 retourne resultat idempotent - Etape 3 retourne ERR-79-006 / 409

Donnees de test :

{"clientRequestId": "req-1", "digestA": "aaa", "digestB": "bbb", "expectedConflictError": "ERR-79-006"}

4) Tests d'integration API /documents/upload (16)¶

TC-79-IT-001 : Upload sans category -> DEFAULT¶

Preconditions : - API demarree - Config DEFAULT active

Etapes : 1. POST /documents/upload sans champ category 2. Fournir fixture_jpeg_500kb.jpg

Resultat attendu : - Reponse 2xx - Category effective tracee = DEFAULT

Donnees de test :

{"file": "fixture_jpeg_500kb.jpg", "category": null, "expected": "DEFAULT"}

TC-79-IT-002 : Category invalide -> 400¶

Preconditions : - API demarree

Etapes : 1. POST avec category=B2C_MINOR

Resultat attendu : - HTTP 400 - Payload erreur code ERR-79-001

Donnees de test :

{"category": "B2C_MINOR", "expectedHttp": 400, "expectedError": "ERR-79-001"}

TC-79-IT-003 : PNG valide B2C accepte¶

Preconditions : - B2C active

Etapes : 1. POST fixture_png_1kb.png avec category B2C

Resultat attendu : - 2xx - Audit enrichi present

Donnees de test :

{"file": "fixture_png_1kb.png", "category": "B2C_EVIDENCE_MINOR", "expected": "accepted"}

TC-79-IT-004 : JPEG valide B2C accepte¶

Preconditions : - B2C active

Etapes : 1. POST fixture_jpeg_500kb.jpg

Resultat attendu : - 2xx

Donnees de test :

{"file": "fixture_jpeg_500kb.jpg", "declaredMimeType": "image/jpeg", "expected": "accepted"}

TC-79-IT-005 : MP4 50 Mo valide B2C accepte¶

Preconditions : - B2C active

Etapes : 1. POST fixture_mp4_50mb.mp4

Resultat attendu : - 2xx - Sealing latency capturee

Donnees de test :

{"file": "fixture_mp4_50mb.mp4", "sizeBytes": 52428800, "expected": "accepted"}

TC-79-IT-006 : MIME non autorise -> 415¶

Preconditions : - B2C active

Etapes : 1. POST application/pdf en B2C

Resultat attendu : - HTTP 415 - Code ERR-79-003

Donnees de test :

{"declaredMimeType": "application/pdf", "expectedHttp": 415, "expectedError": "ERR-79-003"}

TC-79-IT-007 : Fichier 101 Mo -> 413 et interruption stream¶

Preconditions : - Limite B2C 100 Mo

Etapes : 1. POST fixture_oversize_101mb.mp4 2. Observer telemetry d'interruption stream

Resultat attendu : - HTTP 413 - Flux coupe avant persistance complete - Aucun artefact scelle/non scelle persistant

Donnees de test :

{"file": "fixture_oversize_101mb.mp4", "sizeBytes": 105906176, "expectedHttp": 413}

TC-79-IT-008 : Fichier a la limite 100 Mo accepte¶

Preconditions : - Fixture 100 Mo exacte disponible

Etapes : 1. POST fixture 100 Mo en B2C

Resultat attendu : - 2xx

Donnees de test :

{"sizeBytes": 104857600, "expected": "accepted"}

TC-79-IT-009 : Config categorie absente -> 422¶

Preconditions : - Feature flag B2C active mais config regles retiree

Etapes : 1. POST upload B2C valide

Resultat attendu : - HTTP 422 - ERR-79-002

Donnees de test :

{"category": "B2C_EVIDENCE_MINOR", "expectedHttp": 422, "expectedError": "ERR-79-002"}

TC-79-IT-010 : Fingerprint mismatch -> 422¶

Preconditions : - API attend fingerprint client

Etapes : 1. POST fichier valide avec fingerprint faux

Resultat attendu : - HTTP 422 - ERR-79-005

Donnees de test :

{"providedFingerprint": "deadbeef", "expectedHttp": 422, "expectedError": "ERR-79-005"}

TC-79-IT-011 : Audit enrichi B2C present et immutable¶

Preconditions : - Audit store accessible en lecture

Etapes : 1. Realiser un upload B2C succes 2. Lire enregistrement audit 3. Tenter modification/suppression via API interne de maintenance

Resultat attendu : - Champs enrichis presents - Modification/suppression refusee et tracee

Donnees de test :

{"expectedFields": ["category","clientRequestId","digest","sealId","sealingLatencyMs","timestamp"]}

TC-79-IT-012 : Aucune persistance en clair¶

Preconditions : - Backend execute en environnement de test avec acces stockage

Etapes : 1. Uploader un fichier B2C valide 2. Scanner stockage objet et temporaire

Resultat attendu : - Aucune copie en clair accessible - Uniquement objets chiffres/scelles referencables

Donnees de test :

{"file": "fixture_png_1kb.png", "expected": "no-plaintext-artifact"}

TC-79-IT-013 : Aucun upload non scelle ne persiste¶

Preconditions : - Possibilite d'injecter une panne entre reception et scellement

Etapes : 1. Injecter faute durant scellement 2. Envoyer upload valide

Resultat attendu : - Reponse erreur controlee (500 / ERR-79-007) - Nettoyage complet, pas d'objet non scelle residuel

Donnees de test :

{"faultInjection": "sealing-service-timeout", "expectedError": "ERR-79-007"}

TC-79-IT-014 : Idempotence clientRequestId conservee¶

Preconditions : - API idempotente active

Etapes : 1. Poster une requete clientRequestId=req-79-idem-1 2. Rejouer identique 3. Rejouer avec fichier different

Resultat attendu : - Rejeu identique: meme reponse / meme preuve - Rejeu divergent: 409 + ERR-79-006

Donnees de test :

{"clientRequestId": "req-79-idem-1", "expectedConflictHttp": 409}

TC-79-IT-015 : p95 scellement <= 1s sur trafic representatif¶

Preconditions : - Environnement de perf integration stable

Etapes : 1. Envoyer 500 uploads repartis (PNG/JPEG/MP4) 2. Collecter latence de scellement

Resultat attendu : - p95 <= 1000 ms - p99 documente

Donnees de test :

{"workload": 500, "mix": {"png": 0.4, "jpeg": 0.4, "mp4": 0.2}, "slaMsP95": 1000}

TC-79-IT-016 : Erreur interne controlee -> ERR-79-007¶

Preconditions : - Injecteur de fautes actif

Etapes : 1. Simuler indisponibilite service de scellement 2. Envoyer upload valide

Resultat attendu : - HTTP 500 - Code erreur ERR-79-007 - Audit d'echec trace

Donnees de test :

{"faultInjection": "sealing-unavailable", "expectedHttp": 500, "expectedError": "ERR-79-007"}

5) Tests de non-regression PD-60 (5)¶

TC-79-NR-001 : Client legacy sans category continue de fonctionner¶

Preconditions : - Client PD-60 sans champ category

Etapes : 1. Executer scenario upload legacy complet

Resultat attendu : - Aucun changement de contrat API - Traitement DEFAULT

Donnees de test :

{"clientVersion": "PD-60", "category": null, "expected": "no-breaking-change"}

TC-79-NR-002 : MIME autorises historiques DEFAULT inchanges¶

Preconditions : - Regles DEFAULT pre-PD-79 connues

Etapes : 1. Executer batterie MIME DEFAULT historique

Resultat attendu : - Meme comportement qu'avant PD-79

Donnees de test :

{"category": "DEFAULT", "expected": "baseline-pd60"}

TC-79-NR-003 : Schema de reponse upload inchange pour DEFAULT¶

Preconditions : - Snapshot schema OpenAPI PD-60 disponible

Etapes : 1. Comparer reponse upload DEFAULT a snapshot

Resultat attendu : - Aucune rupture backward-compatible

Donnees de test :

{"contract": "upload-default-response", "expected": "compatible"}

TC-79-NR-004 : Idempotence legacy non alteree¶

Preconditions : - Cas idempotence PD-60 existants

Etapes : 1. Reexecuter suite idempotence pre-existante

Resultat attendu : - Resultats identiques

Donnees de test :

{"suite": "pd60-idempotency-regression", "expected": "unchanged"}

TC-79-NR-005 : Journalisation standard DEFAULT inchangee¶

Preconditions : - Format logs PD-60 reference

Etapes : 1. Executer upload DEFAULT 2. Comparer champs de log standard

Resultat attendu : - Aucun champ supprime/renomme

Donnees de test :

{"category": "DEFAULT", "expected": "log-format-compatible"}

6) Tests de securite (6)¶

TC-79-SEC-001 : Tentative injection metadata¶

Preconditions : - WAF/validation input actives

Etapes : 1. Soumettre metadata contenant payload injection ("$ne":null, SQL-like)

Resultat attendu : - Rejet ou neutralisation stricte - Aucune corruption audit

Donnees de test :

{"metadata": {"minorCaseId": {"$ne": null}, "comment": "' OR 1=1 --"}, "expected": "rejected-or-sanitized"}

TC-79-SEC-002 : EXE deguise en PNG (bypass MIME)¶

Preconditions : - Detection magic bytes active

Etapes : 1. Uploader fixture_exe_renamed_png.png avec MIME declare image/png

Resultat attendu : - HTTP 415 - Rejet avant scellement

Donnees de test :

{"file": "fixture_exe_renamed_png.png", "declaredMimeType": "image/png", "expectedHttp": 415}

TC-79-SEC-003 : Magic bytes incorrects¶

Preconditions : - Verification contenu binaire active

Etapes : 1. Uploader fixture_bad_magic_png.png

Resultat attendu : - HTTP 415 - Trace d'anomalie de type contenu

Donnees de test :

{"file": "fixture_bad_magic_png.png", "expectedHttp": 415}

TC-79-SEC-004 : Timing attacks sur comparaison hash¶

Preconditions : - Harness de benchmark dispo

Etapes : 1. Comparer series de hash avec prefixes communs differents 2. Evaluer corrélation temps / longueur prefixe

Resultat attendu : - Pas de correlation exploitable - Seuil d'alerte non depasse

Donnees de test :

{"dataset": "hash-prefix-variance", "expected": "no-timing-leak"}

TC-79-SEC-005 : DoS payload oversize stream¶

Preconditions : - Limiteur flux actif

Etapes : 1. Envoyer flux >100 Mo en chunk lent

Resultat attendu : - Connexion coupee proprement - Ressources liberees

Donnees de test :

{"attack": "slow-oversize-stream", "expected": "terminated-cleanly"}

TC-79-SEC-006 : Rejeu malveillant clientRequestId avec contenu different¶

Preconditions : - Idempotence store actif

Etapes : 1. Envoyer requete A (id X) 2. Envoyer requete B (id X, contenu different)

Resultat attendu : - HTTP 409 - Tentative de conflit tracee en audit securite

Donnees de test :

{"clientRequestId": "req-replay-1", "expectedHttp": 409, "expectedError": "ERR-79-006"}

7) Tests de performance (3)¶

TC-79-PERF-001 : SLA p95 scellement <= 1s (charge nominale)¶

Preconditions : - Env de perf representatif

Etapes : 1. Simuler 50 RPS pendant 10 min (mix B2C) 2. Capturer latences scellement

Resultat attendu : - p95 <= 1000 ms

Donnees de test :

{"rps": 50, "durationMin": 10, "slaP95Ms": 1000}

TC-79-PERF-002 : Robustesse en pic (burst)¶

Preconditions : - Autoscaling/queueing configure

Etapes : 1. Generer burst 200 RPS sur 60s

Resultat attendu : - Aucun timeout critique - p95 <= 1s maintenu ou degradation documentee sous seuil d'alerte

Donnees de test :

{"burstRps": 200, "durationSec": 60, "expected": "controlled-degradation"}

TC-79-PERF-003 : Endurance 1h sans derive¶

Preconditions : - Monitoring memoire/cpu/queue

Etapes : 1. Maintenir 20 RPS pendant 60 min 2. Mesurer p95 toutes les 5 min

Resultat attendu : - Pas de fuite memoire significative - p95 stable <= 1s

Donnees de test :

{"rps": 20, "durationMin": 60, "expected": "stable-latency"}

8) Tests d'invariants (INV-79-xx)¶

TC-79-INV-001 : INV-79-01 aucun fichier en clair cote serveur¶

Preconditions : - Acces lecture aux stockages techniques en environnement de test

Etapes : 1. Uploader 3 fichiers B2C 2. Scanner stockages temporaire/permanent

Resultat attendu : - Aucun contenu en clair trouvable

Donnees de test :

{"files": ["fixture_png_1kb.png", "fixture_jpeg_500kb.jpg", "fixture_mp4_50mb.mp4"], "expected": "encrypted-only"}

TC-79-INV-002 : INV-79-02 aucun upload non scelle persiste¶

Preconditions : - Fault injection active

Etapes : 1. Interrompre traitement avant scellement final

Resultat attendu : - Nettoyage complet des artefacts temporaires

Donnees de test :

{"fault": "pre-seal-crash", "expected": "no-unsealed-left"}

TC-79-INV-003 : INV-79-03 aucune modification ulterieure¶

Preconditions : - Une preuve scellee existe

Etapes : 1. Tenter update metadonnees preuve

Resultat attendu : - Refus explicite - Trace d'action interdite

Donnees de test :

{"proofId": "proof-79-1", "operation": "update", "expected": "forbidden"}

TC-79-INV-004 : INV-79-04 aucun effacement silencieux¶

Preconditions : - Policy retention configuree

Etapes : 1. Tenter suppression via endpoint admin

Resultat attendu : - Operation soit interdite, soit journalisee explicitement - Jamais de suppression silencieuse

Donnees de test :

{"operation": "delete-proof", "expected": "blocked-or-audited"}

TC-79-INV-005 : INV-79-05 preuve tracable independamment¶

Preconditions : - Identifiant preuve disponible

Etapes : 1. Recuperer preuve et chainage audit sans contexte applicatif

Resultat attendu : - Verification independante possible (digest + horodatage + sealId)

Donnees de test :

{"proofId": "proof-79-2", "expected": "independent-verifiability"}

TC-79-INV-006 : INV-79-06 scellement inferieur a 1s¶

Preconditions : - Instrumentation latence active

Etapes : 1. Executer campagne de charge nominale

Resultat attendu : - p95 <= 1000 ms

Donnees de test :

{"metric": "sealingLatencyMs.p95", "threshold": 1000}

9) Scenarios de validation fonctionnelle (BDD Given/When/Then)¶

TC-79-BDD-001 : Upload legacy sans category¶

Preconditions : - Client legacy PD-60

Etapes : 1. Soumettre un JPEG sans category

Resultat attendu : - Upload accepte sous DEFAULT

Donnees de test :

{"file": "fixture_jpeg_500kb.jpg", "category": null}

BDD : - Given un client legacy sans champ category - When il charge un fichier valide - Then le systeme applique la category DEFAULT sans rupture de contrat

TC-79-BDD-002 : Upload B2C nominal PNG¶

Preconditions : - Category B2C active

Etapes : 1. Soumettre PNG 1 Ko avec category B2C

Resultat attendu : - Upload accepte, preuve scellee, audit enrichi

Donnees de test :

{"file": "fixture_png_1kb.png", "category": "B2C_EVIDENCE_MINOR"}

BDD : - Given une requete B2C valide - When le fichier PNG est envoye - Then la preuve est scellee et tracee en append-only

TC-79-BDD-003 : Rejet MIME hors whitelist¶

Preconditions : - Category B2C active

Etapes : 1. Envoyer application/pdf en B2C

Resultat attendu : - 415 immediat

Donnees de test :

{"declaredMimeType": "application/pdf", "category": "B2C_EVIDENCE_MINOR"}

BDD : - Given une requete B2C avec MIME non autorise - When le serveur valide les regles de category - Then la requete est rejetee avec 415

TC-79-BDD-004 : Rejet oversize¶

Preconditions : - Limite B2C a 100 Mo

Etapes : 1. Envoyer un fichier 101 Mo

Resultat attendu : - 413 et interruption de flux

Donnees de test :

{"file": "fixture_oversize_101mb.mp4", "sizeBytes": 105906176}

BDD : - Given un upload B2C depassant la taille maximale - When le flux est recu - Then le serveur coupe le stream et renvoie 413

TC-79-BDD-005 : Idempotence stricte¶

Preconditions : - API idempotente

Etapes : 1. Soumettre requete avec clientRequestId fixe 2. Rejouer identique 3. Rejouer avec contenu different

Resultat attendu : - Rejeu identique idempotent - Rejeu divergent 409

Donnees de test :

{"clientRequestId": "req-bdd-5", "expectedConflict": 409}

BDD : - Given un identifiant client deja utilise - When la meme requete est rejouee - Then le systeme retourne le meme resultat - And une variation du contenu produit un conflit 409

TC-79-BDD-006 : Audit enrichi obligatoire¶

Preconditions : - Audit consultable

Etapes : 1. Uploader preuve B2C 2. Lire entree audit associee

Resultat attendu : - Champs enrichis tous presents

Donnees de test :

{"expectedFields": ["category", "clientRequestId", "digest", "sealId", "timestamp"]}

BDD : - Given une preuve B2C nouvellement creee - When l'audit est consulte - Then l'entree est complete et exploitable pour verification independante

TC-79-BDD-007 : Hash mismatch¶

Preconditions : - Fingerprint client attendu

Etapes : 1. Envoyer fichier valide avec fingerprint incorrect

Resultat attendu : - HTTP 422

Donnees de test :

{"providedFingerprint": "ff00", "expectedHttp": 422}

BDD : - Given un fichier intact et un fingerprint transmis incorrect - When le systeme compare les digest - Then il rejette la requete avec 422

TC-79-BDD-008 : SLA de scellement respecte¶

Preconditions : - Monitoring de latence actif

Etapes : 1. Executer campagne nominale

Resultat attendu : - p95 <= 1s

Donnees de test :

{"metric": "sealingLatencyMs.p95", "thresholdMs": 1000}

BDD : - Given un trafic representatif de production - When les preuves B2C sont scellees - Then la latence p95 reste inferieure ou egale a 1 seconde

10) Couverture minimale atteinte¶

11) Strategie d'execution et criteres de sortie¶

• Ordre recommande : Unitaire -> Integration -> Invariants -> Securite -> Non-regression -> Performance -> BDD
• Critere GO QA : 100% des P0 verts, 0 echec sur invariants, SLA p95 valide, 0 regression PD-60
• Critere NO-GO : tout echec P0, toute violation d'invariant, ou toute derive SLA non justifiee