Passer au contenu principal
Didit lève 7,5 M$ pour bâtir l'infrastructure pour l'identité et la fraude
Didit
Retour au blog
Blog · 13 juin 2026

KYC Sans Code : Créer des Flux de Vérification sans Ingénierie (FR)

Un constructeur de flux KYC sans code permet aux équipes de conformité de modifier les règles de vérification, d'activer des modules et de réaliser des tests A/B sans déploiement de code.

Par DiditMis à jour le
no-code-kyc-workflow-builder.png

Un constructeur de flux KYC (Know Your Customer) sans code est une interface visuelle permettant de construire, tester et déployer une logique de vérification d'identité sans écrire de code. La distinction clé avec un panneau de configuration : la programmabilité. Le branchement conditionnel, les décisions imbriquées, les tests A/B et l'activation de modules en un clic permettent à une équipe de conformité d'exprimer visuellement l'intégralité de sa politique de risque — et de la modifier sans déploiement de code.

Cette distinction est plus importante qu'il n'y paraît. Les exigences de conformité changent. Les seuils de risque évoluent. Une nouvelle gamme de produits nécessite une portée de vérification différente. Les régulateurs mettent à jour les directives. Selon l'approche conventionnelle, chacun de ces changements est ajouté au carnet de commandes de l'ingénierie et attend un cycle de déploiement. Dans un modèle de flux de travail sans code, le changement est effectué dans une Console, examiné par la conformité et mis en ligne le jour même.

L'Orchestrateur de Flux de Didit est cette couche, et il est gratuit. Il se superpose à l'API unifiée /v3/, que les ingénieurs appellent une seule fois. À partir de ce moment, ce que fait le flux de vérification est une décision de produit et de conformité — et non une décision d'ingénierie.

Points clés à retenir

  • Un constructeur de flux sans code sépare l'intégration de la configuration. Les ingénieurs appellent un point d'API ; la conformité construit et modifie le flux dans la Console sans toucher à l'intégration.
  • Le branchement conditionnel et les décisions imbriquées dirigent les utilisateurs vers différents ensembles de contrôles en fonction du pays, du type de produit, du montant de la transaction ou de tout champ disponible dans le contexte de la session.
  • L'activation de modules en un clic ajoute ou supprime l'un des plus de 25 modules de Didit — document, biométrie, AML, e-mail, IP, téléphone, validation de base de données — d'un flux de travail en quelques secondes.
  • Les tests A/B en production exécutent deux flux sur du trafic réel, mesurent les taux de complétion et de réussite par branche, et promeuvent le gagnant — aucune modification de code n'est requise.
  • Les modifications examinées par la conformité signifient que chaque modification apportée à un flux de travail en direct passe par une étape d'approbation avant d'affecter les utilisateurs réels.
  • L'Orchestrateur de Flux est gratuit. Vous payez par exécution de module, par appel, sans licence d'utilisateur ni frais de plateforme.

Qu'est-ce qu'un constructeur de flux de travail KYC sans code ?

Un flux de travail de vérification est la séquence de contrôles par lesquels un utilisateur passe lors de l'onboarding — ou lors d'un événement d'élévation de privilèges plus tard dans son cycle de vie. Au plus simple : scanner une pièce d'identité, prendre un selfie, faire correspondre le visage au document. Au plus complexe : un arbre de branchement où les utilisateurs de juridictions à haut risque reçoivent un ensemble de modules différent de celui des utilisateurs nationaux, où la taille de la transaction détermine le niveau de détection du vivant à exécuter, et où une biométrie échouée est dirigée vers une file d'attente de révision plutôt qu'un refus catégorique.

Un constructeur sans code exprime cet arbre visuellement. Chaque nœud est une condition ou un module ; chaque arête est une branche. La personne responsable de la politique de conformité — et non l'ingénieur — est propriétaire de la logique. Cette séparation de la propriété est le point clé : la personne qui comprend la politique de risque peut désormais la modifier directement.

Branchement conditionnel et décisions imbriquées

Le constructeur de flux de Didit prend en charge le branchement multi-niveaux. Un seul flux de travail peut contenir :

Routage basé sur le pays. Les résidents de l'UE suivent un chemin ; les résidents d'Amérique latine, où la validation de base de données par rapport aux registres locaux s'applique, suivent un autre. La condition de routage est évaluée lors de la création de la session à partir du contexte de la session.

Routage basé sur le produit. Les comptes de trading nécessitent un document complet plus la détection du vivant ; les comptes d'épargne sont validés avec un e-mail plus une IP. Le même utilisateur, ouvrant un produit différent, entre dans une branche différente — le tout au sein d'un seul flux de travail, d'un seul workflow_id, d'une seule intégration.

Portes de montant de transaction. Le premier dépôt d'un utilisateur en dessous d'un seuil fait l'objet d'un contrôle plus léger ; tout ce qui dépasse déclenche le flux complet. La condition de montant est transmise dans la charge utile de la session et évaluée par le moteur.

Routage en cas d'échec. Une première tentative biométrique échouée est dirigée vers une file d'attente de révision humaine plutôt qu'un refus catégorique. La branche est une condition sur le résultat du module, et non une intégration distincte.

Les conditions s'imbriquent — une condition à l'intérieur d'une condition — de sorte que la carte des politiques peut être aussi granulaire que l'entreprise l'exige. Tout cela est exprimé dans le constructeur visuel, et non dans le code backend.

Activation de modules en un clic

La bibliothèque de modules de Didit couvre l'ensemble du cycle de vie de l'identité et de la fraude : vérification d'identité, lecture NFC, détection du vivant passive, détection du vivant active, correspondance faciale 1:1, recherche faciale 1:N, estimation de l'âge, contrôle AML (Anti-Money-Laundering), surveillance AML continue, vérification d'e-mail, vérification de téléphone, analyse IP, intelligence des appareils, validation de base de données, preuve d'adresse, questionnaires personnalisés, et plus encore.

Dans le constructeur de flux de travail, chaque module apparaît comme une carte. L'ajouter à un flux de travail se fait en un seul clic. Le supprimer se fait en un seul clic. Le module est facturé par utilisation lorsqu'il est exécuté — donc ajouter un module à une seule branche signifie qu'il n'est facturé que pour les utilisateurs qui atteignent cette branche.

Ceci est particulièrement important lorsque les réglementations changent et qu'un nouveau contrôle requis doit être ajouté à tous les flux de travail. Dans une intégration basée sur le code, il s'agit d'une modification du backend, d'une révision, d'un cycle de déploiement. Dans le constructeur de flux de travail, il s'agit d'activer le module sur les flux pertinents dans la Console et de le soumettre pour examen de conformité. La couche d'intégration ne bouge pas.

Tests A/B de flux de travail en production

L'impact sur la conversion des choix de conception de la vérification — document d'abord ou selfie d'abord, trois étapes ou deux, détection du vivant active ou passive — est souvent plus important que prévu et généralement non mesuré. Les tests A/B intégrés de Didit rendent la mesure directe.

Configurez une répartition du trafic (par exemple, 50/50) entre deux variantes de flux de travail. Les deux s'exécutent sur des utilisateurs réels en production. La Console affiche le taux de complétion, le taux de réussite et la distribution des décisions par branche, côte à côte. Lorsque vous êtes sûr du gagnant, promouvez-le à 100 % du trafic — depuis la Console, sans modification de code, avec une révision de conformité avant sa mise en ligne.

Le même mécanisme s'applique aux changements liés à la conformité. Un nouveau contrôle obligatoire à ajouter peut être testé A/B par rapport au flux existant pour mesurer l'impact sur la conversion avant la date de déploiement obligatoire — donnant à l'équipe produit des données plutôt que des hypothèses.

L'API unifiée /v3/ : intégrez une fois, itérez sans fin

L'architecture sous-jacente est ce qui rend cela pratique à grande échelle. Chaque module, chaque branche, chaque version de flux de travail appelle la même surface d'API /v3/. Les ingénieurs appellent POST /v3/session/ avec un workflow_id et redirigent l'utilisateur vers l'URL de la session. Le moteur de flux de travail gère le séquençage des modules, la logique de branchement, la livraison des résultats et l'envoi des webhooks.

Lorsque la conformité modifie le flux de travail, le workflow_id reste le même. Rien côté ingénierie ne change. L'intégration est stable ; la politique est en direct et modifiable.

Cela signifie également que la même intégration prend en charge tous les futurs modules expédiés par Didit. Activation en un clic depuis la Console, facturée à l'utilisation, sans travail de réintégration. De nouveaux modules — validation de base de données pour un nouveau pays, un nouveau niveau de détection du vivant, un nouveau fournisseur AML — apparaissent dans le constructeur et sont immédiatement disponibles pour tout flux de travail.

Parce que l'Orchestrateur de Flux est sur la même API /v3/ que la surveillance des transactions, une session KYC peut être liée à un profil de risque de transaction sur la même référence vendor_data. L'identité établie lors de l'onboarding se transmet directement à la couche de surveillance continue — une seule plateforme, une seule intégration.

Cas d'utilisation

Fintech réglementée lançant de nouveaux produits. Une nouvelle gamme de produits avec un profil de risque client différent nécessite une portée de vérification différente. Créez une nouvelle branche de flux de travail dans la Console ; aucune équipe d'ingénierie requise. Le journal d'audit capture chaque changement avec l'horodatage et l'auteur.

Conformité VASP et échange de crypto. Les obligations de la Règle de voyage du FATF varient selon la juridiction et le type de contrepartie. Un flux de travail avec branchement par pays et par montant applique la bonne politique par catégorie de transaction sans logique backend personnalisée par marché.

Plateformes de marché avec onboarding double face. Les comptes acheteurs et vendeurs ont des profils de risque différents. Deux flux de travail — ou deux branches au sein d'un même — avec des ensembles de modules différents, gérés dans la Console et contrôlés par version dans le journal d'audit. Les ingénieurs ont livré une seule intégration.

Opérateurs de jeux en ligne (iGaming). Les exigences en matière de jeu responsable varient selon la juridiction et le segment d'utilisateurs. Tester A/B la longueur du flux par rapport aux taux de complétion, avec un examen de conformité qui valide chaque changement, est le modèle réglementaire que les régulateurs en Espagne, au Royaume-Uni et à Malte attendent de plus en plus.

Questions fréquemment posées

L'Orchestrateur de Flux est-il vraiment gratuit ?

Oui. L'orchestration, le branchement, les tests A/B et la logique d'activation des modules ne sont pas facturés. Vous payez par exécution de module, par appel, sans licence d'utilisateur ni frais d'abonnement à la plateforme.

Le constructeur sans code remplace-t-il notre intégration backend ?

Non — les ingénieurs appellent toujours POST /v3/session/ depuis votre backend. Le constructeur configure ce que le moteur fait avec cet appel. Il élimine le besoin de réintégrer lorsque la politique change ; il ne supprime pas le point d'intégration.

Comment fonctionnent les modifications examinées par la conformité ?

Chaque modification apportée à un flux de travail en direct dans la Console déclenche une étape d'examen avant que le changement n'affecte les utilisateurs réels. Le journal d'audit capture qui a modifié quoi et quand, ce qui satisfait la plupart des exigences de documentation de gestion des changements réglementaires.

Puis-je combiner le constructeur de flux de travail avec la surveillance des transactions ?

Oui. Une session KYC est liée à un profil de surveillance des transactions via la même référence vendor_data — ainsi l'identité d'onboarding se transmet à la couche de risque transactionnel post-onboarding sans réintégration. Le statut AWAITING_USER dans la surveillance des transactions peut générer une session KYC de remédiation via le même moteur de flux de travail.

Combien de modules puis-je combiner dans un seul flux de travail ?

Il n'y a pas de limite stricte. Les flux de travail peuvent activer n'importe quelle combinaison des plus de 25 modules de Didit, dans n'importe quel ordre, avec n'importe quelle profondeur de branchement requise par la politique.

Prêt à commencer ?

Infrastructure pour l'identité et la fraude.

Une seule API pour le KYC, le KYB, la surveillance des transactions et le screening de portefeuilles. Intégration en 5 minutes.

Demande à une IA de résumer cette page
Constructeur KYC Sans Code : Bâtir sans Ingénierie | Didit.