PaddleOCR : l'OCR qui comprend la page

#La détection d'abord : ce que ça change

PaddleOCR est une boîte à outils d'OCR libre, sous licence Apache 2.0, qui ne lit pas une page ligne par ligne : elle cherche d'abord où se trouve le texte, puis lit chaque zone, puis peut reconstituer la structure de la page et de ses tableaux. C'est ce qui la rend robuste sur les factures, les formulaires, les scans inclinés et les documents multilingues, là où un moteur comme Tesseract produit des absurdités avec assurance. Le projet existe en deux familles : un pipeline modulaire (PP-OCRv6 pour la lecture, PP-StructureV3 pour la structure) et PaddleOCR-VL, un modèle de vision d'environ 0,9 milliard de paramètres qui convertit une page en Markdown en un seul passage et affiche 96,33 % sur OmniDocBench v1.6 selon son éditeur. Le prix à payer est une installation plus lourde, avec PaddlePaddle et des poids de modèles, et des prérequis GPU documentés pour la variante VL. Sur du texte propre en grand volume, un moteur léger reste plus simple.

Un moteur classique suppose qu'une page est faite de lignes de texte disposées comme dans un livre. Les documents réels ne le sont pas : une facture a des cadres, un formulaire a des champs, une présentation a du texte par-dessus des images, un scan arrive de travers, un plan technique porte des étiquettes en biais.

PaddleOCR sépare le problème. Un modèle de détection trouve les zones de texte où qu'elles soient et renvoie leur position ; un modèle de reconnaissance lit chaque zone. Un texte incliné, une légende en marge et un nombre dans une cellule deviennent trois zones parmi d'autres. C'est ce qui lui permet de tenir sur des documents où un lecteur ligne par ligne se trompe sans le montrer.

#Les étapes du pipeline

Toutes les étapes ne sont pas obligatoires. Lire quelques étiquettes ne demande que la détection et la reconnaissance ; ingérer des rapports financiers pour une recherche documentaire justifie la chaîne complète. PP-OCRv6, la génération de modèles de reconnaissance publiée en 2026, couvre à elle seule 50 langues dans un modèle unifié (chinois, anglais, japonais et 46 langues à alphabet latin), sans changer de modèle d'une langue à l'autre.

#PaddleOCR-VL : l'OCR qui devient un modèle de vision

Depuis octobre 2025, le projet publie une deuxième famille sous le même nom : PaddleOCR-VL, un modèle de vision-langage compact qui remplace tout le pipeline en cinq étapes par un seul passage. La version 1.6, sortie fin mai 2026, compte environ 0,9 milliard de paramètres et associe un encodeur visuel à résolution dynamique à un petit modèle de langage. Sur OmniDocBench v1.6, le benchmark de référence pour la conversion de documents en Markdown ou en JSON, elle atteint un score de 96,33 %, un niveau que le projet qualifie lui-même de nouvel état de l'art.

Ce qui frappe n'est pas seulement le score : c'est la taille du modèle qui l'obtient. Un guide publié par InsiderLLM résume la situation en une phrase : un modèle de 0,9 milliard de paramètres qui dépasse un modèle de 72 milliards et GPT-4o sur l'OCR de documents. Le même article chiffre le coût mémoire du concurrent généraliste — Qwen2.5-VL-72B a besoin de 48 Go de VRAM ou plus en quantification Q4 — quand PaddleOCR-VL, converti au format GGUF et quantifié en Q4_K_M, occupe de l'ordre d'un à un gigaoctet et demi, poids du modèle de langage et projecteur visuel réunis. Cette voie GGUF est récente : la prise en charge de PaddleOCR-VL a été intégrée à llama.cpp en février 2026 (version b8110), et les fichiers GGUF disponibles sont ceux de la communauté, pas ceux de l'équipe PaddleOCR.

La brique qui produit le score OmniDocBench n'est pas seule : à côté de PaddleOCR-VL, le projet maintient PP-StructureV3, un pipeline dédié à la conversion de PDF complexes en Markdown ou en JSON avec les coordonnées précises de chaque cellule de tableau et de chaque bloc de texte. Les deux briques visent le même objectif — un document réel converti proprement — par deux chemins différents : un modèle unique pour PaddleOCR-VL, une chaîne de composants spécialisés pour PP-StructureV3. Le moteur, quel qu'il soit, prend en charge l'inférence multi-GPU et multi-processus en natif, ce qui compte dès qu'il faut avaler un corpus de plusieurs dizaines de milliers de pages dans un délai raisonnable.

#PaddleOCR ou Tesseract

Une chaîne bien conçue utilise les deux : les pages simples au moteur léger, les pages complexes au moteur coûteux. L'aiguillage ne coûte rien et fait gagner des heures sur un gros corpus. La ligne sur l'inclinaison n'est pas anecdotique : Koncile, un éditeur d'extraction de factures, a mesuré dans ses propres tests un taux de lecture de Tesseract passé de 100 % sur une facture droite à 31 % dès que le scan est incliné de 3 à 5 degrés à peine — exactement le cas que l'étape de classification d'orientation de PaddleOCR est conçue pour absorber.

• Tesseract : le moteur léger, et quand il suffit
• Docling : convertir des documents structurés
• Extraire les données d'une facture de bout en bout
• Analyser une image avec un modèle de vision local

#Cas d'usage : quand basculer sur PaddleOCR

Facturation et comptabilité

Un scan de facture arrive rarement parfaitement droit ; la structure du tableau (quantité, prix unitaire, TVA) doit rester lisible pour que les montants gardent leur sens plutôt que de finir en ligne de chiffres isolés.

Dossiers administratifs multilingues

Formulaires, pièces d'identité, courriers dans plusieurs écritures : la couverture large de langues de PaddleOCR évite de monter un moteur différent par pays ou par alphabet.

Rapports longs pour un RAG

Un rapport de plusieurs dizaines de pages avec titres, sous-titres et tableaux gagne à être converti avec sa structure : un découpage qui respecte les sections vaut mieux qu'un découpage au nombre de caractères.

Archives scannées en vrac

Boîtes de documents papier numérisées sans soin, orientation aléatoire : l'étape de classification d'orientation absorbe l'essentiel du désordre avant même la lecture.

Volume élevé et texte propre

À l'inverse, un flux de tickets de caisse ou de relevés déjà bien cadrés, en grand volume, reste souvent mieux servi par un moteur plus léger — voir la comparaison avec Tesseract plus haut.

#Installer et lancer une première extraction

L'installation passe par pip, avec une particularité : depuis la série 3.x, le paquet paddleocr ne suffit pas seul. La documentation demande d'installer d'abord le moteur d'inférence choisi (par défaut PaddlePaddle), puis le paquet paddleocr. Les poids des modèles de détection, de reconnaissance et, le cas échéant, de mise en page sont téléchargés au premier lancement de chaque pipeline utilisé.

1. 01
   Installer la bibliothèque

   Installer d'abord PaddlePaddle en suivant la page d'installation officielle (la variante CPU ou GPU selon la machine), puis python -m pip install paddleocr. Le paquet de base accepte Python 3.8 ou plus ; les extras pour l'analyse de documents (paddleocr[doc-parser]) demandent Python 3.9 ou plus.
2. 02
   Lancer une première extraction

   La commande paddleocr ocr prend une image en entrée (option -i) et écrit les résultats dans le dossier indiqué par --save_path. Pour convertir une page en Markdown avec PaddleOCR-VL, la commande est paddleocr doc_parser, avec les mêmes options -i et --save_path.
3. 03
   Activer les étapes utiles

   Les options use_doc_orientation_classify, use_doc_unwarping et use_textline_orientation activent le redressement d'une page ou d'une ligne de travers. Sur des scans propres, les passer à False accélère le traitement ; la documentation officielle recommande d'ailleurs de désactiver les fonctions inutiles quand l'inférence est trop lente.

python -m pip install paddleocr
paddleocr ocr -i ./facture.jpg --use_doc_orientation_classify True --use_textline_orientation True --save_path ./output

#Ce que ça consomme

Le projet ne publie pas de débit universel par page : il dépend de la densité du document, des étapes activées et du matériel, et la documentation invite à désactiver les fonctions inutiles ou à choisir des modèles plus légers quand l'inférence est lente. Mesurez sur une vingtaine de vos pages avant d'extrapoler à un corpus. Pour PaddleOCR-VL, la documentation officielle donne les prérequis GPU NVIDIA (PaddlePaddle : capacité de calcul 7.0 ou plus et CUDA 11.8 ou plus ; vLLM : 8.0 ou plus et CUDA 12.6 ou plus) et prévoit aussi un chemin pour processeur x64. Les poids sont téléchargés une fois, puis tout est local : aucune API, aucun coût à la page.

#L'argument qui tranche : pas d'invention

PaddleOCR lit des pixels. Il peut mal lire un caractère, et une substitution de chiffre ne se voit pas toujours. Un modèle de vision généraliste à qui l'on demande de transcrire un document peut produire une valeur bien formée, plausible et absente de la page — et rien dans la sortie ne le signale. PaddleOCR-VL est plus délicat : comme il génère le texte au lieu de le lire zone par zone, il relève de la même famille de risque que les modèles de vision généralistes, même s'il est entraîné pour la transcription. Aucun système n'est à l'abri d'une erreur sur un caractère ambigu.

Pour du contrôle documentaire, de la comptabilité ou tout ce qui doit être auditable, cette différence doit guider le choix : un moteur d'OCR dédié pour les chiffres sur lesquels vous allez vous appuyer, un modèle de vision généraliste quand vous voulez que le document soit expliqué plutôt que transcrit. Sur les pièces à enjeu, utiliser les deux et comparer reste la troisième option légitime.

En pratique, la vérification ne demande pas de tout relire. Un échantillon de quelques dizaines de documents par lot, comparé manuellement à la sortie du moteur, suffit à détecter une dérive systématique — un champ mal cadré, une langue mal reconnue, un tableau régulièrement mal découpé — avant qu'elle ne contamine des milliers de pages traitées automatiquement.

• Source : dépôt officiel PaddleOCR sur GitHub
• Source : fiche du modèle PaddleOCR-VL-1.6
• Source : comparatif indépendant PaddleOCR-VL en local

#FAQ