Votre LLM n'est pas un pipeline de documents

Il y a un moment dans chaque projet d'IA où la démo semble si parfaite que votre cerveau commence silencieusement à supprimer du code. Vous regardez un modèle « lire » un relevé bancaire et vous vous dites : ça y est. On peut sauter l'OCR. On peut sauter l'analyse de la mise en page. Peut-être qu'on peut sauter la moitié du pipeline. Dans la version cinéma, quelqu'un appuie sur Entrée et du JSON coule en cascade depuis le cloud.

En réalité, la cascade est un goutte-à-goutte. Et quelqu'un doit quand même apporter une serpillière.

Nous écrivons ceci avec les cicatrices laissées par nos tentatives de faire faire de l'extraction de bout en bout sur des PDF financiers à des LLM et des VLM. Pas un document de trois pages soigneusement sélectionné avec un crénage parfait, mais les PDF sans glamour qui arrivent en production : 120 pages, des mises en page multiples et quelques scans au milieu, avec une tache de café qui vous offre un filigrane bien utile vers la page 42.

Si vous voulez la conclusion tout de suite : les modèles font d'excellents assistants au sein d'un pipeline documentaire. Ils font de terribles pipelines.

Le premier succès

Mon premier succès était presque cinématographique. J'ai montré une page propre à un modèle vision-langage. « Donne-moi la date, le commerçant, le montant, le solde. » Il s'est exécuté, poliment, en JSON. Les limites du tableau semblaient correctes. Les décimales étaient justes. J'ai écrit un message Slack à l'équipe commençant par « Et si… »

C'est le moment où la caméra coupe sur un montage de moi essayant ce « Et si… » sur un vrai relevé.

Même banque, modèle différent. Les totaux renommés de « Cette période » à « Sous-total ». Les débits imprimés comme des positifs. Un saut de page qui coupe une description de ligne en deux. Un slogan d'en-tête que le modèle décide être la dernière ligne d'une transaction. Un scan avec des lignes de grille gris clair qui s'effacent juste assez pour embrouiller la détection des lignes. Ligne manquée, contenu altéré, répétitions.

Être serviable est le problème. Être serviable n'est pas auditable.

Voici un exemple concret où les VLM trébuchent, même avec la revendication du « meilleur modèle OCR du monde » de Mistral AI.

En comparant les deux, la colonne Crédit disparaît et plusieurs valeurs atterrissent dans les mauvaises colonnes, un échec classique de structure de tableau.

En revanche, les modèles de Holofin sont entraînés spécifiquement pour la structure des tableaux financiers. Sur ces pages, qui se situent pourtant dans la fourchette basse de l'échelle de complexité, ils récupèrent le schéma complet et corrigent les affectations de cellules avec une précision parfaite. Si vous voulez remplacer la saisie manuelle de données, obtenir une structure correcte à l'étape de l'OCR n'est pas négociable.

Les façons silencieuses dont un modèle peut se tromper

Ce qui nous énerve, ce ne sont pas les erreurs évidentes. Celles-là sont faciles à repérer. Ce qui nous énerve, ce sont les erreurs plausibles.

Vous pouvez regarder la sortie d'un modèle et avoir l'impression que tout va bien. Les chiffres sont formatés. Les champs sont présents. Le JSON est valide. Ce n'est que plus tard que vous remarquez qu'un « Total » apparemment raisonnable est un chiffre cumulé depuis le début de l'année (YTD), ou qu'un solde d'ouverture a été lu comme une transaction, ou qu'une ligne passée à la ligne suivante a fusionné deux commerçants en une chimère qui n'a jamais existé. Personne n'a levé d'erreur ; le système a continué sa route.

Nous pensions que c'était un problème de précision. Ce n'est pas le cas (ou pas seulement). C'est un problème de calibration. La précision, c'est « À quel point sommes-nous proches ? ». La calibration, c'est « À quel point devrions-nous faire confiance à ceci ? ». Les modèles semblent précis dans les démos. Les pipelines ont besoin de calibration en production.

Comme nous l'avons vu, il existe des articles de blog et des tests publics qui renforcent cela. Certains VLM commercialisés comme « capables d'OCR » peuvent effectivement lire des tableaux propres sur des pages propres, mais trébuchent sur le genre exact de désordre que nous venons de décrire. Qualité du scan, dérive de la mise en page, signe des montants : les types de variations qui sont routiniers dans le monde réel transforment des extractions confiantes en fiction confiante. Vous n'avez pas besoin de malveillance pour halluciner ; vous avez juste besoin de la page 57.

Le coût que personne ne mentionne dans la démo

Il y a aussi la facture.

Prenons un exemple conservateur : un relevé de 120 pages. Même si vous le découpez en deux pages par requête, vous envoyez environ 60 prompts. Vous ajouterez des instructions, peut-être quelques exemples pour stabiliser les sorties. Si vous utilisez un VLM, chaque page est un embedding d'image en plus des tokens. Multipliez par 60. Multipliez par les nouvelles tentatives (retries). Multipliez par une seconde passe quand vous réalisez que vous avez besoin de vérification. La latence passe de « rapide » à « faites-vous un thé ». Le coût passe de centimes à des euros.

Ordre de grandeur, pas une promesse : traiter un fichier de plus de 100 pages avec un seul grand VLM peut atterrir dans le voisinage de « plusieurs euros par document », et des minutes de temps réel.

Vous pouvez, bien sûr, réduire cela, mais remarquez ce que cela implique. Les astuces mêmes qui rendent la chose abordable (modèles plus petits, moins d'appels, prompts plus serrés) viennent généralement du fait de faire moins avec le modèle et plus avec du code. Ce qui nous amène à la partie ennuyeuse et incontournable.

Et la facture gonfle silencieusement quand vous ajoutez du « k-LLM » ou de l'ingéniosité Agentique. Vous routez les pages bizarres vers un second modèle, échantillonnez deux fois pour plus de sécurité, ajoutez une passe de vérification, peut-être une légende d'abord et une extraction ensuite — chaque filet de sécurité est un autre aller-retour et un autre compteur qui tourne. Ce qui ressemblait à un seul appel devient un petit comité, et le coût explose.

Le pipeline que vous finissez par construire de toute façon

À un moment donné, nous avons arrêté de demander « Un modèle peut-il lire ceci ? » et avons commencé à demander « Si le modèle lit ceci, pouvons-nous le prouver ? »

La preuve n'est pas sexy. Cela signifie que vous gardez les coordonnées pour chaque token. Cela signifie que vous pouvez montrer à un régulateur la boîte de pixels sur la page 83 qui est devenue « -1 237,45 € ». Cela signifie que vous réconciliez les soldes d'ouverture et de clôture entre les pages, et que vous paniquez si la somme des deltas ne correspond pas. Cela signifie que vous remarquez quand deux totaux différents vivent sur la même page et ne sont pas d'accord sur le fait d'être des totaux.

Vous pouvez faire tout cela avec des modèles. Mais une fois que vous avez écrit suffisamment d'échafaudages pour être en sécurité (la redondance OCR, la géométrie, les parseurs stricts, la réconciliation), une chose amusante se produit : le modèle n'est plus le héros. C'est le spécialiste que vous bipez pour les litiges et les cas limites.

C'est une bonne chose.

Là où le modèle brille vraiment

Nous aimons toujours ces modèles. Nous les aimons juste au bon périmètre.

Si deux passes déterministes ne sont pas d'accord sur la convention de signe « Débit/Crédit » — par exemple, des montants imprimés comme positifs avec une colonne D/C séparée, demandez au modèle d'arbitrer et d'expliquer son choix. Si un en-tête a changé discrètement de « Frais » à « Frais de tenue de compte » ou « Commissions d’intervention », demandez au modèle de le mapper à votre schéma canonique. S'il y a une note de bas de page comme « dont TVA 20 % » ou une section « CB différé » qui décale le moment où les montants sont appliqués, demandez au modèle de le signaler avant de mal classer un lot de transactions.

En d'autres termes : traitez le modèle comme un juge ou un traducteur. Ne lui demandez pas d'être le scanner, le parseur et le comptable.

Mais les modèles ne s'améliorent-ils pas ?

Absolument. Nous aimerions avoir tort dans six mois. Des contextes plus larges réduisent la douleur du découpage (chunking). Les backbones de vision continuent de s'améliorer. L'utilisation d'outils (tool-use) et le multi-passes aident énormément.

Même alors, les parties qui nous importent pour les documents financiers ne disparaissent pas : provenance, réconciliation, détection de dérive, et la capacité d'expliquer n'importe quel nombre à quelqu'un qui se fiche de vos prompts. De meilleurs modèles rendent les jugements plus propres. Ils ne nous dispensent pas de fournir les reçus.

Si votre cas d'usage est « extraire des totaux de documents d'une page sur papier glacé », peut-être que la boîte noire suffit. Si votre cas d'usage est « ingérer 120 pages de relevés de qualité mixte provenant de 17 banques, respecter un SLA et passer un audit », vous voudrez toujours les garde-fous. Vous voudrez aussi que la facture soit prévisible.

La check-list invisible que nous trimbalons désormais

Nous n'imprimons plus de check-list ; nous la cherchons à tâtons comme des clés dans une poche. Pouvons-nous traiter un relevé de 120 pages sans déclencher de timeouts ? Conservons-nous la provenance de la page et des coordonnées pour chaque valeur extraite ? Si nous sommons les transactions, obtenons-nous le delta du solde, ou avons-nous un trou quelque part ? Que se passe-t-il quand un modèle cale sur la page 87 : continuons-nous ou cachons-nous le bug dans une jolie enveloppe JSON ? Pourrions-nous faire tourner cela avec les modèles désactivés et obtenir quand même quelque chose d'utilisable ? Remarquerons-nous quand une banque déploie discrètement le « Template v7 » et déplace une colonne, ou le système acceptera-t-il poliment la nouvelle réalité et classera-t-il des absurdités sous les bons noms de champs ?

Ce ne sont pas des questions de deep learning. Ce sont des questions de logiciel. Ce qui est réconfortant, honnêtement.

Si vous devez choisir un combat, choisissez-en un petit

La chose qui réduit constamment les coûts et augmente la confiance est la discipline de périmètre. Demandez au modèle de choisir entre des candidats, pas d'inventer une structure. Demandez un index, pas un paragraphe. Groupez les cellules ambiguës ensemble pour que 20 décisions coûtent un seul aller-retour. Mettez en cache tout ce que vous pouvez : si vous avez vu un modèle (template), apprenez ses bizarreries une fois et réutilisez cette connaissance. Et quand le modèle perd, assurez-vous qu'il perde d'une manière qu'un humain peut corriger en un clic.

Faites cela et vous aurez la magie là où ça compte : dans les coins bizarres où les règles deviennent fragiles. Sautez cette étape et vous obtiendrez une manière très coûteuse d'avoir tort avec confiance.

Les LLM et les VLM restent la partie la plus délicieuse de la stack, tant qu'ils ne sont pas toute la stack. Le travail n'est pas d'éliminer les parties ennuyeuses. Le travail est de construire des choses ennuyeuses pour que la magie ait quelque chose de solide sur quoi reposer.

Chez Holofin, nous nous appuyons sur cette discipline : construire d'abord l'échafaudage fiable — provenance, réconciliations, vérifications de dérive — puis inviter les modèles à arbitrer là où les règles deviennent floues. Cela garde les échecs locaux et bruyants, rend les coûts prévisibles, et laisse la magie faire sa part sans porter toute la charge.

Mise à jour de décembre 2025 : Mistral OCR 3

Nous avons revisité ce sujet en décembre 2025 lorsque Mistral a sorti mistral-ocr-3. Malgré la nouvelle version et les affirmations continues d'une meilleure compréhension des documents, nous avons observé les mêmes problèmes spatiaux sur les tableaux : colonnes qui fusionnent, valeurs atterrissant dans les mauvaises cellules, et la colonne Crédit disparaissant sur les mêmes échantillons de relevés bancaires. Le défi fondamental de la récupération de la structure des tableaux reste non résolu par les VLM généralistes.