Résoudre les problèmes de téléversement et de lecture de documents
La plupart des problèmes de téléversement et d'OCR viennent de la qualité d'image, d'une image de dos manquante, d'un sous-type non autorisé ou d'une copie au lieu de l'original - voici comment corriger chacun d'eux.
Procédez dans cet ordre : le sous-type est-il autorisé dans votre workflow, l'image du dos a-t-elle été capturée, l'image était-elle suffisamment bonne, et s'agissait-il d'une photo originale plutôt que d'une capture d'écran ou d'un scan. Ces quatre points couvrent presque tous les cas.
Si un document ne se téléverse pas ou si des champs clés ne sont pas extraits correctement, c'est presque toujours l'une de quelques causes connues. Voici comment les passer en revue.
#D'abord : le document est-il seulement autorisé ?
Avant de déboguer la qualité d'image, vérifiez que votre workflow accepte bien ce sous-type précis de document pour ce pays. Un sous-type non autorisé échoue d'une manière qui ressemble à un problème de lecture mais n'en est pas un, et il échoue pour chaque utilisateur détenant ce format, pas seulement un seul. Voir les sous-types sont la raison habituelle du rejet d'un document.
#Images floues, sombres ou surexposées
Didit vérifie la qualité de l'image avant de traiter un document et demande à l'utilisateur de reprendre la photo si elle est trop floue, trop sombre ou trop claire. Demandez à l'utilisateur de :
- Utiliser un éclairage bon et homogène, sans reflet direct
- Tenir la caméra stable et laisser la mise au point se faire avant la capture
- Garder les quatre coins du document visibles dans le cadre
- Retirer le document d'une pochette plastique : le reflet empêche la capture automatique
Les utilisateurs disposent d'un nombre limité de reprises ; lors de leur dernière tentative autorisée, l'image est acceptée pour qu'ils ne soient jamais bloqués définitivement, mais une capture de mauvaise qualité peut tout de même laisser des champs illisibles. Vérifiez les avertissements de la session pour IMAGE_TOO_BLURRY, IMAGE_TOO_DARK ou IMAGE_TOO_BRIGHT afin de confirmer que c'était la cause.
Si des documents flous passent et sont même approuvés, le seuil est trop bas pour votre appétence au risque. Deux réglages dans l'étape de vérification d'identité du workflow y remédient :
- Qualité d'image minimale (le curseur de qualité) : chaque photo de document est notée par le modèle de qualité au moment de la capture, et les captures sous votre minimum sont rejetées immédiatement avec une demande de reprise. La valeur par défaut est volontairement permissive ; relevez-la et le verso flou noté 33 n'atteint jamais les vérifications.
- Écran de vérification de l'image capturée (sous Avancé) : montre à la personne la photo qu'elle vient de prendre et lui demande de la confirmer ou de rescanner avant l'envoi. Ne s'applique qu'aux scans par caméra, puisque les imports affichent déjà un aperçu du fichier.
Le score de qualité lui-même figure dans le rapport de session, vous pouvez donc examiner les sessions qui vous ont inquiété et choisir un seuil juste au-dessus.
#Un champ n'a pas été détecté, ou a été mal lu (nom, date de naissance, numéro de document)
Lorsque l'OCR ne parvient pas à extraire un champ précis, cela seul ne déclenche généralement pas le refus de la session : par défaut, elle est orientée vers une revue manuelle afin qu'une personne puisse vérifier.
Si cela se produit souvent pour un type de document ou une langue donnée, vérifiez le paramètre Format de caractères préféré de votre workflow : choisissez si les noms extraits doivent être normalisés en caractères latins ou conservés dans l'écriture d'origine du document. Une mauvaise configuration ici est une cause fréquente de champs de nom brouillés ou manquants sur les documents en cyrillique, en arabe, en grec ou en écriture han.
Lorsqu'une valeur extraite est fausse (un nom de famille avec une lettre erronée, l'adresse dans le champ du nom), voir corriger un nom ou un champ mal lu : le support ne peut pas le modifier pour vous, mais l'étape de révision des données par l'utilisateur, l'API update-data et une resoumission le peuvent.
#Les captures d'écran, impressions et photos d'écran sont refusées
Didit exige une photo originale et prise en temps réel du document physique, et non une capture d'écran, un scan, une copie imprimée, ou une photo du document affiché sur un autre écran. Les contrôles de vivacité du document sont conçus pour détecter précisément ces cas et signaleront ou refuseront la session. Demandez à l'utilisateur de photographier directement le document physique.
C'est volontaire : accepter une photo d'une photo supprime l'essentiel de l'intérêt de vérifier un document.
Le détecteur de capture d'écran peut parfois se déclencher sur un document authentique photographié sur un fond chargé : un clavier, un bureau à motifs, un écran derrière la carte. Si vous avez regardé les images et que le document est manifestement réel, approuvez la session vous-même : l'étiquette envoie en revue précisément pour qu'une personne prenne cette décision. Chaque signal de liveness du document (capture d'écran, copie imprimée, remplacement du portrait) a ses propres seuils de revue et de refus dans les paramètres de contrefaçon de l'étape, si l'un d'eux est trop sensible pour votre trafic.
#Image du dos manquante
Les cartes d'identité et les permis de conduire sont des documents à deux faces : Didit a besoin à la fois de l'image du recto et du verso pour terminer l'extraction. Si seule une image du recto a été soumise pour l'un de ces types de documents, la session ne disposera pas des données dont elle a besoin.
Si des utilisateurs restent bloqués de façon récurrente à l'étape du verso, vérifiez si le document concerné porte réellement des données lisibles au verso dans ce pays. Exiger une image de verso qui ne contient rien fait échouer une étape pour les utilisateurs sans aucun bénéfice.
#La caméra ne s'ouvre jamais
Cela ressemble à un problème de document mais c'est en réalité un problème d'environnement :
- Navigateurs intégrés aux applications. Un lien ouvert dans le navigateur intégré d'une autre application (une appli de messagerie, par exemple) ne peut souvent pas obtenir l'accès à la caméra. Ouvrir le même lien dans le navigateur normal du téléphone résout le problème.
- Autorisation précédemment refusée. Une fois qu'une personne refuse l'accès à la caméra pour un site, le navigateur s'en souvient. Elle doit la réactiver dans les paramètres du site ; le flux ne peut pas redemander.
- Caméra déjà utilisée. Un autre onglet ou une autre application qui accapare la caméra la bloque. Sur certains appareils, accorder l'accès au microphone peut aussi mobiliser la caméra.
#Le texte du parcours semble brouillé
Si la personne signale des mots brouillés ou incompréhensibles dans l'interface (pas sur le document), la cause habituelle est une extension de traduction de page du navigateur qui réécrit l'écran. Demandez-lui de désactiver la traduction pour cette page : le parcours propose déjà ses propres langues. Voir définir la langue de vérification.
#Combien de langues l'OCR prend-il en charge ?
L'OCR de Didit lit les documents dans plus de 130 langues, dans le cadre de sa couverture de documents et de pays. Ceci est distinct de la langue de l'écran de vérification lui-même, que le navigateur de l'utilisateur définit automatiquement sauf si vous la définissez explicitement.
#Toujours bloqué ?
Contactez le support avec l'identifiant de session de la vérification concernée : c'est le moyen le plus rapide pour que l'équipe examine un cas précis, car cela lui permet de voir exactement les images et les avertissements que vous décrivez.