Chez holofin, l'extraction de relevés bancaires est l'un de nos cœurs de métier, et nous la faisons tourner en production. Les prêteurs, les comptables et les équipes financières nous confient des relevés de centaines de banques différentes et s'attendent à récupérer chaque transaction, exactement, sans rien d'inventé ni d'oublié.
L'extraction se situe tout au début de cette pipeline, ses erreurs ne restent donc jamais isolées. Une ligne manquante ou inventée ne fait pas que retirer un point à un score de précision. Elle devient un solde impossible à rapprocher, une décision de solvabilité basée sur un chiffre qui n'a jamais figuré sur la page, un grand livre auquel personne en aval ne peut se fier. Un relevé bancaire est booléen : soit il est entièrement correct, soit c'est un risque.
Nous voulions donc savoir avec quelle fiabilité les meilleurs modèles actuels accomplissent réellement cette tâche, non pas sur une démo triée sur le volet, mais sur de vrais relevés, évalués de la même manière qu'une équipe financière les évalue, où la seule chose qui compte est de savoir si l'ensemble du relevé tient la route. Nous avons construit un benchmark pour le découvrir.
Le jeu de données47 vrais relevés, un par banque
Chaque relevé est réel, puis anonymisé de sorte que la mise en page, les tableaux et les totaux survivent, mais les noms et les chiffres sont synthétiques : grandes banques françaises, banques allemandes, néobanques et EMI, chacune avec sa propre idée de ce à quoi devrait ressembler un tableau de transactions. Les labels gold ont été vérifiés à la main par rapport aux PDF sources.
Chaque relevé est réel, puis anonymisé pour que la mise en page, les tableaux et les totaux survivent, mais les noms et les chiffres sont synthétiques. Cliquez sur n'importe quelle page pour zoomer ; passez à Par banque pour filtrer.
La précision par ligne est une vanity metric
Le chiffre qui compte pour un client n'est pas "quelle fraction des lignes est correcte" mais "est-ce que ce relevé est correct". Ce ne sont pas les mêmes métriques. Un relevé n'est correct que si chaque ligne l'est, donc une seule ligne manquante ou inventée fait échouer tout le document.
- Par relevé, pas par ligne. holofin extrait 98 % des relevés avec zéro erreur ; le meilleur modèle de pointe atteint 80 %. Sur 44 documents, holofin a produit une seule ligne erronée ; les modèles de pointe en ont produit 70 à 115 chacun.
- L'écart vient de l'invention, pas de la lecture. Chaque système lit bien la page (recall 0.88–1.00). Les erreurs sont des lignes que le modèle renvoie et qui ne sont pas sur la page : environ 8 à 10 % des lignes renvoyées par un modèle de pointe ne correspondent à aucune transaction sur le relevé. Nous les avons toutes tracées à la main — 68 à 93 % d'entre elles (selon le modèle) n'ont aucun équivalent sur la page, c'est de la pure invention ; le reste correspond à une vraie ligne lue avec un montant ou une date erronés. holofin : une seule ligne de ce type sur 44 relevés.
- Le risque est dans la traîne, pas une taxe constante. Les erreurs ne sont pas réparties uniformément — la plupart des relevés reviennent propres sur tous les modèles, mais une poignée de mises en page échouent lourdement. Une seule ligne inventée fait échouer tout le relevé, et rien ne vous dit à l'avance de quel document il s'agira.
- Une fenêtre plus grande n'est pas la solution. Fournir plus de pages par appel ne change rien ; le traitement par page est fiable car il limite l'invention.
Ce que nous avons trouvé
Quatre lectures du même benchmark. La première place chaque système sur l'exhaustivité (a-t-il trouvé les lignes ?) par rapport à la précision (les lignes renvoyées sont-elles réelles ?). Le reste suit l'arithmétique à partir de là.
Chaque système trouve les lignes (exhaustivité, x). Ils diffèrent sur le nombre de lignes renvoyées qui existent réellement (précision, y). holofin se situe dans le coin supérieur droit ; les modèles de pointe chutent sur l'axe de la précision à mesure qu'ils inventent. Modèles de pointe affichés par page.
Un relevé n'est correct que si chaque ligne l'est. Part des relevés extraits avec zéro erreur (aucune ligne manquante, aucune ligne inventée) par rapport au gold vérifié à la main. Le sous-label indique le total des lignes erronées sur l'ensemble des 44 documents : holofin en a fait une seule ; les modèles de pointe en ont fait des dizaines.
Sur chaque ligne renvoyée par un modèle, la part dont le (date, amount) n'est pas sur la page. Nous les avons toutes tracées à la main : environ 68 à 93 % (selon le modèle) n'ont aucun équivalent sur la page — de la pure invention ; le reste correspond à une vraie transaction lue avec un montant ou une date erronés. Une ligne inventée se rapproche d'un solde erroné et semble plausible : l'échec silencieux. Modèles de pointe affichés avec leur meilleur paramétrage (par page).
holofin traite une page à la fois et domine tous les axes. Pour les modèles de pointe, fournir plus de pages par appel ne change rien : le recall baisse un peu, la precision augmente un peu, le traitement par deux pages est souvent le point d'équilibre. L'écart qui compte est celui avec la barre verte.
Les erreurs ne sont pas une taxe constante — elles s'accumulent sur une poignée de mises en page (bami, crédit industriel, raiffeisenbank, paypal…) tandis que la plupart des relevés reviennent propres sur tous les modèles. C'est là le vrai risque : pas un 10 % prévisible, mais quelques mises en page qui échouent lourdement, sans aucun moyen de savoir à l'avance quel document vous avez entre les mains — et une seule mauvaise ligne fait échouer tout le relevé. Décompte brut des lignes erronées (manquantes + inventées, vs gold) par relevé, paramétrage par page ; un relevé par banque, les mises en page rares sont donc surreprésentées. La colonne de holofin est vide. · = propre ; chiffres = erreurs sur ce document.
La destruction silencieuse de la ligne inventée
Ce n'est pas un échec de lecture de l'encre sur la page. Si une transaction est visiblement imprimée, chaque modèle la trouve. Le problème est ce qu'ils trouvent quand la transaction n'y est pas. Il y a une différence opérationnelle massive entre une ligne manquante et une ligne inventée. Une ligne manquante est ennuyeuse : le solde ne correspond pas et un opérateur repère l'écart. Une ligne inventée est un tueur silencieux. Le modèle récupère un solde courant, un sous-total ou une date isolée et le formate comme une transaction valide. Il a l'air parfaitement plausible en le faisant. Il empoisonne simplement l'arithmétique, lentement et de manière invisible.
Ce que "inventé" signifie ici — et ce que cela ne signifie pas
Nous associons chaque ligne renvoyée à la page sur son (date, signed amount) à la précision du centime. Une ligne renvoyée qui ne correspond à rien compte contre le modèle. Ce groupe ne représente pas qu'une seule et même chose, nous avons donc tracé chaque ligne non correspondante à la main : 68 à 93 % d'entre elles
(selon le modèle) n'ont aucun équivalent sur la page — un solde courant, un sous-total ou un chiffre isolé déguisé en transaction. Le reste correspond à une vraie transaction
lue avec un montant ou une date altérés. Les deux rendent le relevé faux, mais ce sont des échecs différents —
et la majorité relève d'une véritable invention, pas d'une erreur d'OCR. (Une mise en garde : une erreur de lecture ne se distingue d'une invention que lorsqu'une ligne sœur survit pour l'y associer, cette répartition est donc une limite inférieure de la véritable invention.)
Le gold est humain, pas un modèle
Nous n'avons pas laissé un modèle évaluer d'autres modèles. La vérité terrain (ground truth) a été construite à la main : sur chaque document où les systèmes étaient en désaccord, une personne a ouvert le PDF source et vérifié les transactions ligne par ligne. Le benchmark évalue par rapport à ce qui est réellement imprimé sur la page, vérifié par un humain, et non par rapport à l'opinion d'un autre modèle.
MéthodologieComment le benchmark est conçu
Les candidats de pointe reçoivent des images de pages avec un prompt d'extraction générique à trois tailles de contexte. holofin est la véritable pipeline de production (classify → OCR → per-page extract), pilotée via HTTP. Chaque métrique est doc-macro : calculée par document, puis moyennée.
44 relevés, un par banque distincte, choisis pour la diversité de leur mise en page — non pondérés par la fréquence d'apparition de chaque banque dans le trafic réel. Cela surreprésente délibérément les mises en page rares et complexes (une petite mutuelle basque, une coopérative allemande Raiffeisen de huit pages), ce qui est exactement là où les modèles de pointe échouent. Considérez donc ceci comme une évaluation de la fiabilité dans le pire des cas, et non comme une prévision de la précision moyenne en production : un modèle propre sur les banques courantes ici peut toujours être coulé par la prochaine mise en page étrange qu'il rencontrera. Et la seule ligne erronée de holofin sur 44 docs est un point de donnée encourageant, pas un taux garanti.
La vérification évidente en production est de savoir si les calculs d'un relevé tombent juste : solde d'ouverture + Σ transactions = solde de clôture. Nous l'avons mesuré, et c'est nécessaire mais non suffisant comme métrique de vérité. Les relevés de GPT-5.5 se rapprochent 42/45 du temps, pourtant il invente toujours ~8 % des lignes par rapport à la page réelle ; une ligne inventée compensée par une autre erreur tombe toujours juste, et un modèle qui omet entièrement les soldes (Gemini les a laissés vides sur 12 documents) ne peut pas être vérifié du tout. Un relevé peut passer les mathématiques et être quand même faux. Nous évaluons donc chaque transaction par rapport au gold qui a été vérifié à la main contre le PDF source.
Vous n'avez pas besoin d'une fenêtre plus grande. Vous avez besoin d'un harnais.
Vous ne résolvez pas l'extraction en passant un PDF entier à un endpoint et en demandant à un modèle de faire attention. Chez holofin, c'est la description du poste. Nous construisons la cage à l'intérieur de laquelle l'intelligence s'exécute :
- La structure avant la sémantique. L'OCR déterministe et la géométrie construisent d'abord le contexte de la page. Les prompts capturent bien le sens et mal la structure visuelle.
- Délimiter le problème. Nous traitons strictement par page, sans jamais demander à un modèle de conserver un grand livre entier dans sa mémoire de travail.
- Contraintes > vibes. Des règles comptables strictes décident de ce qui compte comme une transaction avant même qu'un résultat ne soit finalisé.
Une fois que vous avez écrit suffisamment d'échafaudages pour être en sécurité (la redondance de l'OCR, la géométrie de délimitation, les parseurs stricts, les rapprochements), le modèle n'est plus le héros. C'est le spécialiste que vous appelez pour les litiges et les cas particuliers. Le travail ne consiste pas à éliminer les parties ennuyeuses ; il consiste à construire des choses ennuyeuses pour que la magie ait un support solide sur lequel s'appuyer.
Articles connexes
Votre extracteur de tableaux a réussi le test. Pas les chiffres.
Une auditrice ouvre votre résultat d'extraction pour un bilan. Le modèle affiche une précision par cellule de 99,2 %. Impressionnant. Puis elle fait le total de la colonne des actifs à la main, comme le font les auditeurs, et obtient un chiffre décalé d'une ligne. Les actifs ne sont plus égaux au passif plus les capitaux propres. Le bilan ne s'équilibre pas.
Détection de fraude documentaire : ce qu'un PDF ne peut pas cacher
Nous pensions que la fraude documentaire était un problème visuel. Mauvaises polices. Colonnes mal alignées. Un logo qui semblait légèrement décalé. Nous avons construit des vérifications basées sur ce que les humains voient, car ce que les humains voient était tout ce que nous avions.
Quand les documents contre-attaquent
Page 1 : Résumé du compte, deux colonnes. Page 15 : Même compte, trois colonnes, noms d'en-tête différents. Page 47 : Un scan avec une tache de café. Page 89 : La page des totaux, qui fait référence à des transactions que vous avez extraites il y a 70 pages.