Du document capturé à une décision contrôlable

Six fonctions à distinguer

Lire un document n’équivaut pas à vérifier une identité. L’OCR reconnaît des caractères ; l’extraction associe des valeurs à des champs ; la vérification documentaire examine des indices d’authenticité. La biométrie compare des caractéristiques d’une personne, la liveness cherche des indices de présence réelle, et la décision KYC applique un processus métier et ses obligations. Ces fonctions peuvent participer à un parcours commun sans devenir interchangeables.

Cette distinction évite une erreur de conception : transformer un nom correctement extrait en décision de confiance. Le NIST SP 800-63A-4 distingue les opérations de preuve d’identité. Il constitue une référence technique, pas une validation réglementaire d’un parcours KYC ni une certification d’un moteur OCR.

Capture : faire entrer une image exploitable

Une image floue, présentant des reflets ou incomplète peut rendre un champ illisible avant toute inférence. Définir les contrôles de capture : document entier, lisibilité, taille suffisante, orientation et absence d’obstruction. Donner un retour compréhensible à l’utilisateur et permettre une nouvelle capture sans l’enfermer dans une boucle.

Conserver le motif de rejet de qualité séparément du contenu extrait. Une image rejetée pour reflet n’est pas un document frauduleux. Tester différents appareils et conditions de lumière ; mesurer le nombre de tentatives et le temps nécessaire pour obtenir une capture utilisable.

Classification et rectification

Identifier la famille de document et sa variante avant de choisir les zones utiles. Une catégorie inconnue doit rester inconnue : forcer le gabarit le plus proche peut produire une extraction convaincante mais erronée. Le redressement et le recadrage doivent conserver une relation avec l’image source pour que l’opérateur comprenne ce qui a été lu.

Tester changements de génération, recto/verso, pages supplémentaires et documents hors périmètre. La classification peut utiliser des modèles, des règles ou une combinaison ; ses erreurs doivent être évaluées séparément de celles de la reconnaissance.

OCR spécialisé et modèles vision-langage

Les moteurs OCR spécialisés restent utiles lorsque les champs, écritures et contraintes de calcul sont bien identifiés. Les modèles vision-langage élargissent les possibilités de lecture de mises en page variées, mais introduisent d’autres comportements, coûts et besoins d’évaluation. Choisir sur un corpus local et un contrat de sortie, pas uniquement sur un classement général.

Le rapport PP-OCRv5 de 2026 et la documentation multilingue PaddleOCR fournissent des références actuelles. Leurs résultats ne doivent pas être transférés à Identity OCR ni à vos documents sans mesure sur la version et le matériel réellement utilisés.

Extraction et normalisation sans perte

Définir un schéma avec valeur brute, valeur normalisée, zone source, moteur et version. Traiter dates, numéros et noms selon des règles explicites. Une normalisation doit être traçable : elle ne doit pas supprimer silencieusement un caractère inhabituel ou inventer une date à partir d’une chaîne ambiguë.

Pour les champs absents ou illisibles, produire une valeur inconnue et un motif. Ne pas remplir à partir d’une plausibilité linguistique. Valider formats et cohérences entre champs, tout en distinguant erreur de lecture, incohérence du document et échec d’une règle métier.

Français, arabe et affichage

Les documents bilingues demandent une évaluation par écriture et par champ. Conserver les formes arabe et latine, gérer le sens de lecture et tester les caractères ressemblants, les chiffres et les variantes de noms. Une divergence entre translittérations ne prouve pas une fraude et ne justifie pas une correction silencieuse.

L’algorithme bidirectionnel Unicode traite l’ordre d’affichage ; il ne résout pas l’équivalence sémantique des noms. Vérifier l’interface de revue, les exports et les recherches : une chaîne stockée correctement peut devenir trompeuse si son affichage mélange mal les directions.

Règles et scores : rendre l’incertitude visible

Séparer confiance du modèle, contrôles de format, cohérences et décision opérationnelle. Un score élevé n’est pas nécessairement une probabilité calibrée d’exactitude. Mesurer sa relation aux erreurs observées, par type de document et champ, puis choisir les seuils selon le coût métier d’une erreur.

Pour une MRZ, les spécifications ICAO Doc 9303 offrent des règles de structure et de contrôle. Un checksum valide peut renforcer la cohérence d’une lecture ; il n’atteste ni de l’authenticité du support ni de l’identité du porteur. Présenter ces contrôles séparément dans la sortie.

Une revue humaine réellement exploitable

L’opérateur doit voir le champ, sa zone source, les contrôles échoués et les alternatives utiles. Prévoir validation, correction et refus, avec des motifs lisibles. Conserver la correction comme un événement distinct de l’extraction initiale ; elle doit pouvoir être auditée sans exposer inutilement le document à d’autres personnes.

Mesurer la charge de revue et les divergences entre opérateurs. Un seuil qui oriente presque tous les dossiers vers l’humain peut annuler l’intérêt opérationnel ; un seuil qui réduit artificiellement les escalades peut laisser passer des erreurs coûteuses. Évaluer ces deux effets ensemble.

Confidentialité et on-premise

Déployer dans le périmètre du SI peut faciliter le contrôle des accès et des flux, mais n’établit pas une conformité automatique. Cartographier images, champs, fichiers temporaires, logs, sauvegardes et éventuelles télémétries. Limiter accès réseau, données de test, rétention et export ; vérifier l’effacement sur chaque support utile.

La CNDP présente les conditions de traitement au Maroc. Le responsable du processus doit déterminer les formalités et règles qui lui sont applicables. La présence d’un moteur local ne résout pas, à elle seule, finalité, minimisation, droits des personnes et sécurité d’exploitation.

Tests, performance et dérive

Constituer une vérité terrain autorisée et revue, avec familles, variantes, langues, qualité de capture et cas hors périmètre. Séparer documents de développement et validation, éviter les doublons proches et garder des versions. Mesurer exactitude par champ, erreurs graves, dossiers sans intervention et taux de correction humaine.

Tester latence de bout en bout, débit sous charge, mémoire et files sur le matériel cible. Surveiller nouvelles variantes, nouveaux appareils et évolution du taux de rejet. Une dérive du corpus peut exiger une nouvelle qualification même si le modèle n’a pas changé. Aucun seuil chiffré universel ne remplace les critères du processus.

Identity OCR : un périmètre d’extraction

Le Lab Identity OCR documente une chaîne de détection, rectification, OCR FR/arabe et extraction, avec console opérateur et architecture on-premise décrites par les sources internes. Le service public présente CIN, certificat d’immatriculation, permis et passeport marocains. La documentation annonce des capacités CPU ; cette note ne les transforme pas en performance garantie.

Ce Lab ne revendique ni biométrie, ni liveness, ni détection de fraude ni décision KYC. Il constitue un point d’entrée pour évaluer une brique documentaire. Une intégration métier doit qualifier le corpus, définir les validations et décider explicitement qui autorise la suite du parcours.

Du champ extrait à une décision contrôlable

Le contrat final doit distinguer ce qui a été lu, corrigé, vérifié et décidé. Il doit permettre de retrouver la source, la règle, la version et l’intervention humaine. La décision reste liée à une politique métier et à une responsabilité identifiée.

La valeur de la Document Intelligence tient à cette continuité : préparer des données exploitables, conserver l’incertitude et rendre les contrôles visibles. C’est sur cette chaîne, plutôt que sur la seule élégance d’une démonstration, qu’une DSI et des opérations peuvent fonder une mise en service.