OCR et 2D-Doc : pourquoi vérifier un document demande les deux, et pas l’un ou l’autre

Deux lectures du même document

La lecture optique (OCR, aujourd’hui confiée à un modèle de vision) fait ce qu’un œil humain fait : elle lit la page. Nom, numéro fiscal, revenu fiscal de référence, nombre de parts, année. Elle voit exactement ce que le destinataire voit, y compris ce qui a été retouché.

La lecture du 2D-Doc décode le petit carré imprimé par l’émetteur. Il contient une copie des champs essentiels, accompagnée d’une signature électronique calculée avec une clé privée que seul l’émetteur détient. La signature se vérifie avec le certificat public de l’autorité de certification : si un seul caractère des données signées a changé, elle échoue.

Ce que l’OCR seul laisse passer

Un service qui extrait les champs d’un avis d’imposition par reconnaissance optique et les affiche proprement donne une impression de contrôle. Il n’a rien contrôlé. Si le revenu fiscal de référence a été porté de 18 000 à 42 000 euros avec un éditeur de PDF, un excellent OCR lira 42 000 et le présentera avec la même assurance. La qualité de la lecture ne change rien : elle confirme fidèlement le faux.

C’est le cas de la majorité des outils de capture de documents et de nombreuses plateformes de gestion locative : ils lisent, structurent, parfois estiment une « cohérence » visuelle, mais ne disposent d’aucune donnée de référence indépendante du document lui-même. Un OCR seul répond à la question « qu’est-ce qui est écrit ? », jamais à « est-ce vrai ? ».

Un OCR, aussi précis soit-il, ne distingue pas un chiffre authentique d’un chiffre retouché : les deux sont de l’encre sur une page.

Ce que le 2D-Doc seul laisse passer

À l’inverse, un lecteur de 2D-Doc qui s’arrête à « signature valide » rate la fraude la plus simple. Le faussaire ne touche pas au code : il modifie le montant dans le corps de la page et laisse le carré intact. Le code contient toujours les vraies données signées, la signature reste parfaitement valide, et le lecteur affiche un cachet vert au-dessus d’un document dont le texte visible ment.

Deuxième cas : le code d’un document authentique, recopié sur une page fabriquée, ou l’avis d’une autre personne présenté avec un nom changé. Là encore la signature se vérifie, puisque les données signées sont bien celles de l’émetteur. Seule la comparaison avec ce que la page affiche révèle que le nom imprimé n’est pas celui du code.

Le 2D-Doc répond à « ces données signées viennent-elles bien de l’émetteur ? ». Il ne répond pas à « la page que j’ai sous les yeux correspond-elle à ces données ? ». Cette seconde question n’a de réponse que si quelqu’un lit la page.

Le recoupement, champ par champ

Trust My Docs effectue donc les deux lectures sur chaque document qui porte un code, puis compare les champs communs. Sur un avis d’imposition : nom et prénom du déclarant, numéro fiscal, revenu fiscal de référence, année des revenus, nombre de parts, référence de l’avis. Sur une carte d’identité récente : nom, prénoms, numéro du titre, sexe, nationalité.

La comparaison est déterministe, écrite en code et lisible : elle ne demande rien à un modèle de langage. Elle tolère ce qui n’est pas une fraude : « 1 » et « 1,00 » pour un nombre de parts, un accent ou une majuscule en moins, un prénom secondaire omis par la lecture optique, « FR », « FRA » et « Française » pour la nationalité. Elle ne tolère pas un montant, un numéro ou un nom différents.

• Signature valide et champs concordants : les données signées viennent de l’émetteur et la page les reproduit. C’est le seul cas où le résultat est vert.
• Signature valide et écart sur un champ : le code est authentique mais la page ne dit pas la même chose. Résultat rouge, « Authenticité mise en doute », avec le champ en cause.
• Signature invalide : le code a été altéré ou fabriqué, quelle que soit la page. Résultat rouge.
• Aucun code lisible : rien ne peut être prouvé. Résultat ambre, « Authenticité non vérifiable », jamais vert.
• Aucun champ comparable (lecture optique en échec) : la signature reste vérifiée, la concordance est déclarée « non vérifiable » plutôt qu’inventée.

Pour un avis d’imposition, un troisième contrôle, indépendant des deux premiers, complète le tableau : le numéro fiscal et la référence de l’avis sont soumis au service de vérification de la DGFiP, qui indique si l’avis présenté est bien le dernier connu. Un avis authentique mais périmé apparaît ainsi comme tel.

À quoi ressemble le résultat

Le résultat n’est pas un score ni un cachet unique : c’est une ligne par contrôle. Analyse, signature 2D-Doc, concordance des données visibles avec les données signées, dernier avis connu de la DGFiP, et enfin l’authenticité qui en découle. Chaque ligne indique ce qui a été établi, ce qui a échoué, ou ce qui n’a pas pu être vérifié, avec une phrase d’explication.

Un passeport, une ancienne carte d’identité ou un bulletin de paie ne portent pas de 2D-Doc. Le service les lit, mais affiche « authenticité non vérifiable » : dire « vérifié » sur une simple lecture optique serait précisément l’erreur que cet article décrit.

Pourquoi si peu d’outils font les deux

Les deux lectures viennent de deux mondes. L’OCR et l’extraction de champs sont l’affaire des éditeurs de capture de documents et des plateformes métier, pour lesquels la vérification cryptographique est un sujet à part. Le 2D-Doc est l’affaire de lecteurs spécialisés, souvent conçus pour un guichet, qui n’ont pas besoin de lire la page puisque le code suffit à leur cas d’usage. Chacun est complet dans son périmètre, et incomplet face à un document retouché.

Faire les deux demande de décoder le code selon la spécification de l’ANTS, de tenir à jour les certificats des autorités de certification (le nouveau repository apparu avec les avis 2026, par exemple), de lire la page avec un modèle capable de la structurer, puis d’écrire une comparaison qui distingue une différence de forme d’une différence de fond. Aucune de ces briques n’est spectaculaire ; c’est leur assemblage qui rend le contrôle probant.

Ce que même les deux ensemble ne prouvent pas

• Que la personne qui présente le document en est le titulaire : le recoupement porte sur le document, pas sur son porteur.
• Que le document est récent : c’est le rôle du contrôle DGFiP pour les avis d’imposition, et il n’existe pas d’équivalent pour les titres d’identité.
• Qu’un bulletin de paie est authentique : sans code signé, seule la cohérence avec l’avis d’imposition, dans le dossier locataire, apporte un indice.
• Qu’une lecture optique est parfaite : un champ mal lu produit une concordance « non vérifiable » ou, plus rarement, un écart à examiner par un humain. Un écart n’est pas une accusation, c’est une ligne à contrôler.

C’est pour cela que le résultat reste une liste de contrôles lisibles, et non un verdict global. Le destinataire voit ce qui a été prouvé, ce qui a échoué, et ce qui reste à regarder lui-même.

Questions fréquentes

Un OCR ne suffit-il pas pour vérifier un avis d’imposition ?

Non. L’OCR lit ce qui est imprimé, c’est-à-dire exactement ce qu’un faussaire modifie. Il restitue un montant retouché avec la même fidélité qu’un montant authentique. Seule une donnée de référence indépendante de la page, comme les champs signés du 2D-Doc, permet de dire si ce qui est imprimé est vrai.

Une signature 2D-Doc valide prouve-t-elle que le document est authentique ?

Elle prouve que les données contenues dans le code viennent bien de l’émetteur et n’ont pas été modifiées. Elle ne dit rien du texte imprimé autour du code : un montant changé sur la page laisse la signature valide. Il faut comparer les champs signés aux champs imprimés pour conclure.

Comment Trust My Docs compare-t-il les deux lectures ?

Champ par champ, avec une règle écrite en code et sans intelligence artificielle : nom, numéro fiscal, revenu fiscal de référence, année, nombre de parts et référence de l’avis pour un avis d’imposition ; nom, prénoms, numéro, sexe et nationalité pour une carte d’identité. Les différences de forme (« 1 » et « 1,00 », accents, prénom secondaire omis) sont tolérées ; les différences de valeur ne le sont pas.

Que se passe-t-il si le montant a été modifié sur la page mais pas dans le code ?

La signature du code reste valide, puisque le code n’a pas été touché, mais la concordance échoue sur le revenu fiscal de référence. Le résultat est « Authenticité mise en doute », en rouge, avec le champ en cause. C’est exactement la fraude qu’un lecteur de 2D-Doc seul ne voit pas.

Et pour un document sans 2D-Doc, comme une fiche de paie ou un passeport ?

Le service le lit et en extrait les champs, mais affiche « Authenticité non vérifiable » : sans donnée signée, aucun recoupement n’est possible. Dans un dossier locataire, les fiches de paie sont toutefois comparées au revenu fiscal de référence signé dans l’avis d’imposition.

L’intelligence artificielle intervient-elle dans la décision ?

Elle intervient dans la lecture de la page, comme un OCR avancé, parce que lire une page scannée est une tâche de perception. La décision, elle, repose sur la vérification cryptographique de la signature et sur une comparaison déterministe des champs, toutes deux auditables.