Les workflows orchestrés de Didit sont la manière la plus puissante et la plus souple de concevoir et de déployer des parcours de vérification d’identité complets et en plusieurs étapes.
Cette leçon de Didit Academy construit un workflow de vérification dans la console réelle, du modèle jusqu’au flux publié : choix des contrôles sur chaque nœud, règles et seuils, embranchements AML, nœuds webhook et retour à une version antérieure.
Ce parcours d’intégration vous permet d’exploiter toute l’intelligence de la plateforme Didit V2 et de créer des séquences de vérification sophistiquées grâce à notre éditeur visuel sans code. Vous définissez la logique une seule fois dans votre Business Console, et Didit prend en charge toute l’expérience utilisateur, la gestion des états et les étapes conditionnelles.
Choisissez ce parcours lorsque vous avez besoin d’une solution complète, de bout en bout, pour l’onboarding des utilisateurs (KYC), la vérification de l’âge ou la réauthentification, et que vous souhaitez vous lancer rapidement avec un effort de développement minimal tout en gardant un contrôle maximal sur le processus.
Méthodes d’identification par pays
Dans Vérification d’identité, ouvrez Pays et méthodes d’identification autorisées pour configurer, pour chaque pays, la capture de document, la recherche sans document et les portefeuilles d’identité numérique.
Paramètres supplémentaires contient les sous-types de documents, les tentatives de recherche et les règles de repli.
La recherche sans document est facturée selon les tarifs du service Validation en base de données de votre organisation.
Chaque tentative terminée est facturée séparément, y compris les correspondances partielles et les absences de correspondance : deux tentatives terminées donnent donc lieu à deux facturations.
Les erreurs de format et les pannes du fournisseur qui ne renvoient aucune réponse ne sont pas facturées.
Si plusieurs services de base de données répondent à une même tentative, leurs tarifs applicables s’additionnent.
La valeur par défaut est une tentative avant le repli, configurable de une à cinq.
La capture de document est facturée en supplément lorsqu’une recherche terminée bascule vers les documents.
Les applications en production ne peuvent activer que les portefeuilles disponibles pour la production.
Les portefeuilles en attente de lancement restent désactivés.
Les applications sandbox peuvent tester chaque portefeuille du catalogue avec des résultats simulés ; la disponibilité en sandbox n’indique pas la disponibilité en production.
Consultez Test en sandbox pour les scénarios de défaillance de la recherche et des portefeuilles.
Gestion des versions des workflows
Les workflows prennent en charge la gestion des versions en brouillon et publiées. Vous pouvez ainsi modifier votre workflow en toute sécurité, sans affecter les sessions en cours :
- Les versions brouillon sont entièrement modifiables : vous pouvez ajouter, supprimer ou restructurer librement les nœuds
- La publication d’un brouillon crée une version immuable, que les nouvelles sessions utiliseront
- Les versions précédentes sont conservées, de sorte que vous pouvez inspecter la configuration exacte utilisée pour n’importe quelle session passée
- Les sessions font toujours référence à la version précise avec laquelle elles ont été créées, ce qui garantit la cohérence même après la publication de mises à jour
Pour modifier un workflow publié, créez un nouveau brouillon à partir de la version publiée, modifiez-le, puis publiez-le lorsqu’il est prêt. L’historique des versions est disponible via la Management API.
Deux façons de créer des workflows
Didit propose deux approches distinctes pour créer des workflows de vérification, afin que vous puissiez choisir le niveau de complexité adapté à vos besoins :
1. Mode simple : création à partir de modèles
Le Mode simple est idéal pour bien démarrer rapidement. Sélectionnez un modèle prédéfini, activez ou désactivez les fonctionnalités dont vous avez besoin, et vous êtes prêt à l’emploi.
Idéal pour :
- Une mise en place et un déploiement rapides
- Les parcours de vérification standard
- Les équipes qui découvrent la vérification d’identité
- Les cas d’usage qui correspondent à des schémas courants
Fonctionnement :
- Choisissez un modèle de workflow (KYC, vérification de l’âge, etc.)
- Activez ou désactivez les fonctionnalités (détection du vivant, correspondance faciale, AML, etc.)
- Configurez les paramètres de base de chaque fonctionnalité
- Publiez et commencez les vérifications
2. Mode avancé : constructeur visuel par graphe
Le Mode avancé exploite toute la puissance du moteur d’orchestration de Didit. Créez des parcours de vérification complexes et conditionnels à l’aide de notre éditeur de graphe visuel, avec des nœuds, des branches et une logique personnalisée par glisser-déposer.
Idéal pour :
- Les parcours de vérification complexes à plusieurs chemins
- La logique conditionnelle fondée sur les données utilisateur ou les résultats de vérification
- Les règles métier personnalisées et les embranchements
- Les exigences de conformité de niveau entreprise
Principales capacités :
- Éditeur visuel de nœuds : faites glisser, déposez et connectez les nœuds sur un canevas infini
- Connexions intelligentes : faites glisser depuis la poignée d’un nœud vers un espace vide pour créer et connecter immédiatement un nouveau nœud
- Branches conditionnelles : orientez les utilisateurs selon les données extraites, le statut de vérification, le pays, le type de document, le sous-type de document, la date de délivrance, l’âge, les chemins JSON des réponses de webhook ou des règles personnalisées
- Automatisation des actions : ajoutez des tags, définissez des métadonnées ou envoyez vers un examen manuel en fonction de l’issue du flux
- Raccourcis clavier : annuler (Ctrl/Cmd+Z), rétablir (Ctrl/Cmd+Shift+Z), supprimer (Delete/Backspace)
- Zoom et déplacement : parcourez les flux complexes en zoomant avec la molette et en vous déplaçant par glisser-déposer
Types de nœuds du graphe
Catégories de nœuds de fonctionnalité
Fonctionnalités interactives avec l’utilisateur (peuvent démarrer un workflow) :
- Vérification d’identité (OCR)
- Détection du vivant
- Correspondance faciale
- Estimation de l’âge
- Vérification du téléphone
- Vérification de l’e-mail
- Questionnaire
- Justificatif de domicile
- Document AI
- NFC / ePassport
Fonctionnalités uniquement côté serveur (s’exécutent automatiquement, sans interaction avec l’utilisateur) :
- Filtrage AML (nécessite une étape de vérification d’identité, de registre KYB ou de Document AI en amont - voir Entité filtrée)
- Validation en base de données (nécessite d’abord l’OCR)
- Analyse de l’appareil et de l’IP
Remarque : les fonctionnalités en arrière-plan sont signalées par un indicateur particulier dans le constructeur et s’exécutent automatiquement, sans interaction avec l’utilisateur, dès que leurs dépendances sont satisfaites.
Le premier onglet de configuration de chaque nœud de fonctionnalité commence par un contrôle Moteur de vérification : exécutez la vérification avec le moteur propre de Didit, ou basculez vers un fournisseur tiers que vous connectez depuis la Marketplace, avec un repli automatique vers Didit si ce fournisseur est indisponible.
Entité filtrée
Le filtrage AML apprend généralement qui il doit contrôler à partir de l’étape qui le précède : la personne dont les informations ont été relevées sur un document par une étape Vérification d’identité, ou l’entreprise renvoyée par une étape Registre KYB. Certains flux n’ont ni l’une ni l’autre. Un flux construit entièrement sur Document AI - des documents non standardisés, comme une attestation fiscale ou un acte de constitution notarié - contient déjà le nom, la date de naissance, le numéro de document et le pays, mais sous vos propres clés de champ.
L’onglet Avancé du nœud AML permet d’associer ces clés au filtrage :
- Type d’entité - filtrer une personne, ou l’entreprise nommée dans un document téléversé. Un nœud d’entreprise recherche dans les registres d’entreprises et non parmi les personnes.
- Sources des champs - associer chacune des quatre entrées de filtrage (nom, date de naissance, pays, numéro de document) à un champ Document AI, à une réponse de questionnaire ou à une valeur que vous envoyez lors de la création de la session (
expected_details / metadata). Un champ Document AI que vous avez déjà nommé full_name est repris automatiquement.
- Données de filtrage incomplètes - ce qui se passe lorsque le filtrage s’exécute sur une identité partielle. L’examen manuel est l’option par défaut ; choisissez Aucune action uniquement lorsque le flux ne contient sciemment qu’un nom.
Deux points méritent votre attention avant de vous y fier. Sans étape Vérification d’identité ou KYB Registry, le nom est obligatoire : le workflow ne peut pas être publié tant qu’aucune valeur ne le renseigne, car il n’existe aucune recherche sans nom. Et la précision du filtrage AML dépend directement du nombre d’identifiants que vous fournissez : un filtrage sur le seul nom est à l’origine du volume de faux positifs dont se plaignent les réviseurs. Renseignez donc la date de naissance et le pays dès que le document les contient.
Quel enregistrement une condition lit. Une condition de branchement est liée au nœud de fonctionnalité à partir duquel elle a été construite, et elle lit le résultat de ce nœud. Lorsqu’un seul nœud a produit plusieurs enregistrements, la condition lit le plus récent. Cela compte surtout pour Analyse de l’appareil et de l’IP : Didit enregistre une observation par appareil et par adresse IP depuis lesquels une session est ouverte. Un utilisateur qui change de téléphone ou de réseau en cours de session laisse donc plusieurs enregistrements sur le même nœud. Une règle telle que IP COUNTRY is in [...] est alors évaluée sur la dernière observation, c’est-à-dire le même enregistrement affiché en premier dans le panneau Analyse de l’appareil et de l’IP de la session et dans le tableau ip_analyses du payload de décision. Les sessions comportant plus d’une observation portent aussi l’avertissement MULTIPLE_DEVICES_IN_SESSION, qui signale qu’il faut examiner la liste complète plutôt que le seul résultat de branchement.
Valeurs de pays. Les conditions de pays sont comparées sur le pays lui-même, et non sur sa notation. Choisissez les pays dans le sélecteur de champs : Didit normalise les deux côtés de la comparaison, donc une règle écrite en ISO 3166-1 alpha-3 (UKR) correspond toujours à une valeur saisie en alpha-2 (UA).
Valeurs manquantes, valeurs vides et comparaisons négatives. Un champ sans aucune valeur (le document ne la contient pas, la clé de métadonnées n’a pas été envoyée, la fonctionnalité ne s’est pas exécutée) ne correspond qu’aux comparaisons is empty et equals not_defined. Toutes les autres comparaisons (equals, contains, greater than, mais aussi not equals et not in) ne correspondent pas, et le nœud de branchement passe à sa branche suivante. Un champ contenant une chaîne vide est une valeur, et non un champ manquant : une session créée avec "metadata": {"credential_state": ""} échoue à metadata.credential_state equals IL, mais réussit not equals IL, not in [IL, MA, NJ] et equals "" (is empty correspond aux deux cas). Une branche qui approuve sur une comparaison négative approuve donc une session dont l’état a été envoyé vide, alors que la même session sans la clé emprunte la branche de repli. Lorsque vous routez sur not equals ou not in, ajoutez metadata.<key> is not empty à la même branche (logique ET) afin que les deux cas aboutissent là où une valeur absente doit aboutir. Les branches sont évaluées dans l’ordre et la première correspondance l’emporte. La branche de repli (celle sans condition) n’est prise que lorsqu’aucune autre branche ne correspond : donnez donc à chaque nœud de branchement une branche de repli qui mène là où vous voulez qu’une valeur inattendue aboutisse. Une session qui atteint En cours d’examen sans avertissement sur aucune fonctionnalité a été dirigée là par un nœud de statut du graphe, et non par une vérification ; la branche de repli d’un nœud de branchement en est la cause habituelle.
Métadonnées de session. Les valeurs envoyées dans metadata à la création de la session sont disponibles dans chaque branche sous la forme metadata.<key>. Elles peuvent être comparées à une valeur fixe ou à un autre champ de la session (par exemple metadata.min_age <= Age). Les nombres sont comparés comme des nombres : 18 et "18" se comportent de la même façon.
Sandbox / mode test. Les conditions de branchement, les métadonnées et les nœuds de statut s’exécutent dans le sandbox exactement comme en production, et le sandbox ne place jamais de session en examen de sa propre initiative. La différence tient au document : une session sandbox porte un document fictif sans État / région des États-Unis, donc les conditions Region ne peuvent pas correspondre. Consultez ce que le document fictif ne contient pas pour savoir comment tester les parcours qui dépendent de l’État.
Nouvelles soumissions. Les nœuds de branchement sont évalués à chaque tentative, y compris une nouvelle soumission. Lorsque vous renvoyez une session pour des étapes précises, les branches et les actions placées entre ces étapes s’exécutent de nouveau à mesure que l’utilisateur les refait, sur les données de la nouvelle tentative. Un utilisateur qui se déplace vers une juridiction restreinte entre deux tentatives est donc routé par la branche qui la couvre, et une branche qui aboutit à un résultat refusé met fin à la session renvoyée à cet endroit.
Voir la branche suivie par une session. Chaque décision de branchement prise par le workflow pendant l’exécution d’une session, et chaque nœud de résultat atteint, est enregistré dans la chronologie des événements de la session (Console session detail > Events, et GET /v3/session/{id}/decision/?include=events). Une ligne Routage du workflow indique le nœud de branchement, la condition qui a été satisfaite et le nœud vers lequel la session s’est poursuivie, ou indique qu’aucune condition n’a été satisfaite et que l’arête de repli du nœud a été empruntée. Une ligne Résultat du workflow indique le nœud de statut qui a défini le statut de la session. Lorsqu’un workflow envoie une session en En cours d’examen sans qu’aucune fonctionnalité ne la signale, ces lignes montrent le chemin suivi, y compris toute arête de repli et le nœud de résultat auquel elle a mené. Les décisions manuelles prises plus tard ne réécrivent pas ces événements de workflow. L’absence de donnée d’entrée est une cause possible : les conditions qui exigent une valeur metadata.* présente ne correspondent pas lorsque la clé a été omise à la création de la session. Les conditions qui testent explicitement une absence de donnée, comme is_empty ou equals avec not_defined, peuvent correspondre à cette même clé absente. L’arête de repli n’est empruntée que lorsqu’aucune branche ne correspond, y compris toute branche else, et mène au nœud relié à la sortie par défaut. Voir événements de session pour les payloads des événements.
Modèles de workflow, votre point de départ
Considérez les modèles non pas comme des types rigides, mais comme des points de départ intelligents et préconfigurés, conçus pour des cas d’usage courants. En mode simple, ils sont prêts à l’emploi. En mode avancé, ils constituent une base que vous pouvez personnaliser en profondeur.
Modèles disponibles
1. Workflow KYC
La solution complète pour l’intégration de nouveaux utilisateurs et le respect de l’ensemble des obligations de connaissance client (KYC).
- Commence par : la vérification de base du document d’identité.
- Fonctionnalités couramment ajoutées :
[+] Détection du vivant : vérifiez que l’utilisateur est physiquement présent et empêchez l’usurpation.[+] Correspondance faciale 1:1 : comparez biométriquement le selfie de l’utilisateur à la photo de sa pièce d’identité.[+] Filtrage AML : vérifiez les utilisateurs au regard des listes mondiales de sanctions, de personnes politiquement exposées et de presse négative.[+] Vérification NFC : ajoutez un niveau de sécurité gouvernemental en lisant les puces des passeports et des cartes d’identité électroniques.[+] Justificatif de domicile (PoA) : vérifiez l’adresse de résidence de l’utilisateur.[+] Vérification du téléphone : validez la propriété du numéro de téléphone comme facteur supplémentaire.[+] Vérification de l’e-mail : validez la propriété de l’adresse e-mail comme facteur supplémentaire.[+] Validation en base de données : validez les informations auprès des bases de données officielles des administrations et des bases de crédit.[+] Questionnaire : recueillez des attestations structurées et des documents justificatifs via des formulaires personnalisables.[+] Analyse de l’appareil et de l’IP : analysez le risque lié à la localisation et à la connexion.
2. Workflow de vérification d’âge adaptatif
Un parcours peu contraignant et respectueux de la vie privée, destiné aux services soumis à une limite d’âge.
- Commence par : l’estimation de l’âge à partir d’un selfie.
- Logique clé :
- Si l’âge estimé est nettement supérieur à votre seuil (par exemple, un âge estimé de 25+ pour un service réservé aux 18+), l’utilisateur est validé immédiatement.
- Si l’estimation est inférieure ou se situe dans une « zone tampon » (par exemple, un âge estimé entre 16 et 20 ans), vous pouvez configurer le workflow pour déclencher automatiquement une solution de repli vers la vérification d’identité complète afin de confirmer la date de naissance exacte.
- Fonctionnalités couramment ajoutées :
[+] Analyse de l’appareil et de l’IP : restreignez l’accès en fonction de la localisation géographique.
3. Workflow d’authentification biométrique
Un moyen rapide et sécurisé de revérifier les utilisateurs existants, sans leur demander à nouveau leurs documents.
- Commence par : un contrôle de détection du vivant pour confirmer la présence de l’utilisateur.
- Logique principale :
- Le système effectue une correspondance faciale entre le nouveau selfie en direct et le gabarit biométrique de confiance issu de la vérification KYC initiale approuvée de l’utilisateur.
- Si l’utilisateur dispose déjà d’un visage enregistré sous le même
vendor_data (visage approuvé lors de la détection du vivant, photo du passeport électronique, portrait de la pièce d’identité ou visage du profil enregistré), vous pouvez omettre portrait_image lors de la création de la session, et Didit réutilise automatiquement le visage enregistré. Sinon, transmettez portrait_image (image encodée en Base64, 2 Mo maximum) ; sans l’un ou l’autre, la création de la session échoue avec 400.
- Fonctionnalités couramment ajoutées :
[+] Vérification du téléphone : associez l’adresse à un numéro de téléphone vérifié.[+] Vérification de l’e-mail : validez la propriété de l’adresse e-mail comme facteur supplémentaire.[+] Analyse de l’appareil et de l’IP : signalez les tentatives de connexion suspectes depuis de nouvelles localisations.
4. Workflow de vérification d’adresse
Un parcours dédié aux cas où le justificatif de domicile (PoA) est l’exigence principale.
- Commence par : l’envoi d’un justificatif de domicile par l’utilisateur (par exemple, une facture de services publics ou un relevé bancaire).
- Logique principale : notre IA extrait et valide le nom et l’adresse figurant dans le document.
- Fonctionnalités couramment ajoutées :
[+] Vérification du téléphone : associez l’adresse à un numéro de téléphone vérifié.[+] Vérification de l’e-mail : validez la propriété de l’adresse e-mail comme facteur supplémentaire.[+] Analyse de l’appareil et de l’IP : comparez l’adresse du document à la géolocalisation actuelle de l’utilisateur pour un niveau de garantie supplémentaire.
5. Workflow de vérification par questionnaire
Un parcours ciblé, à utiliser lorsque votre objectif principal est de recueillir des attestations structurées et des documents justificatifs via des formulaires personnalisables.
- Commence par : Questionnaire.
- Logique principale : le système présente le questionnaire que vous avez configuré (sections, contenu traduit, champs obligatoires, envois de fichiers).
- Fonctionnalités couramment ajoutées :
[+] Analyse de l’appareil et de l’IP : ajoutez le contexte de localisation et de connexion à vos envois de questionnaires.
Personnalisation complète
Chaque fonctionnalité d’un workflow peut être personnalisée davantage à l’aide de paramètres spécifiques, afin de répondre exactement à vos besoins. Explorez les paramètres de chaque vérification dans le créateur.
Créer des règles selon le statut matrimonial
En mode avancé, vous pouvez utiliser le champ OCR kyc.marital_status dans les branches conditionnelles et les règles de statut personnalisées. Choisissez la valeur dans le sélecteur de champs afin que la règle utilise l’énumération prise en charge plutôt qu’un texte libre. Si le document ne fournit pas le statut matrimonial, la valeur est vide et votre branche de repli s’applique.
Le copilote de workflow peut également créer et configurer des étapes Validation en base de données en une seule action. Lorsque vous lui demandez d’ajouter cette vérification, indiquez les pays dont vous avez besoin : la console détermine le service pris en charge pour chaque pays et affiche la configuration enregistrée sur le canevas.
Comparaison des modes Simple et Avancé
Flux d’intégration
L’intégration d’un workflow orchestré est simple. Votre serveur crée une session auprès de Didit, reçoit une URL unique et redirige votre utilisateur vers cette URL. Didit gère le reste et notifie votre serveur des résultats via des webhooks.
Cas d’usage courants
| Cas d’usage | Modèle recommandé | Mode recommandé | Fonctionnalités suggérées |
|---|
| Vérification d’identité de base | KYC | Simple | Détection du vivant, Correspondance faciale |
| Onboarding à haute sécurité | KYC | Avancé | NFC, Détection du vivant, Correspondance faciale, AML, Vérification du téléphone |
| Contenus et services soumis à une restriction d’âge | Vérification d’âge adaptative | Simple | Repli sur la vérification d’identité |
| Authentification des utilisateurs récurrents | Authentification biométrique | Simple | Analyse de l’appareil et de l’IP |
| Vérification d’adresse | Justificatif de domicile | Simple | Vérification du téléphone |
| Onboarding pour les services financiers | KYC | Avancé | Détection du vivant, Correspondance faciale, Justificatif de domicile, AML, Validation en base de données |
| Conformité propre à une région | KYC | Avancé | Routage conditionnel par pays, contrôles différents selon la région |
| Vérification fondée sur le risque | KYC | Avancé | Branchements conditionnels selon les scores de risque, chemins d’escalade |
Premiers pas
- Vous découvrez Didit ? Commencez avec le Mode Simple et un modèle prédéfini
- Besoin de personnalisation ? Passez au Mode Avancé pour ajouter une logique conditionnelle
Contactez notre équipe commerciale pour discuter de configurations de workflow personnalisées ou pour obtenir des conseils sur la configuration la mieux adaptée à vos besoins spécifiques.
Dernière modification le 7 novembre 2026
Commencer
Intégrer / SDK
Vérification des utilisateurs
Vérification d'entreprise
Surveillance des transactions
Journal des modifications
