Aller au contenu

PD-42 — Retour d'experience (REX)

1. Resume executif

Objectif initial : Definir et implementer un mecanisme de recherche deterministe sur keywords tokenises (primitive cryptographique client), permettant l'execution de requetes cote serveur sans acces aux keywords en clair (zero-knowledge contractuel).

Resultat obtenu : Module client src/crypto/search/ fonctionnel avec 70 tests PASS (Canonicalizer, KeyDeriver, Tokenizer). Les composants serveur (MetadataValidator, SearchIndex, TokenStorage) sont specifies dans le plan mais implementes dans PD-236.

Verdict d'acceptabilite : - 2026-01-24 : REFUSE (E-01 bloquant, E-02 majeur) - 2026-01-25 : ACCEPTE (E-01/E-02 resolus par delegation formalisee a PD-236)

Etat des tests contractuels : - Tests client (PD-42) : 70/70 PASS - Tests serveur (PD-236) : 135/135 PASS - Vecteurs deterministes VEC-01, VEC-02, VEC-03 : PASS

2. Points fluides

  1. Specification canonique solide : La structure en invariants (INV-01..05), criteres d'acceptation (CA-01..05), parametres contractuels (4.1..4.5) et cas d'erreur (ERR-01..05) a fourni un referentiel non ambigu.

  2. Vecteurs de test deterministes : Les 3 vecteurs VEC-01/02/03 avec valeurs hexadecimales intermediaires (K_search, HMAC-SHA256, b64url) ont permis une validation cryptographique bit-a-bit.

  3. Decoupage client/serveur explicite : La separation des responsabilites (client = tokenisation, serveur = stockage/recherche) a permis un developpement parallele avec PD-236.

  4. Tests contractuels automatisables : La formulation Given/When/Then des scenarios TC-* a permis une transposition directe en tests vitest.

  5. Hors-perimetre explicite : L'enumeration des elements hors-perimetre (full-text, fuzzy, frequence, dictionnaire) a clarifie les attentes et evite les debats lors de la revue.

3. Points difficiles

  1. Ambiguite plan/code sur les composants serveur : Le plan d'implementation (§4.4-4.6) decrivait des modules serveur (MetadataValidator, SearchIndex, TokenStorage) sans preciser qu'ils etaient hors-scope du code PD-42. Cela a conduit a l'ecart E-01 (bloquant).

  2. Hypotheses supplementaires non prevues : Les hypotheses H-04 a H-09 ont ete introduites dans le plan et la matrice de couverture, au-dela des H-01 a H-03 contractuels de la spec. Cela a conduit a l'ecart E-02 (majeur).

  3. Coordination inter-repos : La primitive PD-42 (app) et sa consommation PD-236 (backend) ont ete developpees dans des repos distincts, necessitant une synchronisation sur les contrats d'interface.

  4. Checklist de livraison client/serveur melee : La checklist §14 originale melangeait items client et serveur sans distinction, masquant l'etat reel de completude.

4. Hypotheses revelees tardivement

ID Hypothese Decouverte
H-04 Bibliotheque crypto conforme (HKDF, HMAC-SHA256) Prerequis implicite client, explicite lors de la revue plan
H-05 Implementation Unicode NFC disponible et conforme UAX #15 Prerequis implicite client, explicite lors de la revue plan
H-06 Base64 URL-safe sans padding disponible Decouvert comme hypothese serveur, delegue a PD-236
H-07 Comparaison byte-to-byte sans normalisation cote serveur Decouvert comme hypothese serveur, delegue a PD-236
H-08 Stockage supporte VARCHAR(22) Decouvert comme hypothese serveur, delegue a PD-236
H-09 user_id gere cote serveur (contexte auth) Decouvert comme hypothese serveur, delegue a PD-236

Impact : Ces hypotheses ont ete integrees a la spec §10 et au plan §10.2 lors de la correction de E-02.

5. Invariants complexes

ID Complexite Mecanisme Test(s) Risque residuel
INV-01 Faible HMAC-SHA256 est une PRF deterministe TC-NOM-01, TC-NR-01 Aucun (propriete mathematique)
INV-02 Faible Resistance aux collisions HMAC-SHA256 dans l'espace nominal TC-NOM-03 Collision theorique (2^-132)
INV-03 Elevee API serveur n'accepte que T_kw + metadonnees TC-NOM-06, TC-NEG-01 Ajout futur d'un champ "keyword" par erreur
INV-04 Moyenne HKDF derive K_search par K_master_user ; scope USER TC-NOM-05 Partage accidentel de K_master_user
INV-05 Faible Comparaison byte-to-byte sur T_kw TC-NOM-04 Normalisation serveur non desiree

Note : INV-03 (zero-knowledge serveur) est l'invariant le plus sensible ; sa verification repose sur des tests d'inspection probatoire (TC-NOM-06) implementes dans PD-236.

6. Dette technique

Element Description Criticite Impact
Documentation API Non produite (checklist §14.3) Faible Documentation a completer
Tests d'integration client/serveur Pas de tests end-to-end croises PD-42/PD-236 Moyenne Regression possible a l'interface
Corpus Unicode diversifie Tests canonicalisation limites aux cas basiques Faible Cas limites Unicode non couverts

7. Risques residuels

Risque Probabilite Impact Mitigation actuelle
Attaque par frequence/dictionnaire Accepte Moyen Hors perimetre (spec §2.2)
Collision fonctionnelle Tres faible Eleve 132 bits (2^-132), monitoring
Reindexation apres rotation K_master_user Certaine Eleve Procedure documentee (plan §9.3)
Derive de l'interface client/serveur Faible Moyen Contrat fige par algorithm_id/canonicalization_id

8. Ameliorations de processus

  1. Expliciter la delegation inter-US des le plan : Lorsqu'un plan d'implementation decrit des composants implementes dans une autre US, ajouter une note de delegation explicite des la redaction initiale (pas en correction).

  2. Separer les hypotheses client/serveur dans la spec : Distinguer H-xx client (environnement d'execution) et H-xx serveur (delegues a une autre US) pour eviter l'ambiguite.

  3. Structurer la checklist par repo/US : Organiser la checklist de livraison avec des sous-sections explicites par responsable (PD-42 client, PD-236 serveur) pour visualiser l'etat reel.

  4. Revue croisee des plans avant implementation : Lorsqu'une US depend d'une autre (PD-42 → PD-236), effectuer une revue croisee des plans pour verifier la coherence des interfaces.

  5. Inclure les references de delegation dans les References : Ajouter systematiquement une section "Delegation" dans les References pointant vers les US dependantes.

9. Enseignements cles

  1. La delegation doit etre explicite et tracable : Un ecart BLOQUANT (E-01) a ete resolu par l'ajout de notes de delegation formelles dans le plan. La traçabilite plan → code doit couvrir les delegations, pas seulement le code local.

  2. Les hypotheses supplementaires doivent etre integrees a la spec : Les hypotheses revelees en cours d'implementation (H-04..H-09) ont ete retro-integrees a la spec §10 pour maintenir la coherence contractuelle.

  3. Le verdict peut evoluer sans reexecution des tests : Le passage de REFUSE a ACCEPTE entre le 24 et le 25 janvier a ete obtenu par correction documentaire (delegation, hypotheses), les 70 tests client etant deja PASS.

  4. La coordination multi-repos necessite des contrats d'interface figes : Les identifiants normatifs (algorithm_id, canonicalization_id, k_search_scope) servent de contrat stable entre PD-42 (client) et PD-236 (serveur).

  5. Le hors-perimetre protege le perimetre : L'enumeration explicite des elements hors-perimetre (frequence, dictionnaire, full-text) a evite les derives de scope et clarifie les attentes de la revue d'acceptabilite.