Une démo n’a qu’un seul chemin heureux. La production a des documents expirés, un mauvais éclairage, un pays que vous n’aviez pas prévu, et un conseiller au téléphone avec un client qui attend une réponse maintenant.
Ce qu’une API de vérification d’identité doit renvoyer
Une API de vérification d’identité reçoit un document, un visage ou un nom et en renvoie une évaluation. Le plus difficile n’est pas l’appel. C’est ce qui revient : une réponse assez détaillée pour que vos propres règles puissent agir, assez traçable pour qu’un auditeur puisse la suivre, et assez rapide pour que le client soit encore là quand elle arrive.
L’intégration est pensée autour de cet écart, et non autour de la démo.
Une seule API, pas une deuxième intégration
La vérification documentaire, la biométrie et le renseignement en sources ouvertes partagent la même URL de base, le même jeton et la même forme de JSON. Ajouter une capacité, c’est appeler un autre groupe de points d’entrée, pas démarrer un nouveau projet.
- REST sur HTTPS, avec la même authentification partout.
- Réponses synchrones pour les contrôles rapides, rappels pour les autres.
- Chaque réponse porte l’identifiant qui permettra de la retrouver dans la trace d’audit.
Cela tourne là où tournent déjà vos systèmes
Thin clients, bureaux virtuels et systèmes core sur mesure sont le cas normal, pas l’exception. Le déploiement est conçu pour se placer à côté de l’existant plutôt que de vous demander de le remplacer.
Si le flux exige du matériel neuf à chaque guichet, ce n’est pas une intégration. C’est une migration déguisée.
Le rapport est le contrat
Ce qui revient n’est pas un booléen. C’est le résultat, la confiance, les contrôles qui ont tourné et ceux qui n’ont pas pu, pour que vos propres règles décident de ce qu’un cas limite signifie au regard de votre appétence au risque.
Deux établissements lisant le même rapport traceront raisonnablement des limites différentes. Le rapport existe pour le leur permettre, au lieu de cacher la décision dans notre seuil.
Ce que nous attendons de vous
Un environnement de test, la liste des types de documents et des pays que vous voyez réellement, et quelqu’un capable de dire ce que font vos équipes aujourd’hui quand un contrôle revient incertain. Ce dernier point façonne l’intégration plus que n’importe quel choix technique.
Concevoir pour le cas incertain
Chaque verdict est accepter ou escalader. Les cas acceptés sont simples à brancher : le parcours continue. Les cas escaladés sont ceux où les intégrations réussissent ou échouent, parce qu’ils ont besoin d’un endroit où arriver, d’une personne pour les lire et de la trace complète de ce qui a tourné, rattachée au dossier plutôt que perdue dans un journal.
Les meilleures intégrations fixent ce chemin avant la première ligne de code : qui voit une escalade, en combien de temps, et ce qu’il est autorisé à décider. L’API leur donne la matière ; le flux leur appartient.
Ce qui change au guichet
La mesure d’une bonne intégration n’est pas l’appel d’API. C’est le service de l’agent. Un contrôle qui prenait 3 à 5 minutes à un agent formé revient en moins de 7 secondes, sans rien à saisir, et l’attention de l’agent retourne au client qui est en face de lui.
- Une URL de base et un jeton pour les documents, la biométrie et le renseignement en sources ouvertes.
- Un résultat, une confiance et la liste des contrôles, jamais un simple oui ou non.
- Un identifiant sur chaque réponse qui mène à la trace d’audit.
- Un déploiement à côté de vos systèmes existants, pas à leur place.
Les questions des équipes avant l’intégration
Documents, biométrie et OSINT demandent-ils des intégrations séparées ?
Non. Ils partagent une URL de base, un jeton et une forme de JSON. Ajouter une capacité, c’est appeler un autre groupe de points d’entrée sur l’intégration que vous avez déjà.
Les réponses sont-elles synchrones ?
Les contrôles rapides répondent de façon synchrone. Les plus longs répondent par un rappel, pour que votre système ne garde pas une connexion ouverte pendant qu’ils tournent.
Cela fonctionne-t-il avec des thin clients et des bureaux virtuels ?
Oui. Le déploiement est conçu pour se placer à côté des systèmes existants, y compris les thin clients, les bureaux virtuels et les systèmes core sur mesure, plutôt que de les remplacer.
Que devons-nous préparer ?
Un environnement de test, la liste des types de documents et des pays que vous voyez réellement, et un responsable clair pour les cas escaladés : qui les lit, en combien de temps, et ce qu’il est autorisé à décider.