PD-277 — Plan d'implémentation : Revue¶
1. Références¶
PD-277-specification.mdv2 (Document 1)PD-277-tests.mdv2 (Document 2)PD-277-plan.mdv3 (Document 3)PD-277-code-contracts.yamlv2.0.0 (Document 4)- Contexte itération v3 (ECT-v2-01, ECT-v2-03, ECT-v2-05)
2. Constatations (écarts)¶
| Type | Référence | Description | Impact | Gravité |
|---|---|---|---|---|
| Ambiguïté de conformité | Spec §4 vs Plan §6 (erreurs 40001) | Le plan indique que le client régénère un nonce après 40001, alors que la spec impose crypto.randomUUID() côté serveur uniquement. | Risque de non-conformité INV/CA sur contrat nonce, divergence d’implémentation et de tests. | MAJEUR |
| Ambiguïté d’interface | Spec F2 / Plan F2+C3 | Le plan dit “endpoint existant, aucune modif controller”, mais introduit reEncryptWithNonce(...) avec nonce obligatoire. Sans preuve que l’API actuelle transporte déjà ce champ, la faisabilité reste incertaine. | Risque de trou d’intégration (nonce jamais injecté) ou changement API implicite non tracé. | MAJEUR |
| Écart contractuel DDL | Spec §6 DDL vs Plan C1 / Contracts module migration | La spec canonique ne contractualise pas DEFAULT '' pour certificats; le plan l’introduit comme décision d’implémentation (justifiée migration legacy), mais la présente comme “contractualisée §6.1” par endroits. | Ambiguïté normative en Gate: possible débat “spec vs plan” lors de validation finale. | MAJEUR |
| Couverture incomplète de l’immutabilité | INV-277-05 / Plan C5 / Contracts module repository | Le mécanisme proposé (“updateStatus() ne touche pas les champs”) est partiel; il ne démontre pas explicitement le rejet fail-closed pour toute autre voie d’update (save/update SQL direct via repository métier). | Risque de contournement de l’immutabilité certificats, non-respect INV-277-05. | MAJEUR |
| Risque probatoire non planifié | INV-277-06 / CA-277-06 | Le plan classe l’invariant at-rest “hors scope code”, mais ne matérialise pas explicitement la production des preuves de config attendues dans les livrables de clôture. | Risque de blocage en clôture conformité faute d’artefact probatoire, malgré code conforme. | MOYEN |
3. Synthèse¶
- Feasibility : techniquement réalisable dans l’ensemble, mais avec 2 ambiguïtés bloquantes à lever avant exécution sûre: source de génération du nonce (serveur/client) et point d’injection API réel du nonce.
- Coverage : bonne couverture structurelle des INV/CA et TC-*, y compris concurrence, migration up/down, Prolog, non-régression; toutefois INV-277-05 (immutabilité) et INV-277-06 (preuve infra) ne sont pas suffisamment verrouillés opérationnellement.
- Risk mitigation : le plan identifie correctement les risques (concurrence, perf JSONB, legacy, scope nonce), mais certaines mitigations restent déclaratives (pas entièrement transformées en mécanismes vérifiables).
- Coherence plan ↔ contracts :
- ECT-v2-03 (frontière API) : amélioration nette, mais ambiguïté résiduelle tant que le transport du nonce n’est pas démontré.
- ECT-v2-05 : corrigé.
- ECT-v2-01 : partiellement résolu; justification technique crédible, mais contradiction normative persistante avec la spec v2 non amendée.
4. Verdict de la revue¶
VERDICT: RESERVE
Le plan v3 est solide sur l’architecture et la couverture de test, mais il reste des ambiguïtés majeures de conformité/contrat (nonce serveur, interface nonce, DDL DEFAULT '', immutabilité exhaustive) qui empêchent un GO net en Gate 5 AMBIGUITY.
Pour passer en GO, il faut au minimum: 1. Aligner explicitement la règle de génération nonce (serveur uniquement) dans plan + contracts + tests. 2. Prouver le chemin d’entrée du nonce sans changement d’API, ou tracer la modification contractuelle API si nécessaire. 3. Lever l’ambiguïté normative sur DEFAULT '' (amendement spec ou stratégie migration 2 phases). 4. Durcir l’immutabilité certificats en garde explicite “toute tentative de modification => rejet fail-closed”. 5. Ajouter l’artefact probatoire INV-277-06 au plan de livraison.