---
url: 'https://www.corbado.com/fr/blog/process-mining-authentification'
title: 'Process Mining d''Authentification : La Prochaine Discipline CIAM'
description: 'Le process mining d''authentification transforme les journaux d''événements des clés d''accès en parcours de connexion optimisés. Découvrez la discipline d''observabilité CIAM.'
lang: 'fr'
author: 'Vincent Delitz'
date: '2026-05-19T14:50:58.124Z'
lastModified: '2026-05-20T06:03:30.645Z'
keywords: 'process mining authentification, authentification parcours utilisateur, observabilité CIAM, authentification renforcée, optimisation parcours authentification'
category: 'Passkeys Strategy'
---

# Process Mining d'Authentification : La Prochaine Discipline CIAM

## Key Facts

- Le **process mining d'authentification** applique la **reconstruction de journaux
    d'événements** façon **Celonis**, formalisée par le **groupe de travail IEEE sur le
    Process Mining** pour les workflows **ERP** dans les années **2010**, aux cérémonies
    de connexion par clé d'accès. - Cela nécessite une **couche d'observabilité côté
    client**. Les **journaux de l'IdP** enregistrent les **tentatives**, les **succès** et
    les **échecs** côté serveur, mais manquent l'**interface utilisateur conditionnelle
    (Conditional UI)**, les invites biométriques, la sélection du **gestionnaire de mots
    de passe** et les abandons silencieux. - Dans les déploiements observés, seuls environ
    **30 %** des utilisateurs éligibles suivent le **parcours idéal conçu pour les clés
    d'accès**, et un **taux de succès global de 92 %** masque régulièrement un **taux
    d'abandon de 40 %** sur le seul parcours des clés d'accès. - Les **cinq principales
    variantes de déviation** représentent généralement **85 %** de toutes les déviations,
    de sorte que des correctifs ciblés favorisent davantage l'adoption que n'importe quel
    test A/B sur le parcours idéal. - Le modèle d'événements nécessite **3 types
    d'initiation** (`text-field`, `one-tap`, `cui`), **6 classes de résultats** et un
    **inventaire des identifiants** segmenté par **transport** et authentificateur
    (**Apple**, **Google Password Manager**, **iCloud Keychain**, **Windows Hello**,
    **YubiKey**). - Les données de process mining transforment l'**authentification
    renforcée (step-up)** d'une règle OTP brutale - ajoutant des frictions sur **95 %** du
    trafic légitime pour attraper **5 %** de trafic suspect - en une décision **évaluée en
    continu par les risques**. - Aucun **IdP** ne propose cela nativement : **Okta**,
    **Ping**, **ForgeRock** et **Auth0** possèdent le **plan de contrôle**, tandis que le
    process mining est une **discipline du plan de données**, rendant l'**analyse des
    variantes**, la **détection de dérive de cohorte** et la **vérification de
    conformité** obligatoires pour les équipes d'analyse CIAM d'ici **2027**.

## 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](https://www.corbado.com/fr/blog/comment-passer-totalement-sans-mot-de-passe), 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](https://www.corbado.com/fr/blog/comment-passer-totalement-sans-mot-de-passe) 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](https://www.corbado.com/fr/blog/comment-passer-totalement-sans-mot-de-passe)
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](https://www.corbado.com/fr/blog/conformite-cybersecurite)û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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/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](https://www.corbado.com/fr/blog/comment-activer-passkeys-android) conçu contre parcours de
[clé d'accès](https://www.corbado.com/fr/blog/comment-activer-passkeys-android) 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](https://www.tf-pm.org/resources/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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/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](https://www.corbado.com/fr/blog/comment-activer-passkeys-android) 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](https://www.corbado.com/fr/blog/conformite-cybersecurite)û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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/how-to-use-google-password-manager),
[iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain), [Windows Hello](https://www.corbado.com/glossary/windows-hello),
[1Password](https://www.corbado.com/blog/1password-passkeys-best-practices-analysis),
[Bitwarden](https://www.corbado.com/blog/passkey-analysis-bitwarden-developer-survey-2024),
[Dashlane](https://www.corbado.com/blog/dashlane-passkeys), [YubiKey](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/auth0-passkeys-analysis) 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](https://www.corbado.com/) fournit la couche de mesure et d'adoption qui se situe
au-dessus des IdP existants. Elle s'intègre avec Okta,
[Auth0](https://www.corbado.com/blog/auth0-passkeys-analysis), 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](https://www.corbado.com/fr/blog/conformite-cybersecurite)û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.

## 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.