Comment évaluer un analyseur de documents pour la production

Un analyseur de documents peut obtenir d’excellents résultats sur les benchmarks et pourtant échouer sur vos documents réels, au risque de compromettre votre pipeline RAG dès la source. Pour évaluer correctement un analyseur, il faut le confronter à des jeux de documents réalistes, complexes et imparfaits, plutôt qu’à de simples démonstrations soigneusement préparées. Gartner dresse un constat préoccupant : les organisations devraient abandonner 60 % de leurs projets d'IA d'ici 2026, faute de données prêtes pour l'IA. Cet article vous propose un cadre concret pour comparer les analyseurs de documents en conditions de production, y compris les tests que la plupart des évaluations ignorent.

La plupart des évaluations d'analyseurs commencent par poser une mauvaise question. Les équipes se demandent : « Quel est son niveau de précision ? », alors que la vraie question est : « Que se passe-t-il dans mon pipeline quand cet analyseur commet une erreur ? »

La réponse à cette question est bien plus importante qu’on ne pourrait le penser. Selon le benchmark ParseBench de LlamaIndex, même les services d’analyse documentaire les plus performants n’atteignent aujourd’hui qu’environ 90 % de fidélité au contenu sur des pages issues de documents d’entreprise. Un résultat qui peut sembler satisfaisant, jusqu’à ce que l’on mesure l’impact des hallucinations et des autres erreurs. En pratique, cela signifie qu’une page sur dix comporte une omission significative ou une erreur de structure, avant même la génération du moindre embedding ou le traitement de la moindre requête.

Une analyse défaillante au moment de l'ingestion en est la cause principale.

C’est lors des évaluations préalables au déploiement que ce risque doit être identifié, et non après plusieurs semaines de résultats erronés en production. La comparaison pertinente ne consiste pas à confronter un nouvel analyseur sur les documents qu’il traite le mieux à votre analyseur actuel sur ceux qu’il traite le moins bien. Une évaluation réaliste d’un analyseur doit s’appuyer sur un jeu de documents représentatif de votre corpus de production réel, y compris les cas les plus difficiles.

Ce guide vous fournit un cadre pour mener une évaluation qui prédit réellement les performances en production, plutôt qu'une évaluation conçue pour confirmer ce qu'une démo fournisseur cherche à vous montrer.

Pourquoi la précision en démonstration ne prédit pas les performances en production

Les démonstrations réalisées à partir de fichiers d’exemple sans difficultés particulières donnent un faux sentiment de fiabilité.

Les démonstrations reposant sur des PDF natifs, des mises en page sur une seule colonne et des tableaux bien structurés placent les analyseurs dans des conditions idéales, où ils obtiennent tous de bons résultats. Or, votre corpus documentaire en production ne réunit presque certainement pas de telles conditions.

Contrats numérisés présentant des variations de luminosité, factures reçues par fax et mal alignées, documents réglementaires multilingues mêlant plusieurs systèmes d’écriture : ces cas ne se présentent généralement que plus tard, en production, et non dans le jeu de données utilisé pour l’évaluation.

C’est dans l’écart entre les performances observées en démonstration et celles obtenues en production que les pipelines de génération augmentée de récupération (Retrieval-Augmented Generation, RAG) montrent leurs limites. Une mauvaise analyse produit des segments de mauvaise qualité. Ces segments nuisent à la pertinence de la recherche d’information, ce qui entraîne à son tour des hallucinations qu’aucune optimisation des prompts ni aucun ajustement du modèle ne peut corriger. En effet, le problème ne vient pas d’un manque de connaissances du modèle, mais du fait qu’il raisonne à partir d’informations altérées.

Les travaux de recherche d'OmniDocBench, publiés à l’occasion de la conférence CVPR 2025, le confirment : les scores de précision diminuent sensiblement lorsque les analyseurs passent des conditions idéales d’un benchmark à des jeux de documents réalistes et diversifiés. Si votre évaluation ne reproduit pas les conditions réelles de traitement de vos documents, les scores obtenus ne seront pas représentatifs des performances que vous observerez en production.

Ce que doit contenir un jeu de documents d'évaluation réaliste

Les documents utilisés pour évaluer un analyseur doivent être représentatifs des types de documents que votre organisation traite au quotidien. Votre jeu de test doit inclure au minimum :

• Documents numérisés : images de documents papier présentant différents niveaux de qualité de numérisation, ainsi que des problèmes d’inclinaison et de bruit. C’est notamment sur ce type de documents que la qualité de la reconnaissance optique de caractères (Optical Character Recognition, OCR) permet de distinguer les analyseurs professionnels des outils open source comme Tesseract.
• Mises en page à plusieurs colonnes : rapports financiers, publications universitaires et lettres d’information présentant du texte sur plusieurs colonnes parallèles. Les analyseurs incapables de détecter les limites entre les colonnes risquent d’entremêler le contenu de colonnes adjacentes et de produire ainsi des segments dont le contenu manque de cohérence.
• Tableaux complexes : tableaux sans bordures, cellules fusionnées et tableaux s’étendant sur plusieurs pages. La restitution des tableaux sous une forme aplatie constitue l’un des dysfonctionnements silencieux les plus fréquents en production.
• Contenu multilingue : documents mêlant plusieurs langues ou utilisant des systèmes d’écriture non latins, comme l’arabe, le chinois, le japonais ou le coréen. La couverture linguistique varie considérablement d’un analyseur à l’autre. ABBYY prend en charge 208 langues, tandis que de nombreux outils open source sont loin d’offrir une couverture comparable.
• Documents longs de plusieurs pages : contrats, manuels techniques et rapports dont la hiérarchie des sections s’étend sur des dizaines, voire des centaines de pages. L’ordre de lecture et la continuité de la structure d’une page à l’autre constituent des sources fréquentes d’erreurs.
• Structure incohérente : les documents réels sont rarement parfaitement uniformes. Les en-têtes peuvent apparaître à des endroits inattendus. Les notes de bas de page peuvent interrompre le corps du texte. Même des documents qui semblent bien structurés à première vue présentent souvent des irrégularités susceptibles de mettre en difficulté les analyseurs entraînés sur des formats parfaitement structurés.

Évaluez la manière dont l'analyseur gère l'ambiguïté structurelle, et pas seulement les documents avec une mise en forme claire et uniforme. Sans un jeu de test réaliste incluant ces types de documents, votre évaluation mesure des conditions de démo, et non les réalités de la production.

Ce qu'il faut tester au-delà de la précision au niveau des caractères

C La précision au niveau des caractères, c’est-à-dire le pourcentage de caractères correctement extraits, renseigne très peu sur la capacité d’un analyseur à assurer une recherche d’information fiable dans le cadre d’un système RAG. Un analyseur peut afficher une excellente précision au niveau des caractères tout en détruisant complètement la structure de l’information dont les systèmes en aval ont besoin.

Testez chacun des points suivants :

• Préservation de la structure : les titres, les sections et la hiérarchie du document sont-ils correctement identifiés et balisés ? Une segmentation fondée sur la structure réelle du document permet une recherche d’information plus pertinente qu’une segmentation qui détermine approximativement les limites des différents blocs de contenu.
• Ordre de lecture : le texte extrait respecte-t-il l’ordre dans lequel un lecteur humain parcourrait le document ? Les documents à plusieurs colonnes et les mises en page complexes conduisent fréquemment les analyseurs à restituer le texte dans le mauvais ordre.
• Fidélité des tableaux : les relations entre lignes et colonnes sont-elles préservées dans le résultat obtenu ? Lorsqu’un tableau est aplati en une simple chaîne de texte, les relations qui lui donnent son sens sont perdues, ce qui le rend difficilement exploitable par les modèles utilisés en aval.
• Relations entre champs et libellés : dans les formulaires et les documents structurés, l'analyseur associe-t-il correctement les valeurs de champs à leurs libellés ? Les valeurs dissociées constituent une source fréquente d'erreurs factuelles dans les réponses générées par les systèmes RAG.
• Utilité du format de sortie : le format de sortie conserve-t-il suffisamment d’informations sémantiques pour permettre une segmentation et une recherche d’information efficaces ? Le texte brut élimine une partie du contexte indispensable à la pertinence de la recherche.

Un format structuré comme DocLang, développé conjointement par ABBYY, IBM, Nvidia, Red Hat et la Linux Foundation comme standard ouvert de balisage documentaire natif pour l’IA, intègre des balises sémantiques pour les titres, les paragraphes, les cellules de tableaux, les notes de bas de page et les champs de formulaires. C’est cette structure qui rend les données extraites véritablement exploitables par l’IA.

La différence entre les performances en laboratoire et les performances opérationnelles

Les performances en laboratoire correspondent aux scores obtenus par un analyseur sur un benchmark soigneusement sélectionné. Les performances opérationnelles correspondent aux résultats qu’il obtient sur vos propres documents, avec vos volumes de traitement et dans vos conditions réelles d’utilisation.

Les analyseurs les plus efficaces sont ceux qui produisent une structure de données fiable et prévisible sur des types de documents variés. Cette évaluation doit aller au-delà de la simple précision OCR pour mesurer la compréhension sémantique.

Les limites du « suffisamment bon » en production

Il existe un type de résultat d’évaluation particulièrement problématique : « suffisamment performant sur la plupart des documents ».

La question n'est pas de savoir si votre analyseur traite bien les documents propres, mais s'il peut traiter votre corpus de façon fiable sans introduire d'erreurs qui se propagent en aval dans le pipeline.

Une performance « suffisamment bonne » ne tient pas compte de l’effet cumulatif des erreurs partielles. Un analyseur qui extrait correctement 98 % du contenu d’un document, mais qui aplatit systématiquement tous les tableaux, peut produire des résultats exploitables pour la plupart des requêtes tout en échouant totalement dès qu’une requête nécessite des données contenues dans un tableau. Un taux de précision global de 98 % ne rend pas compte d’un taux d’échec de 100 % pour les requêtes qui dépendent de ces données.

Lorsque ces erreurs concernent des données financières essentielles, des dates ou des clauses de responsabilité, leurs conséquences sur les traitements en aval sont bien réelles.

C’est pourquoi il est essentiel d’évaluer en priorité les types de documents et les caractéristiques structurelles qui comptent le plus pour votre cas d’usage. Si votre pipeline repose sur l’extraction de tableaux, évaluez spécifiquement la fidélité de leur restitution. Si vous traitez des documents multilingues, mesurez la précision pour chaque langue. Si votre segmentation repose sur la hiérarchie des sections, vérifiez que les limites entre les sections sont correctement identifiées.

Les documents difficiles révèlent les limites de performance.

Comment mener une comparaison équitable avec votre analyseur actuel

Une comparaison directe vous fournit le signal le plus exploitable. Faites traiter le même jeu de documents par votre analyseur actuel et par celui que vous évaluez, puis comparez les résultats côte à côte selon les critères qui comptent pour votre pipeline.

Plus précisément :

1. Étape 1 : sélectionnez un jeu de référence de 50 à 100 documents. Privilégiez les documents complexes et difficiles de votre corpus réel, et non les plus simples.
2. Étape 2 : analysez chaque document avec les deux outils. Conservez l’intégralité des résultats obtenus pour une évaluation approfondie.
3. Étape 3 : sélectionnez un échantillon de 10 à 20 documents pour inspecter manuellement la structure, l'ordre de lecture et la fidélité des tableaux. Ne vous fiez pas uniquement aux métriques de précision au niveau des caractères : elles ne permettent pas de détecter les erreurs structurelles qui ont le plus d’impact sur les performances.
4. Étape 4 : effectuez un test de recherche d’information en préparant une série de questions dont les réponses sont connues et figurent dans vos documents. Indexez les résultats obtenus par chaque outil, puis vérifiez si la recherche permet de retrouverles passages corrects.
5. Étape 5 : comparez les formats de sortie pour déterminer si le format de votre analyseur actuel contient suffisamment de structure sémantique pour que votre logique de segmentation fonctionne correctement. Si ce n'est pas le cas, envisagez un format comme DocLang, avec un balisage sémantique, qui peut améliorer de manière mesurable la qualité de la segmentation et de la recherche d’information.

L’objectif n’est pas de trouver l’analyseur qui obtient le meilleur score dans un classement. Il s’agit de déterminer lequel offre les meilleurs résultats dans votre propre pipeline, avec vos propres documents.

Commencez par vos documents les plus difficiles

Le moyen le plus rapide de cerner les limites d’un analyseur en production consiste à lui soumettre d’abord vos documents les plus difficiles : ceux qui posent déjà problème dans votre pipeline, qui entraînent des hallucinations, des tableaux mal restitués ou un ordre de lecture incohérent.

Avec FineParser d'ABBYY, vous pouvez récupérer le conteneur Docker, l’exécuter sur les documents qui posent déjà problème et comparer les résultats structurés obtenus avec ceux de votre analyseur actuel.

La différence entre ce que retourne votre analyseur et ce que retourne un analyseur préservant la structure vous en dira plus sur les limites de fiabilité de votre pipeline que n'importe quel score obtenu sur un benchmark.

Testez ABBYY sur vos documents réels. L'accès anticipé est désormais ouvert.