Gestion des habilitations : procédure et matrice des droits

Un salarié change de service et garde ses anciens accès. Un prestataire termine sa mission, mais son compte reste actif. Un comptable peut valider les paiements qu’il a lui-même préparés. Ces situations ont la même origine : personne n’a décidé, tracé puis revu les droits concernés. La gestion des habilitations organise ces décisions, de la demande d’accès à son retrait.

Ce guide présente une procédure en cinq étapes, une matrice des droits commentée, le traitement des arrivées, mobilités et départs, puis la revue périodique des accès. Vous pouvez télécharger la matrice des habilitations pour l’adapter à votre organisation.

Qu’est-ce que la gestion des habilitations ?

La gestion des habilitations consiste à déterminer, attribuer, contrôler et retirer les droits d’accès de chaque utilisateur aux applications, aux fonctions et aux données de l’entreprise. Elle répond à trois questions : qui peut accéder à quoi, avec quel niveau de droit, et qui l’a autorisé ?

Elle se distingue de l’authentification. L’authentification vérifie l’identité d’une personne qui se connecte : mot de passe, double facteur, authentification unique (SSO). L’habilitation détermine ensuite ce que cette personne peut consulter, saisir, valider ou administrer. Un SSO bien configuré ne règle donc pas, à lui seul, la question des droits.

Trois principes guident les décisions :

• Le moindre privilège : chaque personne reçoit les droits nécessaires à sa fonction, et pas davantage.
• Le besoin d’en connaître : l’accès à une donnée se justifie par l’usage qui en est fait, pas par la position hiérarchique.
• La séparation des tâches : certaines combinaisons de droits sont évitées, par exemple modifier les coordonnées bancaires d’un fournisseur et valider le paiement correspondant.

Ces principes figurent dans les recommandations publiques. La fiche « Gérer les habilitations » du guide de la sécurité des données personnelles de la CNIL recommande notamment de définir des profils en séparant les tâches, de faire valider toute demande par un responsable, de supprimer les permissions d’accès des utilisateurs dès qu’ils ne sont plus habilités et de revoir les habilitations au moins une fois par an. Le guide d’hygiène informatique de l’ANSSI consacre une mesure à l’organisation des arrivées, des départs et des changements de fonction (mesure 6) et une autre à l’attribution des bons droits sur les ressources sensibles (mesure 9). L’annexe A de la norme ISO/IEC 27001:2022 comporte également des mesures intitulées contrôle d’accès, gestion des identités, droits d’accès et droits d’accès privilégiés.

L’enjeu n’est pas théorique. Lorsque des données personnelles sont concernées, l’article 32 du RGPD impose des mesures techniques et organisationnelles « afin de garantir un niveau de sécurité adapté au risque ». En janvier 2026, la CNIL a sanctionné France Travail d’une amende de 5 millions d’euros après une violation de données. Elle a notamment relevé que les habilitations des comptes des conseillers Cap emploi « avaient été définies de manière trop large », leur permettant d’accéder aux données de personnes qu’ils n’accompagnaient pas, et a souligné l’insuffisance des mesures de journalisation.

Définir le périmètre des accès

Commencez par l’inventaire de ce qui doit être protégé. Une ressource peut être une application entière, un module, un espace documentaire ou un ensemble de données. Pour chacune, désignez un propriétaire : la personne du métier qui sait qui doit y accéder et qui valide les demandes. L’équipe informatique exécute ; elle ne devrait pas décider seule qu’un acheteur peut consulter la paie.

Définissez ensuite des niveaux de droits simples et communs à toutes les ressources. Dans le modèle proposé, cinq codes suffisent ; ils se combinent si besoin (S+V : saisie et validation) :

Traitez à part trois familles de comptes souvent oubliées : les comptes à privilèges (administration de l’annuaire, des serveurs ou d’une application), les comptes externes (prestataires, intérimaires, partenaires) et les comptes techniques utilisés par des traitements automatiques ou des intégrations. Les premiers méritent un inventaire tenu à jour et un compte dédié, distinct du compte de travail habituel, comme le recommandent le guide d’hygiène de l’ANSSI (mesures 5 et 8) et ses recommandations relatives à l’administration sécurisée (R27). Les deuxièmes ont besoin d’une date d’expiration ; les troisièmes d’un responsable nommé et de droits limités à leur usage. Cette dernière règle vaut aussi pour les agents IA connectés à vos applications : ils ne doivent pas disposer de plus de droits que les personnes qui les sollicitent.

Demander, approuver et exécuter un accès

Une demande d’habilitation suit un circuit court, mais chaque étape a un responsable distinct. Le schéma ci-dessous résume le cycle de vie d’un droit.

1. Demander

La demande précise la personne, la ressource, le profil ou le droit souhaité, le motif et, pour un besoin temporaire, une date de fin. Partir d’un profil de la matrice plutôt que d’une liste libre de droits évite de recopier les accès d’un collègue « qui fait le même travail ».

2. Approuver

Le manager confirme le besoin lié à la fonction ; le propriétaire de la ressource approuve les droits sensibles. Une règle simple évite la plupart des abus : personne ne valide sa propre demande, ni une demande qui lui donnerait un droit qu’il exercerait ensuite sur ses propres opérations.

3. Exécuter

L’équipe informatique ou l’administrateur de l’application crée le compte et les droits approuvés, ni plus ni moins. L’exécution est tracée : date, auteur et droits effectivement attribués. Cette trace permet ensuite de comparer ce qui a été demandé, approuvé et réellement configuré.

4. Utiliser et tracer

Les connexions et les actions sensibles sont journalisées selon la politique de l’entreprise ; l’ANSSI recommande d’activer et de configurer les journaux des composants les plus importants (mesure 36). Les journaux servent à reconstituer qui a fait quoi en cas d’incident ; ils doivent eux-mêmes être protégés et conservés pendant une durée définie.

5. Revoir

Un droit n’est pas acquis définitivement. La revue périodique, détaillée plus bas, vérifie qu’il reste justifié. Toute mobilité ou fin de besoin relance le circuit : nouvelle demande ou retrait.

Remplir la matrice des habilitations

La matrice des habilitations croise des profils métier en lignes et des ressources en colonnes. Chaque cellule indique le droit accordé au profil. Voici un extrait de l’exemple fourni dans le modèle, pour une entreprise fictive :

Quelques règles rendent la matrice utilisable dans la durée :

• Raisonner par profil, pas par personne. Une personne reçoit un ou plusieurs profils ; les exceptions individuelles sont justifiées, datées et revues plus souvent.
• Justifier chaque droit sensible. Une colonne « besoin » oblige à formuler la raison d’un accès en validation ou en administration.
• Nommer le valideur de chaque profil. C’est lui qui confirmera le profil lors de la revue.
• Contrôler les cumuls. Le modèle signale automatiquement trois combinaisons à arbitrer : référentiel fournisseurs et validation des paiements, saisie et validation des paiements par un même profil, administration de l’annuaire et validation métier. Un cumul n’est pas toujours évitable dans une petite équipe ; il doit alors être décidé et compensé, par exemple par une revue des modifications par une autre personne.

Le profil « manager » illustre une difficulté fréquente : il doit pouvoir consulter certaines informations de son équipe, mais pas celles des autres services. Ce filtrage par périmètre se configure dans l’application elle-même ; la matrice le documente pour que la règle soit vérifiable.

Arrivée, mobilité, départ : la procédure

La plupart des droits excessifs naissent lors des changements de situation. La procédure d’arrivée, de mobilité et de départ relie les événements RH aux actions sur les accès.

La mobilité est l’étape la plus souvent oubliée : l’arrivée crée un besoin visible et le départ déclenche une alerte, alors qu’un changement de poste ajoute des droits sans retirer les précédents. Le guide User Management décrit plus largement ce cycle de vie des identités ; la procédure ci-dessus en fixe les responsabilités.

Les délais cibles ne sont pas imposés par le modèle. Fixez-les selon la sensibilité des ressources : la désactivation d’un compte à privilèges ou d’un accès distant n’attend pas la même échéance que le retrait d’un droit de lecture sur un espace documentaire.

Revue des habilitations : revoir et révoquer les accès

La revue des habilitations consiste à faire confirmer périodiquement, par les propriétaires des ressources ou les managers, que chaque droit en place reste justifié. Elle rattrape ce que la procédure n’a pas vu : une mobilité non signalée, un droit temporaire jamais retiré, un compte de prestataire oublié.

Pour qu’une campagne de revue produise des décisions plutôt qu’une validation en bloc :

1. Extraire les droits réels depuis les applications, et non depuis la matrice théorique. L’écart entre les deux est justement ce que la revue cherche.
2. Présenter au valideur des informations utiles : fonction actuelle, profil attendu, droit constaté, date de la dernière revue. Une liste de comptes sans contexte conduit à tout maintenir.
3. Exiger une décision par ligne : maintenir, modifier ou retirer.
4. Exécuter et prouver : une décision de retrait sans date d’exécution laisse le risque entier. Le modèle distingue les décisions « à exécuter » et « exécutées ».
5. Adapter la fréquence au risque : la CNIL recommande une revue au moins annuelle, avec l’implication des métiers. Prévoyez une fréquence plus élevée pour les comptes à privilèges et les données sensibles.

La révocation ne se limite pas au compte principal. Pensez aux sessions ouvertes sur mobile, aux jetons d’accès des intégrations, aux délégations de validation en cours et aux partages de documents créés par la personne.

Exemple de procédure et indicateurs

L’exemple suivant décrit une organisation fictive. Il illustre une manière de formaliser la procédure ; il ne s’agit ni d’un cas client ni d’une norme.

Procédure de gestion des habilitations — entreprise industrielle de 300 salariés (illustratif)

• Objet : encadrer l’attribution, la modification et le retrait des accès à l’ERP, au SIRH, à la GED et aux applications métier.
• Rôles : les RH déclenchent les arrivées, mobilités et départs ; le manager choisit le profil ; le propriétaire de chaque ressource approuve les droits sensibles ; l’équipe informatique exécute ; le RSSI tient la matrice et organise la revue.
• Règles : aucun droit hors profil sans justification datée ; aucun compte externe sans date d’expiration ; comptes d’administration dédiés ; aucune validation de sa propre demande.
• Revue : trimestrielle pour les comptes à privilèges, le référentiel fournisseurs, les paiements et les dossiers salariés ; semestrielle pour les autres ressources.
• Preuves : demandes, décisions, traces d’exécution et résultats de revue conservés selon la politique de l’entreprise.

Quelques indicateurs suffisent pour piloter le dispositif. Le modèle calcule les quatre premiers à partir de l’onglet de revue, et le dernier à partir de la matrice :

• avancement de la revue : décisions prises sur droits à revoir ;
• nombre de retraits décidés lors de la campagne ;
• décisions de modification ou de retrait non encore exécutées ;
• délai moyen entre la décision et son exécution ;
• comptes actifs de personnes parties ou de missions terminées, constatés lors de la revue ;
• profils présentant un cumul de droits à arbitrer.

Mesurez d’abord la situation actuelle, puis suivez l’évolution. Un nombre élevé de retraits lors de la première revue est fréquent : il révèle les droits accumulés, pas l’échec de la démarche.

Une matrice des habilitations à télécharger

Télécharger la matrice des habilitations et la procédure (.xlsx) — modèle gratuit, sans formulaire.

Le classeur contient sept onglets : mode d’emploi, inventaire des ressources, matrice des droits avec contrôle des cumuls (y compris un exemple de compte technique pour un agent IA), table des incompatibilités, procédure d’arrivée, de mobilité et de départ, revue des accès et indicateurs calculés. Les exemples sont fictifs et des lignes vierges sont prévues pour vos propres profils. Le fichier documente une politique et des décisions : il n’attribue ni ne retire aucun droit dans vos applications.

Avant de déployer une nouvelle application, vérifiez aussi que les droits configurés correspondent à la matrice : un cahier de recette informatique peut inclure des cas où un compte non habilité tente d’ouvrir un dossier ou de valider une demande.

Tableur, annuaire ou workflow : comment outiller la gestion des habilitations ?

Un tableur suffit pour décrire la politique et préparer une première revue. Il atteint vite ses limites pour le suivi des demandes : validations par e-mail, versions multiples du fichier, preuves dispersées. Un annuaire d’entreprise ou une solution de gestion des identités (IAM) centralise les comptes et les groupes ; selon les outils, ils peuvent aussi automatiser la création des comptes dans les applications connectées.

Entre les deux, beaucoup d’organisations ont surtout besoin d’un circuit de demande et de validation fiable : un formulaire unique, des étapes attribuées au manager puis au propriétaire, une tâche d’exécution pour l’équipe informatique, des relances et un historique consultable. C’est un cas typique de gestion de workflow.

Avec l’outil workflow Softyflow, ce circuit se construit comme une application métier : formulaire de demande, tâches attribuées à des rôles, délégation datée en cas d’absence, relances programmées et journal des actions. Dans les applications créées avec Softyflow, les rôles et les groupes peuvent être distincts selon l’environnement de test, de recette et de production ; l’accès aux pages et aux données se règle par rôle ; l’authentification unique peut s’appuyer sur OpenID Connect ou SAML 2.0 ; avec SAML (Azure AD, Okta, ADFS), les comptes peuvent être créés à la première connexion et les rôles attribués à partir des groupes du fournisseur d’identité. Pour créer les comptes dans vos autres logiciels, un appel à leur API peut être paramétré avec les intégrations et connecteurs ; sa faisabilité se vérifie application par application.

Demander une démonstration à partir de votre propre circuit de demande d’accès.