Cinq agents qui enquêtent sur les alertes de fraude au lieu de se contenter de les noter.

Un modèle de détection de fraude est bon pour une chose : vous indiquer qu’une transaction semble anormale. Il est bien moins efficace pour répondre aux questions que se pose réellement un analyste afin de clore l’affaire. Que s’est-il passé ici ? Pourquoi cela semble-t-il suspect ? Que doit-on faire immédiatement ?

FraudLens AI, un projet de hackathon pour le Google Cloud Hackathon 2026, est conçu autour de ce second type de questions. Il ne cherche pas à produire un score de fraude plus précis. Il entoure un score existant de cinq agents collaboratifs qui mènent l’enquête : ils collectent des preuves comportementales, mettent en corrélation les événements d’authentification, rédigent un résumé de l’affaire, et permettent aux analystes de consulter les données en langue simple.

Un score n’est pas une explication

De nombreux systèmes de détection de fraude s’arrêtent à un chiffre comme 0,87. Le modèle qui les sous-tend peut être excellent pour repérer les comportements suspects, mais un enquêteur qui consulte ce chiffre n’a toujours aucune idée de ce qui s’est passé ou pourquoi le modèle s’est déclenché.

Aujourd’hui, c’est une personne qui comble cette lacune : elle ouvre le compte, parcourt l’historique des transactions, vérifie si le dispositif est déjà apparu auparavant, lit les journaux d’authentification, compare les activités récentes aux schémas antérieurs, et rédige enfin une note d’analyse justifiant la décision prise.

Tout cela est lent et répétitif, et cela devient inefficace lorsque le volume d’alertes augmente. L’idée derrière FraudLens est de conserver le modèle de détection de fraude tel quel et d’automatiser l’enquête qui commence dès que le modèle déclenche une alerte.

Cinq agents, cinq tâches

La plateforme répartit l’évaluation des risques et les enquêtes entre cinq agents. Chacun a des responsabilités précises, tout comme des spécialistes qui se partagent le travail au sein d’une équipe de lutte contre la fraude.

Agent de détection

L’évaluation est effectuée à l’aide d’un classificateur XGBoost. Il a été validé sur l’ensemble de données public Kaggle Credit Card Fraud Detection, qui comprend 284 807 transactions et 492 cas de fraude confirmés. Les résultats de validation :

Cet ensemble de données du monde réel est utilisé uniquement pour valider le modèle de détection, une distinction qui reviendra plus loin.

Agent d’enquête

Lorsqu’une transaction dépasse le seuil d’enquête, cet agent crée le contexte qui l’entoure. Il examine :

• le comportement du compte et l’historique des transactions
• les montants qui ne correspondent pas au compte
• le comportement du pays et le contexte IP
• quels appareils sont liés à quels comptes
• les écarts par rapport aux schémas historiques

Ainsi, au lieu de fournir Score de risque : 0,92, le système produit des constats sur lesquels on peut agir, par exemple « ce montant est bien supérieur à la moyenne historique du compte » ou « cet appareil a été utilisé par plusieurs comptes différents ». Ces constats sont regroupés dans un dossier structuré que les agents suivants utilisent.

Agent d’analyse des journaux

Les activités de connexion constituent souvent la preuve la plus solide dont on dispose, surtout en cas de risque de prise de contrôle d’un compte. Le projet utilise un journal d’authentification synthétique contenant des événements tels que LOGIN_FAILED, LOGIN_SUCCESS, OTP_FAILED, NEW_DEVICE_REGISTERED et PASSWORD_RESET ; cet agent compare ces événements aux transactions suspectes.

LOGIN_FAILED (Multiple) ──> OTP_FAILED ──> NEW_DEVICE_REGISTERED ──> SUSPICIOUS_TRANSACTION

Une telle séquence vous en dit bien plus que la transaction elle-même. Elle révèle des signaux de prise de contrôle que un modèle ne pourrait jamais détecter s’il ne se concentrait que sur les paiements.

Où Gemini intervient, et où il ne l’fait pas

Agent d’explication

Google Gemini n’intervient qu’à ce stade. Les agents de détection et d’enquête produisent d’abord des preuves structurées, puis l’agent d’explication transmet ces preuves à Gemini afin qu’il les transforme en un récit lisible, quelque chose comme ceci : cette transaction est marquée comme CRITICAL car elle dépasse de loin le comportement normal du compte et correspond à des activités inhabituelles du dispositif et de connexion, ce qui nécessite un examen immédiat.

Le choix de conception important est que Gemini ne définit jamais le score de fraude. Cela explique les résultats déjà produits par du code déterministe. Cela garantit la fiabilité de la décision principale et signifie qu’une hallucination ne peut pas modifier le fait qu’un paiement soit marqué ou non.

Agent de requête

Les analystes peuvent taper des questions telles que "affichez-moi les transactions critiques en provenance du Nigeria". Le modèle n’a pas le droit d’exécuter du code arbitraire ou du SQL brut. Au lieu de cela, les appels de fonction de Gemini extraient l’intention et la transforment en paramètres validés, que du code ordinaire utilise ensuite pour récupérer les données.

Natural Language Request
       │
       ▼
Gemini Function Calling (Intent Extraction)
       │
       ▼
Structured Filters (risk_tier = CRITICAL, country = Nigeria)
       │
       ▼
Application Parameter Validation
       │
       ▼
Controlled Pandas Filtering Layer
       │
       ▼
Filtered Transaction Results

La récupération des données reste sûre, prévisible et facile à auditer.

Architecture et données

Tout le système est fourni sous forme d’une application Flask dans Docker, hébergée sur Render pour la démonstration en direct, avec une structure de conteneurs fonctionnant également sur Google Cloud Run.

Une décision délibérée a été de séparer les affirmations relatives aux tests de performance des capacités de démonstration. Les données de Kaggle ne sont utilisées que pour valider la détection, d’où provient un score ROC-AUC de 0,985. Les flux d’enquête en direct s’exécutent sur des données d’entreprise synthétiques, car les tests anonymisés ne comprennent pas de champs relationnels tels que l’historique des appareils, les journaux de connexion ou les liens entre comptes.

┌───────────────────────────────────────┐      ┌───────────────────────────────────────┐
│           REAL KAGGLE DATA            │      │        SYNTHETIC ENTERPRISE           │
│         284,807 Transactions          │      │     50,000 Transactions + Logs        │
└───────────────────┬───────────────────┘      └───────────────────┬───────────────────┘
                    │                                              │
                    ▼                                              ▼
┌───────────────────────────────────────┐      ┌───────────────────────────────────────┐
│          XGBoost Validation           │      │          Live Investigation           │
│ ROC-AUC 0.985 | Precision/Recall 82%  │      │  Accounts + Devices + Auth Logs       │
└───────────────────────────────────────┘      └───────────────────┬───────────────────┘
                                                                   │
                                                                   ▼
                                               ┌───────────────────────────────────────┐
                                               │         Interactive Dashboard         │
                                               │      Evidence + Gemini Narrative      │
                                               └───────────────────────────────────────┘

Flux de bout en bout

Lorsqu’un analyste commence une enquête, le pipeline s’exécute dans l’ordre suivant : l’agent de détection évalue la transaction, l’agent d’enquête rassemble les preuves comportementales, l’agent d’analyse des journaux ajoute le contexte d’authentification, l’agent d’explication rédige le récit, et le résultat est affiché sur le tableau de bord de l’affaire afin que l’agent de recherche puisse approfondir ses investigations.

Conçu pour échouer de manière contrôlée

Les API d’IA rencontrent des limites de fréquence et des erreurs réseau. Afin d’éviter que cela ne fasse planter l’application, le service de rédaction narrative Gemini est complètement séparé du pipeline déterministe.

Si l’appel Gemini échoue sans cette séparation, la page affiche une erreur 500. Avec elle, l’application renvoie néanmoins toutes les métriques de risque essentielles, les indicateurs du dispositif, les déviations comportementales et les détails des journaux, ainsi qu’un message non bloquant indiquant que le récit explicatif n’est pas disponible temporairement. Dans le pire des cas, on obtient un tableau de bord d’enquête normal qui continue de remplir sa fonction.

Leçons tirées du développement

• Soyez transparents concernant les données. En séparant la validation des références de la démonstration synthétique, on gagne la confiance des reviewers techniques qui, sinon, remettraient en question chaque chiffre.
• Collectez des preuves dans le code, raisonnez avec le LLM. Les règles et l’agrégation doivent figurer dans du code déterministe. Le rôle du modèle est de transformer ces résultats en une explication naturelle.
• Testez les composants qui n’ont pas besoin d’une API en temps réel. La suite comprend 53 tests destinés au pipeline déterministe, ce qui assure une grande fiabilité sans consommer de tokens API à chaque exécution.

Que vient ensuite ?

• Ingestion en flux continu via Google Cloud Pub/Sub et Dataflow au lieu du traitement par lots
• Stockage natif sur Google Cloud avec BigQuery et Firestore
• Réseaux neuronaux graphiques pour déceler des réseaux de fraude répartis sur de nombreux comptes
• Preuves multimodales, en intégrant des PDF de litige, des documents d’identité et des transcriptions de conversations dans le contexte de Gemini

Le principe sous-jacent

Le travail lié à la détection de la fraude ne s’arrête pas dès que le modèle affiche un score. L’essentiel réside dans la détermination des éléments de preuve qui expliquent l’alerte et des actions à entreprendre par l’analyste. FraudLens sépare clairement ces tâches : le modèle détecte, du code déterministe collecte les preuves, des agents spécialisés mènent l’enquête, tandis que le LLM se contente d’expliquer.