# 10. Exploitation et déploiement

## Ce qui constitue une version exploitable

- commit/tag Git identifié ;
- images construites depuis ce commit ;
- `.env.production` cohérent ;
- migrations ou import SQL appliqués et tracés ;
- volume MySQL ;
- volume des modèles documentaires ;
- montage des paies ;
- configuration Entra/Graph/Caddy/DNS.

## Déploiement applicatif standard

```bash
git fetch origin --prune
git switch main
git pull --ff-only origin main
docker compose --env-file .env.production \
  -f docker-compose.yml -f docker-compose.prod.yml \
  build
docker compose --env-file .env.production \
  -f docker-compose.yml -f docker-compose.prod.yml \
  up -d
```

Pour forcer la recréation d’un composant après changement d’environnement :

```bash
docker compose --env-file .env.production \
  -f docker-compose.yml -f docker-compose.prod.yml \
  up -d --force-recreate backend alert-mail-scheduler frontend
```

## Bascule de base

Préférer une nouvelle base nommée à l’écrasement de la base courante : importer la candidate dans `app_db_prod_<date>`, valider, changer `MYSQL_DATABASE`/`DATABASE_URL`, recréer le backend et conserver l’ancienne base le temps de la recette. Le guide détaillé est dans `exploitation/guide-mise-en-production-linux.txt`.

## Sauvegardes

| Élément | Fréquence minimale | Rétention indicative | Test |
|---|---|---|---|
| MySQL | quotidienne + avant déploiement | politique DSI | restauration mensuelle |
| Modèles DOCX | quotidienne + avant import massif | alignée avec MySQL | extraction + génération |
| Paies | selon source DSI | politique légale/DSI | présence et lecture contrôlée |
| Configuration | à chaque changement | versions chiffrées/coffre | reconstruction d’un environnement |

Le dump MySQL et l’archive de modèles doivent pouvoir être rapprochés temporellement.

## Supervision simple

```bash
docker compose ps
docker compose logs --since=30m backend
docker compose logs --since=30m alert-mail-scheduler
docker stats --no-stream
df -h
```

Surveiller : redémarrages, erreurs Prisma, erreurs Graph, stockage indisponible, espace disque, lenteurs, échec SSO, absence de passage scheduler et erreurs 5xx.

## Recette après déploiement

1. `/api/health` répond.
2. SSO fonctionne avec le callback prod.
3. Un compte limité ne voit que ses scopes.
4. La liste et le compteur d’actifs sont cohérents.
5. Une fiche salarié et ses onglets se chargent.
6. Un document de test est généré.
7. Une fiche de paie de test est extraite.
8. Swagger est exposé ou désactivé selon décision.
9. Le scheduler est dans le mode prévu.
10. Les logs ne présentent pas d’erreur répétée.

## Retour arrière

Un rollback de code ne suffit pas si le schéma a changé. Conserver : commit précédent, images précédentes si possible, ancienne base, dump avant bascule, archives de volumes et ancien `.env.production`. Pour une bascule blue/green, repointer vers l’ancienne base et recréer les services est le retour arrière le plus rapide.