Passer au contenu principal

Vue d’ensemble

Les avertissements du rapport de vérification d’identité signalent chaque condition observée par Didit lors de la lecture et de la validation du document. Ils figurent dans le tableau warnings[] de chaque élément de id_verifications[] (voir Rapport de vérification d’identité), avec la structure décrite dans Modèles de données — Objet d’avertissement : feature, risk, additional_data, log_type, short_description, long_description, node_id. Chaque avertissement comporte trois niveaux :
  1. Le code risk — un identifiant stable que vous pouvez utiliser pour effectuer des correspondances dans votre code.
  2. Le log_type — dérivé de l’action que votre configuration attribue au risque au moment de l’évaluation : Refuser → error, Examen → warning, toute autre valeur → information.
  3. L’impact sur la décision — défini par les groupes de risques configurables du workflow. Le même code risk peut être orienté vers Approuver, Examen ou Refuser selon la configuration de votre application.

Conditions de refus automatique

Dans les workflows, les risques suivants font systématiquement passer le rapport d’identité (et la session) à Declined. Ils ne peuvent pas être configurés : Pour l’API OCR autonome, l’ensemble des refus inconditionnels comprend DOCUMENT_EXPIRED, MINIMUM_AGE_NOT_MET, PORTRAIT_IMAGE_NOT_DETECTED, SCREEN_CAPTURE_DETECTED, PRINTED_COPY_DETECTED, PORTRAIT_MANIPULATION_DETECTED et PUBLIC_DOCUMENT_IMAGE_DETECTED. Dans les workflows, l’âge minimum est configurable (par défaut Refuser) et les trois risques de détection du vivant du document dépendent de seuils (voir ci-dessous). Les risques configurables de cette API acceptent DECLINE ou NO_ACTION comme paramètres de requête, plutôt qu’un verdict d’Examen. Le seul résultat d’Examen qu’elle peut renvoyer n’est pas configurable : lorsqu’une vérification de détection du vivant du document demandée ne produit aucun score utilisable, la réponse est In Review avec un avertissement DOCUMENT_LIVENESS_NOT_COMPUTED (voir Détection du vivant du document).

Paramètres de vérification configurables

Dans la console Didit, les risques restants liés à la pièce d’identité sont regroupés dans des paramètres que vous pouvez acheminer vers Approuver, Examen ou Refuser (par workflow et par nœud dans les workflows sous forme de graphe) : Les risques de doublon et de liste de blocage en capture silencieuse proviennent de la Recherche faciale sur le selfie pris lors de la capture du document. La recherche s’exécute lorsque l’option Recherche faciale par capture silencieuse (document_selfie_face_search_enabled) est activée, ce qui est le cas par défaut, et que Recherche faciale n’est pas désactivée à l’étape Détection du vivant ; sinon, aucun de ces six risques n’est déclenché. Deux familles de risques liés à la pièce d’identité sont basées sur des seuils plutôt que sur des options Approuver/Examen/Refuser :
  • Détection du vivant du document — SCREEN_CAPTURE_DETECTED, PRINTED_COPY_DETECTED, PORTRAIT_MANIPULATION_DETECTED. Chaque type de fraude possède ses propres seuils de refus et d’examen : score inférieur au seuil de refus → error + Refusé ; inférieur au seuil d’examen → warning + En cours d’examen ; sinon information.
  • Correspondance faciale multi-caméras — LOW_FRONT_CAMERA_FACE_MATCH_SIMILARITY, régie par document_selfie_portrait_match_decline_threshold / document_selfie_portrait_match_review_threshold.

Configuration des seuils de détection du vivant du document

Dans l’éditeur de workflow, ces seuils se trouvent dans l’onglet Falsification de l’étape Vérification d’identité, avec une carte par type de fraude : Remplacement du portrait, Copie imprimée et Capture d’écran. Chaque contrôle attribue au document un score de 0 à 100 évaluant son authenticité. Un score plus élevé signifie que le document est plus susceptible d’être authentique. Les deux valeurs figurant sur une carte divisent cette échelle en trois plages : Augmenter l’une de ces valeurs rend le contrôle plus strict : davantage de sessions se retrouvent dans la plage supérieure. Diminuer une valeur permet à davantage de sessions de passer. Dans l’éditeur, la valeur de refus ne peut pas dépasser la valeur d’examen. Via l’API, une valeur de refus supérieure à la valeur d’examen supprime la plage En cours d’examen. Valeurs par défaut de la plateforme, utilisées lorsqu’un workflow ne définit pas de valeur : Commencez par les valeurs par défaut et modifiez une valeur à la fois. Chaque carte affiche sa valeur par défaut ainsi qu’un bouton Rétablir les valeurs par défaut, vous permettant de toujours y revenir. L’éditeur vous avertit également concernant ces configurations :
  • Examen à 100. Seul un score parfait est validé, de sorte que presque toutes les sessions passent à l’état En cours d’examen ou sont refusées.
  • Refuser à 100. Seul un score parfait évite un refus, de sorte que presque toutes les sessions sont refusées.
  • Les deux valeurs à 0. Aucun score n’est jamais signalé, le contrôle est donc effectivement désactivé.
Définir les deux valeurs sur le même nombre supprime la plage En cours d’examen : un score inférieur à ce nombre est refusé et tout autre score est validé. Lorsque Copie imprimée et Capture d’écran signaleraient toutes deux le même document, seul SCREEN_CAPTURE_DETECTED est rapporté. La correspondance faciale multi-caméras repose sur le même principe, avec une différence au niveau de la limite : un score égal à son seuil d’examen passe tout de même à l’état En cours d’examen. Quatre risques liés à l’identité ne sont ni configurables ni régis par des seuils. POSSIBLE_FRONT_CAMERA_FACE_IN_BLOCKLIST est toujours orienté vers Examen : un selfie proche d’un visage figurant sur une liste de blocage, sans être une correspondance confirmée, doit être évalué par une personne, sans jamais faire l’objet d’un refus automatique ni être ignoré. BARCODE_SIGNATURE_INVALID est toujours orienté vers Examen. Il ne se déclenche que lorsqu’un code-barres comporte la signature d’une autorité de délivrance qui échoue à la vérification cryptographique, de sorte qu’il n’existe aucune configuration dans laquelle une falsification avérée est ignorée. DOCUMENT_BACK_SIDE_NOT_AVAILABLE est toujours une information et n’affecte jamais la décision : il signale une limitation du catalogue de documents de Didit, et non une propriété du document présenté, de sorte qu’il n’existe aucune configuration dans laquelle il peut refuser ou envoyer en examen un titulaire légitime. FRONT_CAMERA_CAPTURED_DOCUMENT est toujours orienté vers Examen. Il ne se déclenche que lorsque l’image prise par la caméra frontale pendant la capture du document montre une pièce d’identité sans aucune personne, garantissant ainsi qu’une capture n’apportant aucune information sur la personne qui tenait le document parvienne toujours à un réviseur. Il est vérifié dès lors que la correspondance de portrait lors de la capture de document (is_document_selfie_portrait_match_enabled) est activée.

Avertissements générés

Vérifié par rapport à collect_ocr_logs, au flux de capture de document et à process_ocr_logs_and_get_status. Les descriptions courtes ci-dessous correspondent exactement aux chaînes short_description renvoyées par l’API.

Reconnaissance et qualité des documents

Le flux de capture peut également rejeter un téléversement avec les codes de retour IMAGE_RESOLUTION_TOO_LOW, DOCUMENT_NOT_FULLY_VISIBLE, IMAGE_QUALITY_TOO_LOW et DOCUMENT_OCCLUSION_DETECTED (un doigt ou un objet est considéré comme recouvrant physiquement du texte imprimé). Chacun invite à une nouvelle prise dans le SDK et est enregistré dans le rapport sous son propre risque, acheminé selon les paramètres Image Quality — DOCUMENT_OCCLUSION_DETECTED et IMAGE_QUALITY_TOO_LOW partageant une même action. Ils décrivent la capture : une nouvelle prise réussie efface l’avertissement. La question de savoir si un champ masqué doit affecter la décision relève de l’intégrité avec le risque distinct CRITICAL_FIELD_OCCLUSION_DETECTED ci-dessous, qui est émis au moment de la décision et dont l’action est configurée sur Review par défaut.
Si votre workflow ancre l’identité sur Face Match plutôt que sur le portrait du document, envisagez de router Document Without Portrait vers Decline — sinon, une famille de documents sans portrait atteint l’étape Face Match sans aucun élément de comparaison.

Extraction des champs

MRZ, QR, code-barres

Les trois risques liés à la MRZ sont ignorés pour les types de documents dont les MRZ sont notoirement peu fiables.
La vérification de signature des codes-barres couvre actuellement les cartes nationales d’identité françaises, dont le code-barres 2D-Doc ANTS est signé par l’autorité de délivrance. BARCODE_SIGNATURE_INVALID n’est déclenché que lorsque le contrôle de signature rejette lui-même le payload. Un code-barres sans signature, un code-barres signé par une autorité qui ne figure pas encore dans le magasin de confiance de Didit, ou dont la signature ne peut pas être décodée, est traité comme une donnée non authentifiée et validé par rapport à la MRZ et au texte imprimé comme auparavant, sans déclencher ce risque.Les codes-barres des permis de conduire des États-Unis et du Canada (AAMVA) ne font pas l’objet d’une vérification cryptographique : la signature numérique y est facultative et propre à chaque juridiction, et aucune juridiction ne publie de clés de vérification. Didit se contente donc de détecter et de journaliser si un payload comporte une signature ; la signature elle-même n’est jamais vérifiée. Les échecs de signature AAMVA ne constituent pas un signal de risque aujourd’hui. Un payload AAMVA altéré n’apparaît que sous la forme de BARCODE_VALIDATION_FAILED, et uniquement si l’altération entraîne également une discordance entre le code-barres et la MRZ ou les données imprimées/OCR - une signature falsifiée sur un payload par ailleurs cohérent en interne passe sans aucun signal.L’utilisateur n’est jamais invité à reprendre une capture en cas de BARCODE_SIGNATURE_INVALID : une signature qui ne correspond pas au payload ne peut pas être corrigée en prenant une meilleure photo.

Correspondance d’identité

Détection du vivant du document (falsification)

Géré par des seuils selon le type de fraude dans les workflows. Sur l’API OCR autonome, ces trois risques entraînent un refus sans condition, et un contrôle demandé ne produisant aucun score exploitable renvoie In Review au lieu d’approuver. Les scores eux-mêmes figurent sur chaque rapport V3 sous document_liveness, y compris lorsqu’aucun avertissement n’a été émis, permettant ainsi d’auditer un document approuvé.

Intégrité du canal de capture

Le champ log_type reflète l’action configurée : error pour Refus, warning pour Examen, information pour Aucune action. Action recommandée : traitez une session refusée comme une capture injectée et demandez à la personne de réessayer sur un appareil physique doté de sa caméra intégrée. Les signaux qu’une personne authentique peut produire ne déclenchent jamais INJECTION_ATTACK_DETECTED et restent informatifs. Les applications qui relaient une véritable caméra, comme un téléphone utilisé comme webcam ou une couche d’effets appliquée sur une véritable webcam, ne sont pas signalées comme des attaques par injection. Il s’agit d’une détection des attaques par injection, distincte de la détection des attaques par présentation (un faux présenté devant une véritable caméra).

Images de documents publics connus

Discordances avec les informations attendues

Lorsque vous transmettez expected_details à une session, Didit génère un avertissement de discordance pour chaque champ qui ne correspond pas. Un seul regroupement (expected_details_mismatch_action, par défaut Examen) contrôle le routage de tous ces avertissements : Chaque avertissement de discordance contient les valeurs attendues et extraites dans additional_data.

Âge

Adresse

Correspondances de documents entre sessions

En plus des avertissements ci-dessus, le rapport de vérification d’identité V3 inclut un tableau matches[] — contenant jusqu’à 5 autres documents dans votre application présentant la même date de naissance, le même pays de délivrance et un nom complet très similaire (les documents sur liste de blocage nécessitent en plus une correspondance exacte du numéro de document), à l’exclusion des sessions appartenant au même utilisateur. Les documents ajoutés à votre liste de blocage apparaissent avec is_blocklisted: true. Les documents figurant sur votre liste d’autorisation apparaissent toujours dans les correspondances, mais l’action associée aux utilisateurs en double est ignorée. Chaque correspondance comprend session_id, session_number, vendor_data, verification_date, user_details (name, document_type, document_number), status, is_blocklisted, api_service et une front_image_url signée.

Exemples

Avertissement configurable avec son acheminement par défaut (information)

Refus automatique sur document expiré

Discordance des détails attendus avec le payload

Types d’avertissements

Une gravité est attribuée à chaque risque en fonction de la configuration de votre application. Les trois niveaux de gravité sont :

Pages connexes

Dernière modification le 7 novembre 2026