Document intelligence industrielle : OCR cloud vs. on-premise, LLM et gestion des exceptions

OCR cloud vs. on-premise : le critère principal n'est pas le prix

La décision cloud / on-premise pour le traitement OCR est structurante car elle impacte l'architecture complète du pipeline. Le critère déterminant n'est pas le coût par page, mais la nature des données traitées.

Cas pour le cloud (Azure Document Intelligence, AWS Textract, Google Document AI) :

• Documents sans données techniques sensibles — factures fournisseurs génériques, bordereaux de livraison, documents RH
• Volumes variables avec pics — le cloud absorbe les pics sans sur-dimensionnement de l'infrastructure
• Besoin de démarrer vite — les APIs cloud sont opérationnelles en quelques jours
• L'organisation a accepté de traiter ces données sur des serveurs tiers (RGPD, politique sécurité)

Cas pour l'on-premise :

• Documents contenant des données techniques propriétaires — compositions chimiques, plans cotés, formulations, procédés de fabrication
• Exigences réglementaires ou contractuelles de localisation des données (défense, nucléaire, aéronautique)
• Politique IT qui interdit le traitement de données de production sur cloud public
• Volumes stables et élevés rendant le cloud plus coûteux sur 3 ans

Azure Document Intelligence est disponible en déploiement conteneurisé on-premise (Docker) avec les mêmes performances que la version cloud — c'est souvent la solution de compromis pour les documents sensibles.

LLM pour l'extraction : prompt engineering ou fine-tuning ?

Quand le prompt engineering suffit

Le prompt engineering (sans fine-tuning) fonctionne bien sur des documents dont la structure est relativement stable et dont les champs à extraire sont clairement définis dans le document. Pour des certificats matière de format standardisé (même si chaque fournisseur a sa mise en page), un prompt bien conçu avec quelques exemples en few-shot atteint 80 à 88 % de précision.

Avantages : pas de dataset d'entraînement, démarrage rapide, facile à modifier. Inconvénients : les cas limites (tableaux complexes, format inhabituel, scan de mauvaise qualité) posent problème.

Quand le fine-tuning est nécessaire

Le fine-tuning sur un corpus annoté devient nécessaire quand :

• La variabilité des formats est élevée (100+ fournisseurs avec autant de mises en page différentes)
• Vous visez > 90 % d'automatisation — le prompt engineering plafonne en dessous
• Les documents contiennent des termes techniques spécifiques à votre domaine mal couverts par le modèle généraliste
• Vous avez un corpus annoté de 500+ documents (en dessous, le bénéfice du fine-tuning est faible)

Le fine-tuning d'un modèle de 7B à 13B paramètres sur 800 à 1 200 exemples annotés donne généralement 8 à 12 points de précision de plus que le prompt engineering seul sur des corpus industriels hétérogènes.

Valider la précision sur votre corpus : la méthodologie

La précision annoncée par les fournisseurs d'OCR et de LLM est mesurée sur des benchmarks génériques. Sur votre corpus spécifique, les résultats peuvent être très différents — dans les deux sens.

La démarche de validation recommandée :

• Constituer un dataset de test représentatif : 100 à 200 documents couvrant la diversité des formats, des fournisseurs, des qualités de scan. Ne pas prendre uniquement les bons cas.
• Annoter les champs cibles manuellement sur ce dataset — c'est la ground truth.
• Mesurer la précision par champ, pas seulement globalement. Un champ à 60 % de précision qui va dans l'ERP est inacceptable même si la précision globale est de 92 %.
• Mesurer le score de confiance vs. précision réelle : vérifiez que le score de confiance du modèle est bien corrélé avec la précision réelle. C'est la condition pour pouvoir utiliser le seuil de confiance comme critère de routing vers la révision humaine.

Dimensionner la révision humaine : ni trop, ni trop peu

La révision humaine des exceptions est incontournable — mais son dimensionnement conditionne directement la rentabilité du projet.

Le seuil de confiance à partir duquel un document est routé vers révision humaine est le paramètre clé. Trop bas : trop de documents en révision, le gain en productivité s'effondre. Trop haut : des erreurs passent dans l'ERP.

Une approche efficace : utiliser un score de confiance par champplutôt que global. Un document dont 21 champs sur 22 sont à haute confiance et 1 champ est incertain est plus efficacement traité en révision partielle (juste le champ incertain pré-mis en évidence) qu'en révision complète du document.

L'interface de révision doit donc être conçue pour minimiser le travail de l'opérateur : champs pré-remplis, zone incertaine mise en évidence dans le document source, raccourcis de validation. Un opérateur peut traiter 60 à 80 documents / heure en révision partielle bien conçue, vs. 20 à 30 en révision complète.

Intégration ERP : les points d'attention

L'intégration dans l'ERP (SAP MM, Oracle, Sage) via API est plus fiable que l'export de fichiers CSV ou Excel. Elle permet le traitement en temps réel, la gestion des erreurs unitaire et la traçabilité des opérations.

Points d'attention fréquents :

• Gestion des doublons : un même document peut arriver via plusieurs canaux (email + portail fournisseur). La déduplication avant intégration ERP est critique.
• Gestion des rejets ERP : un enregistrement peut être rejeté par l'ERP pour des raisons de validation métier (référence fournisseur inconnue, format de date non reconnu). Ces rejets doivent être catchés et routés vers un file de correction — pas simplement ignorés.
• Tests de non-régression : les mises à jour de l'ERP peuvent modifier les règles de validation et faire rejeter des documents qui passaient avant. Prévoir des tests de non-régression automatisés sur un corpus de référence.