AuditCopilot : les LLM pour la détection de fraude en comptabilité en partie double

L'article que je lis cette semaine est AuditCopilot: Leveraging LLMs for Fraud Detection in Double-Entry Bookkeeping (arXiv:2512.02726), soumis en décembre 2025 par Kadir, Macharla Vasu, Nair et Sonntag. Il se situe à l'intersection de la recherche sur les agents LLM et de la conformité financière : l'utilisation de modèles de fondation pour détecter les écritures comptables frauduleuses dans les grands livres réels des entreprises. De tous les articles de la liste de lecture de Bean Labs jusqu'à présent, c'est celui qui concerne le plus directement le format de données brutes qui nous intéresse.

L'article

Chaque audit de société cotée — mandaté par la norme d'audit PCAOB AS 2401 — doit inclure des tests sur les écritures comptables (Journal Entry Testing - JET) : des vérifications systématiques du grand livre pour identifier les écritures signalées par des heuristiques basées sur des règles. Ces règles concernent des éléments tels que « écriture passée après minuit », « montant rond », « paire de comptes inhabituelle » ou « écriture passée par un utilisateur rarement actif ». Ces règles fonctionnent, mais elles génèrent des volumes énormes de faux positifs : les auditeurs passent la majeure partie de leur temps à écarter des bruits évidents.

AuditCopilot se demande si les LLM peuvent remplacer ou enrichir ces règles. Le système transmet chaque écriture comptable — structurée comme un extrait de texte de type JSON avec des champs pour la date de passation, les montants débit/crédit, les identifiants de compte, les taux de taxe et un ensemble d'indicateurs d'anomalies binaires précalculés — à un prompt LLM qui renvoie une étiquette d'anomalie binaire et une explication en langage naturel. Les auteurs évaluent Mistral-8B, Gemma-2B, Gemma-7B et Llama-3.1-8B sur un grand livre d'entreprise synthétique et sur un grand livre fiscal réel anonymisé, en comparant les résultats aux JET traditionnels et à une base de référence Isolation Forest.

Idées clés

• Sur le jeu de données synthétique (5 000 identifiants d'écritures, ~1 % de taux d'anomalie réelle), Mistral-8B avec le prompt complet atteint une Précision de 0,90, un Rappel de 0,98 et un score F1 de 0,94 — contre une Précision de 0,53, un Rappel de 0,90 et un F1 de 0,50 pour la base JET, et surtout seulement 12 faux positifs contre 942 pour les JET.
• Le prompt « complet » d'AuditCopilot inclut non seulement les caractéristiques brutes de l'écriture, mais aussi des statistiques globales du jeu de données (moyenne, médiane, montants aux 95e et 99e centiles) et un score Isolation Forest précalculé par ligne. Cette ingénierie de contexte est déterminante.
• Sur le jeu de données réel, Gemma-7B avec le prompt complet atteint une Précision de 0,89, un Rappel de 0,78 et un F1 de 0,83. Lorsque l'indice Isolation Forest est supprimé, la précision s'effondre à 0,14 — le LLM seul ne porte pas la charge.
• Les explications constituent la contribution la plus défendable du système : contrairement à un score d'anomalie numérique, chaque écriture signalée est accompagnée d'une justification textuelle (« ce montant dépasse le 99e centile pour ce groupe de comptes et est enregistré en dehors des heures de bureau »), qu'un auditeur peut rapidement accepter ou rejeter.
• Aucun réglage fin (fine-tuning) n'est utilisé. Tout fonctionne en zero-shot ou avec un bref prompt de rôle système, ce qui est avantageux pour le coût de déploiement, mais signifie également que les résultats dépendent fortement du modèle de prompt.

Ce qui tient la route — et ce qui ne la tient pas

Le résultat sur la réduction des faux positifs est frappant et concret. Passer de 942 à 12 faux positifs sur les mêmes données est le genre de gain opérationnel qui détermine si un outil est réellement utilisé en pratique. Je crois en cette direction.

Cependant, j'ai de sérieuses réserves sur la conception de l'évaluation.

Premièrement, les étiquettes de vérité terrain sur le jeu de données synthétique sont elles-mêmes construites à partir des règles JET. Les anomalies injectées sont exactement les types de schémas que les JET ont été conçus pour détecter. Ainsi, le fait que « le LLM surpasse les JET » sur un ensemble de test étiqueté par JET peut refléter en partie l'apprentissage par le LLM des mêmes règles à partir des statistiques contextuelles du prompt, plutôt qu'une généralisation au-delà de celles-ci.

Deuxièmement, l'ablation de l'Isolation Forest sur les données réelles est accablante d'une manière que l'article sous-estime. Le score F1 chute de 0,83 à 0,24 sans les scores IF. Cela m'indique que le LLM fonctionne principalement comme un seuil flexible au-dessus du signal IF, et non comme un détecteur d'anomalies indépendant. Le système est plus proche d'un ensemble de ML avec une interface en langage naturel que d'un « modèle de fondation effectuant un raisonnement d'audit ».

Troisièmement, un seul jeu de données réel, provenant d'un seul partenaire industriel. Les auteurs le reconnaissent, mais cela signifie que nous ne pouvons pas évaluer la généralisation selon la taille de l'entreprise, le système comptable ou le secteur d'activité.

Quatrièmement, l'article compare les résultats aux JET et à une seule base de référence ML (Isolation Forest). La détection d'anomalies basée sur les auto-encodeurs, XGBoost avec des caractéristiques ingénierées et la simple régression logistique sur les scores IF sont absents. L'espace de ce qui est considéré comme du « ML classique » ici est restreint.

La question des hallucinations n'est pas abordée. Les auteurs présentent les explications comme une contribution clé, mais il n'y a aucune évaluation pour savoir si les justifications textuelles sont factuellement correctes ou cohérentes avec la prédiction binaire.

Pourquoi cela compte pour l'IA financière

C'est l'article existant le plus proche de ce que Bean Labs construit. Les journaux Beancount sont des systèmes de comptabilité en partie double. Chaque transaction est un ensemble de lignes d'écritures. La détection d'anomalies sur ces lignes — comptes inhabituels, montants hors normes, schémas de dates invraisemblables — est une première fonctionnalité évidente pour un assistant financier autonome.

Le résultat d'AuditCopilot suggère que la bonne approche pour l'audit Beancount n'est probablement pas de « soumettre une écriture brute à un LLM et lui demander si elle est suspecte », mais plutôt de « calculer un contexte statistique léger (références au niveau du compte, distribution temporelle, scores Isolation Forest) et donner ce contexte enrichi au LLM ». La valeur du LLM réside dans la synthèse et l'explication, pas dans le scoring d'anomalies brut.

La réduction des faux positifs est également directement pertinente. Un outil d'audit Beancount qui affiche 942 anomalies potentielles par exécution sera ignoré. Un outil qui affiche 12 candidats à haute confiance avec des explications sera utilisé. Ce n'est pas une mesure de performance — c'est une mesure de produit.

La préoccupation concernant la sécurité de la réécriture (write-back), qui m'importe le plus, n'est pas abordée dans cet article. AuditCopilot ne fait que lire et signaler ; il ne propose pas de corrections et ne modifie pas le grand livre. C'est le bon périmètre pour un premier article, mais le problème difficile pour Bean Labs demeure : une fois qu'une anomalie est signalée, comment décider en toute sécurité de l'action à entreprendre ?

Que lire ensuite

• Understanding Structured Financial Data with LLMs: A Case Study on Fraud Detection (arXiv:2512.13040, ACL 2026) — présente FinFRE-RAG, qui ajoute des exemples en contexte augmentés par récupération au même problème de détection de fraude et évalue le système sur quatre jeux de données de fraude publics ; répond directement à la limitation du jeu de données unique d'AuditCopilot.
• Anomaly Detection in Double-entry Bookkeeping Data by Federated Learning System with Non-model Sharing Approach (arXiv:2501.12723) — traite de la contrainte de confidentialité qui empêche la mutualisation des données de grand livre entre les entreprises ; l'approche fédérée est probablement nécessaire pour tout service d'audit Beancount en production qui souhaite s'entraîner sur les données clients sans les centraliser.
• GuardAgent: Safeguard LLM Agents by a Guard Agent via Knowledge-Enabled Reasoning (arXiv:2406.09187) — le problème de l'application de la sécurité qu'AuditCopilot évite délibérément : une fois les anomalies signalées, comment s'assurer qu'un agent de réécriture ne valide pas de modifications violant les invariants comptables ?