IDP : quand l'OCR ne suffit pas

"On scanne le courrier entrant et le reste se fait tout seul." La promesse est ancienne et dans la plupart des PME, elle n'est toujours pas tenue. La raison est rarement le scanner et presque jamais la reconnaissance de texte. Elle se trouve dans l'écart entre lire des lettres et comprendre des documents.

Ce que l'OCR sait faire - et où ça s'arrête

Tesseract, ABBYY ou le moteur OCR de l'imprimante multifonction livrent ce qu'ils promettent : du texte à partir d'une image ou d'un PDF. Sur une lettre standard scannée proprement, cela fonctionne très bien.

Le quotidien est différent :

• Mises en page mixtes - facture, bon de livraison et note manuscrite sur la même page.
• Tableaux sans lignes - l'humain voit les colonnes, l'OCR rend une suite de lettres.
• Variantes de formulaires - le même formulaire chez dix fournisseurs, chacun avec sa mise en page.
• Originaux difficiles - impressions fax, scans de travers, stylo bille qui traverse la feuille.
• Multilinguisme - modèle allemand, tampons anglais, nom du fournisseur italien.

L'OCR livre du texte dans tous ces cas. Ce qui manque : personne ne sait quel texte signifie quoi.

Ce qu'apporte l'Intelligent Document Processing

L'IDP s'appuie sur l'OCR et ajoute trois couches :

1. Classification. Quel type de document - facture, relance, contrat, bon de livraison ? Avec de bons modèles, quelques exemples par type suffisent.
2. Extraction. Quelle information se trouve où - numéro de facture, destinataire, IBAN, échéance ? Les systèmes modernes combinent ici des modèles de mise en page (LayoutLMv3, Donut) avec une validation basée sur des règles.
3. Validation. Plausibilité par rapport aux données de référence, vérification arithmétique sur les factures, rapprochement avec les enregistrements ERP. Sans cette couche, toute extraction n'est qu'une proposition.

Seule la combinaison des trois couches distingue "texte reconnu" de "dossier traité".

Où l'IDP livre vraiment dans les PME

Trois domaines où l'effort se rentabilise presque toujours :

• Factures entrantes. Classification, extraction des champs obligatoires, pré-imputation, rapprochement avec les commandes. Économise des minutes mesurables par document et réduit les erreurs de saisie.
• Courrier entrant en cabinet d'avocats ou cabinet médical. Affectation aux dossiers ou aux fiches patients, date d'arrivée documentée proprement, suivis automatiques.
• Formulaires fournisseurs et clients. Maintenance des données de référence sans couche de saisie manuelle, avec piste d'audit claire.

Dans les trois cas, l'IDP ne remplace pas les employés, il élimine le travail préparatoire mécanique qui coûte aujourd'hui des heures.

Quatre points qui décident du résultat

Quatre points qui décident chaque projet IDP :

1. Les documents réels battent tout jeu de données de démo. Les modèles validés sur des factures types s'effondrent au premier fax réel. Les 200 premiers documents de production appartiennent à l'évaluation.
2. Les modèles locaux sont devenus matures. Les modèles de mise en page comme Donut ou LayoutLMv3 tournent sur un GPU en salle serveur et livrent des résultats au niveau des services cloud sur les documents standards allemands - sans que le courrier du client ne quitte les locaux.
3. La validation est obligatoire, pas optionnelle. Un IBAN extrait sans somme de contrôle est un risque. Un montant de facture sans vérification arithmétique contre les totaux de lignes l'est aussi.
4. L'humain dans la boucle reste précieux. Les 5 % de cas particuliers coûtent plus en automatisation totale qu'ils n'en font économiser. Un point de transfert clair vers les agents administratifs fait partie d'un bon design.

Quand le démarrage en vaut la peine

Règle empirique : à partir d'environ 100 documents comparables par jour ou d'un flux entrant clairement récurrent (courrier en cabinet, flux de factures en achats, formulaires de demande en administration), un dispositif IDP se rentabilise sensiblement.

Un pilote avec deux ou trois types de documents, des documents réels et des indicateurs de succès honnêtes montre en quelques semaines si l'effet de levier est là. Ce n'est qu'ensuite qu'il devient pertinent de discuter mise à l'échelle, intégration ERP ou GED et mode d'exploitation.

Conclusion

L'OCR est un composant, pas un processus. Qui veut automatiser les documents entrants a besoin de classification, extraction et validation comme un système cohérent - évalué sur des documents réels et proprement connecté à l'ERP ou la GED. L'effort est maîtrisable, l'effet de levier au quotidien élevé.