Actif identity functional Revu le 2026-07-01 identity/specific-rights.md

Droits Spécifiques — Personnalisation fine des accès aux modules

À quoi ça sert

Le module Droits Spécifiques permet à un administrateur d'aller au-delà des droits standards d'ISI-APP pour configurer qui peut faire quoi sur quel module, en croisant des groupes d'utilisateurs avec des entités (filiales, agences, services).

C'est l'outil de référence pour mettre en place une politique d'accès fine sur une organisation multi-entités, par exemple :

Donner uniquement la lecture du module CRM à l'équipe commerciale junior.
Réserver l'export des données RH à la direction.
Limiter la création de tickets à un service support, sur une seule filiale.

Les 4 piliers du module

Le module est organisé en 4 onglets, qui correspondent aux 4 briques à configurer.

Onglet	Rôle	Question à se poser
Droits	Lister les modules sur lesquels on veut appliquer des règles spécifiques.	« Sur quel module je veux affiner les accès ? »
Groupes	Créer des groupes d'utilisateurs (équipes, rôles, services).	« Qui sont mes ensembles d'utilisateurs ? »
Utilisateurs	Affecter les utilisateurs aux groupes.	« Dans quels groupes mettre cette personne ? »
Permissions	Croiser un droit, un groupe, et un niveau d'accès par action (voir, lire, créer, modifier, supprimer, exporter).	« Qu'est-ce que ce groupe peut faire sur ce module ? »

Niveaux d'accès disponibles

Pour chaque action (voir, lire, créer, modifier, supprimer, exporter), on peut choisir :

Niveau	Signification
Accès global	L'utilisateur a accès à tout.
Limité aux entités	Restreint au profil d'entité de l'utilisateur.
Limité aux groupes	Restreint au profil de groupe.
Entités OU groupes	Combinaison souple.
Entités ET groupes	Combinaison stricte.
Aucun accès	L'action est interdite.

Quand un utilisateur est concerné par plusieurs permissions, c'est la plus permissive qui l'emporte.

Qui l'utilise

Administrateurs avec un profil ≤ 100.
Équipe Assistance Admin ISI.

L'accès passe par le menu Modules > Droits spécifiques (route /modules/rights).

Prérequis et activation

L'option « Droits spécifiques » doit être activée pour l'entité par un Assistance Admin (paramètre DsiParam.blconfig_specific_rights).
Sans activation, une page commerciale présentant la fonctionnalité s'affiche à la place.

Comment configurer une politique d'accès

Workflow recommandé :

Onglet Groupes : créer les groupes nécessaires (ex : « Commerciaux », « Admins RH », « Support N1 »).
Onglet Utilisateurs : affecter chaque utilisateur à un ou plusieurs groupes.
Onglet Droits : déclarer les modules sur lesquels on veut une politique fine et préciser à quelles entités ils s'appliquent (laisser vide = toutes).
Onglet Permissions : pour chaque droit créé, lier les groupes concernés et définir les niveaux d'accès par action.

Multi-tenancy et entités partagées

ISI-APP étant multi-tenant, le module respecte plusieurs règles :

Toutes les listes (groupes, utilisateurs, permissions) sont filtrées par entité automatiquement.
En cas de partage entre entités (mode prestataire/client via ExtAccess), les utilisateurs et groupes des entités partagées deviennent visibles et peuvent être ajoutés aux groupes — utile pour les cabinets et leurs clients.
Les partages doivent être actifs et acceptés des deux côtés pour être pris en compte.

Modules non gérables

Certains modules système ne peuvent pas avoir de droits spécifiques (ex : modules d'identification, de paramétrage core). Ils sont automatiquement exclus du sélecteur lors de la création d'un droit.

Points d'attention

Un droit spécifique bloque par défaut la création, la modification et la suppression : dès qu'un droit spécifique est créé sur un module, seul l'accès en lecture (Annuaire / Accès à la donnée) est configurable à la création. Les actions de création, modification, suppression et export sont automatiquement bloquées pour tout le monde sur ce module, y compris les administrateurs, tant qu'aucune permission n'a été ajoutée. Pour rétablir ces actions pour certains utilisateurs, il faut ensuite créer un ou plusieurs groupes et leur associer les permissions voulues. L'onglet Droits affiche ce blocage sous forme de badge « Bloqué » sur les colonnes Droit de création / modification / suppression.
Effet immédiat à la connexion suivante : les droits calculés sont stockés en session ; un utilisateur connecté peut nécessiter une reconnexion pour voir les changements.
Permissions multiples : si un utilisateur appartient à plusieurs groupes ayant des permissions différentes sur le même module, c'est la plus permissive qui s'applique.
Suppression en cascade : supprimer un droit supprime automatiquement les permissions associées.
Bien préparer ses groupes avant les permissions : un groupe = un ensemble cohérent d'utilisateurs partageant les mêmes besoins.

Lien avec les autres systèmes

Les droits spécifiques s'appliquent au niveau module.
Les Super Limits (voir sl-rights-management.md) s'appliquent au niveau enregistrement.
Les deux peuvent se combiner : un utilisateur peut avoir le droit de lire le module CRM mais pas d'accéder à un contrat précis verrouillé par SL.

Doc technique : .claude/technical-docs/identity/specific-rights.md