Finance & intelligence artificielle
IA en finance : qui doit faire quoi ?
« Commentez SKILL pour mes 47 prompts magiques. » « Commentez CLÔTURE pour l’agent qui fait tout. »
On ajoute des skills, des agents, des modèles. Mais en finance, on oublie la question essentielle : qui doit faire quoi ?
Un amortissement ou un ratio n’a pas besoin d’un LLM pour être calculé. L’IA a un autre rôle : comprendre le contexte, proposer la règle applicable, appeler le bon moteur et savoir quand s’arrêter.
Un calcul exact n’est pas encore une bonne décision
Calculer un amortissement linéaire, une variation ou un ratio est un problème déterministe dès que les entrées, la formule et les conventions sont fixées. Le résultat doit pouvoir être reproduit sans dépendre d’une reformulation du prompt. Demander au modèle de produire lui-même le chiffre ajoute une incertitude inutile.
En revanche, choisir la durée d’utilisation, identifier la date pertinente, distinguer deux conventions de calcul ou décider du traitement d’une exception demande du contexte. L’IA peut rechercher les éléments, rapprocher les sources et proposer une interprétation. Si plusieurs règles restent plausibles, elle doit exposer l’ambiguïté plutôt que la masquer derrière un nombre.
C’est une distinction d’architecture : la compréhension prépare le calcul ; elle ne remplace pas son exécution. Et un moteur déterministe ne dispense pas de contrôler ses entrées, ses unités, ses arrondis et la version de la règle.
| Couche | Responsabilité | Limite à respecter |
|---|---|---|
| ERP | Exécuter les opérations autorisées et conserver les écritures de référence. | Une proposition d’agent n’est pas une autorisation de comptabiliser. |
| Moteurs | Appliquer les formules, les arrondis et les contrôles versionnés. | Un calcul exact peut reposer sur de mauvaises données ou hypothèses. |
| IA | Interpréter la demande, réunir les pièces, proposer la règle et orchestrer les appels. | Elle ne doit ni inventer un paramètre manquant ni étendre ses droits. |
| Humain | Valider les hypothèses sensibles, traiter les exceptions et assumer la décision. | La validation doit porter sur des preuves consultables. |
Un ERP peut embarquer son moteur de calcul. Ce qui compte est la séparation des responsabilités et des contrôles, pas le nombre de briques.
Ce que les études et benchmarks mesurent réellement
Les quatre travaux ci-dessous éclairent des problèmes différents : calcul, lecture de documents financiers, traçabilité du raisonnement et exécution répétée. Leurs scores ne sont pas comparables entre eux. Ce sont des résultats historiques de 2021 à 2024, pas un classement des modèles disponibles en septembre 2026 ni une mesure des performances de HOLCO.
PAL : séparer le raisonnement et l’exécution
+15 points sur GSM8K
Dans le protocole publié, PAL avec Codex dépasse de 15 points de pourcentage PaLM-540B utilisant le chain-of-thought sur GSM8K. Le modèle produit un programme ; un interpréteur Python exécute le calcul. Ce résultat montre l’intérêt de la séparation des rôles, pas une garantie de fiabilité financière.
Portée du résultat. GSM8K porte sur des problèmes mathématiques rédigés. Le programme généré peut être faux. Un interpréteur qui exécute fidèlement du code ne valide pas la règle métier ; en production, privilégions des fonctions testées et des paramètres contrôlés.
Lire l’étude originale : PAL: Program-aided Language Models (2022) ↗FinanceBench : accéder aux documents ne suffit pas
81 % de réponses incorrectes ou de refus
Ce taux concerne GPT-4-Turbo avec un système de recherche documentaire dans l’expérience de 2023. L’étude évalue 16 configurations sur un échantillon de 150 questions financières, pour 2 400 réponses relues manuellement. Une source accessible n’assure donc pas que le bon élément sera retrouvé puis correctement utilisé.
Portée du résultat. Le taux agrège erreur et refus : ce ne sont pas deux risques équivalents. Il ne décrit ni tous les systèmes RAG ni les modèles actuels. L’enseignement opérationnel est de contrôler la recherche, la preuve et le calcul séparément.
Lire l’étude originale : FinanceBench: A New Benchmark for Financial Question Answering (2023) ↗FinQA : vérifier le chemin jusqu’au chiffre
Des programmes de raisonnement de référence
FinQA associe des questions sur des rapports financiers, rédigées par des experts, à des programmes de raisonnement annotés. L’intérêt pour une équipe finance est méthodologique : on peut examiner les opérations nécessaires, pas seulement comparer une réponse finale.
Portée du résultat. Un jeu de questions sur des rapports ne reproduit pas une clôture complète. Nous en retenons un principe de contrôle : conserver les entrées, les opérations et les références permettant de rejouer le calcul.
Lire l’étude originale : FinQA: A Dataset of Numerical Reasoning over Financial Data (2021) ↗τ-bench : réussir une fois n’est pas réussir toujours
Moins de 25 % en pass⁸ dans le retail
Dans les expériences publiées en 2024, les agents testés, dont ceux fondés sur GPT-4o, réussissent moins de 50 % des tâches. Dans le retail, le pass⁸ descend sous 25 % : cette mesure porte sur la réussite de toutes les répétitions d’une tâche sur huit essais, et non sur la réussite d’au moins un essai.
Portée du résultat. Ces environnements ne sont pas des dossiers comptables. Le résultat ne chiffre pas un risque de clôture. Il justifie de tester la constance, le respect des règles et l’état final des outils, au-delà de la qualité d’une conversation.
Lire l’étude originale : τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (2024) ↗Exemple : préparer un amortissement sans déléguer la décision
Prenons un exemple pédagogique : un actif de 12 000 €, une valeur résiduelle nulle, une durée de trois ans et un exercice complet, sans prorata. Une fois ces hypothèses validées, la dotation annuelle linéaire est de 4 000 €. Ce chiffre relève du moteur. Cet exemple n’est pas une prescription de traitement comptable.
L’IA retrouve la facture, recherche la politique applicable, rapproche les caractéristiques de l’actif et présente les paramètres à contrôler. La durée ou la date de mise en service manque ? Elle demande une précision. Deux pièces se contredisent ? Elle signale le conflit. Elle ne transforme pas une supposition en règle du dossier.
Le moteur reçoit des paramètres structurés et renvoie le montant avec sa trace de calcul. Le professionnel vérifie les hypothèses qui engagent son jugement. L’ERP enregistre ensuite l’opération dans son circuit d’autorisation. En lecture seule, l’agent s’arrête à une proposition documentée : il ne passe aucune écriture.
Le benchmark utile teste toute la chaîne
Un score sur des questions financières ne suffit pas à autoriser un agent à intervenir dans une clôture. Il faut tester la chaîne réelle, avec ses documents, ses outils, ses règles et ses permissions. Les résultats attendus doivent être établis indépendamment du modèle évalué.
Pour comparer deux architectures, gardons les mêmes dossiers de test et les mêmes droits. Comparons un LLM seul, puis un LLM relié aux sources, puis une orchestration avec moteurs contrôlés et validation humaine. Répétons les essais : une réussite isolée ne dit rien de la constance.
- Calcul : montant, signe, unité, période et arrondis exacts selon le cas de référence.
- Contexte : bonne règle, bonne entité, bonnes pièces et références vérifiables.
- Abstention : arrêt attendu devant une donnée manquante, contradictoire ou hors périmètre.
- Exécution : respect des droits et absence d’action non autorisée, y compris après une erreur d’outil.
- Utilité : temps de revue humaine, corrections nécessaires, coût et latence par dossier accepté.
Remettre l’humain là où son jugement compte
Faire relire chaque addition à un expert serait un mauvais usage de son temps. Lui faire approuver une conclusion sans accès aux pièces serait une fausse supervision. La bonne frontière porte sur les hypothèses sensibles, les contradictions, les exceptions et les décisions engageantes.
Les cas couverts par une règle approuvée peuvent suivre un circuit automatisé avec contrôles et traces. Les autres doivent arriver à la bonne personne, avec la question précise à trancher. Le pouvoir de bloquer ou de corriger doit être réel, et la décision conservée.
Un skill décrit une procédure. Un agent enchaîne des actions. Aucun des deux ne remplace une répartition explicite des responsabilités. Ajouter des agents avant de tracer cette frontière, c’est multiplier les intervenants sans clarifier qui répond du résultat.
Le sujet n’est plus ce que l’IA peut faire. C’est où mettre la machine, et où remettre l’humain.