Aller au contenu

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

1. Références

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

2. Constatations (écarts)

Type Référence (Spec/Test/Plan) Description Impact Gravité (BLOQUANT/MAJEUR/MINEUR)
Non-conformité Spec Spec §6 (DDL contractuel) / Plan §1 C1, §2 F4 Le plan introduit DEFAULT '' sur owner_certificate_id et recipient_certificate_id, alors que le DDL canonique ne contractualise pas ce default pour ces colonnes. Écart contractuel de schéma ; risque de divergence entre preuve de conformité documentaire et implémentation réelle. MAJEUR
Couverture manquante INV-277-04 / CA-277-02 / TC-ERR-06, TC-NEG-05 / Plan §1 C4, §3 INV-277-04 Le mécanisme décrit pour le binding PKI valide explicitement la non-nullité/non-vacuité, mais ne décrit pas de contrôle explicite “invalide/révoqué/incompatible mandat” au niveau plan. Couverture incomplète des cas contractuels certificats invalides ; risque d’échec des tests d’erreur PKI. MAJEUR
Couverture manquante INV-277-01-fail-closed / INV-277-04 / Plan §1 C1, §2 F2, §9 V5 Le plan justifie des ReKeys pré-existants avec certificats vides (DEFAULT '') mais le flux reEncrypt décrit ne contient pas de contrôle explicite de validité du binding certificat avant succès. Possibilité de chemin opérationnel sans binding PKI valide pour des enregistrements hérités ; fail-closed non démontré sur ce cas. MAJEUR
Non-conformité Spec Spec §1, §5 (aucune règle ajoutée) / Plan §2 F2 étape 3 Le plan ajoute une condition status=ACTIVE dans reEncrypt, non explicitée dans la spécification canonique PD-277. Introduction d’un comportement de rejet non spécifié contractuellement. MAJEUR
Hypothèse implicite Spec §4 (génération nonce serveur) / Plan §2 F2 (“nouveau endpoint ou méthode”) La responsabilité de génération du nonce (appelant vs module legal-pre) reste implicite dans le plan et non verrouillée au niveau contrat d’interface décrit. Ambiguïté d’API et d’auditabilité de conformité sur la contrainte “server-only”. MINEUR
Code Contract — Frontière Code Contracts (règle “files ne se chevauchent pas”) / modules pd277-nonce-anti-replay et pd277-pki-binding Le même fichier src/modules/legal-pre/services/legal-rekey-manager.service.ts est alloué à deux modules propriétaires distincts. Violation de frontière contractuelle inter-agents ; traçabilité de responsabilité affaiblie. MAJEUR
Code Contract — Complétude Plan §1 C5 / Code Contracts (liste modules/files) Le composant C5 cite LegalReKeyRepository comme mécanisme principal, sans contrat de module/fichier dédié pour ce repository dans le YAML fourni. Un mécanisme du plan n’est pas couvert par un code contract explicite. MAJEUR
Contrainte technique non documentée Plan (absence section dédiée “Contraintes techniques” au format demandé) / Axe 7 Les dépendances inter-PD avec statut explicite DONE/TODO/STUB ne sont pas documentées sous forme structurée dédiée. Traçabilité de dépendances incomplète pour audit externe. MINEUR

3. Synthèse

  • Nombre d’écarts par gravité : BLOQUANT 0 / MAJEUR 6 / MINEUR 2
  • Points critiques :
  • Divergence contractuelle DDL sur les defaults certificats.
  • Couverture incomplète du binding PKI invalide/incompatible et du fail-closed sur reEncrypt pour ReKeys hérités.
  • Non-respect des frontières/complétude dans les code contracts.
  • Note domaine crypto-proof appliquée : les contraintes “framework Jest/Vitest” et “compatibilité ESM/CJS” ne sont pas retenues comme écarts dans cette revue.

4. Verdict de la revue

  • Statut : ⚠️ Accepté avec réserves
  • Motif synthétique : Le plan est globalement exécutable et testable, mais comporte des écarts majeurs de conformité contractuelle (DDL, couverture PKI/fail-closed) et de gouvernance des code contracts, incompatibles avec une conformité “stricte” sans réserve.