Confrontation Gate 3 — PD-30¶
Écarts BLOQUANTS¶
[ECT-01] Branche JUDICIAL_REQUEST sans comportement par défaut¶
Verdict : ACCEPTÉ Analyse : Le point est valide et déjà identifié comme bloquant via Q-30-02. Sans portée explicite, la commande JUDICIAL_REQUEST crée une ambiguïté contractuelle réelle (risque d'implémentations divergentes : no-op, erreur, ou révocation trop large). Action : Fermer Q-30-02 avec une règle normative unique (recommandation architecturale : absence de scope => REVOKE_ALL utilisateur + journalisation motif JUDICIAL_DEFAULT_SCOPE), puis aligner FN-30-07, INV-30-11, ECT-30-xx et TC-30-009 (cas avec et sans scope).
[ECT-02] Liste canonique des opérations sensibles non définie¶
Verdict : ACCEPTÉ Analyse : Le reviewer a raison. INV-30-15 est testable sur le mécanisme, mais pas vérifiable contractuellement sur le périmètre sans liste canonique. Q-30-04 ouverte confirme ce manque. Action : Ajouter une table normative "Sensitive Session Operations" (versionnée) dans la spec, référencée par INV-30-15, puis mettre à jour TC-30-012/013 avec assertions par opération (inclusion/exclusion).
[ECT-03] Valeurs TTL par contexte non définies¶
Verdict : ACCEPTÉ Analyse : Exact. Le cahier valide actuellement des propriétés structurelles (positif, distinct), pas la conformité métier/sécurité. Q-30-01 étant bloquante, le test ne peut pas conclure sur l'adéquation des TTL. Action : Fixer les 4 TTL via décision PO/Sec, les inscrire en constantes contractuelles dans la spec, et enrichir TC-30-005 avec assertions de valeur absolue (+ tolérance éventuelle d'horloge).
Écarts MAJEURS¶
[ECT-04] TC-30-014 ne couvre pas FALLBACK_ON/FALLBACK_OFF¶
Verdict : PARTIELLEMENT ACCEPTÉ Analyse : Le déficit est réel dans TC-30-014, mais la couverture fonctionnelle existe partiellement via TC-30-016. L'écart porte surtout sur la centralisation des exigences de format append-only pour ces deux événements. Action : Soit (a) étendre TC-30-014 aux 8 types, soit (b) ajouter une référence croisée explicite vers TC-30-016 et y imposer les mêmes assertions de format (timestamp UTC ms, acteur, motif, immutabilité).
[ECT-05] Absence de matrice ST→TC¶
Verdict : PARTIELLEMENT ACCEPTÉ Analyse : C'est un manque d'auditabilité documentaire, pas une absence de couverture réelle (déjà démontrée par matrices INV→TC et CA→TC). Action : Ajouter une matrice ST→TC en annexe (traçabilité documentaire), sans requalifier la conformité de fond.
[ECT-06] Politique de rétention des événements non définie¶
Verdict : PARTIELLEMENT ACCEPTÉ Analyse : Le risque est légitime, mais la critique mélange contrat PD-30 et gouvernance transverse (Legal/RGPD). Le sujet est ouvert (Q-30-03), donc connu et non occulté. Action : Ajouter une clause explicite "out-of-scope PD-30 / dépendance politique RGPD", avec exigence minimale transitoire (pas de purge ad hoc, purge uniquement par politique versionnée), et créer un test d'intégration dès que la politique est publiée.
[ECT-07] Contrat d'interface avec l'ancrage probatoire absent¶
Verdict : PARTIELLEMENT ACCEPTÉ Analyse : Point pertinent sur la chaîne probatoire de bout en bout, mais non-bloquant pour PD-30 seul si la dépendance PD-31 est explicitée. L'écart est d'interface inter-story, pas de logique cœur PD-30. Action : Formaliser un "interface placeholder contract" (schéma payload, garanties de livraison, codes d'erreur, idempotence), puis planifier tests contractuels croisés PD-30/PD-31.
[ECT-08] "Acteur légitime" non défini contractuellement¶
Verdict : ACCEPTÉ Analyse : Valide. Les tests "acteur non autorisé" restent sous-spécifiés sans matrice de rôles/permissions, ce qui peut produire des implémentations incompatibles. Action : Introduire une matrice RBAC minimale (acteur, action, condition, résultat), référencer FN-30-05/06, ECT-30-07, TC-30-019.
Écarts MINEURS¶
[ECT-09] Terme "rejet de sécurité" non défini¶
Verdict : ACCEPTÉ Analyse : Juste. Le terme est compréhensible mais non contractuel en l'état. Action : Définir le terme en section 3 ou le remplacer par une référence explicite aux erreurs ECT-30-xx concernées.
[ECT-10] Absence de test négatif pour l'unicité de session à la création¶
Verdict : PARTIELLEMENT ACCEPTÉ Analyse : La critique améliore la robustesse mais dépasse partiellement l'invariant tel qu'écrit (une session par authentification réussie). Le cas de double appel/race mérite un test non-régression même si ce n'est pas le cœur du contrat actuel. Action : Ajouter un TC de concurrence (double création quasi-simultanée) avec résultat attendu explicite (idempotence ou rejet déterministe selon contrat retenu).
[ECT-11] Staleness "2 secondes" non justifiée¶
Verdict : CONTESTÉ Analyse : Le seuil est issu des learnings PD-239 (latence bornée) et sert de garde-fou opérationnel, pas de valeur arbitraire. La justification existe mais n'a pas été recopiée dans la section concernée. Action : Ajouter la référence explicite à PD-239 et au rationnel SLO dans la spec pour lever l'ambiguïté documentaire.
[ECT-12] TC-30-002 : seuil de 100 000 sessions¶
Verdict : CONTESTÉ Analyse : Le reviewer évalue ce test comme preuve statistique de collision, alors qu'il est conçu comme test de non-régression d'implémentation. La preuve de collision relève du design de l'espace d'identifiants (ex. UUID/entropy), pas d'un test de charge unitaire. Action : Clarifier l'objectif du TC (sanity/non-régression) et ajouter une note de conception sur la garantie de cardinalité/entropie du sessionId.
[ECT-13] Absence de test pour FALLBACK_OFF (retour nominal) détaillé¶
Verdict : ACCEPTÉ Analyse : Valide. L'action est mentionnée mais les critères d'acceptation du retour nominal ne sont pas assez explicites (resync, cohérence post-reprise). Action : Compléter TC-30-016 avec assertions de sortie de fallback : émission FALLBACK_OFF, resynchronisation, absence de divergence d'état, reprise du chemin nominal.
Synthèse¶
- Écarts BLOQUANTS acceptés : 3/3
- Écarts MAJEURS acceptés : 5/5 (dont 1 ACCEPTÉ, 4 PARTIELLEMENT ACCEPTÉS)
- Écarts MINEURS acceptés : ⅗ (dont 2 ACCEPTÉS, 1 PARTIELLEMENT ACCEPTÉ)
- Recommandation finale : RESERVE
Les trois bloquants sont confirmés et doivent être fermés avant GO. Le reste est majoritairement de cadrage contractuel/traçabilité, traitable sans remettre en cause l'architecture PD-30 de fond.
Confrontation produite par ChatGPT (gpt-5.3-codex) — Gate 3 Phase 2 Date : 2026-02-18