PD-240-SPECIFICATION-REVIEW

Type : Ambiguïté Référence : (PD-240-specification.md §5 Définitions / confirmation renforcée) Description : Le format et le contenu de la « confirmation renforcée » ne sont pas définis ; seul un « format exact à contractualiser » est mentionné. Cela rend l’exigence INV-240-03 et CA-240-03 indéterministe. Impact : Impossibilité de vérifier objectivement la validité de la confirmation ; risque de divergences d’implémentation. Gravité : Majeur

Type : Ambiguïté Référence : (PD-240-specification.md §11 Points à clarifier / modalités RGPD) Description : Les modalités d’anonymisation/purge RGPD ne sont pas bornées (périmètre des données, délai, sources). La règle INV-240-05 manque d’observable contractuel précis. Impact : Testabilité faible ; risque de non‑conformité RGPD non détectée en audit. Gravité : Majeur

Type : Non testable Référence : (PD-240-specification.md §6 INV-240-05 / CA-240-05) Description : L’observable « Audit de données » n’est pas définie (source, périmètre, format), ce qui rend la vérification de l’anonymisation/purge non testable de façon déterministe. Impact : Conformité RGPD non prouvable par tests contractuels. Gravité : Majeur

Type : Incohérence Spec↔Tests Référence : (PD-240-tests.md T-240-POST-02 / Spec INV-240-05) Description : Le test T-240-POST-02 suppose un accès direct aux « stores applicatifs » pour vérifier l’anonymisation, mais la spec ne définit pas cet observable ni son périmètre. Impact : Test non reproductible sans artefact externe ; risque de test inapplicable. Gravité : Majeur

Type : Hypothèse dangereuse Référence : (PD-240-specification.md §7 Flux F-240-01 / §8 ERR-240-DELETE-FAILED) Description : Le comportement en cas de suppression Keycloak réussie mais purge RGPD échouée n’est pas contractualisé (point à clarifier). Le flux nominal suppose une exécution séquentielle sans préciser l’atomicité. Impact : Résultats incohérents possibles (compte supprimé, données non purgées) sans règle contractuelle de compensation ou d’état final. Gravité : Majeur

Type : Risque sécu/conformité Référence : (PD-240-specification.md §8 ERR-240-SESSION-INVALIDATION-FAILED / §6 INV-240-06) Description : La spec admet qu’une suppression puisse réussir alors que l’invalidation des sessions échoue (ERR-240-SESSION-INVALIDATION-FAILED) sans encadrement temporel ni exigence de suivi. Risque de sessions persistantes après suppression. Impact : Exposition de sessions actives post‑suppression ; non‑conformité aux exigences de sécurité et PD-106. Gravité : Majeur

Type : Incohérence Spec↔Tests Référence : (PD-240-tests.md T-240-NOM-01 / Spec INV-240-06) Description : Le test nominal vérifie l’invalidation d’un token précédent, mais la spec ne définit pas le délai maximal d’invalidation ; la testabilité du « après suppression » reste non bornée temporellement. Impact : Risque de tests flous ou non déterministes selon l’environnement. Gravité : Mineur

Type : Non testable Référence : (PD-240-specification.md §6 INV-240-04 / CA-240-04) Description : « Suppression irréversible Keycloak » est vérifiée par « échec d’authentification ultérieure » sans préciser le délai de propagation ni le mécanisme d’observation. La preuve peut être non déterministe. Impact : Test potentiellement flaky ; auditabilité partielle. Gravité : Mineur

Type : Ambiguïté Référence : (PD-240-specification.md §8 ERR-240-DELETE-FAILED) Description : Le périmètre exact de « Échec suppression compte (Keycloak ou purge) » n’est pas distingué ; aucun code différencié entre suppression Keycloak et purge RGPD. Impact : Diagnostic et testabilité réduits ; perte de traçabilité des causes d’échec. Gravité : Mineur