| Non-conformité Spec | Spec §5.9 (reasonCode PV_TSA_CRITICAL_ALERT) / Plan DA-02 | Le plan introduit des reasonCode CRITICAL non contractuels (KEY_RETIRED_SLA_BREACH, KEY_ARCHIVED_SLA_BREACH) non listés dans l’enum §5.9. | Événements d’audit CRITICAL potentiellement non conformes (validation contractuelle / audit tiers KO). | BLOQUANT |
| Couverture manquante | Spec §5.5 + §5.3 (SLA post-rotation “ne peut pas durer au-delà”) / Plan DA-02 + C7 | Le plan “enforce” les SLA post-rotation par alerte, mais ne démontre pas un mécanisme rendant l’état “impossible au-delà” (contrainte bloquante) tel que formulé dans la spec. | Non-conformité possible au libellé contractuel ; difficulté de prouver l’empêchement effectif en audit. | MAJEUR |
| Non-conformité Spec | Spec §5.2 (ntsReferenceServers) + INV-265-01 / Plan DA-01 + C4 | La spec ne spécifie pas la logique d’agrégation multi-serveurs NTS ; le plan fixe une règle “worst-case ANY KO/offset>seuil => NTS” et impose le clearing “2 cycles OK sur TOUS les serveurs”. | Comportement ajouté/non spécifié : deux implémentations pourraient diverger tout en restant “compatibles” avec le texte ; risque de non-conformité contractuelle “aucun comportement non spécifié introduit”. | MAJEUR |
| Hypothèse implicite | Spec §5.4 (contrat de refus API) / Plan C9 + F6 | Le plan fixe un statut HTTP 503 pour le refus d’émission TST alors que la spec ne contractualise pas le code HTTP (seulement le contenu : refusalReasonCode + tsaServiceState + tsaServiceDegradationFlags, et “sans effet partiel”). | Risque de divergence avec consommateurs/contrats externes si un statut HTTP est attendu différemment ; ajout de règle non spécifiée. | MINEUR |
| Risque sécu/conformité | Spec INV-265-11 + TC-ERR-12 / Plan C2 (colonne state) + C3 | Le plan persiste tsaServiceState en DB alors que la spec le définit comme “vue dérivée” des flags ; même si C3 interdit l’écriture directe, l’existence d’un champ stocké augmente la surface de contournement (écritures directes DB, incohérence state/flags). | Risque de rupture du “state dérivé uniquement”, et de contournement des interdictions de transitions (auditabilité / invariants). | MAJEUR |
| Couverture manquante | Tests TC-ERR-14 + Spec §5.9 (canal “notification exploitation via canal contractuel”) / Plan C13 | Le plan mentionne “notification exploitation” mais ne fournit pas de point d’observabilité explicite permettant d’attester (en test) que la notification “canal contractuel” a bien eu lieu (au-delà de métriques + événement). | TC-ERR-14 peut être partiellement non démontrable sur la partie “notification exploitation” ; preuve d’exécution affaiblie. | MAJEUR |
| Non-conformité Spec | Spec §5.1 (tsaServiceDegradationFlags rejet doublons/inconnu + tri) / Plan C3 + §9 V-09 | Le plan indique que les flags sont un Set interne et “pas d’entrée externe”, ce qui évite une partie des cas, mais n’explicite pas de mécanisme de rejet contractuel (doublons / élément inconnu / tri) au niveau des interfaces qui exposent/acceptent ces données. | Contrat de format potentiellement non prouvable si une interface externe/internal tooling peut fournir des flags ; risque de dérivation corrompue. | MINEUR |
| Contrainte technique non documentée | Plan (absence section “Contraintes techniques”) | Le plan ne contient pas de section “Contraintes techniques” listant les dépendances inter-PD avec statut (DONE/TODO/STUB acceptable). | Risque de dépendances implicites non maîtrisées ; audit de traçabilité affaibli. | MINEUR |
| Contrainte technique non documentée | Plan (absence section “Contraintes techniques”) | Le plan ne choisit pas explicitement le framework de test (Jest ou Vitest). | Ambiguïté runner/tests ; risque d’écarts d’outillage CI. | MAJEUR |
| Contrainte technique non documentée | Plan (absence section “Contraintes techniques”) | Le plan ne documente pas la compatibilité ESM/CJS (dépendances ESM-only éventuelles) ni l’adaptation du runner. | Risque CI “tests impossibles à exécuter” selon dépendances ; défaut de testabilité contractuelle. | MAJEUR |
| Contrainte technique non documentée | Plan (absence section “Contraintes techniques”) | Le plan ne documente pas les variables CI attendues pour les tests d’intégration (ex: DATABASE_URL, CI=true, etc.) malgré un scope “PostgreSQL réel” en intégration/E2E. | Risque d’exécution CI non reproductible ; non-testabilité pratique. | MINEUR |
| Code Contract — Frontière | Code contracts CC-265-02 / CC-265-07 | Chevauchement de périmètre fichiers : src/modules/tsa/entities/tsa-key-lifecycle-metadata.entity.ts apparaît dans plusieurs modules de contrat (entities et lifecycle). | Frontières d’ownership non disjointes ; risque de conflits d’implémentation multi-agents / audit de responsabilité. | MAJEUR |
| Code Contract — Invariant | Règle axe 6 (“invariants code contract ⊆ invariants spec”) / CC-265-04 (DA-01) + autres | Plusieurs invariants de code contracts incluent des décisions/contraintes non présentes dans les invariants de la spec (ex: DA-01 “worst-case” explicitement comme invariant). | Non-respect de la contrainte de sous-ensemble ; risque de contract “code” plus fort que le contract “spec”. | MAJEUR |