IA en banque : pourquoi des résultats prêts à remise ne naissent pas du seul modèle.

Nombre de débats sur l’IA dans la finance confondent langage plausible et travail fiable. Un paragraphe bien tourné n’est pas encore un livrable relu et exploitable en dossier. Une présentation peut vite paraître convaincante. Un modèle financier doit toutefois **calculer**, avec des formules traçables, des hypothèses cohérentes et une capacité de scénarios. Lorsque des indicateurs sont saisis comme valeurs figées au lieu d’être dérivés par des formules, l’utilité pour un travail bancaire réel s’effondre, même si les visuels sont soignés.

BankerToolBench a été développé par Handshake AI et l’université McGill comme benchmark open source. Les tâches reflètent des activités typiques des juniors : parcourir des salles de données, interroger des plateformes de données de marché, analyser des dépôts SEC et produire **plusieurs fichiers liés**. L’évaluation s’appuyait sur des grilles définies par des banquiers expérimentés, en moyenne avec de nombreux critères par tâche, couvrant notamment l’exactitude technique, la qualité « client », le respect des consignes, la traçabilité et la cohérence entre fichiers.

Les échecs ne se limitaient pas à la formulation. Les modèles ont échoué sur les formules et le code, sur la logique métier, sur la cohérence entre fichiers, sur des extractions de données interrompues et parfois sur des **chiffres inventés** présentés comme sourcés. Un tel test compte pour les banques parce qu’il ne mesure pas si l’IA « sonne bien ». Il mesure si l’IA peut **livrer un travail** qui tient dans un cadre réglementé et data-intensif.

Le problème n’est pas le chatbot en soi. C’est l’hypothèse selon laquelle des systèmes génératifs pourraient produire un travail bancaire professionnel sans pilotage serré, socle de données clair et responsabilités définies. Dans la finance, l’approximation ne suffit ni pour le pilotage interne ni pour tout ce qui pourrait ensuite aller vers le client ou les instances.

Le contact client ne commence pas à l’entretien. Un mémo, un pitch ou un modèle devient proche du client dès qu’il entre dans un gabarit de décision. Les erreurs ne sont alors plus abstraites : elles influencent les appréciations, les recommandations et les transactions. L’usage direct vers l’extérieur reste le cas d’usage le plus exigeant. Y coexistent exactitude technique, traçabilité, conformité réglementaire et responsabilité interne. Un modèle peut produire du texte. **Il ne porte pas la responsabilité.**

La FINMA cible l’écart entre expérimentation et exploitation. Elle attend des établissements surveillés gouvernance et gestion des risques, inventaire et classification des usages de l’IA, ainsi que des responsabilités claires. Pour les solutions externes, elle souligne des difficultés particulières, transparence sur les données et méthodes employées, diligence raisonnable à l’égard des fournisseurs. Ce n’est pas de la formalité. C’est le cadre qui détermine si l’usage reste maîtrisable.

Les instances internationales ne réduisent pas le risque au « modèle » seul. La Banque des règlements internationaux (BIS) rappelle dans ses travaux de stabilité financière que l’IA, sans contrôles et supervision adéquats, peut amplifier des vulnérabilités existantes. Le Conseil de stabilité financière (FSB) cite notamment la dépendance aux fournisseurs tiers, les cyber-risques et les défis de gouvernance et de risque de modèle, en ligne avec ce que des benchmarks comme BankerToolBench révèlent sur des livrables concrets.

Pour banques, gestionnaires d’actifs et family offices, la priorité est sobre : placer l’IA d’abord dans des **processus internes contrôlés**. Là, elle peut rechercher, structurer, résumer, comparer et préparer. Elle peut soulager les spécialistes. Elle ne doit pas les remplacer précipitamment, ni lorsque des livrables se dirigent vers le client ou les comités sans revue humaine.

Les usages les plus productifs sont souvent en retrait de la vitrine : préparation d’entretiens, analyse documentaire, recherche interne, contrôle qualité, comptes rendus de réunion et premiers brouillons. Moins visible, plus robuste.

Le vrai goulot d’étranglement est l’architecture. Les sources de données doivent être validées. Les rôles doivent être fixés. Les livrables ont besoin de circuits de relecture. Les validations doivent être documentées. Les escalades doivent être claires. Sans cette structure, l’IA produit de la rapidité sans fiabilité.

BankerToolBench ne montre pas que l’IA est inutile en banque. Il montre qu’un **livrable prêt à remise ne naît pas du seul modèle**. Il naît d’un système fait de données, de processus, de contrôle et de responsabilité métier.

Dans la finance, ce n’est pas l’outil qui promet le plus qui l’emporte. C’est la structure qui livre des résultats corrects de manière reproductible.