Aller au contenu

PD-32 — Revue de Code

Résumé

Critère Statut
Patterns NestJS ⚠️
Qualité code ⚠️
Gestion erreurs ⚠️
Maintenabilité ⚠️

Verdict : ⚠️ RÉSERVES

Points positifs

  • Controller fin, service centralise la logique métier (séparation des responsabilités globalement correcte).
  • Usage de DTOs dédiés (UpdateUserProfileDto, UserProfileResponseDto, UserPreferencesDto) avec validations explicites.
  • Journalisation présente sur les parcours principaux (debug/warn/log).
  • Transaction explicite sur la mise à jour profil, limitant le risque de mutation partielle.
  • Champs sensibles marqués @Exclude() dans l’entité.

Points à améliorer

ID Description Fichier Gravité
R-01 Contrat guard non aligné avec code contracts : RateLimitGuard n’est pas explicitement appliqué au controller via @UseGuards(...). src/modules/user/controllers/user-profile.controller.ts MAJEUR
R-02 Schéma preferences implémenté non conforme au contrat PD-32 (clés attendues vs clés présentes différentes). src/modules/user/dto/user-preferences.dto.ts MAJEUR
R-03 sessionTimeout n’a pas de validation de type/borne explicite, contrairement à l’exigence de validation stricte. src/modules/user/dto/user-preferences.dto.ts MAJEUR
R-04 Codes d’erreur renvoyés non alignés avec nomenclature contractuelle ERR-32-* (exemple ERR-32-01). src/modules/user/services/user-profile.service.ts MAJEUR
R-05 Le contrat de sortie API annonce avatar_url; l’implémentation manipule surtout avatarUrl (risque d’incohérence d’exposition JSON). src/modules/user/dto/user-profile-response.dto.ts, src/modules/user/dto/update-user-profile.dto.ts MINEUR
R-06 Logging warn/debug présent, mais absence de error explicite sur erreurs serveur critiques dans le service. src/modules/user/services/user-profile.service.ts MINEUR

Détail par fichier

controller.ts

  • Injection DI correcte et endpoints limités à /user/profile.
  • @UseGuards(JwtAuthGuard) est présent, mais la protection rate limit n’est pas explicitement déclarée au niveau controller contrairement au code contract.
  • Nommage et structure lisibles.

service.ts

  • Bonne séparation logique GET/PUT et transaction sur update.
  • Contrôle RLS visible (SET LOCAL app.current_user_id).
  • Mapping NotFound vers payload d’erreur custom non aligné sur le format contractuel attendu ERR-32-XXX (nomenclature).
  • Logging applicatif présent mais couverture partielle des niveaux de sévérité.

update-user-profile.dto.ts

  • Validation name et avatarUrl bien encadrée (string/maxLength/url https).
  • preferences bien encapsulé via @ValidateNested() + @Type().
  • Contrat de nommage API (avatar_url) vs propriété TS (avatarUrl) potentiellement fragile selon configuration de transformation.

user-profile-response.dto.ts

  • DTO dédié et exposition contrôlée des champs de sortie.
  • preferences toujours présent, cohérent avec le contrat de sortie attendu.
  • Point d’attention sur la cohérence effective du nom de champ JSON avatar_url.

user-preferences.dto.ts

  • Structure DTO propre et lisible.
  • Schéma implémenté (loginNotifications, sessionTimeout, email, push) diverge du schéma contractuel PD-32 (auto_lock_minutes, biometric_enabled, security_alerts, product_updates).
  • Validation incomplète pour sessionTimeout.

user.entity.ts

  • Extension profil claire (name, avatarUrl, preferences).
  • Champs sensibles critiques correctement marqués @Exclude().
  • Aucun pattern interdit évident dans l’extrait.