Nous allons voir ensemble les 10 règles pour réussir la mise en œuvre d’une solution d’IGA.

Règle n° 1 : Comprendre ce qu’est l’IGA

Un projet d’IGA n’est pas uniquement un projet technique. Il s’agit d’un projet qui couvre de nombreux aspects fonctionnels comme la gestion du cycle de vie des identités, la gestion des habilitations informatique, la mise en place d’outils de gouvernance (Rapport, BI, Recertification, Gestion des écarts, etc.), et l’administration des accès aux applications. Ce type de projet, en plus de faire intervenir la DSI, nécessite de faire contribuer des personnes comme les RH ou les managers. Ce projet sera aussi l’occasion de mettre à plat ou de faire évoluer certains de vos process.

Règle n° 2 : Choisir son Business Driver

Afin de pouvoir prendre les bonnes décisions lors du projet, il est important que vous définissiez bien votre besoin principal. Est-ce la gestion des identités ? La création des habilitations de vos collaborateurs ? La gouvernance des habilitations ? L’amélioration de la sécurité informatique ? La maîtrise des coûts des licences SaaS ?

Règle n° 3 : Adopter une approche itérative

Plutôt que d’attendre d’avoir une solution complètement opérationnelle, il est préférable d’ouvrir le service le plus rapidement possible pour récolter au plus tôt les retours utilisateurs. Cela permet d’éviter la mise en œuvre de solutions complexes qui ne répondent pas aux besoins des utilisateurs. Cela permet aussi de faire monter en compétence progressivement les administrateurs de l’application.

L’agilité permet d’avoir des victoires rapides en lien avec le business driver que vous avez défini.

Règle n° 4 : Séparer le Build du Run

Ce n’est pas parce que la solution d’IGA est en production qu’il n’est pas possible de la faire évoluer. Par exemple, il est tout à fait possible de connecter de nouvelles applications à la solution d’IGA une fois en production. Ainsi, il n’est pas nécessaire d’attendre d’avoir connecté toutes les applications pour passer en production.

Règle n° 5 : Identifier les données de référence

Afin d’avoir une solution opérationnelle, il est essentiel d’identifier au plus tôt toutes les données nécessaires à l’alimentation de la solution. On peut citer par exemple les informations RH pour les collaborateurs internes, les informations concernant les prestataires, les données organisationnelles, les applications ou les dotations que l’on souhaite gérer dans la solution d’IGA, etc. On parle alors de données « autoritaires ».

Règle n° 6 : Faire simple

L’un des risques des projets d’IGA est d’essayer de répondre à tous les cas particuliers.

Par exemple, les process peuvent être complexes, avec beaucoup d’acteurs. Alors, le temps de traitement des demandes se trouve considérablement augmenté. Autre exemple, certains process de l’entreprise ne sont pas complètement opérationnels ; ce n’est pas en les digitalisant que les problèmes vont disparaître.

En d’autres termes, il est préférable de mettre en œuvre de préférence des process simples qui répondent aux besoins du plus grand nombre.

Règle n° 7 : Construire le modèle de rôle progressivement

Pour construire un modèle de rôle, la première étape consiste à faire l’inventaire des habilitations techniques de vos applications. C’est l’occasion de faire un grand nettoyage dans vos applications.

Ensuite, il faut faire correspondre ces habilitations techniques à une habilitation fonctionnelle, compréhensible et accessible à vos collaborateurs.

Il est alors possible d’aller plus loin en affectant automatiquement des habilitations aux collaborateurs soit grâce à votre connaissance des habilitations dans votre entreprise, soit à l’aide d’un outil adapté (comme le role mining) qui va analyser la distribution des habilitations pour vous aider à construire un modèle de rôles a posteriori.

Enfin, même en production, le modèle de rôle est quelque chose qu’il faut faire vivre en même temps que les applications de votre système d’information.

Règle n° 8 : Définir les connecteurs à configurer

Il est possible de connecter n’importe quelle application à une solution d’IGA. Mais toutes les applications ne le seront pas forcément. Les limites peuvent être liées au planning ou au budget du projet. Les limites peuvent aussi être techniques : il est toujours possible de lire les données d’une application, mais il n’est pas toujours possible d’écrire dans certaines applications (pas d’interface, application ancienne, etc.).

Enfin, il faudra privilégier la configuration de connecteurs qui vont vous apporter le plus de valeur (sécurité, coûts des licences, etc.) et se poser systématiquement la question du coût de mise en place du connecteur par rapport au gain. Les gains liés à la création automatique des comptes et des droits applicatifs peuvent être multiples : gain financier, gain de productivité, augmentation de sécurité, gain de mise à disposition de l’application.

Règle n° 9 : Commencer par la gouvernance

Même si l’objectif est de gérer les habilitations de vos collaborateurs, il peut être intéressant de commencer par la gouvernance.

Dès que les données des collaborateurs et de vos applications sont chargées dans la solution d’IGA, il est possible de faire le nettoyage des comptes orphelins, et l’analyse des écarts. On peut aussi lancer des campagnes de recertification des habilitations.

Ainsi, même si la solution d’IGA n’a pas la capacité de gérer complètement les habilitations de vos collaborateurs, en mettant en place la gouvernance, la solution d’IGA est capable de vous apporter beaucoup de valeur avec en particulier des gains financiers directs en supprimant les licences inutilisées.

Règle n° 10 : Choisir le bon produit

Afin que votre projet soit une réussite, il est important de choisir le bon produit. Nous vous recommandons de choisir une solution qui couvre nativement la plupart des besoins de votre projet de façon standard. La solution doit être moderne et innovante. N’hésitez pas à demander à rencontrer d’autres clients qui ont des besoins similaires aux vôtres, pour vous rassurer, mais aussi pour apprendre de leur retour d’expérience.

Enfin, dans la mesure où une solution IGA est une brique structurante du SI, il ne faut pas se contenter du discours commercial. Il faut absolument demander la mise en place d’un « Proof of Concept » sur votre SI. Cela consiste à installer la solution dans votre environnement et à vérifier que tous les points sont couverts. Il est recommandé d’assister à toutes les étapes du POC afin de se faire une idée sur la complexité de mise en œuvre de la solution.

Enfin, il est recommandé de choisir une solution SaaS.

Par Jean-Christophe CLEMENT, Chef de projet chez USERCUBE