Commencez l'aventure
Votre application web, mobile ou de back-office permet de créer et de reprendre la demande KYC.
Une intégration solide de l'API KYC transforme les politiques de conformité en résultats prévisibles. Elle relie votre produit aux fournisseurs de données, à la vérification d'identité, au filtrage des sanctions et des personnes politiquement exposées (PEP), à la veille médiatique négative et à la prise de décision en matière de risques, afin que les inscriptions, la surveillance et les mesures correctives s'effectuent à la vitesse de la production. L'objectif est une fiabilité sur laquelle vous pouvez compter : des contrats prévisibles, des appels idempotents, des webhooks signés, des modèles d'événements épurés et des SLA qui tiennent la route même sous charge. Cette page présente des modèles pratiques pour connecter Ondorse, notamment les charges utiles, les tentatives de reconnexion, l'observabilité, la gestion des versions de sécurité et les stratégies de test qui résistent au trafic réel.

Une intégration moderne ne se résume pas à un simple point de terminaison. Il s'agit d'un ensemble de contrats, de données utiles et d'événements liés au cycle de vie sur lesquels le reste de votre plateforme peut s'appuyer pour chaque inscription et chaque dossier.
Les éléments ci-dessous décrivent ce que les équipes mettent en place dès le premier jour et maintiennent au fur et à mesure de leur expansion.
API de vérification d'identité intégrant des contrôles des documents d'identité, des selfies et des justificatifs de domicile, harmonisés entre les différents prestataires.
API de données sur les entreprises avec recherche dans les registres, identification des bénéficiaires effectifs et couverture des listes de surveillance.
Filtrage des sanctions, des personnes politiquement exposées (PPE) et des informations médiatiques négatives, avec des correspondances explicables et des seuils configurables.
Une API d'évaluation des risques qui transforme les signaux en décisions et en codes de justification pouvant faire l'objet d'un audit.
Des webhooks et des modèles d'événements permettant d'assurer la synchronisation entre case management, l'analyse des données et les services en aval.
.webp)
.webp)
Des contrats stables permettent d'éviter les ruptures et rendent les audits prévisibles. Il faut raisonner en termes de ressources, d'états et de transitions plutôt qu'en termes de points de terminaison ponctuels.
Modélisez une ressource d'application qui gère des sous-ressources telles que les vérifications de documents, les données biométriques et les contrôles de sécurité. Chaque sous-ressource passe par différents états, tels que « créé », « en attente », « terminé » ou « échoué ». Exposez les changements d'état sous forme d'événements afin que les utilisateurs n'aient pas besoin d'effectuer de requêtes de vérification.
Les intégrations échouent lorsque les données utiles varient. La normalisation garantit la portabilité de la logique en aval d'un fournisseur à l'autre.
Champs standard portant des noms cohérents, tels que nom, date_de_naissance, adresse, nationalité, type_de_document.
Des résultats structurés qui distinguent clairement les résultats, les notes et les justifications, au lieu de les mélanger dans le texte.
Références de preuves contenant les URL ou les identifiants des images, du texte issu de la reconnaissance optique de caractères (OCR) et des correspondances de filtrage.
Horodatages et identifiants pour chaque appel, ainsi que votre propre clé d'idempotence, spécifique à chaque opération et à chaque ressource.
Bonnes pratiques Unicode : normaliser en NFC, enregistrer les formes brutes et normalisées des noms et adresses afin d'éviter les fausses correspondances.
Certaines vérifications s'effectuent rapidement, tandis que d'autres prennent plus de temps. En combinant des étapes synchrones et des mises à jour asynchrones, on garantit une expérience utilisateur fluide sans compromettre la fiabilité.
Maintenez l'utilisateur dans le flux pour les étapes courtes, telles que la validation de base des documents. Passez à des mises à jour via webhooks pour les vérifications approfondies ou les examens manuels. Renvoyez toujours un `application_id` stable afin que le client puisse effectuer des requêtes de vérification si les webhooks accusent un retard.
Les réseaux tombent en panne et les fournisseurs connaissent parfois des ratés. Une intégration fiable de l'API KYC considère ces incidents comme tout à fait normaux.
Le client effectue de nouvelles tentatives en utilisant un délai d'attente exponentiel et une variation de temps d'attente, uniquement pour garantir la sécurité des opérations.
Utilisez des clés idempotentes pour les appels POST de création afin d'éviter que les nouvelles soumissions ne dupliquent le travail. Enregistrez les clés avec un délai d'expiration (TTL) adapté au nombre de tentatives de l'utilisateur.
Des délais d'expiration adaptés à chaque type d'appel et des itinéraires de secours au niveau de la couche d'orchestration.
Une taxonomie des erreurs qui distingue les erreurs des utilisateurs des incidents passagers liés aux fournisseurs et des limites de débit.
Les webhooks permettent de réduire les requêtes de vérification et d'harmoniser le travail des équipes, mais seulement si les événements sont clairs et sécurisés.
Émettez des événements de domaine tels que `application.created`, `document.updated`, `identity_verification.updated` et `application.status_updated`. Signez les charges utiles à l'aide d'une clé secrète HMAC dans un en-tête dédié, incluez un `event_id` croissant de manière monotone, un horodatage, et autorisez la relecture sécurisée. Les destinataires doivent enregistrer les événements dans un stockage durable avant de les traiter afin d'éviter toute perte.
Les données d'identité sont sensibles. La sécurité n'est pas un simple ajout, elle fait partie intégrante du contrat.
TLS partout et chiffrement au repos avec rotation gérée des clés.
Contrôle d'accès basé sur les rôles, authentification unique (SSO) et autorisations au niveau des champs pour les attributs sensibles.
Réduction des données et conservation de courte durée, avec des procédures de suppression explicites conformes à la réglementation.
Jeton API à portée limitée, listes d'adresses IP autorisées et rotation des secrets pour les clés de signature des webhooks.
Séparation des données à caractère personnel afin que les outils d'analyse reçoivent des jetons ou des hachages plutôt que des données brutes.
Un bon environnement de test vaut mieux que mille simulations. Testez avec des échantillons réalistes, des connexions lentes et des données d'entrée aléatoires.
Ne vous contentez pas des scénarios optimistes. Vérifiez le comportement du système en situation de stress et d'ambiguïté.
Répertorier les cas limites, tels que les reflets, le flou, les recadrages partiels et les pièces d'identité périmées.
Variations biométriques liées aux changements d'éclairage, aux accessoires et aux appareils photo bas de gamme.
Filtrage des correspondances comprenant les vrais positifs, les faux positifs et les collisions partielles de noms.
Problèmes de réseau tels que les délais d'expiration, les tentatives de reconnexion, les retards des webhooks et les événements hors séquence.
Prise en charge des paramètres régionaux pour les scripts non latins, les formats d'adresse et les encodages.
On ne peut pas améliorer ce qu'on ne voit pas. Mettez en place des outils dès le premier jour et convenez de SLA qui reflètent les besoins de l'entreprise.
Suivez un petit ensemble d'indicateurs et configurez des alertes permettant aux utilisateurs d'intervenir.
Taux de réussite et taux d'abandon par étape, par pays et par type d'appareil.
Latence par fournisseur et par type de vérification, avec les valeurs p50, p95 et p99.
Marges d'erreur et nombre d'incidents par dépendance.
État des webhooks, notamment le succès de la transmission, les délais et le taux de relecture.
Les charges utiles des fournisseurs évoluent. Sans gestion des versions, chaque mise à jour se transforme en véritable casse-tête.
Utilisez des versions d'API explicites dans les URL ou les en-têtes. Procédez à une mise hors service progressive en utilisant des fenêtres de lecture et d'écriture parallèles. Tenez à jour un journal des modifications accessible à tous et informez les utilisateurs à l'avance. Pour les modifications à risque, mettez en place des indicateurs de fonctionnalité et un trafic parallèle avant la bascule. Ondorse privilégie l'approche « policy as code » et les règles versionnées afin que les mises à jour à risque ne nécessitent pas la publication d'une nouvelle version de l'application.
L'intégration de l'API KYC se situe à la croisée des domaines des produits, des risques et des données. L'objectif est d'éliminer les angles morts, et non de créer de nouveaux silos.
Un processus KYC en amont qui ne demande que les informations nécessaires à chaque segment.
Orchestration du processus KYC pour acheminer les demandes en fonction du pays, du niveau de risque lié à l'appareil ou du volume de demandes en attente, et pour définir des solutions de repli.
Une évaluation des risques clients qui transforme les données brutes en scores et en parcours.
case management relatifs à la lutte contre le blanchiment d'argent case management enquêtes, avec vérification des preuves et des auteurs.
Entrepôt de données et outils de BI pour analyser le taux d'acceptation, les faux positifs et la rentabilité unitaire.
Un bref scénario illustre comment les différents éléments s'articulent en production. Un fournisseur IDV expire pour une tranche d'appareil spécifique. Votre client effectue une nouvelle tentative avec un délai d'attente, puis votre orchestration bascule vers une solution de secours. Les deux tentatives sont enregistrées avec la même clé d'idempotence. Un webhook arrive en retard mais est vérifié par sa signature et son horodatage, puis dédupliqué en toute sécurité par l'event_id. La décision est enregistrée avec des codes de motif et des liens vers les preuves. Lorsqu'un auditeur vous le demande trois mois plus tard, vous récupérez la chaîne exacte en quelques minutes.
Les déploiements en une seule fois augmentent les risques. Une approche progressive fait ses preuves et permet de maintenir la prévisibilité des audits.
Commencez par un cadre restreint et développez votre argumentation en vous appuyant sur des faits, et non sur des espoirs.
Définir les segments de risque et les contrôles requis pour chacun d'entre eux, y compris les pièces justificatives à conserver.
Définissez dès le départ les charges utiles et les noms d'événements dans un référentiel de schémas partagé.
Intégrez un fournisseur par type de vérification, définissez les délais d'expiration, les tentatives de réessai et les règles d'idempotence.
Configurez des webhooks avec des charges utiles signées, des vérifications d'horodatage et une relecture sécurisée.
Indicateurs et alertes des outils. Expédiez vers un marché, comparez le taux de réussite, la latence et le coût.
Procédez à un déploiement progressif et tenez à jour un journal des modifications, en y indiquant les justifications et les résultats.
Mise à jour d'octobre 2025 : révisé par un ingénieur chargé de la conformité et mis en conformité avec les recommandations publiques du GAFI et des autorités de surveillance européennes.
Si vous envisagez d'intégrer une API KYC, commencez par définir un modèle de contrats et d'événements sur lequel votre plateforme peut s'appuyer. Choisissez un partenaire qui garantit l'idempotence, des webhooks signés, des tentatives de reconnexion prévisibles et un système de gestion des versions clair. Ondorse fournit ces éléments de base, ainsi que des fonctionnalités d'orchestration et case management les équipes puissent passer du pilote à la production en toute confiance.
Les équipes nous demandent souvent comment maintenir un taux de conversion élevé, comment choisir entre les SDK et les API directes, ou comment gérer les incidents. Les réponses ci-dessous abordent ces points courants sans tourner autour du pot.
Les SDK accélèrent la mise en service et améliorent la qualité de la capture sur mobile. Les API directes offrent un contrôle maximal, mais nécessitent davantage de travail d'ingénierie et d'assurance qualité. De nombreuses équipes commencent par utiliser des SDK, puis intègrent la capture directe lorsque la personnalisation s'avère indispensable.
Mettez en place onboarding fondée sur les risques. Privilégiez des parcours simplifiés pour les segments sans problème et ne passez à un niveau supérieur que lorsque les signaux le justifient. Évaluez les taux d'abandon à chaque étape et éliminez les obstacles qui n'ont pas d'incidence sur les résultats.
Votre couche d'orchestration doit basculer vers un fournisseur de secours ou mettre les tâches en file d'attente jusqu'à la reprise du service. Signalez les taux de délai d'expiration et renvoyez un statut « OK » afin que les utilisateurs ne restent pas dans l'attente.
Reliez les étapes onboarding, de vérification, de filtrage et de prise de décision à l'aide de ressources stables et d'états prévisibles. Prévoyez dès la première version la gestion des nouvelles tentatives, des résultats différés et des incidents liés aux fournisseurs.
Vous avez besoin d'un routage multi-opérateurs ? Découvrez l'orchestration KYC.
POST /v1/applications
Idempotency-Key: app_01J8...
{
"external_id": "customer_84721",
"workflow": "business_onboarding",
"country": "FR",
"redirect_url": "https://app.example.com/return"
}
202 Accepted
{ "id": "app_84721", "status": "pending" }
Illustrative contract. Confirm against Ondorse docs.Une intégration d'API KYC relie un produit et ses systèmes internes aux processus de vérification des clients, de filtrage anti-blanchiment, de prise de décision en matière de risques et aux résultats des contrôles, par le biais de ressources, de requêtes et d'événements du cycle de vie prédéfinis.
L'intégration ne se limite pas à un simple appel de vérification. Elle doit coordonner les données client, les vérifications de longue durée, les webhooks, les justificatifs, les erreurs, l'état visible par l'utilisateur et les événements de surveillance ultérieurs, sans créer de doublons d'applications ni entraîner de décisions incohérentes.
L'API constitue l'interface de connexion. L'orchestration KYC gère l'exécution des prestataires en arrière-plan de cette interface, tandis que le workflow KYC définit les étapes métier et les résultats attendus.
Considérez l'intégration comme un petit système distribué. Chaque composant doit avoir un responsable clairement identifié et un comportement défini en cas de défaillance.
Votre application web, mobile ou de back-office permet de créer et de reprendre la demande KYC.
Les points de terminaison stables valident les données et renvoient les identifiants des ressources ainsi que leur état.
Les couches de workflow et d'orchestration coordonnent la vérification et le filtrage.
Les événements signés permettent de communiquer les mises à jour relatives aux vérifications, aux cas et aux décisions.
Les systèmes liés aux produits, à la gestion de la relation client (CRM), aux données et aux opérations réagissent aux états finalisés.
Une ressource applicative centrale fournit aux systèmes en aval un identifiant unique et stable pour le parcours client et les vérifications associées.
Les noms indiqués ici sont donnés à titre d'exemple. La page finale doit utiliser exactement les ressources et les champs figurant dans la référence actuelle de l'API Ondorse.
demandeGère le contexte client, le choix du workflow, l'état d'avancement global et la décision finale.
fêteDésigne la personne, la société, le représentant ou le bénéficiaire effectif faisant l'objet du contrôle.
vérifierPermet de suivre une vérification, un contrôle, une inscription dans un registre ou toute autre tâche, ainsi que son résultat.
casDésigne une exception nécessitant des preuves, une attribution ou un jugement humain.
preuveFait référence aux documents, résultats sources ou livrables associés à un résultat.
événementSignale un changement irréversible du cycle de vie aux destinataires autorisés.
Les clients doivent faire la distinction entre un travail en cours, une action du client, une vérification humaine, l'achèvement d'une tâche et une défaillance technique.
crééLa ressource existe, mais son exécution n'a pas encore commencé.
en attenteUne vérification ou une action de workflow est toujours en cours.
action_requiredLe client ou un opérateur doit fournir des informations.
avis_obligatoireLe résultat nécessite un jugement humain avisé.
terminéLa ressource a atteint un état final positif.
Les défaillances techniques ne doivent pas être présentées comme des risques pour les clients. La taxonomie finale doit correspondre à l'API Ondorse telle qu'elle existe réellement.
Veillez à ce que les réponses synchrones soient courtes et prévisibles. Utilisez les événements pour les tâches dont la durée dépend des fournisseurs, des actions du client ou d'un examen.
Utile lorsque l'API est capable de valider et de créer une ressource dans un délai de requête défini.
Utile pour la vérification des documents, la présélection, les appels aux prestataires et les décisions d'examen qui pourraient être finalisées ultérieurement.
Les tentatives répétées et les aléas du réseau sont normaux. L'intégration doit produire le même résultat logique lorsqu'une requête ou un événement « safe » est transmis plusieurs fois.
Associer une clé générée par le client à l'opération et à la ressource pendant une durée de conservation appropriée.
Clé d'idempotenceUtilisez des délais d'expiration adaptés au point de terminaison et évitez de laisser un client dans un état indéfini.
202 AcceptéN'utilisez le recul exponentiel et la gigue que lorsque le fonctionnement et la classification des erreurs le permettent.
Retry-AfterEnregistrer les identifiants d'événements avant d'appliquer les modifications en aval et prendre en charge la réexécution.
event_idLes événements doivent décrire les modifications apportées au domaine, en indiquant des identifiants stables, des horodatages et des versions.
Signer les charges utiles, documenter le comportement en cas de nouvelle tentative, prendre en charge la relecture sécurisée et fournir aux utilisateurs suffisamment d'informations pour récupérer la ressource faisant autorité.
application.createdUne nouvelle ressource d'application est disponible.
identity_verification.mis à jourUne vérification d'identité a abouti à un nouveau résultat.
collect.openedUn dossier a été ouvert afin de recueillir des éléments de preuve supplémentaires auprès des clients.
avis.publiéUn dossier a été ouvert et doit faire l'objet d'un examen par une personne habilitée.
application.status_updatedLe statut de la demande a changé à la suite d'une décision réglementaire.
Les noms des événements sont donnés à titre indicatif et doivent être remplacés par ceux figurant exactement dans le catalogue actuel des événements d'Ondorse.
Les erreurs doivent indiquer à l'appelant s'il doit corriger la saisie, récupérer une ressource existante, patienter, réessayer en toute sécurité ou s'arrêter.
Un champ, un format ou une condition préalable métier n'est pas valide.
L'authentification ou l'autorisation ne permet pas d'effectuer cette opération.
L'opération est incompatible avec l'état actuel de la ressource ou avec l'idempotence.
Des contraintes liées à la capacité, à la dépendance ou aux conditions de service ont empêché la réalisation du projet.
Les contrôles précis d'Ondorse doivent être vérifiés à l'aide de sa documentation, de sa page consacrée à la sécurité et de l'analyse de sécurité effectuée par le client.
Utilisez des environnements distincts, appliquez le principe du « privilège minimal » et mettez en place un processus de rotation explicite.
Vérifiez la signature et l'horodatage avant d'accepter un événement, puis protégez-vous contre les attaques par rejeu.
N'envoyer et ne conserver que les informations requises par le cas d'utilisation, la politique et les exigences applicables.
Ne divulguez pas d'identifiants privilégiés ni de secrets de signature dans les navigateurs et les clients mobiles.
Utilisez des droits d'accès à durée limitée et des autorisations adaptées aux documents et résultats sensibles.
Utilisez des identifiants et le masquage des données afin que les journaux opérationnels restent utiles sans devenir une base de données fantôme.
La disponibilité de l'API ne permet pas à elle seule de détecter les retards dans la prise de décision, les webhooks défaillants ou les clients bloqués dans un état non résolu.
Débit, latence et état par terminal.
Remise, retard, tentatives de réexpédition et messages non remis.
Les ressources sont en attente depuis plus longtemps que prévu.
Délais d'attente des fournisseurs et activité de secours.
Achèvement, action requise et remise.
Un environnement de test utile doit couvrir les résultats déterministes, mais les tests d'intégration doivent également simuler les problèmes de synchronisation, les doublons et les défaillances partielles.
Champs obligatoires, champs facultatifs, listes énumérées, transitions de statut et gestion des versions.
Vérifiez que les tentatives de reconnexion au réseau n'entraînent pas la création de doublons au niveau des demandes ou des vérifications.
Vérification des signatures, réexpédition, déduplication et traitement des messages hors séquence.
Vérifiez les limites de tentatives, le statut des clients et les alertes opérationnelles.
Noms, adresses, scripts, types de documents et structures d'entreprise.
Veillez à ce que le client puisse restaurer l'état sans avoir à relancer les tâches déjà terminées.
Valider un parcours client et ses modes de défaillance avant de relier tous les produits, tous les marchés et tous les consommateurs en aval.
Identifier les commandes, les ressources, les états, les événements et les responsables.
Convenir des charges utiles, des identifiants, des erreurs et de la politique relative aux versions.
Créer une application, traiter les événements et récupérer les résultats.
Simulation de nouvelles tentatives, de doublons, de retards et de trajets interrompus.
Limiter le trafic dans un premier temps, puis l'étendre après validation opérationnelle.
Cette page traite de l'intégration technique. Les pages associées abordent la conception des processus, le routage en temps réel et les capacités de vérification spécifiques.
Présentez-nous votre parcours actuel, votre modèle de données et vos systèmes en aval. Ondorse peut vous aider à identifier les ressources, les événements et les comportements en cas de défaillance nécessaires à une mise en œuvre fiable.