PD-41 — Rétrospective¶

1. Contexte¶

2. Métriques¶

3. Learnings clés¶

• Formats normés accélèrent l'implémentation : L'annexe 11 (formats PRE-1.0) a éliminé toute ambiguité sur les structures attendues et permis une implémentation directe.

• Fail-closed systématique pour crypto : Aucun résultat partiel en cas d'erreur ; rejets explicites avec codes normatifs. Cette approche a prévenu les fuites accidentelles.

• Testabilité à évaluer dès la spécification : TC-ERR-06 (erreur interne Umbral) n'était pas testable de manière déterministe. Cette limite aurait dû être identifiée plus tôt.

• Invariants explicites facilitent la revue : La matrice de couverture INV → TC → code a permis une vérification systématique de la conformité.

• Séparer provider crypto de logique métier : L'abstraction UmbralProvider a permis d'isoler la dépendance externe et faciliter les tests avec mock.

4. Patterns applicables¶

Pattern existant : Architecture modulaire crypto¶

src/modules/crypto/pre/
├── pre.service.ts           # Facade métier
├── umbral.provider.ts       # Abstraction bibliothèque externe
├── umbral-mock.provider.ts  # Mock pour tests
├── validators/
│   ├── context.validator.ts
│   └── size-limit.validator.ts
└── dto/
    ├── re-key.dto.ts
    └── capsule.dto.ts

Nouveau pattern : Whitelist de champs pour logs¶

const ALLOWED_LOG_FIELDS = [
  'operationType',
  'contextId',
  'timestamp',
  'success',
  'errorCode',
] as const;

sanitizeForLog(data: any): Partial<typeof data> {
  return Object.fromEntries(
    Object.entries(data).filter(([key]) =>
      ALLOWED_LOG_FIELDS.includes(key)
    )
  );
}

Nouveau pattern : Limites de taille multi-niveaux¶

interface SizeLimits {
  maxFieldLength: number;      // Niveau champ individuel
  maxArtifactLength: number;   // Niveau artefact (ReKey, Capsule)
  maxRequestLength: number;    // Niveau requête HTTP
  maxCardinality: number;      // Nombre d'éléments
}

validatePreRequest(request: PreRequest): void {
  // Pré-validation AVANT décodage base64
  this.validateFieldSizes(request);
  this.validateCardinality(request);
  // Décodage et validation détaillée
  const decoded = this.decodeBase64(request);
  this.validateArtifactSizes(decoded);
}

5. Signal CLAUDE.md¶

Priorité moyenne : Définir la whitelist logs dès la spécification.

### Whitelist Logs — Spécification initiale (2026-02-XX)

Pour toute US manipulant des données sensibles, inclure dans la spec :

**Section "Annexe C : Champs autorisés en logs"**
- Liste exhaustive des champs loggables
- Inclure `operationType` et champs métier utiles
- Tout champ non listé = interdit en logs

L'écart E-01 (PD-41) aurait été évité si cette liste avait été exhaustive dès le départ.

6. Conclusion¶

PD-41 a livré le service PRE NuCypher/Umbral avec formats PRE-1.0 normés et 8 invariants de sécurité. Les écarts E-01 (whitelist logs) et E-02 (hypothèse H-05) ont révélé l'importance de documenter exhaustivement les champs autorisés et les hypothèses d'architecture. Le pattern "abstraction provider crypto" permet le remplacement de bibliothèque sans impact API.

Rétrospective générée 2026-02-19 (Étape 10 batch crypto-proof)