PD-32 — Rétrospective¶

1. Contexte¶

2. Métriques¶

3. Learnings clés¶

• Format d'erreur NestJS : Par défaut, NestJS retourne {statusCode, message, error}. La spec exigeait {error, message}. Résolu avec ProfileExceptionFilter.

• Test erreur 500 : Impossible en e2e sans mock. Résolu avec overrideProvider().

• Validation stricte ChatGPT : Ne pas proposer de "déviation acceptable" sans justification solide. ChatGPT refuse les déviations non justifiées.

• class-validator avec whitelist : Rejet automatique des champs non autorisés.

4. Patterns applicables¶

Pattern existant : RLS via RlsQueryService¶

Pattern éprouvé réutilisé de PD-16.

Nouveau pattern : ExceptionFilter dédié par domaine¶

Pour garantir le format d'erreur contractuel :

@Catch(ProfileException)
export class ProfileExceptionFilter implements ExceptionFilter {
  catch(exception: ProfileException, host: ArgumentsHost) {
    const response = host.switchToHttp().getResponse<Response>();
    response.status(exception.status).json({
      error: exception.errorCode,
      message: exception.message,
    });
  }
}

5. Signal CLAUDE.md¶

Priorité moyenne : Créer un BaseExceptionFilter réutilisable.

### ExceptionFilter — Format contractuel (2026-02-XX)

Chaque domaine fonctionnel nécessitant le format `{error, message}` doit avoir son propre filter.

**Template** : `src/common/filters/base-contract-exception.filter.ts`

**Alternative** : Créer un `BaseExceptionFilter` générique paramétré par le préfixe d'erreur (ERR-32-*, ERR-238-*, etc.).

6. Conclusion¶

PD-32 a livré les endpoints profil utilisateur après 3 itérations de Gate CLOSURE. Les validations croisées Claude/ChatGPT ont identifié des écarts que Claude avait manqués (format d'erreur, tests manquants). Le pattern ExceptionFilter dédié est désormais la norme pour le format contractuel des erreurs.

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