Quel mode d'intégration Shufti convient le mieux à votre infrastructure ? Explications sur l'API, le SDK et le client Web

D'après le rapport « State of the API 2024 » de Postman, 43 % des développeurs considèrent l'intégration d'API comme leur tâche de développement la plus chronophage. Pour les équipes qui ajoutent la vérification d'identité à un produit réglementé, un mauvais choix d'intégration ne se contente pas de ralentir la livraison ; il crée des failles de conformité coûteuses à corriger ultérieurement.

Shufti propose cinq modes d'intégration distincts, chacun conçu pour répondre à une combinaison spécifique d'exigences techniques, de contraintes de déploiement et de délais de mise en production. Ce guide associe chaque mode au scénario le plus adapté, afin que votre équipe puisse prendre la décision une seule fois et procéder au déploiement.

Pourquoi le binaire du SDK ou de l'API passe-t-il à côté de l'essentiel ?

La plupart des ressources de vérification d'identité destinées aux développeurs présentent le choix d'intégration comme une option binaire : SDK ou API. Cette approche ignore trois autres modes d'intégration qui existent précisément parce que tous les produits ne sont pas des services backend et que toutes les équipes ne disposent pas de plusieurs semaines de développement.

L'architecture d'intégration de Shufti est conçue pour la distribution réelle des produits nécessitant une vérification : applications mobiles natives, parcours d'intégration web, solutions de conformité sans code et déploiements en entreprise avec exigences de souveraineté des données. Chaque mode répond à un besoin spécifique. L'API RESTful n'est pas intrinsèquement supérieure au client web ; elle est plus adaptée à un type d'équipe particulier développant un type de produit spécifique.

Les cinq modes d'intégration de Shufti

1. API RESTful

L'API RESTful de Shufti offre à votre serveur un contrôle total sur le processus de vérification. Votre serveur soumet une requête de vérification, Shufti la traite et les résultats sont renvoyés de manière asynchrone via des webhooks (requêtes HTTP POST transmises à votre point de terminaison une fois la vérification terminée). Ce même point de terminaison d'API couvre tous les produits Shufti : vérification de documents, reconnaissance faciale, filtrage AML, KKB, etc.

Utilisez cette option lorsque vous avez besoin d'une vérification serveur à serveur, d'un traitement par lots ou d'une intégration étroite avec votre couche d'orchestration existante. Les ingénieurs backend des fintechs et des sociétés de services financiers privilégient généralement cette solution lorsque la logique de vérification doit être gérée au sein de leur propre système de gestion du cycle de vie utilisateur plutôt que côté client. La complexité technique est la plus élevée des cinq options, mais le niveau de contrôle l'est également. Plus de 83 % des charges de travail d'entreprise s'appuient sur des API pour la communication et l'automatisation des données.et l'API de Shufti est conçue pour s'intégrer à cette infrastructure dès le premier jour.

2. Kits de développement logiciel mobiles

Kits de développement logiciel (SDK) mobiles de Shufti Ces applications sont disponibles pour Android, iOS, Flutter, React Native et Cordova. Elles gèrent la capture de documents, la détection de présence et la biométrie faciale directement sur l'appareil, puis transmettent les résultats traités au système de vérification de Shufti.

Utilisez cette méthode lorsque vous développez une application mobile native et que la qualité de la capture biométrique est primordiale. Les SDK mobiles accèdent directement au pipeline de la caméra de l'appareil, ce qui leur permet de détecter les injections de données et les attaques par présentation à un niveau que les canaux basés sur un navigateur ne peuvent égaler. Ceci est conforme aux principes d'assurance de l'authentificateur. NIST SP 800-63BCes technologies reconnaissent l'accès natif au périphérique comme le canal le plus fiable pour la vérification biométrique. Le SDK gère l'interface utilisateur de capture ; votre application gère le déroulement de la session.

3. Client Web (Page de vérification personnalisée / iFrame)

Le client Web hébergé de Shufti est un flux de vérification préconfiguré que vous intégrez dans une session de navigateur via iFrame. Shufti Ce service gère l'interface utilisateur, la capture des documents et des données biométriques, ainsi que la transmission des résultats. Vous recevez une notification webhook une fois le contrôle terminé, sans avoir à créer ni à maintenir vous-même l'interface de vérification.

Utilisez cette option lorsque vous avez besoin d'un parcours d'intégration web et souhaitez éviter de créer et de maintenir une interface utilisateur de vérification. C'est généralement la solution la plus rapide pour les produits web : l'intégration prend quelques jours au lieu de plusieurs semaines et les obligations de gestion des données sont réduites. Article 32 du RGPD La gestion est assurée par Shufti et aucune compilation du SDK mobile n'est requise. La complexité technique est faible à moyenne.

4. Créateur de parcours

Constructeur de voyage Shufti est un configurateur de flux de vérification sans code. Les équipes de conformité et les responsables des opérations peuvent ainsi créer des flux de vérification en plusieurs étapes (vérification de documents, reconnaissance faciale, filtrage AML, vérification d'adresse) grâce à une interface visuelle, sans écrire une seule ligne de code.

Utilisez cette solution lorsque vous devez déployer ou itérer rapidement sur un flux de vérification et que la contrainte réside dans la capacité d'ingénierie, et non dans la faisabilité technique. Elle convient également aux équipes ayant besoin de plusieurs flux spécifiques à un marché : différents pays, différents types de documents, différentes listes de surveillance AML, tous configurables indépendamment. Bibliothèque Journey Builder Inclut des flux préconfigurés couvrant plus de 30 marchés. Délai de mise en service : de quelques heures à une journée pour un premier déploiement.

5. Sur site

Le déploiement sur site de Shufti exécute l'intégralité de la pile de vérification au sein de votre infrastructure. Aucune donnée de vérification ne quitte votre environnement. L'interface API RESTful reste inchangée et vous conservez un contrôle total sur la couche de calcul, la localisation des données et l'historique d'audit.

Utilisez cette option lorsque la souveraineté des données est impérative. Les banques et institutions financières opérant dans des juridictions imposant des règles strictes de résidence des données, ou les entreprises soumises à des cadres sectoriels limitant les transferts de données vers le cloud, privilégient cette solution. Le délai de mise en service est le plus long des cinq modes, mais le niveau de sécurité est également le plus élevé : l’exposition des données vers le cloud est totalement éliminée.

Choisir le bon mode : un cadre pratique

Deux questions permettent de restreindre rapidement le choix.

• Tout d'abord, où votre produit est-il hébergé ? Les applications mobiles natives utilisent le kit de développement logiciel mobile (SDK). Les produits web utilisent par défaut le client web ou l'API REST. Les équipes disposant de peu de temps en développement commencent par l'outil de création de parcours client (Journal Builder). Les entreprises soumises à des réglementations et à des exigences de résidence des données doivent utiliser une solution sur site.
• Deuxièmement, de combien de temps d'ingénierie disposez-vous ? Si le délai est exprimé en heures, Journey Builder est l'option réaliste. Quelques jours à une semaine : client web ou API. Une à deux semaines : API ou kit de développement logiciel mobile. Déploiement en entreprise à grande échelle : sur site.

Les équipes qui intègrent la procédure KYC à un produit financier commencent souvent par le client Web pour une mise en service conforme et rapide, puis migrent vers l'API une fois le flux de travail principal validé. Un guide plus complet sur la planification de ce cycle de vie est disponible dans [référence manquante]. Intégration KYC Stratégies pour une intégration fluide et conforme à la réglementation.

Utilisation simultanée de plusieurs modes

L'utilisation de plusieurs modes d'intégration Shufti au sein d'un même produit est courante et prévue par l'architecture du produit. Une application de services financiers peut ainsi exécuter le client Web pour l'accueil des utilisateurs via navigateur, le SDK mobile au sein de son application native et l'API REST pour le contrôle anti-blanchiment d'argent en arrière-plan. Ces trois éléments se connectent à la même plateforme, au même tableau de bord et aux mêmes données de conformité. Pour une analyse plus approfondie du fonctionnement de la couche API dans un contexte plus large, consultez la documentation. services de vérification d'identité pile, voir API KYC: Définition, fonctionnement, intégration et cas d'utilisation.