Exemple : un agent IA pour réduire les faux positifs fraude d'une banque régionale

Exemple de situation. Cet article décrit une situation type, construite pour illustrer la démarche d'un agent IA de détection de fraude dans une banque régionale. Ce n'est pas un projet client, et nous ne publions pas de chiffres de résultat : ils dépendent de chaque établissement.

#1. Le problème : trop de faux positifs

Prenons une banque coopérative régionale, avec ses agences, sa clientèle de particuliers et de professionnels, et une culture de proximité face aux grandes banques nationales.

Le système de détection de fraude du cœur bancaire (CBS) déclenche un grand nombre d'alertes chaque mois, dont une majorité sont des faux positifs : des transactions parfaitement légitimes.

Ces faux positifs ne sont pas qu'un problème de confort de travail. Chacun génère une chaîne d'actions : examen manuel par un analyste fraude, vérification croisée dans le système d'information de la relation bancaire (SIRB), parfois un appel au client pour valider l'opération suspecte, mise à jour de la décision dans le CBS. Les analystes sont mobilisés sur la validation de transactions légitimes — au détriment des vraies fraudes.

Le délai de traitement d'une alerte est long. Pour les établissements assujettis au reporting ACPR sur les incidents de fraude, ce délai représente une fragilité réglementaire. Et une part des fraudes avérées passe à travers le filet.

La cause racine est connue : le système de règles statiques du CBS, fondé sur des seuils fixes (montant anormal, pays à risque, fréquence inhabituelle), a été conçu pour une époque révolue. Les comportements des fraudeurs et des clients légitimes ont évolué — notamment avec les paiements instantanés, le télétravail (connexions depuis des localités inhabituelles) et la fraude au virement par ingénierie sociale.

---

#2. Diagnostic : auditer le système d'alertes existant

Avant toute décision technique, un audit du système d'alertes existant permet de comprendre pourquoi le taux de faux positifs est si élevé et où se situent les opportunités d'amélioration.

Analyse structurelle du moteur de règles. Le CBS embarque des règles de détection actives codées en dur sur des seuils fixes. Exemple représentatif : une règle qui alerte sur tout virement sortant au-dessus d'un montant vers un IBAN non enregistré récemment. Elle génère à elle seule une part importante des alertes — dont la grande majorité concerne des virements légitimes vers de nouveaux fournisseurs, prestataires immobiliers ou achats en ligne de valeur.

Répartition des faux positifs par catégorie de règle : règles de montant à seuil fixe, règles de géolocalisation (connexion depuis une zone atypique), règles de fréquence, règles de pays à risque (liste noire statique non mise à jour), règles combinées (cumul de plusieurs micro-signaux).

Analyse des faux négatifs (fraudes non détectées). La cartographie révèle trois grands patterns absents des règles existantes : (1) la fraude au virement progressif — montants croissants sur plusieurs jours, chacun pris séparément sous les seuils d'alerte, (2) la fraude par usurpation de session — connexion depuis un appareil connu mais comportement de navigation inhabituel (vitesse de saisie, ordre des actions), (3) la fraude coordonnée multi-comptes — plusieurs clients touchés simultanément par le même mode opératoire, détectable uniquement en corrélant les alertes à l'échelle du portefeuille.

Charge de l'équipe. Des entretiens structurés avec les analystes permettent de calculer le temps passé par alerte vraie-positive et par faux positif, puis le temps total mensuel par rapport à la capacité nominale de l'équipe.

Le diagnostic met aussi en évidence un biais géographique possible dans les données historiques : si l'essentiel des données d'entraînement provient de zones urbaines alors qu'une part de la clientèle est rurale, ce déséquilibre doit être corrigé dès la phase de feature engineering.

---

#3. Architecture envisagée : anomaly detection ML + LLM explicabilité + triage automatique

L'architecture combine trois couches technologiques complémentaires, chacune répondant à une limite du système existant.

Couche 1 — Anomaly detection ML (scoring comportemental). Un modèle d'ensemble combinant Isolation Forest pour la détection d'outliers non supervisée et XGBoost pour la classification supervisée sur les fraudes labellisées historiques. Le modèle score chaque transaction (0 = comportement totalement normal, 100 = anomalie maximale) à partir de features calculées en temps quasi-réel depuis le flux transactionnel.

Cette approche remplace les seuils fixes par des seuils adaptatifs, calibrés sur le comportement propre de chaque client plutôt que sur des moyennes de portefeuille.

Couche 2 — LLM pour l'explicabilité et le triage. Pour chaque alerte générée par le modèle ML, un LLM (par exemple Claude de chez Anthropic) produit rapidement : (1) une explication en langage naturel des signaux déclencheurs (« Cette transaction présente plusieurs anomalies comportementales : montant très supérieur au ticket moyen du client sur ce type de commerçant, premier paiement vers ce bénéficiaire, appareil mobile non habituel »), (2) un niveau de priorité de triage (P1 critique / P2 élevé / P3 standard / P4 surveillance), (3) une suggestion d'action pour l'analyste (bloquer immédiatement / appeler le client / surveiller / clôturer sans action).

L'apport du LLM ici n'est pas la décision — c'est l'explicabilité. Les analystes fraude ne traitent plus des scores opaques ; ils reçoivent une explication structurée qui leur permet de valider ou d'invalider la suggestion bien plus vite. Pour comprendre ce qu'est un agent IA et en quoi il diffère d'un chatbot ou d'un RPA, c'est précisément cette capacité à orchestrer plusieurs outils (scoring ML, accès CBS, génération d'explication, classification de priorité) qui définit l'agent — pas simplement la génération de texte.

Couche 3 — Triage automatique et workflow d'escalade. Un moteur de règles dynamiques (Python + Redis pour la latence) aiguille les alertes selon leur score et leur priorité LLM :

• Score très élevé et P1 : blocage automatique de la transaction + notification client immédiate + alerte analyste senior
• Score élevé et P1-P2 : file prioritaire analyste avec un SLA de traitement court
• Score moyen et P2-P3 : file standard analyste
• Score faible et P3-P4 : clôture automatique de l'alerte avec log, sans intervention humaine

Bloquer automatiquement uniquement au-dessus d'un seuil de score très élevé est un choix délibéré, à défendre contractuellement avec la banque : en dessous de ce seuil, l'agent fait une recommandation que l'analyste valide — il ne bloque pas de transaction de façon autonome. Cette contrainte est cohérente avec le cadre double conformité RGPD et AI Act pour les systèmes de détection de fraude bancaire : le RGPD encadre les décisions automatisées à fort impact sur les personnes et appelle une intervention humaine.

Infrastructure. Le modèle ML tourne sur une instance cloud dédiée dans une région européenne. L'API du LLM est invoquée avec un DPA (article 28 RGPD) signé, et les données sont pseudonymisées avant transmission (tokenisation des IBAN et des numéros de clients). La contractualisation des SLA et KPI d'un agent IA anti-fraude en production détaille les clauses types recommandées pour ce type de déploiement.

---

#4. Phase 1 : entraînement sur l'historique et feature engineering

La phase de préparation des données est la plus longue et la plus exigeante du projet — et de loin la plus déterminante pour la qualité du modèle en production.

Constitution du dataset d'entraînement. Extraction de l'historique transactionnel du CBS sur une période longue (au minimum 18 mois). Chaque transaction est labellisée (fraude confirmée, faux positif, transaction normale non alertée) grâce au travail de labellisation des analystes sur leur historique de décisions.

Correction du biais géographique. Si les fraudes labellisées proviennent surtout de zones urbaines, on applique une technique de sur-échantillonnage comme SMOTE (Synthetic Minority Over-sampling Technique) sur les transactions rurales pour rééquilibrer le dataset, puis on vérifie que le biais de prédiction sur les clients ruraux (sur-alerte) a été réduit.

Feature engineering : features comportementales. Les features les plus prédictives typiques :

• Déviation comportementale individuelle : écart entre le montant de la transaction et la médiane récente pour ce client et ce type de commerçant
• Vélocité temporelle : nombre de transactions dans les heures précédentes pour ce client
• Score de cohérence géographique : distance entre la localisation de la transaction et le centroïde des dernières localisations du client
• Nouveauté du bénéficiaire : ancienneté du premier virement vers ce bénéficiaire
• Empreinte device : familiarité entre le device utilisé et l'historique d'appareils connus du client
• Corrélation portefeuille : présence d'alertes similaires simultanées sur d'autres clients dans les 48 dernières heures

Validation du modèle. Validation croisée sur un jeu de test mis de côté (hold-out). On mesure la précision, le recall (taux de détection de fraude réelle) et le F1-score. Le seuil de classification est calibré pour maximiser le recall (minimiser les fraudes manquées) au prix d'un taux de faux positifs résiduel, qui reste optimisable avec le retour des analystes en production.

---

#5. Phase 2 : pilote sur les cartes bancaires

Le pilote cible exclusivement les alertes sur transactions carte bancaire — cartes de débit et crédit, paiements en ligne et en point de vente. C'est le type de fraude le mieux documenté dans le dataset d'entraînement.

Mode shadow. Le système ML + LLM traite les mêmes alertes que les analystes, en parallèle et sans influence sur leurs décisions. Les sorties du modèle (score, priorité suggérée, explication) sont enregistrées mais non communiquées aux analystes. Après quelques semaines, on compare systématiquement :

• La concordance sur la décision finale (fraude avérée / faux positif)
• Les principales divergences : cas où l'analyste a détecté un élément contextuel absent des features (conversation téléphonique suspecte signalée par le client, changement d'adresse récent non mis à jour dans le CBS)
• Les cas où le modèle avait un score élevé alors que l'analyste avait conclu à un faux positif — dont certains se révèlent plus tard être des fraudes avérées

Réglage des seuils de triage automatique. Les seuils sont affinés après le shadow mode. Exemple d'ajustement : abaisser le seuil de clôture automatique si l'analyse montre que certaines alertes clôturées automatiquement méritaient un examen humain.

Passage en mode autonome. L'agent gère le triage des alertes carte en autonomie. Les analystes voient les alertes P1-P3 avec l'explication LLM, et peuvent invalider toute décision de clôture automatique dans un délai défini. Les invalidations sont intégrées au réentraînement du modèle.

---

#6. Phase 3 : extension aux virements et aux crédits, intégration SIRB

L'extension couvre les deux autres grandes catégories d'alertes fraude : les virements bancaires (SCT / SCT Inst) et les opérations de crédit (demandes de crédit en ligne, modifications de remboursement).

Virements bancaires. Les virements représentent la catégorie à plus fort enjeu financier. La principale fraude ciblée est la fraude au virement par ingénierie sociale (FOVI), où le fraudeur convainc le client de réaliser un virement vers un IBAN qu'il contrôle.

Spécificité technique : le modèle ML entraîné uniquement sur des features transactionnelles ne suffit pas. Pour les FOVI, le signal le plus prédictif est comportemental — le client lui-même réalise l'opération après avoir été manipulé. Features additionnelles : analyse du canal de contact précédant le virement (appel entrant récent, email reçu dans les heures précédentes), score de cohérence entre le destinataire et les relations habituelles du client, vitesse de saisie anormalement rapide sur l'interface web (indicateur de stress ou de guidance externe).

Ces features nécessitent une source de données supplémentaire : le SIRB, qui contient l'historique des interactions client (appels, emails, rendez-vous agence). Cette intégration demande un temps de développement supplémentaire, justifié par l'amélioration de la détection des FOVI.

L'architecture RAG pour connecter l'agent aux données transactionnelles internes permet au LLM de retrouver des patterns de fraude historiques similaires lors de la génération des explications, ce qui améliore la pertinence des suggestions d'action.

Opérations de crédit. Les alertes fraude sur les crédits (usurpation d'identité pour ouverture de crédit à la consommation, modification frauduleuse de coordonnées de remboursement) ont souvent le taux de faux positifs le plus élevé. Cause typique : les règles du CBS ciblent les demandes à fort montant depuis des IP étrangères, ce qui génère des alertes massives sur des clients légitimes résidant temporairement à l'étranger (étudiants Erasmus, expatriés en séjour de retour, travailleurs frontaliers). Un modèle ML comportemental, calibré sur l'historique individuel du client, corrige ce défaut.

Conformité DSP2/DSP3 et ACPR. Les évolutions DSP3 vs DSP2 et leur impact sur la lutte anti-fraude en open banking imposent des exigences accrues sur la traçabilité des décisions de blocage. Le pipeline doit inclure un module de logging complet de chaque décision (score ML, explication LLM, action prise, identifiant analyste pour les décisions humaines) dans une base de données immuable, prête pour un audit et pour le reporting ACPR.

---

→ Prêt à passer à l’action ? Réservez un appel découverte de 15 minutes avec notre équipe pour analyser votre projet — sans engagement.

#7. Ce qu'on mesure

Nous ne publions pas de résultats chiffrés pour cet exemple. Dans un vrai projet, on compare systématiquement les indicateurs à la situation de départ.

#Indicateurs globaux (tous types de fraude confondus)

• Taux de faux positifs
• Délai moyen de traitement d'une alerte
• Taux de détection de fraude réelle
• Coût par alerte traitée
• Temps d'analyste consacré au triage de faux positifs
• Part des alertes traitées sans intervention humaine

#Par catégorie de fraude

On suit les mêmes indicateurs pour la fraude carte bancaire, la fraude au virement (SCT/SCT Inst, dont les FOVI) et la fraude crédit / usurpation d'identité, car les gains diffèrent selon la catégorie.

#Impact opérationnel sur l'équipe fraude

Les analystes, précédemment absorbés par le triage de faux positifs, voient leur activité se redistribuer : moins de validation de faux positifs, davantage d'investigation approfondie de vraies fraudes, de reporting réglementaire ACPR et de veille sur les nouveaux modes opératoires. Le temps libéré peut être réorienté vers le renforcement du pôle conformité et vers une cellule de veille sur la fraude émergente (deepfake, SIM swapping, attaques API), sans avoir à recruter.

#Pertes évitées

C'est l'indicateur le plus significatif pour la direction : l'évolution des pertes fraude non récupérées. Elle s'explique à la fois par l'amélioration du taux de détection et par la réduction du délai de traitement, qui permet le blocage de transactions frauduleuses encore réversibles.

---

#8. Ce qui peut ne pas fonctionner : fraude de nouvelle génération, biais géographiques

Tout déploiement honnêtement documenté inclut ses zones de friction et d'échec. Deux sont typiques, plus une troisième plus technique.

#Zone d'échec 1 : fraude deepfake vocal (appels simulant le conseiller bancaire)

Un mode opératoire non couvert par le modèle peut apparaître : des fraudeurs appellent des clients en usurpant la voix synthétisée d'un conseiller bancaire connu (deepfake vocal), et les convainquent de valider par téléphone des opérations inhabituelles. Le client réalise ensuite l'opération via son application bancaire — un comportement qui paraît parfaitement normal du point de vue des features transactionnelles, puisque c'est bien le client qui agit depuis son appareil habituel.

Le modèle ML ne peut pas détecter ce vecteur : aucune anomalie transactionnelle, aucun signal device suspect, aucun écart comportemental. Ces cas sont détectés après coup, lors d'un signalement client.

Actions correctives possibles : (1) une feature additionnelle de détection d'appels entrants dans la demi-heure précédant une transaction inhabituellement élevée (intégration SIRB approfondie), avec un score de suspicion renforcé si l'appelant provient d'un numéro non enregistré ; (2) une règle de sécurité complémentaire dans le CBS pour déclencher une confirmation supplémentaire auprès du client.

Ces mesures réduisent l'exposition à cette fraude sans la couvrir complètement — le deepfake vocal reste un vecteur en dehors du périmètre du modèle ML.

#Zone d'échec 2 : biais géographiques persistants sur les zones rurales profondes

Malgré la correction de rééquilibrage appliquée en phase de feature engineering, un biais résiduel peut apparaître lors d'un audit interne : les clients de zones rurales de faible densité ont un taux de faux positifs supérieur à la moyenne du portefeuille.

Cause : ces clients ont des comportements transactionnels très stables (faible diversité de commerçants, faibles montants habituels), ce qui amplifie l'impact de toute déviation ponctuelle. Un déplacement professionnel, un achat en ligne sur une nouvelle marketplace, ou un virement vers un notaire suffisent à déclencher des scores de suspicion élevés.

Correction possible : segmentation du modèle par profil de comportement transactionnel (très actif urbain, actif urbain, modéré mixte, faible rural) avec des seuils de score calibrés par segment, puis réentraînement avec davantage de données labellisées rurales.

#Problème technique : latence du LLM en heure de pointe

Lors d'une journée de forte activité transactionnelle (fin de mois, virements de salaires et prélèvements groupés), le pipeline LLM peut présenter des latences supérieures à la cible pour la génération d'explications, par saturation de l'API en heure de pointe.

Solution : une file d'attente Redis avec dégradation gracieuse — pour les alertes P3 et P4, l'explication LLM est générée de façon asynchrone plutôt qu'en temps réel. Seules les alertes P1 et P2 maintiennent une génération synchrone, garantie par un pool d'instances API dédiées.

La sécurité des agents IA : checklist OWASP LLM Top 10 appliquée aux systèmes bancaires doit être intégralement appliquée, notamment sur le risque d'injection de prompt via les champs libres des formulaires de signalement de fraude.

---

#9. Mesurer le retour sur investissement

La méthode de calcul et justification du ROI d'un projet agent IA anti-fraude doit rester conservative : seuls les gains directement traçables et mesurables sont retenus. Les gains indirects (satisfaction client, impact réputationnel, conformité renforcée) sont mentionnés mais ne sont pas intégrés dans le calcul principal.

#Les coûts à compter

• Développement du modèle ML et du pipeline de feature engineering
• Intégration au CBS, au SIRB et à l'API du LLM
• Infrastructure cloud dédiée
• Formation de l'équipe fraude et accompagnement au changement
• Licences logicielles (outils MLOps, monitoring, Redis)
• Conseil juridique RGPD + AI Act + DPA
• Audit de conformité ACPR avant déploiement
• Coûts récurrents : infrastructure ML, API du LLM, maintenance du modèle et réentraînements, monitoring

#Les gains à mesurer

• Pertes fraude évitées : le gain le plus significatif, avec un facteur d'attribution prudent (une partie des gains peut venir d'autres mesures menées en parallèle).
• Temps d'analyste libéré : il ne se traduit pas en réduction d'effectif mais peut éviter des recrutements budgétés.
• Réduction du coût opérationnel par alerte : à croiser avec le gain précédent pour éviter le double compte.
• Conformité ACPR renforcée : un gain réel mais difficile à quantifier ; on le retient de façon très conservative.

Pour les établissements bancaires comparables, les agrégateurs bancaires Bridge, Tink et Powens pour enrichir les données comportementales ouvrent une perspective complémentaire : enrichir les features comportementales avec des données open banking pour améliorer la précision du scoring sur les clients multi-banques.

Cette approche s'applique à tout établissement bancaire régional ou mutualiste disposant d'un historique transactionnel suffisant et d'un CBS structuré. Pour nos services agent IA sur mesure pour le secteur bancaire et financier, l'architecture est reproductible ; la configuration est systématiquement sur mesure (chaque établissement a son CBS, ses règles métier, son portefeuille client).

Un MVP d'agent IA démarre à 11 000 € HT, et un audit IA express d'une journée coûte 990 € HT (déduit du projet s'il est lancé dans les trois mois).

L'exemple d'agent IA sur traitement de sinistres en assurance illustre comment la même approche d'agent IA hybride s'applique à d'autres secteurs financiers réglementés.

Photos : MART PRODUCTION, RDNE Stock project sur Pexels.