refactor: retire les parseurs texte de repli

Les parseurs géométriques (par cellules de tableau) traitent les 5 PDF du
corpus sans jamais déclencher le repli : les parseurs texte étaient 586
lignes de regex fragiles, non testées, à maintenir à chaque évolution du
format de sortie. Les références golden sont inchangées après leur
suppression — l'extraction produit exactement la même chose.

Le parseur géométrique devient donc le seul chemin : ce qu'il ne lit pas
est perdu. L'orchestrateur distingue maintenant les deux cas :

- aucun lot lu -> ExtractionError (422 côté API). Un compte rendu sans
  lot n'existe pas : c'est le tableau qui n'a pas été reconnu, et mieux
  vaut échouer que d'enregistrer un document vide découvert bien plus
  tard, au moment de relire les chiffres ;
- aucune opération -> accepté. Un mois sans dépense reste plausible.

_extract_lot_code_from_description était la seule fonction encore
utilisée : elle rejoint utils.lots sous le nom
extract_lot_numero_from_description, à côté de normalize_lot_numero.
extract_text_from_pdf, sans appelant, disparaît au passage.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
2026-07-26 09:44:20 +02:00
parent 1b319dff4e
commit ea5bdac18a
9 changed files with 122 additions and 635 deletions

View File

@@ -20,7 +20,7 @@ from unicodedata import normalize as _normalize
import pdfplumber
from ..utils.amounts import extract_amounts_from_line
from .operations import _extract_lot_code_from_description
from ..utils.lots import extract_lot_numero_from_description
_Y_TOL = 3.0
@@ -218,7 +218,7 @@ def extract_recapitulatif_operations_from_pdf(pdf_path: str) -> list[dict]:
"fournisseur": current_fournisseur,
"description": desc,
"lot_concerne": None,
"lot_numero": _extract_lot_code_from_description(desc),
"lot_numero": extract_lot_numero_from_description(desc),
"montants": {k: (montants[k] or 0.0) for k in _AMOUNT_KEYS},
"_block": block_id,
}