> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Vérification d'identité : ce que voient les utilisateurs

> Transcription vidéo du parcours KYC avec Didit : personnalisation, document, NFC, détection du vivant, correspondance faciale et refus.

[Ce que voient réellement vos utilisateurs lors d'une vérification KYC (visite guidée complète)](https://www.youtube.com/embed/LzGe-dMWjUw)

Transcription complète de **Ce que voient réellement vos utilisateurs lors d'une vérification KYC (visite guidée complète)** - Vidéo 2 sur 10 de Didit Academy, 14:36. [Regarder sur YouTube](https://www.youtube.com/watch?v=LzGe-dMWjUw). Chaque paragraphe renvoie au moment exact de la vidéo.

## Ce que couvre cette vidéo

[00:03](https://www.youtube.com/watch?v=LzGe-dMWjUw\&t=3s) Quand vous envoyez un client vérifier son identité avec Didit, que voit-il exactement ? C'est l'objet de cette vidéo. Nous allons parcourir tout le parcours de son point de vue : les écrans exacts qu'une personne parcourt après avoir cliqué sur votre lien. Un parcours entièrement aux couleurs de votre marque, dans sa propre langue, sur l'appareil dont il dispose, avec une série de contrôles invisibles qui font l'essentiel du travail, et le résultat réel qui arrive dans votre système dès qu'il est établi. Le meilleur moyen de s'en faire une idée est de lancer un parcours vous-même. Rendez-vous donc sur didit.me : vous pouvez vous inscrire gratuitement et vérifier avec votre propre téléphone en

## Ouvrir le parcours vous-même

[00:38](https://www.youtube.com/watch?v=LzGe-dMWjUw\&t=38s) quelques minutes. Bon, la façon la plus simple de voir exactement ce que vivent vos utilisateurs est d'ouvrir le parcours vous-même. C'est ce que nous allons faire. Nous allons aller sur l'un de nos workflows, copier le lien et le coller dans le navigateur. Prenons ce workflow KYC de base. Nous copions ce lien et le collons ici. Voici donc

## Le premier écran que voit votre utilisateur

[00:58](https://www.youtube.com/watch?v=LzGe-dMWjUw\&t=58s) la toute première chose que voit votre utilisateur après avoir cliqué sur l'un de vos liens. Première remarque : il s'agit d'une démo. La marque Didit est donc affichée, mais vous pouvez entièrement la personnaliser. Cette liste présente chaque étape que cet utilisateur va parcourir : vérification d'identité, vérification faciale et documents supplémentaires. Cette liste n'est pas codée en dur. Le workflow auquel cette session est rattachée détermine les étapes affichées et leur ordre. Ce parcours affiche donc simplement ce que contient le workflow lorsque vous l'activez

## Image de marque, et pourquoi elle améliore la finalisation

[01:28](https://www.youtube.com/watch?v=LzGe-dMWjUw\&t=88s) le logo et le style sont également les vôtres. Pour l'utilisateur, cela reste donc votre produit. C'est essentiel, car la ressemblance avec votre marque est le levier le plus important pour déterminer combien de personnes terminent réellement ce parcours de vérification. Une petite mention « sécurisé par Didit » apparaît ici, et même celle-ci peut être retirée. Tout ce qui se trouve au-dessus vous appartient et peut être configuré. Didit n'est que le moteur qui fonctionne en arrière-plan. Ce que voit l'utilisateur est donc exactement le workflow que vous avez configuré, enveloppé dans votre marque. Voici

## Les contrôles qui n'affichent jamais d'écran

[02:00](https://www.youtube.com/watch?v=LzGe-dMWjUw\&t=120s) quelque chose qui surprend la plupart des gens : tous les contrôles que vous voyez ici n'ont pas forcément d'écran. Les seules étapes affichées sont celles qui exigent réellement une action de l'utilisateur. Document, visage, téléphone, e-mail : pendant qu'il effectue ces étapes, toute une série d'autres contrôles s'exécute côté serveur, sans que personne n'y touche. L'analyse de l'appareil et de l'IP, le filtrage AML, la surveillance AML continue et la validation en base de données se déroulent tous en arrière-plan. L'utilisateur ne voit aucune étape correspondante, et vous recevez quand même tous les résultats dans votre tableau de bord. C'est ce qui permet au parcours de rester très court tout en effectuant un travail considérable. Certains des contrôles les plus solides de Didit n'ajoutent aucune friction, parce qu'ils ne s'adressent jamais à l'utilisateur. Donc si vous revenez examiner l'un de ces workflows, nous voyons ici tous ces contrôles en arrière-plan. Nous avons la validation en base de données. Nous avons la vérification de l'e-mail, la vérification du téléphone, le filtrage AML, l'analyse IP et des risques. Ces contrôles ne sont pas visibles par l'utilisateur. Ce sont tous les contrôles que

## Personnalisation : couleurs, logo, e-mail et domaine

[03:00](https://www.youtube.com/watch?v=LzGe-dMWjUw\&t=180s) vous pouvez ajouter dans un workflow. Regardons l'onglet Personnalisation. C'est là que vous pourrez ajouter votre marque, vos couleurs, votre propre adresse e-mail, votre propre domaine, tout cela. Comme vous le voyez, nous pouvons changer le nom de l'application. Nous pouvons afficher la page d'accueil ou la désactiver. Nous pouvons afficher la barre de progression ou la désactiver. Il y a l'onglet Marque, où nous pouvons ajouter toutes ces couleurs. Nous pouvons ajouter le logo et le favicon, et modifier la typographie. Nous pouvons ajouter un e-mail personnalisé.

[03:25](https://www.youtube.com/watch?v=LzGe-dMWjUw\&t=205s) Si vous saisissez simplement un nom ici, nous pouvons indiquer une adresse e-mail et passer à la vérification. Cela va nous donner le... ça ne marche pas. Mais si nous saisissons un domaine réel et fonctionnel et cliquons sur continuer vers la vérification, cela nous donnera les enregistrements DNS à ajouter, et nous pourrons configurer une adresse e-mail personnalisée. Cette adresse est celle depuis laquelle seront envoyées les notifications, ainsi que toutes les mises à jour sur le statut de la vérification. Pour le domaine, nous pouvons aussi ajouter un domaine personnalisé. Par exemple, si nous avions un sous-domaine. Et là encore, si vous saisissez votre sous-domaine ici, il vous donnera les enregistrements que vous devez mettre à jour chez votre fournisseur de domaine. Vous voyez ce globe en haut ici. Le

## 54 langues, détection automatique

[04:04](https://www.youtube.com/watch?v=LzGe-dMWjUw\&t=244s) l'interface est disponible en 54 langues différentes, y compris les écritures de gauche à droite comme l'arabe. Par défaut, ce parcours détecte automatiquement la langue du navigateur et revient à l'anglais si cette langue n'est pas prise en charge. Mais l'utilisateur peut ouvrir cette liste consultable et passer à n'importe quelle langue à tout moment, et toutes les instructions suivront son choix à partir de là. Et si vous connaissez déjà la langue de quelqu'un à l'avance, par exemple dans votre propre base de données, vous pouvez la définir lors de la création de sa session. Elle s'ouvrira alors dans la bonne langue, sans dépendre du navigateur. Le parcours rencontre donc l'utilisateur dans sa propre langue automatiquement, parmi 54 choix. Donc, si nous jetons un œil à

## Mobile ou ordinateur, et le transfert par QR code

[04:49](https://www.youtube.com/watch?v=LzGe-dMWjUw\&t=289s) Dans cet aperçu, vous voyez que la plupart des personnes finissent par effectuer la vérification sur leur téléphone. Et c'est logique, non ? L'appareil photo rend la capture d'un document et d'un selfie très simple. Il suffit de pointer son téléphone vers ce QR code pour poursuivre la vérification sur le téléphone. Lorsqu'une personne arrive sur cette page depuis un ordinateur, vous voyez ici qu'elle peut continuer sur ordinateur, mais c'est une option. Vous pouvez obliger les utilisateurs à vérifier uniquement depuis leur mobile, mais vous pouvez tout à fait autoriser l'ordinateur et leur permettre de terminer directement ici. Toutefois, sachez que, dans ce cas, le contrôle de détection du vivant passe automatiquement en mode passif sur ordinateur, car la version active fonctionne mal avec les webcams. Par « actif » et « passif », j'entends ceci : dans le mode actif, il faut

## Le parcours hébergé ou la création de vos propres écrans

[05:34](https://www.youtube.com/watch?v=LzGe-dMWjUw\&t=334s) cligner des yeux devant la caméra. C'est un contrôle de détection du vivant actif. Le mode passif consiste simplement en une photo. Le moyen le plus simple de commencer est le parcours hébergé. Lorsque je clique sur ce bouton pour copier le lien et que je l'ouvre dans mon navigateur, vous voyez que vous pouvez envoyer un lien à l'utilisateur, et que Didit gère toutes les parties difficiles à votre place : les autorisations de la caméra, la capture du document, la détection du vivant et chaque particularité fastidieuse des appareils. Vous pouvez donc l'intégrer à votre application via le SDK, un iframe, une redirection ou une pop-up. Et si vous préférez concevoir vos propres écrans à partir de zéro, vous le pouvez tout à fait. Mais vous devez alors vous charger de tout cela. Nous aborderons l'intégration en détail dans une autre vidéo ; pour l'instant, retenez simplement que le lien que vous envoyez et obtenez à partir de ce workflow correspond au parcours hébergé, conçu pour mener les utilisateurs jusqu'au bout.

## Détection du pays de délivrance

[06:20](https://www.youtube.com/watch?v=LzGe-dMWjUw\&t=380s) Revenons au workflow. Lorsque l'étape du document doit savoir de quel pays provient la pièce d'identité, le parcours a généralement déjà déterminé ce pays. Dès le chargement de la page, le système géolocalise l'utilisateur à partir de son adresse IP et présélectionne le pays de délivrance. Comme vous le voyez ici, ce pays a bien été identifié. Et si votre workflow n'autorise qu'un seul pays, celui-ci sera sélectionné automatiquement et l'utilisateur ne verra jamais ce sélecteur. Cet exemple porte sur un parcours KYC, mais cela fonctionne exactement de la même façon pour le KYB ou pour tout autre workflow que vous créez. Le moteur exécute simplement les étapes configurées dans votre workflow. Ensuite, comme vous le voyez sur cet aperçu, l'utilisateur

## Choisir un type de document

[07:00](https://www.youtube.com/watch?v=LzGe-dMWjUw\&t=420s) va choisir le document officiel qu'il présentera. Didit reconnaît sept types nommés : passeport, carte d'identité, titre de séjour, permis de conduire, carte d'assurance maladie, carte fiscale et carte de sécurité sociale. Cette liste est toutefois filtrée pour ne retenir que les types réellement valables pour le pays que nous venons de détecter. L'utilisateur ne peut donc pas choisir un document que Didit ne sait pas lire. Et là encore, si votre workflow n'autorise qu'un seul type de document, cet écran entier est ignoré et l'utilisateur

## Capture du document

[07:26](https://www.youtube.com/watch?v=LzGe-dMWjUw\&t=446s) passe directement à la page de capture. Si nous poursuivons, nous arrivons donc à la page de capture. Comme vous le voyez dans cet aperçu, je suis sur mon ordinateur, je peux donc importer un fichier ou prendre une photo. Vous pouvez aussi forcer une capture en direct : elle guide alors une prise de vue photo en temps réel, sans aucun import, et c'est le réglage le plus efficace contre les images falsifiées ou réutilisées. Pour l'import, les formats acceptés sont les classiques, JPEG, PNG et PDF, ainsi que quelques autres types de fichiers, d'une taille inférieure à 10 Mo. Si le PDF est protégé par un mot de passe, le système demande ce mot de passe. Vous pouvez donc autoriser l'import ou imposer une capture en direct, et tout cela se configure dans les paramètres de votre workflow. Comme vous le voyez dans cet aperçu, pendant que l'utilisateur aligne le document, des repères affichés sur l'appareil contrôlent la luminosité et la netteté, et la capture se déclenche automatiquement dès que la prise de vue est suffisamment bonne, afin que l'analyse commence immédiatement. Et Didit ne se contente pas de lire le texte de la carte. Le système effectue des contrôles d'authenticité et de falsification, ainsi qu'un contrôle de détection du vivant appliqué au document, qui repère par exemple la photo d'un écran ou une copie imprimée. Il vérifie aussi les éléments de sécurité et la validation de la MRZ dans plus de 130 langues de documents.

[08:37](https://www.youtube.com/watch?v=LzGe-dMWjUw\&t=517s) Et ce qui distingue vraiment cette solution, c'est que tout se passe en temps réel. L'utilisateur sait immédiatement si un document n'a pas fonctionné, et vous recevez exactement les mêmes données au même moment. Tout le monde y gagne donc en rapidité. Pour le

## Selfie avec détection du vivant

[08:50](https://www.youtube.com/watch?v=LzGe-dMWjUw\&t=530s) contrôle de détection du vivant, l'utilisateur peut prendre un selfie. Il lui suffit de centrer son visage dans l'ovale qui apparaît à l'écran à cette étape, comme vous le voyez ici. Derrière cet écran simple, un contrôle de détection du vivant vérifie qu'une personne réelle se trouve bien devant la caméra. C'est aussi ce qui permet à Didit de comparer le visage au document que l'utilisateur vient de soumettre. Vous pouvez donc choisir la méthode de détection du vivant utilisée à cette étape. Vous pouvez définir ce réglage pour chaque nœud du workflow ; nous y reviendrons dans d'autres

## Passif, 3D flash et 3D action

[09:17](https://www.youtube.com/watch?v=LzGe-dMWjUw\&t=557s) vidéos. Il existe trois réglages différents. Le mode passif, dans lequel l'utilisateur ne fait rien. Le 3D flash, où des lumières colorées construisent une carte de profondeur, sans rien demander non plus à l'utilisateur. Et le 3D action, qui ajoute les lumières ainsi qu'une petite action aléatoire, comme cligner des yeux ou tourner la tête. Il s'agit donc d'une seule étape de selfie, avec trois niveaux de détection du vivant parmi lesquels vous pouvez choisir. Donc

## La vidéo de détection du vivant et les scores

[09:41](https://www.youtube.com/watch?v=LzGe-dMWjUw\&t=581s) Voyons ce que vous apporte l'étape de détection du vivant. Elle enregistre une courte vidéo de la personne et lui attribue un score. Si nous allons dans les vérifications des utilisateurs et que nous faisons défiler la liste pour ouvrir le profil de l'un d'eux, ne vous inquiétez pas : nous verrons en détail tout ce qui figure dans cette vérification dans une autre vidéo. Mais pour vous montrer ce que fait réellement la détection du vivant et ce qu'elle vous fournit dans le profil, il s'agit d'une courte vidéo que vous pouvez voir ici.

[10:08](https://www.youtube.com/watch?v=LzGe-dMWjUw\&t=608s) Nous pouvons donc lancer la vidéo. Oui, il s'agit uniquement d'une vidéo de démonstration, mais c'est ce qui apparaîtra réellement pour chacun de vos utilisateurs dans l'étape de vérification. Nous avons ici un score de détection du vivant exprimé en pourcentage. Je reviendrai sur ce point dans une autre vidéo. Chacune des méthodes, passive ou active, produit donc un score de détection du vivant compris entre 1 et 100. Elle exécute en plus la détection des attaques par présentation et des deepfakes.

[10:30](https://www.youtube.com/watch?v=LzGe-dMWjUw\&t=630s) La vidéo est enregistrée à côté du score. Vous pouvez revenir la rejouer et consulter chaque score directement ici, dans la vérification, ainsi que dans le profil de l'utilisateur. Vous disposez donc de la vidéo du selfie, ainsi que des scores de détection du vivant et de deepfake.

## Ce qui se passe lorsqu'une étape échoue

[10:45](https://www.youtube.com/watch?v=LzGe-dMWjUw\&t=645s) à rejouer autant de fois que nécessaire. Que se passe-t-il lorsqu'une étape échoue ? L'utilisateur ne se retrouve pas dans une impasse. Il bénéficie d'une nouvelle tentative guidée et précise. Dans les paramètres de vos workflows, vous pouvez définir le nombre maximal de tentatives et la fenêtre de nouvelle tentative. Nous verrons plus en détail les paramètres et le fonctionnement de ces workflows dans une autre vidéo. Mais lorsque l'utilisateur voit un message de nouvelle tentative, celui-ci est précis, par exemple : le document est expiré, ou reprenez la photo avec un éclairage plus fort. Il ne s'agit surtout pas d'une erreur générique et vague. Il sait donc exactement quoi corriger, et le nombre de tentatives qui lui sont accordées est configurable, comme je viens de vous le montrer dans le workflow. Par défaut, le parcours le laisse réessayer jusqu'à ce qu'il réussisse, car l'objectif est de le faire aboutir, et non de le bloquer. Les tentatives sont donc réglables, et la valeur par défaut est

## L'écran d'approbation

[11:30](https://www.youtube.com/watch?v=LzGe-dMWjUw\&t=690s) conçue pour que l'utilisateur puisse toujours atteindre la fin du parcours. Ainsi, lorsque toutes les vérifications requises réussissent, l'utilisateur arrive sur cet écran : une coche verte et un message en langage clair. Vous êtes vérifié. Il lui indique qu'il n'a plus rien à faire et qu'il peut retourner dans votre application. Et voici ce qu'il ne voit pas : votre application a déjà reçu le verdict en temps réel avant même qu'il quitte l'écran. L'approbation se traduit donc par cet écran final vert et rassurant, et

## L'écran de vérification en cours

[11:54](https://www.youtube.com/watch?v=LzGe-dMWjUw\&t=714s) votre back end dispose déjà des résultats. Il arrive qu'une vérification automatisée émette un avertissement plutôt qu'un succès ou un échec net. Dans ce cas, l'utilisateur voit une horloge orange au lieu de cette coche verte, accompagnée du texte suivant : votre demande est en cours d'examen. De votre côté, la vérification apparaît alors comme en cours d'examen. Il vous revient, ou à un membre de votre équipe, de l'approuver, de la refuser ou de demander à l'utilisateur de soumettre à nouveau des informations complémentaires. Le point intéressant est que l'utilisateur reçoit un e-mail dès que le statut change sur sa

## L'écran de refus

[12:30](https://www.youtube.com/watch?v=LzGe-dMWjUw\&t=750s) demande de vérification. Si une vérification échoue réellement, l'utilisateur voit un état de refus clair : un symbole rouge accompagné du message « Nous n'avons pas pu vérifier vos informations pour le moment », qui explique le résultat sans révéler la moindre partie de votre logique de détection de fraude. La suite dépend entièrement de votre workflow. Vous pouvez laisser l'utilisateur soumettre à nouveau dans la limite des tentatives que vous avez définies, ou le diriger vers un parcours d'assistance dans votre propre application. Le refus est donc un écran final clair, sans aspect technique, et c'est vous qui décidez si cela signifie une nouvelle soumission ou une prise en charge par le support.

## Redirection et webhook, à quelle source se fier

[12:58](https://www.youtube.com/watch?v=LzGe-dMWjUw\&t=778s) Deux événements surviennent à la toute fin de ce workflow, et il est utile de savoir lequel privilégier. Premièrement, le navigateur de l'utilisateur revient vers votre application. Il retrouve donc l'endroit où il était, mais pour lui, cette étape n'est qu'un simple passage de relais. Ce sur quoi vous vous appuyez réellement, c'est le résultat que votre serveur reçoit au même moment : il est envoyé directement à votre back end dès que la décision est prise, et c'est sur cette version que vous devez construire votre logique. Ne vous fiez jamais à ce qui se trouve simplement dans le navigateur. Les détails techniques de cette mise en place feront l'objet d'une vidéo à part, nous les verrons donc plus tard. Ce qu'il faut retenir ici est simple : l'utilisateur revient dans votre application, et votre système dispose déjà du résultat fiable qui l'attend.

## Retrouver la session dans votre tableau de bord

[13:41](https://www.youtube.com/watch?v=LzGe-dMWjUw\&t=821s) Chaque vérification apparaît dans l'onglet des vérifications des utilisateurs. Nous disposons ici de filtres : nous voyons les statuts approuvé, en cours d'examen et refusé. Selon le résultat de la vérification et le workflow suivi, le statut se met à jour en conséquence. Les vérifications en cours d'examen sont évidemment celles auxquelles vous devez accorder le plus d'attention. Nous pouvons donc les filtrer pour ne garder que celles qui nécessitent un examen manuel. Pour chacune de ces vérifications, nous pouvons ouvrir le détail et consulter chaque élément de preuve à l'origine du résultat. Et cette valeur en bas, les données du fournisseur, correspond à l'identifiant que votre propre système a envoyé lors de la création de la session. C'est votre référence stable pour cette personne.

[14:25](https://www.youtube.com/watch?v=LzGe-dMWjUw\&t=865s) Et Didit regroupe-t-il sous un même profil toutes les sessions qui partagent le même identifiant de données fournisseur ?


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.