> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Examen manuel KYC : tableau de bord du réviseur > Approuvez, refusez ou demandez une nouvelle soumission des sessions signalées dans la console Didit, avec journal d'audit et preuves. Manual review est un élément essentiel de tout workflow robuste de vérification d'identité et de conformité KYC. Lorsque le système automatisé signale une session de vérification comportant des avertissements ou des incohérences, celle-ci passe au statut **En cours d'examen**, et un réviseur formé doit alors prendre la décision finale. Ce guide vous présente l'intégralité du processus d'examen manuel, notamment l'utilisation de la fonctionnalité de **nouvelle soumission** pour donner une seconde chance aux utilisateurs. *** ## Présentation du tableau de bord de vérification ![Présentation des vérifications nécessitant un examen manuel](https://mintcdn.com/didit-0f962782/ibesJiSLVa9jZb5z/images/console-manual-review.png?fit=max\&auto=format\&n=ibesJiSLVa9jZb5z\&q=85\&s=4f16a753968d444bf4e917c08bcbbef5) La vue en tableau des vérifications répertorie toutes les sessions avec leur statut actuel, le type de document, le pays et d'autres informations clés en un coup d'œil. Les sessions peuvent avoir les statuts suivants : | Statut | Signification | | - | - | | **Approuvé** | L'utilisateur a réussi toutes les vérifications d'identité | | **Refusé** | L'utilisateur a échoué à une ou plusieurs vérifications | | **En cours d'examen** | Nécessite votre intervention manuelle avant qu'une décision puisse être prise | | **Renvoyé** | Il a été demandé à l'utilisateur de refaire certaines étapes de vérification | > [!WARNING] > > Les sessions marquées comme étant **En cours d'examen** ont déclenché un ou plusieurs avertissements lors du traitement automatisé. Le nombre total de sessions en attente d'examen est affiché en haut du tableau de bord de vérification. *** ## Comment mener un examen manuel efficace **1. Évaluation initiale** Cliquez sur n'importe quelle session pour ouvrir la vue détaillée de la session : 1. **Examinez tous les avertissements** affichés dans la vue d'ensemble de la session : ce sont les signaux précis qui ont déclenché l'examen manuel (par exemple, score de détection du vivant faible, correspondance AML, incohérence dans le document). 2. **Examinez les tentatives de vérification précédentes de l'utilisateur** : cliquez sur les données du fournisseur de l'utilisateur pour accéder à l'historique des sessions et vérifier s'il a déjà effectué des sessions de vérification. 3. **Examinez la chronologie des événements de la session** : la section des événements fournit un journal chronologique de chaque action effectuée pendant la session. **2. Inspection du document** Le système automatisé de Didit effectue déjà une vérification complète du document, y compris la détection des éléments de sécurité, les contrôles de cohérence des données champ par champ, la validation des chiffres de contrôle MRZ, la vérification de la date d'expiration et l'analyse de la qualité de l'image. Votre rôle consiste à **évaluer les avertissements signalés** et, si nécessaire, à vérifier visuellement le document. 1. **Examinez les avertissements sur le document** : vérifiez les avertissements précis levés par le système. Les avertissements courants incluent des incohérences de données entre les champs, un échec de la validation du chiffre de contrôle MRZ, des documents expirés ou une falsification suspectée. 2. **Vérifiez visuellement en cas d'ambiguïté** : si un avertissement suggère une possible falsification ou une faible qualité d'image, inspectez directement les images du document. Recherchez des signes de retouche numérique, de recadrage, de capture d'écran ou de manipulation physique. 3. **Contrôlez les données OCR extraites** : examinez les données que le système a extraites du document et confirmez qu'elles semblent cohérentes. Le système met en évidence les champs dont la confiance est faible. 4. **Examinez les codes QR et codes-barres décodés** : lorsque Document AI détecte un code QR ou un code-barres sur le document, la vue de la session met en évidence son emplacement sur l'aperçu de l'image ou du PDF et affiche le payload décodé. Un code détecté mais impossible à décoder est affiché comme simplement détecté, sans payload indiqué. Cette superposition d'emplacement est distincte des mises en évidence des avertissements de manipulation du document, qui conservent leur traitement actuel. 5. **Examinez les correspondances de documents** : si **Recherche faciale** ou la détection des doublons est activée, vérifiez si cet utilisateur a déjà été vérifié sous une autre identité ou si le document figure dans votre **liste de blocage**. > [!TIP] > > Survolez les images de documents dans la console Didit pour utiliser la **fonction de zoom** afin d'inspecter les détails au niveau du pixel. Cela est particulièrement utile pour vérifier les microimpressions et les hologrammes. **3. Vérification biométrique et détection du vivant** Didit effectue automatiquement la **correspondance faciale**, la **détection du vivant** et, si elle est activée, la **recherche faciale**. Votre rôle consiste à examiner les résultats lorsqu'ils sont signalés. 1. **Score de correspondance faciale** : le système calcule un score de similarité biométrique entre le selfie et le portrait du document. Lors de l'examen d'une correspondance faciale signalée, concentrez-vous sur des caractéristiques structurelles comme la forme des yeux, la géométrie du nez, la mâchoire et les signes distinctifs. 2. **Score de détection du vivant** : le système de détection du vivant identifie les attaques par présentation, comme les photos imprimées, les rejeux sur écran, les deepfakes et les masques 3D. Une mauvaise qualité de caméra ou un éclairage insuffisant peut parfois produire des scores plus faibles pour des utilisateurs authentiques : envisagez de **demander une nouvelle soumission** plutôt que de refuser. 3. **Résultats de la recherche faciale** : examinez attentivement toutes les correspondances : * **Détection des doublons** : une correspondance avec une autre session peut indiquer que la même personne effectue une vérification sous plusieurs identités. * **Correspondances avec la liste de blocage** : si le visage correspond à un utilisateur figurant sur la liste de blocage, cela justifie généralement un refus. * **Faux positifs** : des similarités faciales entre des personnes différentes se produisent. Évaluez le score de confiance et comparez visuellement les images. **4. Revue des risques et des signaux** Parcourez les sections **AML**, **Analyse de l'appareil et de l'IP** et **Validation en base de données** pour évaluer le risque contextuel. ![Résultats du filtrage AML dans l'examen manuel](https://mintcdn.com/didit-0f962782/ibesJiSLVa9jZb5z/images/console-manual-review-aml.png?fit=max\&auto=format\&n=ibesJiSLVa9jZb5z\&q=85\&s=f08862b7abc947edb57e81b87ff8ecac) **Filtrage AML** * **Aucune correspondance** : risque faible. Aucun résultat trouvé dans les listes de surveillance mondiales, les listes de sanctions ou les bases PEP. * **Correspondances trouvées** : examinez chaque entrée correspondante. Vérifiez s'il s'agit d'un vrai positif ou d'un faux positif, examinez la catégorie de correspondance (PEP, sanctions, liste de surveillance, presse négative), et tenez compte de la source et de la date des données. * **Utilisez les scores, pas seulement le libellé** : l'en-tête de la section affiche le **score de risque** global dont découle le statut AML (le score de risque le plus élevé parmi les correspondances non marquées comme faux positifs, comparé aux seuils d'approbation et d'examen du workflow). Chaque ligne affiche le **score de correspondance** de la correspondance (confiance d'identité) et le **score de risque** (risque de l'entité) ; survolez l'un ou l'autre pour voir comment il a été calculé. Ce sont les mêmes `score`, `match_score` et `risk_score` que votre intégration reçoit dans le [payload de décision](https://docs.didit.me/fr/core-technology/aml-screening/report-aml-screening.md#trois-scores-pas-un-seul-verdict). **Analyse de l'appareil et de l'IP et renseignements sur l'appareil** * **Cohérence géographique** : comparez le pays de délivrance du document, l'adresse déclarée par l'utilisateur et la géolocalisation de l'IP. * **Détection VPN / Proxy** : vérifiez si l'utilisateur se connecte via un VPN, un proxy ou le réseau Tor. * **Métadonnées de l'appareil** : examinez le type d'appareil, le système d'exploitation et les informations du navigateur pour détecter des anomalies. *** ## Prendre une décision Après avoir terminé votre examen, vous disposez de trois options : **Approuver**, **Refuser** ou **Demander une resoumission**. > [card] Approuver > > * Le document semble authentique et non altéré > * Tous les champs de données sont cohérents et lisibles > * La correspondance biométrique du selfie confirme qu'il s'agit de la même personne > * Le score de détection du vivant se situe dans la plage acceptable > * Aucune correspondance pertinente en matière d’AML, de sanctions ou de PEP > * Les données de l'appareil et de localisation sont cohérentes > [card] Refuser > > * Le document semble falsifié, contrefait ou altéré > * Le selfie ne correspond pas à la photo du document > * Une correspondance AML ou de sanctions à haut niveau de confiance est confirmée > * Indicateurs forts d'une attaque par présentation > * Schémas d'identité frauduleux détectés > * Incohérences critiques des données de l'appareil ou de localisation > [card] Demander une resoumission > > * Images du document floues ou de mauvaise qualité > * Échec de la détection du vivant en raison de problèmes techniques > * Mauvais document soumis > * Étapes de vérification incomplètes ou expirées > * Problèmes corrigeables que l'utilisateur peut résoudre ![Boîte de dialogue de sélection des critères de refus](https://mintcdn.com/didit-0f962782/ibesJiSLVa9jZb5z/images/console-decline-criteria.png?fit=max\&auto=format\&n=ibesJiSLVa9jZb5z\&q=85\&s=1b6056a86de8250e5e4a5cd786de4171) > [!NOTE] > > Sélectionnez toujours un **motif de refus** et ajoutez des **notes d'examen** détaillées lorsque vous refusez une session. Cela favorise le contrôle qualité, les audits réglementaires et les analyses internes. *** ## Demander une resoumission Lorsqu'une session ne peut être ni clairement approuvée ni clairement refusée, généralement à cause de **problèmes corrigeables**, vous pouvez demander à l'utilisateur de resoumettre des étapes de vérification spécifiques. ### Comment demander une resoumission **1. Ouvrir la session** Accédez à la session dans la console Didit. **2. Sélectionner Demander une resoumission** Ouvrez le contrôle de statut de la session, choisissez **Resoumis**, puis sélectionnez **Continuer**. **3. Choisir les fonctionnalités à resoumettre** La boîte de dialogue affiche toutes les fonctionnalités non approuvées avec leur statut actuel. Sélectionnez ou désélectionnez les étapes individuelles. Les fonctionnalités qui n'ont jamais été démarrées sont automatiquement requises. **4. Envoyer éventuellement une notification par e-mail** Si l'e-mail de l'utilisateur est disponible, envoyez-lui une notification localisée avec un lien direct pour reprendre. L'e-mail indique le motif de chaque étape ; lorsque toutes les étapes sont demandées parce que le document a expiré, il le précise et demande un document valide au lieu d’un message générique « Réessayez ». Le texte peut être personnalisé par langue sous [Marque blanche → Textes](https://docs.didit.me/fr/console/white-label.md#texte-personnalisé). **5. Aperçu et confirmation** Sélectionnez **Aperçu** pour vérifier le destinataire, l'expéditeur, l'objet et l'e-mail localisé. Les sessions en marque blanche utilisent la charte graphique configurée et l'expéditeur vérifié. Sélectionnez **Modifier** pour changer les contrôles, le destinataire ou la langue, puis générez un nouvel aperçu. **Confirmer** demande la resoumission ; l'aperçu seul ne modifie pas la session et n'envoie aucun e-mail. Si les contrôles automatiques terminent la vérification sans autre action de l'utilisateur, l'e-mail de demande d'action n'est pas envoyé. ### Ce qui se passe après la resoumission 1. **Les résultats précédents restent consultables** : seules les étapes sélectionnées recommencent. Ce qu'elles ont renvoyé auparavant devient une soumission antérieure : la session l'affiche sous les onglets de soumission de chaque étape (« Soumission 2 · la plus récente », « Soumission 1 »), et l'API la renvoie avec `?include=resubmissions` sur [Retrieve Session](https://docs.didit.me/fr/sessions-api/retrieve-session.md). 2. **L'utilisateur reprend le parcours de vérification** : il doit seulement terminer les étapes spécifiques demandées. 3. **La session reste au statut Resoumis** : ce statut est distinct de **En cours**, ce qui vous permet de suivre séparément les sessions en resoumission. 4. **Réévaluation automatique** : une fois toutes les fonctionnalités resoumises terminées, le système recalcule automatiquement le statut final. 5. **Un nouveau webhook est déclenché** : votre serveur reçoit un webhook avec le statut final mis à jour. > [!TIP] > > Vous pouvez demander une resoumission plusieurs fois pour la même session. Chaque demande est numérotée, et chaque soumission antérieure reste consultable, avec l'indication de la personne qui l'a demandée et de la raison. Les tentatives au sein d'une même étape (par exemple une deuxième photo demandée par le parcours) ne sont pas des soumissions : la session affiche la tentative la plus récente, et Événements les répertorie toutes. La suppression de la session supprime toutes les soumissions. ### Resoumission ou création d'une nouvelle session | | Resoumission | Nouvelle session | | - | - | - | | **ID de session** | Même ID de session conservé | Nouvel ID de session créé | | **Historique** | Tentatives précédentes archivées au sein de la même session | Session distincte, sans historique lié | | **Effort de l'utilisateur** | Refaire uniquement les étapes échouées ou sélectionnées | Vérification complète depuis le début | | **Impact sur la conversion** | Taux de complétion plus élevés | Risque d'abandon de l'utilisateur | | **Webhook** | Même ID de session, le statut passe de Resoumis au statut final | Nouveau cycle de vie de session à partir de l’état Non démarré | | **Piste d’audit** | Historique complet au même endroit | Réparti sur plusieurs sessions | *** ## Bonnes pratiques d'examen > [accordion] Soyez cohérent > > Appliquez les mêmes critères à chaque examen. Documentez votre raisonnement afin que les autres membres de l'équipe puissent comprendre vos décisions et les reproduire. > [accordion] Privilégiez une nouvelle soumission plutôt qu'un refus pour les problèmes corrigibles > > Si le problème est une photo floue ou une erreur technique, demander une nouvelle soumission préserve la session et évite des désagréments inutiles aux utilisateurs légitimes. > [accordion] Utilisez la fonction de zoom > > Zoomez systématiquement sur les images de documents pour repérer les falsifications subtiles, les microimpressions ou les éléments de sécurité invisibles à un niveau de zoom standard. > [accordion] Croisez les données > > N'évaluez pas les signaux isolément. Un faible score de détection du vivant combiné à une connexion VPN et à une géolocalisation incohérente est plus préoccupant que n'importe quel facteur pris seul. > [accordion] Documentez tout > > Ajoutez des notes d'examen détaillées pour chaque décision, en particulier pour les refus. Ces notes servent au contrôle qualité interne et aux audits réglementaires, et aident à former les nouveaux membres de l'équipe. > [accordion] Configurez des alertes > > Configurez des alertes par e-mail ou Slack pour être averti immédiatement lorsque des sessions passent au statut **En cours d'examen**. Des temps de réponse courts améliorent à la fois la conformité et l'expérience utilisateur. > [accordion] Surveillez les tendances en matière de nouvelles soumissions > > Si un utilisateur a plusieurs cycles de nouvelle soumission, examinez attentivement l'historique complet. Des échecs répétés sur la même fonctionnalité peuvent indiquer un problème systémique. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.