« Gérer les identités est trop complexe pour ne pas se spécialiser », Nicolas Petroussenko (Okta)

Le spécialiste de la gestion des accès Okta vient d’annoncer l’ouverture d’une filiale en France. Nicolas Petroussenko, chargé de la direction de celle-ci, revient à cette occasion sur les partenariats récemment conclus par l’éditeur avec VMware et SailPoint, et plus généralement sur l’évolution du marché de la gestion des identités et des accès (IAM).

LeMagIT : vous venez d’annoncer un partenariat avec VMware, alors que celui-ci propose déjà sa propre brique d’IDaaS, avec Identity Manager. Les deux valent également pour Microsoft, avec lequel vos relations n’ont pas toujours été au beau fixe. Est-ce à dire que l’IDaaS est un sujet trop complexe pour des non-spécialistes ?

Nicolas Petroussenko : Avec Microsoft, nous avons aujourd’hui un partenariat qui s’inscrit dans un cadre un peu particulier. Nous pouvons être à la fois partenaires et concurrents.

Avec VMware, les choses sont différentes. Ils disposent d’une solution de gestion de la mobilité d’entreprise (EMM), AirWatch, et ont décidé, eu égard à la complexité du sujet de l’IDaaS, de s’appuyer sur un acteur spécialisé, en l’occurrence nous. Cela signifie une sorte d’abandon à terme de leur solution, au profit de la nôtre.

Justement, la complémentarité entre IDaaS et EMM est bien identifiée, depuis maintenant quelques années. Mais personne ne semble en définitive réussir à proposer une offre intégrée… Ces tentatives sont condamnées à l’échec ?

Je ne sais pas si elles sont condamnées à l’échec, mais c’est compliqué. Okta a d’ailleurs lui-même abandonné une partie qui tendait vers l’EMM, pour se recentrer sur son métier.

L’IDaaS demande d’importants investissements. Ce n’est pas uniquement proposer à des utilisateurs finaux un accès à des ressources applicatives internes ou externes. Cela porte aussi sur des sujets d’ouverture, comme le contrôle des accès à des sites Web, des portails, ou des API. Là, cela devient compliqué, avec des environnements complexes et des modes de connexion multiples.

VMware est ainsi arrivé à la conclusion que, dans ce domaine, il faut un "best-of-breed", alors qu’il pensait pouvoir y arriver. Un peu comme nous pour l’EMM. Mais ce sont des sujets trop complexes pour faire l’économie d’une spécialisation.

Ce que vous indiquez là, entre EMM et IDaaS, me renvoie à la gestion des identités et des accès, l’IAM, un domaine sur lequel se distinguent de plus en plus nettement la gestion des accès (AM), d’un côté, et la gouvernance des identités (IGA), de l’autre. Okta a d’ailleurs récemment noué un partenariat avec SailPoint.

Exactement. C’est la même philosophie : nous nous positionnons comme un partenaire d’intégration de briques applicatives spécialisées. Ce n’est d’ailleurs pas qu’une vision que l’on aurait et partagerait avec quelques acteurs. Nous retrouvons cette vision chez nos clients.

Nous observons de plus en plus d’appels d’offres où les deux domaines sont dissociés : gouvernance des identités et contrôle des accès ne sont plus traités en un seul bloc ; ce sont deux sujets bien distincts et le marché l’appréhende de plus en plus de cette manière.

En 2016, vous avez commencé à vous engager sur le terrain du contrôle des accès aux API. Où en est là la maturité du marché ?

Tout d’abord, en termes d’activité pour nous, ce segment est celui sur lequel nous enregistrons la plus forte croissance. Mais les spécialistes de la gestion des API s’y intéressent aussi. Nous travaillons aujourd’hui avec Apigee, Mulesoft, et avec Axway : un peu comme pour les acteurs de l’EMM, tous disent que le contrôle d’accès aux API est un sujet trop compliqué, trop riche, trop vaste, pour que l’on puisse se contenter d’un contrôle par jeton, par exemple, comme on le fait encore beaucoup aujourd’hui ; ça laisse de côté de nombreux cas d’usages.

Les clients ont bien compris que les solutions de gestion des API n’apportaient pas le niveau de granularité nécessaire en matière de gestion d’accès, de délégation, ou encore d’authentification des systèmes ou des personnes. Cela vaut notamment pour les banques, qui ont toutes des politiques de gestion d’API bien avancées, en particulier dans le cadre de la directive DSP2, pour répondre à des besoins de renforcement des contrôles d’accès.

En définitive, le problème sous-jacent n’est-il pas que la notion d’identité n’est plus aujourd’hui attachée uniquement à des individus, mais à toutes sortes d’entités - systèmes, bots, services tiers, objets connectés, etc. ?

C’est exactement cela. Nous nous apprêtons d’ailleurs à présenter une offre dédiée au domaine des objets connectés (IoT). Parce qu’encore une fois, voilà un domaine où il va falloir contrôler des accès en identifiant, non plus des personnes, mais des objets.

D’où, encore une fois, notre recentrage sur le domaine de l’identité, en abandonnant tous les sujets connexes, car il est extrêmement transversal et a vocation à se déployer de manière très étendue.