À retenir

• Le role mining analyse les droits d’accès déjà attribués dans un système d’information pour en déduire des rôles cohérents, réutilisables dans un modèle RBAC.
• Trois approches coexistent : top-down (partir du métier), bottom-up (partir des données), et hybride — la plus réaliste en pratique.
• C’est d’abord un problème de qualité de données : sans nettoyage préalable, on ne fait qu’industrialiser le désordre existant.
• Le piège principal est l’explosion des rôles. La validation métier et une gouvernance dans la durée sont ce qui distingue un projet réussi d’un échec coûteux.
• Le role mining sert à passer d’une attribution manuelle des droits à un modèle structuré ; il se combine avec l’ABAC pour les accès qui dépendent du contexte.

Introduction

Dans la plupart des organisations, les droits d’accès se sont accumulés au fil des années, attribués au cas par cas, à la main ou semi-automatiquement. Le résultat est connu : des utilisateurs qui cumulent des permissions héritées de postes précédents, des accès accordés « le temps d’un projet » jamais retirés, et personne capable de dire qui a accès à quoi, ni pourquoi.

Le role mining est la démarche qui consiste à remettre de l’ordre dans cet existant en en dérivant des rôles : des regroupements de permissions qui correspondent à des fonctions réelles dans l’organisation. Cet article s’adresse aux architectes et chefs de projet IAM qui doivent mettre en place ou rationaliser un modèle de contrôle d’accès basé sur les rôles. Il détaille ce qu’est réellement le role mining, les approches disponibles, une méthode pas à pas, et les erreurs qui font échouer ces projets.

Qu’est-ce que le role mining ?

Le role mining (« fouille de rôles ») désigne l’analyse des attributions utilisateur–permission existantes afin d’en extraire un ensemble de rôles pertinents. Concrètement, on part de la matrice qui relie chaque utilisateur aux permissions qu’il détient, et on cherche à la réorganiser : au lieu d’attribuer des dizaines de permissions individuellement à chaque personne, on regroupe les permissions en rôles, puis on affecte les rôles aux personnes.

Role mining, RBAC et role engineering : ne pas confondre

Trois notions voisines reviennent souvent et méritent d’être distinguées :

• Le RBAC (Role-Based Access Control, contrôle d’accès basé sur les rôles) est le modèle d’autorisation. Les permissions sont rattachées à des rôles, et les utilisateurs héritent des permissions via les rôles qui leur sont affectés. Ce modèle a été formalisé en 1992 par David Ferraiolo et Rick Kuhn au NIST, puis normalisé sous la référence ANSI/INCITS 359 (édition 2004, révisée en 2012 et reconduite en 2022).
• Le role engineering est le processus global de conception et de maintien d’une structure de rôles pour une organisation.
• Le role mining est une technique au service du role engineering : l’approche dirigée par les données qui extrait des rôles candidats à partir de l’existant.

Autrement dit : on fait du role mining pour alimenter une démarche de role engineering qui aboutit à un modèle RBAC.

Une distinction importante : rôle ≠ groupe

Un rôle n’est pas un simple groupe d’utilisateurs. Un groupe rassemble des personnes ; un rôle rassemble des permissions correspondant à une fonction, auquel on affecte ensuite des personnes. Cette nuance est structurante : elle conditionne la stabilité du modèle, car les fonctions de l’organisation évoluent moins vite que la composition de ses effectifs.

Pourquoi faire du role mining ?

L’intérêt n’est pas cosmétique. Une structure de rôles propre sert plusieurs objectifs concrets :

• Appliquer le moindre privilège : en repartant des besoins réels par fonction, on coupe les permissions superflues accumulées au fil du temps.
• Réduire les erreurs et accélérer le cycle de vie des identités : à l’arrivée d’un collaborateur, on affecte un rôle plutôt qu’une liste de permissions à reconstituer manuellement ; au départ ou à la mobilité, les droits suivent.
• Faciliter les recertifications : il est bien plus simple pour un responsable métier de valider « ce rôle est-il toujours justifié ? » que de passer en revue des centaines de permissions atomiques.
• Soutenir la conformité : les référentiels attendent un contrôle d’accès documenté et auditable. L’ISO/IEC 27001:2022 le traduit notamment dans les contrôles 5.15 (contrôle d’accès), 5.16 (gestion des identités) et 5.18 (droits d’accès) de son Annexe A.

Les trois approches du role mining

Approche top-down (dirigée par le métier)

On part des fonctions, des processus et des fiches de poste pour définir, en atelier avec le métier, les rôles et les permissions qu’ils devraient porter. L’avantage est la pertinence métier : les rôles ont du sens et sont défendables lors d’un audit. L’inconvénient est le coût : la démarche est longue, mobilise fortement les équipes métier, et risque de manquer des permissions réellement utilisées mais non documentées.

Approche bottom-up (dirigée par les données)

On part de l’existant — la matrice utilisateur–permission — et on applique des techniques d’analyse pour faire émerger des regroupements récurrents, qui deviennent des rôles candidats. L’avantage est l’exhaustivité et la rapidité sur de gros volumes. L’inconvénient majeur : sans garde-fou, on reproduit fidèlement le désordre existant, y compris les droits accordés par erreur.

Approche hybride (recommandée en pratique)

La plupart des projets sérieux combinent les deux : la fouille bottom-up propose des rôles candidats, que la validation top-down confronte à la réalité métier. C’est cette confrontation qui transforme un cluster statistique en rôle exploitable et justifiable.

Les techniques de fouille (bottom-up)

Côté données, le role mining s’appuie sur des familles de méthodes issues de la recherche :

• Le clustering, qui regroupe les utilisateurs aux profils de permissions similaires.
• L’analyse de concepts formels (FCA) et la décomposition de matrices booléennes, qui cherchent des structures sous-jacentes dans la matrice d’attributions.
• L’énumération de sous-ensembles et les règles d’association, qui repèrent des combinaisons de permissions fréquemment détenues ensemble.

Le cadre théorique a été posé par le « Role Mining Problem » (RMP), défini par Jaideep Vaidya, Vijayalakshmi Atluri et Qi Guo au SACMAT 2007 : trouver un ensemble minimal de rôles qui reconstitue exactement les attributions de départ. Un résultat important pour les praticiens : ce problème est NP-complet. En clair, sur un système réel, on ne cherche pas la solution mathématiquement optimale mais une solution heuristique « assez bonne » et surtout exploitable par le métier. La recherche du minimum théorique n’est ni atteignable ni souhaitable en soi.

La démarche pas à pas

Un projet de role mining suit en général ces étapes :

1. Collecte des attributions. Extraire des applications et annuaires la matrice utilisateur–permission. Cette étape révèle souvent que la donnée est dispersée et incomplète.
2. Nettoyage des données. C’est l’étape critique, et la plus sous-estimée. Les attributions de départ sont presque toujours « polluées » : droits obsolètes, comptes orphelins, exceptions individuelles. Miner sans nettoyer revient à graver le désordre dans le marbre.
3. Détection des rôles candidats. Application des techniques bottom-up pour faire émerger des regroupements.
4. Validation métier. Confronter chaque rôle candidat aux responsables fonctionnels : ce rôle correspond-il à une fonction réelle ? Les permissions qu’il porte sont-elles toutes justifiées ?
5. Intégration des contraintes de séparation des tâches. Vérifier qu’aucun rôle, ni aucune combinaison de rôles, ne crée de cumul interdit (par exemple créer un fournisseur et approuver ses paiements). La séparation des tâches est un contrôle à part entière de l’ISO/IEC 27001:2022 (contrôle 5.3).
6. Déploiement et gouvernance du cycle de vie des rôles. Affecter les rôles, retirer les attributions directes devenues inutiles, et surtout prévoir l’entretien : un modèle de rôles non gouverné se dégrade aussi vite qu’il a été construit.

Pièges et erreurs fréquentes

• L’explosion des rôles. À vouloir capturer chaque exception par un rôle dédié, on se retrouve avec presque autant de rôles que d’utilisateurs — l’inverse de l’objectif. Un bon modèle accepte une part d’exceptions gérées hors rôles plutôt que de tout modéliser.
• Le tout-bottom-up sans validation métier. Les clusters statistiques ne sont pas des rôles tant qu’un responsable n’en a pas confirmé le sens.
• Négliger le nettoyage des données. C’est la cause d’échec la plus courante. La qualité de l’entrée détermine la qualité des rôles.
• Figer les rôles. Sans processus de revue et de mise à jour, le modèle redevient obsolète.
• Confondre rôles et groupes, ce qui mène à recréer la structure organisationnelle au lieu d’une structure d’habilitations.

Role mining et outillage

Le role mining manuel sur tableur est envisageable pour un périmètre réduit, mais devient vite ingérable à l’échelle. La plupart des suites de gouvernance des identités (IGA) intègrent un module de role mining — c’est le cas, à titre d’exemples et sans exhaustivité, de SailPoint, Saviynt, One Identity, Omada, Microsoft Entra ID Governance ou Netwrix Identity Manager. Ces outils automatisent la collecte, proposent des rôles candidats et facilitent les campagnes de validation. Le choix relève d’une analyse de besoins propre à chaque organisation, qui dépasse le cadre de cet article : aucun de ces produits n’est recommandé ici en particulier.

L’essentiel à retenir : l’outil accélère la fouille, mais ne remplace ni le nettoyage des données ni la validation métier. Un bon outil sur des données sales et sans gouvernance produit de mauvais rôles plus rapidement.

Quand (et quand ne pas) faire du role mining

Le role mining a le plus de valeur lorsque l’organisation gère un grand nombre d’utilisateurs et de permissions, avec un existant historique à rationaliser, et que les accès correspondent majoritairement à des fonctions stables.

À l’inverse, quand les droits dépendent fortement du contexte (heure, localisation, sensibilité de la ressource, appartenance à un projet), un modèle purement basé sur les rôles devient lourd. Dans ces cas, le contrôle d’accès basé sur les attributs (ABAC) ou sur des politiques (PBAC) complète utilement le RBAC : les rôles couvrent le socle stable, les attributs gèrent le dynamique.

FAQ

Quelle différence entre role mining et RBAC ? Le RBAC est le modèle d’autorisation cible ; le role mining est l’une des techniques permettant de construire les rôles de ce modèle à partir des accès existants.

Top-down ou bottom-up : par lequel commencer ? En pratique, les deux en parallèle. Le bottom-up donne rapidement une photographie de l’existant ; le top-down lui donne du sens. Commencer par l’un sans l’autre expose soit à des rôles dénués de logique métier, soit à un projet qui s’enlise en ateliers.

Combien de rôles faut-il viser ? Il n’existe pas de chiffre universel : le bon nombre est celui qui couvre l’essentiel des besoins sans verser dans l’explosion des rôles. L’objectif est l’exploitabilité par le métier, pas un minimum théorique.

Le role mining supprime-t-il toutes les attributions directes ? Non. Une part d’exceptions légitimes subsiste presque toujours. L’enjeu est de les gérer explicitement et de les documenter, pas de prétendre les éliminer toutes.

Quelle place pour l’ABAC face au role mining ? Complémentaire. Le RBAC alimenté par le role mining gère les accès stables liés aux fonctions ; l’ABAC gère les décisions qui dépendent du contexte.

Conclusion

Le role mining n’est pas un exercice purement technique : c’est un projet de gouvernance qui commence par la qualité des données et se juge à la capacité du métier à comprendre et valider les rôles produits. Pour démarrer concrètement, le plus efficace est de choisir un périmètre applicatif limité et représentatif, d’en extraire et nettoyer la matrice d’attributions, puis de faire valider une première série de rôles candidats par les responsables concernés — avant d’étendre la démarche. Mieux vaut quelques rôles justes et adoptés qu’un modèle exhaustif que personne n’entretient.

Sources

• ANSI/INCITS 359, Information Technology – Role Based Access Control (édition 2004 ; révision INCITS 359-2012, reconduite R2022). Modèle RBAC du NIST, formalisé par Ferraiolo et Kuhn (1992).
• Vaidya, J., Atluri, V., Guo, Q., « The Role Mining Problem: Finding a Minimal Descriptive Set of Roles », Proceedings of SACMAT 2007, ACM, p. 175–184.
• ISO/IEC 27001:2022, Annexe A — contrôles 5.3 (séparation des tâches), 5.15 (contrôle d’accès), 5.16 (gestion des identités) et 5.18 (droits d’accès).