# Template — Document d’implémentation technique par zone

Ce template définit la structure d’un document d’implémentation technique pour une zone fonctionnelle. Les sections 2 et 3 s’appuient sur [REFERENTIEL_ECRANS_ACTIONS.md](../REFERENTIEL_ECRANS_ACTIONS.md) pour la liste des identifiants d’écrans et des actions 18.x, et sur la SPEC correspondante pour les règles métier et les endpoints.

---

# Implémentation technique : [Nom de la zone]

**Zone** : [N°] — [Titre]  
**Spec fonctionnelle** : [lien vers SPEC_xx]  
**Référentiel** : [lien REFERENTIEL section zone]

## 1. Vue d’ensemble

- Périmètre technique (front, back, BDD, paramétrage) de la zone.
- Dépendances (autres zones, clients externes).

## 2. Écrans (détail technique)

Pour chaque écran du référentiel (identifiant stable) :

### [identifiant stable] — [Nom écran]

- **Route(s)** : chemin(s) front (ex. `app/(auth)/login/page.tsx`, route Next.js ou équivalent).
- **Front** :
  - Page / composant principal (fichier, rôle).
  - Composants enfants (liste ou arbre court).
  - State : local (useState/useReducer) ou global (store/context), données chargées.
  - Appels API : méthode, endpoint, moment (mount, submit, etc.), mapping réponse.
  - Validation : côté client (WASM ou utils), champs concernés, messages d’erreur (i18n).
  - Paramétrage : clé `screen_config` (identifiant stable), effet sur visibilité/ordre.
- **Back** :
  - Handler(s) : fichier, route HTTP, extraction params/body, appel service, retour JSON/erreur.
  - Service(s) : logique métier, appels repository et/ou clients externes.
  - Repository / modèle : tables, requêtes principales (lecture/écriture).
- **BDD** : tables et colonnes concernées (rappel si déjà dans ARCHITECTURE_DOCV_DETAILLEE).
- **Paramétrage** : identifiant stable pour `screen_config`, conditions d’affichage.

(Répéter le bloc pour chaque écran de la zone.)

## 3. Actions (mapping technique)

Table synthétique : pour chaque action 18.x de la zone, le déclencheur UI, l’appel API ou l’action locale, le handler/service back, et la validation ou contrainte éventuelle.

| Action | Déclencheur (UI) | Appel / action | Back (handler, service) | Validation / erreur |
|--------|------------------|----------------|-------------------------|----------------------|
| 18.x   | Bouton/lien/form | GET/POST/… endpoint | handler → service → repo | règle métier, message |

## 4. Points d’attention

- Erreurs typées, pas de fallback silencieux.
- Clients externes (ancrage, IA) : uniquement côté back, depuis quels services.
- i18n : clés utilisées pour libellés et messages d’erreur.