OCR et documents scannés pour l'IA : pourquoi ça échoue et comment vérifier l'extraction

Un PDF scanné n'est qu'une photo de texte : sans OCR (reconnaissance optique de caractères), un moteur de RAG ne trouve littéralement aucun mot à indexer. La qualité de cette conversion, bien avant le choix du modèle ou du prompt, décide si vos réponses citeront la bonne clause contractuelle ou un charabia illisible. Ce guide explique pourquoi les scans échouent, ce qui fait un bon OCR, comment nettoyer le texte, traiter tableaux et formulaires, et vérifier l'extraction avant de mettre une base en production.

Pourquoi un document scanné fait trébucher l'IA

Un PDF « normal », exporté depuis Word ou un logiciel de facturation, contient une couche de texte invisible que n'importe quel moteur peut lire directement. Un PDF scanné, lui, n'est qu'une suite d'images : des pixels, pas des caractères. Tant qu'un OCR n'a pas transformé ces pixels en texte, aucun chunking ni aucune indexation n'est possible, comme l'explique notre article sur le pipeline RAG. Le problème, c'est que beaucoup de plateformes avalent le document sans prévenir que l'OCR a échoué silencieusement : la base se remplit de fragments de texte corrompus, et les réponses de l'IA se mettent à citer des passages qui n'ont aucun sens. Le symptôme le plus fréquent est une réponse qui invente un numéro d'article ou un montant, non pas parce que le modèle hallucine, mais parce que le texte source lui-même était faux dès l'extraction.

Les causes concrètes d'un mauvais OCR

• Résolution insuffisante : en dessous de 200 dpi, les lettres fines se confondent et le taux d'erreur grimpe rapidement
• Image penchée ou mal cadrée (skew) : un scan de travers fausse la reconnaissance ligne par ligne
• Mauvais contraste : photocopie de photocopie, tampon, surlignage ou papier jauni qui noie le texte dans le fond
• Écriture manuscrite ou polices exotiques, que la plupart des moteurs OCR généralistes ne gèrent pas correctement
• Mise en page complexe : colonnes, encadrés, notes de bas de page qui se mélangent à la lecture linéaire
• Langue mal détectée, notamment sur des documents qui mélangent français, anglais et jargon métier

Ce qui détermine la qualité d'un moteur OCR

Résolution, netteté et contraste

La règle de base reste simple : un scan à 300 dpi en niveaux de gris, bien droit et contrasté, donne un texte quasi parfait avec la plupart des moteurs actuels. En dessous, l'OCR doit deviner, et il devine mal sur les chiffres, les sigles et les numéros de contrat, c'est à dire exactement les détails qui comptent dans un document professionnel. Si vous numérisez vous-même des archives papier, privilégiez un scanner à plat plutôt qu'une photo au smartphone : l'éclairage irrégulier d'une photo introduit des ombres que l'OCR interprète comme des traits de caractères.

Langue et vocabulaire métier

Un bon moteur OCR doit connaître la langue du document pour appliquer ses règles de correction contextuelle (accents, apostrophes, mots composés). Sur des documents juridiques, comptables ou techniques truffés d'abréviations, les moteurs génériques trébuchent souvent sur les sigles rares. Si vos documents mélangent des langues, par exemple un contrat en français avec des annexes en anglais, c'est un point de vigilance supplémentaire que nous détaillons dans notre article sur le RAG multilingue.

Nettoyer le texte après l'OCR

Même un bon OCR produit un texte imparfait qu'il faut nettoyer avant indexation. Les artefacts classiques : en-têtes et pieds de page répétés sur chaque page qui polluent chaque chunk, mots coupés en fin de ligne par un trait d'union qu'il faut recoller, confusions récurrentes entre certains caractères visuellement proches, espaces multiples ou sauts de ligne parasites hérités de la mise en page d'origine. Ce nettoyage conditionne directement la qualité du découpage qui suit : un texte mal nettoyé produit des chunks qui coupent une phrase en deux ou qui noient l'information utile dans du bruit répétitif, comme on le détaille dans notre guide sur les stratégies de chunking. Sur Kopik, l'étape d'extraction et de nettoyage se fait automatiquement au moment où vous déposez un document dans la création d'une base, mais la vigilance reste nécessaire côté source : un scan illisible restera illisible, quel que soit le pipeline qui le traite ensuite.

Tableaux et formulaires : le vrai défi

Les tableaux sont le point de rupture le plus fréquent d'un OCR classique. Un moteur qui lit ligne par ligne, de gauche à droite, va fusionner des colonnes qui n'ont rien à voir entre elles : un montant en euros se retrouve collé au nom d'un fournisseur, une date de validité s'accroche à un numéro de référence. Sans reconnaissance de la structure du tableau (bordures, alignement des cellules), le texte extrait perd toute cohérence logique, même si chaque mot pris isolément est correctement reconnu. Les formulaires posent un problème voisin : cases à cocher, champs manuscrits, paires clé-valeur disposées en grille. Un OCR qui ne comprend pas qu'une case cochée signifie « oui » retranscrit parfois un simple carré noir, inutile pour répondre à une question.

Vérifier l'extraction avant d'indexer

La vérification ne doit jamais être une étape facultative. Avant de considérer qu'une base de connaissances construite sur des scans est fiable, prenez le temps de comparer un échantillon de pages à leur transcription. C'est particulièrement important si la base sera interrogée par des tiers, par exemple une base publique vendue à la question sur le catalogue Kopik.

Sur Kopik, le mode « passages » renvoie justement les extraits bruts indexés, sans reformulation : c'est le moyen le plus direct de repérer un OCR défaillant avant qu'il ne pollue des réponses générées. Pour aller plus loin sur la méthode de contrôle, notre article comment évaluer un système RAG détaille les métriques de fidélité à suivre dans la durée, et vérifier une réponse IA avec ses sources explique comment remonter d'une citation jusqu'au document d'origine.

Checklist avant de passer un document scanné en production

1. Scanner à 300 dpi minimum, en niveaux de gris, document bien à plat et droit
2. Vérifier qu'aucune page n'est floue, coupée ou à l'envers avant l'envoi
3. Choisir un moteur OCR qui déclare explicitement la langue du document
4. Nettoyer les en-têtes, pieds de page et numéros de ligne répétitifs
5. Isoler séparément les tableaux ou grilles tarifaires critiques si leur structure est complexe
6. Échantillonner et comparer manuellement un lot de pages après extraction
7. Tester la base avec des questions dont vous connaissez déjà la bonne réponse

Une fois ces vérifications faites, le document scanné devient une source aussi fiable qu'un fichier natif. C'est aussi à ce stade que vaut la peine de revoir le guide de préparation des documents pour l'IA, qui couvre les bonnes pratiques en amont, avant même le scan.