Process Mining d'Authentification : La Prochaine Discipline CIAM

1. Introduction#

Les clés d'accès font progresser le CIAM. Les meilleures équipes commencent à instrumenter le parcours de connexion de bout en bout, à classer des erreurs qu'elles n'avaient jamais enregistrées auparavant et à examiner la télémétrie côté client pour la première fois. La grande majorité des équipes d'identité n'en est pas encore là : il n'y a pas de véritable couche d'observabilité de l'authentification, pas de graphe d'événements par session, pas de données de cérémonie côté client. Les tentatives, les succès et les échecs côté serveur constituent toujours l'ensemble de la situation.

Le process mining d'authentification est la prochaine étape logique, mais seulement une fois que ces données d'événements sous-jacentes existent. Sans la couche d'observabilité, il n'y a rien à explorer. Avec elle, une nouvelle discipline devient disponible. Elle s'inspire directement du process mining métier, qui a transformé les journaux d'événements bruts des ERP en workflows optimisés dans les années 2010. Appliquée à l'identité, elle compare le parcours de connexion conçu au parcours vécu, fait remonter les chemins de déviation, puis comble l'écart avec une authentification renforcée granulaire, des règles de suppression ou des modifications de l'UX qui sont mesurées de bout en bout.

Cet article redéfinit ce que les équipes CIAM devraient construire par-dessus la couche d'observabilité de l'authentification.

1.1 Questions auxquelles cet article répond#

Dans cet article, nous abordons les questions suivantes :

1. Qu'est-ce que le process mining a fait pour le BPM, et quel est le parallèle direct pour l'authentification ?
2. Pourquoi les déploiements de clés d'accès ont-ils mis en évidence cette lacune, et pourquoi les journaux d'authentification n'ont-ils jamais suffi à eux seuls ?
3. À quoi ressemble concrètement un modèle d'événements de process mining d'authentification de bout en bout ?
4. Comment le process mining se connecte-il à l'authentification renforcée granulaire et à l'autorisation ?
5. Qu'est-ce que cela signifie pour le paysage des fournisseurs de CIAM et pour les équipes d'identité qui possèdent déjà un IdP ?

2. Ce que le Process Mining a fait pour le BPM#

2.1 Des journaux d'événements aux processus optimisés#

Le process mining métier est né de la constatation que chaque ERP, CRM ou système de billetterie écrit des journaux d'événements qui, une fois reconstruits, révèlent le workflow réel, et non celui du wiki. Un bon de commande censé passer par trois approbateurs s'est avéré contourner deux d'entre eux dans 40 % des cas. Un flux de réclamations documenté comme une ligne droite revenait sur lui-même cinq fois pour 18 % des réclamations. Les outils de process mining, comme ceux popularisés par Celonis, ont reconstruit ces graphes à partir d'événements horodatés et ont permis aux opérateurs de poser une nouvelle question : où le processus vécu diverge-t-il du processus conçu, et que coûte cette divergence ?

2.2 Parallèle dans l'authentification#

L'authentification a la même structure. Chaque connexion est une séquence d'événements horodatés : page chargée, identifiant saisi, défi sélectionné, invite biométrique, assertion retournée. Le parallèle structurel est exact. La différence pratique est que, contrairement à un ERP ou un CRM, ces données d'événements ne se trouvent pas encore dans vos journaux d'IdP - du moins pas sous la forme granulaire dont le process mining a besoin. Les IdP enregistrent les résultats de connexion et la méthode utilisée. Ils n'enregistrent pas la cérémonie sous-jacente côté client : l'invocation de la Conditional UI, les invites biométriques, la sélection du gestionnaire de mots de passe, l'abandon silencieux avant même qu'une requête n'atteigne le serveur. Cette couche pré-assertion doit être instrumentée au niveau du SDK front-end et réassemblée en un graphe par session avant que le process mining ne puisse s'y appliquer.

Une fois les données présentes, les mêmes techniques s'appliquent : parcours de clé d'accès conçu contre parcours de clé d'accès vécu, flux de récupération conçu contre flux de récupération vécu, authentification renforcée conçue contre authentification renforcée vécue. La discipline académique autour de ce travail gagne en maturité. Un point d'entrée utile est le Process Mining Manifesto du groupe de travail de l'IEEE sur le Process Mining, qui définit la vérification de conformité, l'analyse des variantes et l'amélioration comme les trois techniques principales. Chacune correspond parfaitement à l'authentification.

3. Pourquoi les déploiements de clés d'accès ont mis en évidence la lacune#

3.1 Les clés d'accès obligent les équipes à repenser la journalisation front-end#

L'authentification classique par mot de passe enregistrait trois choses côté serveur : la tentative, le succès, l'échec. C'est suffisant pour faire fonctionner un système de mots de passe, car le mode de défaillance est simple : l'utilisateur a mal tapé une chaîne, et la tentative suivante a fonctionné ou non. Avec les clés d'accès, les moments critiques se déplacent vers le front-end : déclenchement de la Conditional UI, le navigateur décidant de présenter une invite ou non, le gestionnaire de mots de passe proposant un choix, le défi biométrique réussissant ou étant ignoré. Tout cela se produit sur l'appareil du consommateur, avant que l'assertion n'atteigne le back-end.

Ce changement explique pourquoi de nombreuses équipes repensent désormais la façon dont elles enregistrent le comportement côté client. Sans instrumentation front-end, elles ne peuvent pas voir pourquoi les utilisateurs abandonnent, quelles étapes ils franchissent avant de se connecter, ou ce qui s'est réellement passé lorsqu'une tentative de connexion n'a pas abouti. Les journaux de serveur ne montrent que l'absence, pas la cause. Consultez notre analyse approfondie sur l'observabilité de l'authentification pour connaître la taxonomie complète des événements.

3.2 Écart entre le parcours conçu et le parcours vécu#

Une fois que les équipes ont disposé d'événements côté client, elles ont pu observer quelque chose de nouveau : le parcours de clé d'accès conçu (arriver sur la page de connexion, voir le bouton de clé d'accès, appuyer, s'authentifier, terminé) était utilisé par peut-être 30 % des utilisateurs éligibles. Les 70 % restants dérivaient vers les champs de mot de passe, la connexion sociale, les liens magiques ou abandonnaient complètement. Il s'agit d'un problème de process mining, pas d'un problème de journalisation. Aucune quantité de codes d'erreur WebAuthn supplémentaires n'aurait permis de combler cet écart à elle seule.

3.3 Pourquoi les journaux d'authentification n'ont jamais suffi#

Les journaux d'authentification à eux seuls vous indiquent les résultats. Ils ne vous indiquent pas les parcours. Un taux de réussite de connexion de 92 % toutes méthodes confondues peut masquer un taux d'abandon de 40 % sur le parcours des clés d'accès et un taux d'abandon de 15 % sur le parcours des mots de passe, ce qui donne un résultat global jugé « correct ». Le process mining refuse cette moyenne. Il insiste pour examiner chaque variante séparément, puis classer les variantes par fréquence, par coût et par taux d'échec.

4. À quoi ressemble concrètement le Process Mining d'Authentification#

4.1 Modèle d'événements : Processus, Événements et Classification des résultats#

L'unité d'analyse n'est pas un événement unique, c'est un processus : une tentative complète de connexion ou d'ajout d'identifiant sur l'appareil du consommateur, du moment où la surface d'authentification se charge au moment où la session se termine ou est abandonnée. Chaque processus contient un flux d'événements granulaires, porte des métadonnées d'identification et se termine par une classification des résultats plus riche que le binaire « succès ou échec ».

Métadonnées du processus. Chaque processus possède un ID de processus et un horodatage. Il est lié à une application, un système d'exploitation, un navigateur et une marque d'appareil. Il est étiqueté avec une catégorie de visiteur (utilisateur réel, testeur manuel, testeur automatisé, non encore classé) afin que le trafic des automatisations et des bots puisse être segmenté avant le calcul d'une quelconque métrique. Il porte également un score de processus et un nombre d'événements, qui sont les deux signaux les plus simples pour évaluer la complexité de cette session particulière.

Initiation de connexion. Chaque processus enregistre comment le flux a été démarré. Les principaux types d'initiation sont text-field (l'utilisateur a tapé son identifiant), one-tap (un identifiant stocké a été réutilisé) et cui (la Conditional UI a fait apparaître un identifiant sans un clic explicite sur un bouton). L'initiation est une dimension, pas une métrique : le même déploiement peut sembler très différent sur la cohorte cui que sur la cohorte text-field, et faire la moyenne entre elles masque exactement le comportement que le process mining est censé révéler.

Classification des résultats. Au lieu de « succès » ou « échec », le résultat est l'une de plusieurs classes qui correspondent à un comportement distinct. Voici un exemple pour les clés d'accès :

• completed - la cérémonie s'est terminée et l'utilisateur est authentifié.
• filtered-explicit-abort - l'utilisateur a vu une invite et a explicitement annulé.
• filtered-implicit-abort - l'utilisateur est parti ou a expiré sans se décider.
• filtered-passkey-intel - la couche d'intelligence côté client a supprimé le parcours de clé d'accès délibérément, généralement parce que la combinaison appareil/OS est connue pour être défectueuse.
• filtered-no-start - le flux n'a jamais dépassé l'étape d'entrée.
• not-loaded - la surface d'authentification n'a jamais fini de se charger.

La cérémonie d'ajout (création d'identifiant) a une classification parallèle, incluant un cas completed-exclude-credentials lorsque l'utilisateur possède déjà un identifiant.

Couches d'entonnoir et d'inventaire. Au-dessus des processus, deux couches agrégées sont importantes. Une couche d'entonnoir regroupe les processus au fil du temps par résultat, initiation, statut d'achèvement, système d'exploitation et application, à la fois pour la connexion et pour l'ajout. Une couche d'inventaire des identifiants regroupe les clés d'accès existantes par statut de synchronisation (synchronisées ou non), transport (internal, hybrid, usb, nfc, ble, smart-card), authentificateur (Apple, Google Password Manager, iCloud Keychain, Windows Hello, 1Password, Bitwarden, Dashlane, YubiKey), OS et navigateur. Sans la couche d'inventaire, il est impossible de se demander si une variante de déviation donnée est concentrée sur un gestionnaire de mots de passe spécifique ou un état de synchronisation.

C'est la structure minimale qui rend le process mining exploitable. Chaque événement porte suffisamment de métadonnées pour être groupé, filtré et classé. Chaque processus peut être tracé individuellement, ce qui permet les exemples traités ci-dessous.

4.2 Parcours idéal contre Analyse des déviations#

Une fois les événements stockés sous la forme d'un graphe orienté par session, vous pouvez poser la question du process mining : quel pourcentage de sessions suit le parcours idéal, et pour celles qui ne le font pas, quelles sont les cinq principales variantes de déviation classées par fréquence ? Dans nos données d'analyse, les cinq principales variantes représentent généralement 85 % de toutes les déviations. Résoudre deux d'entre elles fait généralement plus bouger les chiffres que n'importe quel test A/B sur le parcours idéal.

4.3 Détection de dérive de cohorte#

Les variantes dérivent. Une mise à jour du navigateur, le déploiement d'un OS, une modification du gestionnaire de mots de passe peuvent rendre soudainement dominante une variante auparavant mineure. La détection de la dérive de cohorte est la discipline consistant à surveiller la distribution des variantes par cohorte d'appareil/OS/navigateur au fil du temps, au lieu de se contenter de regarder le taux de succès global. C'est ainsi que les équipes détectent les régressions silencieuses en quelques heures plutôt qu'en quelques trimestres.

5. Du Process Mining à l'authentification renforcée granulaire#

5.1 Pourquoi l'authentification renforcée a été sous-utilisée#

L'authentification renforcée a existé pendant plus d'une décennie. Elle a été sous-utilisée parce que la plupart des équipes renforcent l'authentification de la même manière, quel que soit le risque : forcer un OTP sur chaque transaction au-dessus d'un certain seuil. C'est une règle aveugle, pas une décision évaluée selon les risques. Elle crée des frictions sur 95 % des transactions légitimes de grande valeur pour arrêter les 5 % qui sont suspectes.

5.2 Parcours évalués selon les risques#

Avec les données du process mining, vous pouvez évaluer le risque d'une session en continu. La réputation de l'appareil, le taux de succès de base de la cohorte, les anomalies liées à l'heure de la journée, la déviation par rapport au parcours historique de l'utilisateur, l'identité du gestionnaire de mots de passe, la réputation de l'IP. Le score de risque motive ensuite une décision granulaire d'authentification renforcée : n'exiger un deuxième facteur que lorsque le score de risque de la session dépasse le seuil de valeur de la transaction. Les sessions à faible risque pour des transactions de grande valeur passent. Les sessions à haut risque pour des transactions de faible valeur font l'objet d'un renforcement.

6. Ce que cela signifie pour le paysage des fournisseurs de CIAM#

6.1 La conception de parcours comme discipline de spécialiste#

L'industrie de l'identité a historiquement regroupé la conception des parcours au sein de l'IdP. Les moteurs d'orchestration au sein d'Okta, Ping, ForgeRock, Auth0 et d'autres vous permettent de configurer des flux. Ce qu'ils ne font pas bien, c'est de les observer. C'est cette discordance qui ouvre la voie à une couche d'analyse spécialisée.

6.2 Pourquoi aucun IdP ne proposera cela nativement#

Les fournisseurs d'IdP optimisent pour le plan de contrôle : qui peut se connecter, avec quel identifiant, sous quelle politique. Le process mining est une discipline du plan de données : chaque événement, à grande échelle, normalisé à travers les combinaisons OS/navigateur/gestionnaire de mots de passe. Le volume d'événements, la cardinalité et les bases de référence inter-clients vont tous à l'encontre d'une solution nativement construite par un IdP. Consultez les notes de terrain dans notre guide achat contre construction pour les clés d'accès pour voir le même modèle appliqué à la couche SDK.

6.3 La couche d'analyse comme nouvelle catégorie#

Ce qui émerge est une fine couche d'analyse et d'adoption qui se situe au-dessus de l'IdP, ingère les événements du front-end, les normalise par rapport aux bases de référence inter-déploiements et réinjecte ces informations dans les décisions d'orchestration. Elle ne remplace pas l'IdP. Elle rend l'IdP mesurable.

7. Comment Corbado aide au Process Mining d'Authentification#

Corbado fournit la couche de mesure et d'adoption qui se situe au-dessus des IdP existants. Elle s'intègre avec Okta, Auth0, Ory, ForgeRock et des stacks sur mesure sans les remplacer. Ce qu'elle ajoute, c'est spécifiquement la capacité de process mining :

• Taxonomie d'événements de bout en bout. Le SDK côté client capture la cérémonie complète, du chargement de la page à l'assertion, y compris les événements précédant l'identifiant, l'invocation de la Conditional UI et la sélection du gestionnaire de mots de passe.
• Analyse des variantes prête à l'emploi. La plateforme reconstruit les graphes de parcours par cohorte et classe les variantes de déviation par fréquence, opportunité de récupération et coût.
• Alerte de dérive de cohorte. Lorsqu'une distribution de variantes se décale pour un OS, un navigateur ou un gestionnaire de mots de passe spécifique, la plateforme le signale avant que cela ne devienne un problème du jour 2.
• Bases de référence inter-déploiements. Parce que Corbado agrège des données anonymisées sur les environnements clients, les nouvelles erreurs ou régressions apparues dans un déploiement sont classées et documentées avant qu'elles n'atteignent le vôtre. Découvrez l'approche complète.
• Retour vers l'orchestration. Les décisions d'authentification renforcée fondées sur les risques et les règles de suppression peuvent être renvoyées à l'IdP ou gérées au niveau de la couche d'adoption, y compris les interrupteurs d'arrêt dynamiques et les incitations spécifiques à la cohorte.

8. Conclusion#

Les clés d'accès n'étaient pas la destination. Elles étaient le levier d'instrumentation qui oblige la première vague d'équipes CIAM à journaliser les événements côté client pour commencer. Une fois cette couche d'observabilité en place, une nouvelle discipline s'y superpose : le process mining d'authentification. C'est ainsi que les équipes d'identité passent de « la connexion a-t-elle réussi » à « quelle variante du parcours cet utilisateur a-t-il empruntée, qu'est-ce que cela a coûté et comment la prochaine session devrait-elle être routée différemment ». Les équipes qui construisent la couche d'observabilité en premier, puis la couche de process mining juste après, établiront la référence pour la catégorie. Les équipes qui s'en tiennent aux taux de réussite globaux continueront de passer à côté des variantes systémiques sous-jacentes.

À propos de Corbado

Corbado est la Passkey Intelligence Platform pour les équipes CIAM qui gèrent l'authentification client à grande échelle. Nous vous montrons ce que les logs IDP et les outils d'analytics génériques ne voient pas : quels appareils, versions d'OS, navigateurs et gestionnaires de credentials prennent en charge les passkeys, pourquoi les enrôlements ne deviennent pas des connexions, où le flux WebAuthn échoue et quand une mise à jour OS ou navigateur casse silencieusement la connexion — le tout sans remplacer Okta, Auth0, Ping, Cognito ni votre IDP interne. Deux produits : Corbado Observe ajoute l'observabilité pour les passkeys et toute autre méthode de connexion. Corbado Connect apporte des passkeys managés avec analytics intégrés (aux côtés de votre IDP). VicRoads gère les passkeys pour plus de 5M d'utilisateurs avec Corbado (+80 % d'activation passkey). Parler à un expert Passkey →

FAQ#

Qu'est-ce que le Process Mining d'Authentification ?#

Le process mining d'authentification est l'application des techniques de process mining métier aux journaux d'événements de connexion. Il reconstruit le graphe orienté des événements par session, compare le parcours d'authentification vécu au parcours conçu et classe les variantes de déviation par fréquence et par coût. Il se situe au-dessus de l'observabilité de l'authentification et en dessous de l'orchestration.

En quoi est-ce différent de l'analyse de l'authentification ?#

L'analyse de l'authentification rend compte de métriques telles que le taux de réussite des connexions, le taux d'abandon et le taux d'utilisation des clés d'accès. Le process mining va plus loin en reconstruisant la séquence complète des événements par session et en demandant quelles variantes du parcours existent, à quelle fréquence chacune se produit et où chacune diverge du parcours idéal conçu. L'analyse rend compte des résultats. Le process mining explique les parcours.

Pourquoi l'adoption des clés d'accès rend-elle cette discipline nécessaire ?#

Les déploiements de clés d'accès sont la première raison pour laquelle les équipes CIAM instrumentent les événements côté client. Une fois que ces événements existent, les métriques agrégées cachent trop de choses : un taux de réussite de 92 % peut masquer un taux d'abandon de 40 % sur le parcours des clés d'accès. Le process mining refuse cette moyenne et oblige les équipes à examiner les variantes séparément.

Comment le Process Mining se connecte-t-il à l'authentification renforcée ?#

L'authentification renforcée (step-up) fonctionne mieux lorsqu'elle est évaluée en fonction des risques plutôt que basée sur des règles. Le process mining fournit les preuves au niveau de la session (base de référence de la cohorte, déviation par rapport au parcours historique de l'utilisateur, réputation de l'appareil) qui permettent à un moteur de renforcement de prendre une décision granulaire plutôt qu'une décision de seuil brutale.

Mon IdP le proposera-t-il nativement ?#

Peu probable à court terme. Les IdP optimisent pour le plan de contrôle. Le process mining est une discipline du plan de données avec un volume d'événements élevé et une cardinalité élevée à travers les combinaisons OS, navigateur et gestionnaire de mots de passe. Le modèle correspond à ce que nous voyons dans la couche SDK aujourd'hui.

Quelle est la première chose qu'une équipe CIAM devrait mesurer ?#

Commencez par la fréquence des variantes sur le parcours des clés d'accès : quel pourcentage de sessions suit le parcours idéal, et quelles sont les cinq principales variantes de déviation classées par fréquence ? Ce seul graphique suffit généralement à révéler les deux ou trois correctifs qui font le plus progresser l'adoption globale des clés d'accès.