_Assistant_Lead_Tech/knowledge/backend/patterns/general.md

title: Backend — Patterns : Général domain: backend bucket: patterns tags: [auth, helpers, architecture, rbac] applies_to: [implementation, review, architecture] severity: medium validated_on: 2026-04-07 source_projects: [RL799_V2]

Backend — Patterns : Général

Extrait de la base de connaissance Lead_tech. Voir knowledge/backend/patterns/README.md pour l'index complet.

---

Pattern : Helper d'authentification centralisé enrichissable

• Objectif : éviter la duplication de logique RBAC dans chaque service en centralisant un seul requireRoleAccess dans lib/authHelpers.ts.
• Contexte : chaque nouveau service réimplémentait requireRoleAccess localement avec des variations subtiles (certains retournaient { email }, d'autres { email, role }).
• Quand l'utiliser : dès qu'un endpoint nécessite une vérification de rôle ou d'authentification.
• Validé le : 07-04-2026
• Contexte technique : backend / RBAC — RL799_V2 epics 7-8-9

Règle

• Un seul requireRoleAccess dans lib/authHelpers.ts, retournant toutes les infos du token utiles (email, role, sub).
• Quand un service a besoin d'une info supplémentaire : enrichir le helper centralisé, pas le copier.
• Le retour riche est rétrocompatible : les consommateurs existants utilisent ce dont ils ont besoin via destructuring.

Signal review

• Tout service qui importe verifyToken directement ET fait son propre check RBAC est suspect de duplication.

---

Pattern : Extension d'un service existant par type avec RBAC granulaire

• Objectif : éviter la duplication de service quand un nouveau besoin est fonctionnellement identique à un service existant mais avec des restrictions d'accès différentes.
• Contexte : ajout d'un nouveau type de communication (ex: vm) avec restrictions RBAC spécifiques dans un service communications existant.
• Quand l'utiliser : quand le nouveau besoin utilise le même modèle de données et le même CRUD que le service existant, seules les restrictions d'accès changent.
• Quand l'éviter : quand le modèle de données diverge (champs spécifiques au nouveau type) — dans ce cas, un service dédié est préférable.
• Validé le : 08-04-2026
• Contexte technique : backend / architecture — RL799_V2 story 18-7

Règle

Préférer étendre le service avec un nouveau type (enum/Set) et ajuster les restrictions RBAC par type, plutôt que dupliquer le service.

Avantages

• Un seul repository, un seul endpoint, même format de réponse
• Tests existants couvrent la non-régression
• Moins de code à maintenir

Signal review

• Nouveau service qui réplique le CRUD d'un service existant avec un filtre additionnel → candidat à la fusion par type