Allouer les ressources : moins de techniques, plus de worklow ?

Toujours dans le dossier 01 Informatique du 15/11/2007 consacré à la gestion des identités, un article indique l'importance vitale du workflow et du self-service afin que l'utilisateur puisse demander lui-même l'attributation de certaines ressources après validation des acteurs adéquats et cet article laisse à penser que le provisioning de ressources est chose aisée.

Il est vrai que l'une des briques importantes est le moteur de workflow et qu'il est attendu que ce moteur soit de bonne qualité pour s'adapter au métier de l'entreprise. Remarquons qu'à ce stade, la gestion des identités recouvre, quel que soit le métier de l'entreprise, les mêmes processus : arrivée / mutation / départ d'une Personne... il est donc attendu que le workflow puisse s'appuyer sur une organisation spécifique (propre à chaque entreprise), offrir des IHMs de validation paramétrables, prendre en compte le modèle de droits de l'entreprise...

Pour autant, de nombreux grands comptes ont déjà mis en oeuvre des systèmes de workflows dans le cadre de dématérialisation de processus internes et il peut être légitime de se poser la question de savoir s'il n'est pas plus judicieux d'appuyer un système de workflow connu de l'entreprise à un outil de provisioning du marché. Il n'existe pas de réponse type à cette question. Chaque entreprise devra étudier l'intêret ou non de ré-utiliser un workflow connu plutôt que celui inclu dans l'outil de provisioning. On peut toutefois noter que, évidemment il n'y a pas de prise en main de l'outil de workflow car il est déjà connu mais il sera nécessaire de mettre en oeuvre un interfaçage avec l'outil de provisioning. A l'inverse, si l'on retient l'outil de workflow inclu dans l'outil de provisioning, il sera nécessaire de prévoir une phase de prise en main de ce moteur de workflow et de prévoir potentiellement un interfaçage avec l'outil de workflow déjà retenu au sein de l'entreprise. L'un des critères de choix de prendre ou non le moteur de workflow inclu dans la solution de gestion des identités est aussi le fait que ce moteur de workflow est déjà pré-packagé pour la gestion des identités ce qui n'est pas forcément le cas pour un moteur de workflow standard. A l'inverse, il sera difficile de faire autre chose que de la gestion d'identités avec un moteur de workflow de gestion d'identités.

Au final, ce qu'il faut retenir c'est que la complexité ne provient pas de la technique. Implémenter un workflow avec un processus bien décrit n'est pas extrêmement difficile s'il a été bien spécifié. La difficulté provient de l'organisation à mettre en place pour être acteur de ces processus et surtout des modifications d'organisations qui auront un impact fort sur les processus.

Le fait de donner la possibilité à l'utilisateur final de demander l'attribution à des ressources me paraît à mon sens être une hérésie à plusieurs titres :
- ceci va à l'encontre de la définition de rôles métiers puisque l'utilisateur demandera l'accès à des ressources et non l'attribution d'un rôle métier (laisser la possibilité à l'utilisateur final demander un rôle métier aurait encore moins de sens).
- ceci amène un niveau de complexité à l'utilisateur final qui n'est pas forcément apte à comprendre l'objet de la demande : comment l'utilisateur sait choisir quel est le bon accès auquel il devrait avoir droit au sein d'une application?

Au pire, il devrait pouvoir être créer une IHM pour l'utilisateur final permettant de demander l'attribution de certaines ressources spécifiques connues de tous et ne nécessitant pas de connaissances spécifiques à l'avance.

Concernant le provisioning, je m'étonne qu'on puisse dire que cela soit chose aisée. En effet, les solutions de gestion des identités offrent des connecteurs de provisioning pour systèmes d'exploitation, les annuaires, les SGBDs, les ERPs et c'est à près tout. Or plus de 80 % des applications d'un SI s'appuient sur des progiciels spécifiques ou des développement à façon ce qui complexifie énormément la tâche de provisioning.
A mon sens, provisioner une application devrait être le choix de dernier recours et ne devrait être effectué que si le jeu en vaut économiquement la chandelle. Je reviendrais dans un prochain billet sur comment on peut éviter les problématiques de provisioning en faisant un peu d'architecture.