Comment l’OCR lit un PDF scanné, et pourquoi cet outil renvoie du Markdown

Un PDF scanné stocke les pages sous forme d’images matricielles : des photographies de texte, pas des caractères sélectionnables. L’OCR (reconnaissance optique de caractères) examine ces pixels, devine quelles formes sont des caractères et produit du vrai texte. Sur PDF123, cette opération tourne comme outil de navigateur gratuit et comme POST /api/v1/misc/ocr-pdf ; la réponse est du Markdown, pas un PDF réécrit.

Le scan reste une image

L’OCR ne nettoie pas, n’affine pas et ne remplace pas l’image matricielle. Un scan net que l’OCR lit mal paraît toujours net. L’image n’a jamais été le facteur limitant de la qualité : la reconnaissance l’était. Changer de moteur de reconnaissance sur le même lot de scans peut faire varier la précision dans une large mesure, sans que les pixels eux-mêmes changent.

L’OCR PDF classique écrit une seconde couche de texte invisible, alignée sous l’image, pour que la sélection et la recherche tombent sur les bons mots. C’est ce que montre le schéma, et beaucoup d’outils de bureau fonctionnent encore ainsi.

Ce que renvoie réellement ce point de terminaison

La page OCR appelle /api/v1/misc/ocr-pdf, qui tourne sur un crate Rust autonome, pdf-inspector (compilé avec sa fonctionnalité ocr). Il ne transmet pas le PDF entier à un modèle de reconnaissance. pdf-inspector classe d'abord chaque page selon qu'elle possède déjà du texte natif extractible ou qu'elle est uniquement une image. Les pages avec du texte natif conservent ce texte tel quel et ne touchent jamais le modèle de reconnaissance ; les pages uniquement image passent par le pipeline de reconnaissance : PDFium (le même moteur de rendu open source que Chrome utilise en interne) rastérise la page, puis ONNX Runtime exécute le modèle PP-OCRv6 Small pour la lire. Les deux types de page sont ensuite assemblés dans l'ordre en un seul document Markdown, ce qui explique pourquoi la réponse est text/markdown et pourquoi le téléchargement se termine en .md.

Ce contrat est nouveau avec cette réécriture. Le backend Java/Spring Boot que ce projet utilisait auparavant appelait OCRmyPDF, l'approche classique « image plus couche de texte cachée », et renvoyait un PDF. La réécriture en Rust a remplacé entièrement ce chemin par l'OCR sélectif de pdf-inspector, et la sortie est passée du PDF au Markdown du même coup. L'ancien backend Java a depuis été retiré du dépôt ; ce n'est pas une option qu'on peut réactiver.

S’il vous faut un PDF interrogeable (image plus couche de texte), ce n’est pas la bonne sortie. S’il vous faut un texte qu’un agent ou un pipeline peut lire, le Markdown est précisément l’objectif.

Auto ou Force OCR

Le formulaire expose un champ ocrType :

• Normal (tout sauf force-ocr) correspond à Auto : réutiliser le texte existant là où le fichier en possède, et lancer l’OCR sur les pages purement image. Sur un PDF né numérique propre, Auto ne charge pas le moteur OCR.
• Force OCR (ocrType=force-ocr) relance la reconnaissance sur chaque page, y compris celles qui ont déjà une couche de texte. Sur de vraies pages image, vous payez du temps sans gagner en précision ; vous obtenez en revanche une passe qui ignore une couche existante cassée ou partielle.

Le portail utilise Force OCR par défaut. Aucun réglage de langue n’existe : les codes tessdata hérités de l’ancien chemin Java sont ignorés.

La bascule entre Auto et Force se joue à l'intérieur même de la requête, et ni le portail ni la sonde de capacités de l'API ne la vérifient à l'avance. GET /api/v1/settings/get-endpoints-status indique toujours ocr-pdf comme activé, sans réellement vérifier que PDFium, ONNX Runtime ou le modèle PP-OCRv6 sont installés. La vérification réelle n'a lieu qu'au moment où une requête déclenche la reconnaissance : si l'un d'eux manque, le point de terminaison renvoie 503, plutôt qu'un Markdown dégradé qui retomberait silencieusement sur le texte natif seul. Le modèle PP-OCRv6 Small pèse environ 31 Mo ; à moins d'avoir été pré-chargé dans le cache local au déploiement, il se télécharge sur le réseau la première fois qu'une page a réellement besoin de reconnaissance. Une machine hors ligne sans modèle pré-chargé échouera très probablement dès sa première requête Force, plutôt que de simplement tourner plus lentement.

La reconnaissance est probabiliste

Les moteurs comparent des motifs de pixels à des modèles de lettres et de mots. Ils réussissent bien sur de l’imprimé net, contrasté, en police standard, et moins bien sur :

• les scans à basse résolution ou à faible contraste (qualité fax contre original 300 DPI) ;
• l’écriture manuscrite, les polices décoratives, les mises en page inhabituelles (tableaux multicolonnes, texte pivoté, formulaires denses) ;
• les pages inclinées, qui déforment les glyphes juste assez pour brouiller la correspondance.

Un fax flou ne donnera pas le même OCR qu’un scan net, qu’on choisisse Auto ou Force. C'est une limite du modèle lui-même, pas quelque chose qu'un paramètre peut corriger.

Ce que l’OCR ne fait pas

L’OCR fournit du texte. Il ne reconstruit pas les paragraphes, les titres, les tableaux ni un document Word dont la mise en page se réorganise. Une mise en page éditable est un problème de conversion qui s’ajoute aux erreurs de reconnaissance : ce n’est pas la même tâche que lire un scan.

OCR un PDF s’exécute côté serveur sans compte. Le téléchargement est du Markdown. Si une couche de texte existante semble fausse, utilisez Force OCR pour qu’Auto ne s’y fie pas ; pour vérifier si une machine donnée dispose réellement de PDFium et du modèle installés, lancer une vraie requête est plus fiable que de lire la sonde de capacités, car celle-ci confirme seulement que le point de terminaison existe, pas que son runtime est prêt. Pour les clés d’automatisation et OpenAPI, voir Développeurs.