Rôles

Route de l’application : /admin/roles

À quoi sert cet écran

C’est le seul endroit du produit où le modèle de droits devient manipulable. On y voit les cinq rôles Un ensemble nommé de droits, attribué à une personne pour tout l'établissement ou pour une partie seulement. système, on y construit des rôles personnalisés, et on décide de ce que chacun ouvre.

C’est aussi l’écran où une erreur coûte le plus cher : un rôle trop large donne des droits que personne n’a demandés, un rôle trop étroit produit des refus que personne ne comprend.

Qui y a accès

Permission requise : Gérer les rôles role.manage .

La portent Administrateur — plus, le cas échéant, les rôles personnalisés de votre établissement qui la contiennent.

Sans cette permission, l'entrée n'existe pas dans le menu. Elle n'y figure ni grisée ni cadenassée : la navigation est filtrée sur les droits résolus, pas désactivée. Une section absente n'est donc pas une panne — et au tout premier affichage, le menu peut être plus court une fraction de seconde, le temps que les permissions arrivent.

Une permission peut être limitée à certains campus ou formations. Dans ce cas l'écran s'ouvre, mais les ressources hors périmètre en sont absentes — voir Portée.

Sans cette permission, l’entrée « Administration » n’existe pas dans le menu et l’adresse directe renvoie à l’accueil.

Voir les rôles et les attribuer sont deux choses différentes : cet écran définit les rôles, Utilisateurs les attribue, et la seconde action demande Gérer les utilisateurs user.manage .

Ce qu’on y voit

L’écran est titré « Rôles », sous-titré « Rôles système et rôles personnalisés construits à partir du catalogue de permissions. »

La liste des rôles, chacun avec son étiquette — « Système » ou « Personnalisé » — son nom, sa description et ses permissions. Le bouton « Créer un rôle » ouvre « Nouveau rôle personnalisé » : « Nom », « Description », « Permissions ».

Rôle système, rôle personnalisé

	Rôle système	Rôle personnalisé
Combien	cinq, les mêmes partout	autant que l’établissement en crée
Où il est défini	dans le code du produit	en base, dans votre établissement
Modifiable ?	non — ni son nom, ni ses permissions	oui, entièrement
Supprimable ?	non	oui
Ce qu’il garantit	un socle identique pour tous les établissements	une adaptation à votre organisation

Pourquoi les cinq rôles système ne se modifient pas. Ils sont la référence commune : c’est ce qui permet à cette documentation, aux guides par rôle et au support de parler de « planificateur » sans avoir à demander « chez vous, ça veut dire quoi ? ». Un établissement qui a besoin d’autre chose ne modifie pas le socle — il ajoute un rôle.

Ces cinq rôles sont les rôles système, identiques dans tous les établissements. Un établissement peut créer ses propres rôles à partir du même catalogue de permissions : ceux-là ne sont pas décrits ici.

Le catalogue de permissions

Une permission Le droit de faire une chose précise dans l'application — modifier le planning, approuver une demande, consulter le journal. est une clé technique qui autorise une famille d’actions. Le catalogue en compte douze, et il est fixe : aucun écran ne permet d’en créer une.

Ce n’est pas une limitation d’interface, c’est une conséquence du fonctionnement. Chaque clé est posée sur les routes de l’API qu’elle protège ; c’est là que la vérification a lieu. Une permission qu’un établissement inventerait ne serait rattachée à aucune route, donc vérifiée nulle part : elle donnerait un sentiment de contrôle et aucun contrôle.

Ce qui s’adapte à votre organisation, c’est donc la combinaison des douze clés, pas la liste.

La matrice complète

Voici, pour les cinq rôles système, ce que chaque permission ouvre. Un rôle personnalisé se construit dans exactement le même catalogue.

Ce que chaque rôle système peut faire — 12 permissions, 5 rôles.

Permission	Administrateur	Planificateur	Gestionnaire de patrimoine	Enseignant	Étudiant
Modifier le planning planning.edit	✓ Oui	✓ Oui	— Non	— Non	— Non
Publier le planning planning.publish	✓ Oui	— Non	— Non	— Non	— Non
Lancer une optimisation planning.solve	✓ Oui	✓ Oui	— Non	— Non	— Non
Réserver une salle room.book	✓ Oui	✓ Oui	✓ Oui	✓ Oui	— Non
Gérer les contraintes constraint.manage	✓ Oui	— Non	— Non	— Non	— Non
Gérer le référentiel referential.manage	✓ Oui	— Non	✓ Oui	— Non	— Non
Approuver les réservations booking.approve	✓ Oui	✓ Oui	✓ Oui	— Non	— Non
Gérer les règles de réservation booking_rule.manage	✓ Oui	— Non	— Non	— Non	— Non
Consulter le journal d'audit audit.read	✓ Oui	— Non	— Non	— Non	— Non
Consulter les statistiques d'occupation analytics.read	✓ Oui	— Non	✓ Oui	— Non	— Non
Gérer les utilisateurs user.manage	✓ Oui	— Non	— Non	— Non	— Non
Gérer les rôles role.manage	✓ Oui	— Non	— Non	— Non	— Non

Ces cinq rôles sont les rôles système, identiques dans tous les établissements. Un établissement peut créer ses propres rôles à partir du même catalogue de permissions : ceux-là ne sont pas décrits ici.

Un rôle personnalisé doit porter au moins une permission — sans quoi la création est refusée : « Sélectionnez au moins une permission. » Un rôle vide n’aurait aucun sens : il n’ouvrirait rien.

Le périmètre, et sa règle contre-intuitive

Un rôle n’est pas forcément donné pour tout l’établissement. Il peut être limité à certains campus ou à certaines formations, au moment où on l’attribue à quelqu’un — sur Utilisateurs, pas ici.

Un rôle peut être donné pour tout l'établissement ou limité à certains campus ou à certaines formations. Porter une permission ne suffit alors pas : encore faut-il que la ressource visée entre dans cette limite.

La règle tient en une phrase : une permission limitée à un campus ne s'applique jamais à une ressource dont le campus est inconnu. Dans le doute, la réponse est non — c'est ce qu'on appelle une règle fail-closed, et c'est ce qui évite qu'un identifiant manquant ouvre un accès par accident.

Chaque réponse de la dernière colonne est calculée à la construction du site en appelant la fonction qui décide réellement, dans le produit.

Le rôle est limité à…	La ressource visée	Autorisé ?
Aucune limite — l'établissement entier	Une salle du campus Nord	Oui
Le campus Nord	Une salle du campus Nord	Oui
Le campus Nord	Une salle du campus Sud	Non
Le campus Nord	Une ressource dont le campus est inconnu	Non
La formation Informatique	Une salle du campus Nord, rattachée à aucune formation	Non

• Aucune limite — l'établissement entier → Une salle du campus Nord : Un rôle attribué sans portée couvre tout l'établissement : c'est le cas le plus courant.
• Le campus Nord → Une salle du campus Nord : La ressource est dans la liste : la permission joue normalement.
• Le campus Nord → Une salle du campus Sud : La ressource est hors de la liste : la permission ne s'applique pas.
• Le campus Nord → Une ressource dont le campus est inconnu : C'est la règle fail-closed : dans le doute, la réponse est non. Une permission limitée à un campus ne s'applique jamais à une ressource qui ne dit pas le sien.
• La formation Informatique → Une salle du campus Nord, rattachée à aucune formation : La portée ne parle que de formations, mais la ressource n'en porte aucune : refusé, pour la même raison.

L’exemple qui fait comprendre

L’établissement de démonstration a deux campus. Prenons un rôle « Gestionnaire campus Nord », limité au campus Nord, attribué à quelqu’un.

La ressource visée	Autorisé ?	Pourquoi
Une salle du campus Nord	oui	le campus est renseigné, et il est dans la liste
Une salle du campus Sud	non	le campus est renseigné, et il n’y est pas
Une salle dont le campus n’est pas renseigné	non	et c’est ce qui surprend

La troisième ligne est la règle fail-closed : le produit ne dit « oui » que s’il peut prouver que la ressource est dans le périmètre. Une donnée manquante n’est pas un doute favorable, c’est un refus.

En pratique : un périmètre mal renseigné côté patrimoine — un bâtiment sans campus, par exemple — se traduit par des refus inexplicables du côté de l’utilisateur, qui a pourtant « le bon rôle ».

Le cumul de plusieurs rôles

Un utilisateur peut porter plusieurs rôles. La règle est simple et permissive :

Les permissions s’additionnent. La plus large gagne.

Trois conséquences à connaître :

• deux rôles, un seul suffit : si l’un des deux porte Publier le planning planning.publish , la personne peut publier — l’autre rôle ne l’en empêche pas ;
• un rôle global annule le périmètre d’un autre : ajouter un rôle non limité à quelqu’un qui avait un rôle limité au campus Nord lui ouvre tout l’établissement. Le périmètre du premier n’est pas « intersecté », il est simplement contourné ;
• retirer un rôle ne suffit pas toujours : si la permission vient aussi d’un autre rôle, elle reste. Le panneau « Rôles de … » de la fiche utilisateur montre la liste complète, et c’est là qu’il faut regarder.

Le même principe vaut pour les règles de réservation — voir Règles de réservation.

Un rôle scopé n'est presque nulle part appliqué aujourd'hui

L’éditeur de périmètre fonctionne, le périmètre est bien enregistré, et la fonction qui décide est écrite et testée. Ce qui manque, c’est son appel : vérifié dans le code, le seul service applicatif qui vérifie réellement le périmètre est celui des approbations.

Concrètement, un rôle limité au campus Nord :

• filtre bien la file des demandes de réservation — voir Approbations ;
• ne filtre rien ailleurs : le planning, le référentiel, la pédagogie, l’analytique et les imports s’ouvrent sur tout l’établissement.

Le symptôme, et il est trompeur : on scope un rôle, on vérifie sur les approbations, on constate que ça marche, et on en conclut que le périmètre est appliqué partout. Il ne l’est pas.

Ce qu’il faut en faire : traiter le périmètre comme une intention d’organisation et non comme une barrière de sécurité. Quand la séparation doit être réelle, elle passe par les permissions attribuées, pas par le périmètre.

Ce qu’on peut y faire

Action	Permission	Où c’est expliqué
Créer un rôle personnalisé	Gérer les rôles role.manage	guide de l’administrateur
Modifier un rôle personnalisé	Gérer les rôles role.manage	guide de l’administrateur
Supprimer un rôle personnalisé	Gérer les rôles role.manage	cette page
Attribuer un rôle à quelqu’un	Gérer les utilisateurs user.manage	Utilisateurs
Limiter un rôle à un périmètre	Gérer les utilisateurs user.manage	Utilisateurs
Attacher des règles de réservation à un rôle	Gérer les règles de réservation booking_rule.manage	Règles de réservation

Chaque création, modification et suppression de rôle est auditée, ainsi que chaque attribution — voir Journal d'audit.

États particuliers

Ce que vous voyez	Ce que ça veut dire
« Chargement… »	vos permissions ou la liste des rôles arrivent
« Une erreur est survenue. Veuillez réessayer. »	la liste n’a pas pu être chargée
Un rôle étiqueté « Système » sans bouton de modification	c’est normal : les cinq rôles système ne se modifient pas
Un rôle personnalisé sans aucun utilisateur	il existe, il n’ouvre rien à personne — c’est un état parfaitement valide, et invisible depuis cet écran : le décompte se lit sur Utilisateurs
« Un rôle porte déjà ce nom. »	les noms sont uniques par établissement
« Sélectionnez au moins une permission. »	un rôle sans permission ne peut pas exister
Supprimer un rôle attribué à quelqu’un	l’attribution disparaît avec le rôle : la personne perd ces droits immédiatement, sans avertissement préalable
Vous êtes renvoyé à l’accueil	vous n’avez pas Gérer les rôles role.manage

Sur un rôle personnalisé sans utilisateur : cet écran ne le signale pas — il ne compte pas les attributions. Un rôle créé « pour plus tard » et jamais attribué est indiscernable d’un rôle en service. C’est la liste des utilisateurs qui répond.

Sur un périmètre vide : laisser les deux listes vides signifie tout l’établissement, et c’est écrit dans l’éditeur : « Laissez vide pour tout l’établissement. » Il n’y a pas de « périmètre nul » qui ne donnerait rien — le vide est le plus permissif.

Sur le temps réel : cet écran ne se met pas à jour tout seul. En revanche, un changement de rôle prend effet immédiatement pour la personne concernée, sans qu’elle ait à se reconnecter — sa navigation se réorganise à la volée.

Sur le hors-périmètre : la portée d’un rôle ne filtre pas cet écran. Qui porte Gérer les rôles role.manage voit et modifie tous les rôles.

Écrans liés

• Utilisateurs — où les rôles s’attribuent et se limitent.
• Règles de réservation — les règles de réservation, attachées aux mêmes rôles.
• Journal d'audit — la trace de chaque changement de rôle.
• Accueil — où un utilisateur constate l’effet de ses rôles, dans « Vos accès ».
• Qui fait quoi — la même matrice, lue du point de vue des rôles.
• Rôle, Permission et Portée — les définitions courtes.