PD-82 — Rétrospective¶

1. Contexte¶

2. Métriques¶

3. Learnings clés¶

• State machines explicites : Préférer des state machines explicites aux conditions imbriquées pour les workflows complexes. Pattern TransitionResult { newState, isActivation, isTerminal }.

• Transactions SERIALIZABLE : Pour les opérations critiques (validation 2-of-2), le niveau d'isolation SERIALIZABLE est nécessaire malgré le coût performance.

• Validation eIDAS : Les niveaux substantial/high doivent être capturés au moment de la signature, pas inférés après.

• TypeScript strict mode et DTOs : Les DTOs avec class-validator décorateurs nécessitent le modificateur ! (definite assignment assertion).

• ESLint security/detect-object-injection : Remplacement des accès par clé dynamique (obj[key]) par des switch statements explicites.

4. Patterns applicables¶

Nouveau pattern : State machine pour workflow 2-of-2¶

interface TransitionResult {
  newState: DualValidationState;
  isActivation: boolean;  // PRE activé
  isTerminal: boolean;    // Workflow terminé
}

@Injectable()
export class DualValidationStateMachineService {
  private readonly transitions: Record<DualValidationState, Partial<Record<DualValidationAction, TransitionResult>>> = {
    [DualValidationState.PENDING]: {
      [DualValidationAction.PARENT_APPROVE]: {
        newState: DualValidationState.PARENT_APPROVED,
        isActivation: false,
        isTerminal: false,
      },
      [DualValidationAction.AUTHORITY_APPROVE]: {
        newState: DualValidationState.AUTHORITY_APPROVED,
        isActivation: false,
        isTerminal: false,
      },
    },
    [DualValidationState.PARENT_APPROVED]: {
      [DualValidationAction.AUTHORITY_APPROVE]: {
        newState: DualValidationState.FULLY_APPROVED,
        isActivation: true,  // 2-of-2 validé
        isTerminal: true,
      },
    },
    // ...
  };

  transition(currentState: DualValidationState, action: DualValidationAction): TransitionResult {
    const result = this.transitions[currentState]?.[action];
    if (!result) {
      throw new InvalidStateTransitionException(currentState, action);
    }
    return result;
  }
}

Pattern confirmé : Séparation responsabilités validation¶

// Transitions pures (testable unitairement)
DualValidationStateMachineService

// Orchestration business (intégration services)
DualValidationService

// Crypto (signature X.509, eIDAS)
SignatureVerificationService

// Horodatage (TSA RFC 3161)
TsaClientService

5. Signal CLAUDE.md¶

Priorité moyenne : Pattern state machine pour workflows 2-of-N.

### NestJS — State machine pour workflows multi-validation (2026-02-XX)

**Contexte** : Workflows nécessitant N validations (2-of-2, 3-of-5, etc.).

**Pattern** :
```typescript
interface TransitionResult {
  newState: State;
  isActivation: boolean;  // Action déclenchée
  isTerminal: boolean;    // Workflow terminé
}

const transitions: Record<State, Partial<Record<Action, TransitionResult>>> = { ... };

Bénéfices : - Transitions déterministes et testables - Invariants vérifiables formellement - Code lisible et maintenable

Réutilisable pour : PD-41 (PRE activation), workflows d'approbation. ```

6. Conclusion¶

PD-82 a livré le module DualValidation complet avec state machine, service de signature X.509/eIDAS, client TSA stub, et controller REST. Les 3 gates GO direct (sans itération) démontrent l'efficacité d'une architecture state machine bien définie. Le pattern est réutilisable pour tout workflow multi-validation (2-of-N, approval chains).

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