Rôles, équipes et responsables

Vue d’ensemble — à quoi cela sert

Les rôles et les équipes sont des libellés informatifs servant à classer les personnes. La seule et unique chose qui ouvre l’accès aux écrans et aux actions est le niveau (user_level). Ce qu’un utilisateur peut voir, et ce qu’il a le droit d’enregistrer ou de supprimer, est décidé à 100 % par le niveau ; les rôles (« DBA », « DevOps », « Sécurité ») et les équipes (« Équipe Infrastructure », « Équipe Sécurité ») sont des étiquettes d’affichage et d’organisation qui n’accordent absolument aucune permission.

Le modèle de permissions reste ainsi simple. Pour donner à quelqu’un des pouvoirs d’administrateur, vous relevez son niveau — vous ne changez pas son rôle. Étiqueter un utilisateur « Sécurité » n’ouvre pas les écrans de sécurité ; son niveau doit être Personnel (5) ou supérieur.

Cet article couvre trois sujets :

1. Les rôles (infr_role) — six intitulés de poste (DBA, DevOps, Sécurité, Administrateur, Personnel, Développeur).
2. Les équipes (infr_team) — des unités organisationnelles, utilisées pour l’appartenance des utilisateurs et la responsabilité des actifs.
3. Le sélecteur de responsable — une liste déroulante combinée qui permet d’affecter soit un utilisateur, soit une équipe, avec App\Support\Owners comme source de vérité unique. Le champ « responsable » des Instances, du Matériel et du Stockage l’utilise.

Contrôle d’accès = le niveau (user_level) uniquement. Les rôles et les équipes n’ouvrent aucune permission de manière programmatique. Voir Comprendre les niveaux (RBAC) pour le système de niveaux.

Quand l’utiliser

• À l’arrivée d’une nouvelle personne, pour étiqueter son poste (rôle) et son appartenance (équipe).
• Lors d’une réorganisation — créer une équipe ou changer son responsable.
• Pour affecter un responsable (une personne ou une équipe) aux actifs serveur, matériel ou stockage, afin que « qui en répond » soit explicite.
• Audit / passation : rechercher « qui est responsable de cet actif ».

Disposition de l’écran

/admin/users (Administration ▸ Utilisateurs et rôles) comporte deux onglets.

La modale d’édition d’un utilisateur comporte des sélecteurs niveau / rôle / équipe, suivis de cette indication :

Le niveau régit l’accès — Démo (lecture), Personnel (exploitation), Administrateur (tout). Le rôle est un simple libellé.

Comment l’utiliser

Les rôles — des intitulés de poste

Le référentiel des rôles compte six entrées, insérées ou mises à jour de façon idempotente par key grâce à InfrRoleSeeder.

• Un utilisateur possède au plus un rôle (users.role_id, nullable). Il peut ne pas être renseigné.
• Les rôles n’apparaissent que sous forme de libellé et de couleur dans la liste déroulante utilisateur de la barre supérieure et dans les badges des listes.
• Le libellé affiché est résolu par App\Support\RolePolicy::roleLabel($roleId) avec un cache de 60 secondes (appelez RolePolicy::flush() après une modification).

Le rôle admin (libellé « Administrateur ») n’a rien à voir avec le niveau administrateur (10). Un rôle n’est qu’un libellé : un utilisateur dont le rôle est « Administrateur » mais dont le niveau est Démo (1) ne peut rien enregistrer. À l’inverse, un administrateur de niveau 10 dispose de toute l’administration même avec un rôle vide.

Les équipes — des unités organisationnelles

Les équipes se gèrent librement en CRUD dans l’onglet Équipes. Les quatre équipes de la semence :

Champs d’édition d’une équipe :

• Un utilisateur appartient à au plus une équipe (users.team_id, nullable).
• À la suppression d’une équipe : le team_id des membres de cette équipe passe à null (les utilisateurs subsistent, désormais sans affectation). Les actifs qui référençaient l’équipe via owner_type='team' relèvent d’un autre sujet : les actifs eux-mêmes ne sont donc pas supprimés.

Le sélecteur de responsable — utilisateurs et équipes réunis

Les actifs (instances serveur, matériel, stockage) possèdent un champ « responsable » qui peut désigner soit une personne, soit une équipe. Les règles de ce sélecteur combiné se trouvent dans App\Support\Owners (la SOT).

Forme de stockage = deux colonnes

La table de l’actif enregistre le responsable dans deux colonnes.

Forme d’échange côté front = une chaîne ref unique

Le navigateur (formulaires, filtres) échange owner_type et owner_id sous la forme d’une seule chaîne.

user:5     → user id 5
team:3     → team id 3

Les options d’amorçage (Owners::options()) renvoient les deux groupes pour le rendu en optgroup (cache de 20 secondes). Les utilisateurs clôturés (is_close=1) et les équipes inactives (is_active=0) sont exclus.

{
  "users": [ { "ref": "user:5", "id": 5, "name": "Jane Doe" } ],
  "teams": [ { "ref": "team:3", "id": 3, "name": "Infra Team" } ]
}

Découpage / reconstruction côté serveur

Par exemple, le contrôleur d’enregistrement des instances procède ainsi :

// ref du responsable ("user:5"/"team:3") → owner_id + owner_type
[$ownerType, $ownerId] = Owners::split($request->input('owner_ref'));
$payload['owner_id']   = $ownerId ?: null;
$payload['owner_type'] = $ownerId ? $ownerType : 'user';   // 'user' par défaut si non renseigné

La même ref sert au filtrage par responsable : la requête de liste découpe le paramètre owner (user:5/team:3) avec split() et restreint à WHERE owner_id = ? AND owner_type = ?.

Le sélecteur de responsable est réutilisé à l’identique sur les écrans d’actifs Instances, Matériel et Stockage et fichiers. Affecter une équipe comme responsable place l’équipe entière sur la ligne de responsabilité (ce qui résiste au départ de n’importe quelle personne).

Avatar · initiales · couleur

L’avatar affiché à côté d’un libellé est généré à partir du nom par RolePolicy.

• Initiales (initials) : CJC/coréen → premier caractère ; noms latins → première lettre du premier et du dernier mot (2 caractères).
• Teinte (hue) : crc32(name) % 360 pour un fond HSL stable.
• Teinte de niveau (tierTone) : administrateur (≥10) = crit · personnel/exploitation (≥2) = accent · démo = muted.

Sources de données

Assistants SOT :

• App\Support\Owners — sélecteur de responsable combiné (options/split/ref/resolveName/flush).
• App\Support\RolePolicy — libellés et teintes de niveau, libellés de rôle (cache de 60 secondes), initiales et couleur de l’avatar.

Accès

• L’entrée de tout l’écran est réservée aux administrateurs. /admin/* est protégé par le middleware de groupe infr.level:10, et UserController / TeamController revérifient eux-mêmes le user_level >= 10 de la session (RolePolicy::ADMIN). Démo (1) et Personnel (5) obtiennent un 403.
• Seuils de niveau (référence) : écriture ≥ 2 (RolePolicy::WRITE, bloque la démo) · administration ≥ 10 (ADMIN) · développement/observabilité ≥ 9 (DEV, inclut l’administrateur 10).
• À l’enregistrement d’un utilisateur, user_level est restreint à l’une des valeurs 1,5,10.
• Chaque modification d’utilisateur ou d’équipe est auditée dans infr_audit_log (team.create / team.update / team.delete, enregistrement/suppression d’utilisateur, etc.).

Garde-fous (protection du dernier administrateur)

Dépannage et FAQ

Q. J’ai donné à quelqu’un le rôle « Sécurité » mais les écrans de sécurité ne s’ouvrent pas. Les rôles sont des libellés ; ils n’ouvrent aucune permission. Les écrans de sécurité (essentiellement en lecture) exigent un niveau — faites-le passer à Personnel (5) ou au-delà. Voir Niveaux RBAC.

Q. Un utilisateur ou une équipe manque dans la liste déroulante des responsables. Les utilisateurs clôturés (is_close=1) et les équipes inactives (is_active=0) sont exclus du sélecteur. Réactivez l’utilisateur ou l’équipe ; si la liste est périmée, attendez l’expiration du cache de 20 secondes (Owners::flush() l’invalide immédiatement).

Q. Si je supprime une équipe, ses membres disparaissent-ils ? Non. Les utilisateurs subsistent ; seul leur team_id devient null (sans affectation). La référence owner_type='team' d’un actif est indépendante : l’actif n’est donc pas supprimé non plus (son responsable affiché devient simplement vide).

Q. J’ai enregistré un responsable mais aucun nom ne s’affiche. resolveName() dispose d’un cache de 20 secondes. Si vous venez de renommer quelque chose, cela se rafraîchit sous peu. Vérifiez également que le format de la ref est bien user:5/team:3 — un format cassé est traité par split() comme sans affectation (user:0).

Q. Un utilisateur peut-il avoir deux rôles ? Non. role_id est une valeur unique (nullable). S’il vous faut aussi un regroupement organisationnel, utilisez une équipe (également une valeur unique).

Voir aussi

• Comprendre les niveaux (RBAC) — le seul axe qui décide réellement de l’accès
• Console utilisateurs et équipes — détails du CRUD de /admin/users
• Instances — l’écran d’actifs phare qui utilise le sélecteur de responsable
• Matériel — responsables des actifs physiques
• Stockage et fichiers — responsables des actifs de stockage
• Journal d’audit — historique des modifications d’utilisateurs, d’équipes et de responsables