PD-84-specification-review.md¶

Type : Ambiguïté
Référence : Spec section 2.3, section 3.3, section 7.3 (message utilisateur)
Description : La spec v1.1.0 ajoute en section 2.3 : "En plan PREMIUM, les quotas de dossiers actifs et de documents par dossier sont levés (pas de limite supérieure appliquée par PD-84)". La section 3.3 confirme : "aucune borne supérieure de cardinalité n'est appliquée par PD-84". Cependant, aucune règle fonctionnelle F-84-XX ne formalise explicitement le comportement PREMIUM (pas de F-84-XX "le système DOIT autoriser un utilisateur PREMIUM à créer un nombre illimité de dossiers actifs"). Le comportement se déduit des clarifications et contraintes de cardinalité, mais n'est pas exprimé comme exigence fonctionnelle testable.
Impact : Un implémenteur lisant uniquement les F-84-XX pourrait manquer le comportement PREMIUM. Le message "dossiers illimités" (section 7.3) concerne les dossiers mais pas explicitement les documents. La clarification structurelle (section 2.3) dit "quotas levés" ce qui couvre les deux, mais sans F-84-XX associée.
Gravité : Mineur

Type : Ambiguïté
Référence : Spec section 4, F-84-12
Description : L'exigence F-84-12 stipule que "l'utilisateur DOIT pouvoir démontrer visuellement l'existence et le contenu de ses dossiers depuis l'application". Aucun critère objectif n'est fourni : pas de format de rendu, pas de niveau de détail, pas de distinction fonctionnelle avec F-84-11 (consulter ses preuves). Aucun CA-84-XX ne couvre spécifiquement cette exigence. Aucun test ne l'adresse.
Impact : Exigence fonctionnelle orpheline. Non différenciable de F-84-11.
Gravité : Mineur

Type : Ambiguïté
Référence : Spec section 3.1 (ProbatoryFolder.closed_reason), endpoint POST /folders/{folderId}/close
Description : Le champ closed_reason est défini comme nullable dans le modèle de données mais aucune règle fonctionnelle ne spécifie quand il est renseigné, quelles valeurs sont possibles, ni s'il provient de l'utilisateur ou du système. L'endpoint de clôture ne le mentionne pas en entrée. Aucun test ne vérifie sa valeur.
Impact : Champ orphelin dans le schéma. L'implémentation peut l'ignorer ou l'inventer sans contrainte.
Gravité : Mineur

Type : Ambiguïté
Référence : Spec section 3.1 (UserAccount.account_role), INV-84-09, INV-84-10
Description : Le champ account_role (MINOR, LEGAL_GUARDIAN, OTHER) est présent dans le modèle de données. INV-84-09 stipule que le plan est universel sans distinction d'âge. Aucune règle F-84-XX ne conditionne un comportement au account_role. TC-15 confirme l'absence de branchement par rôle.
Impact : Cohérent avec le périmètre PD-84 (le rôle est sans doute exploité par d'autres stories de l'epic PD-185). Clarification de modélisation suffisante; pas de risque d'implémentation.
Gravité : Mineur

Type : Ambiguïté
Référence : Spec section 9.1 dernier point
Description : La spec note : "Le besoin ne précise pas si ce SLA est paramétrable runtime". Ce point reste ouvert en v1.1.0. Le seuil p95 < 5s est fixe dans la spec mais la question de sa configurabilité n'est pas tranchée.
Impact : Faible pour PD-84. Si le SLA doit être ajustable, l'architecture de configuration doit le prévoir. Si non, le point est clos.
Gravité : Mineur

Type : Contradiction
Référence : Spec CA-84-08 (révisé) vs section 7.1 (endpoints)
Description : CA-84-08 mentionne que "les opérations de modification/suppression de documents individuels ne sont pas exposées par les endpoints PD-84; elles sont implicitement bloquées par l'absence d'API". Or le CA parle initialement d'un dossier CLOSED_READ_ONLY avec "ajout de document refusé" et "export complet verrouillé". La note de périmètre est une clarification bienvenue, mais le CA lui-même ne teste que des comportements sur dossier clôturé FREE, pas l'absence d'endpoints modification/suppression. La formulation reste ambiguë entre "comportement testé" et "comportement implicitement assuré par absence d'API".
Impact : Mineur car la note de périmètre lève l'ambiguïté pratique. Le cahier de tests (TC-08, TC-12) couvre correctement le périmètre API réel.
Gravité : Mineur

Type : Contradiction (spec étend le besoin)
Référence : Spec section 5 (INV-84-12 à INV-84-15) vs expression de besoin
Description : Les invariants INV-84-12 (chiffrement), INV-84-13 (UX adolescent), INV-84-14 (pas d'export gratuit), INV-84-15 (traçabilité) n'ont pas de correspondance directe dans l'expression de besoin. Ils sont pertinents pour l'epic PD-185 mais ont été ajoutés par le rédacteur de la spec.
Impact : Risque de sur-spécification. INV-84-14 et INV-84-15 sont des renforcements légitimes. INV-84-12 relève de PD-60/PD-79. INV-84-13 introduit une exigence UX non mesurable (cf. NT-v2-01).
Gravité : Mineur

Type : Non testable
Référence : Spec INV-84-13, CA-84-14 / Tests section 6
Description : L'invariant exige un "parcours compréhensible pour un adolescent" et renvoie à une "mesure UX explicitée en CA". CA-84-14 définit "0 erreur bloquante sur scénario nominal" — ce qui mesure la fluidité technique, pas la compréhension. Aucun questionnaire SUS, indice de lisibilité ou taux de compréhension n'est défini. Le cahier de tests le reconnaît en section 6.
Impact : L'invariant est indémontrable objectivement. Le test TC-14 couvre le flux nominal sans erreur mais pas la compréhensibilité adolescente. Reconnu comme partiel par le cahier de tests.
Gravité : Majeur

Type : Non testable
Référence : Spec INV-84-12, SEC-84-04 / Tests TC-SEC-03, section 6
Description : "Le contenu des preuves reste chiffré et inaccessible à la plateforme". TC-SEC-03 vérifie que les API n'exposent pas de contenu en clair. Mais la couverture "inaccessible à la plateforme" (côté infra/backoffice) nécessite un protocole d'audit infra absent de la spécification PD-84. Le cahier de tests reconnaît cette limitation.
Impact : Couverture API uniquement. L'invariant relève largement de PD-60/PD-79 et de l'architecture cryptographique transverse. La couverture partielle dans PD-84 est acceptable si l'invariant est vérifié au niveau de l'epic.
Gravité : Mineur

Type : Non testable
Référence : Spec CA-84-14, Tests section 6
Description : CA-84-14 exige "sans vocabulaire ambigu". Le cahier de tests reconnaît l'absence de glossaire ou règle sémantique formelle. Le critère "0 erreur bloquante" est mesurable mais ne couvre pas la dimension linguistique.
Impact : L'aspect "vocabulaire" est subjectif. Le test TC-14 couvre la dimension fonctionnelle (aucune erreur bloquante).
Gravité : Mineur

Type : Incohérence Spec↔Tests
Référence : Tests TC-11 résultat attendu vs Spec 8.3
Description : TC-11 v1.1.0 compare "algorithme de hash, format d'horodatage, mécanisme d'ancrage" et attend des attributs "strictement identiques". La spec 8.3 confirme l'équivalence algorithmique. Cependant, le scellement est géré par PD-60/PD-79. Pour que TC-11 soit exécutable, il faut que les métadonnées de scellement (algorithme, format horodatage, type d'ancrage) soient exposées par les API de documents. Les endpoints PD-84 (section 7.1) ne spécifient pas les champs retournés par POST /folders/{folderId}/documents ni GET /folders/{folderId}. Le modèle SealedDocument (section 3.1) liste probatory_seal_ref, integrity_state, anchoring_state — mais pas l'algorithme de hash ni le format d'horodatage.
Impact : TC-11 nécessite des champs qui ne sont pas explicitement dans le contrat de réponse API PD-84. L'implémenteur doit inférer qu'ils proviennent de PD-60/PD-79.
Gravité : Mineur

Type : Incohérence Spec↔Tests
Référence : Tests section 2 (matrice ECT-06) vs section 3 (scénarios)
Description : La matrice de couverture des ajouts v1.1.0 indique "ECT-06 -> TC-14-bis (CapabilityState calculé)". Mais TC-14-bis n'est pas défini dans la section 3 des scénarios de test. Aucune description, préconditions, actions ou résultat attendu.
Impact : Test manquant dans le cahier. La couverture ECT-06 (CapabilityState comme vue calculée) n'est pas objectivement vérifiable.
Gravité : Majeur

Type : Incohérence Spec↔Tests
Référence : Tests section 2 (matrice CA-84-12) vs section 3 (scénarios)
Description : La matrice de couverture des CA indique "CA-84-12 -> TC-12-bis". Mais TC-12-bis n'est pas défini dans la section 3. TC-12 couvre l'absence de remise à zéro mensuelle, mais TC-12-bis (potentiel approfondissement) n'existe pas.
Impact : Test fantôme dans la matrice. CA-84-12 est couvert par TC-12 existant, mais la référence TC-12-bis est trompeuse.
Gravité : Mineur

Type : Incohérence Spec↔Tests
Référence : Tests TC-06 vs CA-84-06
Description : TC-06 manipule des éléments visuels ("contrôles d'export visibles mais désactivés", "CTA Premium visible et actionnable"). Les préconditions communes ne couvrent que les appels API. Aucune indication sur le type de test (E2E Playwright/Cypress, composant, snapshot, manuel).
Impact : Sans précision, l'automatisation de TC-06 en CI est incertaine. Un test E2E nécessite un frontend déployé.
Gravité : Mineur

Type : Incohérence Spec↔Tests
Référence : Tests matrice de couverture INV-84-05 -> TC-15
Description : La matrice indique TC-15 couvre INV-84-05 ("La montée en Premium est possible immédiatement"). Or TC-15 teste le plan universel sans distinction d'âge (comptes MINOR vs OTHER, tous en FREE). Ce test ne touche pas la transition de plan. Le mapping est erroné.
Impact : Couverture INV-84-05 surévaluée dans la matrice. INV-84-05 est couvert par TC-10, TC-SLA-01, TC-LIM-04.
Gravité : Mineur

Type : Incohérence Spec↔Tests
Référence : Tests matrice de couverture INV-84-04 -> TC-16
Description : TC-16 teste le refus de catégorie invalide (INVALID_FOLDER_CATEGORY). La matrice le mappe sur INV-84-04 ("Le nombre de dossiers actifs (3) et de documents par dossier (100) est exact, déterministe et traçable"). La validation de catégorie n'a pas de rapport avec les quotas. Le mapping devrait référencer F-84-19 plutôt qu'INV-84-04.
Impact : Mapping inexact mais sans conséquence sur la couverture réelle des quotas (INV-84-04 est amplement couvert par TC-01 à TC-04, TC-LIM-01/02).
Gravité : Mineur

Type : Hypothèse dangereuse (disponibilité)
Référence : Spec F-84-18, INV-84-15, SEC-84-03 / Tests TC-13, TC-SEC-04
Description : Les événements d'audit sont une exigence (INV-84-15). La spécification ne définit pas le comportement si le service PD-31 (audit log) est indisponible. L'opération métier (création dossier, clôture, etc.) doit-elle échouer si l'audit ne peut pas être journalisé ? Ou l'audit est-il asynchrone en best-effort ?
Impact : Si audit synchrone bloquant : l'indisponibilité PD-31 bloque toutes les opérations PD-84. Si audit asynchrone : des événements peuvent être perdus, affaiblissant INV-84-15. La spec ne tranche pas.
Gravité : Majeur

Type : Hypothèse dangereuse (horloge)
Référence : Tests TC-12, préconditions communes
Description : TC-12 "avance l'horloge de test d'un mois calendaire". Les préconditions indiquent "horloge système figée". Le test présuppose une horloge injectable. Ce n'est pas une exigence de la spec mais une contrainte d'architecture pour la testabilité.
Impact : Faible si l'architecture permet l'injection d'horloge (pattern Clock/TimeProvider). Mais si le système utilise Date.now() directement, TC-12 est non-déterministe.
Gravité : Mineur

Type : Hypothèse dangereuse (ordonnancement)
Référence : Spec section 3.2.1 effets de transition
Description : La clôture a trois effets simultanés : (1) libération de slot, (2) blocage modifications, (3) conservation preuves. L'ordre n'est pas spécifié. Si la libération de slot précède le blocage, une fenêtre de race condition existe entre la libération et la finalisation.
Impact : Mitigé par la section 3.4 (atomicité des opérations de quota), mais la clôture elle-même n'est pas explicitement couverte par la contrainte d'atomicité de 3.4 (qui ne mentionne que "création de dossier" et "ajout de document").
Gravité : Mineur

Type : Hypothèse dangereuse (mesure statistique)
Référence : Tests TC-SLA-01 action 3
Description : TC-SLA-01 demande de "Répéter N fois pour calcul p95". La valeur de N n'est pas spécifiée. Pour un p95 statistiquement significatif, il faut un minimum d'environ 100 mesures (pour que le 95e percentile soit basé sur au moins 5 échantillons). Un N trop faible rend la mesure non fiable.
Impact : Avec N=20, le p95 repose sur 1 seul échantillon. Le test pourrait passer ou échouer de manière non reproductible.
Gravité : Mineur

Type : Risque sécu/conformité
Référence : Spec section 7 (endpoints), F-84-18
Description : Aucune règle de rate limiting n'est définie. Chaque refus de quota génère un événement d'audit (F-84-18, INV-84-15). Un acteur malveillant pourrait envoyer des milliers de requêtes de création de dossier, provoquant autant de refus et d'événements d'audit — amplification de charge sur le service d'audit et la base.
Impact : Risque de denial-of-service par amplification audit. La spec ne définit pas de protection contre l'abus de volume sur les endpoints de quota.
Gravité : Majeur

Type : Risque sécu/conformité
Référence : Spec SEC-84-04, INV-84-09, HORS-PÉRIMÈTRE-COMPLIANCE-02
Description : SEC-84-04 mentionne "base légale, minimisation, droits des personnes" pour les données de mineurs. Mais la spec ne définit pas le mécanisme de consentement parental (article 8 RGPD pour < 16 ans / 15 ans en France). INV-84-09 (plan universel sans distinction d'âge) coexiste avec des obligations RGPD de traitement différencié. La spec délègue à HORS-PÉRIMÈTRE-COMPLIANCE-02.
Impact : La délégation est explicite et documentée. Le risque existe au niveau epic PD-185, pas spécifiquement PD-84. Tant que la gouvernance conformité transverse couvre ce point, la délégation est acceptable.
Gravité : Mineur

Type : Risque sécu/conformité
Référence : Spec section 3.2.3, section 7.1 (PUT /account/plan)
Description : L'endpoint PUT /account/plan est un stub de test/intégration. La spec indique qu'il permet de "simuler la transition de plan sans paiement réel". Aucune restriction d'environnement n'est définie : cet endpoint doit-il être désactivé en production ? Protégé par un feature flag ? Restreint à des rôles spécifiques ?
Impact : Si cet endpoint est accessible en production, tout utilisateur authentifié pourrait basculer son compte en PREMIUM sans paiement. La spec ne définit pas de garde-fou.
Gravité : Majeur

Type : Risque sécu/conformité
Référence : SEC-84-02 / Tests TC-SEC-02
Description : TC-SEC-02 teste l'accès non autorisé sur GET, POST documents, POST close. Il ne couvre pas : tentative d'export sur dossier d'autrui, manipulation de paramètres sur GET /folders (listing), accès aux capabilities d'un autre compte.
Impact : Couverture partielle. Les endpoints d'export et de listing ne sont pas testés pour l'isolation de propriété.
Gravité : Mineur