Ça y est, pas mal de GHT ont déjà démarré les travaux de convergence de leur SI… Bon, OK, je reformule, pas mal de GHT ont déjà démarré les travaux de réflexion sur ce qui va devoir converger ou pas, et dans quel ordre. Bon, OK, OK, je reformule encore : pas mal de GHT ont commencé les réunions des DSI, ça vous va ?
Blague à part, sur la partie SI, si convergence il y a, nous sommes tous d’accord pour que l’initiative revienne aux métiers. De quel droit, en effet, un informaticien pourrait affirmer qu’il faut converger vers un logiciel RH unique pour la future DRH de territoire ? Si DRH de territoire il y a d’ailleurs, rien n’est moins sûr d’après ce que mes immenses oreilles me rapportent d’ici ou de là. Quand un GHT marie King Kong (un gros CH) et trois Petits Poucet (des Ehpad), certes nous concevons que le premier va facilement absorber la fonction RH des trois autres (selon le théorème d’Audiard, qui stipule que quand les types de 130 kg parlent, ceux de 60 kg les écoutent[1]). Mais quand les forces sont un peu plus équilibrées et que des CH de taille importante se trouvent dans la corbeille, c’est moins trivial. Et surtout cela prendra un peu plus de temps. Bref, dans tous les cas, c’est le métier qui commande et la DSI qui réalise, et pas l’inverse.
Cela étant, pour les projets sécurité SI, c’est un peu différent. En effet, c’est le RSSI qui est le donneur d’ordres des projets SSI (au même titre que les qualiticiens sont donneurs d’ordres des contraintes qualité, qui sont transversales), sauf si le RSSI a une fonction purement technique – et dans ce cas ce n’est pas un RSSI, mais un responsable sécurité technique, ce qui est différent (et certes utile). La question objet de ce présent article peut donc être reformulée de la sorte : le RSSI a-t-il intérêt à mettre les projets de SSO (Single Sign On) sur le dessus de la pile ?
Le SSO est une sorte de porte-clés tout clinquant que l’on vous donne en cadeau avec la grosse voiture très chère que vous venez d’acquérir : ça sert, mais ce n’est pas l’essentiel. Le SSO est un sous-ensemble d’un projet plus vaste nommé IAM (Identity and Access Management), que l’on peut résumer de deux façons :
- La version « manager friendly », qui consiste à automatiser la gestion des identités et des habilitations au sein de l’établissement afin d’optimiser les processus et les ressources dans une optique de synergie des équipes ;
- La version « unplugged », soit une grosse opération de nettoyage des écuries d’Augias que représente généralement l’annuaire technique de l’établissement (le fameux AD).
En d’autres termes, dans un projet d’IAM, l’enjeu principal est le nettoyage de l’AD (supprimer les identités des agents ayant quitté la structure) et la refonte des processus d’arrivée et de départ des agents pour que l’annuaire RH soit connectable en temps réel à l’AD (la place me manque ici pour décrire tous les impacts, mais dans un CH même de taille moyenne, c’est souvent du sport).
En conclusion, il y a deux réponses à la question posée par l’article. Si le top management est conscient que RH et AD ont besoin d’un petit lifting conjoint, alors c’est par là qu’il faut commencer… et terminer par le SSO (qui peut être vu comme une sorte de bénéfice collatéral d’un projet IAM). Si ce n’est pas le cas, il faut dire que l’on va faire du SSO… et une fois que le top management a tourné la tête, il faut s’attaquer dare-dare au couple RH/AD.
Mais ces considérations ne tiennent pas compte de la situation des autres établissements : si l’établissement support a déjà déployé un projet IAM, les autres établissements n’ont pas d’autre choix (à moins d’être très très joueurs) que d’acquérir la même solution logicielle. Et dans ce cas, exit le SSO, il faudra commencer par le nettoyage RH/AD. Et les questions de circuit de délivrance des habilitations risquent de vous occuper pendant un bon moment.
source : http://www.dsih.fr