Vérifier l'identité d'un utilisateur avec Claude : un guide pratique (FR)

Points clés à retenir

• Ceci est un guide de l'opérateur : les mots exacts à taper dans Claude, ce que le demandeur expérimente, comment lire la réponse et quoi faire lorsqu'une session nécessite une révision.
• Le connecteur Model Context Protocol (MCP) de Didit permet à un opérateur connecté d'utiliser les flux de travail et les autorisations existants depuis le chat sans écrire de code.
• Un flux de travail contrôle les vérifications Know Your Customer (KYC) qui sont exécutées. La liste des flux de travail trouve les choix ; la lecture du flux de travail sélectionné révèle sa configuration.
• Le demandeur effectue les vérifications configurées sur une page hébergée par Didit. Claude récupère et explique le résultat de Didit ; il n'inspecte pas lui-même le document ou le visage de la personne.
• En révision est un transfert pour un jugement humain, pas un autre mot pour Refusé. Demandez à Claude de séparer les preuves retournées des informations manquantes avant que quiconque ne modifie le statut.

Vous n'avez pas besoin de connaître un schéma d'interface de programmation d'application (API) pour aider un demandeur à travers la vérification d'identité. Vous avez besoin d'un compte Didit, d'un flux de travail de vérification approuvé, du connecteur Didit activé dans Claude et de l'autorité en vertu de la politique de révision de votre organisation. Le reste peut se faire en langage courant.

Ce guide concerne délibérément la personne qui gère la conversation. Il ne répète pas les mécanismes de création de lien et de sondage déjà couverts dans MCP pour KYC et le guide du serveur KYC MCP. Gardez ces références ouvertes lorsque vous avez besoin de détails sur le cycle de vie ou l'intégration. Utilisez cette page lorsque la question pratique est : « Que dois-je taper, que dois-je dire au demandeur et que dois-je faire de la réponse ? »

Avant le demandeur : établir le bon espace de travail

Ajoutez le connecteur Didit à Claude et terminez la connexion Didit. Le point de terminaison hébergé utilise OAuth (Open Authorization) 2.1 avec PKCE (Proof Key for Code Exchange), pas une clé API. Claude agit avec le rôle Didit de l'utilisateur connecté, de sorte que l'opérateur doit déjà avoir l'autorisation pour toute action qu'il demande.

Commencez chaque nouvelle conversation d'exploitation en rendant la portée visible :

Utilisez Didit pour m'aider à vérifier un demandeur. Appelez d'abord didit_context_get. Dites-moi quelle organisation et application sont sélectionnées. Ne créez ni ne modifiez rien pour l'instant.

Cela permet de détecter l'erreur opérationnelle la plus simple : travailler dans la mauvaise application lorsqu'une personne peut en consulter plusieurs. Si Claude affiche plusieurs options, nommez l'organisation et l'application que vous comptez utiliser avant de continuer.

Choisissez un flux de travail sans deviner ses vérifications

didit_workflow_list liste les flux de travail disponibles. Il ne renvoie pas le graphe ou la configuration complète du flux de travail. Utilisez-le pour trouver le nom du flux de travail approuvé et le workflow_id, puis récupérez explicitement le flux de travail sélectionné.

Listez les flux de travail de vérification dans l'application sélectionnée avec didit_workflow_list. Affichez uniquement le nom, le workflow_id et le statut de chaque flux de travail. Ne décrivez pas encore ses vérifications.

Après en avoir sélectionné un, demandez la configuration réelle :

Récupérez le flux de travail WORKFLOW_UUID avec didit_workflow_get. Si ses étapes ou branches nécessitent des détails de graphe, appelez également didit_workflow_get_graph avec include_config: false. Ensuite, expliquez, en langage clair, ce que le demandeur doit faire. Séparez les étapes visibles par le demandeur des vérifications qui s'exécutent en arrière-plan. Ne créez pas de session.

Utilisez didit_workflow_get pour la configuration complète du flux de travail sélectionné. Utilisez didit_workflow_get_graph lorsque vous avez besoin de ses nœuds, branches, conditions ou étapes de traitement de documents ; sa configuration résumée par défaut est suffisante pour une explication de l'opérateur. Ce modèle en deux étapes empêche Claude d'inférer un ensemble simplement à partir d'une étiquette de flux de travail.

Demandez un lien de demandeur unique

Une fois que vous avez confirmé l'espace de travail et le flux de travail, l'instruction de l'opérateur peut rester courte :

Créez une session avec didit_session_create en utilisant workflow_id WORKFLOW_UUID et vendor_data customer-8421. Retournez le session_id et l'url. N'envoyez pas le lien et ne modifiez aucun autre enregistrement.

La seule entrée requise pour didit_session_create est workflow_id ; vendor_data est une référence client optionnelle. La réponse inclut une url. Copiez ce lien hébergé dans votre canal approuvé d'e-mail, de support ou d'intégration. La création de la session ne signifie pas en soi que le demandeur a été contacté.

C'est tout le mécanisme dont ce guide de l'opérateur a besoin. Si vous implémentez la livraison automatisée, les rappels, les webhooks ou le sondage, utilisez les guides techniques liés plutôt que de transformer une conversation d'opérateur en un tutoriel d'intégration.

Dites au demandeur ce qui va se passer

Le demandeur ouvre une page hébergée par Didit dans son navigateur ; il n'a pas besoin de Claude ou d'une connexion MCP. L'expérience exacte suit le flux de travail sélectionné. Un ensemble KYC complet configuré peut inclure la capture de documents d'identité, la vivacité passive, une correspondance faciale un à un et l'analyse d'adresse IP (Internet Protocol). Un flux de travail différent peut contenir moins de vérifications, des vérifications supplémentaires ou des branches conditionnelles.

Demandez à Claude de rédiger un message basé uniquement sur la configuration récupérée :

Rédigez un message en quatre points pour le demandeur expliquant ce qu'il verra après avoir ouvert l'URL. Utilisez uniquement la configuration du flux de travail sélectionné. Mentionnez toute préparation de document ou d'appareil réellement requise. Ne promettez pas d'approbation, de délai d'exécution ou de vérifications non configurées.

Un bon message de l'opérateur explique pourquoi la personne a reçu le lien, les étapes visibles qu'elle devra suivre et où demander de l'aide. Il ne doit pas exposer le jeton de session interne, copier des données personnelles dans le chat ou décrire une vérification en arrière-plan comme une action du demandeur.

Didit prend en charge plus de 220 pays et territoires, plus de 14 000 types de documents et plus de 48 langues. Ces chiffres de couverture décrivent la plateforme ; le flux de travail sélectionné et le document du demandeur déterminent toujours les écrans réels disponibles dans cette session.

Demandez un résultat en langage clair

Lorsque le demandeur dit qu'il a terminé, ne demandez pas à Claude s'il a « réussi ». Demandez-lui de récupérer la décision enregistrée et de séparer le statut des preuves :

Appelez didit_session_get_decision pour la session SESSION_UUID. Expliquez le résultat à un opérateur d'intégration non technique. Commencez par le statut actuel exact. Ensuite, listez uniquement les résultats des modules configurés et les champs réellement renvoyés. Séparez les preuves confirmées, les preuves manquantes, les conflits et les éléments nécessitant un jugement humain. Ne modifiez pas la session.

Cette formulation facilite la détection des hallucinations. La décision contient la sortie des modules configurés pour ce flux de travail, et non un ensemble universel de vérifications de documents d'identité, de vivacité, de correspondance faciale, de lutte contre le blanchiment d'argent (AML) et de fraude. Si un module n'a pas été exécuté ou si un champ est absent, la réponse doit le mentionner plutôt que de combler le vide.

Lisez le statut comme l'état actuel de la session :

• Non démarré ou En cours signifie que l'opérateur doit attendre ou aider le demandeur à terminer le flux hébergé.
• En révision signifie que des preuves ou la logique du flux de travail ont acheminé la session vers une décision humaine.
• Approuvé ou Refusé est l'état actuel de la décision. L'un ou l'autre peut refléter une automatisation configurée ou une annulation manuelle par un réviseur autorisé, utilisez donc les preuves d'accompagnement et l'historique d'audit lorsque la politique l'exige.
• Soumis à nouveau signifie que certains nœuds de flux de travail ont été renvoyés pour une autre tentative ; il ne s'agit pas d'une session nouvelle et sans rapport.

L'inférence du modèle s'exécute en moins de 2 secondes au p99, mais ce n'est pas une promesse quant au temps qu'un demandeur mettra à capturer un document, à terminer le flux ou à attendre une révision humaine.

Que faire lorsque la réponse est En révision

Ne traduisez pas En révision par « échec », et ne demandez pas à Claude d'approuver ou de refuser dans la même invite qui explique les preuves. Demandez d'abord un dossier de révision en lecture seule :

Cette session est En révision. Appelez didit_session_get_decision et didit_session_list_reviews. Ne modifiez pas les données ou le statut. Affichez la raison ou la preuve déclencheur retournée, les sorties des modules configurés qui y sont pertinentes, toute information contradictoire ou manquante, et l'historique de révision ou de statut antérieur. Marquez tout ce qui n'est pas retourné comme inconnu.

Suivez ensuite la politique d'escalade de votre organisation. Le réviseur peut comparer les données d'identité extraites avec les preuves documentaires, évaluer une correspondance ou un candidat de filtrage, demander une autre tentative pour les nœuds de flux de travail échoués exacts, ou prendre une décision de statut autorisée. Claude peut organiser le dossier, mais il ne remplace pas le réviseur ou la politique d'acceptation de l'organisation.

Si vous êtes autorisé à documenter la révision, gardez la note séparée de la décision finale :

Ajoutez ce commentaire avec didit_session_add_review à la session SESSION_UUID : « Escaladé pour révision manuelle en raison de [preuve observée]. » Ne transmettez pas new_status et ne modifiez pas les données extraites.

didit_session_add_review nécessite session_id, accepte un comment et peut éventuellement modifier le statut. L'omission de new_status clarifie l'intention ici : enregistrer la note de révision sans décider du cas. Pour les corrections, la soumission partielle, l'approbation et les procédures de refus, utilisez le guide de la file d'attente de révision KYC avec Claude dédié.

Liste de contrôle finale de l'opérateur

• Confirmez l'organisation, l'application et la référence du demandeur avant de créer quoi que ce soit.
• Listez d'abord les flux de travail, puis récupérez la configuration ou le graphe du flux de travail sélectionné avant de décrire ses vérifications.
• N'envoyez que l'url hébergée retournée via un canal client approuvé.
• Demandez à Claude de signaler les preuves retournées, et non d'inférer des modules absents ou de convertir un statut en une histoire.
• Traitez « En révision » comme un transfert humain. Séparez l'enquête, la note d'audit, la correction des données et le statut final en étapes délibérées.
• Gardez les données personnelles inutiles, les images de documents et les jetons internes hors de la conversation.

Le serveur MCP lui-même est gratuit. Un ensemble KYC complet configuré coûte 0,33 $ et comprend la vérification de documents d'identité, la vivacité passive, la correspondance faciale et l'analyse IP. Chaque fonctionnalité comprend 500 vérifications gratuites par mois. Didit sert plus de 2 000 entreprises en production et constitue une infrastructure pour l'identité et la fraude.

Liens de référence

• Présentation MCP — point de terminaison hébergé et architecture
• Documentation des outils MCP — noms canoniques et schémas
• Didit MCP sur GitHub — source publique sous licence MIT
• Page développeur Didit MCP — présentation du produit
• Connecter Didit à Claude — configuration du connecteur