---
title: "Droits Spécifiques — Personnalisation fine des accès aux modules"
module: identity
type: functional
status: active
updated: 2026-07-01
---

# 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é :

1. **Onglet Groupes** : créer les groupes nécessaires (ex : « Commerciaux », « Admins RH », « Support N1 »).
2. **Onglet Utilisateurs** : affecter chaque utilisateur à un ou plusieurs groupes.
3. **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).
4. **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](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](../../.claude/technical-docs/identity/specific-rights.md)