Parcourir les registres et automatiser

TL; DR

L'automatisation robuste « swing » repose sur trois baleines : une ingestion déterministe (livraison sûre, idempotence, contrôle de l'intégrité), une couche de données normalisée (schéma unique, clés de correspondance, unités de temps/devises/signes normalisées) et une discipline rigoureuse de la qualité (validation, tolérances, DLQ, alertes, auto-correction). L'objectif est de transformer les fichiers/webhooks hétérogènes en tableaux stables pour le rapprochement, le reporting et la BI avec SLA sur l'accessibilité.

1) Paysage des sources et des formats

1. 1 Sources

PSP/acquéreurs/agrégateurs : transactions, réseaux, commissions, disputes.
Banques : relevés de MT940, ISO 20022 CAMT. 052/053/054, paiements PAIN. 001/002.
ARM/portefeuilles/paiements (OCT/RTP/SEPA) : registres payants, retours.
Crypto-castodi/échanges : transactions on-chein, rapports de conversion/commissions.
Impôts/État. portails : CSV/XLSX/PDF, parfois via un navigateur scripté.

1. 2 Formats

CSV/TSV (séparateurs variatifs, localités, codages).
XLSX (multi-shit, cellules fusionnées).
XML (ISO 20022 CAMT/PAIN, système personnalisé XSD).
SWIFT MT940/942 (champs de position).
JSON-API/NDJSON (décharges incrémentielles, curseurs).
PDF (tabulaires - parser ; scans - OCR).
ZIP/TAR. GZ (batchi avec plusieurs fichiers).

2) Architecture ingestion-pipline

1. Landing : l'acceptation sécurisée des fichiers (SFTP/FTPS/WebBOU/API/webhooks) → immédiatement compter checksum, garder les matières premières invariables.

2. Raw : mise en page par date/fournisseur/trampoline, stockage avec versions.

3. Normalize : parsing → unification des types/unités → tables normalisées.

4. Validé : après-validation (règles de qualité) → drapeaux, DLQ.

5. Matched : mise en correspondance avec des événements internes/banque.

6. Serving/BI : vitrines de rapprochement/finances/opérations.

• L'idempotence de l'ingestion : '(fournisseur, file_name, file_size, checksum, statement_date)' → une clé unique.
• Répétitions/retraits : La reprise du fichier ne crée pas de prises.
• DLQ (dead-letter queue) : tout ce qui n'est pas reconnu/a enfreint les règles est dans une file d'attente isolée.
• Versioning : un nouveau fichier pour le même jour → une nouvelle version avec un lien vers le précédent.

3) Sécurité de la livraison et des secrets

Canaux : SFTP avec clés limitées ; FTPS - seulement avec un TLS strict ; API - OAuth2/tokens avec TTL court.
Cryptage de contenu : PGP/GPG lors du téléchargement de fichiers ; S/MIME pour e-mail-inbox (si utilisé).
Contrôle d'intégrité : SHA-256/512 checksum, comparaison avec le hachage dans le manifeste.
Secrets : stocker dans Vault/KMS, rotation, interdit dans les fichiers/logs config.
Accès : RBAC + principe des « plus petits privilèges », comptes-services séparés.

4) Normalisation et schéma de données

4. 1 Règles universelles

Temps : toujours UTC en ISO-8601 ; pour les dates de settlement - 'DATE' sans TZ.
Montants : 'DECIMAL (p, s)' en unités mineures + 'scale' séparée ; signe : paroisse/consommation strictement selon le dictionnaire.
Devises : ISO-4217, table de taux fixe avec 'fx _ src'.
Localy : l'interdiction de l'autotest est un réglage explicite des séparateurs/décimales/millièmes.
Codages : entrée dans UTF-8 ; d'autres sont la conversion avec le logs.

4. 2 Couche « plane » normalisée (exemple)

json
{
"provider": "Acquirer_A",
"source_kind": "PSP_TX    PSP_SETTLEMENT    BANK    WALLET    CRYPTO",
"kind": "AUTH    CAPTURE    REFUND    PAYOUT    FEE    SETTLEMENT    CHARGEBACK",
"payment_id": "pay_123",        // ваше
"provider_txid": "psp_abc_789",    // внешнее
"merchant_ref": "mr_456",
"sequence": 0,             // partial/refund line index
"amount_minor": 100000,        // 1000.00
"currency": "EUR",
"fee_minor": 120,           // 1.20
"fx_rate": 1.0000,
"fx_src": "PSP    ECB    BANK",
"event_ts": "2025-11-03T12:00:00Z",
"value_date": "2025-11-05",
"account": "PSP_MERCHANT_CARD_A",
"bin": "425000",
"last4": "1234",
"status": "APPROVED    CAPTURED    SUCCESS    FAILED    SETTLED",
"file_id": "ing_20251103_001",
"row_hash": "sha256(raw_row)"
}

5) Parsers par format : réceptions et râteaux

5. 1 CSV/TSV

Définissez explicitement « delimiter », « quotechar », « escapechar », « encoding ».

5. 2 XLSX

Lecture par sheet whitelist ; Interdiction de la lecture automatique - aplatissement des cellules combinées.
Convertir les formules en valeurs ; dates Excel → UTC avec TZ explicite.

5. 3 XML (ISO 20022 CAMT/PAIN)

Validation par XSD ; XPath-mapping des détails ('<Ntry>', '<TxDtls>', '<Amt>', '<CdtDbtInd>').
Normaliser le credit/debit → signe ; prise en charge des multiples '<Chrgs>', '<RmtInf>'.

5. 4 MT940

Analyse des tags ': 61 :', ': 86 :' ; soutenir les élargissements nationaux ; les champs de position → les règles de slicing.
Consolidation de plusieurs ': 61 :' en un seul batch.

5. 5 JSON/NDJSON/API

5. 6 PDF/OCR

D'abord, une tentative de parsing tabulaire (clip-détecteur), puis seulement OCR (Tesseract) avec des caractères whitelist.
Post-validation : montants, résultats de contrôle, rapprochement du nombre de lignes.

5. 7 Archives/Batchi

Déballage avec conservation de la structure ; chaque fichier est un 'file _ id' distinct ; manifeste, contrôle de toutes les parties.

6) Validation et règles de qualité des données

• Schéma : tous les champs requis sont présents.
• Types : les montants sont numériques, les dates partent.
• Montants de contrôle/totaux : somme des lignes = total dans le fichier (le cas échéant).
• Fourchettes : date dans une fenêtre raisonnable ; somme> 0 (ou selon le dictionnaire des négatifs admissibles).
• Unicité : '(provider, provider_txid, sequence)' n'est pas dupliqué dans normalized.
• Tolérances : écarts valides 'amount/fx/time'.

Résultat : 'VALID', 'VALID _ WITH _ WARNINGS', 'INVALID → DLQ (reason_code)'.

7) Idempotence et déduplication

Ingestion key : '(fournisseur, file_name, filesize, checksum, statement_date)' → le seul 'file _ id'.
Row-level idem: `row_hash = sha256(normalized_row_compact)`; le redémarrage ne crée pas de nouveaux enregistrements.
Webhooks/API : 'idempotency _ key' fournisseur + vos étiquettes ('exec _ id'), stocker TTL.
Doublons du fournisseur : dedup par 'provider _ txid' + 'sequence', en divergence par DLQ_DUPLICATE.

8) Orchestration et horaires

Оркестратор: Airflow/Dagster (DAG: `fetch → decrypt → parse → normalize → validate → publish → match`).
SLA/SLO : 'Time-to-Availability (TtA)' de l'apparition du fichier à 'normalized = READY'.
Retrai : backoff exponentiel + jitter ; limites de tentative ; des statuts clairs.
Parallélisme et isolation : OCR/Parsing XLSX lourds - dans un pool/worker séparé avec une limite CPU/RAM.
DLQ-replay : replay périodique lors de la mise à jour des règles/mappings.

9) Observabilité et alertes

• Ingestion Success %, Parse Success % selon les sources.
• TtA p50/p95, Throughput (lignes/min).
• DLQ Rate и Aging DLQ p50/p95.
• Schema Drift Incidents (changement de titre/format).
• Duplicate Rate по `provider_txid`.

• `TtA p95 > SLA` → P1.
• 'Taux DLQ> 2 % 'par heure sur le fournisseur → P1.
• 'Schema Drift detected '→ P0 (arrêt auto-match par source).
• 'Duplicate spike '→ P2 (vérifier le fournisseur/webhooks).

Дашборд : l'entonnoir ' files → rows_raw → rows_norm → rows_valid → rows_matched ', la carte DLQ pour les raisons, TtA-kvantili.

10) Auto-corrections et mappings

Header aliases : dictionnaire avec versions (e. g., `Amount`→`amt`, `AMOUNT`→`amt`).

11) Lien avec le « Rapprochement des paiements et des rapports du PSP »

La couche normalisée finie est l'entrée pour le match (provider_txid/merchant_ref/fuzzy), le calcul de la taxonomie, les journaux auto et les settlement↔bank. Champs clés : 'provider _ txid', 'sequence', 'kind',' amount _ minor ',' value _ date ',' account '.

12) Modèle de stockage et tables

sql
CREATE TABLE landed_files (
file_id TEXT PRIMARY KEY,
provider TEXT,
source_kind TEXT,
file_name TEXT,
file_size BIGINT,
checksum TEXT,
statement_date DATE,
received_at TIMESTAMP WITH TIME ZONE,
version INT,
status TEXT, -- RECEIVED    PARSED    FAILED error TEXT
);

sql
CREATE TABLE psp_norm (
row_id BIGSERIAL PRIMARY KEY,
file_id TEXT REFERENCES landed_files(file_id),
provider TEXT,
source_kind TEXT,
kind TEXT,
payment_id TEXT,
provider_txid TEXT,
merchant_ref TEXT,
sequence INT,
amount_minor BIGINT,
currency CHAR(3),
fee_minor BIGINT,
fx_rate NUMERIC(18,8),
fx_src TEXT,
event_ts TIMESTAMPTZ,
value_date DATE,
account TEXT,
status TEXT,
row_hash TEXT UNIQUE,
repair_flags TEXT[]
);
CREATE INDEX idx_psp_norm_txid ON psp_norm(provider, provider_txid, sequence);

13) Pseudo-code parser

python def parse_table(file, spec):
df = load_csv_or_xlsx(file, delimiter=spec.delim, encoding=spec.enc, sheet=spec.sheet)
df = rename_headers(df, spec.header_aliases)
df = clean_amounts(df, thousand=spec.thousand, decimal=spec.decimal, sign_policy=spec.sign)
rows = []
for r in df.itertuples():
rows.append(normalize_row(r, spec))
return rows

python def parse_camt(xml):
root = parse_xml(xml, xsd="camt053.xsd")
for ntry in root.findall('.//Ntry'):
sign = 1 if ntry.findtext('CdtDbtInd') == 'CRDT' else -1 amt = Decimal(ntry.findtext('Amt')) sign
... map to normalized fields

python def parse_pdf_ocr(pdf):
text = tesseract(pdf, lang="eng", psm=6, whitelist="0123456789.,-;:/A-Za-z")
table = detect_table(text)
return normalize_table(table)

14) GDPR/PII et édition de logs

Masquage/hachage : PAN/email/téléphone → 'sha256 + salt', logs - sans valeurs primaires.
Stratégie de stockage : 'rétention' par type de source (AML/Buchet).
Accès aux IPI - uniquement par rôle ; vérification des lectures/exportations.

15) KPI et objectifs (pour parsing/ingestion)

Ingestion Success % ≥ 99. 5 %/jour par source.
Parse Success % ≥ 99%, DLQ ≤ 1%.
TtA p95 (fayl→normalized) ≤ 15 minutes (CSV/XML), ≤ 60 minutes (PDF/OCR).
Schema Drift Incidents : 0/mois sans alerte/fix.
Duplicate Rate по `provider_txid` ≤ 0. 05%.

16) Pleybooks d'incidents

Schema drift : stop auto-matching, inclure un parser « doux » avec ML-detect de colonnes, préparer un patch alias, chasser DLQ-replay.
Sursaut de DLQ : débogage des derniers fichiers, vérification du codage/local/signe, abaissement temporaire de la rigueur des tolérances (avec drapeau).
Retards SFTP : passage à API-polling/webhooks, augmentation des retraits, communication avec le fournisseur.
Spikes duplicates : activer le dopage « row _ hash », bloc de répétition jusqu'à ce qu'il soit élucidé.

17) Test-case-pack (UAT/Prod-Prepared)

1. Idempotence : Répétez le même chargement → 1 'file _ id', 0 nouvelles lignes.
2. Localy : fichiers avec ', '/'/espaces → des montants corrects.
3. Partial/refund : plusieurs 'sequence' à un 'provider _ txid'.
4. XML XSD : CAMT non valide → 'INVALID' + DLQ.
5. MT940 variations : extensions nationales → analyse correcte.
6. PDF→OCR : scan avec bruit → extraction et passage des règles de base.
7. Schema drift : un nouveau hader → un patch alias et un traitement répété des fichiers historiques.
8. Throughput : test de charge de N fichiers/heure → conformité au SLA TtA.
9. Édition PII : logs sans PAN/e-mail, hashi uniquement.

18) Chèque de mise en œuvre

• Registre des sources : protocole, planning, SLA, format, contact.
• Canaux sécurisés (SFTP/PGP/API), Vault pour les secrets.
• Idempotent ingestion + checksum + versions.
• Parser par format, alias-dictionnaire, signal/locale-politique.
• Calque normalisé et index de clés.
• Règles de validation, tolérances, DLQ et replay.
• Orchestrateur (DAG), retrai/backoff, pools de ressources.
• Observabilité : métriques, dashboards, alertes.
• GDPR/PII-masquage, audits d'accès.
• Cas de test et drills schema-drift réguliers.

Résumé

L'automatisation du parsing n'est pas « écrire parser », mais construire un circuit industriel : livraison et cryptage fiables, piplines idempotentes, normalisation stricte, règles de qualité et alertes transparentes. Ce schéma transforme tous les registres en tableaux prévisibles avec un SLA garanti sur l'accessibilité des données - un fondement pour les puces, la trésorerie et les rapports de gestion.