PD-84-specification-review.md¶

Type : Ambiguïté
Référence : Spec section 9, SLA-84-01 / INV-84-05 / INV-84-06
Description : La spécification exige que l'activation Premium rende les capacités effectives "immédiatement" mais ne fournit aucun seuil numérique (p95 < X secondes, borne max, stratégie de repli en cas de propagation partielle). La section 9.1 reconnaît elle-même cette lacune explicitement.
Impact : Impossible de définir un critère d'acceptation objectif pour la montée en Premium. En cas de latence de propagation (cache, eventual consistency), aucun seuil ne permet de distinguer un comportement conforme d'une anomalie. Les invariants INV-84-05 et INV-84-06 sont formellement inviolables mais matériellement invérifiables.
Gravité : Bloquant

Type : Ambiguïté
Référence : Spec section 2, section 4 (F-84-01 à F-84-06), section 3.3
Description : La spécification définit les quotas FREE (3 dossiers actifs, 100 documents) mais ne spécifie jamais les limites PREMIUM. Le message utilisateur mentionne "dossiers illimités" (section 7.3), mais aucune règle fonctionnelle F-84-XX ne formalise cela. Les contraintes de cardinalité (section 3.3) ne s'appliquent qu'au plan FREE. Il n'est pas précisé si un compte PREMIUM a des quotas plus élevés, illimités, ou si les quotas FREE sont simplement levés.
Impact : L'implémentation de TC-10 (upgrade) et TC-LIM-04 (export après upgrade) dépend de la connaissance des limites PREMIUM. L'endpoint POST /folders/{folderId}/documents en PREMIUM : accepte-t-il le document 101 ? Rien ne le dit formellement.
Gravité : Majeur

Type : Ambiguïté
Référence : Spec section 7.2, code erreur PLAN_STATE_INCONSISTENT
Description : Ce code erreur est listé parmi les erreurs métier contractuelles mais aucune règle fonctionnelle, aucun invariant et aucun critère d'acceptation ne définit dans quelles conditions il est émis. TC-LIM-04 mentionne que ce code ne doit PAS être observé, mais sans jamais définir quand il DEVRAIT l'être.
Impact : Code mort ou comportement imprévisible. Un développeur ne sait pas quand lever cette erreur. Un testeur ne peut pas écrire de test positif pour ce code.
Gravité : Majeur

Type : Ambiguïté
Référence : Spec section 3.1 (ProbatoryFolder.category), section 7.2, F-84-03
Description : Le modèle de données indique que category "doit inclure B2C_EVIDENCE_MINOR" mais ne définit pas l'ensemble des catégories valides. F-84-03 mentionne "la catégorie probatoire applicable" sans énumérer les valeurs autorisées. Le code erreur INVALID_FOLDER_CATEGORY existe mais les conditions de son déclenchement sont indéterminées.
Impact : Impossible de valider un refus de catégorie invalide. Les préconditions de test utilisent CATEGORY_VALID_1 et CATEGORY_INVALID_X mais aucun test ne couvre le code erreur INVALID_FOLDER_CATEGORY.
Gravité : Majeur

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 entre consultation et démonstration.
Impact : Exigence non différenciable de F-84-11 (consulter ses preuves). Aucun critère d'acceptation CA-84-XX ne couvre spécifiquement cette exigence. Aucun test ne la couvre.
Gravité : Mineur

Type : Ambiguïté
Référence : Spec section 3.1 (entité 4), section 3.2.2
Description : L'entité CapabilityState liste les capabilities booléennes et la section 3.2.2 définit leurs valeurs par plan. Mais aucune règle fonctionnelle ne définit COMMENT et QUAND cette entité est mise à jour : est-elle calculée à la volée à partir de plan_type ? Est-elle persistée et mise à jour par un event handler lors de la transition de plan ? Est-elle une vue matérialisée ?
Impact : Si CapabilityState est persistée, la transition FREE -> PREMIUM nécessite une mise à jour explicite (risque de désynchronisation). Si elle est calculée, son existence en tant qu'entité du modèle de données est trompeuse. Cela impacte directement le SLA-84-01 et les tests TC-10, TC-LIM-04.
Gravité : Majeur

Type : Ambiguïté
Référence : Spec section 3.1 (ProbatoryFolder), F-84-13, 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 sont ses valeurs possibles, ni s'il est fourni par l'utilisateur ou calculé par le système. L'endpoint de clôture ne mentionne pas ce champ dans ses entrées.
Impact : Champ orphelin dans le schéma. L'implémentation peut l'ignorer ou l'inventer, sans garantie de cohérence. Aucun test ne vérifie sa valeur.
Gravité : Mineur

Type : Ambiguïté
Référence : Spec section 7.1 (POST /folders/{folderId}/documents), F-84-04
Description : L'endpoint de document stipule "refuse au-delà de 100 en FREE". La formulation laisse entendre que la limite de 100 ne s'applique pas en PREMIUM, mais aucune règle fonctionnelle ne définit explicitement le comportement PREMIUM (illimité ? plafond plus élevé ?). Le message "dossiers illimités" de la section 7.3 concerne les dossiers, pas les documents.
Impact : Ambiguïté entre "dossiers illimités" et "documents illimités". Un compte PREMIUM avec 100+ documents par dossier : autorisé ou non ?
Gravité : Majeur

Type : Ambiguïté
Référence : Spec section 3.1 (UserAccount.account_role), INV-84-09, INV-84-10
Description : L'entité UserAccount comporte un champ account_role (MINOR, LEGAL_GUARDIAN, OTHER). INV-84-09 stipule que le plan est universel sans distinction d'âge. INV-84-10 stipule que les quotas sont séparés par compte. Aucune règle fonctionnelle F-84-XX ne conditionne un comportement au account_role. Le rôle est présent dans le modèle mais n'a aucun effet observable dans PD-84.
Impact : Le champ est soit inutile dans le périmètre PD-84, soit la spécification omet des règles liées au rôle. TC-15 teste l'absence de distinction par rôle, confirmant qu'il n'a pas d'impact — mais cela n'est pas explicité dans la spécification.
Gravité : Mineur

Type : Contradiction
Référence : Spec section 3.3 vs F-84-01/F-84-02 vs section 7.1
Description : La section 3.3 stipule "Pour un UserAccount en FREE : nombre de ProbatoryFolder en ACTIVE <= 3". F-84-01 et F-84-02 le confirment. Mais la section 7.1 (POST /folders) dit "refuse si quota dossiers actifs atteint en FREE" — cela implique que le quota ne s'applique PAS en PREMIUM. Or la section 3.3 ne définit aucune contrainte pour PREMIUM. Il y a une présomption de "pas de limite en PREMIUM" mais jamais formalisée.
Impact : Non-contradiction à proprement parler, mais incohérence par omission : si un comportement n'est pas spécifié, il est "non autorisé" (section 10.2 dernier paragraphe). Or le comportement PREMIUM est requis par TC-10 et TC-LIM-04.
Gravité : Majeur

Type : Contradiction (spec étend le besoin)
Référence : Spec section 5 (15 invariants) vs besoin d'origine
Description : La spécification définit 15 invariants dont INV-84-12 à INV-84-15 qui n'ont pas de correspondance directe dans l'expression de besoin : INV-84-12 (contenu chiffré), INV-84-13 (UX adolescent), INV-84-14 (pas d'export gratuit), INV-84-15 (traçabilité). Ces invariants ont été ajoutés par le rédacteur de la spécification sans validation PO tracée.
Impact : Risque de sur-spécification. Les invariants ajoutés sont pertinents mais leur absence du besoin signifie qu'ils n'ont pas été explicitement validés par le PO. INV-84-13 en particulier introduit une exigence UX non mesurable.
Gravité : Mineur

Type : Contradiction
Référence : Spec F-84-13 vs section 3.2.1
Description : F-84-13 stipule que la clôture rend le dossier "lecture seule" et "libère un slot actif". La section 3.2.1 ajoute un troisième effet : "Conservation intégrale des preuves scellées associées". Cet effet n'est pas mentionné dans F-84-13 (il l'est dans F-84-14 séparément). La règle fonctionnelle est incomplète par rapport au modèle d'état.
Impact : Un implémenteur lisant uniquement F-84-13 pourrait manquer l'aspect conservation.
Gravité : Mineur

Type : Non testable
Référence : Spec section 9, SLA-84-01 / Tests section 6
Description : La spécification reconnaît elle-même que le délai "immédiatement" n'est pas chiffré. Le cahier de tests le classe en "NON TESTABLE". Aucun seuil p95/p99 n'est défini.
Impact : INV-84-05 et INV-84-06 sont formellement présents mais leur vérification temporelle est impossible. TC-10 teste la fonctionnalité mais pas le SLA.
Gravité : Bloquant

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 en test d'acceptation fonctionnelle" — ce qui mesure la fluidité technique, pas la compréhension adolescente. Aucun questionnaire SUS, aucun taux de compréhension, aucun indice de lisibilité n'est défini.
Impact : L'invariant est indémontrable. Le test TC-14 couvre le flux nominal sans erreur, mais pas la compréhensibilité.
Gravité : Majeur

Type : Non testable
Référence : Spec INV-84-12, SEC-84-04 / Tests TC-SEC-03
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 spécification ne fournit pas de protocole d'audit côté infra/backoffice pour vérifier que la plateforme elle-même n'a pas accès aux clés de déchiffrement.
Impact : Couverture API-only. Un auditeur ne peut pas valider la garantie "inaccessible à la plateforme" sans protocole d'audit infra.
Gravité : Majeur

Type : Non testable
Référence : Spec F-84-12
Description : Aucun critère d'acceptation CA-84-XX ne couvre explicitement F-84-12. Aucun test ne l'adresse. L'exigence n'a pas d'observable mesurable.
Impact : Exigence fonctionnelle orpheline dans la matrice de couverture.
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 de règle sémantique formelle pour qualifier l'ambiguïté. Le critère "0 erreur bloquante" est mesurable mais ne couvre pas l'aspect linguistique.
Impact : La partie "vocabulaire ambigu" de CA-84-14 est subjective et non vérifiable.
Gravité : Mineur

Type : Incohérence Spec↔Tests
Référence : Tests TC-LIM-01 vs INV-84-04
Description : TC-LIM-01 part d'un compte avec "exactement 2 dossiers actifs" et envoie "2 requêtes POST /folders en parallèle". Le résultat attendu est "exactement 1 succès et 1 refus QUOTA_FOLDER_LIMIT_REACHED". Or, en partant de 2 dossiers actifs, les deux requêtes pourraient légitimement réussir (menant à 3 et 4) si la vérification n'est pas atomique. Le résultat attendu présuppose un niveau d'isolation transactionnelle (SERIALIZABLE ou verrou explicite) que la spécification ne définit pas.
Impact : Le test est non-déterministe sans spécification du niveau d'isolation. En READ COMMITTED, les deux requêtes pourraient voir 2 dossiers et réussir toutes les deux.
Gravité : Bloquant

Type : Incohérence Spec↔Tests
Référence : Tests TC-LIM-02 vs INV-84-04
Description : TC-LIM-02 part d'un dossier avec 99 documents et envoie 2 requêtes parallèles. Le résultat attendu est "exactement 1 succès (100e), 1 refus". Même problème que TC-LIM-01 : sans spécification du mécanisme de contrôle de concurrence (verrou pessimiste, contrainte CHECK en base, compteur atomique), le résultat est non-déterministe.
Impact : En l'état, les deux requêtes pourraient réussir (menant à 101 documents), violant INV-84-04.
Gravité : Bloquant

Type : Incohérence Spec↔Tests
Référence : Tests TC-10 action 1 vs Spec (aucun endpoint de transition de plan)
Description : TC-10 requiert "Transition de plan de FREE vers PREMIUM (événement métier de plan)". La spécification ne définit aucun endpoint, aucun mécanisme, aucun event de transition de plan. La section 9 mentionne la transition mais ne la spécifie pas. Le périmètre explicite (section 2.2) exclut "tarification Premium, paiement, facturation".
Impact : Le test TC-10 est inimplémentable dans le périmètre PD-84. L'action "basculer le plan en PREMIUM" n'a pas d'API définie.
Gravité : Majeur

Type : Incohérence Spec↔Tests
Référence : Tests TC-11 résultat attendu vs INV-84-01 / INV-84-02
Description : TC-11 vérifie que "les objets de preuve produits dans les deux plans contiennent le même niveau d'information probatoire attendu : hash présent, horodatage présent, ancrage présent". Cela vérifie la PRÉSENCE des champs mais pas leur ÉQUIVALENCE algorithmique. INV-84-02 exige "aucune dégradation cryptographique" — vérifier la présence d'un hash ne prouve pas qu'il s'agit du même algorithme/longueur/force.
Impact : Le test pourrait passer avec un hash SHA-256 en FREE et un hash SHA-3-512 en PREMIUM. La non-dégradation n'est pas démontrée par la seule présence des champs.
Gravité : Majeur

Type : Incohérence Spec↔Tests
Référence : Tests TC-06 vs CA-84-06
Description : TC-06 est un test UI ("Ouvrir l'écran détail dossier", "Contrôles d'export visibles mais désactivés", "texte exact attendu", "CTA Premium visible et actionnable"). Le cahier de tests ne précise pas s'il s'agit d'un test E2E (Cypress/Playwright), d'un test de composant, ou d'un test manuel. Les préconditions communes parlent d'appels API mais TC-06 manipule des éléments visuels.
Impact : Sans précision du framework, le test est potentiellement non-automatisable ou mal catégorisé. Son intégration dans une pipeline CI est incertaine.
Gravité : Mineur

Type : Incohérence Spec↔Tests
Référence : Spec section 7.2 (INVALID_FOLDER_CATEGORY) vs cahier de tests complet
Description : Le code erreur INVALID_FOLDER_CATEGORY est défini comme erreur métier contractuelle. Les préconditions de test définissent CATEGORY_INVALID_X (section 3). Mais aucun test TC-XX, TC-LIM-XX ou TC-SEC-XX ne provoque ni ne vérifie ce code erreur. La matrice de couverture ne le mentionne pas.
Impact : Code erreur contractuel sans aucune couverture de test.
Gravité : Majeur

Type : Incohérence Spec↔Tests
Référence : Tests TC-08 vs CA-84-08
Description : CA-84-08 exige le refus d'ajout, modification ET suppression sur un dossier clôturé. TC-08 ne teste que l'ajout de document (POST /folders/{F1}/documents). Le cahier de tests reconnaît (section 6) que les endpoints de modification/suppression n'existent pas. Mais CA-84-08 les mentionne explicitement comme comportements attendus.
Impact : Soit CA-84-08 est sur-spécifié (les opérations n'existent pas dans PD-84), soit la spécification omet des endpoints nécessaires. Dans les deux cas, le critère d'acceptation n'est pas entièrement testable.
Gravité : Majeur

Type : Incohérence Spec↔Tests
Référence : Spec F-84-18 / SEC-84-03 vs Tests TC-13
Description : F-84-18 et SEC-84-03 listent "tentative d'export verrouillé" parmi les événements à auditer. TC-13 teste 4 événements : refus quota dossier, refus quota document, clôture, changement de plan. La tentative d'export verrouillé n'est pas testée dans TC-13. TC-05 teste le refus d'export mais ne vérifie pas l'événement d'audit associé.
Impact : Événement d'audit contractuel non vérifié.
Gravité : Majeur

Type : Incohérence Spec↔Tests
Référence : Tests matrice de couverture, TC-15 vs INV-84-05
Description : La matrice de couverture indique que 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 entre un compte MINOR et un compte OTHER, tous deux en FREE. Ce test ne touche ni la transition de plan ni la montée en Premium. Le mapping est erroné.
Impact : Couverture INV-84-05 surévaluée. En réalité, seuls TC-10 et TC-LIM-04 couvrent cet invariant.
Gravité : Mineur

Type : Hypothèse dangereuse (atomicité)
Référence : Spec INV-84-04, F-84-01, F-84-02, F-84-04 / Tests TC-LIM-01, TC-LIM-02
Description : L'invariant INV-84-04 exige que les quotas soient "exacts, déterministes et traçables". Les tests de concurrence TC-LIM-01 et TC-LIM-02 présupposent un mécanisme d'exclusion mutuelle. La spécification ne définit aucune stratégie de contrôle de concurrence : verrouillage pessimiste (SELECT FOR UPDATE), contrainte CHECK en base, compteur atomique avec CAS, ou sérialisation.
Impact : En environnement multi-instance (horizontal scaling), sans mécanisme explicite, un race condition pourrait permettre 4 dossiers actifs ou 101 documents, violant INV-84-04.
Gravité : Bloquant

Type : Hypothèse dangereuse (idempotence)
Référence : Spec section 3.2.1, endpoint POST /folders/{folderId}/close
Description : La spécification définit que la transition ACTIVE -> CLOSED_READ_ONLY est unidirectionnelle. Mais elle ne spécifie pas ce qui se passe si on appelle POST /folders/{folderId}/close sur un dossier déjà clôturé. Erreur 409 ? Succès idempotent ? Aucune règle ne le dit.
Impact : Comportement indéfini en cas de double appel (timeout réseau, retry client). Aucun test ne couvre ce cas.
Gravité : Majeur

Type : Hypothèse dangereuse (cohérence éventuelle)
Référence : Spec section 3.1 (CapabilityState), section 3.2.2 / Tests TC-LIM-04
Description : TC-LIM-04 teste la séquence "refus export FREE -> upgrade PREMIUM -> export autorisé". Le test attend "aucun PLAN_STATE_INCONSISTENT observé". Mais si CapabilityState est une entité persistée et que la mise à jour est asynchrone (event-driven), il existe une fenêtre temporelle où plan_type=PREMIUM mais can_export_composite=false. La spécification ne définit pas si la mise à jour est synchrone ou asynchrone.
Impact : Fenêtre de temps où l'état est inconsistant. C'est précisément le scénario de PLAN_STATE_INCONSISTENT, mais puisque le code n'est pas défini (cf. AMB-03), il est impossible de savoir si cette fenêtre est un bug ou un état transitoire accepté.
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" pour vérifier l'absence de reset mensuel. Les préconditions indiquent "horloge système figée". Le test présuppose que l'horloge est injectable et contrôlable dans l'environnement de test. Cela n'est pas spécifié dans la spécification comme exigence technique d'architecture.
Impact : Faible si l'architecture permet l'injection d'horloge. Mais si le système utilise Date.now() directement, le test est inimplémentable de manière fiable.
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 non-négociable (INV-84-15). La spécification ne définit pas le comportement si le service PD-31 (audit log) est indisponible. La création d'un dossier doit-elle échouer si l'audit ne peut pas être journalisé ? Ou l'audit est-il en best-effort ?
Impact : Si l'audit est synchrone et bloquant, l'indisponibilité de PD-31 bloque toutes les opérations de PD-84. Si l'audit est asynchrone, des événements peuvent être perdus, violant INV-84-15.
Gravité : Majeur

Type : Hypothèse dangereuse (ordonnancement)
Référence : Spec section 3.2.1 effets de transition
Description : La clôture a trois effets : (1) libération de slot, (2) blocage des modifications, (3) conservation des preuves. L'ordre d'exécution n'est pas spécifié. Si la libération de slot précède le blocage des modifications, un autre processus pourrait créer un nouveau dossier et le dossier en cours de clôture pourrait encore accepter des écritures pendant un instant.
Impact : Fenêtre de race condition entre la libération du slot et la finalisation de la clôture.
Gravité : Mineur

Type : Risque sécu/conformité
Référence : Spec section 7 (tous les endpoints)
Description : Aucune règle de rate limiting n'est définie. Un utilisateur malveillant pourrait envoyer des milliers de requêtes de création de dossier et générer autant d'événements d'audit et de refus, causant un denial of service sur le service d'audit ou la base de données.
Impact : Amplification de charge via les refus de quota. Le système génère un événement d'audit pour chaque refus (F-84-18), ce qui amplifie l'impact d'un abus.
Gravité : Majeur

Type : Risque sécu/conformité
Référence : Spec SEC-84-04 / INV-84-09
Description : SEC-84-04 mentionne "base légale, minimisation, droits des personnes" pour les données de mineurs. Mais la spécification ne définit pas le mécanisme de consentement parental requis par l'article 8 du RGPD pour les mineurs de moins de 16 ans (15 ans en France). Le plan est "universel sans distinction d'âge" (INV-84-09), mais le RGPD exige un traitement différencié pour les mineurs.
Impact : Contradiction potentielle entre INV-84-09 (pas de distinction d'âge) et les obligations RGPD (traitement différencié pour les mineurs). La spécification délègue à "la gouvernance conformité transverse" (HORS-PÉRIMÈTRE-COMPLIANCE-02) mais le risque existe dans PD-84.
Gravité : Majeur

Type : Risque sécu/conformité
Référence : Spec section 3.1 (AuditLogEvent), F-84-18, INV-84-15
Description : L'entité AuditLogEvent repose sur PD-31 mais la spécification ne mentionne aucune garantie d'immutabilité des logs d'audit dans le contexte PD-84 : pas de chaînage cryptographique, pas de référence à un mécanisme append-only, pas de protection contre la modification rétroactive.
Impact : Si les logs d'audit peuvent être modifiés, INV-84-15 (traçabilité) perd sa valeur probatoire. Pour une application visant à produire des preuves juridiques, c'est un risque de crédibilité.
Gravité : Mineur (PD-31 est une dépendance externe censée fournir ces garanties)

Type : Risque sécu/conformité
Référence : Spec section 3.1 (UserAccount.plan_type), TC-10
Description : La spécification ne définit pas qui peut modifier plan_type. TC-10 suppose qu'un "événement métier de plan" le modifie. Mais aucune règle de sécurité ne protège cette transition : pas de vérification de paiement, pas de signature d'événement, pas de guard spécifique. Un acteur interne ou un bug pourrait basculer un compte en PREMIUM sans paiement.
Impact : La section 2.2 exclut le paiement du périmètre, mais la transition de plan est dans le périmètre (INV-84-05, INV-84-06). Le mécanisme de protection de cette transition n'est spécifié nulle part.
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 d'un utilisateur aux dossiers d'un autre sur 3 opérations : GET, POST documents, POST close. Il ne couvre pas : tentative d'export sur le dossier d'autrui, tentative de listing des dossiers d'autrui via manipulation de paramètres, accès aux capabilities d'un autre compte.
Impact : Couverture partielle du test d'accès horizontal. Les endpoints d'export et l'endpoint de listing ne sont pas testés pour l'isolation de propriété.
Gravité : Mineur