# 01 — Rôles et droits

## Modèle d'accès

Site **multi-utilisateur à cercle restreint**. Pas d'inscription libre : les comptes sont créés
par le **Super Admin** (via l'interface `/admin/users` ou le script `create-user`).

## Rôles (3 niveaux)

| Rôle          | Description                                                                       |
|---------------|-----------------------------------------------------------------------------------|
| `super_admin` | Tout pouvoir : gère la **configuration** et les **comptes** + agenda/mail. (Guillaume.Lion) |
| `admin`       | Peut **ajouter et modifier** l'agenda et les mails (lecture + écriture). Pas de gestion comptes/config. |
| `user`        | **Consultation seule** de l'agenda et des mails (lecture). Aucune modification.   |

### Matrice des capacités

Implémentée dans `backend/src/lib/permissions.ts` (`ROLE_CAPABILITIES`). Les endpoints vérifient
une **capacité** (`requireCapability`) plutôt qu'un rôle en dur.

| Capacité          | super_admin | admin | user |
|-------------------|:-----------:|:-----:|:----:|
| `config:manage`   | ✅          | ❌    | ❌   |
| `users:manage`    | ✅          | ❌    | ❌   |
| `agenda:read`     | ✅          | ✅    | ✅   |
| `agenda:write`    | ✅          | ✅    | ❌   |
| `mail:read`       | ✅          | ✅    | ✅   |
| `mail:write`      | ✅          | ✅    | ❌   |
| `drive:read`      | ✅          | ✅    | ✅   |
| `drive:write`     | ✅          | ✅    | ❌   |
| `whatsapp:read`   | ✅          | ✅    | ✅   |
| `whatsapp:write`  | ✅          | ✅    | ❌   |

> Garde-fou : impossible de rétrograder/désactiver/supprimer le **dernier super_admin** actif
> (anti-verrouillage), et un super_admin ne peut pas supprimer son propre compte.

### Impersonation (« Se connecter en tant que »)
Le Super Admin peut, depuis `/admin/users`, ouvrir une session **en tant qu'un autre utilisateur**
(pour vérifier ce que voit un admin/user). Le jeton JWT porte alors un claim `imp` = id du Super
Admin d'origine ; un **bandeau** permet de « revenir à mon compte » (`POST /auth/stop-impersonation`).
Pendant l'impersonation, l'utilisateur a **exactement les droits du compte cible** (un admin usurpé
ne peut donc pas gérer les comptes). Endpoint : `POST /users/:id/impersonate` (capacité
`users:manage`). Action journalisée côté serveur.

## Modèle « compte partagé » (important)

Contrairement à un modèle « chacun son compte », **toutes les données externes appartiennent au
Super Admin** (le « propriétaire ») : **un seul compte Google** (agenda, mail, Drive) et **un seul
téléphone** suivi. Les admins/users consultent — et, selon leurs droits, modifient — les données
**du Super Admin**.

- `super_admin` : connecte/gère le compte Google (`/settings`), gère les appareils de localisation,
  les comptes (`/admin/users`) et la configuration. Voit et modifie tout.
- `admin` : voit **et modifie** l'agenda, les mails et les Documents du Super Admin ; voit la
  localisation. Ne gère **ni** la connexion Google, **ni** les appareils, **ni** les comptes.
- `user` : **lecture seule** de l'agenda, des mails, des Documents et de la localisation du Super Admin.

Implémentation : `backend/src/lib/data-owner.ts` (`getDataOwnerId` = le super_admin actif le plus
ancien) ; les modules Google utilisent `getOwnerGoogleClient()` ; le tracking lit les appareils du
propriétaire.

## Authentification

- **Connexion au site** : **nom d'utilisateur + mot de passe** (hash bcrypt), session par **JWT**
  (access + refresh) via cookies httpOnly. Pas de « Se connecter avec Google » (décidé 2026-06-06).
- **Changement de mot de passe** : en libre-service via `/profile` (`POST /auth/password`,
  vérifie le mot de passe actuel). Le Super Admin peut aussi réinitialiser le mot de passe d'un
  compte depuis `/admin/users`.
- **Liaison Google** : OAuth 2.0 séparé du login site. Un utilisateur connecté lie ensuite son
  compte Google (le site stocke un *refresh token* chiffré). Voir
  [05_INTEGRATION_GOOGLE.md](05_INTEGRATION_GOOGLE.md).

## Sécurité des accès sensibles

- Tokens OAuth Google **chiffrés au repos** (clé `LEPERELION_ENCRYPTION_KEY`).
- Données de position et contenu mail considérés comme **sensibles** : accès journalisé,
  transport en HTTPS uniquement, jamais exposés à un autre utilisateur.