---
title: "Gestion des droits logiciels (profils applicatifs)"
module: identity
type: functional
status: active
updated: 2026-07-22
---

# Gestion des droits logiciels (profils applicatifs)

> Doc fonctionnelle : décrit le **quoi** et le **pourquoi** (point de vue utilisateur / chef de projet).

## À quoi ça sert

ISI-APP recense les applications du SI, mais ne savait pas **qui doit avoir quel profil dans quelle
application**. Cette fonctionnalité décrit les profils de chaque application (nom, code, admin),
les affecte aux utilisateurs (manuellement, en masse ou par règles automatiques), déclenche par mail
la demande de création des comptes à l'arrivée d'un collaborateur, et expose ces besoins à l'IAM
Youzer. Les logiciels en ligne non gérés dans l'IAM sont éligibles aussi (connaître les comptes
existants partout).

## Comment ça marche (côté utilisateur)

### Activation

Param DSI › Gestion des personnes › Informations générales › **« Gestion des droits logiciels
(profils applicatifs) »** (Oui/Non). Désactivé : aucun onglet, aucune étape de wizard, aucun champ
API — les données existantes sont conservées (réactivation sans perte).

### Fiche Application › onglet « Profils »

- CRUD des profils : **nom**, **code** (celui du rôle dans le logiciel cible), **commentaire**,
  case **Profil Admin**.
- **Niveau de création** par application : *Local* / *Global* / *Les deux* — détermine uniquement
  qui reçoit les mails de demande de création (pas les droits de gestion dans ISI-APP).
- **Règles d'affectation automatique** par profil : critère *fonction* OU *entité* OU *groupe* →
  le profil est proposé à la création d'utilisateur. Appliquées uniquement à la création (pas de
  recalcul continu, cf. « Améliorations futures »).
- **Affectation en masse** : un profil → plusieurs utilisateurs (sélection multiple).
- Panneau **« Suivi des droits »** : comparaison théorique vs intégré, avec pointage manuel des
  statuts et alerte sur les écarts.

### Fiche Personne › Informatique › sous-onglet « Applications »

Tableau des profils du collaborateur (application, profil, code, Admin, origine manuel/règle,
statut) + ajout et retrait depuis cet écran, et changement de statut manuel par le gestionnaire.

### Cycle de vie d'une affectation

`À créer` → `Notifié` (mail parti) → `Intégré` (compte constaté) → `À désactiver` / `À supprimer`
(utilisateur désactivé/parti ou affectation retirée après notification) → `Désactivé` / `Supprimé`.
Le statut est modifiable manuellement à tout moment par le gestionnaire.

### Wizard de création d'utilisateur — étape « Profils applicatifs »

Affichée si la fonctionnalité est active et qu'au moins un profil existe (jamais en création
externe prestataire). Les règles correspondant à la fonction, l'entité et les groupes saisis
proposent des profils **pré-cochés**, ajustables ; d'autres profils peuvent être ajoutés à la main.
À la validation, les affectations sont créées en `À créer`.

### Mails de demande de création (H+1)

Toute nouvelle affectation `À créer` (wizard, fiche personne, masse) programme un mail **1 heure
après** :

- niveau **Local** → admins locaux (profils 100/110/150) de l'entité du collaborateur ;
- niveau **Global** → responsable(s) de l'application (fiche « Utilisation interne ») ;
- **Les deux** → les deux.

Le délai d'1h est une **fenêtre d'annulation** : affectation retirée avant l'envoi → aucun mail.
Les affectations créées dans l'heure pour un même destinataire sont **regroupées en un seul mail**
(collaborateur, date d'arrivée, profils + codes, mention Admin). Une affectation sans destinataire
résolu (responsable non renseigné, aucun admin local) reste `À créer` et sera reprise au prochain lot.

### API Youzer

`GET apiv2/{idc}/users` expose `apps_to_provision` par utilisateur : liste des affectations
`À créer`/`Notifié` (application, profil, code, is_admin, status) — uniquement si la fonctionnalité
est activée.

## Règles d'accès

- Onglet Profils fiche app : visible si toggle actif ; gestion gatée par `manageAccessRights('U', idapp, 80500101)`.
- Sous-onglet fiche Personne : visible si toggle actif + module enfant `app` ; gestion gatée par
  `manageAccessRights('U', idUser, 12000101)`.
- Étape wizard : toggle actif + au moins un profil dans le tenant + création non externe.

## Points d'attention

- Le matching des règles « fonction » se fait sur le **libellé exact** (`lbfonc`, texte libre) —
  la saisie de la règle propose les fonctions existantes du tenant pour éviter les fautes.
- Retirer une affectation déjà notifiée/intégrée ne la supprime pas : elle passe en « À supprimer »
  (le compte existe peut-être côté application).

## Améliorations futures (hors V1, validées au PRD)

- Workflow de validation complet (approbation avant envoi du mail).
- Recalcul automatique des règles lors d'un changement de fonction/entité/groupe.
- Import automatique des comptes réels (fichier ou retour IAM) pour la comparaison.