OCR dans n8n : extraire des reçus sans service cloud

OCR n8n sans cloud : intégrer Tesseract ou Ollama Vision pour les reçus, avec les erreurs fréquentes rencontrées en pratique.

Croquis dessine a la main: une loupe survole un recu traverse de lignes de scan, la loupe est colore en teal.

Extraire automatiquement des reçus, factures et bons de livraison sans les envoyer vers une API cloud : c'est possible avec l'OCR dans n8n, soit avec le moteur classique Tesseract, soit avec un modèle de vision IA local via Ollama. Pour des documents structurés avec une mise en page nette, Tesseract fournit des résultats exploitables ; pour des scans de mauvaise qualité ou des mises en page complexes, un modèle de vision a généralement l'avantage, mais nécessite nettement plus de puissance de calcul. État : août 2026.

Quelles sont les approches possibles pour l'OCR dans n8n ?

n8n ne dispose pas de nœud OCR intégré, la voie passe donc soit par des nœuds communautaires, soit par le nœud Execute Command combiné à un outil en ligne de commande. La seconde option est la plus répandue pour les instances auto-hébergées, car elle ne nécessite pas de paquets npm supplémentaires et peut être intégrée dans une image Docker personnalisée.

Comment construire la variante Tesseract ?

Le cœur est le Execute Command Node, qui exécute des commandes shell sur la machine où n8n fonctionne. D'après la documentation, ce nœud est désactivé par défaut pour des raisons de sécurité depuis la version 2.0 et n'est pas du tout disponible sur n8n Cloud, car il représente un risque dans des environnements avec des utilisateurs non fiables. Pour une instance auto-hébergée avec un cercle d'utilisateurs restreint, il peut cependant être activé de manière ciblée.

  • Écrire les données binaires sur le disque : Le Read/Write Files from Disk Node enregistre le PDF ou l'image entrant sous forme de fichier avant que Tesseract puisse y accéder. Sur n8n Cloud, l'accès est limité à `/home/node/` ; en auto-hébergement, cette zone peut être restreinte ou étendue via une variable d'environnement.
  • Convertir le PDF en image : Pour les PDF multipages, Tesseract a d'abord besoin d'un format image ; `pdftoppm` du paquet poppler-utils convient à cet usage, installé dans l'image n8n via un Dockerfile personnalisé.
  • Reconnaître le texte : La commande `tesseract` elle-même lit l'image et renvoie le texte reconnu. Tesseract est un moteur OCR open source qui, selon la description du projet sur GitHub reconnaît le texte dans plus de 100 langues.
  • Relire le résultat : Un second nœud Read/Write Files relit le fichier texte et le transmet aux étapes suivantes du workflow.

Quelles sont les limites de Tesseract en pratique ?

Tesseract atteint ses limites avec des reçus mal scannés ou à la mise en page complexe. Cela est ouvertement décrit dans la communauté n8n : un utilisateur rapporte dans le fil Local OCR in n8n with Ollama que la qualité de Tesseract était tout simplement mauvaise pour ses documents, tandis que des modèles de vision comme minicpm-v ou llava-llama3 s'en sortent mieux sur du texte dense et structuré. Cette observation provient de l'expérience pratique d'utilisateurs individuels et ne constitue pas un benchmark généralisé, mais elle correspond à la faiblesse connue des moteurs OCR classiques face à des modèles peu nets.

Quelle est l'alternative Ollama Vision, et où pose-t-elle problème ?

Au lieu de Tesseract, on peut utiliser un modèle de vision local via Ollama, capable de décrire directement des images et d'en extraire du texte. Selon les retours de la communauté, cette approche présente elle aussi des écueils pratiques rarement documentés : les gros PDF multipages dépassent la fenêtre de contexte du modèle et font caler le conteneur Ollama lorsque toutes les pages sont envoyées d'un coup. La solution courante consiste à traiter chaque page individuellement et à insérer un nœud Wait entre les requêtes afin de ne pas surcharger le conteneur local. Pour les deux variantes : quiconque utilise fréquemment `/tmp` ou des chemins similaires pour des fichiers temporaires doit vérifier si la variable d'environnement limitant l'accès aux fichiers le permet.

L'effort en vaut-il la peine par rapport à une API OCR cloud ?

L'effort en vaut surtout la peine si les reçus ne doivent pas être envoyés à un prestataire externe pour des raisons de RGPD ou de confidentialité. Si cette exigence ne s'applique pas, une API OCR cloud permet souvent d'obtenir des résultats stables plus rapidement, car la maintenance des modèles et la mise à l'échelle sont prises en charge ailleurs. Pour les entreprises qui hébergent déjà elles-mêmes leur automatisation et souhaitent garder le contrôle de leurs données, la solution locale est l'étape suivante logique. Pour ceux qui souhaitent faire installer une instance n8n sur une base saine pour ce type de workflows, plus d'informations sont disponibles sous /leistungen/n8n.

Questions fréquentes sur l'OCR dans n8n

Ai-je absolument besoin du nœud Execute Command pour l'OCR dans n8n ?

Non, il existe aussi des nœuds communautaires comme n8n-nodes-tesseractjs, qui encapsulent Tesseract directement comme un nœud, sans nécessiter de commandes shell. L'approche Execute Command est cependant plus flexible, car elle peut être combinée avec n'importe quel outil en ligne de commande, pas seulement Tesseract.

L'OCR avec Tesseract fonctionne-t-il sur n8n Cloud ?

Non, le nœud Execute Command n'est fondamentalement pas disponible sur n8n Cloud, et l'accès aux fichiers est limité à un chemin restreint. Pour ce cas d'usage, il faut une instance n8n auto-hébergée avec sa propre image Docker.

Un modèle de vision via Ollama est-il toujours le meilleur choix par rapport à Tesseract ?

Pas toujours, car les modèles de vision nécessitent nettement plus de puissance de calcul et ne sont pas non plus exempts d'erreurs avec des scans de très mauvaise qualité. Pour des documents nets et bien imprimés, Tesseract suffit souvent ; pour des modèles denses ou peu nets, les utilisateurs rapportent de meilleurs résultats avec des modèles de vision.

Comment gérer des PDF multipages sans surcharger le serveur local ?

L'approche éprouvée en pratique consiste à traiter chaque page individuellement plutôt que d'envoyer le document entier d'un coup, et à insérer de courts temps d'attente entre les étapes de traitement. Cela empêche que le conteneur Ollama ou le processus Tesseract soit bloqué par trop de requêtes simultanées.

Simon Glowik, fondateur de NordFlux
À propos de l’auteur

Fondateur de NordFlux. Sept ans d'expérience, du web et du SEO jusqu'à l'automatisation à l'échelle d'un groupe, aujourd'hui pragmatique pour les PME et avec une souveraineté des données allemande.

Certifications

  • Certifié Microsoft — PL-900 et AZ-900
  • Certifié UiPath — Automation Developer Associate
Tous les articles
Premier échange gratuit

Des questions concrètes sur l’automatisation ou l’IA ?

Lors d’un premier échange gratuit de 30 minutes, nous discutons directement de votre cas. Sans engagement.