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.

C'est un seul « document ».

Votre pipeline d'extraction fonctionne à merveille dessus. Page par page, chaque transaction atterrit dans la bonne colonne. Les montants sont analysés proprement. Les dates semblent correctes. Vous le livrez.

Puis la comptabilité appelle. Les crédits et les débits ne correspondent pas. Il y a un écart de 3 200 €. Non pas parce qu'une page unique était fausse, mais parce que la page 12 utilise des virgules pour les décimales et la page 68 utilise des points. Votre parseur a géré les deux correctement, isolément. Ensemble, ils ont produit deux interprétations différentes de « 1.234 » et personne ne l'a remarqué jusqu'à ce que l'équation d'équilibre se brise.

L'extraction d'une page individuelle peut être parfaite alors que le document dans son ensemble est inutilisable.

Un document, quinze personnalités

Les documents longs ne sont pas monolithiques. Ce sont des sections assemblées avec différentes mises en page, différentes qualités de scan et différentes idées sur l'apparence que devraient avoir les nombres.

Un vrai relevé bancaire de 120 pages que nous avons traité comportait :

Changements de mise en page : - Pages 1-10 : Portrait, tableau de transactions à deux colonnes - Pages 11-50 : Paysage, trois colonnes avec un solde courant - Pages 51-80 : Retour au portrait, noms d'en-tête entièrement différents - Pages 81-120 : Pages de résumé avec totaux agrégés

Variation de qualité : - Pages 1-40 : PDF natif, couche texte propre - Pages 41-60 : Scanné à un moment donné, nécessite l'OCR - Pages 61-80 : Scanné avec des annotations manuscrites dans les marges - Pages 81-120 : PDF natif à nouveau

Surprises sémantiques : - Trois comptes distincts regroupés dans un seul relevé - Sous-relevés imbriqués dans le relevé principal - Totaux à la page 118 qui font référence à une transaction à la page 3

Tout système d'extraction qui traite cela comme « un document, une passe » va passer un mauvais moment. La mise en page de la page 11 invalide les hypothèses de la page 1. La qualité du scan à la page 45 nécessite une stratégie d'extraction complètement différente de celle du PDF propre de la page 5.

La question n'est pas « avons-nous extrait chaque page correctement ? ». C'est « avons-nous extrait le tout de manière cohérente ? ».

Ce qui se passe quand on ne découpe pas

L'approche naïve consiste à lancer tout le document dans une seule passe d'extraction et à espérer le meilleur. Voici ce qui se passe réellement :

Les fenêtres de contexte se remplissent. Même les grands modèles s'étouffent avec 120 pages de données de transaction. Ils commencent à laisser tomber des lignes vers la page 40, silencieusement. Pas d'erreur, pas d'avertissement. Juste des transactions manquantes qui ne font surface que lorsque quelqu'un effectue la réconciliation.

La confusion de mise en page s'aggrave. Le modèle apprend la disposition à deux colonnes des pages 1 à 10, puis rencontre trois colonnes à la page 11. Parfois, il s'adapte. Parfois, il fusionne deux colonnes et produit des transactions fantômes avec des descriptions concaténées. À la page 51, lorsque la mise en page change à nouveau, tout est possible.

Une mauvaise page empoisonne tout. Ce scan taché de café à la page 47 ? Dans une extraction en une seule passe, un montant mal lu provoque une cascade. Le solde courant se décale, le modèle « corrige » les transactions suivantes pour qu'elles correspondent, et vous avez maintenant des données d'apparence plausible qui sont fausses d'une manière difficilement détectable.

La solution est la segmentation : découper le document en morceaux cohérents, extraire chacun indépendamment, puis réassembler avec une validation inter-segments.

Mais la mise en page n'est pas la seule chose qui varie sur 120 pages. La qualité physique des pages riposte aussi.

Le scanner gagne toujours

Les changements de mise en page sont au moins logiques. Quelqu'un a conçu un format à trois colonnes pour les pages 11-50 et un format à deux colonnes pour le reste. Vous pouvez raisonner là-dessus.

La qualité du scan, c'est le chaos.

Un relevé bancaire de 120 pages arrive. Les pages 1-40 sont en PDF natif : couche texte propre, coordonnées parfaites, extractible jusqu'au glyphe. Puis la page 41 arrive et la couche texte disparaît. Quelqu'un a imprimé le relevé, l'a scanné et a fusionné le résultat. Vous faites maintenant de l'OCR sur des pixels au lieu de lire du texte à partir d'un document structuré.

C'est le cas facile. Voici ce qui arrive réellement :

La photo prise au téléphone. Quelqu'un a tenu son téléphone au-dessus du relevé au lieu d'utiliser un scanner. Le flash de l'appareil photo délave le coin supérieur droit, exactement là où se trouve le solde de clôture. L'image est nette au centre et floue sur les bords. Les hautes lumières surexposées créent des taches blanches qui avalent les chiffres. Nous détectons cela en mesurant les ratios de pixels surexposés et les taches de reflets spéculaires. Si plus de 15 % d'une page est brûlée, vous regardez une photo, pas un scan.

La relique de fax à 75 DPI. Un relevé qui est passé par un fax quelque part dans sa vie. La résolution est si basse qu'un « 8 » et un « 6 » sont indiscernables. Un « 3 » pourrait être un « 8 ». La confiance de l'OCR tombe en dessous de 50 %, et maintenant vous devinez les montants. À 75 DPI, la netteté des bords s'effondre. La magnitude du gradient de Sobel qui indique 15+ sur un scan propre tombe en dessous de 2,5. Les caractères individuels cessent d'avoir des bords.

La bavure de fond. Un rouleau usé dans le chargeur de documents du scanner laisse une bande grise sur chaque page. Ou pire : l'encre de la page précédente a été transférée lors de l'alimentation, et maintenant la page 47 a du texte fantôme de la page 46 qui transparaît. L'OCR ne sait pas quelle couche de texte est la vraie. Il extrait les deux, et soudain vous avez des transactions fantômes qui n'existent pas.

La section pivotée. Les pages 51-60 ont été scannées en paysage mais les métadonnées PDF indiquent portrait. Le texte est de côté. L'OCR peut parfois gérer une rotation de 90 degrés, mais 2-3 degrés d'inclinaison dus à une page mal alignée dans le chargeur ? Cela transforme les lignes droites du tableau en lignes légèrement courbes, et l'alignement des colonnes, la chose dont dépend votre logique d'extraction, devient mou.

La falaise de qualité au sein d'un même document :

C'est le vrai problème. Ce n'est pas que certains documents sont de mauvais scans. C'est que la page 40 est immaculée et la page 41 est terrible, dans le même fichier. Votre pipeline doit gérer les deux extrêmes et tout ce qui se trouve entre les deux, et il doit savoir, par page, à quel point faire confiance à ce qu'il a extrait.

C'est là que les modèles de ML visuels gagnent leur vie. L'OCR traditionnel regarde les caractères individuels et devine. Un modèle de vision voit la page entière : la structure du tableau, l'alignement des colonnes, le contexte autour de ce chiffre taché de café. Il peut lire « 12 345,67 € » même lorsque la virgule est obscurcie, car il comprend à quoi ressemble un relevé bancaire, pas seulement ce que les glyphes individuels décodent.

Le passage de l'OCR au niveau du texte à la compréhension visuelle au niveau de la page est ce qui rend les scans dégradés survivables. Une relique de fax qui met en échec la reconnaissance de caractères a toujours une structure visible : des lignes, des colonnes, des montants dans des positions prévisibles. Un modèle de vision qui a vu des milliers de relevés bancaires peut extraire à partir du motif même lorsque les pixels sont grossiers.

Le champ de mines de l'équation d'équilibre

Pour les relevés bancaires, il existe une équation impitoyable : start_balance + credits - debits = end_balance.

Quatre termes. Une infinité de façons de les briser.

Références inter-pages. Le solde d'ouverture est à la page 1. Le solde de clôture est à la page 120. L'équation couvre chaque segment, chaque série, chaque changement de mise en page entre les deux. Si n'importe quel segment est extrait incorrectement, l'équation se brise. Mais lequel ? Avec 7 segments et 4 000 transactions, trouver la mauvaise donnée est un problème en soi.

Transactions coupées par un saut de page. Une description de transaction s'étend sur les pages 47-48 : - Page 47 : « VIREMENT À ACME CORP » - Page 48 : « REF : 12345 - PAIEMENT FACTURE »

Une transaction ou deux ? Comptez-la deux fois et le solde se brise d'exactement un montant de transaction. Le genre d'erreur qui semble plausible jusqu'à ce que quelqu'un fasse un audit. La solution est le chevauchement : lorsque nous divisons le document en segments, les pages limites sont partagées entre les séries adjacentes. Les deux séries voient la transaction, mais l'agrégateur déduplique par coordonnées de page lors du réassemblage. Une seule copie survit.

La roulette des paramètres régionaux. Même banque, même relevé : - Segment 1 : 1.234,56 € (décimale virgule) - Segment 2 : 1,234.56 € (décimale point)

Analysez les deux « correctement » selon leur convention locale et vous obtenez deux nombres différents. L'équation d'équilibre se fiche des conventions. Elle voit juste que la somme est fausse.

Le chaos des conventions de signe. Banque A : les débits sont négatifs. Banque B : tous les montants positifs, avec une colonne D/C séparée. Banque C : débits entre parenthèses, (1,234.56). L'équation suppose des signes cohérents. Si l'extraction ne normalise pas avant de sommer, les crédits annulent les débits et le relevé semble vide.

Le piège de la tolérance de 0,02 €. Un relevé de 120 pages peut contenir des milliers de transactions, chacune analysée à partir de texte rendu et portant le risque d'arrondi au niveau de la source. Exiger une correspondance exacte rejette des documents valides. Trop de tolérance cache de vraies erreurs. 0,02 € est ce sur quoi nous avons atterri après avoir exécuté des données de production. Assez serré pour attraper les erreurs, assez large pour survivre aux arrondis.

Strict, puis intelligent, puis désespéré

Lorsque nous construisions le pipeline de validation de Holofin, nous avons essayé d'exécuter toutes les corrections en même temps. Cela masquait les problèmes de qualité des données. Des documents qui auraient dû être signalés passaient au travers. Nous l'avons donc reconstruit en trois étapes. L'ordre est la conception.

Étape 1 : Strict. Chaque transaction doit avoir une date de valeur. Chaque montant doit être analysé. L'équation d'équilibre doit tenir dans la tolérance. Si le strict passe, les données sont de haute qualité et nous avons terminé. La plupart des documents propres s'arrêtent ici.

Si le strict échoue, nous notons ce qui a échoué et nous continuons.

Étape 2 : Normalisation. Les données ont été extraites proprement, mais les conventions s'entrechoquent entre les segments. Séparateurs décimaux mixtes : virgules dans le segment 1, points dans le segment 3. Dates ambiguës : 01/02/2024 pourrait être le 2 janvier ou le 1er février selon la locale de la banque. Conventions de signe qui basculent entre les segments. La normalisation unifie tout cela avant de relancer la vérification du solde.

Étape 3 : Révision humaine. Lorsque l'automatisation ne peut pas résoudre le problème, le document est signalé à un opérateur. Pas « quelque chose ne va pas, bonne chance », mais « segment 4, pages 41-60, les crédits sont 3,20 € plus élevés que prévu. Commencez par là ».

Pourquoi cet ordre compte : le strict d'abord préserve la qualité des données. Nous ne normalisons que lorsque le strict échoue. Nous n'impliquons un humain que lorsque la normalisation ne suffit pas.

Tout exécuter en même temps masquerait les problèmes. Un document nécessitant une révision humaine doit être traité différemment d'un document qui a passé le strict. L'ordre est le signal de qualité.

Quand la majeure partie du document est correcte

Vous avez segmenté le monstre de 120 pages. Chaque segment a été extrait indépendamment. Des scores de qualité attachés par page. Et maintenant ?

Les segments doivent redevenir un seul document. Solde d'ouverture du premier segment, solde de clôture du dernier, chaque crédit et débit sommés à travers tous les segments. Ensuite, l'équation d'équilibre s'exécute une dernière fois, non pas par segment, mais sur l'ensemble.

Quand ça passe, vous avez fini. Quand ça échoue, la question intéressante est où.

C'est là que la plupart des pipelines prennent la mauvaise décision. Le solde est décalé de 3,20 €, donc tout le document est rejeté. L'opérateur ré-uploade, ré-extrait, re-valide, les 120 pages, parce qu'un segment a trébuché.

C'est la mauvaise réponse. En production, la plupart des documents sont majoritairement corrects.

Disons que le segment 4 sur 7 présente l'écart. Les six autres segments sont propres, validés, réconciliés, exportables. Nous ne les jetons pas. Nous signalons le segment 4, mettons en évidence la non-concordance et laissons l'opérateur résoudre le conflit avec le PDF source côte à côte. Le bon travail reste bon. Le mauvais segment reçoit l'attention humaine.

La source : un vrai scan de relevé bancaire avec des changements de qualité en milieu de document

L'extraction : les boîtes englobantes retracent chaque valeur jusqu'à sa source, même sur les pages dégradées

L'opérateur voit exactement ce qui doit être corrigé. Pas « votre document a échoué », mais « segment 4, pages 41-60, les crédits sont 3,20 € plus élevés que prévu, et la page 47 avait une confiance OCR faible (34 %). Commencez par là ».

C'est la différence entre un pipeline qui traite des documents et un pipeline qui respecte le temps de l'opérateur.

Les principes qui survivent à la production

Si vous construisez quelque chose de similaire, voici les leçons qui sont restées :

• Segmentez avant d'extraire. Traitez les changements de mise en page comme des frontières, pas comme du bruit.
• Mesurez avant de faire confiance. Les scores de qualité par page vous indiquent où l'extraction est fragile.
• Validez entre les segments, pas seulement à l'intérieur. Une page peut être correcte alors que le document est faux.
• Dégradez gracieusement, dans l'ordre. Validation stricte d'abord. Normalisation ensuite. Révision humaine en dernier. L'ordre encode la qualité.
• Journalisez tout ce que l'utilisateur n'a pas demandé. Les corrections système sont invisibles dans l'interface utilisateur et visibles dans la piste d'audit.

Les relevés bancaires sont le test de résistance, des milliers de transactions, de multiples mises en page, une qualité de scan qui change en milieu de document, et une équation d'équilibre qui exige la perfection à travers tout cela. Si votre pipeline survit à cela, les factures d'une seule page sont une erreur d'arrondi.

L'extraction est résolue à la page 1. La cohérence est résolue à la page 120. Et l'espace entre les deux, les changements de mise en page, les taches de café, les reliques de fax, les conventions de signe, c'est là que les pipelines naïfs vont mourir et que l'ingénierie minutieuse gagne sa vie.

Construisez pour le monstre de 120 pages dès le premier jour. Les documents d'une page s'occuperont d'eux-mêmes.