Le piège des habilitations

Tout d’abord, il y a les composants du SI pour lesquels nous sommes bien en peine de définir une MOA : les partages de fichiers, par exemple. Dès que l’on examine le fonctionnement de cette partie dans une organisation un tant soit peu substantielle (plusieurs centaines, voire milliers de collaborateurs), la question de la politique concernant les partages de fichiers est d’une extrême complexité : qui décide de créer un partage, pour qui, qui décidera des habilitations sur ledit partage, combien de partages au maximum par individu ou par service, quid des partages transversaux ? Sans compter qu’il est impossible, justement, de trouver une MOA unique sur cette question : autant de services, autant de pratiques. Et il en va de même pour la messagerie : boîtes aux lettres de services, etc.

Ensuite, il y a les composants du SI pour lesquels les utilisateurs sont peu nombreux et surtout très éclatés dans l’organisation. Par exemple, SAS (outil sophistiqué de requêtes sur les bases de données métiers) est utilisé par quelques personnes dans un établissement, et jamais deux dans le même service : bon courage pour écrire une politique formelle.

Il y a également les applications avec un seul utilisateur : dans ce cas, la solution est simple, sauf quand l’utilisateur en question quitte son poste – mutation ou départ de l’entreprise. Là, il va falloir « rejouer le film » de l’historique au successeur. Vous pouvez en effet être certain que dans la phase de passage des dossiers (lorsqu’il y en a une) la question informatique passe très souvent à la trappe. Et je passe les cas où l’attribution technique (une fois la décision politique prise) nécessite un ou plusieurs allers et retours entre des équipes différentes, tel ce progiciel GEF qui nécessite à la fois la création d’un compte Unix et d’un compte au sein de l’application.

En outre, il y a la myriade de progiciels qui concernent l’ensemble de l’activité de l’entreprise. Certes, les gros progiciels métiers (RH, gestion économique et financière, comptabilité, cœur de métier) sont couverts en termes de politique d’habilitation formalisée du fait de leur ancienneté. Mais il y a tout le reste : à titre d’exemple, dans mon organisation nous avons recensé non moins de 105 applicatifs divers, répartis dans environ 75 groupes (certains sont des modules d’un même progiciel), le tout étant susceptible de concerner une population de 305 profils distincts (dont certains ne sont bien entendu concernés que par quelques progiciels). Pour chacune des cases dudit tableau, il faut en sus définir un représentant de la MOA et un référent nommé à la DSI : à titre d’exemple encore, sur 105 applications, seules 73 ont un référent DSI désigné, et moins du tiers une MOA identifiée. Sans parler du fait que, pour celles dont le référent DSI ou MOA n’est pas connu, avant de répondre à la question : « Quel nom je mets dans la case ? » ; il faut d’abord répondre à la question : « Qui pourra répondre à la question ? » Vous avez suivi ? 

Enfin, toujours pour chaque case, il faut renvoyer vers un autre tableau qui soit répond à la question de l’accès par Oui/Non, soit renvoie vers une matrice encore plus complexe, quand ce n’est pas vers une instance spécifique, comme l’accès aux données médicales dans le Dossier patient informatisé.

Simple les habilitations ?