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

Face au nombre croissant d'accès à accorder, nous devons arriver à élaborer un système d'autorisations qui ne soient pas statiques. Il doit dépendre de conditions qui, si elles sont satisfaites, permettent d'activer dynamiquement les autorisations. Dans ce cas, nous parlons souvent d'autorisations contextuelles. Ainsi, les autorisations peuvent dépendre de contextes temporels (par exemple permission pendant les heures de travail), de contextes géographiques (par exemple, permission à l'intérieur de l'enceinte sécurisée de l'entreprise), de contextes provisionnels (permission si d'autres actions ont, au préalable, été réalisées comme dans le cas d'un workflow). D'autres types de contextes peuvent également être définis. Pour représenter ces autorisations contextuelles, plusieurs modèles de contrôle d'accès à base de règles ont été proposés (modèles de type Rule-BAC). Dans ces modèles, une politique d'autorisation correspond à un ensemble de règles de la forme condition permission qui spécifient qu'une permission peut être accordée lorsqu'une certaine condition est satisfaite. Les modèles de type Rule-BAC sont en quelque sorte les fondations logiques des autres modèles d'autorisations d'accès. Elles reposent sur une logique du premier ordre^1(*) qui est indécidable. Leur formalisme théorique ne permet pas la structuration d'une politique d'autorisation avec l'introduction des concepts de rôle, d'activité, de vue et d'organisation. Cette structuration est indispensable pour être exploitable rapidement. Le modèle Or-BAC offre également la possibilité d'exprimer des autorisations contextuelles. Pour cela, le concept de contexte est explicitement introduit dans le modèle (Cuppens et Miège 2003). La définition d'un contexte correspond à une condition logique qui permet de conclure que l'on se trouve dans un contexte particulier lorsque cette condition est satisfaite. Remarquons que chaque organisation définit ses contextes. Ceci permet de modéliser la définition d'un contexte tel que la population rattaché peut varier d'une organisation à une autre.

Comme nous l'avions déjà souligné, alors que les applications informatiques structurent de plus en plus les modes d'organisation des entreprises, aucune démarche n'est mise en oeuvre lors de la conception du système d'information pour optimiser la productivité et le confort des utilisateurs finaux. Dans un article parue dans le journal « Entreprise et Carrières » (Nogier et Helderlé 2006), JF Nogier regrette que l'ergonomie soit le parent pauvre de l'informatique. L'ergonomie, ce n'est pas seulement l'esthétique des pages mais aussi la façon d'accéder aux écrans nécessaires à la tâche à accomplir par l'utilisateur. Il explique cette lacune par le fait que la démarche de conception des systèmes d'information est généralement descendante. Des experts porteurs des déclinaisons métiers des applications informatiques vont spécifier le besoin à partir de leur propre connaissance du domaine. Les utilisateurs n'interviennent qu'à la fin du projet, généralement lors de la recette.

En fait, l'ergonomie informatique est méconnue. En France, l'ergonome a souvent l'image d'un chercheur. Les formations au métier d'ergonome sont encore trop théoriques. Or le métier d'ergonome informatique est typiquement un métier transverse. Il nécessite une formation adaptée et pluridisciplinaire lui permettant de comprendre les différents aspects de la conception d'un produit logiciel. De plus, de nombreuses normes encadrent maintenant l'ergonomie.

Des outils difficiles à utiliser ont un impact direct sur la productivité. Le risque est de délivrer des solutions trop complexes dont la cinématique et les fonctionnalités n'ont pas été validées dans le contexte réel d'utilisation. L'appropriation de l'outil par les utilisateurs finaux est difficile. L'entreprise doit mettre l'accent sur la formation avec des surcoûts à la clé.

Ici encore, comme pour la gestion de la confidentialité, nous nous apercevons que la notion de contexte à toute son importance pour composer l'environnement de travail.

La gestion des accès pourrait-elle fournir le « contexte » dont l'ergonomie a besoin ?

Il nous apparait maintenant utile de préciser le périmètre de la gestion des accès que nous allons étudier.

La sécurité des systèmes d'information a longtemps été considérée comme l'apanage des équipes systèmes et réseau. Cette vision est aujourd'hui dépassée. Les logiciels d'infrastructure comportent de moins en moins de failles, tandis que les processus de sécurisation des systèmes sont aujourd'hui matures.

Toutes les applications devant être utilisées par plus d'une personne dispose d'une gestion des accès. Du blog jusqu'à l'ERP. Elle permet de contrôler la manière dont un utilisateur se connecte à l'application. Elle traite des sujets tels que l'authentification, le filtrage des accès en fonction de l'utilisateur, la méthode d'authentification utilisée, le type de poste de travail, sa localisation ou encore la délégation des accès ou l'audit centralisé des accès.

Authentification : Processus consistant à s'assurer de l'identité d'un utilisateur, portant sur un des trois fondamentaux suivant (Debaes, Pezziardi et Vincent 2007) :
- ce que je sais : un secret que je suis le seul à connaitre, tel un mot de passe, un code PIN ;
- ce que je possède : un objet physique que je suis le seul à posséder, comme une carte à puce ;
- ce que je suis : une caractéristique corporelle que je suis le seul à posséder comme l'empreinte digitale ou l'iris.

Nous n'étudierons pas ces dispositifs puisque notre étude portera sur la question suivante : à quoi a-t-on le droit d'accéder ?

Elle se focalise principalement sur la création des attributs de l'identité de l'utilisateur. Cela concerne ses attributs métiers qui définissent sa place au sein de l'entreprise et apparaissent dans l'annuaire LDAP de l'organisation, mais aussi ses attributs techniques tels qu'ils sont déclarés dans les systèmes informatiques.

Elle permet de définir une politique des accès et de l'appliquer pour la gestion des accès et la gestion des identités après l'authentification.

La définition commune de l'ingénierie est l'« ensemble des activités qui concourent à la conception et à l'élaboration d'un projet industriel » (Encarta® 2008 2007). Nous souhaitons que notre problématique aboutisse à une ingénierie des rôles. Notre intention est d'élaborer à partir des rôles de l'utilisateur qui se connecte, un système d'autorisations qui ne soient pas statiques mais qui dépendent de conditions qui, si elles sont satisfaites, permettent d'activer dynamiquement les autorisations. Il va s'agir pour nous de préparer et de combiner un ensemble d'activité qui va nous permettre d'élaborer et de concevoir une description des rôles qui répondent à notre but.

Vous trouverez dans la figure ci-dessous la carte des buts que nous visons pour construire cet environnement de travail dynamique. Il s'appuie à la fois sur les buts de l'ergonomie et sur les buts de la confidentialité.

Pour les buts de la confidentialité, nous nous sommes appuyés sur les possibilités du framework technologique du SIRH que nous allons étudier.

Le National Institute of Standards and Technology (NIST) avait commandé en 2002 une étude sur les impacts économiques de l'adoption du dispositif R-BAC dans les systèmes d'informations (Gallager, O'Connor et Kropp 2002). Les bénéfices de l'adoption de la mise en oeuvre d`un R-BAC sont les suivants :

Comme vous pouvez le voir ce sont surtout des gains de productivité. Nous pensons aussi que l'ingénierie des rôles avec un dispositif R-BAC peut aussi apporter une valeur ajoutée au système qui l'implémente.

Pour les éditeurs et les intégrateurs, l'implémentation d'un dispositif R-BAC va permettre à l'utilisateur final de lui fournir uniquement les écrans dont il a besoin pour son rôle dans l'entreprise et « créer » pour lui une « application » correspondant à son rôle dans l'entreprise.

Cette possibilité de fournir une application sur mesure à chaque utilisateur pourrait permettre d'élaborer un nouveau système de licence et de facturation à partir des rôles. Plus le rôle dispose de privilège plus le tarif est élevé et inversement moins il a de privilège plus le tarif est bas. Ce dispositif de facturation pourrait être envisagé et fournir un nouveau business-model pour le marché du logiciel en ligne de type ASP ou SaaS (Barathon 2007). Il a représenté 1230 M € pour la France en 2007.

En conclusion, il nous faut réussir à identifier les utilisateurs par leurs rôles dans les processus métier pour les raisons illustrées dans la figure suivante :

Figure 5 : d'après M.Mersiol (LAAS-CNRS) Club SEE Systèmes Informatiques de Confiance Journée « Facteurs Humains » 19/04/2001

Le rôle est un objet à la croisé des mondes : il va nous permettre d'agréger des concepts techniques, théoriques et fonctionnels et de les faire converger vers une solution méthodologique.

Pour notre étude de cas sur la mise place d'un accès basé sur les rôles, nous allons étudier le système d'information des ressources humaines HRA Suite 7. Son évolution illustre les grandes tendances des systèmes d'informations depuis plus de trente ans^2(*).

GIP^3(*) a été créé par la compagnie Générale d'Informatique. GIP a suivi les grandes tendances du moment. Il s'agit avant tout d'un progiciel de paie hautement paramétrable et ceci dès la fin des années 1960. Chaque élément participant au calcul de la paie était stocké dans un fichier paramètre séquentiel appelé « sous-fichier ». Ensuite lorsqu'est venue l'époque des Ateliers de Génie Logiciel et de ses générateurs de codes, la CGI a intégré le L4G Pacbase à l'environnement de développement de GIP.

Ce produit n'était rien de plus qu'un générateur de COBOL qui permettait de produire des états et des programmes « batch » de façon automatisée en s'appuyant sur la méthode de programmation phare de l'époque : CORIG. C'est d'ailleurs de là que vient le nom de PAC qui signifie « Programmation Automatique "Corrigée" »

Pour la petite histoire, Pacbase aurait été imaginé par des informaticiens travaillant au ministère des finances. Ils n'étaient pas très doués en programmation Cobol et un peu fainéants et ont eu l'idée de concevoir un programme qui leur permettrait d'écrire les applications à leur place. Le premier atout de PAC se comprend très vite : le code est généré automatiquement donc les risques d'erreurs de syntaxe sont minimes. Les créateurs du produit fondent la CGI et très vite PAC700 connait un essor important car il est disponible pour presques toutes les plateformes de développement de l'époque (BULL, IBM, etc...).

Le produit va être rebaptisé PACBASE et son noyau est constitué par le dictionnaire qui est LE référentiel des données informatiques de l'entreprise. Différents modules sont venus se greffer au fil des évolutions technologiques (pacbase.free.fr 2003-2008).

GIP fonctionnait avec des « squelettes » de programmes COBOL qui contenait les traitements « génériques » de paie. La CGI ayant intégré l'environnement Pacbase à GIP, cela lui permettait d'ajouter des traitements complémentaires dans des « contextes ». Les contextes sont des emplacements particuliers dans les différents squelettes COBOL^4(*).

La gestion de la Paie est une application longue et complexe à développer en interne. C'est pour cela que GIP est un des premiers progiciels qui a connu un grand succès bien avant SAP.

Chaque génération de GIP s'est adaptée aux technologies du moment. Lorsque les tables relationnelles sont apparu, GIP devenue SIGAGIP l'a presqu'immédiatement adopté. Les « sous-fichiers » sont devenus des tables relationnelles. Hormis pour les données devant être traitées par lots (batchs) qui reste stockées dans des fichiers séquentiels ou séquentiels indexés, tout le reste est stocké dans des tables relationnelles, y compris les sources Pacbase.

Lorsque l'époque du client/serveur est arrivée, SIGAGIP est devenue SIGAGIP/CS. C'est aussi à cette époque de la CGI a été racheté par I.B.M.

La Figure 6 présente l'architecture générale de SIGAGIP/CS qui est devenu HR-Access V1 après son rachat par IBM.

Cette architecture a trois niveaux a permis, de faire évoluer à leur rythme chacun des niveaux qui eux-mêmes reposait sur des technologies différentes : le poste client (de Windows au client web), le serveur (du Mainframe, unix ou AS/400), et la base de données ( DB2, Oracle...). Cette architecture à trois niveaux permet de s'adapter à l'architecture technique du client.

Il n'y a pas que l'architecture technique qui a évolué, le modèle conceptuel des données à aussi évolué.

Le modèle conceptuel de données (MCD) a pour but d'écrire de façon formelle les données qui seront utilisées par le système d'information. Il s'agit donc d'une représentation des données, facilement compréhensible, permettant de décrire le système d'information à l'aide d'entités. Il ne se préoccupe pas des contraintes d'organisation et techniques.

Ce MCD met en évidence les entités présentes dans l'application, ainsi que les relations qu'elles ont entre elles. Nous obtenons pour le modèle « fonction public » le schéma suivant :

Un Agent occupe un Poste. Un poste requiert des compétences et un agent détient également des compétences. De plus, un poste est associé à un emploi de référence qui fait lui-même partie d'une filière. Enfin un agent appartient aussi à une filière bien déterminée.

La Figure 7 illustre comment sont représenté les données. La notion de dossier de gestion permet de rassembler les données connues sur l'objet à gérer. La notion de dossier réglementaire permet de rassembler des données organisées de façon simple comme un code et un libellé par exemple. Les dossiers des salariés sont des dossiers de gestion alors que la description des données de références (comme le paramétrage) sont des dossiers réglementaires.

Figure 7 : le modèle conceptuel des données pour la gestion du personnel avec HR-Access

Au cours de ces quarante années d'existence, HR-Access est devenue une solution applicative intégrée dédiée au domaine de la Gestion des Ressources Humaines.

Ce modèle de données constitue véritablement le socle du Système d'Information et permet une véritable approche globale et intégrée de la gestion des Ressources Humaines, de l'Administration du Personnel et de la Paie pour toutes les populations gérées : chaque information est décrite de manière unique et est ensuite utilisable dans tous les domaines fonctionnels et tous les modèles applicatifs proposés avec HR Access. Cette architecture est la seule capable d'assurer une cohérence complète du Système d'Information Ressources Humaines.

HR Access est une solution applicative organisée en modèles applicatifs dont la cohérence est assurée par le modèle de données

Afin de proposer une offre applicative proche des attentes de ses clients (c'est à dire dans laquelle les utilisateurs se reconnaissent), l'éditeur IBM a dû organiser les fonctionnalités proposées en modèles de gestion dédiés à certains secteurs.

En particulier HR Access propose un modèle applicatif pour le Secteur Public et un modèle applicatif pour le secteur Privé.

L'ensemble des fonctionnalités nécessaires pour couvrir les besoins de La Poste s'appuient sur deux modèles applicatifs proposés par HR Access (Droit Privé, Droit Public).

* ⁴ Encore sur la Suite 7, ce principe est encore utilisé pour tous les traitements se faisant sur le serveur.

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

Définir des Modèles d'autorisations dynamiques et contextuelles