OCR côté serveur avec modèle de vision pour les documents scannés

Pourquoi les documents scannés cassent l'extraction de texte

Demandez à un extracteur de texte de lire un PDF scanné et vous n'obtiendrez presque rien. Un PDF produit par un traitement de texte porte une couche de texte - les caractères sont stockés comme texte, et l'extraction est triviale. Un PDF produit par un scanner est au contraire une enveloppe d'images de pages : il n'y a aucune couche de texte, seulement des pixels. Le parser du collector ne peut extraire que ce qui existe réellement, donc les pages en images seules reviennent vides ou presque, et un document qui paraît parfaitement lisible dans une visionneuse ne contribue pas du tout à la base de connaissances.

Simmetric Chat le gère côté serveur, avant qu'un document n'atteigne l'étape de chunking et d'embedding. Quand l'ingestion détecte un PDF pauvre en texte, la plateforme le route vers une pipeline OCR dédiée dont le moteur n'est pas une bibliothèque OCR classique à reconnaissance de motifs, mais un modèle de langage doté de capacités de vision servi localement via Ollama. Le résultat est du Markdown extrait qui préserve titres, listes et structure de tableaux bien mieux qu'un OCR au niveau des caractères - et tout tourne entièrement dans votre infrastructure. Aucun document ne quitte jamais le réseau pour être lu.

Cet article décrit comment fonctionne la pipeline, quels contrôles elle expose et l'étape d'approbation humaine qui empêche un modèle qui lit mal de polluer silencieusement une base de connaissances.

Des pixels au Markdown : la pipeline

L'OCR dans Simmetric Chat est une pipeline côté serveur basée sur des jobs. Un upload dont le texte extrait ne passe pas le précheck - par défaut, moins d'environ 200 caractères extractibles marquent un document comme scanné - devient un job OCR, et un ordonnanceur de polling reprend les jobs toutes les 10 secondes avec une limite de concurrence globale, pour qu'un lot d'uploads ne puisse pas saturer la machine. Un document unique traverse alors cinq étapes :

1. Chargement. pdfjs-dist ouvre le PDF côté serveur et énumère les pages, avec un plafond de 50 pages par job comme limite de sécurité contre les traitements incontrôlés.
2. Rendu. Chaque page est rendue en image PNG à une échelle agrandie - 2x par défaut - pour que même les petits caractères d'une numérisation de qualité fax arrivent au modèle avec une résolution lisible.
3. Reconnaissance. Chaque image de page est envoyée au modèle de vision Ollama configuré comme image base64, et le modèle transcrit la page en texte Markdown.
4. Protection. La transcription brute traverse une garde anti-hallucination et une étape de nettoyage du grounding. Les modèles de vision annotent parfois la sortie avec des marqueurs de grounding, ou inventent du contenu plausible quand une page est vraiment illisible - les deux cas sont interceptés ici plutôt que sauvegardés.
5. Score et assemblage. Chaque page reçoit un score de qualité, les pages sont concaténées en un seul document, et le job se conclut par un récapitulatif honnête : les pages échouées sont comptées et rapportées comme pages échouées, jamais absorbées en silence dans un résultat « terminé » propre.

Chaque étape de cette liste se déroule sur le serveur. Le navigateur n'exécute jamais l'OCR, et aucune API OCR tierce n'est appelée - le seul saut réseau va de votre serveur à votre instance Ollama.

Choix du modèle

Le modèle de vision est configurable, et la pipeline inclut un petit registry de modèles qui sait dialoguer avec chaque famille prise en charge :

• glm-ocr - le défaut (OCR_MODEL=glm-ocr:latest), un modèle de vision spécialisé en OCR. Le registry le route via l'endpoint chat d'Ollama, qui pour cette famille de modèles détecte la fin de transcription de façon plus fiable.
• deepseek-ocr - une seconde famille optimisée pour l'OCR qui utilise des tokens de grounding ; le registry lui envoie des images d'une page et retire les marqueurs de grounding pendant le nettoyage.
• N'importe quel modèle de vision générique - les modèles que le registry ne reconnaît pas retombent sur un prompt générique via l'endpoint generate d'Ollama, donc même un modèle multimodal que vous exécutez déjà en local fonctionne.

Les paramètres liés au modèle sont des variables d'environnement, documentées avec le reste de la surface de configuration :

# OCR vision côté serveur
OCR_MODEL=glm-ocr:latest   # modèle de vision (supporte model:version)
OCR_TIMEOUT=600000         # 10 minutes - les modèles de vision sont lents
OCR_NUM_PREDICT=8192       # tokens de sortie max par page

Un endpoint de prewarm permet à un administrateur de charger le modèle en mémoire avant le premier job, pour que le premier upload scanné de la journée ne paie pas le coût de démarrage à froid du modèle.

L'humain dans la boucle : approuver ou rejeter

La qualité de la transcription varie avec la qualité de la numérisation, et une base de connaissances est le mauvais endroit pour découvrir qu'un modèle a mal lu une page. C'est pourquoi la pipeline traite la sortie OCR comme un brouillon, pas comme un fait. Chaque job produit un artefact révisable : l'aperçu garde le texte extrait lié à la même portion de page que le panneau avec l'image, pour qu'un relecteur puisse vérifier n'importe quelle page en la comparant à la numérisation d'origine.

Depuis le panneau de paramètres OCR un administrateur voit le catalogue des modèles, la liste des jobs avec les scores de qualité et de crédibilité par page, et le flux de travail lui-même :

• Approuver - les pages extraites sont acceptées et poursuivent : un job d'archive approuvé matérialise les pages dans la base de connaissances, et depuis le résultat approuvé une exécution de synthèse peut être lancée.
• Rejeter - la sortie est écartée et la décision est consignée sur le job.

L'automatisation est disponible sans renoncer au verrou. Un hook d'auto-approbation piloté par les événements peut finaliser les jobs dont les signaux de qualité sont propres, et préserve délibérément le flux d'approbation manuelle partout où la décision humaine est le contrat - un import explicitement routé vers une base de connaissances n'est jamais auto-approuvé en silence. Dans tous les cas, les récapitulatifs de jobs restent honnêtes sur la santé des pages : un job terminé avec trois pages échouées le déclare dans son résultat et dans les logs.

Le sens du cérémonial est un invariant unique : le texte n'entre dans votre index RAG qu'après un passage de qualité propre ou après qu'un humain l'a examiné.

Où va le texte extrait

La sortie OCR approuvée rentre dans le flux d'ingestion normal. Pour les documents uploadés, le Markdown extrait remplace la couche de texte manquante à la numérisation, et le document poursuit avec chunking, embedding et indexation pour la recherche hybride exactement comme un PDF natif. Pour les archives, les pages approuvées deviennent partie de la base de connaissances curée du workspace, où wikilinks, backlinks et la pipeline de synthèse peuvent opérer dessus comme sur n'importe quelle autre page.

Parce que la pipeline est côté serveur, elle se compose avec les garanties du reste de la plateforme : les filtres DLP continuent de scanner les contenus avant qu'ils ne quittent le réseau, le RBAC continue de décider qui peut lancer des jobs et approuver des résultats, et aucun point du parcours OCR n'exige une connexion sortante vers un service OCR cloud.

Réglages pratiques

La plupart des déploiements ne requièrent que trois décisions :

• L'activer. OCR_ENABLED et OCR_PRECHECK_CHARS - le seuil de caractères qui route un PDF vers la pipeline - se gèrent dans les paramètres d'administration.
• Choisir le modèle. glm-ocr:latest est un défaut sensé ; le catalogue des modèles liste ce que le registry reconnaît, le choix du modèle par job est disponible depuis le panneau de paramètres, et des instructions personnalisées peuvent affiner le comportement de transcription pour votre domaine documentaire.
• Budgéter le temps. L'OCR vision échange de la vitesse contre de la fidélité. Le timeout par défaut de 10 minutes et le plafond de 50 pages existent pour qu'une numérisation pathologique dégrade en échec visible plutôt qu'en worker bloqué.

Si votre corpus est surtout fait de PDF natifs, vous remarquerez rarement la pipeline : les couches de texte saines contournent complètement l'OCR. Au moment où un document scanné arrive, il passe par le rendu, le modèle de vision et votre approbation - et finit recherchable au lieu d'invisible.

Lire le guide complet dans la doc →