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.
- comparison
- ocr
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 :
- Les valeurs sont étiquetées.
total_dueest 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. - 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).
- Les types sont normalisés.
1250.00est un nombre, pas la chaîne"$1,250.00".2026-05-30est 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
| OCR | Extraction de documents | |
|---|---|---|
| Sortie | Une suite de texte | Des champs nommés et typés (JSON / CSV / Excel) |
| Comprend le document ? | Non — il transcrit seulement | Oui — il sait distinguer total, sous-total et taxe |
| Structure | Texte plat, ordre de lecture | Préserve listes, tableaux, imbrications |
| Types | Tout est une chaîne | Nombres, dates, booléens normalisés |
| Nouvelle mise en page | Fonctionne (il lit, c’est tout) | Fonctionne sans modèle par fournisseur |
| Bon pour | Recherche, archivage, accessibilité | Alimenter outils et processus en données |
| Faut-il encore ressaisir ? | Le plus souvent oui | Non |
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.