Review Plan — PD-31¶

1. Analyse de faisabilité¶

Le plan est globalement réaliste sur le plan technique (modules clairs, séquence par phases logique, buffer explicite).

Points positifs: - Découpage en 6 phases cohérent pour limiter le risque d'intégration tardive. - Architecture modulaire adaptée (audit, alerting, API, intégration auth). - Buffer de 3.5 jours (~19%) raisonnable pour ce type de story.

Points de vigilance: - 21.5 jours paraît crédible seulement si les prérequis infra (HSM, Redis, schéma DB, observabilité) sont déjà stabilisés. - Les décisions QO (notamment HSM partagé et PARTIAL_PROOF) peuvent générer des coûts de validation supplémentaires non explicitement provisionnés. - La phase tests (3j) semble tendue vu les enjeux intégrité/performance/concurrence.

2. Analyse de couverture¶

Couverture structurelle correcte (interfaces, services, controllers, processor/listener), mais couverture fonctionnelle non démontrable complètement avec les seuls résumés fournis.

Constats: - Les modules couvrent bien les domaines attendus (piste d'audit, alerting, exposition API). - Les contracts (CC-31-01..70) donnent une profondeur technique suffisante. - Gap de traçabilité: absence de matrice explicite F-31-01..08 -> module/service/controller. - Gap de traçabilité: absence de mapping explicite CA -> code contract dans les éléments fournis.

3. Analyse des risques¶

Risques identifiés pertinents et techniques (perf insertion, concurrence hash chaîné, Redis sliding window, rétention 3 ans, intégrité export).

Risques manquants ou sous-traités: - Risque de sécurité/isolement de clé HSM partagée (QO-31-03). - Risque de dérive de cache Redis vs source de vérité PostgreSQL. - Risque légal/compliance (rétention, purge, right-to-erasure si applicable). - Risque d'exploitation (monitoring, SLO, capacité, backfill/reprocessing).

4. Analyse de cohérence¶

Cohérence globale correcte entre architecture plan et granularité des contracts.

Incohérences/ambiguïtés: - QO-31-02 (PARTIAL_PROOF autorisé) peut entrer en tension avec des invariants d'intégrité. - QO-31-03 (clé HSM existante) nécessite des garanties contractuelles explicites. - Le chaînage entre entities/services/controllers et les CA n'est pas explicite.

5. Écarts détectés¶

ECT-31-01 : Absence de matrice de traçabilité F -> Contracts¶

• Type : ECT
• Sévérité : MAJEUR
• Description : Le dossier ne montre pas explicitement la couverture de F-31-01..08 par module/service/controller.
• Recommandation : Ajouter une matrice obligatoire Feature -> Module -> Service -> Endpoint -> Tests.

AMB-31-02 : Traçabilité CA insuffisante¶

• Type : AMB
• Sévérité : MAJEUR
• Description : Impossible de vérifier que chaque critère d'acceptation est ancré dans au moins un code contract.
• Recommandation : Ajouter un tableau CA -> CC-ID -> Invariant -> Test.

DIV-31-03 : PARTIAL_PROOF non cadré¶

• Type : DIV
• Sévérité : MAJEUR
• Description : Autoriser PARTIAL_PROOF sans bornes explicites risque de divergence avec les exigences d'intégrité.
• Recommandation : Formaliser les cas autorisés/interdits, impact métier, et mécanisme de remédiation.

SEC-31-04 : Clé HSM partagée sans garanties formelles¶

• Type : ECT
• Sévérité : MAJEUR
• Description : QO-31-03 introduit un risque de sécurité/compliance si la ségrégation des usages n'est pas contractualisée.
• Recommandation : Ajouter des exigences de scope, rotation, audit trail et contrôle d'accès dans les contracts.

PERF-31-05 : Budget performance non chiffré¶

• Type : PERF
• Sévérité : MINEUR
• Description : Les risques perf sont identifiés mais sans SLO/chiffres cibles.
• Recommandation : Définir des objectifs mesurables + plan de charge + seuils d'alerte.

6. Scoring¶

7. Verdict préliminaire¶

RESERVE

Review générée par ChatGPT (gpt-5.3-codex) dans le cadre du workflow de gouvernance ProbatioVault.