Review Gate 5 — PD-30¶
1. Scores¶
| Critère | Score | Justification |
|---|---|---|
| feasibility | 7/10 | Le découpage est globalement implémentable (NestJS + Redis + patterns existants), mais plusieurs comportements critiques restent sous-spécifiés (fallback du rate limit, stratégie de resync Redis↔memory, mesure SLA en CI). |
| coverage | 8/10 | La matrice INV/CA → tâches couvre formellement 19 INV et 16 CA, mais la traçabilité vers des tests précis est insuffisante (pas de mapping INV/CA → TC explicite, assertions clés non détaillées). |
| risk_mitigation | 6/10 | Les risques principaux sont identifiés, mais les mitigations restent génériques et peu opérables (pas de critères de bascule/reprise, pas de stratégie de conflit/idempotence, pas de garde-fous observabilité). |
| coherence | 6/10 | Le macro-séquencement est logique, mais des dépendances fonctionnelles sont incomplètes (audit dépend en pratique de T3/T5, contraintes mode dégradé réparties sans contrat inter-couches clair). |
2. Points positifs¶
- Bonne structuration en 8 tâches avec responsabilités lisibles et périmètre technique crédible.
- Mapping INV/CA vers tâches complet au niveau plan, avec référence explicite des fichiers.
- Prise en compte explicite des exigences non-fonctionnelles sensibles (latence p95/p99, fallback, append-only audit).
- Séquencement global pertinent (socle domaine/config/store avant interfaces et tests intégrés).
- Intégration avec dépendances amont déjà livrées (PD-28/31/238/240), ce qui réduit le risque d'architecture.
3. Écarts identifiés¶
BLOQUANTS¶
- Aucun bloquant formel détecté à ce stade (aucun INV/CA explicitement non couvert dans la matrice).
MAJEURS¶
- [ECT-01] Traçabilité tests incomplète : TASK-8 annonce "19 TC couverts" sans matrice explicite INV/CA → cas de test → fichier/test id; risque de faux positif de couverture contractuelle.
- [ECT-02] Mode dégradé du rate limiting non défini : TASK-6 repose sur Redis sorted sets, mais le comportement attendu si Redis est indisponible (fail-open/fail-closed/quota local) n'est pas spécifié.
- [ECT-03] Mitigation "fallback → Redis sync" trop vague : absence de stratégie de reprise (ordre des événements, idempotence, déduplication, conflit temporel), alors que le risque de perte/incohérence est explicitement listé.
- [ECT-04] Dépendances audit sous-estimées : TASK-7 dépend officiellement de TASK-1, mais journalise des événements produits par TASK-3/TASK-5 (FALLBACK_, REVOKE_); risque d'écart d'implémentation et de trous d'audit.
- [ECT-05] SLA invalidation non opérationnalisé : "pub/sub + tests de charge" est insuffisant sans protocole de mesure (fenêtre, volumétrie, environnement, seuil d'acceptation stable CI).
MINEURS¶
- [ECT-06] Staleness <= 2s peu détaillé : le mécanisme concret garantissant CA-30-07 (cache/read model/polling/consistency model) n'est pas explicité.
- [ECT-07] Memory store TTL via
setTimeout: risque de scalabilité/memory pressure si cardinalité élevée; manque de précision sur stratégie de cleanup batchée. - [ECT-08] Validation startup config : pas de détail sur bornes minimales/maximales ni comportement en cas de configuration partielle/invalide.
4. Recommandation¶
RESERVE — Le plan est globalement solide et faisable, avec une couverture contractuelle correcte sur le papier, mais il manque des précisions majeures pour sécuriser l'exécution (traçabilité tests, comportement en mode dégradé pour rate limiting, stratégie de resynchronisation et dépendances d'audit). La levée des écarts MAJEURS ci-dessus est recommandée avant démarrage implementation pour éviter des non-conformités tardives.