Aller au contenu
Ztract

OCR ou extraction de documents — pourquoi des caractères ne sont pas des données

L'OCR transforme une page scannée en texte. L'extraction de documents la transforme en champs exploitables — invoice_number, total, line_items — chacun rattaché à l'endroit d'où il provient. Si vous avez déjà lancé un OCR puis tout ressaisi à la main dans un tableur, voici la différence qui compte, et comment savoir lequel votre processus a réellement besoin.

L'équipe Ztract 8 min read
  • comparison
  • ocr
Gros plan sur une carte de circuit imprimé — l'écart entre lire des caractères sur une page et les transformer en données structurées exploitables par une machine.

Si vous avez déjà scanné une pile de factures, fait tourner un outil d’OCR dessus, puis fini par recopier quand même les chiffres à la main dans un tableur, vous avez déjà ressenti l’écart dont parle cet article. L’OCR a fait son travail — il a transformé l’image d’une page en texte. Mais du texte n’est pas une donnée. Savoir que les caractères 1,250.00 apparaissent quelque part sur la page ne vous dit pas qu’il s’agit du montant total à payer et non du sous-total, de la taxe ou du solde du mois dernier.

Ce dernier maillon — passer de « voici les mots sur la page » à « voici le total, le fournisseur et chaque ligne de détail, étiquetés et prêts à l’emploi » — c’est l’extraction de documents. Cet article explique la différence en termes simples, montre où chacun trouve sa place, et vous aide à savoir lequel votre processus a réellement besoin.

Ce que fait réellement l’OCR

L’OCR — la reconnaissance optique de caractères — a une seule mission : regarder l’image d’un texte et restituer ce texte. Donnez-lui un reçu scanné et il vous rend une transcription — le nom du commerçant, les lignes de détail, le total, la date — sous la forme d’une suite plate de caractères, à peu près dans l’ordre de lecture.

C’est réellement utile pour certaines choses :

  • Rendre un PDF scanné consultable. C’est l’OCR qui vous permet de faire Ctrl-F sur un document que vous avez photographié.
  • L’accessibilité. Les lecteurs d’écran ont besoin de la couche de texte que produit l’OCR.
  • Les archives en texte intégral. Si tout ce dont vous avez besoin, c’est de retrouver un document plus tard par son contenu, l’OCR suffit.

Ce que l’OCR ne fait pas, c’est comprendre le document. Il ne sait pas quel nombre est le total et lequel est la taxe. Il ne sait pas que les trois lignes du milieu sont des lignes de détail et que la ligne du bas est une somme. Il ne sait pas que « Acme Corp » est le fournisseur et « Jane Smith » la personne de contact. Il vous donne simplement les caractères et vous laisse le sens.

Ce que l’extraction de documents ajoute

L’extraction de documents commence là où l’OCR s’arrête. Elle prend le contenu de la page et renvoie des champs nommés et typés — un objet structuré que vous pouvez déposer directement dans un tableur, une base de données ou un autre système :

{
  "invoice_number": "INV-2026-0412",
  "issue_date": "2026-05-30",
  "vendor": "Acme Corp",
  "total_due": 1250.00,
  "currency": "USD",
  "line_items": [
    { "description": "Design work", "quantity": 10, "unit_price": 100.00 },
    { "description": "Hosting", "quantity": 1, "unit_price": 250.00 }
  ]
}

Trois choses ont changé entre la transcription OCR et ceci :

  1. Les valeurs sont étiquetées. total_due est le total, pas simplement un nombre qui se trouve sur la page. Vous n’avez pas à deviner lequel est lequel — l’extraction l’a fait.
  2. La structure est préservée. Les lignes de détail reviennent sous forme de liste de lignes, pas d’un amas aplati. Ce dont il n’y a qu’un seul exemplaire (le numéro de facture) est séparé de ce qu’il y a en plusieurs exemplaires (les lignes de détail).
  3. Les types sont normalisés. 1250.00 est un nombre, pas la chaîne "$1,250.00". 2026-05-30 est une date triable, quel que soit le format imprimé sur le document. Vous pouvez faire des calculs et des filtres sans rien nettoyer au préalable.

C’est toute la différence en un mot : l’OCR vous donne des caractères, l’extraction vous donne des données.

La comparaison, côte à côte

OCRExtraction de documents
SortieUne suite de texteDes champs nommés et typés (JSON / CSV / Excel)
Comprend le document ?Non — il transcrit seulementOui — il sait distinguer total, sous-total et taxe
StructureTexte plat, ordre de lecturePréserve listes, tableaux, imbrications
TypesTout est une chaîneNombres, dates, booléens normalisés
Nouvelle mise en pageFonctionne (il lit, c’est tout)Fonctionne sans modèle par fournisseur
Bon pourRecherche, archivage, accessibilitéAlimenter outils et processus en données
Faut-il encore ressaisir ?Le plus souvent ouiNon

La ligne qui compte le plus pour la plupart des équipes, c’est la dernière. Si votre objectif est de faire quelque chose avec les chiffres — les rapprocher, les additionner, les pousser dans votre système comptable — l’OCR vous laisse l’étape de ressaisie encore devant vous. L’extraction la supprime.

« Mais j’ai déjà l’OCR — ça ne suffit pas ? »

C’est la question la plus fréquente, et la réponse honnête est : cela dépend entièrement de ce que vous faites ensuite.

Si vous avez seulement besoin de retrouver et lire des documents, l’OCR suffit — n’ajoutez pas une complexité que vous n’utiliserez pas. Mais si une personne lit la sortie OCR et saisit les valeurs ailleurs, cette étape de saisie est exactement ce à quoi sert l’extraction. Le signe est simple : êtes-vous en train de recopier des chiffres d’un écran à un autre écran ? Si oui, vous faites à la main ce que l’extraction fait automatiquement.

Un piège voisin consiste à construire soi-même l’extraction par-dessus l’OCR à coups d’expressions régulières — « trouve la ligne qui commence par TOTAL, prends le nombre qui suit ». Ça marche sur le premier fournisseur et casse sur le deuxième, parce que la facture suivante indique « Amount Due » à la place, ou place le total ailleurs, ou étale le tableau sur deux pages. Chaque nouvelle mise en page est une nouvelle règle. C’est ce tapis roulant qui explique pourquoi les approches à base de modèles et de regex ne passent pas l’échelle au-delà d’une poignée de formats de documents.

En quoi l’extraction de documents moderne est différente

L’ancienne génération d’outils d’extraction exigeait un modèle par mise en page — vous dessiniez des cadres sur un document type en disant « le numéro de facture est toujours ici, le total est toujours là ». Cela ne fonctionne que si tous les documents se ressemblent, ce qui n’est presque jamais vrai dès que vous avez plus d’un fournisseur, d’une banque ou d’une contrepartie.

L’extraction tenant compte de la mise en page lit le document comme le ferait une personne — en comprenant ce que les champs signifient, et non où ils se trouvent sur la page. Une nouvelle mise en page de facture fonctionne dès le premier essai, sans aucun modèle à configurer. Un relevé bancaire dont le tableau s’étale sur douze pages revient sous forme d’une seule liste propre. Un document de douane qui mêle deux langues conserve chaque valeur dans son écriture d’origine. La même approche couvre les reçus, les contrats, les pièces d’identité, les CV et les comptes rendus d’analyses — des documents différents, une même idée : vous décrivez ce que vous voulez, le moteur le trouve.

Si vous voulez la version pratique de « décrivez ce que vous voulez », nous y avons consacré tout un article : comment rédiger un bon schéma d’extraction.

Et la vérification du résultat ?

Il y a une inquiétude légitime à passer de l’OCR brut aux champs structurés : quand un outil interprète le document au lieu de simplement le transcrire, comment vérifier qu’il a vu juste ?

La réponse, c’est la provenance. Chaque valeur extraite par Ztract est ancrée à sa position exacte sur la page source. Cliquez sur total_due dans la sortie et l’endroit correspondant s’illumine sur le document d’origine — vérifier un nombre devient un coup d’œil, pas une chasse au trésor. Vous parcourez les champs qui semblent bancals, vous en corrigez un en un clic (les corrections sont gratuites — seule l’extraction est décomptée de vos pages), et c’est terminé. Vous obtenez la vitesse de l’automatisation sans perdre la traçabilité que vous donne la lecture de la source vous-même.

Alors, lequel vous faut-il ?

Un guide de décision rapide :

  • Vous devez rechercher ou archiver des documents scannés → l’OCR suffit.
  • Vous devez rendre le document accessible aux lecteurs d’écran → l’OCR suffit.
  • Une personne lit des documents et saisit les valeurs dans un tableur, un ERP ou une base de données → il vous faut l’extraction de documents.
  • Vous avez tenté l’OCR plus regex et ça casse à chaque changement de mise en page → il vous faut une extraction tenant compte de la mise en page, pas davantage de règles.
  • Vous avez besoin que chaque valeur extraite soit traçable jusqu’à la source → il vous faut une extraction avec provenance, comme la visionneuse côte à côte.

La plupart des équipes qui adoptent Ztract ont commencé avec l’OCR, buté sur le mur de la ressaisie, et compris que la pièce manquante n’était pas une meilleure reconnaissance de caractères — c’était la transformation de ces caractères en données étiquetées.

Essayez la différence sur votre propre document

La façon la plus rapide de ressentir l’écart, c’est de faire passer par l’extraction un document avec lequel vous travaillez vraiment, et de regarder la sortie structurée — champs étiquetés, vrais nombres, lignes de détail sous forme de lignes — au lieu d’un mur de texte. Les nouveaux comptes reçoivent 30 pages offertes, sans carte bancaire, de quoi largement tester quelques-unes de vos mises en page les plus désordonnées.

Et si vous avez un processus où vous hésitez entre l’OCR et l’extraction comme bon outil, parlez-nous-en — nous préférons vous aider à choisir la bonne approche plutôt que vous vendre la mauvaise.

← Back to all posts