Aller au contenu

PD-275 — Plan d’implémentation : Revue

1. Références

  • Spécification : PD-275-specification.md
  • Tests contractuels : PD-275-tests.md
  • Plan d’implémentation : PD-275-plan.md
  • Date de revue : 2026-02-28
  • Reviewer : Auditeur technique indépendant (OpenCode)

2. Constatations (écarts)

Type Référence (Spec/Test/Plan) Description Impact Gravité (BLOQUANT/MAJEUR/MINEUR)
Non-conformité Spec Spec §6 ERR-REVOKEDBY-SPOOFING / Spec INV-275-10 / Plan C7, FT3, §7.2 La spec contractualise le rejet d’injection revokedBy via payload/query/header métier. Le plan ne décrit explicitement que la détection dans le body DTO. Le traitement des vecteurs query/header n’est pas contractualisé dans le flux technique FT3. Conformité anti-usurpation incomplète sur le périmètre d’entrée demandé par la spec. MAJEUR
Couverture manquante Spec INV-275-11 / Spec Flux F4 step 2-4 / Plan FT4 La spec impose lecture/décision de soumission sous verrou FOR UPDATE dans le flux de soumission. Le plan introduit une transaction dédiée de pré-vérification puis un second contrôle plus tard dans submitBatch(), avec createBatch()/buildBatch() entre les deux. Le design décrit ne garantit pas une unique fenêtre décisionnelle sérialisée pour tout le flux de soumission. Exposition à des effets intermédiaires hors fenêtre de sérialisation contractuelle ; alignement partiel avec la sémantique F4. MAJEUR
Test irréalisable Test TC-NOM-10 / Spec Flux F4 step 6 / Plan FT4 TC-NOM-10 exige une oracle déterministe fondée sur l’ordre d’acquisition du verrou entre revokeSigner() et submitBatch(). Le plan de soumission comporte deux phases de verrou distinctes côté submit (pré-check puis re-check), ce qui ne correspond pas au modèle d’arbitrage unique de F4 step 6. La preuve de conformité attendue par TC-NOM-10 n’est pas directement démontrable avec la sémantique de verrou décrite ; verdict du test non univoque au regard du contrat F4. BLOQUANT
Hypothèse implicite Spec §3 (actor identity = JWT sub ou service account identity) / Spec H-06 / Plan C7, FT3, §7.2 Le plan fixe actorIdentity = request.user.sub sans contractualiser le comportement lorsque l’identité effective est de type service account non représentée via sub exploitable. Risque d’audit trail non conforme (revokedBy) ou de divergence d’implémentation selon type d’appelant. MAJEUR
Code Contract — Cohérence Code Contracts module signer-registry-service (interface revokeSigner(address, actorIdentity, actorRoles, manager)) / Plan C4 vs FT3 Incohérence interne entre interface contractuelle de service (inclut actorRoles) et flux FT3 qui appelle revokeSigner(address, actorIdentity, manager) sans actorRoles. Ambiguïté contractuelle sur l’effectivité de la double protection d’autorisation documentée. MAJEUR
Code Contract — Forbidden Code Contracts module signer-registry-service (Math.random() interdit) Pattern interdit non rattaché explicitement aux invariants PD-275 ni aux exigences de sécurité de la spec fournie. Frontière contractuelle étendue au-delà du périmètre PD-275, avec risque d’audit de conformité hors contrat. MINEUR
Contrainte technique non documentée Exigence revue axe 7 (dépendances inter-PD avec statut) / Plan §8 Le plan mentionne des dépendances (PD-177, Keycloak role, seed) mais ne les documente pas avec statut explicite DONE/TODO/STUB acceptable dans une section de contraintes techniques dédiée. Traçabilité d’exécution inter-story incomplète pour audit tiers. MINEUR

3. Synthèse

  • Nombre d’écarts par gravité : 1 BLOQUANT, 4 MAJEURS, 2 MINEURS.
  • Points critiques :
  • Non-alignement du flux concurrent submitBatch() avec la sémantique de sérialisation contractuelle unique attendue par F4/TC-NOM-10.
  • Couverture anti-usurpation revokedBy incomplète sur le périmètre d’entrée explicitement contractualisé.
  • Incohérence de contrat d’interface sur revokeSigner() (plan vs code contracts).

4. Verdict de la revue

  • Statut : ⛔ Rejeté
  • Motif synthétique : présence d’un écart BLOQUANT sur la testabilité contractuelle de la sérialisation concurrente (TC-NOM-10) et de plusieurs écarts MAJEURS de conformité/traçabilité contractuelle.