# Architecture technique

## Vue générale

```mermaid
flowchart TD
    U[Utilisateur RH] --> F[Frontend Next.js]
    F --> B[Backend Next.js API]
    S[Planificateur] --> B
    B --> DB[(MySQL 8)]
    B --> G[Microsoft Entra ID et Graph]
    B --> P[Partage fiches de paie]
    B --> D[(Volume modèles DOCX)]
```

## Composants

### Frontend

- application Next.js et React ;
- navigation entre dashboard et fiches salariés ;
- appels au backend avec cookie SSO ou JWT Bearer ;
- contrôle d’affichage selon les habilitations, complété par les contrôles API.

### Backend

- Route Handlers Next.js sous `src/app/api` ;
- validation des entrées avec Zod ;
- accès MySQL avec Prisma ;
- génération PDF avec PDFKit et LibreOffice ;
- génération DOCX avec Docxtemplater ;
- lecture et découpage des fiches de paie PDF ;
- envoi d’e-mails avec Microsoft Graph ;
- documentation OpenAPI générée à partir de l’inventaire des routes.

### Base MySQL

La base remplace les tables historiques Access. Les migrations Prisma versionnent les évolutions applicatives récentes. Les scripts SQL historiques de migration et de correction restent dans le dépôt pour assurer la traçabilité.

### Planificateur

Le service `alert-mail-scheduler` ne contient pas les règles métier. Il déclenche périodiquement une route interne du backend, protégée par un secret partagé. Le backend sélectionne les alertes, applique les jalons et écrit l’historique.

## Authentification

Deux modes coexistent :

1. connexion locale produisant un JWT ;
2. connexion Microsoft Entra ID produisant une session via cookie `auth_token`.

Les routes utilisent ensuite le même mécanisme de vérification du principal et des permissions.

## Autorisation

L’autorisation comprend deux niveaux :

- permission par module : lecture ou écriture ;
- périmètre de données : établissements, secteurs, catégories et types de contrat.

Le filtrage des salariés est réalisé dans les services backend à partir du profil d’accès authentifié.

## Identifiants salariés

RH Connect conserve deux notions :

- `id` : clé primaire interne utilisée par MySQL et les relations ;
- `COS` : identifiant métier historique utilisé dans les URLs et par l’interface.

Les routes `/api/employes/{cos}` résolvent le salarié grâce au COS. Les relations internes continuent d’utiliser la clé primaire lorsque le schéma le prévoit. Le COS doit donc rester unique et indexé.

## Persistance

| Donnée | Emplacement | Comportement |
|---|---|---|
| données RH | volume Docker `db_data` | persistantes entre les redémarrages |
| modèles DOCX | volume `document_templates_data` | persistants lors de la reconstruction du backend |
| fiches de paie | dossier hôte monté sur `/data/paies` | lecture seule côté application |
| secrets | fichier `.env` ou configuration serveur | jamais dans Git |
| images et polices de procédures | image backend | versionnées avec le code |

## API et documentation

L’inventaire OpenAPI est généré depuis les fichiers `src/app/api/**/route.ts` :

```powershell
cd backend\backend_envie2e
node scripts\generate-openapi-routes.mjs
```

Les schémas métier enrichis restent définis dans `src/lib/swagger.ts`. La protection réelle des routes reste dans les handlers et les fonctions d’autorisation ; Swagger ne remplace pas ces contrôles.

## Dépendances externes

- Microsoft Entra ID : authentification SSO ;
- Microsoft Graph : envoi d’e-mails ;
- partage de fichiers Envie2e Nord : consultation des paies ;
- CDN Swagger UI : affichage de l’interface de documentation en développement.

Une indisponibilité réseau peut donc affecter le SSO, les e-mails ou l’affichage Swagger sans empêcher nécessairement l’accès aux fonctions locales déjà authentifiées.