# Contexte backend

Ce document décrit le rôle du backend, ses responsabilités et ses choix techniques.
Tout ce qui est indiqué ici est la référence pour les agents backend.

---

## Légende des zones
- `<A REMPLIR - PROJET> (exemple: à personnaliser — a supprimer)` : à compléter par toi selon le projet.
- `<A COMPLETER PAR AGENT>` : à compléter par un agent spécialisé backend.

---

## Objectif du backend
- Problème métier couvert : <A REMPLIR - PROJET> (exemple: suivi manuel sur tableur — a supprimer)
- Responsabilités principales : <A COMPLETER PAR AGENT>
- Hors périmètre : <A REMPLIR - PROJET> (exemple: à personnaliser — a supprimer)

## Interfaces
- API publique (API = Interface de Programmation) : <A COMPLETER PAR AGENT>
- Authentification/autorisation : <A COMPLETER PAR AGENT>
- Intégrations externes : <A REMPLIR - PROJET> (exemple: ERP existant — a supprimer)

## Données
- Base(s) utilisée(s) : <A COMPLETER PAR AGENT>
- Modèle de données clé : <A COMPLETER PAR AGENT>
- Stratégie de migration : <A COMPLETER PAR AGENT>

## Architecture interne
- Style (monolithe modulaire, hexagonal, etc.) : <A COMPLETER PAR AGENT>
- Modules principaux : <A COMPLETER PAR AGENT>
- Couche d’accès aux données : <A COMPLETER PAR AGENT>

## Qualité & exploitation
- Observabilité (logs/metrics/traces = journaux/mesures/traces) : <A COMPLETER PAR AGENT>
- Tests (unitaires/intégration) : <A COMPLETER PAR AGENT>
- Performance attendue : <A REMPLIR - PROJET> (exemple: à personnaliser — a supprimer)

## Conventions
- Organisation du code : <A COMPLETER PAR AGENT>
- Nommage : <A COMPLETER PAR AGENT>
- Gestion erreurs : <A COMPLETER PAR AGENT>

---

## Exemple (a supprimer)
- Style : monolithe modulaire avec modules `users`, `billing`, `catalog`.
- API : REST `/api/v1` + JWT (Jeton d’authentification).
- DB : PostgreSQL, migrations via outils natifs.