> ## 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. # Constructeur de workflows KYC sans code > Concevez vos parcours KYC sans code avec le constructeur visuel Didit : ID, vivacité, AML, NFC, logique conditionnelle. Payez les étapes terminées. 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. [Créer votre premier workflow de vérification : Didit Academy](https://www.youtube.com/embed/7-nJ3JE20i4?rel=0\&playsinline=1) 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](https://docs.didit.me/fr/integration/sandbox-testing.md) 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 : ![Modes de création simple et avancé du workflow KYC de Didit, côte à côte](https://mintcdn.com/didit-0f962782/DSfxHq_ggIpqiQSG/images/workflows-simple-and-complex.jpg?fit=max\&auto=format\&n=DSfxHq_ggIpqiQSG\&q=85\&s=07f4e97f94cb1179de16732573612b6e) ### 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. ![Interface de création à partir de modèles en mode simple pour le workflow de vérification d'identité de Didit](https://mintcdn.com/didit-0f962782/DSfxHq_ggIpqiQSG/images/workflows-simple.jpg?fit=max\&auto=format\&n=DSfxHq_ggIpqiQSG\&q=85\&s=ebe4da7cf6549793629497fb36053fe2) **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 :** 1. Choisissez un modèle de workflow (KYC, vérification de l'âge, etc.) 2. Activez ou désactivez les fonctionnalités (détection du vivant, correspondance faciale, AML, etc.) 3. Configurez les paramètres de base de chaque fonctionnalité 4. 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. ![Constructeur visuel de workflow basé sur des nœuds](https://mintcdn.com/didit-0f962782/z6T2GHM4Zh-iSj-K/images/node-based-workflow.png?fit=max\&auto=format\&n=z6T2GHM4Zh-iSj-K\&q=85\&s=2c0997ab8bbb09dbf7c4cb26b201eced) **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](https://docs.didit.me/fr/core-technology/id-verification/document-subtypes-id-verification.md), 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 | Type de nœud | Couleur de l'icône | Description | Exemples | | - | - | - | - | | **Nœuds de fonctionnalité** | Bleu | Vérifications qui traitent les données utilisateur | Vérification d'identité (OCR), Détection du vivant, Correspondance faciale, NFC, AML, Vérification du téléphone/e-mail, Questionnaire, Justificatif de domicile, Document AI, Validation en base de données, Analyse de l'appareil et de l'IP, Estimation de l'âge | | **Nœuds de branche** | Violet | Routage conditionnel selon les données ou les résultats | Routage selon le pays, le score de risque, le type de document, le sous-type de document, l'âge, la date de délivrance, le nombre de mois depuis la délivrance, le statut de vérification | | **Nœuds d'action** | Ambre | Déclencheurs d'automatisation qui modifient les données de la session ou de l'utilisateur | Ajouter un tag, Supprimer un tag, Définir des métadonnées, Ajouter une note d'examen | | **Nœuds de webhook** | Cyan | Requêtes HTTP qui peuvent alimenter les branches suivantes | Envoyer les données de session à votre serveur, analyser les réponses JSON, brancher selon des chemins tels que `category`, `status` ou `tags.0` | | **Nœuds de statut** | Vert/Rouge/Ambre | Résultats finaux qui mettent fin au flux de vérification | Approuvé, Refusé, En cours d'examen | #### 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](#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](https://docs.didit.me/fr/console/marketplace.md), 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. #### Comment les conditions de branchement lisent les données de session **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. 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.`. 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](https://docs.didit.me/fr/integration/sandbox-testing.md#ce-que-le-document-fabriqué-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](https://docs.didit.me/fr/sessions-api/retrieve-session.md#événements-de-routage-du-workflow) 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. ![Galerie des modèles de workflow Didit KYC pour les cas d'usage KYC, KYB et de vérification de l'âge](https://mintcdn.com/didit-0f962782/DSfxHq_ggIpqiQSG/images/workflows-template.jpg?fit=max\&auto=format\&n=DSfxHq_ggIpqiQSG\&q=85\&s=a727315368aa2f6bd096e873d7fbae6c) ### 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é | Fonctionnalité | Mode Simple | Mode Avancé | | - | - | - | | Sélection de modèle | ✅ | ✅ | | Activer ou désactiver les fonctionnalités | ✅ | ✅ | | Configuration de base des fonctionnalités | ✅ | ✅ | | Éditeur visuel de graphe | ❌ | ✅ | | Branchements conditionnels | ❌ | ✅ | | Automatisation des actions (tags, métadonnées) | ❌ | ✅ | | Chemins de vérification parallèles | ❌ | ✅ | | Décisions basées sur le risque | Limitée | ✅ Contrôle total | | Prise en charge de l'annulation et du rétablissement | ❌ | ✅ | | Raccourcis clavier | ❌ | ✅ | *** ## 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. ```mermaid theme={null} sequenceDiagram participant Customer participant Client participant Server participant Didit Customer->>Client: Go to verification page Client->>Server: POST /create-verification-session Server->>Didit: POST /v3/session/ Didit-->>Server: Return new verification session Server-->>Client: Return verification session's url Client->>Customer: Redirect customer to url Customer->>Didit: Complete verification steps Didit->>Server: Send status updates Server->>Customer: Notify of status changes Customer->>Customer: Return to callback URL ``` *** ## 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 1. **Vous découvrez Didit ?** Commencez avec le **Mode Simple** et un modèle prédéfini 2. **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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.