Des clients de la Banque Populaire et de la Caisse d’Épargne sont alertés d'un incident susceptible de provoquer des débits en double sur leurs comptes bancaires, ce 29 octobre 2026. Le problème viendrait d'un autre établissement français, mais son origine exacte reste à préciser.
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.
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 exécution est horodatée 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.
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.
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.
Connexion