Aller au contenu

PD-21 — Acceptabilité

Objectif

Vérifier que l’implémentation est conforme à la spécification, respecte l’ensemble des invariants ProbatioVault et ne présente aucune incohérence ou oubli critique.

Périmètre de vérification

La revue d’acceptabilité vérifie explicitement :

  • la conformité stricte à la spécification fonctionnelle
  • le respect de tous les invariants applicables
  • la couverture des scénarios de test définis
  • l’absence d’incohérences, oublis ou régressions

Écarts identifiés

Chaque écart constaté doit être documenté et classé selon sa gravité.

Classification des écarts

Niveau Définition
BLOQUANT Violation d’un invariant, faille de sécurité, non-conformité majeure à la spec
MAJEUR Fonction incomplète, comportement non conforme mais sans rupture de sécurité
MINEUR Détail, dette acceptable, amélioration non critique

Détail des écarts

ID Description Référence Gravité Statut
E-01 Invariant des trois queues non respecté : seule la queue DEFAULT est implémentée (JobType DEFAULT), les queues backup/export/blockchain requises par la spec ne sont ni créées ni initialisées. Spec §2.1 (queues backup/export/blockchain), §4.1-4.2 ; Plan §1.3 BLOQUANT ✅ RÉSOLU
E-02 Exécution "au plus une fois" ambiguë : attempts=1 mais le mécanisme de retry via Prefect crée de nouveaux jobs sans contrainte d'idempotence ni déduplication effective (idempotencyKey optionnelle, non vérifiée). Spec §4.3 (exécuté au plus une fois ou échec explicite), §5.⅖.3 ; Plan §2.4 MAJEUR ✅ RÉSOLU

Résolutions appliquées (2025-12-23)

E-01 - Queues contractuelles :

  • Ajout des queues BACKUP, EXPORT, BLOCKCHAIN dans queue-names.ts
  • Mise à jour du mapping job-type-queue-map.ts : les job types métiers sont mappés vers leurs queues respectives
  • Enregistrement des 4 queues dans jobs.module.ts via BullModule.registerQueue()

E-02 - Idempotence obligatoire (Option B) :

  • Ajout de la méthode abstraite getIdempotencyKey(job): string | null dans BaseProcessor
  • Vérification d'idempotence OBLIGATOIRE dans handleJob() AVANT markRunning()
  • Enregistrement automatique de l'effet après succès via recordEffect()
  • Chaque processor DOIT implémenter getIdempotencyKey() (contrat TypeScript)
  • Tests E-02 ajoutés pour valider le comportement

[2025-12-23] — Suivi E-01

  • Statut précédent : BLOQUANT
  • Statut actuel : RÉSOLU
  • Justification factuelle :
  • QUEUE_NAMES déclare désormais BACKUP, EXPORT, BLOCKCHAIN en plus de DEFAULT.
  • Mapping strict JobType → Queue dans job-type-queue-map.ts (DOCUMENT_ARCHIVE→BACKUP, BLOCKCHAIN_→BLOCKCHAIN, EXPORT_→EXPORT).
  • Enregistrement des 4 queues contractuelles dans jobs.module.ts via BullModule.registerQueue(...).
  • Référence vérification :
  • src/modules/jobs/constants/queue-names.ts
  • src/modules/jobs/constants/job-type-queue-map.ts
  • src/modules/jobs/jobs.module.ts

[2025-12-23] — Suivi E-02

  • Statut précédent : MAJEUR
  • Statut actuel : RÉSOLU
  • Justification factuelle :
  • Idempotence imposée : BaseProcessor rend getIdempotencyKey abstraite et appelle checkIdempotency/recordEffect dans handleJob() avant tout effet irréversible ; jobs déjà traités sont marqués SKIPPED et journalisés.
  • Tests processors/services couvrent l’idempotence et les reprises.
  • Référence vérification :
  • src/modules/jobs/processors/base.processor.ts
  • src/modules/jobs/jobs.service.ts
  • Tests : src/modules/jobs/processors/.spec.ts ; src/modules/jobs/services/.spec.ts

Conclusion d'acceptabilité

✅ ACCEPTÉ

Tous les écarts identifiés ont été corrigés :

  • E-01 (BLOQUANT) : Les 4 queues contractuelles sont maintenant implémentées et enregistrées
  • E-02 (MAJEUR) : L'idempotence est garantie par contrat via la méthode abstraite getIdempotencyKey()

Historique des verdicts

Date Verdict Version Commentaire
2025-12-23 ✅ ACCEPTÉ v2 E-01 et E-02 résolus : queues contractuelles + idempotence obligatoire
2025-12-23 ⛔ REFUSÉ v1 E-01 BLOQUANT (queues absentes), E-02 MAJEUR (unicité non garantie)