Aller au contenu principal

Règles backend DMV

Statut​

Document de règles projet — v1.0 — relu le 2026-05-10.

Objectif​

Règles générales applicables à tout développement backend dans l'écosystème DMV, indépendamment du framework.

Règles strictes​

  • Le backend est la seule source de vérité pour les règles métier et les autorisations.
  • Ne jamais exposer de données personnelles, financières ou de sécurité dans les logs ou les réponses d'erreur.
  • Ne jamais faire confiance à une entrée extérieure sans validation — tout input est suspect.
  • Ne jamais stocker de secrets en dur dans le code — utiliser les variables d'environnement.
  • Ne jamais contourner les middlewares d'authentification ou d'autorisation.
  • Ne jamais exposer un endpoint non protégé qui modifie des données.
  • Ne jamais supprimer physiquement des données sans politique de rétention documentée.

Architecture attendue​

  • API JSON pure : toutes les réponses sont en JSON, y compris les erreurs.
  • Stateless : aucune session serveur, authentification par token uniquement.
  • Modules autonomes : chaque module porte ses propres modèles, services, routes.
  • Services métier : la logique applicative vit dans les services, pas dans les contrôleurs ou modèles.

Principes directeurs​

  • Validation à la frontière système (entrée HTTP, webhooks), pas dans les couches internes.
  • Erreurs typées et codes machine stables (pas de messages d'erreur changeants).
  • Réponses paginées pour toutes les listes pouvant dépasser quelques dizaines d'éléments.
  • Jobs asynchrones pour les opérations longues ou les effets de bord non critiques.
  • Cache pour les données fréquemment lues et rarement modifiées.

Recommandations​

  • Documenter les endpoints sensibles et les règles d'accès associées.
  • Tester les cas nominaux ET les cas d'erreur (validation, auth, scope).
  • Monitorer les temps de réponse des endpoints critiques.
  • Journaliser les actions importantes avec contexte (sans données sensibles).
  • Versionner l'API (/api/v1/) dès le début.

Anti-patterns à éviter​

  • Logique d'autorisation dans la base de données côté application (sauf RLS Supabase).
  • Endpoints qui font trop de choses à la fois (violer le principe de responsabilité unique).
  • Réponses incohérentes (parfois JSON, parfois HTML).
  • Pas de gestion d'erreur → retourner 500 sans contexte.
  • Migrations irréversibles sans stratégie de rollback.