Ariovis
Conseil d'expert — Access Management et CIAM

Nous ne cherchons pas à tout savoir sur un client

Nous cherchons à obtenir assez de confiance pour autoriser une action sans ouvrir la voie à la fraude. Retour d'expérience d'un architecte IAM senior Ariovis, à partir de deux situations très concrètes : un client particulier qui perd son téléphone et un professionnel qui demande un délai de paiement au comptoir d'un magasin de matériaux de construction.

Deux situations, une même question

Nous concevons régulièrement des parcours CIAM pour des organisations qui accueillent des clients particuliers, des clients professionnels, des usagers, des partenaires, des fournisseurs, des adhérents et des collaborateurs externes. Les technologies sous-jacentes ressemblent souvent à celles utilisées pour les collaborateurs, mais les enjeux sont différents. Le client a le choix, il n'a pas le temps, et le premier objectif de l'authentification n'est presque jamais la conformité interne. C'est la prévention de la fraude.

La question utile n'est donc pas toujours : « Pouvons-nous prouver entièrement qui est cette personne ? » Elle est souvent : « Avons-nous suffisamment de raisons de penser que cette personne est bien le titulaire légitime du compte et que l'action demandée peut être acceptée ? » Ce qui n'est pas la même conversation.

Deux situations reviennent constamment dans nos entretiens avec les responsables fraude, les responsables digitaux et les architectes sécurité. Un client particulier qui a perdu son téléphone et réinstalle une application. Un client professionnel qui se présente à un comptoir de matériaux de construction et demande à régler à trente jours, une fois que son propre client l'a payé. Elles semblent très différentes. Elles posent en réalité la même question : quel niveau de confiance faut-il obtenir avant d'accepter la demande ?

L'identité n'est pas une information que nous cherchons à accumuler. C'est une confiance que nous construisons pour prendre une décision.

Le téléphone perdu : reconstruire une session sans transformer l'incident en épreuve

Le premier cas est banal, et c'est précisément pour cela qu'il mérite d'être traité avec soin. Un client utilise régulièrement l'application mobile d'une enseigne. Son ancien téléphone est perdu, cassé ou volé. Il en récupère un autre, installe l'application, se souvient de son identifiant et de son mot de passe. Le parcours pourrait alors lui demander son mot de passe, un code SMS, une pièce d'identité, une série de questions personnelles, un appel au service client. Chaque étape supplémentaire semble améliorer la sécurité. Elle peut également transformer un incident banal en parcours pénible.

Le mot de passe qu'il saisit constitue l'authentification explicite du parcours : le service vérifie un élément que le client connaît et qu'il fournit volontairement. Nous ne présentons pas cette information comme une preuve absolue. Un mot de passe peut avoir été compromis, réutilisé sur un autre service, hameçonné, ou enregistré dans un emplacement insuffisamment protégé. Il constitue néanmoins un premier élément de confiance. La décision ne doit pas nécessairement s'arrêter là.

Avant d'imposer immédiatement une nouvelle action au client, le parcours peut examiner des éléments de contexte : ce sont ce que nous appelons les Implicit Signals. Selon les capacités du terminal, du système d'exploitation, de l'application et des composants déployés, ces signaux peuvent notamment concerner la zone géographique, l'adresse IP, le réseau utilisé, la langue et le fuseau horaire du terminal, le type d'appareil, la version du système, l'intégrité de la plateforme, la présence d'un root ou d'un jailbreak, l'utilisation d'un émulateur, la réputation de l'adresse IP, la vélocité des tentatives, les habitudes de connexion du compte et le comportement observé pendant la saisie. Certains projets envisagent également des signaux plus intrusifs comme la liste des contacts ou des catégories d'applications installées ; ces informations sont particulièrement sensibles, largement restreintes par les systèmes mobiles et par le droit applicable, et nous n'en faisons jamais un socle. Un bon signal de risque n'est pas seulement techniquement disponible. Il doit aussi être légitime à collecter et réellement utile à la décision.

Ces signaux ne sont pas des preuves isolées. Un nouveau terminal n'est pas nécessairement frauduleux. Une nouvelle adresse IP n'est pas nécessairement suspecte. Une langue différente n'est pas une preuve de compromission. Un voyage n'est pas une fraude. Le moteur de Risk-Based Authentication combine les signaux pour produire un Risk Score que le métier interprète. Dans notre cas, le terminal est nouveau, mais la connexion provient de la zone habituelle, la langue et le fuseau sont cohérents, aucun root n'est détecté, le comportement de saisie ressemble aux usages précédents, aucune tentative récente anormale n'est constatée. Le score reste faible. Le client peut être connecté sans qu'un nouveau facteur explicite lui soit demandé.

Nous prenons soin, à ce moment précis, de ne pas céder à un abus de langage. Ce que nous venons de faire n'est pas nécessairement une authentification multifacteur. Le mot de passe reste le facteur d'authentification explicite. Les signaux contextuels augmentent le niveau de confiance associé à la tentative — nous parlerions plutôt d'Authentication Assurance ou d'Adaptive Authentication. Ce n'est pas nécessairement une authentification multifacteur. C'est une authentification dont le niveau de confiance est enrichi par le contexte.

Quand demander une preuve supplémentaire, et sous quelle forme

Le même parcours doit produire un autre résultat lorsque les signaux racontent une autre histoire. C'est là qu'intervient la notion de Step-Up Authentication. Nous demandons alors à ce que la confiance manquante soit apportée, sans nécessairement demander davantage d'informations : nous demandons une preuve plus forte. Voici quelques situations récurrentes, et la manière dont nous les instruisons avec les équipes fraude et produit.

  1. 01

    Un terminal inconnu depuis un pays inhabituel

    Le mot de passe est correct, mais le terminal est nouveau, la localisation ne ressemble à aucune connexion précédente, l'application demande immédiatement l'accès aux données sensibles et le comportement de saisie est très différent. Le Risk Score monte. Nous déclenchons alors un step-up plus exigeant : une passkey si le client en a enrôlé une, une validation dans un autre canal de confiance déjà utilisé, une authentification forte préalablement enrôlée, ou une vérification d'identité — Identity Proofing — pour les cas les plus sensibles. Ce n'est pas la nouveauté du terminal qui déclenche la friction. C'est la combinaison de plusieurs signaux qui ne se recoupent avec aucun usage antérieur.

  2. 02

    Un terminal compromis ou un émulateur

    La Device Posture indique un root, un jailbreak, un émulateur, une version d'OS très ancienne ou une intégrité d'application altérée. Ces signaux ne sont pas anodins, même lorsque le mot de passe est correct. Nous refusons alors une reconnexion silencieuse et exigeons un step-up, éventuellement un parcours de récupération encadré et, pour les actions sensibles, une intervention du support. Le Device Trust dont parle un fournisseur ne se résume pas à un identifiant de terminal ; il repose sur ce que le terminal accepte de dire de lui-même, et sur la capacité à en vérifier l'intégrité.

  3. 03

    Une demande immédiate de modification sensible

    Le client vient de se connecter et demande, dans la foulée, un changement d'adresse de livraison, un changement de compte bancaire ou une réinitialisation d'un moyen d'authentification. Le niveau de preuve attendu n'est plus le même que pour consulter un historique. Nous appliquons alors une politique métier explicite : certaines actions déclenchent un step-up même lorsque le score global reste bas, parce que leur potentiel de fraude est asymétrique. Le score aide à prendre une décision ; il ne la remplace pas.

  4. 04

    Le SMS n'est pas la réponse par défaut

    Nous constatons régulièrement que le SMS reste le premier réflexe des équipes projet parce qu'il est simple à déployer. Il ne doit pas être présenté comme un facteur robuste. L'ANSSI recommande de ne pas l'utiliser comme moyen de réception d'un facteur d'authentification, en raison notamment de l'interception possible, du SIM swapping, de la réattribution des numéros et de la faiblesse structurelle du canal. Nous ne prétendons pas qu'il n'a jamais aucune valeur — il peut contribuer à la détection ou constituer une solution résiduelle à défaut d'alternative — mais il ne peut pas être présenté au client comme une garantie forte. La passkey, l'application d'authentification déjà enrôlée ou la validation dans un canal indépendant déjà utilisé sont, dans la plupart des cas, des choix plus solides.

  5. 05

    Trois formulations commerciales à passer au crible

    Trois expressions reviennent dans les démonstrations d'éditeurs. « Nous faisons du MFA invisible » — non, une analyse de risque peut renforcer considérablement la confiance sans être, en toute rigueur, un second facteur d'authentification indépendant. L'objectif n'est pas de renommer un score de risque en MFA, mais de prendre une décision proportionnée avec la confiance réellement disponible. « Nous reconnaissons le terminal » — sur quelle base ? Un cookie, un identifiant applicatif, une clé cryptographique, un attachement au compte Apple ou Google ? Peut-il être copié, disparaît-il après réinstallation, est-il révoqué lorsque le téléphone est perdu ? Reconnaître un appareil n'est pas encore reconnaître la personne qui l'utilise. « Le score de risque décide » — non, le moteur calcule un risque, mais le métier décide ce qu'il accepte de faire avec ce risque. Un score de 70 n'a aucune signification universelle.

  6. 06

    Ce que nous demandons systématiquement à un moteur d'Adaptive Authentication

    Quels signaux sont utilisés et pourquoi. Comment ils sont pondérés. Quelles règles déclenchent un step-up. Comment les faux positifs sont suivis et corrigés. Comment un client légitime peut récupérer son compte lorsque la décision se retourne contre lui. Comment la décision est expliquée lors d'une fraude avérée. Comment les règles évoluent avec les incidents observés. Un moteur qui refuse de répondre à ces questions n'est pas prêt pour un parcours CIAM sérieux. Le score aide à prendre une décision. Il ne remplace pas la politique métier.

  7. 07

    Le rôle du parcours d'Account Recovery

    Une part importante de la fraude se concentre sur les parcours de récupération. Nous les traitons comme des parcours à part entière, avec des règles explicites, une graduation des preuves, une trace des décisions et une articulation claire avec le support. Un parcours de récupération n'est pas une porte dérobée pour contourner la Risk-Based Authentication ; c'est un parcours qui doit être au moins aussi rigoureux que la connexion normale, et souvent plus.

Lorsque le risque augmente, nous ne demandons pas nécessairement davantage d'informations. Nous demandons une preuve plus forte.

Le client au comptoir : distinguer l'entreprise, la personne et le mandat

La seconde situation semble éloignée de la première, elle en révèle en fait la même structure. Un professionnel se présente dans un magasin de matériaux de construction. Son entreprise est cliente régulière, les commandes précédentes ont été correctement réglées. Il présente un extrait Kbis et demande à régler à trente jours, une fois que son propre client l'a payé. Pour le magasin, cette proposition a une vraie valeur commerciale : elle fidélise le professionnel et simplifie sa trésorerie. Le risque principal n'est pas nécessairement la solvabilité de l'entreprise. Le compte est connu, l'historique est régulier. La question devient : la personne présente au comptoir est-elle bien autorisée à engager cette entreprise dans cette opération ? Voici comment nous instruisons ce parcours avec les équipes.

Ce que prouve un Kbis, et ce qu'il ne prouve pas
Le Kbis permet de renseigner l'existence et certaines caractéristiques de la société : dénomination, immatriculation, adresse, représentants légaux, informations administratives. Il ne suffit pas toujours à établir que le porteur est bien la personne qu'il prétend être, qu'il travaille toujours pour l'entreprise, qu'il est autorisé à commander, qu'il peut négocier un délai de paiement, ni qu'il peut engager l'entreprise jusqu'au montant demandé. Nous distinguons donc trois questions : l'entreprise existe-t-elle, qui est la personne présente, et cette personne peut-elle engager cette entreprise pour cette opération. Connaître l'entreprise, reconnaître la personne et vérifier son mandat sont trois décisions différentes.
S'appuyer sur une identité déjà vérifiée
Plutôt que de demander au client de remplir un dossier complexe ou de présenter plusieurs justificatifs difficiles à contrôler au comptoir, le magasin peut s'appuyer sur un Identity Provider externe. Selon le contexte, l'éligibilité du service et les accords disponibles, cela peut reposer sur un parcours complet porté par Ping Identity, sur b.connect pour une authentification fondée sur une relation bancaire existante auprès des services partenaires, sur FranceConnect ou FranceConnect+ lorsqu'un service est éligible à ces dispositifs, sur une identité numérique reconnue ou sur un autre fournisseur adapté au marché et au niveau de preuve attendu. Ces dispositifs ne sont pas des remplaçants universels du CIAM du magasin ; leur usage dépend du public, du niveau de preuve, des informations disponibles, du cadre contractuel et de l'acceptation par les utilisateurs.
Le parcours réel au comptoir
Le vendeur recherche le compte de l'entreprise et constate qu'elle est cliente, que son historique est régulier, que le montant demandé reste cohérent et qu'aucun incident particulier n'est présent. La personne scanne un QR code ou utilise le canal prévu. Elle s'authentifie via un Identity Provider accepté. Le magasin reçoit les informations nécessaires pour rapprocher la personne du compte professionnel. Le système vérifie ensuite qu'elle est déjà connue au titre de ce compte, ou qu'elle correspond à un représentant enregistré, ou que l'opération doit être validée par un responsable de l'entreprise, ou qu'une première Delegated Authority doit être formalisée. Le vendeur n'a pas à devenir expert en détection de faux documents ; le client n'a pas à constituer un dossier disproportionné.
Le collaborateur qui n'est pas représentant légal
Dans le bâtiment, les achats sont rarement effectués par le dirigeant : ce sont plutôt un conducteur de travaux, un chef de chantier, un acheteur, un collaborateur habilité ou un prestataire agissant pour le compte de l'entreprise. La personne peut être parfaitement légitime sans apparaître sur le Kbis. Le système doit permettre de représenter la délégation : le dirigeant ou un responsable enregistré inscrit un collaborateur autorisé, l'entreprise confirme une demande, une délégation est bornée dans le temps, un plafond est fixé, certains magasins ou certaines familles de produits sont autorisés, et les opérations importantes appellent une validation supplémentaire. L'identité nous dit qui agit. La délégation nous dit au nom de qui et jusqu'où cette personne peut agir.
Le fournisseur d'identité aide, il ne décide pas
L'Identity Provider apporte une preuve sur l'identité ou l'authentification de la personne. Il ne décide pas à la place du magasin s'il faut accorder le délai de paiement. Le magasin combine cette preuve avec le compte de l'entreprise, son historique, le montant de la commande, la liste des acheteurs déjà connus, les délégations enregistrées, les incidents de paiement et sa propre politique commerciale. Fédérer une identité ne signifie pas externaliser toute la relation client. Cela permet d'emprunter une confiance déjà construite lorsque cette confiance correspond au besoin.
Ce que la Business Identity change par rapport à un compte particulier
Le compte auquel nous rattachons la personne n'est pas un compte particulier au sens strict : c'est un Corporate Account, avec ses propres attributs — historique de commandes, encours, plafonds, incidents, liste d'acheteurs autorisés, magasins fréquentés. Le rattachement d'une personne à ce compte doit être explicite, révisable et révocable. Une personne peut être ajoutée, retirée, restreinte à certains magasins, à certains montants, à certains types d'opérations. La Business Identity du magasin n'est pas simplement une somme de comptes particuliers ; c'est un objet qui a sa propre gouvernance et qui doit être conçu en tant que tel.
Là où Ping Identity intervient dans notre pratique
Ping Identity est notre partenaire technologique de référence sur l'Access Management et le CIAM. Selon les composants retenus, Ping peut contribuer à orchestrer les parcours d'authentification, fédérer des Identity Providers externes, gérer les sessions, appliquer une Adaptive Authentication, collecter et évaluer les signaux de risque, établir une confiance dans le terminal, déclencher un step-up et sécuriser les parcours de récupération. Nous ne présentons jamais ces capacités comme automatiquement fournies par un seul module ou comme automatiquement disponibles dans chaque projet : elles s'assemblent selon l'architecture cible. Lorsque le contexte existant ou le projet le nécessite, nous intervenons également sur des architectures Microsoft Entra ID ou Keycloak.

Le rapport avec la fraude, et la question de la vie privée

Nous ne mettons pas en place une Adaptive Authentication, un Risk Score, une fédération d'identités, une vérification d'identité ou une gestion de délégations pour collectionner des données. Nous les mettons en place pour empêcher des fraudes concrètes. Dans le premier cas, la prise de contrôle d'un compte après perte du téléphone, le détournement du parcours de récupération, l'utilisation d'un mot de passe compromis. Dans le second, l'usurpation d'un professionnel, l'utilisation frauduleuse du compte d'une entreprise, la demande de crédit par une personne non habilitée ou la commande passée au nom d'une société réelle par un tiers. Le contrôle doit être proportionné à la perte potentielle et à la confiance déjà acquise.

Plus l'organisation collecte de Behavioral Signals et de signaux de terminal, plus elle peut enrichir son analyse. Elle augmente également la quantité de données traitées, la sensibilité du profil construit, les obligations d'information, les conséquences d'une fuite, le risque d'une décision opaque et la charge liée au consentement et à la conservation. Nous ne considérons donc pas que davantage de signaux signifie automatiquement davantage de sécurité. Chaque signal doit répondre à quatre questions : apporte-t-il réellement de la valeur à la détection de fraude, est-il légitime de le collecter, combien de temps doit-il être conservé, et la même décision pourrait-elle être prise avec une information moins intrusive ? La fraude ne justifie pas de tout observer. Elle justifie de choisir les signaux qui changent réellement la décision.

Nous rencontrons régulièrement des organisations qui imposent le SMS à tous parce qu'il est simple à déployer, qui traitent tout nouveau terminal comme une fraude, qui laissent un score opaque bloquer un client régulier, qui demandent une pièce d'identité pour des actions sans enjeu, qui considèrent le Kbis comme une preuve de l'identité du porteur, qui confondent identité du dirigeant et délégation des collaborateurs, qui font confiance à un Identity Provider sans vérifier le niveau de preuve transmis, ou qui collectent de nombreux signaux sans savoir lesquels influencent réellement la décision. Ce ne sont pas des mauvaises intentions : ce sont les conséquences d'un parcours conçu sans questionner la fraude qu'il vise à empêcher.

La confiance est cumulative. Aucun élément ne suffit toujours à lui seul. Dans le cas du téléphone, le mot de passe correct, le terminal cohérent, la localisation habituelle, l'absence de comportement anormal et la faible sensibilité de l'action peuvent produire ensemble une confiance suffisante. Dans le cas du client professionnel, l'entreprise existante, le compte régulier, la personne authentifiée, sa relation connue avec le compte, le montant cohérent et l'absence d'incident forment un ensemble. Nous ne cherchons pas systématiquement une preuve parfaite. Nous cherchons une combinaison de preuves suffisamment cohérente pour l'action demandée.

Ce que nous demandons avant de concevoir un parcours

Le client qui avait perdu son téléphone n'a pas été soumis à un parcours disproportionné. Son mot de passe, son contexte et le faible niveau de risque associé à sa tentative ont permis de rétablir la session. Un step-up serait resté disponible si les signaux avaient été incohérents. Le professionnel présent au comptoir n'a pas obtenu son délai de paiement uniquement parce qu'il possédait un Kbis : le magasin a combiné l'existence de l'entreprise, son historique commercial, l'identité de la personne, sa relation avec le compte professionnel et son autorité pour engager cette opération.

Dans les deux cas, l'organisation n'a pas cherché à tout savoir. Elle a cherché à savoir assez pour accepter la demande sans exposer inutilement le client, l'entreprise ni elle-même. Lorsque nous concevons un parcours CIAM, nous ne commençons pas par demander comment identifier davantage le client. Nous commençons par demander quelle fraude nous cherchons à empêcher, quelle confiance nous possédons déjà et quelle preuve manque réellement pour accepter l'action.

Parlons de votre projet IAMNous écrire