# Sécurité et confidentialité

Statut: référence opérationnelle  
Public: exploitants, sysadmin, mainteneurs, exécutifs  
Dernière révision: 2026-06-01

## Principes

L'application doit minimiser les données personnelles, isoler les groupes et permettre au groupe de comprendre qui a changé quoi. Le journal ne sert pas à surveiller les membres; il sert à protéger l'historique et corriger les erreurs.

## Authentification

- Connexion par groupe, identifiant/courriel et PIN à 4 chiffres.
- PIN haché côté serveur.
- Session JWT.
- Durée normale: 30 jours.
- Durée avec `Se souvenir de moi`: 90 jours.
- Un membre inactif ne peut pas se connecter.

## Sysadmin

Le compte `Sysadmin`:

- existe au déploiement initial;
- a tous les accès;
- ne doit pas être supprimé;
- peut impersonifier un membre;
- peut gérer les groupes;
- doit être utilisé avec retenue.

Le PIN initial `0000` doit être changé ou encadré selon la politique du groupe après installation réelle.

## Impersonification

Quand Sysadmin agit comme un autre membre, le jeton conserve l'identité sysadmin dans `adm`. La journalisation peut donc distinguer:

- le membre au nom duquel l'action est faite;
- le sysadmin qui a causé l'action.

## Autorisations

Les accès ordinaires viennent:

- des postes actifs;
- des permissions de modules associées aux postes;
- de la catégorie `executif`.

Le frontend masque les modules non visibles, mais le backend doit toujours vérifier l'autorisation.

## Isolation multi-groupe

Chaque lecture ou modification doit être bornée au `groupe_id` du membre courant. Une route qui reçoit un identifiant doit vérifier l'appartenance de l'objet au groupe courant.

Voir [Multi-groupe](93_MULTI_GROUPE.md).

## Journalisation

Sont journalisées automatiquement:

- méthodes `POST`, `PUT`, `PATCH`, `DELETE`;
- routes sous `/api/`;
- actions réussies;
- membre;
- sysadmin d'origine si impersonification;
- chemin;
- statut HTTP;
- IP;
- user-agent;
- paramètres sûrs.

L'historique métier peut conserver:

- domaine;
- objet;
- ancienne valeur;
- nouvelle valeur;
- raison automatique;
- membre responsable.

## Données personnelles

Données membres typiques:

- prénom;
- nom optionnel;
- téléphone;
- identifiant/courriel;
- date d'abstinence optionnelle;
- PIN haché;
- préférences de notifications.

Le prénom est conservé lors du droit à l'oubli afin que l'historique reste lisible.

## Droit à l'oubli

Le droit à l'oubli ne supprime pas l'enregistrement du membre. Il anonymise:

- nom;
- téléphone;
- courriel ou identifiant de connexion;
- date d'abstinence;
- PIN;
- préférences;
- abonnements push.

Sont conservés:

- ID technique;
- prénom;
- relations historiques.

## Notifications push

Les notifications sont opt-in. Le membre choisit les catégories. Le navigateur peut refuser ou bloquer les notifications.

Les catégories applicatives sont:

- gouvernance;
- trésorerie;
- membres;
- postes;
- rencontres;
- littérature;
- événements;
- système.

## Secrets

Les secrets ne doivent pas être committés en clair.

Secrets principaux:

- mot de passe PostgreSQL applicatif;
- secret JWT;
- variables de notification push si utilisées;
- accès SSH Ansible.

Le fichier `ansible/group_vars/vault.yml` doit être chiffré avec Ansible Vault lorsqu'il contient des valeurs réelles.

## Sauvegardes

Les sauvegardes PostgreSQL doivent être protégées comme des données personnelles. Elles contiennent l'historique complet du groupe.

## Points de fracture

Risques principaux:

- mauvais groupe sélectionné à la connexion;
- utilisation prolongée de `Sysadmin`;
- permissions trop larges accordées à un poste;
- sauvegardes non testées;
- perte d'accès au serveur;
- conflit social autour du journal;
- absence de reprise papier.

Mesures:

- vérifier régulièrement les permissions;
- imprimer ou savoir produire les rapports clés;
- tester les sauvegardes;
- expliquer le rôle du journal;
- garder l'application comme outil, pas comme autorité.