PD-81 - Review Step 3 : CONFORMITY_CHECK — v2 (re-evaluation apres correction)¶

Statut: REVIEW PHASE 1 — ITERATION 2 Version: 2.0.0 Date: 2026-02-23 Perimetre: EPIC PD-189 (CRYPTO) Auditeur: Claude Opus 4.6 (auditeur technique independant)

Documents audites¶

PARTIE A — Verification des corrections v1¶

Ecart v1 : ECT-01 — COMPLETED absent du modele LegalReKey.status¶

Statut : RESOLU

Justification : La spec v2 §7.3 definit desormais status avec la liste explicite ACTIVE/REVOKED/EXPIRED/COMPLETED/DESTROYED [CORRECTION v2]. Le statut COMPLETED est present dans le modele de donnees. La table de transitions v2 §7.3 definit la transition ACTIVE -> COMPLETED via closeLegalAccess avec END_OF_CONSULTATION. Les tests v2 N4 referent correctement aux statuts {REVOKED, EXPIRED, COMPLETED} puis DESTROYED. L'incoherence inter-documents est resolue.

Ecart v1 : AMB-01 — "Fin de consultation" non definie¶

Statut : RESOLU

Justification : La spec v2 §3 ajoute une definition contractuelle de END_OF_CONSULTATION [CORRECTION v2] : "condition de cloture declenchee par action explicite de l'autorite judiciaire consultante (Bob) OU par epuisement du nombre de consultations autorisees explicitement par le mandat; a defaut de plafond explicite dans le mandat, seule l'action explicite est valide." Les deux declencheurs sont identifies (action explicite Bob, plafond mandat). La regle par defaut en l'absence de plafond est specifiee (seule l'action explicite). L'interface closeLegalAccess §9.1 accepte END_OF_CONSULTATION comme cause avec post-condition coherente. Le test L2 v2 precise "action explicite de l'autorite judiciaire" comme etape. La regle metier est maintenant suffisante pour une implementation deterministe.

Ecart v1 : SEC-01 — Source de bobPublicKey non specifiee¶

Statut : RESOLU

Justification : La spec v2 ajoute dans §3 une definition de "Bob (contexte Legal PRE)" et une definition normative "Source et verification de bobPublicKey" [CORRECTION v2] : "la cle provient du mandat eIDAS (ou de son annexe signee referencee) et DOIT etre verifiee via chaine de certificats/CRL/OCSP par TSP, puis rapprochee d'une identite judiciaire autorisee dans IAM." La source (mandat eIDAS / annexe signee), le mode de verification (TSP + rapprochement IAM), et le destinataire (autorite judiciaire consultante) sont definis. Les pre-conditions de generateLegalReKey §9.2 reprennent ces exigences [CORRECTION v2]. La chaine de confiance est complete.

Ecart v1 : AMB-02 — validationTtl sans borne contractuelle¶

Statut : RESOLU

Justification : La spec v2 §3 definit "TTL de double validation (validationTtl)" [CORRECTION v2] : "fenetre contractuelle par defaut de 7 jours calendaires; parametre configurable dans l'intervalle [1 heure, 30 jours], sans depasser la validite du mandat." Le modele §7.2 confirme "defaut 7 jours calendaires, configurable [1 heure..30 jours]" [CORRECTION v2]. Le test N2 reference "defaut 7 jours calendaires" [CORRECTION v2]. La valeur par defaut, la plage, et la borne superieure (validite mandat) sont definies. Un implementeur peut coder cette regle sans ambiguite.

Ecart v1 : ECT-02 — Aucune transition definie vers DESTROYED¶

Statut : RESOLU

Justification : La spec v2 §7.3 ajoute une table de transitions contractuelles complete [CORRECTION v2] avec 6 transitions : - ACTIVE -> REVOKED (via revokeReKey(), invalidation <= 5s) - ACTIVE -> EXPIRED (echeance expiresAt) - ACTIVE -> COMPLETED (via closeLegalAccess + END_OF_CONSULTATION) - REVOKED -> DESTROYED (destruction cryptographique) - EXPIRED -> DESTROYED (destruction cryptographique) - COMPLETED -> DESTROYED (destruction cryptographique)

Chaque transition a un declencheur et une contrainte explicites. Le cycle de vie est complet et deterministe. Les tests v2 N4, L1, L2, L3, L4 sont coherents avec cette table.

Ecart v1 : AMB-03 — Orchestration ambigue activateLegalAccess vs generateLegalReKey¶

Statut : RESOLU

Justification : La spec v2 §5-N3 etape 1 clarifie [CORRECTION v2] : "le systeme appelle activateLegalAccess, qui orchestre en interne generateLegalReKey() (un seul appel API externe)." La spec v2 §9.1 activateLegalAccess confirme [CORRECTION v2] : "L'appel orchestre en interne generateLegalReKey(...); aucun second appel API externe n'est requis pour le meme dossier." Le test N3 v2 est coherent : "Appeler activateLegalAccess (orchestration interne de generateLegalReKey)" [CORRECTION v2]. L'ambiguite est levee : un seul appel API externe (activateLegalAccess) qui encapsule l'appel interne.

Ecart v1 : AMB-04 — "Invalidation immediate" sans borne¶

Statut : RESOLU

Justification : La spec v2 §3 "Revocation" ajoute [CORRECTION v2] : "effet immediat attendu avec invalidation dans la meme transaction ou sous 5 secondes maximum." La spec v2 §7.3 table de transitions precise "Invalidation immediate (<= 5s)" pour ACTIVE -> REVOKED. La spec v2 §10.2 confirme [CORRECTION v2] : "L'invalidation dite 'immediate' [...] doit etre effective dans la meme transaction ou en <= 5 secondes." La borne contractuelle est definie (5 secondes). Le test S3 peut verifier cette contrainte avec un delai observable.

Ecart v1 : AMB-05 — Mapping roles PD-82 non specifie¶

Statut : RESOLU

Justification : La spec v2 §3 "Double validation 2-of-2" ajoute [CORRECTION v2] : "mapping PD-82 DPO -> PARENT et LegalOfficer -> AUTHORITY et etats intermediaires PENDING_DPO/PENDING_LEGAL_OFFICER/PENDING_BOTH avant ACTIVATED." Le flux N2 v2 §5 etape 3 reprend ce mapping [CORRECTION v2]. Le mapping est explicite et les etats intermediaires sont nommes. Coherent avec les etats PD-82 (PENDING_PARENT/PENDING_AUTHORITY) renommes pour le contexte legal.

Ecart v1 : SEC-02 — Verification identite juridique non precisee¶

Statut : RESOLU

Justification : La spec v2 §6 ERR-81-08 precise [CORRECTION v2] : "Validateur 1 et validateur 2 de meme identite juridique (userId IAM identique), meme si le role differe." Le critere de distinction est le userId IAM, pas le role fonctionnel ni le certificat technique. L'invariant INV-81-03 v2 confirme [CORRECTION v2] : "deux userId IAM juridiquement distincts." Le test E08 v2 utilise validator-dual-001 defini comme "meme userId IAM simule" [CORRECTION v2]. La verification est univoque : identite = userId IAM.

Ecart v1 : AMB-06 — Rate limiting non contractualise¶

Statut : RESOLU

Justification : La spec v2 §3 ajoute [CORRECTION v2] : "Rate limiting legal PRE: valeur contractuelle par defaut de 10 consultations/minute par legalReKeyId, parametre configurable dans [1..60] consultations/minute." Le flux N3 v2 §5 etape 4 reprend ce seuil [CORRECTION v2]. ERR-81-18 v2 reference le seuil [CORRECTION v2]. Les tests E18 et S5 v2 referent au "defaut 10/min par legalReKeyId" [CORRECTION v2]. Le point NT-81-01 v2 passe a "TESTABLE" [CORRECTION v2]. La valeur par defaut, l'unite, la granularite et la plage configurable sont definies.

Ecart v1 : AMB-07 — Frequence d'ancrage non definie¶

Statut : RESOLU

Justification : La spec v2 §3 ajoute [CORRECTION v2] : "Frequence d'ancrage probatoire: ancrage au batch periodique avec delai maximal contractuel de 24 heures entre emission de l'evenement et ancrage observable." L'invariant INV-81-08 v2 confirme [CORRECTION v2] : "rattachable a l'ancrage periodique (delai max 24h)." La spec v2 §10.3 precise [CORRECTION v2] : "cadence periodique avec delai maximal d'ancrage de 24 heures." La borne contractuelle (24h max) est definie. Un test peut verifier qu'un evenement est ancre dans ce delai.

Ecart v1 : SEC-03 — Persistance residuelle sans transition DESTROYED¶

Statut : RESOLU

Justification : La table de transitions v2 §7.3 definit explicitement les transitions REVOKED -> DESTROYED, EXPIRED -> DESTROYED, et COMPLETED -> DESTROYED avec la contrainte "Suppression physique/zeroisation de l'artefact obligatoire" [CORRECTION v2]. INV-81-07 v2 mentionne "destructible de facon verifiable a expiration, a fin de consultation, ou sur revocation." Le test AC-81-09 v2 confirme le cycle EXPIRED -> DESTROYED. Le risque de persistance residuelle est couvert par l'obligation de destruction physique/zeroisation avant atteinte de l'etat DESTROYED.

Ecart v1 : AMB-08 — Taxonomie evenements probatoire/informatif non delimitee¶

Statut : RESOLU

Justification : La spec v2 §7.4 eventType ajoute [CORRECTION v2] une liste explicite des evenements probatoires : "probatoire si dans {MANDATE_QUALIFIED, VALIDATION_SUBMITTED, VALIDATION_ACTIVATED, LEGAL_ACCESS_ACTIVATED, LEGAL_DOCUMENT_ACCESSED, LEGAL_ACCESS_CLOSED, LEGAL_REKEY_REVOKED, LEGAL_REKEY_DESTROYED}, informatif sinon." La distinction est exhaustive : 8 types probatoires nommes, tout autre type est informatif. Le champ tsaTokenRef ("obligatoire pour evenement probatoire") est desormais interpretable sans ambiguite.

Ecart v1 : AMB-09 — Mapping documentId mandat vers internes non specifie¶

Statut : RESOLU

Justification : La spec v2 §5-N1 etapes 4-5 ajoutent [CORRECTION v2] : "puis resout chaque identifiant de mandat vers un documentId interne ProbatioVault" (etape 4), et "En cas de non-resolution d'au moins un identifiant, le systeme rejette la demande en fail-closed (ERR-81-06)" (etape 5). L'erreur ERR-81-06 v2 couvre "non resoluble vers les documentId internes" [CORRECTION v2]. Le principe de resolution est defini (mapping obligatoire avec rejet fail-closed), et l'erreur de non-resolution est couverte. Le mecanisme concret de resolution (table de mapping, API externe) reste hors implementation, ce qui est acceptable pour une specification contractuelle.

Ecart v1 : AMB-10 — "Titulaire" non formalise¶

Statut : RESOLU

Justification : La spec v2 §3 ajoute [CORRECTION v2] : "Titulaire: proprietaire du coffre (ownerUserId) auquel appartiennent les documents vises par le mandat; l'habilitation audit est evaluee sur cette propriete IAM." L'interface getLegalAuditProof §9.1 v2 precise [CORRECTION v2] : "titulaire (ownerUserId du coffre cible) ou role explicitement delegue dans IAM." Le point NT-81-02 v2 passe a "TESTABLE" [CORRECTION v2] avec reference "ownerUserId vs non-owner." Le test S6 v2 reference "ownerUserId du coffre cible dans IAM" [CORRECTION v2]. Le modele d'habilitation est defini : ownerUserId + delegation IAM explicite.

PARTIE B — Nouveaux constats v2¶

CONSTAT-v2-01¶

Type : Ambiguite Reference : Spec v2 §7.3 table de transitions, §5-N4 etape 4 Description : La table de transitions definit les transitions vers DESTROYED avec le declencheur "Procedure de destruction cryptographique" et la contrainte "Suppression physique/zeroisation de l'artefact obligatoire." Cependant, la specification ne definit pas si la transition vers DESTROYED est automatique (declenchee immediatement apres l'atteinte de l'etat REVOKED/EXPIRED/COMPLETED) ou si elle necessite un processus asynchrone distinct (batch de nettoyage, declenchement manuel). Le flux N4 v2 etape 4 dit "puis a DESTROYED apres suppression physique/zeroisation verifiable", ce qui suggere un delai potentiel entre etat de cloture et DESTROYED. Or, la duree maximale de ce delai n'est pas contractualisee. La section §2.3 point 5 de la spec confirme cette lacune : "Delai maximal entre expiration TTL et destruction effective constatee" est listee comme information manquante. Impact : Un implementeur ne sait pas si la destruction doit etre synchrone (dans la meme transaction que la cloture) ou asynchrone (batch periodique). En mode asynchrone, la ReKey reste dans un etat intermediaire (REVOKED/EXPIRED/COMPLETED mais pas encore DESTROYED) pendant un delai indefini, ce qui maintient un risque residuel de persistance contraire a l'esprit de INV-81-01. La preuve composite (§7.5) reference rekeyLifecycleEvidenceRef qui devrait inclure l'evenement DESTROYED — si la preuve est generee avant DESTROYED, elle est incomplete. Gravite : Majeur

CONSTAT-v2-02¶

Type : Incohérence Spec<>Tests Reference : Spec v2 §7.3 table de transitions vs Tests v2 §2 N4 etape 4 Description : Le flux N4 v2 etape 4 stipule : "Le statut d'acces passe a un statut terminal de cloture (REVOKED ou EXPIRED ou COMPLETED) puis a DESTROYED." Le test N4 v2 verifie : "Statut de cloture dans {REVOKED, EXPIRED, COMPLETED} puis transition vers DESTROYED apres destruction cryptographique verifiable." Or, le test N4 ne specifie pas quel cas de cloture est teste (les 3 declencheurs sont listes en etape 1 : END_OF_CONSULTATION ou revokeReKey). Le test N4 devrait couvrir au moins un chemin precis pour etre deterministe. Les tests L1 (EXPIRED), L2 (COMPLETED), L3 (REVOKED) couvrent chacun un chemin specifique, mais N4 reste ambigu sur lequel il exerce. Impact : Le test N4 risque de faire double emploi avec L1/L2/L3 tout en etant moins deterministe qu'aucun d'entre eux. Un testeur pourrait choisir n'importe quel chemin de cloture, ce qui est acceptable en couverture nominale mais reduit la valeur discriminante de N4. Gravite : Mineur

CONSTAT-v2-03¶

Type : Ambiguite Reference : Spec v2 §5-N4 etape 5, §7.5 LegalCompositeProof, §7.4 anchoringBatchRef Description : Le flux N4 v2 etape 5 dit "Le systeme assemble la preuve composite complete et la rend disponible pour audit." La preuve composite §7.5 contient anchoringEvidenceRef (obligatoire). Or, la frequence d'ancrage est de 24 heures maximum (§3, §10.3). Si la destruction est effectuee et la preuve composite assemblee immediatement apres cloture, l'ancrage de l'evenement LEGAL_REKEY_DESTROYED n'a potentiellement pas encore eu lieu. La specification ne precise pas si l'assemblage de la preuve composite doit attendre l'ancrage complet de tous les evenements, ou si anchoringEvidenceRef peut etre absent/partiel au moment de la generation initiale puis complete ulterieurement. Impact : Un implementeur doit choisir entre : (a) bloquer la generation de preuve composite jusqu'a 24h pour attendre l'ancrage complet, (b) generer une preuve incomplete puis la re-generer apres ancrage, ou © considerer que l'ancrage de destruction sera ajoute a posteriori. Aucune de ces strategies n'est specifiee. Le test L4 v2 verifie "coherence des statuts" mais ne precise pas si l'ancrage de l'evenement DESTROYED est present dans la preuve composite au moment de la verification. Gravite : Majeur

CONSTAT-v2-04¶

Type : Hypothese dangereuse Reference : Spec v2 §3 "END_OF_CONSULTATION", §5-N3 etape 4, §3 "Rate limiting" Description : La definition de END_OF_CONSULTATION prevoit un declenchement par "epuisement du nombre de consultations autorisees explicitement par le mandat." Le rate limiting contractuel est defini a 10 consultations/minute. Ces deux mecanismes de limitation sont independants et potentiellement contradictoires dans leur semantique. Le "nombre de consultations autorisees par le mandat" est un plafond absolu (total), tandis que le rate limiting est un debit instantane (par minute). La spec ne precise pas si le systeme doit compter les consultations totales pour verifier le plafond mandat, ni quel est le compteur de reference (par document, par ReKey, par session). Le modele de donnees LegalReKey (§7.3) ne contient pas de champ de compteur de consultations, ni LegalMandate (§7.1) ne contient de champ "nombre maximal de consultations autorisees." Impact : Si un mandat specifie un plafond de consultations (ex: "3 consultations autorisees"), le systeme ne dispose pas du champ modele pour stocker cette valeur ni pour comptabiliser les consultations effectuees. La condition END_OF_CONSULTATION par epuisement serait non implementable en l'etat du modele de donnees. Le test L2 ne teste que l'action explicite, pas le declenchement par epuisement. Gravite : Majeur

CONSTAT-v2-05¶

Type : Non testable Reference : Spec v2 §10.4, Tests v2 passim Description : L'exigence §10.4 "Toute rupture de chaine probatoire doit etre detectee et faire echouer l'operation concernee" persiste en v2 sans modification. La structure de la chaine probatoire n'est toujours pas definie (pas de hash linking entre evenements successifs dans §7.4). Les evenements ont merkleLeafRef et eventPayloadHashSha3 mais pas de reference au hash de l'evenement precedent. Aucun test ne verifie la detection de rupture de chaine probatoire. Ce constat existait en v1 (CONSTAT-21, mineur) et n'a pas ete corrige car il n'etait pas dans la liste des ecarts a corriger. Impact : L'exigence de detection de rupture reste non testable. Impact limite car l'exigence est dans §10 (contraintes non fonctionnelles) et non dans les invariants/AC testables. Gravite : Mineur

CONSTAT-v2-06¶

Type : Ambiguite Reference : Spec v2 §5-N1 etape 4, §7.1 LegalMandate.scopeDocumentIds[] Description : Le flux N1 v2 etape 4 ajoute [CORRECTION v2] : "puis resout chaque identifiant de mandat vers un documentId interne ProbatioVault." Cependant, le modele LegalMandate §7.1 ne contient qu'un seul champ scopeDocumentIds[] qui est defini comme "obligatoire, non vide." La spec ne precise pas si ce champ contient les identifiants du mandat (avant resolution), les identifiants internes (apres resolution), ou les deux. Si la resolution echoue partiellement (certains identifiants resolus, d'autres non), le flux prevoit un rejet complet (ERR-81-06, fail-closed), ce qui est clair. Mais le modele ne conserve pas la correspondance entre identifiants du mandat et identifiants internes pour auditabilite. Impact : Pour la preuve composite, il pourrait etre necessaire de demontrer que le mapping entre identifiants du mandat et identifiants internes est correct. Sans champ dedie dans le modele, cette tracabilite de mapping n'est pas auditable. Gravite : Mineur

CONSTAT-v2-07¶

Type : Incohérence Spec<>Tests Reference : Tests v2 §1.1 matrice couverture INV vs scenarios Description : La matrice de couverture des invariants (§1.1 tests v2) reference les scenarios suivants pour INV-81-11 (fail-closed sur indisponibilite composant de confiance) : "E13, E14, E15, R1, R2, R3." Cependant, INV-81-11 stipule "En cas d'erreur de validation, incoherence d'etat, ou indisponibilite d'un composant critique de confiance (TSP/HSM/TSA), le systeme refuse l'acces." Les scenarios E13 (echec HSM), E14 (echec TSA), E15 (TSP indisponible) couvrent l'indisponibilite des composants. Les scenarios R1, R2, R3 couvrent les pannes intermittentes. Mais aucun scenario ne couvre explicitement le cas "incoherence d'etat" mentionne par l'invariant. ERR-81-16 (incoherence mandateId) est couvert par E16, mais E16 n'est pas reference dans la couverture de INV-81-11. Impact : Couverture incomplete de INV-81-11 pour le volet "incoherence d'etat." L'ajout de E16 dans la matrice comblerait le trou. Gravite : Mineur

CONSTAT-v2-08¶

Type : Hypothese dangereuse Reference : Spec v2 §3 "Source et verification de bobPublicKey", §9.2 generateLegalReKey Description : La verification de bobPublicKey requiert un "rapprochement d'une identite judiciaire autorisee dans IAM." Cela presuppose que les autorites judiciaires potentielles sont pre-enregistrees dans IAM avec leur cle publique associee. La spec v2 §2.3 point 2 mentionne "Source de verite de l'identite juridique interne (annuaire, registre RH, IAM)" comme information manquante a preciser. La verification de bobPublicKey depend donc d'un referentiel IAM dont la composition et la maintenance sont hors perimetre. Si IAM ne contient pas l'autorite du mandat, la verification echoue systematiquement (fail-closed, ce qui est correct), mais aucun flux d'enrolement des autorites judiciaires n'est prevu dans PD-81. Impact : Le risque est operationnel, pas securitaire (fail-closed protege). Mais un mandat parfaitement valide pourrait etre rejete parce que l'autorite n'est pas connue d'IAM. La spec §2.3 signale honnetement ce point. L'impact est limite car c'est un prerequis d'exploitation, pas une faille de specification. Gravite : Mineur

CONSTAT-v2-09¶

Type : Ambiguite Reference : Spec v2 §5-N2 etapes 1-2, §7.2 LegalValidationCase, §3 "Double validation 2-of-2" Description : La spec v2 definit les etats intermediaires PENDING_DPO/PENDING_LEGAL_OFFICER/PENDING_BOTH. Le flux N2 v2 dit que si les deux validations sont presentes dans validationTtl, l'etat final est ACTIVATED. La spec v2 §5-N2 post-condition mentionne : "sinon REJECTED/EXPIRED selon regles PD-82." Or, la spec PD-82 (§6 ERR-82-02) definit EXPIRED sur depassement TTL et REJECTED sur revocation. La spec PD-81 v2 ne precise pas le comportement si une seule des deux validations est rejetee (signature invalide d'un validateur) sans que l'autre ait ete soumise : l'etat reste-t-il PENDING_X jusqu'a expiration du TTL, ou passe-t-il directement a REJECTED ? ERR-81-08 couvre le cas de meme identite (refus de la 2e), mais pas le cas d'un echec cryptographique de signature d'un validateur (qui est implicitement couvert par PD-82 ERR-82-05 mais sans transition d'etat specifique). Impact : Impact limite car le comportement est implicitement heritable de PD-82 (echec de validation = tentative rejetee, etat inchange, retry possible). Neanmoins, l'absence de mention explicite dans PD-81 des cas d'echec de signature pendant la double validation laisse un trou de specification. Gravite : Mineur

CONSTAT-v2-10¶

Type : Risque secu/conformite Reference : Spec v2 §10.2 "atomicite probatoire des transitions critiques" Description : La spec v2 §10.2 exige "atomicite probatoire des transitions critiques" et §10.5 exige des transitions "deterministes et auditablement reproductibles." La transition ACTIVE -> REVOKED a une borne de 5 secondes. Cela implique que la revocation n'est pas necessairement atomique (transactionnelle) mais peut etre eventuelle (jusqu'a 5s). Pendant ces 5 secondes, une consultation en cours pourrait aboutir sur une ReKey en etat ACTIVE (pas encore propagee comme REVOKED). Le test R6 v2 verifie la concurrence consultation/expiration TTL mais aucun test ne verifie la concurrence consultation/revocation dans la fenetre de 5 secondes. Impact : La fenetre de 5 secondes est un compromis acceptable entre securite et realite technique. Toutefois, l'absence de test de concurrence consultation/revocation dans cette fenetre est un trou de couverture. Un attaquant pourrait exploiter ces 5 secondes pour effectuer des consultations supplementaires apres une revocation demandee. Gravite : Majeur

Synthese v2¶

Ecarts v1 resolus¶

15/15 ecarts v1 resolus. 0 residu. 0 non resolu.

Nouveaux constats v2¶

Comptage v2¶

Synthese par axe¶

1) Ambiguites (4 constats)¶

• CONSTAT-v2-01 : Delai destruction non borne (Majeur)
• CONSTAT-v2-03 : Assemblage preuve composite vs ancrage (Majeur)
• CONSTAT-v2-06 : Tracabilite mapping identifiants (Mineur)
• CONSTAT-v2-09 : Echec validateur, transition non specifiee (Mineur)

2) Contradictions¶

Neant.

3) Regles non testables (1 constat)¶

• CONSTAT-v2-05 : Structure chaine probatoire non definie (Mineur)

4) Incoherences Spec<>Tests (2 constats)¶

• CONSTAT-v2-02 : N4 ambigu sur chemin de cloture (Mineur)
• CONSTAT-v2-07 : INV-81-11 sous-couvert dans matrice (Mineur)

5) Hypotheses dangereuses (2 constats)¶

• CONSTAT-v2-04 : Plafond consultations sans champ modele (Majeur)
• CONSTAT-v2-08 : Enrolement IAM autorites hors perimetre (Mineur)

6) Risques securite / conformite (1 constat)¶

• CONSTAT-v2-10 : Race condition revocation/consultation (Majeur)

Points positifs observes en v2 (hors perimetre de correction)¶

1. Exhaustivite des corrections : Les 15 ecarts v1 (3 bloquants, 12 majeurs) ont tous ete traites avec des marqueurs [CORRECTION v2] clairs et localisables. Aucun ecart n'est laisse sans reponse.
2. Table de transitions : L'ajout d'une table de transitions contractuelles complete dans §7.3 est un apport structurant majeur qui leve l'ambiguite sur le cycle de vie.
3. Taxonomie des evenements probatoires : La liste fermee de 8 types probatoires (§7.4) leve l'ambiguite sur le perimetre TSA.
4. Definition de END_OF_CONSULTATION : La regle metier avec cas par defaut (action explicite seule si pas de plafond mandat) est bien formulee.
5. Borne de 5 secondes pour revocation : Compromis explicite entre "immediat" et realite technique, desormais contractualise.
6. Coherence Spec<>Tests : Les tests v2 ont ete mis a jour en parallele avec la spec (marqueurs [CORRECTION v2] presents dans les deux documents).
7. Transparence sur les lacunes restantes : La section §2.3 "Informations manquantes" a ete mise a jour pour refleter les parametres encore a contractualiser.

Verdict d'auditabilite v2¶

La specification PD-81 v2 presente 0 constat bloquant et 4 constats majeurs :

1. Delai de destruction (CONSTAT-v2-01) : La transition vers DESTROYED est definie mais sa temporalite n'est pas bornee. La spec reconnait ce manque (§2.3 point 5). Risque de persistance residuelle.
2. Preuve composite vs ancrage (CONSTAT-v2-03) : L'assemblage de la preuve composite peut preceder l'ancrage de l'evenement de destruction. Strategie de completude non specifiee.
3. Plafond consultations mandat (CONSTAT-v2-04) : La condition END_OF_CONSULTATION par epuisement est definie mais le modele de donnees ne contient pas les champs necessaires pour l'implementer.
4. Race condition revocation/consultation (CONSTAT-v2-10) : La fenetre de 5 secondes d'invalidation cree un intervalle de concurrence non teste entre consultation et revocation.

Ces 4 majeurs ne bloquent pas l'implementation mais creent des zones d'interpretation qui devront etre tranchees avant recette finale. La specification a progresse significativement entre v1 (score 4.25/10, NON_CONFORME) et v2 (0 bloquant, 4 majeurs, 6 mineurs).