BPCE has built an internal AI benchmark to avoid “paying for evaluation on every project without owning anything at the end,” and to work around the limits of public benchmarks. Mikaël Le Bars, who leads the group’s cross-functional AI expertise team within BPCE’s data science center, presented the initiative at Big Data & AI Paris 2026. The bank’s experience reflects a broader problem in the market: cheaper models on a per-token basis are not necessarily cheaper at the request level, something BPCE was able to verify on customer-support moderation through its own tests.

Public benchmarks, Le Bars argued, suffer from several weaknesses. Some contain flawed reference data: when Epoch AI released FrontierMath v2 in June, it acknowledged that 42% of the v1 problems contained errors. Many benchmarks are also saturating, becoming too easy for top models, which then hit maximum scores; Stanford’s latest AI Index estimates that this affects nearly half of the 60 most popular benchmarks. Models can also overfit to specific tests, so even a minor change can sharply reduce performance, as Apple researchers showed on a GSM8K derivative. Governance is another issue, since model vendors can test multiple versions before publishing one, which may not be the version actually sold to customers; some also help fund benchmarks, as OpenAI did with FrontierMath. Finally, there is an “Anglocentric” bias: MMLU, for example, includes more than a quarter of questions requiring “Western thinking,” and 85% of geographic references focus on North America or Europe.

BPCE’s framework was built around real business needs. The team mapped all the group’s projects, including PoCs and ideation work, then identified the skills each project required — moderation, translation, intent detection, and so on — and broke them down into testable tasks such as classification, speech recognition, and entity extraction. It then identified available datasets and, where needed, created new labels; in one project, employees recorded the text they had to read aloud. Alongside standard metrics such as BLEU and METEOR for translation or false positives and false negatives for sensitive-data extraction, BPCE added metrics specific to its own operations, such as error rates on banking-specific terms in audio transcription. Prioritization depends on use case, internal data availability and criticality, while also factoring in cost, latency and system robustness.

Technically, the benchmark was implemented with an object-oriented framework designed to evolve as new datasets, models or metrics are added. Code is deployed across multiple environments depending on data sensitivity and model availability. Every run is timestamped and tagged with the model version, dataset version and prompt version, and results can be exported via a common protocol into CSV files for business dashboards.

One of BPCE’s key findings is that pipeline configuration often matters more than the model itself. In a document-information extraction use case for financial documents, the model accounted for only 1 to 4 percentage points of impact, compared with 12 to 17 points for embeddings, 10 to 20 points for chunking/retrieval, and 14 to 21 points for OCR. Internal metrics also proved crucial in audio transcription. In a phone call containing the instruction “virer 45 000 € sur le compte 8837,” one model might omit the word “le,” while another might hear “40 000” instead of “45 000.” Standard metrics such as Word Error Rate would score both errors the same, even though their business impact differs. Adding punctuation and domain-specific terms makes the benchmark more discriminating.

BPCE’s evaluations also showed that rankings obtained under nominal conditions do not hold up well under noise, accents or out-of-distribution data. Building the benchmark required significant human effort for labeling, coding and deployment, but Le Bars described the trade-off as moving from “costs suffered” to a “chosen cost.” About 70% of the code is reusable. BPCE is now considering broader adoption across the group, with the solution available in the internal repository and a possible future open-source release. The next major step could be extending the benchmark to agentic systems, which are not yet deployed internally; in that case, the challenge will be to assess not only the final outcome, but also the sequence of actions taken to reach it.

Un modèle moins cher au token ne l’est pas forcément à la requête.

BCPE a pu le vérifier sur la modération de l’assistance client… grâce à son benchmark interne.

Mikaël Le Bars (photo) dirige l’équipe expertises transverses IA au sein du centre d’expertise data science du groupe. Au salon Big Data & AI Paris 2026, il est revenu sur le développement de ce benchmark.

À la racine, il y avait la volonté ne pas « payer l’évaluation à chaque projet […] sans rien posséder à la fin ». Il y avait aussi les limites des benchmarks publics.

Certaines de ces limites se manifestent dans la qualité des tests. Il arrive notamment que des données de référence soient fausses. Illustration dans FrontierMath. Lorsqu’il en a publié la v2 en juin, Epoch AI a reconnu que 42 % des problèmes de la v1 contenaient des erreurs.

En parallèle, nombreux sont les benchmarks arrivant à saturation : ils deviennent trop « simples » pour les principaux modèles, qui y atteignent les scores maximaux. Dans son dernier AI Index, Stanford estime que le phénomène touche près de la moitié des 60 benchmarks les plus populaires.

Les modèles ont aussi une tendance au surapprentissage : ils « collent » à certains benchmarks, si bien qu’une modification, même mineure, peut suffire à faire chuter les performances. Des chercheurs d’Apple en ont donné des illustrations sur un dérivé de GSM8K.

Se pose également le problème de la gouvernance des classements. Les fournisseurs de modèles peuvent tester plusieurs versions avant d’en publier une… qui n’est pas forcément celle proposée aux clients. On en a par ailleurs vu certains financer des benchmarks (OpenAI avec FrontierMath, par exemple). S’y ajoute un certain « anglocentrisme ». MMLU en témoigne. Plus d’un quart des questions exigent une « pensée occidentale » et 85 % des références géographiques se focalisent sur l’Amérique du Nord ou l’Europe.

Un framework orienté objets

Pour identifier les périmètres métiers, l’équipe de Mikaël Le Bars s’est basée sur tous les projets sur lesquels avait travaillé BPCE – y compris PoC et idéations. Elle a déterminé les compétences attendues dans chaque projet (modération, traduction, détection des intentions…) et les a découpées en tâches sur lesquelles évaluer les modèles (classification, reconnaissance vocale, extraction d’entités…).

Deuxième étape : identifier les datasets à disposition. Et éventuellement procéder à des labellisations. « Sur un des projets, on a tous enregistré du texte qu’on devait lire », explique Mikaël Le Bars.

Aux métriques à l’état de l’art (BLEU et METEOR pour la traduction, faux positifs et faux négatifs pour l’extraction de données sensibles…), BPCE a ajouté des métriques propres à ses activités. Par exemple, pour la transcription audio, le taux d’erreurs sur les termes spécifiques au milieu bancaire.

Le priorisation se fait selon l’usage, les données internes disponibles et la criticité, en prenant en compte le coût, la latence et la robustesse des systèmes mis en place.

L’implémentation s’est faite avec un framework orienté objets. Il permet de développer des composants évolutifs, pour recevoir de nouveaux datasets, modèles ou métriques.

Le code est déployé dans plusieurs environnements en fonction de la criticité des données et de la disponibilité des modèles. Chaque est horodaté et identifié par version de modèle, de jeu de données et de prompt. Un protocole commun permet d’exporter les résultats en CSV dans un tableau de bord pour les métiers.

La configuration est plus importante que le modèle

Entre autres éléments dont les benchmarks publics ne rendent pas forcément compte, il y a l’impact de chaque composante d’un pipeline sur la justesse des réponses. En la matière, BPCE évoque un de ses cas d’usage, sur l’extraction d’informations à partir de documents financiers. Son constat : la configuration est plus importante que le modèle. Celui-ci n’a qu’un impact de 1 à 4 points de pourcentage. Contre 12 à 17 points pour l’embedding, 10 à 20 pour la phase de chunking / récupération et 14 à 21 pour l’OCR.

L’intérêt des métriques internes est apparu en particulier sur la transcription audio. Plus précisément, le traitement d’une conversation téléphonique comportant la consigne « virer 45 000 € sur le compte 8837 ». Un modèle peut oublier le mot « le » tandis qu’un autre comprendra 40 000 au lieu de 45 000. Dans la pratique, les deux erreurs ne se valent pas. Mais une métrique standard comme le WER (Word Error Rate), très utilisé dans les benchmarks publics, produira le même score pour l’un et l’autre modèle. Y ajouter des aspects tels que la ponctuation et les termes métier permet de faire une différence.

L’agentique, un gros morceau en perspective

Au fil des évaluations, BPCE a conclu que le classement obtenu en conditions nominales ne résiste ni au bruit, ni aux accents, ni aux données hors distribution.

Quant à ce qu’a coûté la démarche : « Pas mal, d’abord en temps humain », entre labellisation, codage et déploiement selon Mikaël Le Bars. Mais « on échange des coûts subis contre un coût choisi ». Et 70 % du code est réutilisable.

BPCE réfléchit à impliquer davantage les entités du groupe (la solution est disponible sur le dépôt intenre). Notamment en permettant aux utilisateurs d’uploader leurs modèles et de configurer des prompts. Un passage en open source est envisagé à moyen ou long terme. Autre perspective : élargir le benchmark aux systèmes agentiques – pas encore déployés en interne. Le défi est singulier : il ne faudra pas évaluer que le résultat final, mais aussi l’enchaînement des actions réalisées pour y parvenir.

Illustration principale générée par IA

The post BPCE construit son benchmark IA : « Un coût choisi contre des coûts subis » appeared first on Silicon.fr.