PD-52 — Scenarios de tests contractuels¶

1. References¶

Specification : PD-52-specification.md
Epic : PD-187 - BLOCKCHAIN
JIRA : PD-52
Repos concernes : ProbatioVault-backend, ProbatioVault-infra
Documents associes : PD-52-besoin.md, learnings PD-36/PD-7/PD-37

2. Matrice de couverture¶

2.1 Invariants → Tests¶

ID Invariant	ID Critere	ID Test(s)	Couverture	Commentaire
INV-52-01	CA-52-01, CA-52-02	TC-NOM-01, TC-NOM-02	Oui	Polygon et Arbitrum couverts separement
INV-52-02	CA-52-06	TC-NOM-08, TC-INV-02	Oui	Verification testnet-only dans config et transactions
INV-52-03	CA-52-04, CA-52-09	TC-NOM-06, TC-INV-03a, TC-INV-03b, TC-INV-03c	Oui	Secret prive jamais en clair (code, env, logs, traces)
INV-52-04	CA-52-03	TC-NOM-03, TC-NOM-04, TC-NOM-05, TC-INV-04	Oui	Un et un seul mode selectionne
INV-52-05	CA-52-03	TC-ERR-03, TC-ERR-04	Oui	Refus si mode indisponible
INV-52-06	CA-52-07	TC-NOM-09, TC-INV-06	Oui	Primaire + secondaire par reseau
INV-52-07	CA-52-07	TC-NOM-09, TC-ERR-01	Oui	Bascule automatique transparente
INV-52-08	CA-52-10	TC-NOM-12, TC-INV-08	Oui	Hash et metadonnees non identifiantes uniquement
INV-52-09	CA-52-06, CA-52-11	TC-NOM-08, TC-ERR-08	Oui	Finalite apres seuil de confirmations
INV-52-10	CA-52-08	TC-NOM-10	Oui	Metriques minimales exposables
INV-52-11	-	TC-INV-11a, TC-INV-11b	Oui	Erreurs deterministes sans fuite de secret
INV-52-12	CA-52-12	TC-NOM-13, TC-INV-12	Oui	Tests executes en CI
INV-52-13	-	TC-INV-13	Oui	Seuil confirmations configurable

2.2 Criteres d'acceptation → Tests¶

ID Critere	ID Test(s)	Couverture	Commentaire
CA-52-01	TC-NOM-01	Oui	10 appels Polygon
CA-52-02	TC-NOM-02	Oui	10 appels Arbitrum
CA-52-03	TC-NOM-03, TC-NOM-04, TC-NOM-05	Oui	Couverture S1, S2, S3
CA-52-04	TC-NOM-06	Oui	Signature verifiable
CA-52-05	TC-NOM-07	Oui	Ecart gas < 25%
CA-52-06	TC-NOM-08	Oui	Confirmation <= 30s
CA-52-07	TC-NOM-09	Oui	Failover < 5s
CA-52-08	TC-NOM-10	Oui	4 metriques presentes
CA-52-09	TC-NOM-11, TC-INV-03a, TC-INV-03b, TC-INV-03c	Oui	Audit multi-couche
CA-52-10	TC-NOM-12	Oui	Payload inspect
CA-52-11	TC-ERR-08	Oui	Reorg gere
CA-52-12	TC-NOM-13, TC-INV-12	Oui	CI verte + couverture >= 80%
CA-52-13	TC-ERR-14	Oui	Validation payload entrante

2.3 Cas d'erreur → Tests¶

ID Cas d'erreur	ID Test(s)	Couverture	Commentaire
ERR-52-01	TC-ERR-01	Oui	Bascule automatique
ERR-52-02	TC-ERR-02	Oui	Erreur bloquante RPC_UNAVAILABLE
ERR-52-03	TC-ERR-03	Oui	CUSTODY_MODE_MISSING
ERR-52-04	TC-ERR-04	Oui	CUSTODY_MODE_INVALID
ERR-52-05	TC-ERR-05	Oui	SIGNATURE_VERIFICATION_FAILED
ERR-52-06	TC-ERR-06	Oui	INSUFFICIENT_FUNDS
ERR-52-07	TC-ERR-07	Oui	GAS_PRICE_CEILING_EXCEEDED
ERR-52-08	TC-ERR-08	Oui	Reorg avant finalite
ERR-52-09	TC-ERR-09	Oui	Fuite de secret detectee
ERR-52-10	TC-ERR-10	Oui	CUSTODY_MODE_AMBIGUOUS
ERR-52-11	TC-ERR-11	Oui	CUSTODY_MODE_UNKNOWN
ERR-52-12	TC-ERR-12	Oui	RPC_INVALID_ENDPOINT
ERR-52-13	TC-ERR-13	Oui	MAINNET_FORBIDDEN
ERR-52-14	TC-ERR-14	Oui	PAYLOAD_VALIDATION_FAILED

3. Scenarios de test — Flux nominaux¶

TEST-ID: TC-NOM-01
Reference spec: FN-52-01, CA-52-01, INV-52-01

GIVEN
  - Un endpoint RPC Polygon testnet (Amoy) valide et accessible
  - Le service est demarre avec la configuration Polygon active
WHEN
  - 10 appels consecutifs `eth_blockNumber` sont executes sur l'endpoint Polygon
THEN
  - Les 10 appels retournent un numero de bloc valide (entier > 0)
  - Aucun appel ne retourne d'erreur
  - Le temps de reponse de chaque appel est journalise
AND
  - Le journal contient 10 entrees de succes consecutives pour Polygon
  - Les numeros de blocs sont monotones non decroissants

TEST-ID: TC-NOM-02
Reference spec: FN-52-01, CA-52-02, INV-52-01

GIVEN
  - Un endpoint RPC Arbitrum testnet (Sepolia) valide et accessible
  - Le service est demarre avec la configuration Arbitrum active
WHEN
  - 10 appels consecutifs `eth_blockNumber` sont executes sur l'endpoint Arbitrum
THEN
  - Les 10 appels retournent un numero de bloc valide (entier > 0)
  - Aucun appel ne retourne d'erreur
  - Le temps de reponse de chaque appel est journalise
AND
  - Le journal contient 10 entrees de succes consecutives pour Arbitrum
  - Les numeros de blocs sont monotones non decroissants

TEST-ID: TC-NOM-03
Reference spec: FN-52-02, CA-52-03, INV-52-04

GIVEN
  - Le mode de custody S1 (CloudHSM/PKCS#11) est configure
  - L'infrastructure CloudHSM est accessible en environnement de test
  - Aucun autre mode (S2, S3) n'est active simultanement
WHEN
  - Un test de capacite de signature secp256k1 est execute via PKCS#11
THEN
  - Le mode S1 est marque "valide"
  - Le journal de selection affiche un unique mode actif : S1
  - La signature produite est verifiable cryptographiquement
AND
  - Aucun fallback implicite vers un autre mode n'est tente
  - L'evenement de selection est journalise avec horodatage

TEST-ID: TC-NOM-04
Reference spec: FN-52-02, CA-52-03, INV-52-04

GIVEN
  - Le mode de custody S2 (AWS KMS ECC_SECG_P256K1 ou Vault Transit) est configure
  - Les droits IAM/Vault sont actifs en environnement de test
  - Aucun autre mode (S1, S3) n'est active simultanement
WHEN
  - Un test de capacite de signature secp256k1 est execute via KMS ou Vault Transit
THEN
  - Le mode S2 est marque "valide"
  - Le journal de selection affiche un unique mode actif : S2
  - La signature produite est verifiable cryptographiquement
AND
  - Aucun fallback implicite vers un autre mode n'est tente
  - L'evenement de selection est journalise avec horodatage

TEST-ID: TC-NOM-05
Reference spec: FN-52-02, CA-52-03, INV-52-04

GIVEN
  - Le mode de custody S3 (hybride HSM + secret chiffre Vault) est configure
  - Le materiel derive est accessible et le secret est stocke chiffre dans Vault
  - Aucun autre mode (S1, S2) n'est active simultanement
WHEN
  - Un test de capacite de signature secp256k1 est execute sur le materiel derive
THEN
  - Le mode S3 est marque "valide"
  - Le journal de selection affiche un unique mode actif : S3
  - La signature produite est verifiable cryptographiquement
  - Le secret reste chiffre au repos dans Vault (non extrait en clair)
AND
  - Aucun fallback implicite vers un autre mode n'est tente
  - L'evenement de selection est journalise avec horodatage

TEST-ID: TC-NOM-06
Reference spec: FN-52-03, CA-52-04, INV-52-03

GIVEN
  - Un message canonique de test defini (ex: "ProbatioVault-PD52-connectivity-check")
  - Une adresse wallet de service attendue connue
  - Un custody mode valide selectionne
WHEN
  - Le wallet signe le message canonique
THEN
  - Une signature Ethereum (r, s, v) est retournee
  - La verification ecrecover retrouve l'adresse wallet attendue
  - La signature est conforme au format EIP-191 ou EIP-712
AND
  - A aucun moment la cle privee n'apparait dans les logs ou la reponse
  - L'operation de signature est journalisee (horodatage, adresse, hash du message)

TEST-ID: TC-NOM-07
Reference spec: FN-52-04, CA-52-05

GIVEN
  - Une transaction type d'ancrage est construite (payload minimal representatif)
  - Le reseau cible est un testnet (Polygon ou Arbitrum)
  - Le wallet dispose de fonds testnet suffisants
WHEN
  - Le systeme estime le gas pour cette transaction
  - Puis la transaction est effectivement executee
THEN
  - L'estimation de gas est un entier positif
  - Le gas reellement consomme est mesure apres execution
  - L'ecart relatif |gas_estime - gas_reel| / gas_reel est inferieur a 25%
AND
  - L'estimation et la mesure reelle sont journalisees pour audit
  - La comparaison est disponible dans les metriques

TEST-ID: TC-NOM-08
Reference spec: FN-52-05, CA-52-06, INV-52-02, INV-52-09

GIVEN
  - Une transaction de test est prete pour emission sur un testnet cible
  - Le wallet dispose de fonds testnet suffisants
  - Le custody mode est valide
  - Le seuil de confirmations est configure (valeur connue)
WHEN
  - La transaction est emise sur le testnet
  - Le systeme suit le hash de transaction jusqu'a inclusion et confirmations
THEN
  - La transaction est incluse dans un bloc
  - Le nombre de confirmations atteint le seuil configure
  - La transaction est marquee "finalisee" uniquement apres atteinte du seuil
  - Le temps total emission → finalisation est <= 30 secondes
AND
  - Le hash de transaction est journalise
  - L'etat de confirmation est tracable dans le journal
  - La transaction est bien sur testnet (chain ID testnet verifie)

TEST-ID: TC-NOM-09
Reference spec: FN-52-06, CA-52-07, INV-52-06, INV-52-07

GIVEN
  - Un provider primaire et un provider secondaire sont configures pour un reseau
  - Le provider primaire est rendu indisponible (simulation: coupure, timeout)
  - Le provider secondaire est operationnel
WHEN
  - Un appel RPC (ex: `eth_blockNumber`) est execute
THEN
  - Le systeme detecte l'echec sur le provider primaire
  - La bascule vers le provider secondaire est automatique
  - L'appel RPC retourne un resultat valide via le secondaire
  - Le temps total de bascule est < 5 secondes
AND
  - L'appelant applicatif n'a pas connaissance du failover (transparence)
  - Le changement de provider est journalise (provider source, provider cible, duree de bascule)
  - Le provider actif est mis a jour dans les metriques

TEST-ID: TC-NOM-10
Reference spec: FN-52-07, CA-52-08, INV-52-10

GIVEN
  - Le service est en execution avec au moins un reseau connecte
  - Des transactions ont ete effectuees (ou le service tourne depuis > 1 minute)
WHEN
  - L'endpoint ou le rapport d'observabilite est consulte
THEN
  - Les metriques suivantes sont presentes :
    1. Latence RPC (derniere mesure)
    2. Gas price (derniere mesure)
    3. Solde wallet (en unites natives du reseau)
    4. Provider actif (identifiant du provider en cours d'utilisation)
  - Chaque metrique est horodatee
AND
  - Les valeurs sont coherentes avec l'etat runtime observe
  - Le format est exploitable pour supervision et alerting (JSON ou Prometheus)

TEST-ID: TC-NOM-11
Reference spec: CA-52-09, INV-52-03

GIVEN
  - Une campagne de tests complete a ete executee
  - Les logs applicatifs, les fichiers de configuration et le code source sont accessibles
WHEN
  - Un audit automatise est execute sur :
    1. Les logs applicatifs (recherche de patterns cle privee hexadecimale 64 chars, mnemonic, seed)
    2. Les fichiers de configuration (recherche de cle en clair)
    3. Le code source (recherche de hardcoded secrets)
    4. Les variables d'environnement runtime
    5. Les traces (OpenTelemetry ou autre)
THEN
  - Aucune cle privee en clair n'est detectee dans aucune des 5 sources
  - Aucun materiel secret exploitable n'est expose
AND
  - Le rapport d'audit est genere avec zero finding critique

TEST-ID: TC-NOM-12
Reference spec: CA-52-10, INV-52-08

GIVEN
  - Au moins une transaction type d'ancrage a ete emise sur testnet
  - Le payload de la transaction est inspectable (via explorateur testnet ou API)
WHEN
  - Le payload (data field) de la transaction est inspecte
THEN
  - Le payload contient exclusivement des hash (hexadecimaux)
  - Aucun champ ne contient de donnees personnelles (noms, emails, adresses physiques)
  - Aucune metadonnee identifiante n'est presente
AND
  - L'inspection est reproductible via le hash de transaction
  - Le format du payload est documente pour audit

TEST-ID: TC-NOM-13
Reference spec: CA-52-12, INV-52-12

GIVEN
  - Le code source est commite dans le repository
  - Le pipeline CI est configure et operationnel
  - Les tests unitaires et d'integration sont ecrits
WHEN
  - Le pipeline CI est declenche
THEN
  - Les tests unitaires s'executent avec succes
  - Les tests d'integration s'executent avec succes
  - La couverture unitaire est >= 80%
  - Le pipeline est vert (statut success)
AND
  - Le rapport de couverture est genere et accessible
  - Aucun test n'est marque "skip" sauf justification documentee

4. Scenarios de test — Cas d'erreur¶

TEST-ID: TC-ERR-01
Reference spec: ERR-52-01, INV-52-07

GIVEN
  - Le provider primaire RPC est indisponible (timeout ou erreur reseau)
  - Le provider secondaire est operationnel
WHEN
  - Un appel RPC est effectue par le service
THEN
  - L'erreur sur le primaire est detectee
  - La bascule vers le secondaire est automatique
  - L'appel est servi par le secondaire sans erreur remontee a l'appelant
AND
  - L'erreur du primaire est journalisee (code, message, timestamp)
  - Le journal NE contient PAS de secret (token, cle API provider en clair)
  - La metrique "provider actif" est mise a jour vers le secondaire

TEST-ID: TC-ERR-02
Reference spec: ERR-52-02

GIVEN
  - Le provider primaire RPC est indisponible
  - Le provider secondaire RPC est egalement indisponible
WHEN
  - Un appel RPC est effectue par le service
THEN
  - Le systeme retourne l'erreur `RPC_UNAVAILABLE`
  - L'appel est marque en echec
  - Aucune tentative de transaction n'est effectuee
AND
  - L'erreur est journalisee avec le code `RPC_UNAVAILABLE`, le reseau concerne et l'horodatage
  - Les deux providers en echec sont mentionnes dans le journal
  - Le systeme reste dans un etat stable (pas de crash, pas de retry infini)

TEST-ID: TC-ERR-03
Reference spec: ERR-52-03, INV-52-04, INV-52-05

GIVEN
  - Aucun custody mode (S1, S2, S3) n'est defini dans la configuration
  - (Variante : le champ de configuration est vide ou absent)
WHEN
  - Le systeme tente d'initier une signature ou emission de transaction
THEN
  - Le systeme retourne l'erreur `CUSTODY_MODE_MISSING`
  - Aucune tentative de signature n'est effectuee
  - Aucune transaction n'est emise
AND
  - L'erreur est journalisee avec le code `CUSTODY_MODE_MISSING`
  - Le systeme ne bascule pas implicitement sur un mode par defaut

TEST-ID: TC-ERR-04
Reference spec: ERR-52-04, INV-52-04, INV-52-05

GIVEN
  - Un custody mode est configure (ex: S1)
  - La capacite secp256k1 pour ce mode est non fonctionnelle
    (ex: CloudHSM inaccessible, KMS sans permission, cle corrompue)
WHEN
  - Le systeme execute le test de capacite de signature
THEN
  - Le systeme retourne l'erreur `CUSTODY_MODE_INVALID`
  - Le mode est marque "invalide"
  - L'emission de transaction est interdite
AND
  - L'erreur est journalisee avec le code `CUSTODY_MODE_INVALID` et le mode concerne
  - Le systeme ne bascule pas vers un autre mode de custody
  - Aucune signature degradee n'est produite

TEST-ID: TC-ERR-05
Reference spec: ERR-52-05

GIVEN
  - Un custody mode est configure et marque "valide"
  - La signature produite ne correspond PAS a l'adresse wallet attendue
    (ex: cle incorrecte, desynchronisation adresse/cle)
WHEN
  - Le systeme verifie la signature apres signature du message canonique
THEN
  - Le systeme retourne l'erreur `SIGNATURE_VERIFICATION_FAILED`
  - Le mode est marque "non conforme"
  - Aucune transaction n'est emise avec cette signature
AND
  - L'erreur est journalisee avec l'adresse attendue, l'adresse recuperee, et le hash du message
  - Ni la cle privee ni la signature brute ne figurent dans les logs

TEST-ID: TC-ERR-06
Reference spec: ERR-52-06

GIVEN
  - Le wallet de service a un solde insuffisant pour couvrir le gas estime
  - Le gas estime pour la transaction type est connu
WHEN
  - Le systeme tente d'emettre une transaction
THEN
  - Le systeme retourne l'erreur `INSUFFICIENT_FUNDS`
  - La transaction n'est pas emise
AND
  - L'erreur est journalisee avec le solde actuel, le gas estime, et le deficit
  - Le solde wallet est mis a jour dans les metriques
  - Aucune transaction partielle n'est soumise au reseau

TEST-ID: TC-ERR-07
Reference spec: ERR-52-07

GIVEN
  - Un plafond gas est configure (ex: 100 Gwei)
  - Le gas price actuel du reseau depasse ce plafond
WHEN
  - Le systeme tente d'emettre une transaction
THEN
  - Le systeme retourne l'erreur `GAS_PRICE_CEILING_EXCEEDED`
  - La transaction est rejetee ou mise en attente selon la politique configuree
AND
  - L'erreur est journalisee avec le gas price actuel et le plafond configure
  - La metrique gas price est mise a jour
  - La politique appliquee (rejet strict / mise en queue) est tracee dans le journal

TEST-ID: TC-ERR-08
Reference spec: ERR-52-08, CA-52-11, INV-52-09

GIVEN
  - Une transaction est incluse dans un bloc mais n'a pas atteint le seuil de confirmations
  - Une reorganisation de chaine (reorg) survient
    (simulation : le bloc contenant la transaction est invalide)
WHEN
  - Le systeme detecte que le bloc de la transaction n'est plus dans la chaine canonique
THEN
  - L'etat de la transaction repasse a "non finalisee"
  - Le suivi de la transaction continue jusqu'a nouvelle inclusion et finalite
  - Si la transaction ne reapparait pas apres un delai configurable, elle est marquee "echouee"
AND
  - Le changement d'etat est journalise (finalisee → non finalisee → suivi repris)
  - Aucune confirmation prematuree n'est emise a l'appelant

TEST-ID: TC-ERR-09
Reference spec: ERR-52-09, INV-52-03

GIVEN
  - Une campagne de tests est en cours d'execution
  - Un mecanisme de detection de fuite de secrets est actif (scanner de logs)
WHEN
  - Le scanner detecte un pattern de cle privee ou secret exploitable dans les logs
THEN
  - La campagne d'acceptation est immediatement interrompue
  - Un statut "non-conformite securite" est emis
  - Le test global est marque en echec
AND
  - Le fichier et la ligne contenant la fuite sont identifies dans le rapport
  - L'interruption est automatique (pas de validation manuelle requise)
  - Le rapport de non-conformite est genere pour audit

5. Tests d'invariants (non negociables)¶

Invariant	Test(s) dedies	Observable	Commentaire
INV-52-01	TC-NOM-01, TC-NOM-02	10/10 succes sur chaque reseau	Polygon ET Arbitrum obligatoires
INV-52-02	TC-INV-02	Chain ID testnet verifie	Voir scenario ci-dessous
INV-52-03	TC-NOM-06, TC-NOM-11, TC-INV-03a, TC-INV-03b, TC-INV-03c	Zero secret en clair detecte	Couverture multi-couche
INV-52-04	TC-NOM-03, TC-NOM-04, TC-NOM-05, TC-INV-04	Journal de selection unique	Un et un seul mode
INV-52-05	TC-ERR-03, TC-ERR-04	Refus explicite avec code d'erreur	Aucune signature degradee
INV-52-06	TC-NOM-09, TC-INV-06	Deux providers configures par reseau	Minimum contractuel
INV-52-07	TC-NOM-09, TC-ERR-01	Bascule < 5s, transparente	Automatique sans intervention
INV-52-08	TC-NOM-12, TC-INV-08	Payload inspecte = hash uniquement	Aucune donnee identifiante
INV-52-09	TC-NOM-08, TC-ERR-08	Seuil de confirmations respecte	Protection reorg
INV-52-10	TC-NOM-10	4 metriques presentes et horodatees	Latence, gas, solde, provider
INV-52-11	TC-INV-11a, TC-INV-11b	Code d'erreur deterministe, sans secret	Diagnostic fiable
INV-52-12	TC-NOM-13, TC-INV-12	Pipeline CI vert, couverture >= 80%	Refus automatique sinon

Scenarios d'invariants dedies¶

TEST-ID: TC-INV-02
Reference spec: INV-52-02

GIVEN
  - Le service est configure pour operer sur testnet
WHEN
  - Une transaction est construite et signee
THEN
  - Le chain ID de la transaction correspond a un testnet connu :
    * Polygon Amoy : 80002
    * Arbitrum Sepolia : 421614
  - Aucun chain ID mainnet n'est utilise (137 pour Polygon, 42161 pour Arbitrum)
AND
  - La verification du chain ID est effectuee AVANT emission
  - Toute tentative avec un chain ID mainnet est bloquee avec erreur explicite

TEST-ID: TC-INV-03a
Reference spec: INV-52-03

GIVEN
  - Le code source est accessible
WHEN
  - Une analyse statique (grep, scanner de secrets type gitleaks/trufflehog) est executee
THEN
  - Aucune cle privee hexadecimale (64 caracteres) n'est detectee
  - Aucun mnemonic (12/24 mots BIP-39) n'est detecte
  - Aucun seed n'est detecte
AND
  - Le scan couvre tous les fichiers du repository (y compris historique git)

TEST-ID: TC-INV-03b
Reference spec: INV-52-03

GIVEN
  - Le service est en execution et a traite des transactions
WHEN
  - Les logs applicatifs sont inspectes (grep de patterns cryptographiques)
THEN
  - Aucune cle privee en clair n'apparait dans les logs
  - Aucun materiel secret (seed, mnemonic, cle brute) n'est journalise
AND
  - Les logs contiennent uniquement des adresses publiques et hash de transactions

TEST-ID: TC-INV-03c
Reference spec: INV-52-03

GIVEN
  - Les variables d'environnement runtime sont inspectables
WHEN
  - La liste des variables d'environnement est auditee
THEN
  - Aucune variable ne contient une cle privee en clair
  - Les references aux secrets sont des chemins Vault ou des identifiants KMS (jamais des valeurs brutes)
AND
  - L'audit couvre les environnements de test et de CI

TEST-ID: TC-INV-04
Reference spec: INV-52-04

GIVEN
  - Le systeme est configure avec deux modes de custody simultanement (ex: S1 et S2)
WHEN
  - Le systeme demarre et tente de selectionner un mode
THEN
  - Le systeme refuse de demarrer ou retourne une erreur `CUSTODY_MODE_AMBIGUOUS`
  - Aucune signature n'est possible tant que la configuration est ambigue
AND
  - L'erreur est journalisee avec les modes en conflit

TEST-ID: TC-INV-06
Reference spec: INV-52-06

GIVEN
  - La configuration reseau est chargee
WHEN
  - La liste des providers par reseau est inspectee
THEN
  - Chaque reseau (Polygon, Arbitrum) a au minimum 2 providers configures (primaire + secondaire)
  - Les endpoints sont distincts (pas de duplication)
AND
  - La configuration est validee au demarrage du service
  - Si un reseau n'a qu'un seul provider, le demarrage echoue avec erreur explicite

TEST-ID: TC-INV-08
Reference spec: INV-52-08

GIVEN
  - Toutes les transactions emises pendant la campagne de test sont collectees
WHEN
  - Chaque payload est decode et analyse
THEN
  - Les donnees emises sont exclusivement :
    * Hash de documents (SHA-256 ou equivalent)
    * Metadonnees techniques (timestamp, version, type d'operation)
  - Aucun champ ne contient : nom, email, adresse, numero de document, ni toute donnee a caractere personnel
AND
  - L'analyse couvre 100% des transactions emises pendant la campagne

TEST-ID: TC-INV-11a
Reference spec: INV-52-11

GIVEN
  - Une erreur RPC survient (timeout, erreur reseau, reponse malformee)
WHEN
  - Le systeme traite l'erreur
THEN
  - Un code d'erreur deterministe est retourne (ex: `RPC_TIMEOUT`, `RPC_UNAVAILABLE`, `RPC_MALFORMED_RESPONSE`)
  - Le code d'erreur est le meme pour des conditions d'erreur identiques (determinisme)
AND
  - L'erreur est journalisee avec : code, reseau, provider, horodatage
  - Le message d'erreur ne contient ni token d'API provider ni secret

TEST-ID: TC-INV-11b
Reference spec: INV-52-11

GIVEN
  - Une erreur de signature survient (HSM timeout, KMS erreur, cle invalide)
WHEN
  - Le systeme traite l'erreur
THEN
  - Un code d'erreur deterministe est retourne (ex: `SIGNATURE_FAILED`, `HSM_UNAVAILABLE`)
  - Le message d'erreur ne contient aucun materiel cryptographique
AND
  - L'erreur est journalisee avec : code, mode custody, horodatage
  - Aucune partie de la cle privee ou du processus de derivation n'est exposee

TEST-ID: TC-INV-12
Reference spec: INV-52-12

GIVEN
  - Le pipeline CI est configure avec les stages de test
WHEN
  - Un commit est pousse sur la branche de la story
THEN
  - Les tests contractuels PD-52 sont automatiquement executes
  - Si un test echoue, le pipeline est en echec (pas de passage en force)
  - La couverture unitaire est calculee et rapportee (>= 80%)
AND
  - Le rapport de tests et de couverture est publie comme artefact CI
  - Aucun test ne peut etre desactive sans justification dans le code (commentaire + ticket)

6. Tests de non-regression¶

Test ID	Objet	Observable	Commentaire
TC-NR-01	Reconnexion apres interruption reseau temporaire	Le service reprend les appels RPC sans redemarrage apres retour du reseau	Stabilite long terme
TC-NR-02	Re-selection du mode custody apres redemarrage du service	Le mode configure avant arret est re-selectionne et re-valide au redemarrage	Pas de perte de configuration
TC-NR-03	Stabilite du failover apres bascule repetee	Apres 5 bascules primaire↔secondaire, le systeme reste stable et fonctionnel	Pas de fuite memoire ou d'etat corrompu
TC-NR-04	Coherence des metriques apres failover	Les metriques refletent le provider actif reel apres une ou plusieurs bascules	Metriques fiables post-incident
TC-NR-05	Transaction apres failover	Une transaction emise apres failover est correctement signee et confirmee	Chaine signature → emission intacte apres bascule
TC-NR-06	Pas de regression sur chain ID apres changement de configuration	La modification d'un endpoint RPC ne permet pas d'emettre sur mainnet	Protection INV-52-02 persistante
TC-NR-07	Learning PD-7 : tests en CI apres chaque modification	Toute modification du code PD-52 declenche l'execution des tests en CI	Refus automatique si CI non verte

7. Tests negatifs et adversariaux¶

Test ID	Entree invalide / abus	Resultat attendu	Observable
TC-NEG-01	Configuration avec un custody mode inexistant (ex: "S4")	Rejet au demarrage avec erreur `CUSTODY_MODE_UNKNOWN`	Log d'erreur avec le mode invalide
TC-NEG-02	Appel RPC avec endpoint URL malformee	Erreur `RPC_INVALID_ENDPOINT` au demarrage, pas de tentative de connexion	Validation de configuration precoce
TC-NEG-03	Injection dans le payload de transaction (donnees personnelles en hex dans le champ data)	La couche de validation rejette le payload non conforme ou le transforme en hash	Aucune donnee identifiante emise on-chain
TC-NEG-04	Tentative d'emission sur mainnet chain ID (137 ou 42161)	Transaction bloquee avec erreur `MAINNET_FORBIDDEN`	Protection INV-52-02
TC-NEG-05	Envoi massif de transactions (100 en 10 secondes) pour epuiser le solde	Le systeme detecte le solde insuffisant et refuse apres seuil, pas de dette gas	Erreur `INSUFFICIENT_FUNDS` avant epuisement total
TC-NEG-06	Modification de la configuration custody mode pendant une signature en cours	La signature en cours utilise le mode initial, pas de corruption mid-flight	Coherence transactionnelle
TC-NEG-07	Provider primaire retourne des reponses JSON-RPC valides mais avec des donnees incoherentes (bloc = 0, gas = -1)	Le systeme detecte l'incoherence et declenche le failover ou retourne une erreur	Protection contre provider compromis
TC-NEG-08	Tentative de lecture de la cle privee via l'API d'observabilite	L'endpoint ne retourne aucun secret, uniquement les metriques contractuelles	Separation stricte metriques / secrets
TC-NEG-09	Timeout extreme sur provider primaire (> 30 secondes de latence)	Failover declenche dans le delai contractuel (< 5s), pas d'attente des 30s	Timeout de detection << timeout provider
TC-NEG-10	Deux instances du service tentent d'utiliser le meme wallet simultanement	Pas de double-spend, nonce manage correctement ou erreur explicite	Protection contre race condition

8. Observabilite requise pour les tests¶

Pour que les scenarios ci-dessus soient executables et verifiables, les observables suivants doivent etre disponibles :

Etat systeme¶

Custody mode actif (S1/S2/S3 ou aucun)
Provider actif par reseau (primaire/secondaire)
Etat de connexion par reseau (connecte/deconnecte)
Nombre de failovers depuis le demarrage

Reponse API / Service¶

Code de retour structure pour chaque operation (succes ou erreur deterministe)
Hash de transaction retourne apres emission
Etat de finalisation par transaction (pending/confirmed/finalized/failed)
Estimation de gas avant emission

Journal d'audit¶

Evenements de selection du custody mode (horodatage, mode, resultat)
Evenements de signature (horodatage, adresse, hash message, succes/echec — JAMAIS de cle)
Evenements de failover (horodatage, provider source, provider cible, duree)
Evenements de transaction (horodatage, hash, reseau, chain ID, statut)
Erreurs RPC (horodatage, code, reseau, provider — JAMAIS de token API)

Metriques operationnelles¶

Latence RPC (derniere mesure, par reseau et provider)
Gas price (derniere mesure, par reseau)
Solde wallet (derniere mesure, par reseau)
Provider actif (identifiant, par reseau)
Horodatage de chaque metrique

Export probatoire¶

Rapport d'audit de secrets (resultat du scan, nombre de findings)
Rapport de couverture de tests (pourcentage, fichiers couverts)
Rapport d'inspection des payloads on-chain (hash des transactions, contenu decode)
Historique de confirmations par transaction (bloc, nombre de confirmations, horodatage)

9. Regles non testables¶

Regle	Raison	Impact
"Perception utilisateur de la confiance induite par la blockchain" (hors perimetre spec)	Subjectif, non mesurable, hors perimetre contractuel PD-52	Mineur — correctement exclu par la specification
"Interpretation juridique definitive de la valeur probatoire" (hors perimetre spec)	Depend de la juridiction et de l'evolution legale, non deterministe	Mineur — correctement exclu par la specification
Comportement exact en cas de reorg prolongee (> N blocs)	Le seuil de confirmations n'est pas encore defini (point a clarifier #1). Le test TC-ERR-08 couvre le cas nominal mais le comportement apres un delai prolonge sans re-inclusion est indetermine	Majeur — necessite clarification du seuil et du timeout d'abandon
Politique exacte GAS_PRICE_CEILING_EXCEEDED (rejet vs queue vs TTL)	Point a clarifier #3 de la specification. TC-ERR-07 couvre le cas generique mais la politique precise est non testable tant que non definie	Majeur — necessite decision architecturale
Critere de conformite S3 "secret chiffre au repos"	Point a clarifier #5 de la specification. La methode de preuve que le materiel derive reste chiffre n'est pas definie	Majeur — bloque la validation complete de TC-NOM-05 sur le volet chiffrement au repos
Seuil de solde wallet "critique" pour alerting	Point a clarifier #7 de la specification. Le seuil d'alerte n'est pas defini	Mineur — n'impacte pas les tests fonctionnels, uniquement l'alerting operationnel

10. Verdict QA¶

⚠️ Testable partiellement (avec reserves listees)

Couverture atteinte¶

12/12 invariants couverts par au moins un scenario de test
12/12 criteres d'acceptation couverts par au moins un scenario de test
9/9 cas d'erreur couverts par un scenario dedie
7 flux nominaux couverts integralement
7 tests de non-regression definis
10 tests negatifs/adversariaux definis
Total : 43 scenarios de test

Reserves¶

Les reserves suivantes doivent etre levees avant acceptation :

#	Reserve	Points a clarifier references	Impact
R1	Seuil de confirmations non defini par reseau	Point #1	TC-NOM-08 et TC-ERR-08 executables mais seuil = parametre a fournir
R2	Politique GAS_PRICE_CEILING_EXCEEDED non tranchee	Point #3	TC-ERR-07 couvre le cas generique, verification de la politique exacte impossible
R3	Methode de preuve S3 "chiffre au repos" non specifiee	Point #5	TC-NOM-05 partiellement verifiable sur le volet chiffrement
R4	Endpoint d'observabilite non defini (format/source de verite)	Point #6	TC-NOM-10 verifiable sur le contenu, format exact non validable
R5	Definition normative "transaction type d'ancrage" pendante	Point #2	TC-NOM-07, TC-NOM-08, TC-NOM-12 utilisent un payload "representatif" non canonique

Recommandation¶

Les 5 reserves sont liees aux points a clarifier identifies dans la specification. Aucune ne bloque la redaction des tests mais elles devront etre resolues pour que la campagne d'acceptation soit pleinement executable. Le cadre de test est complet et pret pour implementation des qu'une decision sera prise sur ces points.