Le machine learning s'est installé dans les directions data des banques et des assureurs bien au-delà des projets pilotes. Deux terrains d'application concentrent l'essentiel des enjeux opérationnels et réglementaires : la détection de fraude, où le modèle doit trancher en quelques millisecondes, et le trading algorithmique, où la promesse de performance se heurte à la réalité de marchés non stationnaires. Entre les deux, une même discipline : construire des systèmes qui restent fiables, explicables et gouvernables une fois en production.
Détection de fraude : un problème d'abord statistique avant d'être un problème de modèle
Que ce soit sur les paiements par carte, les demandes d'indemnisation en assurance ou l'ouverture de comptes en ligne, la fraude partage une caractéristique structurante : elle est rare. Un jeu de données où les cas frauduleux représentent une fraction infime des transactions rend inopérants les réflexes classiques de classification. Un modèle entraîné sans précaution apprend simplement à prédire l'absence de fraude et affiche une exactitude trompeuse.
Les équipes data traitent ce déséquilibre par plusieurs leviers combinés :
- rééchantillonnage des classes minoritaires ou pondération différenciée des erreurs selon leur coût réel
- choix de métriques adaptées comme la précision et le rappel à des seuils de décision, plutôt que la seule exactitude globale
- construction de jeux de validation qui respectent la chronologie des événements, pour éviter toute fuite d'information du futur vers le passé
Des features comportementales plus que des features brutes
La performance d'un modèle de détection tient moins à l'algorithme choisi qu'à la richesse des variables construites en amont. Les données brutes d'une transaction apportent peu d'information isolément. Ce qui discrimine réellement une fraude, ce sont des signaux comportementaux agrégés : écart à l'historique du client, vitesse d'enchaînement des opérations, cohérence géographique, réseau de bénéficiaires ou de tiers déjà associés à des cas avérés. Cette ingénierie de variables mobilise souvent des fenêtres glissantes calculées à la volée, ce qui impose une architecture de données capable de rafraîchir des agrégats en continu, et pas seulement en traitement de nuit.
Sur le plan des modèles, les approches supervisées, entraînées sur un historique de fraudes confirmées, cohabitent avec des méthodes de détection d'anomalies non supervisées, utiles pour repérer des schémas inédits qu'aucun exemple étiqueté ne permettait d'anticiper. Les organisations les plus matures combinent les deux : un modèle supervisé pour les patterns connus, un module d'anomalies en complément pour capter la nouveauté, et des règles métier explicites pour les cas où la réglementation impose un contrôle systématique.
Scoring en temps réel et arbitrage faux positifs
Une fois le modèle validé, la contrainte change de nature : il faut produire un score en quelques millisecondes, au moment même de l'autorisation d'une transaction, sans dégrader l'expérience client. Cela impose des choix d'architecture spécifiques, un modèle assez léger pour être servi en ligne, un système de features précalculées accessible à faible latence, et un plan de repli si le service de scoring est indisponible.
Le vrai sujet de pilotage reste cependant l'arbitrage entre faux positifs et fraudes manquées. Bloquer trop de transactions légitimes dégrade la relation client et génère du travail d'investigation inutile pour les équipes ; relâcher le seuil laisse passer des pertes. Ce curseur n'est pas qu'un paramètre technique, c'est une décision métier qui doit être documentée, révisée régulièrement et assumée collectivement entre la data, les risques et la conformité.
La boucle de retour, condition de survie du modèle
Un modèle de détection de fraude n'est jamais figé. Les fraudeurs adaptent leurs méthodes dès qu'ils perçoivent les limites du système en place, ce qui provoque une dérive progressive de la performance. La qualité d'un dispositif se juge autant à sa boucle de retour qu'à sa précision initiale : les décisions des analystes qui confirment ou infirment une alerte doivent revenir alimenter les données d'entraînement, avec un circuit de réentraînement régulier et un suivi de la dérive des distributions en amont, pas seulement de la baisse des scores agrégés en aval.
Explicabilité et exigences réglementaires
En banque comme en assurance, un score qui bloque un client ou refuse un remboursement doit pouvoir être justifié. Les exigences de transparence des superviseurs, la gouvernance des modèles et le droit des clients à une explication imposent des méthodes d'interprétabilité qui restituent la contribution de chaque variable à une décision individuelle. Cette explicabilité n'est pas un ajout cosmétique postérieur au projet : elle conditionne le choix même du modèle, oriente la documentation exigée par les fonctions de contrôle interne, et doit être pensée dès la phase de cadrage.
C'est aussi pour cette raison que les plateformes d'industrialisation comme Dataiku trouvent leur place dans ce type de projet : elles permettent de tracer les versions de modèles, de documenter les features, de rejouer les décisions passées et de fournir aux équipes de contrôle une vision auditable du pipeline complet, du recueil de la donnée jusqu'au score final.
Trading algorithmique et gestion des risques
Le trading algorithmique attire l'attention par sa promesse d'automatisation, mais son usage du machine learning reste plus circonscrit qu'on ne l'imagine souvent. Les modèles y servent surtout à détecter des régularités dans des séries de marché, à ajuster dynamiquement des paramètres de gestion des risques, ou à filtrer le bruit dans des flux d'ordres, plutôt qu'à prédire directement des mouvements de prix de façon fiable.
Les limites y sont réelles et documentées. Les marchés financiers sont des systèmes non stationnaires : une relation statistique observée sur une période donnée peut disparaître ou s'inverser sans prévenir, ce qui rend le surapprentissage particulièrement dangereux dans ce contexte. Un modèle qui performe remarquablement sur données historiques peut échouer dès le changement de régime de marché. À cela s'ajoutent des risques opérationnels propres à l'automatisation : erreurs de configuration, boucles de rétroaction entre algorithmes concurrents, ou dépendance excessive à une infrastructure de données qui doit rester robuste sous forte charge. Ces sujets relèvent d'une discipline de gestion des risques modèles à part entière, distincte de la seule performance prédictive, et ne constituent en rien une invitation à un quelconque type de stratégie d'investissement.
Une exigence commune : la rigueur d'ingénierie
Ce qui relie la détection de fraude et le trading algorithmique, c'est moins la technique de modélisation que l'exigence d'ingénierie autour du modèle : qualité et fraîcheur de la donnée, capacité à réentraîner sans tout reconstruire, traçabilité des décisions, et alignement avec les équipes risques et conformité dès la conception. HaskeData accompagne les directions data des banques et des assureurs sur ce type de projet, du cadrage à l'industrialisation sur un socle Modern Data Stack, en gardant cette rigueur au centre de chaque étape.