Utilisateurs

Un utilisateur dans Liberty est l'identité qui se connecte et porte des rôles. L'onglet Paramètres → Accès → Utilisateurs est l'endroit où créer les utilisateurs locaux, voir les utilisateurs OIDC qui se sont connectés au moins une fois, attribuer les rôles et basculer les drapeaux actif et superutilisateur.

La même interface gère les deux backends d'identité (TOML / DB) et les deux sources d'identité (locale / OIDC). Les différences portent sur les champs modifiables : les utilisateurs OIDC n'ont pas de mot de passe (il est chez l'IdP) et leur champ provider est en lecture seule.

---

L'onglet Utilisateurs

Chaque carte affiche le nom d'utilisateur (monospace), le nom complet, le courriel, le fournisseur (local / oidc), les pastilles de statut et les rôles attribués.

Pastille	Signification
superutilisateur (orange)	is_superuser = true — passe outre chaque vérification de permission.
inactif (rouge)	is_active = false — l'utilisateur ne peut pas se connecter. Ses sessions existantes s'arrêtent au prochain rafraîchissement de jeton.
Aucun rôle (atténué)	Aucun rôle attribué et pas de superutilisateur — l'utilisateur se connecte mais ne voit rien.
Noms de rôles (violet)	Chaque rôle attribué, une pastille par rôle.

---

Ajouter un utilisateur local

Cliquer sur ＋ Ajouter un utilisateur. L'éditeur d'utilisateur s'ouvre avec chaque champ vide.

Champs

Champ	Requis	Notes
Nom d'utilisateur	oui	Lettres, chiffres, soulignés, points et tirets. Sert d'identifiant de connexion, de sujet JWT et d'identité d'audit. Immuable après création.
Nom complet	non	Le nom d'affichage montré dans les en-têtes et les colonnes d'audit.
Courriel	non	Adresse destinataire pour les invitations, la réinitialisation de mot de passe (quand implémentée) et les routes de notification.
Mot de passe	oui (pour les nouveaux utilisateurs)	Au moins 8 caractères. Enregistré sous forme de hachage Argon2id, jamais relisible. Laisser vide en modification pour conserver le mot de passe actuel.
Rôles	non	Sélecteur de pastilles — taper ou choisir dans la liste. La liste contient chaque rôle configuré sous l'onglet Rôles.
Actif	oui (activé par défaut)	Désactivé, l'utilisateur ne peut pas se connecter ; les sessions existantes s'arrêtent au prochain rafraîchissement de jeton.
Superutilisateur	non	Activé, passe outre chaque vérification de permission. À utiliser avec parcimonie.

Cliquer sur Enregistrer — l'utilisateur est créé et la fenêtre se ferme. Le nouvel utilisateur apparaît en tête de liste.

Endpoints en coulisses

Action	Endpoint
Création	POST /admin/access/users
Mise à jour	PATCH /admin/access/users/{username}
Changement de mot de passe	POST /admin/access/users/{username}/password

Le backend TOML écrit dans config/auth.toml de façon atomique ; le backend DB commit dans ly2_users / ly2_user_roles. Dans les deux cas, le changement prend effet immédiatement — l'utilisateur peut se connecter tout de suite avec le nouveau mot de passe.

---

Modifier un utilisateur existant

Cliquer sur n'importe quelle ligne d'utilisateur pour ouvrir l'éditeur avec ses valeurs courantes :

Champ	Modifiable	Notes
Nom d'utilisateur	non	Fixé à la création.
Nom complet / Courriel	oui	Mise à jour libre.
Mot de passe	oui (utilisateurs locaux uniquement)	Laisser vide pour conserver le mot de passe actuel. Saisir un nouveau (8 caractères ou +) le définit à l'enregistrement.
Rôles	oui	Ajouter / retirer des pastilles.
Actif	oui	Basculer pour désactiver.
Superutilisateur	oui	Basculer pour accorder / révoquer le statut superutilisateur.

Les enregistrements passent par PATCH /admin/access/users/{username} pour les mises à jour de propriétés et par POST /admin/access/users/{username}/password si un nouveau mot de passe a été saisi.

Quand l'utilisateur est connecté

Les changements n'interrompent pas la session courante. Les nouveaux rôles / le drapeau de désactivation / le mot de passe prennent effet au prochain rafraîchissement (dans le TTL du jeton d'accès — par défaut 1 heure) ou à la déconnexion + reconnexion.

---

Utilisateurs OIDC — les différences

Les utilisateurs OIDC arrivent dans la liste des Utilisateurs après leur première connexion — Liberty les crée automatiquement avec provider = "oidc". L'éditeur pour un utilisateur OIDC a la même apparence, mais :

Champ	Modifiable pour OIDC ?	Notes
Nom d'utilisateur	non	Identique au local.
Nom complet / Courriel	techniquement oui, mais…	À chaque connexion OIDC, ces champs sont rafraîchis depuis les claims de l'IdP. Les modifications manuelles sont écrasées. Les modifier au niveau de l'IdP.
Mot de passe	non	L'IdP détient le mot de passe. Le champ est désactivé ou rejeté avec HTTP 400.
Rôles	oui	C'est la raison principale qui pousse les opérateurs à visiter les utilisateurs OIDC — pour attribuer les rôles.
Actif	oui	Désactivé, la connexion est refusée même avec des jetons OIDC valides.
Superutilisateur	oui	Basculer pour accorder le contournement.

La séquence d'onboarding standard :

1. La nouvelle recrue se connecte via OIDC pour la première fois.
2. Elle arrive avec aucun rôle → elle voit une application vide.
3. Elle prévient son administrateur : « je suis entré mais je ne vois rien ».
4. L'administrateur ouvre Paramètres → Accès → Utilisateurs, la retrouve, attribue les bons rôles, enregistre.
5. L'utilisatrice rafraîchit la page (ou se déconnecte + reconnecte) et dispose alors de ses accès.

Pour les installations qui veulent pré-créer des utilisateurs OIDC avec leurs rôles déjà attachés, des scripts peuvent appeler POST /admin/access/users avec provider = "oidc" et le provider_subject attendu (le claim sub). À la première connexion, le framework retrouve l'utilisateur pré-créé et l'utilise. Les installations standard sautent cette étape et attribuent les rôles après la première connexion.

---

Désactiver ou supprimer

Deux façons d'écarter un utilisateur :

Option	Effet	Quand
Basculer Actif sur off	L'utilisateur ne peut pas se connecter. Sa session courante continue jusqu'à expiration du jeton d'accès (par défaut 1 h), puis le rafraîchissement échoue. Rôles, historique et piste d'audit conservés.	Maintenance, congé, compte suspendu.
🗑 Supprimer (action par ligne, avec confirmation)	L'utilisateur est retiré entièrement. Son historique est conservé (les lignes d'audit sont immuables), mais le nom d'utilisateur peut être réutilisé.	Départ, droit à l'effacement RGPD.

La désactivation est réversible en un clic. La suppression est définitive — un utilisateur qui se reconnecte (OIDC) verrait son compte recréé automatiquement avec le même nom d'utilisateur mais un nouvel id et sans report de rôles.

---

Ce que l'on fait concrètement — flux types

Onboarder une recrue locale

1. Paramètres → Accès → Utilisateurs → ＋ Ajouter un utilisateur.
2. Nom d'utilisateur = identifiant d'entreprise, mot de passe = une chaîne ponctuelle qu'elle changera, courriel = son adresse.
3. Attribuer les rôles selon son équipe (analyst, reporter, …).
4. Enregistrer.
5. Lui transmettre les identifiants temporaires par le canal habituel de l'entreprise.
6. Elle se connecte, atteint l'assistant IA ou le flux de changement de mot de passe pour définir le sien.

Onboarder une recrue OIDC

1. Elle se connecte via OIDC la première fois — Liberty crée automatiquement le compte.
2. Elle signale qu'elle n'a aucun accès.
3. Paramètres → Accès → Utilisateurs, la retrouver, attribuer les rôles, enregistrer.
4. Elle rafraîchit → elle est dedans.

Changer le mot de passe d'un utilisateur (en tant qu'administrateur)

1. Paramètres → Accès → Utilisateurs, cliquer sur l'utilisateur.
2. Saisir le nouveau mot de passe dans le champ Mot de passe (8 caractères ou +).
3. Enregistrer.
4. Le prévenir. Il se connecte avec le nouveau mot de passe ; sa session existante continue de fonctionner jusqu'à expiration du jeton d'accès.

Révoquer un compte immédiatement

1. Basculer Actif sur off et enregistrer.
2. Si le délai pouvant aller jusqu'à 1 heure avant l'expiration du jeton d'accès courant est inacceptable, faire tourner le secret de signature JWT ([auth] jwt_secret dans app.toml ou variable d'environnement LIBERTY_JWT_SECRET) et redémarrer. Chaque jeton existant est invalidé — un coup de marteau lourd, mais la seule révocation immédiate offerte par Liberty.

---

Pièges courants

Erreur	Symptôme	Correction
Utilisateur OIDC sans rôles après connexion.	Comportement attendu — l'opérateur n'en a pas encore attribué.	Ouvrir Paramètres → Accès → Utilisateurs, attribuer les rôles.
Modifier le courriel d'un utilisateur OIDC revient à la connexion suivante.	Le claim de l'IdP l'emporte ; le framework rafraîchit depuis le dernier jeton.	Modifier le courriel au niveau de l'IdP.
Tenter de définir un mot de passe pour un utilisateur OIDC.	Le backend rejette avec 400.	Les utilisateurs OIDC n'ont pas de mot de passe local — ils se connectent via le fournisseur.
Changer le rôle d'un utilisateur ne prend pas effet immédiatement.	Le JWT de l'utilisateur contient toujours les anciens rôles.	Il rafraîchit (ou se déconnecte + reconnecte) — dans le TTL du jeton d'accès, les nouveaux rôles s'appliquent.
Supprimer et recréer un utilisateur pour « le réinitialiser ».	Son historique d'audit se détache (référence désormais un nom d'utilisateur supprimé).	Utiliser la désactivation + réactivation ; ne supprimer que si l'utilisateur est vraiment parti.
Passer un utilisateur en superutilisateur pour corriger un manque de permission.	Cela fonctionne, mais cela passe outre chaque vérification — y compris celles qu'il ne devrait pas contourner.	Ajouter plutôt la permission manquante à l'un de ses rôles.

---

Suite

• Rôles et permissions — ce qu'il faut attribuer une fois l'utilisateur créé.
• Se connecter — comment les utilisateurs s'authentifient réellement.
• Secrets chiffrés — l'interrupteur 🔒 pour les identifiants ailleurs dans le framework.