Confidentialité et ergonomie, personnaliser l'accès au SIRH avec RBAC

1 Introduction

1.1 Les rôles : clés des nouveaux paradigmes des accès au système d'information

Le système d'information n'existe pas pour lui-même, mais pour rendre service à un utilisateur ou un groupe d'utilisateurs. C'est l'utilisateur qui déclenche le processus de gestion. C'est lui qui donne ou reçoit les informations du système d'information (S.I). L'utilisateur qui donne les informations en entrée peut ne pas être le même que l'utilisateur qui déclenche le processus ou celui qui bénéficie du résultat. L'utilisateur n'est pas le même parce qu'il a un rôle différent dans le processus d'entreprise. Dans cette étude nous nous intéresserons au rôle comme moyen d'accès au SI.

Depuis plusieurs années, de plus en plus d'auteurs font appel aux rôles pour modéliser les processus d'entreprise. Nous pouvons prendre par exemple la multi-méthode EKD-CMM élaboré par le CRI à l'IAE de Paris.

Dans la façon de modéliser d'EKD-CMM, les entreprises forment des réseaux de processus reliés afin d'atteindre leurs objectifs. Ce qui se passe dans les processus est regardé en termes de rôle que les individus ou les groupes jouent afin de réaliser leurs tâches. Les utilisateurs exécutent des activités pour atteindre les objectifs de l'entreprise. Les activités sont portées par des rôles différents suivant les processus métier. Le modèle d'acteur/rôle vise à décrire comment des acteurs sont reliés à chaque autre et ainsi qu'aux buts. Ce modèle de rôle/activité est utilisés dans EKD-CMM pour définir les processus d'entreprise, la façon ils consomment ou produisent des ressources pour atteindre les objectifs de l'entreprise.

Alors que EKD-CMM utilise les rôles pour participer à la définition du système à construire, notre approche des rôles sera différente pour plusieurs raisons. Le système d'information que nous souhaitons implémenter pré-existe, il s'agit d'un système d'information des ressources humaines (SIRH). Il couvre 85 % du besoin. Des adaptations seront à faire, mais une infrastructure technique et un ensemble d'outils sont disponible. Les rôles doivent nous servir définir les accès à l'infrastructure et aux outils nécessaires à un groupe d'utilisateur devant exercer les mêmes tâches. Il s'agit donc d'une définition à posteriori des rôles. Cette définition des rôles nous la voudrions dynamique afin qu'elle s'adapte aux contextes du sujet qui utilise le rôle.

1.2 Trouver comment conjuguer confidentialité et ergonomie avec l'ingénierie des rôles

Nous avons vu que les applications informatiques en entreprise doivent être maintenant accédées par une multitude d'utilisateurs. Ces utilisateurs ont des attentes et des besoins différents par rapport à cette application. Ces attentes et ces besoins peuvent être regroupées et liées dans des rôles. D'autres contraintes que les attentes et les besoins de l'utilisateur doivent être prise en compte. Ce sont les contraintes de confidentialité et les contraintes d'ergonomie. Pour être ergonomique, l'interaction Homme-Machine à besoin d'un contexte. Les rôles et l'organisation de l'utilisateur peuvent fournir le contexte recherché.

Il va donc s'agir pour nous, d'identifier les rôles et d'identifier les entités nécessaires aux tâches de l'utilisateur. Ainsi, l'utilisateur ne verra que ce qu'il a le droit de voir et ne pourra effectuer que des tâches et des actions déterminées sur des populations dédiées selon le profil qui lui a été attribué. De façon induite, le contrôle d'accès basé sur les rôles procure une ergonomie adaptée à chaque utilisateur: Une interface utilisateur orientée métier. C'est l'ergonomie qui guide l'élaboration du R-BAC et non plus la sécurité.

Formulé différemment, cette démarche d'« ingénierie des rôles » reposera sur la gestion des habilitations et la gestion de la sécurité.

La gestion des habilitations se base sur la définition de trois grands principes :

- Les droits d'actions

Scénario : L'utilisateur X a le droit de créer un dossier dans le cadre du processus d'Embauche.

- Les droits d'actions dans quel périmètre

Scénario : L'utilisateur X a le droit d'effectuer une action d'embauche uniquement dans le site A.

- Les acteurs des actions

Scénario 1 : Acteur 1 est un utilisateur ayant les habilitations d'Expert Formation en charge uniquement de la Formation dans le site A

Scénario 2 : Acteur 2 est un utilisateur ayant les habilitations de Gestionnaire GA et Gestionnaire formation pour le site A.

L'attribution des habilitations à un acteur se fera en fonction de ses attributions métiers. Par exemple, un Gestionnaire Paie qui dans ses attributions n'est en charge que de la Paie ne se verra attribuer que les habilitations liées à la Paie.

La sécurité dans la gestion des habilitations garantie :

- La qualité des données

Exemple : C'est le fait de s'assurer que les données modifiables ne le sont que par les utilisateurs ayant reçus les habilitations.

- La confidentialité des données

Scénario 1 : C'est de s `assurer qu'un gestionnaire en charge de la paie ne verra que la paie de son site d'affectation.

Scénario 2 : C'est de s'assurer qu'un gestionnaire qui n'est pas en charge de la paie des cadres dirigeants ne puisse pas voir la population des cadres dirigeants.

Scénario 3 : S'assurer que des données médicales qui font partie du dossier médical de l'agent ne soit visible que par le médecin du travail.

Les applications du SIRH (SAP Hr et Hr Access) permettent de définir et d'attribuer des autorisations spécifiques aux utilisateurs du système selon leurs fonctions, leurs responsabilités et leur contexte d'utilisation. Pour pouvoir définir et attribuer ces autorisations, un travail en amont va être nécessaire. Par où commencer ? Quelles vont être les informations à collecter ? Comment discerner les informations utiles des informations superflues ? De quoi a-t-on besoin pour paramétrer les rôles ? L'objectif de ce mémoire va être, pour moi, de faire l'inventaire des fondations théoriques aux éléments pratiques, pour construire une méthode de travail pour définir les rôles qui permettront d'accéder au SIRH.

Comme nous venons de le voir, le fait d'utiliser des scénarios est une approche intéressante. Elle permet d'expliquer concrètement les aspects d'un problème. Elle est proche des attentes de l'utilisateur. Nous pensons qu'elle nous permettra de trouver les éléments que nous recherchons pour construire le paramétrage des rôles dans notre application.

2

2 Quelle solution pour personnaliser l'accès au système d'information

2.1 Comment différencier les accès au système d'information de l'entreprise ?

De nos jours, les progiciels métiers ont envahi le quotidien des employés et cadres de l'entreprise. Ces progiciels en sont à leur troisième, voire énième version. Chaque nouvelle version étant enrichit de nouvelles fonctionnalités issues de la capitalisation faites sur des projets d'implémentations majeurs, d'autres venants d'un logiciel racheté par l'éditeur à un autre éditeur. Les multiples fonctionnalités rajoutées à chaque génération ont fait des progiciels un énorme framework qui répond à un maximum de besoins d'une ou de plusieurs directions de l'entreprise.

Ce qui est bien pour le niveau stratégique ne l'est pas nécessairement pour le niveau opérationnel. Avoir accès à une centaine d'écrans peut nuire à la productivité de l'utilisateur final. Un travail est à faire sur l'ergonomie de l'application. D'autre part, avoir accès à des centaines d'écrans implique que l'utilisateur peut accéder à des pages qui ne le concernent pas à plus d'un titre. Il y a donc un travail à faire sur la confidentialité.

Figure 1 : Les buts des utilisateurs sont différents lorsqu'ils accèdent au S.I.

La figure 1 illustre notre propos : Comment différencier les accès au système d'information de l'entreprise ? Notre réponse est d'expliquer comment le rôle de l'utilisateur dans l'entreprise peut être un critère discriminant d'accès à ce S.I.. Pour certains S.I. il faut gérer des milliers, voire plusieurs milliers d'utilisateurs. L'objet de cette étude va être de trouver des attributs discriminants de l'utilisateur pour industrialiser la gestion des accès aux entités du S.I. : accès aux données qui relève du domaine de la confidentialité et accès aux autres composants du S.I. (pages, actions fonctionnels, workflows...). Il s'agira de proposer une ingénierie des rôles (He 2007)

2.1.1 les nouvelles tendances RH imposent de déléguer certaines tâches à différentes catégories d'acteurs dans l'entreprise

Cette différenciation des accès devient un enjeu majeur avec la délégation de certaines tâches de saisie directement par les intéressés eux-mêmes.

Jusqu'à présent le problème des accès aux systèmes d'information pouvait être éludé par le fait que chaque groupe d'utilisateurs avait son application. Une application de saisie des temps pour les salariés, était interfacée avec une application de gestion des plannings, qui était interfacée avec l'application de gestion administrative pour les gestionnaires RH, qui elle-même était interfacée avec une application paie pour les gestionnaires Paie. Ces multiples applications avec leurs interfaces faisaient les beaux jours des urbanistes.

Figure 2 : à chaque groupe son application

Maintenant ces différents processus métiers sont inclus dans un même système d'information des ressources humaines (comme c'est le cas d'HR Access Suite 7 qui sera le support de notre étude de cas.

Autrefois, les applications étaient bien compartimentées puisque sur de systèmes différents. Qu'en est-il maintenant que tout a été regroupé sur un même système ? Exigences juridiques à prendre en compte en plus des exigences métier. Quelle méthode pour définir nos accès utilisateurs ?

Exigences juridiques des accès au S.I.

Tout le monde ne doit pas tout voir

Les exigences de confidentialité sont réglementées en France. La CNIL a publié un guide de travail où elle indique les sept principes clés de la confidentialité du SIRH (CNIL Commission Nationale Informatique et Liberté 2005).

Le principe de finalité

Les données à caractère personnel ne peuvent être recueillies et traitées que pour un usage déterminé et légitime. (...)Tout détournement de finalité est passible de sanctions pénales. De même, l'ensemble des objectifs poursuivis dans le cadre de l'informatisation doit être clairement exprimés (...).