Détection de fraude à la facture avec ChatGPT : architecture...

La fraude à la facture n’a rien d’un hack hollywoodien. En B2B, c’est souvent un PDF crédible avec une urgence calculée. Le vrai risque vient du manque de capacité de revue manuelle.

Les LLM de type ChatGPT lisent la facture et son contexte (emails, conditions, notes) et expliquent, de façon traçable, ce qui paraît anormal. Ils ne remplacent pas l’AP : ils aident surtout à prioriser les rares cas à vérifier.

Pourquoi la détection de fraude à la facture évolue

La fraude à la facture mêle processus, data et comportement. Les attaquants imitent le “business as usual” : modèles connus, fournisseurs plausibles, canaux ouverts.

Volumes en hausse, paiements accélérés et formats hétérogènes (PDF, scans, emails, portails) mettent les contrôles sous tension. Le three-way matching et les règles restent clés, mais ratent des cas limites visibles dans le texte.

Compromission de messagerie (BEC) avec demande tardive de changement de compte bancaire.
Factures en double (ou quasi) avec micro-variations (date, numéro, lignes).
Surfacturation cachée dans des libellés complexes ou des conversions d’unités.
Fournisseurs écrans ajoutés au référentiel avec des informations plausibles.
Redirection de facture : le PDF semble correct, les coordonnées de règlement ne le sont pas.

Les LLM captent ces signaux faibles : incohérences, ton inhabituel, écarts de politique en texte libre, ou différences par rapport à l’historique d’un fournisseur.

Ce que ChatGPT peut (et ne peut pas) faire pour la détection de fraude

Considérez ChatGPT comme une couche d’explication, pas comme l’unique détecteur. Le plus robuste : règles + Machine Learning + interprétation LLM, avec le LLM en mode consultatif.

Points forts des LLM :

Compréhension documentaire : extraction + contrôle de plausibilité sur des factures semi‑structurées.
Cohérence inter-sources : comparaison avec PO, contrats, livraisons, notes d’exception.
Synthèse de dossier : explication prête pour revue (« Qu’est-ce qui cloche, et pourquoi ? »).
Analyse des échanges : détection de formulations suspectes sur paiement/urgence.

Limites (et parades) :

Déterminisme : sorties variables. Parade : schémas JSON, température, LLM consultatif.
Arithmétique et matching : erreurs possibles. Parade : calculs/tolérances en code déterministe.
Ancrage sur des preuves : risque de réponses “confiantes” sans preuve. Parade : citations (RAG) ou rejet.
Contenu adversarial : prompt injection dans PDF/email. Parade : isoler texte non fiable + garde-fous.

Pour intégrer des LLM en finance avec des garde-fous, voir les services d’intégration ChatGPT.

If you need to separate “nice demo” from a production-ready fraud pipeline, we can help you scope the right roles for rules, ML, and LLMs.

Scope the fraud detection approach

Signaux data clés : au-delà du PDF

Le PDF seul suffit rarement. Les meilleurs signaux viennent de l’enrichissement avec données opérationnelles et historique : avant les prompts, pensez jointures de données.

Entrées à forte valeur :

Référentiel fournisseurs : création, validations, historiques bancaires, identifiants fiscaux/TVA, changements d’adresse.
Historique de paiement : montants, devises, conditions, saisonnalité, exceptions.
Rapprochement PO/GRN : PO absent, livraison partielle, lignes “misc”, couples quantité/prix atypiques.
Bancaire & bénéficiaire : nouvel IBAN, pays incohérent, compte partagé, nom du bénéficiaire divergent.
Contexte de communication : domaine/reply-to anormaux, urgence inhabituelle, changements tardifs.

Les LLM valent surtout si l’extraction est fiable. Sinon, sécurisez d’abord le pipeline : voir traitement OCR des factures.

If your invoice data is fragmented across ERP, email, and portals, we can help you design the minimum data model needed for reliable fraud signals.

Map the data signals

Architecture de référence : pipeline hybride (règles + ML + LLM)

Traitez la fraude comme un scoring de risque. Demandez au LLM d’extraire des preuves, vérifier la cohérence et résumer les anomalies ; le score final reste calculé par règles et ML.

Vue d’ensemble d’une architecture de production :

Ingestion : email, SFTP, exports AP ; stockage immuable des fichiers bruts.
Extraction : OCR + parsing ; objet facture structuré (fournisseur, totaux, lignes, coordonnées de règlement).
Enrichissement : jointure avec référentiel, PO/GRN, contrats, historique de paiement.
Scoring : règles (contraintes), ML (anomalie/classif), contrôles LLM (cohérence + texte).
Routage : auto-approbation faible risque, revue risque moyen, blocage risque élevé.
Apprentissage : retours de revue → recalibrage des seuils + ré-entraînement.

Deux rôles LLM à privilégier :

Auditeur de cohérence : alignement champs extraits ↔ records récupérés (ex. « texte vs périmètre du PO »).
Rédacteur de dossier : explication courte + checklist (ex. « appeler le fournisseur via un numéro connu »).

Ces briques s’intègrent comme en automatisation de factures (capturer → valider → router → auditer). Voir automatisation des factures.

Exemple d’orchestration avec sorties structurées :

# Pseudocode: hybrid invoice fraud scoring
invoice = extract_invoice(pdf)
features = enrich(invoice, vendor_master, po_grn, payment_history)

rule_flags = run_rules(features)          # deterministic checks
ml_score   = anomaly_model.predict(features)

llm_input = {
  "invoice_text": invoice.text_snippet,   # limited context only
  "structured_fields": invoice.fields,
  "retrieved_records": features.context,  # evidence from ERP/MDM
  "rule_flags": rule_flags
}

llm_result = llm_check_consistency(llm_input, output_schema="JSON")
# llm_result: {"risk_factors": [...], "evidence": [...], "summary": "..."} 

final_score = calibrate(rule_flags, ml_score, llm_result.risk_factors)

route_case(final_score, llm_result.summary, llm_result.evidence)

Sortie LLM bornée : preuves citées, pas de champs inventés, revue accélérée.

DataSqueeze conçoit des pipelines documents + LLM sécurisés (data engineering, évaluation, MLOps) pour passer du PoC à la production.

If you want a reference architecture tailored to your ERP and AP workflow, we can run a short workshop to define components, guardrails, and a PoC plan.

Run an architecture workshop

Évaluation et ROI : des métriques pour aligner finance et opérations

Problème d’événement rare : trop de rappel sature la revue ; trop d’automatisation laisse passer des cas atypiques. Il faut piloter ces arbitrages.

Métriques clés :

Précision à capacité de revue : parmi les cas investigués, combien sont réellement problématiques ?
Rappel des fraudes prioritaires : pour vos patterns clés, quelle fraction captez-vous ?
Coût des faux positifs : minutes de revue par alerte + coût des paiements retardés.
Délai de décision : temps bout en bout entre réception et décision de routage.
Qualité d’explicabilité : le “pourquoi” est-il clair et actionnable ?
Drift modèle/prompt : impact des changements de fournisseurs, mises en page, tactiques.

Créez un « challenge set » d’exceptions historiques (doublons, écarts, litiges, changements d’instructions, fraudes connues). Comparez règles, ML puis hybride avec explications LLM, et itérez avec les retours de l’équipe de revue.

Sécurité, confidentialité et conformité : pièges avec les LLM

Les factures contiennent données personnelles, bancaires et termes sensibles. Les LLM ajoutent des surfaces de risque à traiter tôt — surtout en secteur régulé.

Pièges et atténuations :

Exposition de données : envoi de documents bruts à des APIs tierces. Atténuation : minimiser, anonymiser, chiffrer, aligner rétention/traitement.
Injection de prompt : texte caché dans PDF/email (« Ignore previous rules… »). Atténuation : isoler le texte + sorties validées par schéma strict.
Récupération non autorisée : RAG qui remonte des données non accessibles. Atténuation : contrôle d’accès au retrieval + logs.
Décisions invérifiables : sortie sans preuves. Atténuation : stocker champs, records et réponse modèle (hash + contrôles d’accès).
Sur-automatisation : blocage sur un seul signal IA. Atténuation : confirmation multi-signal + revue humaine pour paiements critiques.

La clé n’est pas le prompt, mais la gouvernance : traçabilité, moindre privilège, monitoring, réponse à incident.

FAQ

ChatGPT peut-il remplacer le rapprochement à trois voies ?
Non. Le three-way matching reste central ; les LLM complètent en interprétant documents/contexte et en expliquant les exceptions.

Faut-il des données de fraude labellisées pour commencer ?
Pas forcément. Démarrez avec règles + anomalies non supervisées, puis labellisez via la revue. Captez le feedback dès le départ.

Comment éviter que le modèle “hallucine” des informations fournisseur ?
Retrieval avec contrôle d’accès + citations de preuves. Rejet des sorties hors schéma ou sans preuves.

Quel est un premier cas d’usage sûr ?
Des explications sur des factures déjà signalées : gain de temps, sans blocage automatique.

Ce que vous pouvez faire cette semaine

Documentez votre taxonomie de fraude : 5–10 patterns à détecter (doublons, changement d’IBAN, écarts PO, etc.).
Constituez un petit jeu d’évaluation : 200–500 factures + vérité terrain + notes de revue.
Construisez les jointures data : référentiel fournisseurs, historique de paiement, signaux PO/GRN.
Implémentez une baseline de règles : explicitez les contrôles pour mesurer les gains.
Ajoutez un LLM “rédacteur de dossier” : explication + checklist pour les factures signalées, contrainte à un schéma JSON.
Définissez les garde-fous : anonymisation, logs d’audit, accès au retrieval, contournement humain.

If you want to turn these steps into a concrete plan, DataSqueeze can run a short fraud-risk and data-readiness audit, then scope a PoC with measurable metrics and security guardrails. Discuss your invoice fraud detection use case with a DataSqueeze expert.

ChatGPT pour détecter la fraude à la facture : guide B2B pratique