La gestion des identités et des accès consiste essentiellement à gérer, pour un utilisateur du système d’information, l’ensemble de ses accès aux ressources informatiques avec les droits afférents. Même si tout un chacun pense que les accès au Système d’Information sont maitrisés et que l’informatique est « sous contrôle », la réalité est toute autre.  En effet, les droits d’accès aux ressources informatiques et leur gestion dans le temps sont intimement liés à l’organisation de l’entreprise et à la maitrise de ses référentiels et de ses processus.

Par exemple, quand un nouveau collaborateur arrive, il faut lui donner accès aux applications avec les profils appropriés. Ces tâches sont réalisées par le service informatique, mais un certain nombre de questions se posent : qui fait la demande de création des comptes ? Qui définit les profils appropriés ? Qui décide de la « dotation logique » d’une secrétaire du service paye ou d’un ingénieur du bureau d’étude ? La problématique est encore plus prégnante quand la personne change de service ou quitte l’entreprise. Elle devient cruciale avec les applications dans le Cloud qui pour certaines ne sont même plus visibles par le service informatique. Tout le monde connait l’exemple du commercial parti à la concurrence, mais qui continue de recevoir ses mails et d’accéder au CRM de l’entreprise.

Le sujet de la gestion des identités et des accès est porté par les RSSI et les DSI depuis plus d’une dizaine d’années et le marché s’est organisé autour d’une poignée d’éditeurs de logiciels et d’intégrateurs spécialisés. Des montants financiers importants ont été investis par les clients sur cette période.

Néanmoins, force est de constater que la promesse au sens marketing du terme n’a pas été tenue et que les projets se sont le plus souvent transformés en échecs coûteux. Ces échecs récurrents peuvent être résumés par le « syndrome des trois 3 » où les trois 3 correspondent à la synthèse du projet : 3 ans de délais, 3 connecteurs réalisés et 3 millions d’euros investis… avec en prime une solution devenue tellement complexe qu’elle est quasiment impossible à maintenir.

Les raisons de ces échecs sont multiples, mais une des causes principales réside dans le montage même du projet et dans la répartition de la chaine de valeur à travers les différents acteurs. Chaque société se croyant unique, elle fait appel à des consultants externes pour affiner son besoin (parfois aussi pour externaliser le risque lié au projet). Un nombre restreint de sociétés se sont spécialisées depuis une dizaine d’années et se partagent la majeure partie de ce marché lucratif.

À ce niveau commence le syndrome des trois 3.

En effet, les intérêts intimes du consultant et du client sont divergents par nature.

Le consultant veut maximiser sa prestation (facturer le maximum), minimiser son risque (rester uniquement sur l’AMOA), optimiser sa rentabilité (réutiliser au maximum ce qui a été fait par ailleurs et facturer des juniors au tarif fort), se rendre indispensable (devenir l’unique dépositaire du besoin client) et favoriser ses alliés (les éditeurs qui vont alimenter ses équipes d’intégration). Sur ce dernier point, les clients font preuve d’une grande naïveté en confiant le choix d’une solution technique à des consultants « soi-disant indépendants » qui ont par ailleurs des activités d’intégration et des partenariats avec des éditeurs.

Le résultat concret, c’est qu’en application de la célèbre définition de Larry Kersten « Consulting : if you are not part of the solution there is good money to be made in prolonging the problem », l’appel à la majorité de ces sociétés spécialisées en consulting IAM aboutit à des cahiers des charges extrêmement complexes, bien souvent très au-delà du besoin réel du client. La complexité justifie la facture et il est très intéressant de comparer le coût de l’étude par rapport au budget prévu pour la mise en œuvre du projet.

Le deuxième intervenant dans la chaine de valeur est le fournisseur de la technologie : l’éditeur de logiciel.

Ce dernier met généralement en œuvre deux stratégies (remarquablement décrites par Henri de Bodinat dans « La Stratégie de l’Offre ») :

-Pour les leaders, il s’agit de la « stratégie de domination » qui consiste à signer des accords-cadres qui permettent au client d’accéder à tout le catalogue sans surcoût : le choix de l’éditeur est alors imposé par le haut.

-Pour les autres, il s’agit de la « stratégie de la sur-promesse ». Pour gagner, l’éditeur doit uniquement passer deux étapes : être retenu en short list en cochant « oui » à toutes les questions et faire la différence en soutenance grâce à une démonstration époustouflante. Il vend ses licences et ne prend aucun risque sur la réalisation. Sa relation avec le client s’arrête à la vente de la licence.

Dans la mesure où le marché de la gestion des identités en est toujours au stade « early adaptors » et afin de pouvoir cocher toutes les cases du cahier des charges, les solutions disponibles sur le marché sont essentiellement des boites à outils, coûteuses, puissantes, mais complexes et qui nécessitent un fort niveau d’expertise.

En résumé, à ce stade, nous avons une expression de besoin complexe qui doit être adressée par une technologie également complexe.

C’est à ce niveau qu’intervient l’intégrateur.

Son objectif est de parvenir à « entrer » chez le client, puis d’y rester ad vitam aeternam en déposant couche après couche des développements spécifiques réalisés par des ingénieurs généralement peu formés (mais disponibles en inter contrats) car la faible marge de ces sociétés ne permet pas d’investir massivement en expertise.

Au bout du compte, le logiciel est tellement customisé que ce n’est plus le logiciel du fournisseur X, ni même la solution mise en œuvre par la société Y, mais l’œuvre unique et personnelle du consultant Z, extrêmement coûteuse à maintenir et à faire évoluer.

Le dernier acteur est le client final. Il a laissé le projet lui échapper, devenir extrêmement visible grâce au travail des consultants puis s’enliser et consommer toujours plus en fournissant toujours aussi peu.

C’est à ce stade que se situe sans doute l’aspect le plus extraordinaire. En effet, alors que l’on pourrait s’attendre à une révolte, le client est le plus souvent résigné. Dans une logique d’autoprotection, une chape de plomb est posée sur le projet qui devient une citadelle imprenable. Tout le monde sait que c’est un échec, mais il est hors de question de le dire, encore moins de le remettre en cause. Certains poussent même la logique à faire du prosélytisme et à devenir les premiers sponsors d’une solution qui les a conduits à un véritable désastre, bien aidés, il faut l’avouer, par les analystes qui continuent sans état d’âme à promouvoir les leaders du marché (qui sont par ailleurs leurs principaux clients).

Deux éléments exogènes sont susceptibles de remettre en cause ce statu quo :
-La disparition de la technologie (car elle a été rachetée par un éditeur qui ne la maintient plus) ;
-Un changement à la direction du projet.

Le premier cas conduit rarement à une remise en cause profonde : il est souvent traité avec brio par le fournisseur qui, dans une logique de stratégie de domination, propose des « plans de migration ». Et même quand cela consiste à tout jeter et à tout refaire, la logique d’autoprotection prévaut.

Finalement, c’est souvent un changement d’acteur à la direction informatique qui va permettre de découvrir le pot aux roses, de mettre fin à la gabegie et de repartir sur une approche d’autant plus efficace que les leçons de l’expérience précédente sont acquises.

En conclusion, peut-être encore plus qu’ailleurs, les projets IAM doivent être pragmatiques, se focaliser sur des objectifs simples, atteignables en quelques mois, privilégier une approche itérative et développer une « stratégie de l’offre » vis-à-vis des clients internes. En respectant ces quelques principes, il est alors possible de faire d’un projet de gestion des identités un projet fédérateur qui petit à petit va se transformer en fournisseur de services pour les Ressources Humaines (avec l’annuaire d’entreprise), pour la Communication (avec l’organigramme), pour les Services Généraux (avec la gestion des dotations logiques), pour le help desk informatique (avec la création automatique des comptes), pour l’utilisateur final (avec le self service reset password), pour le RSSI (avec la gestion des habilitations) et pour la Direction des Risques (avec le contrôle des accès au SI).

___________
Nicolas Moyere est CTO d’Usercube