Review Gate 3 — PD-30¶

1. Scores¶

2. Points positifs¶

• Rigueur structurelle exemplaire : la spec couvre systématiquement invariants, flux nominaux, cas d'erreur, critères d'acceptation et scénarios de test avec un nommage cohérent et traçable.
• Transparence sur les limites : les hypothèses (H-30-01 à H-30-05), les points à clarifier (Q-30-01 à Q-30-05) et le périmètre hors-scope (HP-30-01/02) sont explicitement identifiés plutôt que masqués.
• Sécurité intégrée dès la conception : comparaison timing-safe (INV-30-14), zero-knowledge sur les secrets (INV-30-17), rate limiting dual scope (INV-30-15), isolation inter-utilisateur (INV-30-08).
• Mode dégradé contractualisé : le comportement en fallback est non seulement prévu mais borné (INV-30-18/19), avec rejet explicite des opérations globales pour éviter un faux sentiment de cohérence — choix d'architecture mature.
• Cahier de tests complet et automatisable : 19 TC couvrant 19 INV et 16 CA, tous marqués automatisables, avec préconditions et oracles déterministes.
• Couverture explicite des cas d'erreur : les 7 ECT sont tous couverts par au moins un TC.

3. Écarts identifiés¶

BLOQUANTS¶

• [ECT-01] — Branche JUDICIAL_REQUEST sans comportement par défaut défini. INV-30-11 et FN-30-07 stipulent "REVOKE_ALL utilisateur ou portée précisée par la requête judiciaire" mais ne définissent pas le comportement lorsque la portée n'est pas fournie. Le test TC-30-009 utilise JUDICIAL_REQUEST(scope explicite) mais ne teste pas le cas sans scope. Cela rend cette branche contractuellement ambiguë et potentiellement exploitable (une requête judiciaire sans scope pourrait être silencieusement ignorée ou provoquer un comportement indéfini). Référence : Q-30-02 le confirme comme bloquant.

• [ECT-02] — Liste canonique des opérations sensibles non définie. INV-30-15 impose un rate limiting sur les "endpoints sensibles session" et la section 3 les définit comme "opérations de révocation et de consultation exhaustive", mais Q-30-04 confirme que la liste canonique exacte n'est pas établie. Sans cette liste, l'implémentation du rate limiting est spéculative : des opérations sensibles pourraient ne pas être protégées, ou des opérations non sensibles pourraient être indûment limitées. Les tests TC-30-012/013 vérifient le mécanisme mais sur un "endpoint sensible" non spécifié contractuellement.

• [ECT-03] — Valeurs TTL par contexte non définies. Q-30-01 est identifié comme "bloquant pour finaliser les tests de valeur absolue". TC-30-005 vérifie que les 4 TTL sont distincts et positifs, mais ne peut pas vérifier la conformité aux valeurs attendues puisqu'elles n'existent pas. Cela signifie qu'un TTL SENSITIVE de 24h passerait le test, ce qui serait une faille de sécurité. La spec elle-même reconnaît ce manque.

MAJEURS¶

• [ECT-04] — TC-30-014 ne couvre pas explicitement FALLBACK_ON/FALLBACK_OFF dans sa séquence. INV-30-16 liste 8 types d'événements à journaliser : CREATE, REFRESH, REVOKE_SESSION, REVOKE_DEVICE, REVOKE_ALL, EXPIRE, FALLBACK_ON, FALLBACK_OFF. Le TC-30-014 ne teste que 6 d'entre eux dans sa séquence. Les événements FALLBACK_ON/FALLBACK_OFF sont testés par TC-30-016, mais la vérification de conformité du format append-only (timestamp UTC ms, acteur, motif) pour ces deux types n'est pas explicitement couverte par TC-30-014.

• [ECT-05] — Absence de matrice ST→TC. Les 13 scénarios de test (ST-30-01 à ST-30-13) de la spécification ne sont pas formellement mappés aux 19 cas de test (TC-30-001 à TC-30-019) du cahier. La correspondance est intuitive (ST-30-01 ↔ TC-30-001, etc.) mais non contractualisée. Cela rend la vérification de couverture entre la spécification et le cahier de tests non auditable de manière formelle.

• [ECT-06] — Politique de rétention des événements non définie (Q-30-03). INV-30-16 impose une journalisation append-only mais aucune règle de rétention/purge n'est définie. Cela rend la conformité RGPD indémontrable pour les données de session contenant des ipHash et des localisations. TC-30-014 vérifie l'immutabilité mais ne peut pas tester la purge conforme.

• [ECT-07] — Contrat d'interface avec l'ancrage probatoire absent (Q-30-05/HP-30-02). La spec mentionne un ancrage probatoire (PD-31) mais sans contrat d'interface technique. Les tests vérifient la journalisation locale mais ne peuvent pas garantir que les événements sont effectivement ancrés. Cela fragilise la valeur probatoire de toute la chaîne.

• [ECT-08] — "Acteur légitime" non défini contractuellement. FN-30-05 et FN-30-06 mentionnent un "acteur légitime (utilisateur ou système)" sans définition des rôles/permissions. ECT-30-07 et TC-30-019 testent le rejet d'un "acteur non autorisé" mais sans matrice de permissions documentée, le test est sous-spécifié.

MINEURS¶

• [ECT-09] — Terme "rejet de sécurité" non défini. La définition d'"activité continue" exclut les requêtes "soumises à rate limit/rejet de sécurité", mais "rejet de sécurité" n'est pas un terme défini dans la section 3. Recommandation : ajouter une définition ou remplacer par une référence aux cas d'erreur ECT-30-XX concernés.

• [ECT-10] — Absence de test négatif pour l'unicité de session à la création. INV-30-01 stipule "exactement une session" par authentification réussie. TC-30-001 vérifie qu'une session est créée, mais ne teste pas explicitement le cas de double appel (idempotence ou rejet du second appel). Le scénario de race condition (deux créations quasi-simultanées pour la même authentification) n'est pas couvert.

• [ECT-11] — Staleness "2 secondes" de CA-30-07 sans justification. Le seuil de fraîcheur de 2 secondes pour la consultation des appareils (FN-30-04) n'est pas justifié. Est-ce un compromis technique ou une exigence fonctionnelle ? Ce seuil mériterait une justification ou une référence à un besoin métier.

• [ECT-12] — TC-30-002 : seuil de 100 000 sessions. Le test d'unicité du sessionId utilise N >= 100 000 sans justification du seuil. Pour un système en production, ce volume pourrait être insuffisant pour détecter des collisions sur un espace d'identifiants donné. Recommandation : documenter la taille de l'espace de sessionId et justifier le seuil de test en conséquence.

• [ECT-13] — Absence de test pour FALLBACK_OFF (retour au mode nominal). TC-30-016 mentionne "restaurer store central et vérifier FALLBACK_OFF" dans ses actions, mais le résultat attendu ne détaille pas les critères de succès du retour au mode nominal (resynchronisation des sessions fallback, cohérence post-reprise, etc.).

4. Recommandation¶

RESERVE

Justification : La spécification et le cahier de tests présentent un niveau de maturité élevé avec une couverture structurelle complète (19/19 INV, 16/16 CA, 19 TC automatisables). Cependant, trois écarts bloquants empêchent un verdict GO :

1. Le comportement par défaut de JUDICIAL_REQUEST sans portée explicite doit être contractualisé avant implémentation (ECT-01).
2. La liste canonique des opérations sensibles soumises au rate limiting doit être établie pour que INV-30-15 soit implémentable et testable sans ambiguïté (ECT-02).
3. Les valeurs TTL par contexte doivent être définies pour que TC-30-005 puisse valider la conformité fonctionnelle et non seulement structurelle (ECT-03).

Conditions de levée de réserve : - Résoudre Q-30-02 (portée JUDICIAL_REQUEST par défaut) et mettre à jour INV-30-11, FN-30-07 et TC-30-009. - Résoudre Q-30-04 (liste des opérations sensibles) et mettre à jour INV-30-15 et les préconditions de TC-30-012/013. - Résoudre Q-30-01 (valeurs TTL) et ajouter des assertions de valeur absolue dans TC-30-005. - Traiter les écarts majeurs ECT-04 à ECT-08 avant validation finale.

Review produite par Claude (subprocess) — Gate 3 Phase 1 Date : 2026-02-18