Une démonstration d’extraction documentaire sur une dizaine de factures propres rassure facilement une salle. La production, elle, reçoit des scans de qualité variable, des formats mixtes, des annotations manuscrites et des exceptions métier que personne n’avait listées. Dans ce décalage, le modèle n’est souvent qu’une partie du problème. Ce qui décide de la tenue du système, c’est l’ingénierie autour : jeux de test, scores, files de reprise, observabilité.
Jeux de test et scores par champ
Un jeu de test représentatif ne se limite pas aux documents « beaux ». Il doit refléter la distribution réelle - y compris les cas rares qui coûtent cher en reprise manuelle. Nous préférons un score de confiance par champ plutôt qu’un score global par document : un montant mal lu n’a pas le même impact qu’un libellé approximatif. Sans cette granularité, on accepte ou on rejette trop gros. Le même écart démo / production apparaît en RAG entreprise.
La file de reprise humaine n’est pas un aveu d’échec ; c’est un composant du pipeline. Chaque reprise doit être traçable : quelle valeur a été proposée, qui l’a corrigée, dans quel délai. Ces corrections alimentent ensuite l’analyse d’erreur. Sans boucle fermée, le taux d’erreur mesuré le jour du go-live dérive sans que personne ne s’en aperçoive avant un incident métier.
Prêt pour la production sous charge réelle
Nous ne considérons un extracteur prêt pour la production que lorsque les erreurs résiduelles sont acceptables pour le métier et reprises dans un délai défini. Si cette condition n’est pas tenue, l’outil déplace le travail plutôt qu’il ne le réduit. La question n’est donc pas « le modèle est-il assez bon ? », mais « le système autour du modèle est-il opérable sous charge réelle ? ». En finance, cela se prolonge dans l’automatisation en pré-comptabilité.
Quand le flux doit aller jusqu’à l’outil comptable, une brique comme AYA 360 aide à penser bout en bout plutôt qu’une OCR isolée. Pour cadrer un pipeline d’extraction, voir aussi nos offres IA.
